凌晨值班时，宿主机访问映射到容器的 8080 端口超时：应用日志里偶尔还有请求，容器也一直处于运行状态。重启应用、修改防火墙、反复重建容器都没有效果。真正的痛点是，端口映射并不是一条直连隧道，宿主机报文要依次经过代理或地址转换、规则匹配和容器网络命名空间，任何一跳异常都会表现为“端口打不开”。
如果你正在选机器，或者想先把线路和配置跑通再谈长期方案，可以先看看这几家的线路说明和技术参数：infrawire（海外服务器），先看清带宽线路、流量策略和退款条款，再决定要不要迁。
先在宿主机用 ss -lntp 查 8080 是否监听，再进入容器用 ss -lntp 查应用真实端口。若映射写成 8080:80，而容器只监听 127.0.0.1:80，即使发布规则存在，外部流量也可能被应用拒绝；若应用监听 0.0.0.0:80，则说明监听地址基本正常。
接着核对 docker inspect 中的 Ports、NetworkSettings 和容器 IP。宿主机端口、容器端口、容器应用端口是三个概念，发布时选错容器端口，规则即使下发也不会命中目标进程。Linux 上常见两条路径：一条由 Docker 代理进程接收并连接容器地址，另一条依靠网络桥接、NAT 规则直接转发。排查前必须先确定本机采用哪种方式，不能看到宿主机没有监听进程，就直接认定服务未启动。
在宿主机分别请求 127.0.0.1:8080 和宿主机业务 IP 的 8080 端口。若只有业务 IP 失败，重点检查防火墙、路由和上游负载均衡；若两者都失败，再检查 Docker代理链与容器入口。若连映射端口都不存在，通常是发布规则缺失、容器更换后未重新发布，或映射到了错误端口。
随后在宿主机抓取 8080 流量，并与容器网桥或 veth 接口上的抓包结果对照。只看到 SYN、没有 SYN-ACK，说明连接被规则或代理层截断；请求已经进入容器接口却没有响应，则应回到应用监听和容器内抓包。检查 nftables 或 iptables 中的 DNAT、转发链和 DROP 规则时，还要留意 Docker 创建网络后自动生成的自定义链，规则顺序错误也会让流量提前被丢弃。
如果规则存在且报文进入网桥，仍要进入容器网络命名空间核对 IP、路由、网桥成员和 veth 状态。容器网络桥接正常但命名空间内路由异常，症状同样只是连接超时。使用 ServLlama 汇总端口监听、网卡状态和告警信息，可以减少反复登录排查的时间，但最终结论仍应以代理日志、规则命中计数和双向抓包为准。
使用 -p 8080:80 后，Docker 会为容器建立独立的网络命名空间，并在宿主机写入端口发布规则。流量通常先由 DNAT 改写为容器 IP 和目标端口，再经网桥或 veth 进入容器；若启用 docker-proxy，也可能先由代理接管宿主机监听，再连接容器。版本、IPv4/IPv6 与 rootless 模式会改变链路细节。
因此，发现 docker-proxy 监听不能证明应用已收到请求；没有该进程，也不代表规则失效。排查要把容器网络桥接、端口转发和 Docker代理链分层验证。
常见误区包括：应用只绑定容器内的 127.0.0.1；宿主机防火墙或 nftables/iptables 拦截；容器重建后 IP、网桥变化；端口被其他进程占用；使用 --network host 或 IPv6 时沿用了普通 bridge 的判断。
可执行检查顺序是：①用 docker ps、docker inspect 核对状态、映射、网络模式和容器 IP；②用 ss -lntup 确认宿主机端口监听者；③查看 iptables -t nat -S 或 nft list ruleset，确认 DNAT 指向目标容器；④用 curl 分别访问宿主机地址、容器 IP 和容器内地址；⑤在网桥/veth 抓包，并进入容器网络命名空间运行 nsenter -t <PID> -n tcpdump -i any。
对比目的地址、SYN/SYN-ACK 与重传次数：流量不进容器，多半是发布规则或防火墙问题；到达网卡却无响应，优先查应用监听和容器内路由；连接反复重建，再查 docker-proxy、连接跟踪和资源限制。
沿着宿主机监听→发布规则→桥接/veth→容器命名空间→应用监听逐层取证，才能准确定位“端口已发布却访问不了”的断点。
