docker stats看到容器CPU和内存都正常，但服务就是不可用，端口映射和网络模式该从哪查起？

目录

一、导语：一个被指标"欺骗"的典型场景

凌晨两点，值班工程师打开终端，docker stats 的输出一切正常：CPU 占用 0.3%，内存 128MiB / 512MiB，网络 I/O 还在缓慢增长。但上游调用方持续报 502，健康检查接口超时。重启容器，指标依旧"健康"，服务依旧不可达。这类故障在现场极为常见，而它的迷惑性恰恰来自一个认知错位——把资源指标当成了可用性指标。

资源指标回答的是"容器消耗了多少"，可用性回答的是"外部请求能否抵达并得到正确响应"。二者之间隔着命名空间隔离、iptables 规则链、用户态代理、内核连接跟踪、应用层监听地址等至少五道关卡。任何一道出问题，docker stats 都不会有任何异常表现，因为它的数据源是 cgroup 的记账文件，与网络数据面无关。

本文的主线由此确立：先证伪指标的可信范围，再沿数据通路逐跳验证。这条主线贯穿全文——从 docker stats 的测量边界出发，经端口映射的 DNAT 与代理双路径，到四种网络模式的语义差异，最终落到一套可复现的七步排查法与工程化的网络契约验证。笔者认为，容器排障的核心能力不是记住更多命令，而是建立"观测面"与"数据面"的映射关系，知道每个工具究竟能看到哪一层、看不到哪一层。

二、背景与问题定义：docker stats 到底测了什么

2.1 数据来源：cgroup 记账而非网络探针

在 Linux 上，Docker 守护进程通过读取 cgroup 控制器暴露的记账文件获取容器资源用量。以 cgroup v2 为例，CPU 用量来自 cpu.stat 中的 usage_usec 累计值，内存来自 memory.current 与 memory.stat，网络来自容器网络命名空间内的 /proc/net/dev。这些数据有一个共同特征：它们描述的是"已经发生的流量与消耗"，而不是"连接是否可达"。

更关键的是，网络 I/O 计数统计的是容器 veth 接口上的收发字节数。如果请求根本没到达容器（例如 DNAT 规则缺失、目标端口未监听、安全组拦截），这个计数自然为零或极低；如果请求到达但应用返回 500，计数反而会正常增长。也就是说，网络 I/O 指标既不能证明可达，也不能证明不可达，它只是一个流量体积的度量。

本文评述：把 docker stats 当作"健康检查"是一种典型的概念偷换。它更接近汽车仪表盘上的油量表——告诉你还剩多少资源，但完全不知道轮胎是否漏气。工程上应当把资源指标与可用性指标严格分层，前者用于容量规划与限流，后者必须依赖主动探测（TCP 握手、HTTP 探针、DNS 解析链验证）。

2.2 观测盲区的形式化描述

设一次外部请求从客户端到容器进程需要经过若干跳，可抽象为：客户端 → 宿主机网卡 → 主机路由/防火墙 → 端口映射层（DNAT 或用户态代理）→ 容器网络命名空间 → 容器内网卡 → 应用监听套接字。docker stats 只观测到"容器内网卡"这一跳的字节计数，其余各跳的状态对它完全不可见。

因此，当服务不可用时，可能的失效点至少有六类：宿主机防火墙（firewalld/ufw/nftables）拦截、iptables NAT 链规则缺失或被覆盖、docker-proxy 进程异常、容器内应用监听在 127.0.0.1 而非 0.0.0.0、容器网络命名空间路由错误、应用层自身拒绝连接（如连接池耗尽、TLS 握手失败）。这六类失效在 docker stats 上的表现完全一致——都是"看起来正常"。

三、原理层：端口映射的完整数据通路

3.1 DNAT 路径：内核态的默认选择

执行 docker run -p 8080:80 时，Docker 守护进程会在宿主机 netfilter 的 nat 表中创建规则。核心逻辑位于 DOCKER 自定义链，由 PREROUTING 与 OUTPUT 链跳转进入。当数据包命中 -p tcp --dport 8080 -j DNAT --to-destination 172.17.0.2:80 时，目的地址被改写为容器 IP，随后经 FORWARD 链转发至容器 veth。

