刚接触 docker 和反向代理的时候，我用的是 Nginx Proxy Manager 。
但后来我注意到 Nginx Proxy Manager 的 GitHub 页面上有 1.5K 个待解决的 issues... 这对于一个反向代理，一个负责管理你公开 80 和 443 端口的服务，并不是个好现象。因为写过 web 应用的应该都知道，web 这玩意儿，更新很重要，一会儿不更新你用的什么依赖就爆出漏洞了。如果一个重要的 web 项目上有一堆 bug ，那安全性就要打问号了。
我之前没怎么注意，就只是把 nginx proxy manager 换成 caddy ，把自己服务器所有端口关掉，改用 tailscale 访问而已。
但我今天在网上晃悠的时候看到了这个 Nginx Proxy Manager 的 issue ，2024 年 1 月的 issue：
github.com/NginxProxyManager/nginx-proxy-manager/issues/3503
该死，400 多个 CVE 漏洞，真的假的？
他 issue 里面提供的扫描容器的网址已经挂了，不过没关系。有个开源的容器漏洞扫描工具叫做 Trivvy ，我用这个工具扫描了一下最新的 Nginx Proxy Manager 的 docker 镜像。
github.com/aquasecurity/trivy
该死，真的有好几百个 CVE 漏洞，还有两个 Critical 级别的漏洞...
有点吓人，考虑到 Nginx Proxy Manager 应该现在还是自部署领域比较主流的反向代理工具，影响面还是挺大的。
如果可以的话还是改用其他的反向代理吧。
关于 “容器被黑了又能怎么样” 的问题

虽然 Docker 容器具有隔离性，但这不是绝对安全的！
Docker 的隔离性主要依赖于 Linux 内核的 namespaces 和 cgroups 技术。

Namespaces: Namespaces 提供了进程、网络、挂载点、用户等资源的隔离。

Cgroups: Cgroups 用于限制容器可以使用的资源，例如 CPU 、内存、磁盘 I/O 等。

然而，隔离性不是万无一失的，它依赖于以下因素:

内核的安全性: 容器与宿主机共享同一个内核，因此内核漏洞可能导致容器逃逸。

Docker 的配置: Docker 守护进程和容器的配置是否安全，例如是否以 root 权限运行 Docker 守护进程，是否将宿主机的敏感目录挂载到容器中，是否禁用了不安全的功能等。

容器内部的应用安全: 容器内部运行的应用是否存在漏洞，例如 SQL 注入、代码执行等。

我自己比较担心的是黑客攻破服务器之后，拿来当跳板干花活，最后给我惹上麻烦...
另外还在把 docker 运行在 root 权限上的，记得去配置一下 无 root docker ，不要把 docker 进程跑在 root 权限上...

😁正经服务器谁用？
Trivvy 只要没更新系统啥的几百个也正常吧，多读书多看报

docker 反向代理应该用 nginx:stable 这个镜像

Nginx Proxy Manager 不是本地开发用的吗，一点都不稳定

都是因为懒才用这玩意，不过我最近刚换成了 1panel 里的 openresty ，也是图形化操作，而且 1panel 里可以申请泛域名证书，比 npm 方便很多。南墙也可以做反代，但给的默认用户名密码显示不对，放弃。

😰
正在用 Nginx Proxy Manager ，看起来好危险。

我都是内网用避免有些应用强制 https ，外面用 VPN 连回来

还可以统一用一个端口

目前用 nginxui 主要是用它配置 nginx+ssl 挺方便。

漏洞啥的就说不来了

看成 ng 有千把个漏洞，冷汗冒了 0.01s

＃4 试试 NginxUI github.com/0xJacky/nginx-ui

用 traefik 吧

玩具，而已。

这种涉及修改基础设施配置的工具，一般就不该暴露 UI 出去的，都是内部网络，自己一个人访问，很多漏洞可以无视。

treafik 很方便

treafik 是要在每个容器上都配上指定的 label 吗，这样感觉侵入性好强

＃15 可以用最基础的 file config 模式

这种必须禁止公网访问的东西，无所谓了

这就是不同工种的区别了，开发用 Nginx Proxy Manager 方便你本地调试，真上线上环境了就得用 nginx/caddy 这种了，这就是运维的活了，而靠谱的运维是必须过一遍 nginx 源码的，因为很多细节文档是没讲清楚的

这种反代工具，本身是不在公网曝露的，所以有没有 CVE 并不影响，何况还有 docker 环境隔离。如果 dock 是 root ，那就办法了。
要说漏洞，当年系统加软件漏洞都已经有上千个了，我家里的反代还是跑在 freebsd 5.3 上，要知道现在的 freebsd 已经是 14 了。
你只要保证给应用/进程最低的权限、最低的曝露量，再加一些权限验证，其实你 10 几年不升级都没问题。
我再举个当下的例子，pve 使用 lxc 搭建应用平台，一般人都是直接在 lxc 里以 root 运行实例，而我从来都是自己在 lxc 里另开单独的帐户，有时候不给帐户 login 权限，跑相应的实例，挂载的 host 文件夹也通过 setfacl 设定最低的权限。 无论有多少漏洞，都不担心安全问题。

…
不是 NPM 本身程序有漏洞慌啥，按截图的 libaom3 搜了下，是音视频解码的 library ，而 NPM 仅是个 proxy ，不参与实际的 decode 行为，要是数据包/proxy 层面的巨大漏洞不修复则是维护者有问题

而 op 的结论和应届出的等保报告有何区别？

用了十多年 nignx ，第一次听说有 nginx proxy manager 这种东西。。

Nginx Proxy Manager 比原生的 nginx 还难用。
我遇到过容器内部的某些依赖版本过新导致更新证书报错，也有更新证书进程失败导致容器启动失败的。反正一堆问题。

后来把配置抄一抄，直接本地运行 nginx ，把证书续签换成 lego ，舒服多了。

都用 npm 了，不如直接上 caddy ，更省心

你说的是这个?

hub.docker.com/layers/library/nginx/stable-perl/images/sha256-11b3f27123be3c21f43fc974e44295ef741af25bc9ad75c5c7b247f45d7de241

caddy 啊，比这个好用多了

笑死，当然没区别，我就是应届生🤡 也不是搞网络安全的

这种反带工具最佳实践毫无疑问是限内网访问，很多佬也不会用这种奇奇怪怪的 GUI 玩意儿，我自己也是 caddy + tailscale 纯内网访问。

但现在自部署相关的文章/视频有一大把都是用 nginx proxy manager 的 (国内外都是)，搞自部属的，刚入门的 用这个一堆... 这也很合理，nginx caddy 都没有 GUI ，而 nginx proxy manager 有。很多人会倾向有个 web ui 来管这个的...

最近我才遇到一个用这个的，还把源服务器 ip 漏出来了，随便扫一下就扫出了好多服务，甚至 ssh 用的还是密码登入... 这样的人很多... 起码得提醒他们一下吧...

我都是手动配置，写监听脚本同步配置到不同服务器上

我选择 traefik

用 lucky,刚好解决 ipv6 和 ipv4 的问题
安全方面用 ufw 做好

但是这个简单好用啊，别的还得手写配置，懒～

还是 caddy 反代简单，也就使用基础的一些功能，刚好够用。