Docker NAT 机制依赖 iptables nat 表中 PREROUTING（DNAT）、DOCKER（集中匹配）和 POSTROUTING（SNAT/MASQUERADE）三链协同工作，端口映射与容器出向通信由此闭环实现。
要深度复核 Docker 在宿主机网络层自动配置的 NAT 地址转换逻辑，关键不是“看一眼规则”，而是沿着数据包实际流转路径，逐层验证每个 iptables 链在 nat 表中的作用点、匹配条件和跳转行为。Docker 的 NAT 机制不是黑箱，它由几条明确链协同完成：PREROUTING → DOCKER → POSTROUTING，而真正决定“谁被转换、怎么转换”的，是这些链里具体规则的源/目标地址、端口、接口和跳转目标。
聚焦 nat 表，定位核心链与执行顺序
Docker 的端口映射（如 docker run -p 8080:80）本质是 DNAT + SNAT 组合，全部发生在 nat 表中。必须只查 nat 表，filter 表里的规则不参与地址转换：
-
PREROUTING 链：处理刚抵达网卡的数据包。Docker 在此处插入规则，将发往宿主机 IP:端口的请求，目标地址改写为对应容器 IP:端口（DNAT）。例如：
DNAT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:8080 to:172.17.0.2:80 - DOCKER 链：这是 Docker 自建的自定义链，PREROUTING 中的跳转目标。它集中管理所有容器入向 DNAT 规则，按顺序匹配，一旦命中即执行 DNAT 并返回 PREROUTING 继续后续流程。
- POSTROUTING 链：处理即将离开宿主机的数据包。Docker 在此处添加 MASQUERADE 或 SNAT 规则，将容器发出、经 docker0 网桥转发出去的流量，源地址统一替换为宿主机出口 IP（SNAT），确保外部能回包。
用 iptables 命令逐级抓取真实规则快照
运行以下命令获取当前生效的完整 nat 表视图，重点关注带注释（/* */）的规则，它们是 Docker 自动生成的标记：
iptables -t nat -L -n -v --line-numbers
输出中重点识别：
- PREROUTING 链中指向
DOCKER链的跳转规则（通常第一行或第二行） - DOCKER 链内每条 DNAT 规则的
to:目标是否与docker inspect <container>查到的 IPAddress 一致 - POSTROUTING 链中针对 docker0 网桥子网（如
172.17.0.0/16）的 MASQUERADE 规则，确认其out接口是实际对外网卡（如 eth0），而非 docker0
模拟数据包路径，验证 DNAT/SNAT 是否闭环
仅看规则不够，需验证实际转换效果。可借助 tcpdump 和连接测试交叉印证：
- 在宿主机上监听 docker0 接口：
tcpdump -i docker0 port 80，然后从外部访问http://宿主机IP:8080。若能看到目的 IP 已变为容器 IP（如172.17.0.2），说明 PREROUTING → DOCKER 的 DNAT 生效 - 在容器内访问外部服务（如 curl http://httpbin.org/ip），同时在宿主机监听 eth0：
tcpdump -i eth0 src host 172.17.0.2。若抓到的包源 IP 是宿主机公网 IP，而非容器 IP，说明 POSTROUTING 的 SNAT/MASQUERADE 正常工作
检查 DOCKER-USER 链是否干扰了默认 NAT 流程
DOCKER-USER 链位于 PREROUTING 末尾、DOCKER 链之前，用户在此添加的规则会先于 Docker 自动规则执行。如果误加了 DROP 或 RETURN，会导致端口映射失效：
- 运行
iptables -t nat -L DOCKER-USER -n，确认该链为空或仅有明确意图的 ACCEPT/DNAT 规则 - 若存在
RETURN或DROP且无匹配条件限制，极可能拦截本该进入 DOCKER 链的端口映射流量 - 生产环境建议：DOCKER-USER 链只用于白名单式放行（如
-A DOCKER-USER -s 192.168.1.0/24 -j ACCEPT），避免无条件 RETURN
