@zhangjiashu2023 这不是 waf 的问题，而且 waf 是很耗性能的。

服务器层面
先从外网用 nmap 之类的工具扫一下看看对外开放了哪些端口，然后一个个去分析，没用的关了。
打开系统的防火墙，只对外开放需要的端口。
类似如 ssh 这样的服务如果非要外网访问，把 22 端口改成其它的一定程序上也有效果，关闭密码登录验证方式。其它服务思路也类似。

应用层面
你说的是一个典型的前后端分离的常规部署方式，没啥问题，但是也解决不了什么安全方面的问题。
安全上我觉得得具体看你的系统本身写的时候考虑的全不全了，像 SQL 注入，XSS 之类的，可以自己去扫一下，该解决的解决，waf 并不能完全解决问题。
然后就是应用的日志，记录好，记录全。Nginx 的日志也打开，定期看看有没有什么可疑的访问方式。

不对
你前端好比是 nginx ，那也必然要反向代理到后端啊，不然两个地址一直跨域访问吗？
这里只考虑应用级别的渗透，那操作的目标本来就是你的前端地址，然后 nginx 反向代理到后端，不是同样可以访问到后端么。
最简单的渗透用 burpsuit 之类的代理一下接口就全出来了。

自己买个硬盘靠谱

我觉得 C/C++“交叉编译”的意义不大。
通过 cmake 构建的如果写的严谨，理论上可以在不同平台下面编译，但也只是理论，
因为打个比方说 setsockopt 函数，在 windows 、linux 、mac 下面都有，但是有区别，一套代码想都支持，要解决这种情况太多了。
C/C++可能会依赖不同的动态链接库(.so .dll .dylib)，这个也是交叉编译的一个坎儿。
我觉得 cmake 挺好，比直接写 Makefile 简单，而且在 win 环境还能生成 msvc 的解决方案文件。

我觉得还是得看这些文件存储以后具体会有什么样的操作吧，根据实际的情况去选择。
如果是一个“小说”的“系统”，我觉得不会是某一种存储方案。
文件的基本信息需要放到关系型数据库里，文件本身其实我是倾向于放到对象存储里面，根据文件总量、单个文件大小、并发量还有能够接受的延迟，去选择具体的对象存储。
单纯从使用上说我从 S3, MinIO, Ceph 这三个里面去选，因为 api 基本兼容，后面不管换啥，代码都不需要修改。

成本 NAS 做 raid5 ，每天定时增量备份到 TrueNAS ，然后照片每年会记得成蓝光盘。

Js 跟 C 没有啥可比性，运行机制不一样。就像上面说的完全不是一个赛道上的。

程序员而已哪来这么强的优越感

glfw ，或者直接 vtk

是有这个现象。
电脑上不想装那么多乱七八糟的东西，而且鼠标键盘用浏览器也没觉得麻烦。
手机上浏览器使用就不如电脑方便，应用之类的套不套壳无所谓，好用就行。

Java 不是也支持了 var 声明变量么,C/C++里现在也有 auto ，我是一直挺反感这个的.
一方面像 js 这种往 typescript 这方向走，另一方面本来是强类型的又非要引入弱类型的风格。

应该是看具体产品和平台的设计吧
我 C621A 平台，16 条最大全插满也能跑 3200MHz

只是测试开发的话，如果身边有一些个旧电脑是不是可以利用一下

再补充一下，nginx 服务启动不要用 root 帐户

先想一下有没有可能操作系统或者服务本身是有问题的。
然后 nmap 之类的工具看一下哪些端口是可访问的，把没必要的都关了
ssh 直接登录操作的可能性我觉得不大，但是限制一下不能用密码登录也不费事，还有就是默认端口号可以改最好也改一下。
你这个 nginxs 配置文件只有一个反向代理，面儿上看我觉得是没啥问题的吧
可以看一下你的 nginx 版本号，用了哪个 module ，然后看一下这个版本有没有一些 CVE ，最好升到最新的。
也可以再看一下 accesslog.
其它的就得看具体还有啥服务了

如果还要跑虚拟机，是不是 pve 比直接运行 CentOS 更方便一点儿