为什么我让应用只监听本机地址

给应用接入域名时，一个很容易图省事的做法，是把容器端口直接发布到所有网卡，再让反向代理转发过去。这样应用本身也有了一个绕过入口的公网路径。我的个人服务器准备承载不同项目，入口若越来越多，靠记住“哪个端口不能被外部访问”并不可靠。

把公开入口收在一处

目前的约定是由 Caddy 接收公开的 HTTP 和 HTTPS 请求，再依据域名送到静态站点或本机应用。应用发布端口时，明确绑定回环地址。下面只是示意值，不是本站的实际端口或部署名称：

ports:
  - "<loopback-ip>:<app-port>:<container-port>"

这样应用在主机上仍可被 Caddy 访问，但远端不能直接用该端口连接。它让公开路径集中到 Caddy，证书、域名和转发规则也更容易一起检查。某个应用将来需要自己的子域名时，只需增加对应的 DNS 与 Caddy Host 路由；不需要先建统一的 API 网关。

示例中的 <loopback-ip>、<app-port> 和 <container-port> 都是占位值。实际配置里需要填入主机的回环地址和应用真实监听端口，再核对容器内部端口是否一致。这样写文章时能说明端口映射的结构，却不用把正在运行的生产端口公布出来。

配置意图要和实际监听一致

只在 Compose 文件里写了回环地址还不够。我在建立基础部署模式时，用过临时 API 容器作端到端验证：确认应用健康，确认主机监听只落在本机地址，再从 HTTPS 域名请求到预期响应。测试后清理临时容器与路由。这个过程验证的是“应用经公开入口可用”以及“应用端口没有按预期以外的方式暴露”，而不是把一个临时示例当成生产服务。

检查监听可以用系统的 socket 列表，检查公开入口则要从服务器外面访问。两者回答不同的问题：前者看进程究竟绑在哪个地址，后者看用户实际能否经域名和可信证书访问。即使本机地址绑定正确，云侧规则、DNS 或代理配置仍可能让服务不可用。

我还会把“从外部无法直接访问应用端口”和“经 HTTPS 可以访问应用”一起看。只有前一项通过，可能只是服务根本没起来；只有后一项通过，又不能排除应用端口同时向公网开放。这个成对检查，比单看一次成功的浏览器页面更贴近我想要的边界。配置里的默认规则和真实网络行为，必须对得上。

反向代理本身也不会自动替应用关掉另一扇门。如果容器端口已经发布在所有网卡上，再给它加一条 Caddy 路由，外部仍可能绕开 HTTPS 入口直连应用。因此我会先检查 Compose 的绑定地址，再看主机真实监听和外部访问结果。这个顺序能避免一种错觉：浏览器经域名访问正常，就以为网络暴露也已经收敛。

边界不是全部安全性

回环绑定可以减少直接暴露面，但不能代替应用自身鉴权、更新、日志和数据保护。Caddy 收到请求后，应用仍然要正确处理输入。未来若某项服务确实需要直连公网端口，我会把它作为一次明确的例外，先说明原因、影响和验证方式，而不是默认给每个容器开一个公网口。

对我当前的小规模部署，这条规则的价值很朴素：新增项目时不必重新发明入口，也能从配置和实际监听两处核对“哪些东西真的在公网”。