执行 docker run -p 8080:80 ... 后，服务器公网 IP 的 8080 端口突然能打开页面；明明在 ufw 里拒绝了这个端口，外部请求却仍然进得来。这类现象往往与端口发布的默认地址、Docker 的转发规则有关。
Docker 官方文档说明：省略宿主机地址时，发布端口默认绑定宿主机的所有地址。8080:80 中的 8080 也不会自动成为“仅内部可用”的端口。[1] 如果服务只供本机 Nginx 代理，通常应显式绑定回环地址；如果调用方也是容器，则可以考虑取消宿主机端口发布，改用容器网络通信。
本文讨论普通 Linux Docker Engine、rootful 模式下的 bridge 网络与常规 NAT 发布。host 网络、Swarm、rootless 和 Docker Desktop 的流量路径存在差异，不能直接套用所有结论。以下命令用于自有服务器的核查与配置示例，未代表对读者环境进行过实测。
一、8080:80 到底开放在哪个地址上
下面两种配置的暴露范围不同：
# 发布宿主机的 8080，未限定宿主机地址
docker run -d --name web -p 8080:80 nginx:stable
# 仅将宿主机 IPv4 回环地址的 8080 映射到容器 80
docker run -d --name web -p 127.0.0.1:8080:80 nginx:stable
这是两个互斥的写法示例，不要在已有同名容器的机器上连续执行。实际项目需要保留原镜像、卷、环境变量和启动参数，不应直接用示例替换生产容器。
第一个命令中的宿主机端口可能通过公网、内网及其他宿主机接口接受请求，前提是对应网络路径与访问控制允许通过。第二个命令限定的是宿主机这一侧的发布地址。
IPv6 要单独检查。需要本机 IPv6 入口时，可使用 -p '[::1]:8080:80'。未指定宿主机地址的发布，在特定配置下还可能将宿主机 IPv6 请求转到 IPv4 容器，例如 IPv4-only bridge 配合默认 userland proxy。[1] 只验证 IPv4 不能证明 IPv6 已经收敛。
另外，Docker 文档对低于 28.0.0 的版本提示了一个历史问题：同一二层网络的其他主机可能访问发布到 localhost 的端口。[1] 使用旧版时，应结合升级、网络隔离与外部验证处理，不能只改绑定地址就宣告安全。
二、先把实际运行配置查清楚
Compose 文件可能已经修改，运行中的容器却仍保留旧映射。核查应以运行状态为准：
docker version --format '{{.Server.Version}}'
docker ps --format 'table {{.Names}}\t{{.Ports}}'
docker port web
docker inspect web --format '{{json .HostConfig.PortBindings}}'
docker inspect web --format '{{json .NetworkSettings.Ports}}'
docker inspect web --format '{{.HostConfig.NetworkMode}}'
将 web 换成实际容器名。重点看 HostIp、HostPort 和网络模式：0.0.0.0 指 IPv4 所有接口，:: 涉及 IPv6，127.0.0.1 是 IPv4 回环地址。若看到的是具体内网地址，还要确认这个地址是否被负载均衡、路由或其他代理转发。
ss -lntp 可以辅助查看监听进程，但 Docker 的端口发布可能由 NAT 规则完成，不一定出现独立的监听套接字。仅凭 ss 没有 8080 的监听行，就认定端口未开放，容易漏判。
还应分清两个位置的 0.0.0.0：
- 容器里的应用监听
0.0.0.0:80，表示接受该容器网络命名空间中的各接口请求。 - 宿主机发布地址为
0.0.0.0:8080，表示宿主机 IPv4 各接口都可成为这个映射的入口。
将容器内应用改成只监听 127.0.0.1，经常会让 bridge 发布失效，因为转发请求到达的是容器网络接口。更稳妥的收敛位置通常是宿主机发布地址，或取消发布。
镜像的 EXPOSE 和 Compose 的 expose 都不等于将端口发布到宿主机；它们也不能代替同一容器网络内的访问控制。真正需要检查的配置包括 ports、-p、-P 以及网络模式。
三、ufw 已拒绝，为什么容器还能收到请求
Docker 会为 bridge 网络创建转发及 NAT 规则。官方文档明确提示 Docker 与 ufw 的交互存在问题：发布端口的流量可能在进入 ufw 使用的 INPUT、OUTPUT 链之前就被转走。[2]
因此，ufw status 中的一条拒绝规则不能单独证明容器端口已被封闭。排查时可以只读查看实际规则；以下命令需要相应权限，应按机器安装的工具选择：
sudo iptables -S DOCKER-USER
sudo iptables -t nat -S DOCKER
sudo nft list ruleset
规则输出可能包含内网地址和网络结构，分享日志时请脱敏。命令不存在或链不存在，也不能单独判定 Docker 没有防火墙规则，需要结合 Docker 配置确认其后端。
使用 Docker 的 iptables 后端时，官方提供 DOCKER-USER 链，让管理员在 Docker 自身的转发放行规则之前插入策略。流量到达该链时通常已经做过 DNAT，此时匹配到的目标地址、端口可能是容器地址和容器端口；需要匹配原始宿主机端口时，还涉及 conntrack。[3]
这也是不宜直接复制“封掉所有 FORWARD”命令的原因。它可能同时中断容器间访问、数据库连接或其他服务。需要保留的来源、接口、已建立连接和 IPv6 流量，应一并纳入规则设计，并提前准备回滚方式。
Docker 原生 nftables 后端则没有 DOCKER-USER 链，需要通过独立表、base chain 和合适的优先级组织策略。[4] 官方文档目前将 Docker 29.0.0 引入的 nftables 支持标为实验性。系统显示 iptables-nft，也不等于 Docker 已启用原生 nftables 后端；两者不能混为一谈。
不要为解决一个暴露端口而清空整套规则，或直接关闭 Docker 管理 iptables、ip6tables 的能力。这可能破坏容器网络，也可能移除原本有效的隔离。
四、服务只给本机 Nginx 用：限定回环发布
假设 Nginx 运行在宿主机，业务容器内部监听 80，可将原有 Compose 服务中的端口改成：
services:
app:
# 保留项目原有的 image、volumes、environment 等配置
ports:
- "127.0.0.1:8080:80"
以上是配置片段，需要合入原文件，不是可独立运行的完整项目。宿主机 Nginx 的上游可以继续指向 http://127.0.0.1:8080。
修改前备份 Compose 文件与关联配置，确认数据位于持久化卷。随后在正确的项目目录中检查并应用：
docker compose config --quiet
docker compose up -d app
docker compose port app 80
config --quiet 用于校验配置；若运行完整的 docker compose config 并转发输出，要留意其中可能展开的凭据。端口映射变更通常需要重建容器，单纯执行 restart 不会应用新的映射。up -d app 可能造成短暂中断，应安排维护窗口；这里也没有理由执行会删除数据卷的 down -v。
应用后同时验证本机上游和网站域名，避免出现“公网入口封住了，正常代理也断了”。回滚时恢复备份的映射配置，再对该服务执行 up -d，并重新核对运行状态。
五、代理本身也在容器里：可以不发布业务端口
如果 Nginx 与应用都是容器，可让它们加入同一个用户自定义网络，由 Nginx 通过服务名访问应用，例如 http://app:80。业务服务的 ports 可以移除，只保留反向代理对外需要的 80、443 等入口。
容器里的 127.0.0.1 指向该容器自己。把宿主机代理方案原样搬进 Nginx 容器，再继续连接 127.0.0.1:8080，通常无法访问另一个容器。
数据库、缓存、管理界面也应逐项确认是否有宿主机发布需求。只供内部服务访问的端口，取消发布通常比维护一套额外公网白名单更容易核对。但同一网络里的容器仍可能互相访问，需要隔离不同信任域的服务时，应继续拆分网络、配置认证或实施网络策略。
上述收敛建议还存在一个适用边界：管理员如果开启了容器地址的 direct routing、trusted host interfaces，或采用 routed 等 gateway 模式，外部主机可能经路由直接访问容器 IP。[1] 限定宿主机回环发布不能代替对这些路径的检查。发现自定义网络配置时，要核查路由和容器地址，而不只盯着宿主机 8080。
六、从外部验证，不用本机测试代替公网结论
配置改完后，应从自己控制的另一台外部主机，对已授权的目标 IP 与单个端口进行验证。以 HTTP 服务为例：
# 本机：确认宿主机反向代理所需的上游仍然可用
curl --noproxy '*' -I --connect-timeout 5 http://127.0.0.1:8080/
# 外部主机：替换为自己的公网 IPv4 地址
curl --noproxy '*' -I --connect-timeout 5 http://YOUR_PUBLIC_IPV4:8080/
# 有公网 IPv6 时，替换下方地址并单独验证
curl --noproxy '*' -g -6 -I --connect-timeout 5 'http://[YOUR_PUBLIC_IPV6]:8080/'
示例使用 HEAD 请求，不需要提交账号或调用写入接口。如果服务不支持 HEAD，返回 405 仍说明 HTTP 服务已能被外部触达；401、403 也属于“网络可达但应用拒绝”。它们都不等于端口已关闭。非 HTTP 服务应使用对应的只读连接检查方式。
超时也有多种原因：云安全组、宿主机规则、路由或服务本身都可能导致超时。应结合 Docker 映射和预期调用方的成功访问来判断，避免把服务故障当作隔离成功。
云安全组仍是重要的一层。Docker 在宿主机设置转发规则，不代表它能绕过云平台安全组。若公网意外可达，要复查实际生效的安全组、IPv4/IPv6 来源范围、负载均衡和其他入口，确认请求到底经过了哪条路径。
留下一份能复查的端口清单
最终应能回答每个发布端口的用途：谁需要访问、绑定哪个地址、由哪层规则限制、IPv6 是否同样受控。只给本机代理使用的业务端口不必承担额外的公网入口；容器间内部调用也不必默认发布到宿主机。
变更记录中保留修改前后的映射、Docker 版本、网络模式和外部验证结果。下次更新 Compose 或新增服务时，对照这份清单，比只确认“网页还能打开”更容易发现暴露范围扩大。
参考资料
资料核验日期：2026 年 11 月 6 日。本文依据 Docker 官方文档源码核对配置行为，未将示例描述为生产环境实测。