Node.js 监听 localhost 还是 0.0.0.0？反向代理与端口暴露
监听地址决定进程在哪些本机网络接口接受连接，防火墙则决定流量能否到达，两者不是同一项设置。本文适用于受维护的 Node.js 和使用标准网络监听接口的应用；框架可能有自己的配置名称，应确认最终传给监听方法的值。
先区分几类地址的作用
127.0.0.1 是 IPv4 回环地址，通常用于同机进程访问；0.0.0.0 表示监听所有本机 IPv4 接口，并不是访客应该输入的目标地址。IPv6 的回环和通配地址又不同，不能只检查 IPv4 就认定整个主机没有暴露入口。
省略 host 参数时，运行时可能选择未指定地址，行为还涉及操作系统的双栈支持。因此需要内部服务时，应显式配置地址，不要依赖“没有写地址就只能本机访问”的猜测。Node.js 网络监听说明
同机反向代理可明确监听回环
如果 Nginx 与 Node.js 在同一主机，应用只需要通过 Nginx 对外提供服务，可以采用如下监听思路：
server.listen(3000, '127.0.0.1');
这里的 server 应是应用已经创建好的 HTTP 服务对象，不是可单独运行的完整程序。Express 等框架应在自己的入口按相应方式传入端口和地址。配置变化后查看实际监听状态，确认没有另一个旧进程仍在所有接口监听同一业务。
代理入口继续处理域名和 HTTPS，应用端口无需额外开放公网。需要从另一台服务器访问时，应选择受控内网地址并限制来源，而不是立刻改成所有接口后依赖一个未经验证的规则。
容器里的 localhost 属于容器自己
如果应用和代理位于不同容器，代理容器访问自己的回环地址并不会到达应用容器。它们应通过已配置的容器网络和服务名称通信，应用监听也要允许该容器网络的连接。
容器内部监听所有接口与把宿主机端口发布到公网是两个层次。可以让应用在容器内接受连接，同时只向必要网络提供访问，或把宿主机发布端口限制到回环。不能仅看到应用使用 0.0.0.0 就认定已公网暴露，也不能仅看到 UFW 拒绝就认定容器端口安全。
可信代理设置应匹配真实路径
反向代理通常通过请求头传递客户端地址和原始协议。应用必须知道哪些代理可以被信任，否则可能错误生成 HTTP 链接、识别访客 IP，或被伪造头影响访问判断。
以 Express 为例，trust proxy 的设置需要与实际代理层数或可信来源一致，不能把任意访问都视为可信代理。不同长度的接入路径也可能影响基于跳数的信任假设。Express 代理部署说明
如果公网仍能绕过 Nginx 直接访问应用，攻击者可能提交本应由代理写入的头。应同时约束网络入口与应用信任配置，两者互相配合，不能只改其中一项。
分别从主机与外部验收
在服务器检查监听并请求一个真实只读入口：
sudo ss -lntp
curl --max-time 5 http://127.0.0.1:3000/health
把路径换成应用实际提供的健康或只读页面。再从授权外部电脑访问正式域名，并检查应用直连端口是否符合预期限制。测试一个成功请求还不够，登录跳转、客户端地址和 HTTPS 识别都应核对。
变更前记录原监听方式、代理地址和服务启动参数。若内部通信被阻断，恢复刚才修改的地址并重新检查路径，不要同时清空防火墙。交付时保存拓扑和测试结果，后续从同机改成容器或跨机部署时，才能准确调整访问边界。