这条路径完全在内核态完成，性能开销小，是 Linux 上的默认行为。但它有一个隐含前提：宿主机必须开启 IP 转发，且 FORWARD 链策略不能为 DROP。很多发行版默认 net.ipv4.ip_forward=0，或 firewalld 将 FORWARD 默认策略设为 DROP，此时 DNAT 规则存在但数据包在转发阶段被丢弃，表现为"端口能连上（SYN 到达）但无响应"或直接超时。

# 验证 IP 转发是否开启
sysctl net.ipv4.ip_forward
# 查看 DOCKER 链的 DNAT 规则
iptables -t nat -L DOCKER -n -v --line-numbers
# 查看 FORWARD 链策略与命中计数
iptables -L FORWARD -n -v --line-numbers

3.2 docker-proxy 路径：用户态的兜底

当宿主机无法使用 DNAT（例如开启 userland-proxy=true，这是 Docker 的默认配置之一），或访问来源是本机回环地址时，Docker 会启动 docker-proxy 进程监听宿主机端口，由用户态程序接受连接后再转发到容器 IP。这条路径的失效模式与 DNAT 截然不同：

• docker-proxy 进程崩溃或被 OOM Killer 杀死，端口监听消失，表现为 connection refused；
• docker-proxy 与 DNAT 规则同时存在时，回环访问走代理、外部访问走 DNAT，两条路径行为不一致，容易造成"本机 curl 通、外部不通"的诡异现象；
• 高并发下用户态代理成为瓶颈，连接排队导致超时，而容器内 CPU 依旧很低。

本文评述：docker-proxy 的存在是历史兼容性的产物，它为不支持 DNAT 的场景提供了兜底，但也引入了"双路径不一致"这一经典陷阱。笔者建议在生产环境显式设置 "userland-proxy": false，统一走内核 DNAT，既降低开销，也消除路径歧义。代价是失去对回环地址的自动转发，需要额外处理。

3.3 conntrack：被忽视的容量边界

DNAT 依赖内核连接跟踪（conntrack）维护会话状态。每个经过 NAT 的连接都会在 conntrack 表中占用一条表项，表项有超时时间（TCP established 默认 5 天，可调）。当表满时，新连接会被直接丢弃，内核日志出现 nf_conntrack: table full, dropping packet。此时容器资源指标毫无异常，但所有新连接都失败——这是高并发场景下"指标正常但服务不可用"的典型成因之一。

根据 Linux 内核文档，conntrack 表大小由 net.netfilter.nf_conntrack_max 控制，默认值随内存规模变化。工程上应结合连接速率与超时时间估算所需容量，并通过 nf_conntrack_count 监控使用率。关于容器网络性能与 conntrack 压力的系统性讨论，可参考 Kubernetes 网络特别兴趣小组的公开文档与 CNCF 博客中的相关实践总结。

四、网络模式语义与失效模式对照

4.1 四种模式的本质差异

Docker 提供 bridge、host、none、container 四种内置网络模式，其差异本质上是"容器进程看到哪个网络命名空间"。bridge 模式为容器创建独立命名空间并接入 docker0 网桥；host 模式直接复用宿主机命名空间；none 模式只创建回环；container 模式共享另一容器的命名空间。理解这一点，才能理解为什么某些模式下 -p 参数会被忽略或行为异常。

4.2 host 模式的隐性陷阱

host 模式下容器直接使用宿主机网络栈，-p 参数被完全忽略，Docker 不会报错也不会警告。如果应用配置里写死了监听 127.0.0.1:8080，在 bridge 模式下可能因为 docker-proxy 的回环转发而"碰巧可用"，切换到 host 模式后反而外部不可达。这类问题在迁移环境时极易出现，且因为 docker stats 一切正常而难以定位。

笔者认为，host 模式的最大风险不是性能问题，而是"配置语义漂移"——同一份应用配置在不同网络模式下含义不同。工程上应当在镜像层面强制应用监听 0.0.0.0，并通过启动探针验证实际监听地址，而不是依赖部署时的模式假设。

4.3 自定义 bridge 与 DNS 解析链

使用自定义 bridge 网络时，Docker 内置 DNS 服务器（监听 127.0.0.11）为容器提供基于容器名的解析。若容器加入多个网络，或 DNS 配置被 --dns 参数覆盖，解析链可能指向错误地址。此时服务进程本身健康、端口监听正常，但调用方通过服务名解析到旧 IP 或不可达 IP，表现为间歇性超时。这类问题的排查必须跳出单容器视角，进入 DNS 与网络拓扑层面。

