Docker 容器明明使用了 -p 8080:80，宿主机却无法通过 8080 端口访问，这类问题往往不在应用本身，而在端口监听、网络转发或 iptables 规则链。Docker 在 Linux 上会利用 NAT、端口转换和相关防火墙规则实现端口发布，因此排查时不能只看容器是否处于 Up 状态。下面按流量路径逐层定位，帮助你快速找到故障点。🔍
一、先确认端口映射是否真实存在
首先执行 docker ps，检查 PORTS 一栏是否出现类似 0.0.0.0:8080->80/tcp 的内容。如果只看到 80/tcp，通常表示镜像声明了端口，但创建容器时没有执行端口发布。
还可以执行 docker inspect 容器名，重点查看 NetworkSettings.Ports。若对应容器端口的 HostPort 为空，应删除并重新创建容器，例如使用 docker run -d -p 8080:80 镜像名。需要注意，端口映射是在容器创建阶段确定的，直接重启原容器不会补上缺失的映射。Docker 对端口发布方式的说明可参考 官方端口映射文档。
二、检查容器内服务监听地址
端口映射存在，不代表容器内应用一定能够接收连接。进入容器执行 ss -lntp，或使用镜像内可用的同类命令，确认目标服务是否监听在正确端口。
- 监听 0.0.0.0:80：通常可以接收来自容器网络接口的请求。
- 只监听 127.0.0.1:80：服务仅接受容器内部回环流量，宿主机转发过来的数据无法到达应用。
- 未出现目标端口：应先检查应用配置、启动日志和进程状态。
可以在容器内部访问 127.0.0.1:80，再从宿主机访问容器 IP 对应端口。前者成功而后者失败时，应优先将应用监听地址调整为 0.0.0.0。🧭
三、核对宿主机监听与端口占用
执行 ss -lntp | grep 8080 检查宿主机端口状态，同时使用 docker port 容器名确认 Docker 记录的映射。如果宿主机已有其他程序占用该端口，容器创建时通常会出现绑定失败提示，此时应更换宿主机端口或停止冲突服务。
若命令显示端口绑定在 127.0.0.1:8080，远程设备无法直接访问属于预期现象。映射为 0.0.0.0:8080 通常会对宿主机所有 IPv4 接口开放，因此还要同步评估安全组和防火墙策略，避免将数据库、管理后台等敏感服务直接暴露到公网。⚠️
四、检查 NAT 表中的 DOCKER 规则
Docker 的 bridge 网络通常会在 nat 表创建 DOCKER 链，并通过 DNAT 将宿主机端口转换为容器地址。可执行以下检查：
iptables -t nat -L DOCKER -n -v --line-numbers
iptables -t nat -S DOCKER
iptables -t nat -L PREROUTING -n -v
正常情况下，应能找到宿主机 8080 端口转发至某个容器 IP 和 80 端口的规则。若 DOCKER 链不存在、跳转规则缺失，或映射规则中的容器 IP 已经过期，说明 Docker 自动维护的防火墙规则可能被清空或覆盖。
不要急于手工添加永久 DNAT 规则。容器重建后 IP 可能变化，手工规则容易留下失效配置。更稳妥的做法是先保存现场，再重启 Docker 服务，让 Docker 根据当前容器和网络配置重新生成规则。
五、检查 FORWARD 与 DOCKER-USER 链
NAT 转换成功后，数据包仍需通过 filter 表。执行 iptables -L FORWARD -n -v --line-numbers 和 iptables -L DOCKER-USER -n -v --line-numbers，观察是否存在优先命中的 DROP 或 REJECT 规则。
Docker 会让相关转发流量进入自定义规则链，而管理员自行添加的限制规则通常应放在 DOCKER-USER 链。若该链顶部存在无条件丢弃规则，后面的放行配置就不会生效。排查时应结合规则顺序和计数器增长判断，而不是只搜索是否存在 ACCEPT。相关链路与处理顺序可参考 Docker 与 iptables 官方说明。
六、确认 IP 转发功能与内核参数
执行 sysctl net.ipv4.ip_forward，正常转发场景一般应返回 net.ipv4.ip_forward = 1。如果值为 0，可临时执行 sysctl -w net.ipv4.ip_forward=1 验证；确认问题后，再将配置写入系统的 sysctl 配置文件并加载。
同时检查 Docker 守护进程配置中是否设置了 "iptables": false。该选项会阻止 Docker 自动创建大部分端口映射所需规则，官方并不建议在常规环境中关闭这一能力，因为它可能直接破坏 bridge 网络的端口发布功能。
七、排除 firewalld、ufw 与 nftables 干扰
许多发行版同时启用了 firewalld、ufw 或 nftables 后端。此时使用 iptables 看到的规则，可能只是兼容层展示的结果。可执行 iptables --version 判断当前使用 legacy 还是 nf_tables 后端，并通过 nft list ruleset 查看真实规则集。
若问题出现在重载防火墙之后，应重点检查 Docker 规则是否被刷新。可以先导出 iptables-save 和 nft list ruleset 的结果，再重启 Docker，比较前后差异。不要在生产环境直接清空全部规则，否则可能中断远程连接、容器通信及其他业务。🛡️
八、通过抓包确定数据丢失位置
当规则表面正常时，抓包是最直接的定位方法。先在宿主机外网接口执行 tcpdump -ni any tcp port 8080，再从客户端发起请求。
- 完全看不到请求包：检查云安全组、上游防火墙、路由或客户端网络。
- 宿主机收到请求，但没有转发至容器地址：重点排查 nat 表、FORWARD 链及 IP 转发。
- 请求进入容器但没有响应：检查应用监听、容器内防火墙和服务日志。
- 能看到响应离开容器，却未返回客户端：检查连接跟踪、返回路由和 SNAT/MASQUERADE 规则。
必要时可查看 conntrack 状态，但在高并发主机上应谨慎使用范围过大的查询，避免给系统增加额外压力。
九、推荐的安全恢复顺序
实际处理时，建议按照“应用监听 → Docker 映射 → NAT 规则 → FORWARD 规则 → 主机防火墙 → 上游网络”的顺序执行。先记录 docker inspect、iptables-save、nft list ruleset 和系统日志，再尝试重启单个容器；仍未恢复时，再评估重启 Docker 服务。
切勿把 iptables -F 当作通用修复命令。它可能暂时让端口恢复，也可能删除安全策略并扩大服务暴露范围。若必须修改规则，应明确表、链、协议、源地址和目标端口，并准备可回滚的规则备份。
总结
Docker 端口映射失效，本质上是数据包在“宿主机入口、DNAT、转发过滤、容器网络、应用监听”中的某一环被阻断。排查重点不是反复重启，而是逐段验证：映射是否存在、服务是否监听、DOCKER 链是否完整、DOCKER-USER 是否提前丢包、IP 转发是否开启，以及 firewalld 或 nftables 是否覆盖规则。按流量路径检查并结合计数器与抓包结果，通常可以快速定位问题，同时避免粗暴清空防火墙带来的安全风险。✅
