davehandong

就算是固定 IP ，也是限制对外的 80,8080,443 端口的。

@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 的解决方案文件。

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

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

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