关于容器 DNS 解析与网络命名空间的深入讨论，可参考 Docker 官方网络教程（docs.docker.com/network）以及 Linux 内核网络文档中关于 network namespace 的章节。视频类资料可参考 Docker 官方 YouTube 频道的网络专题讲解。

五、可操作排查路径：从外到内的七步法

排查顺序应遵循"由外向内、由粗到细"的原则，每一跳都用最小成本的命令验证，避免一开始就进入容器内部盲目翻日志。以下七步构成一条可复现的路径，每一步都给出判定标准与常见异常。

第一步：确认宿主机端口是否处于监听状态

ss -lntp | grep 8080
# 期望看到 docker-proxy 或应用进程监听 0.0.0.0:8080
# 若只有 127.0.0.1:8080，说明绑定地址错误

判定标准：监听地址必须是 0.0.0.0 或 ::。若监听进程不存在，说明端口映射未创建，应检查 docker inspect 中的 NetworkSettings.Ports 字段是否为空。

第二步：验证 DNAT 规则是否存在且命中

iptables -t nat -L DOCKER -n -v
# 关注 pkts 计数：若长期为 0，说明流量未命中该规则
# 检查规则中的目标 IP 是否与容器当前 IP 一致
docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' 容器名

常见异常：容器重启后 IP 变化，但旧规则未清理，导致 DNAT 指向已失效地址。此时规则存在、计数增长，但数据包被转发到不存在的目标，表现为超时。解决方法是重建容器网络或重启 Docker 守护进程触发规则刷新。

第三步：检查 FORWARD 链与防火墙策略

iptables -L FORWARD -n -v --line-numbers
# 若策略为 DROP 且无放行 docker0 的规则，转发会被丢弃
# firewalld 环境下检查：
firewall-cmd --get-active-zones
firewall-cmd --zone=public --list-all

判定标准：FORWARD 链必须存在允许 docker0 或对应网桥的规则。若使用 nftables 后端，需检查 nft list ruleset 中的 forward 链。这是"本机 curl 通、外部不通"最常见的原因。

第四步：从宿主机直接访问容器 IP

