在日常运维中，Docker 容器明明已经通过 -p 8080:80 发布端口，却出现宿主机无法访问、外部请求超时，甚至重启 Docker 后恢复、重启防火墙后再次失效的情况。这类问题通常不只与应用有关，还可能涉及端口绑定、容器网络、IP 转发、iptables 链路以及 firewalld、UFW 等防火墙工具。本文提供一套由内到外的排查流程，帮助快速定位故障。🔍
一、先确认端口映射是否真正生效
执行 docker ps，检查 PORTS 列是否存在类似 0.0.0.0:8080->80/tcp 的记录。如果只看到 80/tcp，说明镜像声明了端口，但运行容器时没有发布到宿主机。此时需要重新创建容器，例如使用 docker run -p 8080:80 镜像名。
还要留意绑定地址。127.0.0.1:8080->80/tcp 表示该端口原则上仅供宿主机本地访问；若希望通过宿主机网卡地址提供服务，应根据安全要求绑定指定网卡 IP，或使用默认的 0.0.0.0。Docker 的端口发布机制会利用防火墙规则完成 NAT、端口转换和地址伪装，具体行为可参考 Docker 端口发布文档。
二、确认容器内服务正在正确监听
端口发布成功不代表容器内应用一定可用。进入容器执行 ss -lntp、netstat -lntp 或直接请求 127.0.0.1:容器端口，确认服务已经启动。若容器镜像没有相关命令，也可以通过应用日志、健康检查或临时调试容器进行验证。
常见误区是应用只监听容器内的 127.0.0.1。此时请求通过容器网卡进入，却无法连接本地回环地址上的服务。应用通常应监听 0.0.0.0 或容器网卡地址。同时检查协议是否一致，例如发布的是 TCP 端口，但程序实际提供 UDP 服务。⚠️
三、按照访问路径逐层测试
- 在容器内访问应用端口，判断程序自身是否正常。
- 在宿主机访问容器 IP 和容器端口，判断 Docker 网桥通信是否正常。
- 在宿主机访问发布端口，判断 DNAT 与端口映射是否生效。
- 从同网段或外部主机访问，判断主机防火墙、云安全组和上游网络是否放行。
获取容器地址可使用 docker inspect 容器名。如果容器内访问成功，但宿主机连接容器 IP 失败，应重点检查网桥、路由和 FORWARD 链；如果宿主机访问发布端口成功，而外部访问失败，则更可能是防火墙、安全组、路由器端口转发或运营环境的访问控制问题。
四、检查 Docker 生成的 iptables 规则
Docker 在 Linux 的 bridge 网络中通常会创建自定义链，并在 nat 表的 DOCKER 链中维护端口映射规则。可以依次查看 iptables -t nat -L DOCKER -n -v、iptables -L FORWARD -n -v 和 iptables -L DOCKER-USER -n -v。正常情况下，已发布端口应存在对应的 DNAT 规则，数据包计数也会随着访问增加。
如果 DOCKER 链不存在、映射规则缺失，或 FORWARD 链没有跳转到 Docker 相关链，可能是 Docker 未能成功写入规则，也可能是其他防火墙服务刷新了规则集。Docker 官方说明，bridge 网络依赖这些规则实现端口发布和网络隔离，不建议直接修改 Docker 自动生成的链，详见 Docker 与 iptables 官方说明。
重点关注 DOCKER-USER 链
管理员自定义的容器访问控制应优先放入 DOCKER-USER 链，因为该链会在 Docker 的主要转发规则之前处理。若链中存在范围过大的 DROP 或 REJECT 规则，端口映射看似正常，流量却会被提前丢弃。检查时不仅要看规则内容，还要看顺序和计数器，避免允许规则排在拒绝规则之后。
五、排查 IP 转发和内核参数
执行 sysctl net.ipv4.ip_forward，确认结果为 1。Docker 默认 bridge 网络需要主机具备 IP 转发能力；如果系统加固脚本、内核参数配置或安全基线将其关闭，容器转发链路可能中断。临时调整后，还应同步修改对应的 sysctl 配置文件，防止重启后失效。
同时检查 FORWARD 链的默认策略。默认策略为 DROP 并不必然导致故障，因为 Docker 会添加允许规则；真正需要确认的是相关跳转是否存在，以及数据包是否在到达 Docker 链之前被其他规则拒绝。可结合规则计数、系统日志和抓包结果判断实际丢包位置。
六、处理 firewalld、UFW 与 nftables 冲突
部分系统使用 firewalld 动态维护规则，重新加载防火墙时可能改变 Docker 的链和转发关系。UFW 的常规 INPUT 规则也不一定覆盖经过 Docker 转发的流量，因此不能只凭“UFW 已放行端口”判断配置正确。建议确认 Docker 与防火墙服务的启动顺序，并检查重载前后的规则差异。
现代发行版还可能使用 iptables-nft 后端。如果系统同时混用 iptables-legacy、iptables-nft 和原生 nftables，管理员看到的规则集可能并不是实际生效的规则集。可检查 iptables --version，并通过 nft list ruleset 交叉验证。不要在不清楚后端关系的情况下反复切换实现，否则容易产生重复规则或持久化配置失配。🧩
七、通过抓包定位流量消失的位置
当规则表面正常时，抓包通常最有效。先在宿主机外部网卡监听目标宿主端口，再在 docker0 或对应自定义网桥上监听容器端口。如果外部网卡收不到请求，应检查上游网络；如果外部网卡有请求而 Docker 网桥没有，问题集中在 NAT 或过滤规则；如果请求已经到达容器但没有响应，则应回到应用监听、容器路由和响应路径继续排查。
排障原则：先证明应用可用，再确认容器网络，随后检查宿主机端口，最后检查外部链路。不要一开始就清空全部 iptables 规则，因为这可能扩大故障范围并暴露原本受保护的服务。
总结
Docker 端口映射失效通常可以归纳为四类原因：容器内服务未正确监听、端口发布参数错误、Docker 自动规则缺失，以及主机防火墙或上游策略拦截。实际处理时，应按照“容器应用—容器网桥—宿主机 NAT—FORWARD 与 DOCKER-USER—外部网络”的顺序逐层验证，并通过规则计数和抓包确认数据包停在哪一层。修复后还要测试 Docker 重启、主机重启和防火墙重载场景，确保规则能够持续生效。✅