CONTAINER_IP=$(docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' 容器名)
curl -v --max-time 3 http://$CONTAINER_IP:80/healthz

这一步用于区分"映射层问题"与"容器内问题"。若直连容器 IP 成功，说明应用与容器网络正常，问题在端口映射或宿主机防火墙；若直连失败，问题在容器内部，进入第五步。

第五步：进入容器验证监听地址与进程状态

docker exec -it 容器名 sh
# 容器内执行
ss -lntp
# 若监听 127.0.0.1:80，外部必然不可达
# 检查进程是否存在、是否处于 D 状态
ps aux

监听地址错误是最高频的根因之一。很多框架默认绑定回环地址（如 Flask 默认 127.0.0.1，Node 某些模板默认 localhost），在容器内必须显式改为 0.0.0.0。此外，进程处于不可中断睡眠（D 状态）时，CPU 指标可能极低但服务无响应，需结合 /proc/<pid>/stack 进一步分析。

第六步：检查 conntrack 与内核日志

cat /proc/sys/net/netfilter/nf_conntrack_count
cat /proc/sys/net/netfilter/nf_conntrack_max
dmesg | grep -i conntrack | tail -20

若 count 接近 max，说明连接跟踪表接近饱和，新连接将被丢弃。此时应调大 nf_conntrack_max，并排查是否存在连接泄漏（如短连接未正确关闭、超时时间过长）。

第七步：抓包定位丢包点

# 宿主机外部网卡抓包
tcpdump -i eth0 -nn port 8080 -c 20
# 容器 veth 抓包
tcpdump -i vethXXXX -nn port 80 -c 20

对比两处抓包结果可精确定位丢包点：若 eth0 收到 SYN 但 veth 未收到，说明丢在 NAT/FORWARD 阶段；若 veth 收到 SYN 但无 SYN-ACK，说明应用未响应或回程路由异常。抓包是最终裁决手段，但应在前面几步缩小范围后使用，避免大海捞针。

本文评述：七步法的价值不在于步骤本身，而在于每一步都设置了"判定标准"与"分支出口"。工程排障最怕的是无分支的线性操作——执行了一堆命令却不知道结果意味着什么。笔者建议团队把这七步固化为脚本或 Runbook，让排障从"经验驱动"转向"流程驱动"。

六、关键案例与数据：三类高频误判的复盘

6.1 案例一：FORWARD 策略导致的静默丢弃

某团队在 CentOS 主机上部署容器，docker run -p 8080:80 后本机 curl 正常，外部访问超时。检查发现 firewalld 运行中，FORWARD 链默认策略为 DROP，且未放行 docker0 网桥。DNAT 规则存在且计数增长，但数据包在 FORWARD 阶段被丢弃。修复方式是将 docker0 加入 trusted 区域或显式添加放行规则。

这个案例的启示是："本机可达"不能证明"外部可达"。本机访问回环地址时走 OUTPUT 链，不经过 FORWARD，因此绕过了转发策略。排查时必须从外部视角验证。

6.2 案例二：应用绑定回环地址

某 Python 服务使用 Flask 默认配置启动，监听 127.0.0.1:5000。在 bridge 模式下，docker-proxy 监听宿主机端口并转发到容器 IP 的 5000 端口，但容器内应用只接受回环连接，导致转发失败。docker stats 显示 CPU 与内存正常，网络 I/O 为零。将启动参数改为 --host=0.0.0.0 后恢复。

笔者认为，这类问题应在镜像构建阶段通过健康检查暴露，而不是等到部署后才发现。健康检查应使用容器内视角访问 127.0.0.1 与容器 IP 两个地址，任一失败即判定为配置错误。

6.3 案例三：conntrack 表满引发的新连接丢弃

某高并发网关服务在流量高峰期出现间歇性不可用，容器资源指标正常。检查 nf_conntrack_count 发现已接近 nf_conntrack_max，dmesg 中有 table full 记录。根因是上游大量短连接未复用，且 TCP 超时时间设置过长，导致表项堆积。调整连接池与超时参数后恢复。

根据公开的内核文档与运维社区实践，conntrack 表满属于"资源耗尽型"故障，其特点是容器内指标完全正常，故障发生在宿主机内核层。这类故障提醒我们，容器排障不能只看容器，必须把宿主机内核状态纳入观测范围。

七、对比与局限：为什么"看指标"永远不够

资源指标与可用性指标属于两个不同的观测平面。前者是"消耗度量"，后者是"路径验证"。任何试图用消耗度量推断路径状态的做法，都存在逻辑跳跃。笔者认为，工程上应建立三层观测体系：第一层是资源层（cgroup 指标），用于容量与限流；第二层是路径层（端口监听、iptables 计数、conntrack 状态），用于验证数据通路；第三层是应用层（主动探针、链路追踪），用于验证业务语义。三层缺一不可。

当前主流容器可观测性方案（如 Prometheus + cAdvisor、eBPF 抓包工具）在资源层已经相当成熟，但在路径层的覆盖仍显不足。cAdvisor 能提供容器级网络计数，却无法回答"DNAT 规则是否命中"；eBPF 工具（如 Cilium 的 Hubble）能提供连接级可见性，但部署成本较高，且对传统 iptables 模式的覆盖有限。这一空白正是"指标正常但服务不可用"问题长期存在的原因。

本文评述：近年关于容器网络可观测性的研究多集中在 eBPF 与服务网格方向，强调"连接级追踪"替代"计数级监控"。这一趋势是合理的，但也带来新的复杂度。对于大量仍在使用传统 bridge + iptables 的存量系统，更现实的改进是把七步排查法固化为自动化检查，在部署后、变更后、告警时自动执行，形成"可验证的网络契约"。关于 eBPF 在容器网络观测中的应用，可参考 Cilium 官方文档（docs.cilium.io）与 eBPF 社区的技术文章。

八、结论与展望：从排障到可验证的网络契约

回到最初的问题：docker stats 看到 CPU 和内存正常，服务却不可用，该从哪查起？答案不是某一个命令，而是一条分析主线——先明确指标的可信范围，再沿数据通路逐跳验证。端口映射要查 DNAT 规则、FORWARD 策略、docker-proxy 进程与 conntrack 状态；网络模式要查命名空间语义、监听地址与 DNS 解析链。每一跳都有对应的验证手段与判定标准。

展望未来，笔者认为容器网络排障将沿着两个方向演进：一是观测下沉，eBPF 与内核 tracing 让路径层可见性成为默认能力；二是契约前置，把"端口可达、监听正确、规则命中"作为部署流水线的强制校验项，让问题在发布前暴露而非在生产中排查。无论技术如何演进，"区分观测面与数据面"这一基本认知不会过时。

九、主要参考文献