Docker/Kubernetes集群连接超时：conntrack表满排查实录

某个工作日的下午，某业务集群的服务可用率监控曲线突然开始抖动。告警里报的是 A 服务调用 B 服务时出现大量连接超时，应用日志里刷出一屏又一屏curl 56 recv failure: 连接超时。当时第一反应是服务出问题了，可登录节点一看，Docker 容器和 Kubernetes Pod 全都活得好好的，CPU、内存、磁盘水位正常，重启次数为零。这个场景相信不少维护容器集群的人都遇到过：服务明明活着，但新连接就是建立不起来，而且失败是间歇性的，让人完全摸不着头脑。

这篇内容主要面向正在维护 Docker/Kubernetes 混合集群、被“时好时坏的网络超时”折磨过的人。我会按当时实际排查的顺序，把从应用层一路打到内核层的完整过程写出来，包括几个容易误判的方向、最后锁定的根因，以及顺带排掉的另一个经典网络坑。如果你手头正好有类似的偶发超时问题，照着这个链路走一遍，大概率能少熬几个通宵。

1. 故障表象：服务活着，新连接却在排队超时

1.1 指标都正常，但失败率就是高

接到告警后，我做的第一件事不是去抓包，而是先确认服务到底有没有挂。因为大多数时候，“偶发连接超时”很容易让人联想到发布变更、配置错误或者资源耗尽，真正服务死掉的场景反而不多。

我拉了一堆监控面板，结果很尴尬：Pod 的 CPU 使用率只有 20% 左右，内存完全够用，没有 OOMKilled，日志里也没有明显异常。B 服务的接口其实已经成功返回了大量请求，只是有一部分请求连 TCP 连接都没有建立起来，更谈不上应用层逻辑执行。再看失败的时间分布，它不像“高峰期流量压垮服务”那样有规律，而是随机的、尖锐的抖动，每次持续几分钟，然后自己恢复。

我把现象整理成一张表，用来提醒自己不要被表象带偏：

这张表做完，我心里已经把目标从“B 服务是不是挂了”转移到了“新建连接到底是在哪一步被丢掉”。这一步看起来简单，但特别重要：如果一开始就钻进应用日志里找异常，很可能一晚上都出不来。

1.2 先搞清楚“连接超时”的本质

很多人看到curl 56 recv failure: 连接超时会以为是对端太慢、响应迟迟不来。其实这个报错的本质是 TCP 三次握手没有完成：客户端发出 SYN 数据包，然后一直等 SYN-ACK，等了好几个超时周期后内核放弃了这次尝试。

三次握手可以类比成一个打电话的场景：你拨号过去，电话通了，但对面一直不接；系统重拨几次之后，告诉你“对方无人接听”。这里的“有人不接”可能是电话坏了、信号被中断，也可能是有人故意把电话线掐了。放在网络里，就是 SYN 包被中间某个环节静默丢弃，而不是被明确拒绝。如果是 RST 拒绝，客户端通常很快能收到“连接被拒绝”；唯独“连接超时”最难缠，因为包丢了，你根本不知道丢在了哪里。

这个认知直接决定了后续的排查方向。我不该再死死盯着应用层，而是应该沿着网络路径一层层往下找，从 DNS、Service NAT、宿主机内核，一直查到物理链路。后面每一步，都是顺着“包在哪一层丢掉”这个问题展开的。

2. 第一轮排查：应用层、DNS、健康检查全部排除

2.1 先翻遍应用服务的“家门口”

在把锅甩给内核之前，我习惯先把最简单的可能排除干净。应用层最容易引发“连接超时”的其实是 listen 队列溢出。一个服务进程虽然活着，但如果它的 accept 队列满了，新来的 TCP 握手会被内核延迟处理，表现为握手超时或者直接失败，而且完全不会体现在 CPU 内存指标上。

我用ss -lnt看了一下 B 服务监听的端口，确认 Recv-Q 和 Send-Q 都没有积压。Recv-Q 如果长期接近 backlog 上限，说明应用线程池扛不住；但当时应用侧一切正常，accept 队列处于空置状态。客户端侧的超时设置我也复测过，从几百毫秒到十秒都试过，只要是失败的业务请求，无论怎么放宽超时，都会稳定地落在同一个“连接建立不了”的区间。

接着查健康检查。Kubernetes 的探针是容器网络内部的访问，它走的是 Pod 网卡到应用端口这条直连路径，没经过 Service 的负载均衡逻辑。探针正常只能说明应用和 Pod 网络栈本身还活着，并不能代表整条业务链路是通的。所以探针绿灯只能算最低限度的“活”，不能让我放心。

2.2 三种访问方式，把嫌疑圈定在 NAT 层

这一步是整个排查里最有信息量的一次实验。我在故障节点上的一个临时 Pod 里，分别通过三种地址访问 B 服务，观察哪种路径会超时。

这个对照结果非常有价值。ClusterIP 本身是一个虚拟 IP，报文必须经过内核的 DNAT 转换，才能被转发到具体的 Pod；而直连 Pod IP 时根本不涉及这一层转换。两者差距如此明显，几乎等于在说：问题不出在 B 服务的代码里，而出在 Kubernetes Service 的 NAT 转发路径上。

为了把问题钉死，我在源节点和目标节点上都抓了包。目标节点的 Pod 网卡上根本看不到那个失败的 SYN 报文，说明包压根没送到容器里；但源节点的物理网卡上确实看到 SYN 发了出去。于是排查范围被进一步压缩到宿主机内核的网络栈，尤其是 netfilter/iptables 这一层。到这里，“Docker/Kubernetes 上无法解释”的神秘感已经消了一大半。

3. 解开“无法解释”的第一层：conntrack 表满导致静默丢包

3.1 被日志限速淹没的关键一行

真正给出答案的，是一条很容易被人忽略的内核日志。我在故障节点的宿主机上执行了下面这条命令：

dmesg -T | grep -i nf_conntrack | tail -20

结果看到一行我非常熟悉的报错：

nf_conntrack: table full, dropping packet

这行日志低调得过分：内核默认对这类消息做了限速，一分钟可能只打印几条，而且它不会出现在应用日志、容器日志里，只存在于宿主机的 dmesg 缓冲中。很多问题处理到一半就被“服务指标正常、容器正常”给劝退了，很少有人会专门打开 dmesg 翻内核网络栈的记账信息。这也是这类问题“无法解释”的根本原因之一：不是没有答案，而是答案被藏在大家都不看的日志层。

看到这行日志，我的第一反应是“破案了”，但很快冷静下来：内核只说表满了，没说为什么满。在 Kubernetes 环境里，conntrack 表满导致的丢包像一种慢性病，一天两天看不出问题，流量稍微集中就爆发，而且只要旧连接不受影响，监控面板上就永远是“一切正常”。

3.2 conntrack 是什么，以及它为什么和 Service 绑定得这么紧

简单解释一下 conntrack：这是 Linux 内核 netfilter 框架里的连接跟踪模块。它会为每个经过的网络连接维护一条记录，包括五元组（源 IP、源端口、目标 IP、目标端口、协议）和连接状态。它的存在让 iptables 的 NAT 功能能够工作：一个数据包经 DNAT 改了目标地址后，回包还要能原路改回来，靠的就是这张“登记表”。

可以把它想象成快递公司的改址登记本。包裹进来时，快递员在登记本上写“这个客户的新地址是 XX”，回程凭证才能发对地方。问题是登记本有厚度上限，一旦写满，新来的包裹就没法登记，快递员只能把包裹丢在门口。table full, dropping packet就是这个丢门口的动作。

Kubernetes Service 的 ClusterIP 之所以能访问，是因为 kube-proxy 在 iptables 里预设了 DNAT 规则，把 ClusterIP 换成后端 Pod IP。而每一次这样的转换，都要依靠 conntrack 记录，否则响应报文无法正确还原源地址。换句话说，Service 的流量规模越大，conntrack 表的压力就越大。整个集群里所有经过 Service 的调用、健康检查、监控抓取，甚至节点上的 DNS 查询，都会被登记进来。默认上限通常是 262144 条（取决于nf_conntrack_buckets），听起来不少，但节点上托管的 Pod 一多、短连接频率一高，这 26 万条很快就会被用完。

3.3 现场验证：不是猜测，是实打实的计数

为了确认当前就是 conntrack 表满，我做了三件事。

第一，查看当前表项数和上限：

cat /proc/sys/net/netfilter/nf_conntrack_count cat /proc/sys/net/netfilter/nf_conntrack_max

故障节点上count已经顶到max的 99%，有些节点短暂溢出，数值直接贴着上限走。

第二，看失败计数：

conntrack -S

结果显示insert_failed在持续增长。insert_failed代表试图新建连接跟踪条目但没有成功的次数，这个字段一旦快速增长，基本就是“表满丢新包”的实锤。

第三，再次验证访问路径：在同一个时间窗口里，直连 Pod IP 稳定、走 ClusterIP 间歇失败。直连可能因为同网段不需要 NAT 而避开了 conntrack 的瓶颈；需要新建条目、走 NAT 转发的请求则被丢弃。这几个证据合在一起，根因已经不用再猜了。

4. 表满不是偶然：从计数分析到短连接风暴

4.1 谁把 26 万条记录吃掉了

根因确认后，接下来要做的是“清理现场”和“防止复发”。但如果只调大表，不搞清楚是谁吃掉的，过几天问题还会回来。

我把conntrack -L的输出导到文件里，用 awk 把 src 和 dst 字段拆出来做了个简单的频率统计：

conntrack -L | awk '{for(i=1;i<=NF;i++){if($i ~ /^src=/){print $i}}}' | sort | uniq -c | sort -rn | head

结果很有意思：占比最高的不是业务大流量，也不是数据库连接，而是几个很容易被忽略的角色——监控采集器、Kubernetes 的探针请求、日志采集 Agent 的 HTTP 回调，以及一大批没有开启 keep-alive 的服务间调用。这些流量的共同特征是“短小频繁”：建立连接，发几个字节，断开，过一会再来一次。每一次连接都会在 conntrack 里留下条目，连接结束后进入 TIME_WAIT 状态，默认还要再停留 120 秒才被回收。

如果连接是长连接，表项虽然一直存在，但数量是稳定的；偏偏大部分是高频短连接，所以表项的新增速度远超回收速度，很快就把容量吃满。而且服务规模越大的集群，这种“短连接日常噪声”就越可观，因为每个组件的连接量单独看都不起眼，叠加上千个 Pod 之后就是一场风暴。

4.2 用一道乘法题估算容量够不够

这里给一个可以复用的估算逻辑，帮助大家判断自己集群的 conntrack 容量是否即将告急。假设集群里有一个服务实例，每秒对外发起 200 个短连接调用，每个连接结束后要停留在 TIME_WAIT 状态 120 秒。那么，这一个实例贡献的常驻表项就是：

200 连接/秒 × 120 秒 = 24000 条

如果默认上限是 262144 条，那么不到 11 个这样的实例就能把整张表塞满。这还没算 ESTABLISHED 状态的长连接、DNS 请求、探针和其他节点上的流量。而现实中，一个中等规模的 Kubernetes 集群，服务实例数量动辄上百，每个实例每秒发起几十到几百个连接都非常正常。再加上产品侧的调用链路放大，表满几乎是必然事件。

这个表格说明了一件事：单纯把nf_conntrack_max调大只是止痛，真正的根治办法是减少不需要的连接新建频率，让表的新增和回收回归平衡。

4.3 与表满伴生的“僵尸 conntrack 坑”

排查过程中，我还注意到一个和 conntrack 经常一起出现、同样会让连接“偶发超时”的坑：Pod 重建后，旧 conntrack 条目里的目标 IP 还指向已经被销毁的旧 Pod 地址。

Kubernetes 里 Pod IP 是短命的，每次滚动更新都可能变化，但 Service 的 ClusterIP 不变。如果外部流量通过固定源端口持续重连同一个 Service，新连接很可能因为五元组一致，被 conntrack 命中旧条目，进而被转发到已经不存在的 Pod IP 上。结果就是：从负载均衡器进来的请求，时不时超时或者连接被重置，完全随机，特别像玄学故障。

这一类问题在外部流量经过 NAT 网关、源端口被网关固定复用时尤其突出。遇到这种情况，等旧 conntrack 条目超时后会自动恢复，也可以主动清理相关条目：

conntrack -D --orig-src 10.233.20.1 --orig-dst 10.233.20.2 -p tcp --orig-sport 8080 --orig-dport 443

如果分不清是哪条，可以直接清掉某个目标 IP 的全部条目，但要谨慎，这可能会打断正在进行的存量连接。

5. 处理手段与调优参数：不仅要扩容，还要管住连接寿命

5.1 先止血：把表容量临时扩到足够大

故障恢复永远是第一步。受影响节点上，我先临时把表上限调大，让业务先跑起来：

sysctl -w net.netfilter.nf_conntrack_max=1048576

这个动作几乎立刻生效，不需要重启任何进程。把容量从 26 万拉到 100 万，相当于给快递公司加了一倍的登记本。需要说明的是，nf_conntrack_buckets这个哈希桶数量通常是模块加载时确定的，很多新内核虽然支持动态扩容，但在生产环境里临时折腾它性价比不高。如果你希望稳定支撑更大的表容量，建议在启动参数nf_conntrack.hashsize或模块加载参数里配好，比如：

echo 262144 > /sys/module/nf_conntrack/parameters/hashsize

之后把相关参数写进/etc/sysctl.d/99-conntrack.conf让它持久化：

net.netfilter.nf_conntrack_max = 1048576 net.netfilter.nf_conntrack_tcp_timeout_established = 1800 net.netfilter.nf_conntrack_tcp_timeout_time_wait = 60

注意一点：在调大 max 的同时，要留意哈希桶数量和内存开销。每个 conntrack 条目大约占用几百字节，100 万条会吃掉几百 MB 内存，对节点内存规划是有影响的。别只盯着“数量大就安心”。

5.2 给连接寿命设置更合理的“保鲜期”

扩容只是短期手段，更关键的是让 conntrack 条目的生命周期匹配真实业务节奏。Linux 的默认超时对大型容器集群来说太宽松了，尤其是 ESTABLISHED 状态默认长达 5 天。如果一些空闲连接长期没有流量，表项就一直挂在那里，完全浪费容量。

但我必须提醒一句：不要把 established 超时调得过分激进，比如 300 秒。如果应用本身有长连接，且 TCP keepalive 配置较疏，conntrack 可能会在连接仍被使用者视为“活着”时就把它清掉，导致后续报文无法完成 NAT 逆转换，反而出现更诡异的“断流”。内部服务之间基本都有周期性的心跳或者探活，1800 秒是比较安全的起点；数据库等连接如果确实需要长时间空闲挂起，可以单独保留更长的超时。

5.3 应用侧改造：让连接自己尽量活久一点

这一步才是根治。因为不管把表扩多大，只要业务保持高频短连接的行为，未来终究还会撞上限。

第一，服务间 HTTP 调用必须开启 keep-alive。很多语言的 HTTP 客户端默认复用连接，但也有不少版本默认每次请求新建连接，这是最典型的 conntrack 杀手。第二，引入连接池。数据库、Redis、MQ 这类资源型连接，全部改成连接池管理，池化后的复用率能直接把新建连接频率降一个量级。第三，Kubernetes 探针频率可以适当调低，比如 liveness 从 10 秒改成 30 秒，在大多数场景下不影响故障发现速度，却能为 conntrack 表减负。第四，如果确实无法改造短连接，那就只能靠监控提前发现水位，把容量松紧掌握在手中。

改造完成后，我盯着监控面板验证了整整一个发布周期：nf_conntrack_count的均值从 26 万附近降到了 9 万左右，insert_failed归零，dmesg 里也不再出现 dropping packet 的新日志，业务失败率曲线完全放平。

6. 顺手排掉的另一个经典坑：MTU 与 overlay 封装

6.1 “大包必挂、小包正常”的信号更接近 MTU

conntrack 的问题解决后，复盘时我们又发现了一个容易被忽略的姊妹坑：客户端只要发起稍大一点的请求体，就稳定超时，而普通的小请求完全正常。这类故障的典型特征是“由包大小触发”，而不是“由连接并发触发”，和刚才的 conntrack 表现明显不同。

原因在 overlay 网络。Docker/Kubernetes 集群的 Pod 网络很少直接使用宿主机网卡，而是通过 VXLAN、IPIP 这类隧道把数据包封装起来再发送。隧道封装会给原始数据包增加几十字节的外层头部，比如 VXLAN 大约增加 50 字节。如果容器网卡和宿主机网卡都被设成了标准 1500 MTU，一个 1500 字节的 Pod 数据包，封装后变成 1550 字节，超过了底层链路能承载的上限，结果就是大包被丢弃，小包安然无恙。

TCP 对大包的表现尤其让人迷惑：握手是几十字节的小包，能正常完成；一旦传输阶段出现超过路径 MTU 的数据段，就开始重传、超时。应用侧看到的依然是“连接超时”，但原因完全在另一个层面。这种故障如果运气不好，会和你刚解决的 conntrack 问题同时存在，让人误以为没有修好。

6.2 一条 ping 命令快速定位 MTU 问题

排查这类问题不用靠猜，直接用禁止分片的方式发大包探测：

ping -M do -s 1472 <目标IP>

这里的-M do表示禁止分片，-s 1472是 ICMP payload 大小，加上 8 字节 ICMP 头和 20 字节 IP 头，正好等于标准以太网 MTU 1500。如果执行结果出现Frag needed and DF set或message too long，说明路径上的 MTU 小于 1500；如果这条命令能通，说明两层之间的基础 MTU 没问题，再用-s 1450、-s 1400逐级下探，找到临界值。

我还习惯配合测量 Pod 到宿主机网关的链路：

ping -M do -s 1450 <宿主机网关IP>

如果 Pod 内 1450 能通而 1472 不通，并且底层物理链路是 1500，通常就需要把隧道网络配置的 MTU 降下来，例如把 VXLAN 的对外传输 MTU 设为 1450 或更低，让上层封装之后仍不超过物理链路。

6.3 两种故障叠加时的判断顺序

经历过这次排查，我的经验是先看并发水位，再看包大小。如果失败集中在请求高峰、且insert_failed在飙升，优先怀疑 conntrack；如果失败总是和“比较大的请求体”绑定，小请求再怎么高峰也不会出问题，就优先测 MTU。两者也可以同时量：一边执行conntrack -S，一边跑 1472 的探测包，几分钟内就能把最常见的两个嫌疑排掉。

这类网络问题还有一个共同点：容器里看到的永远只是“对方没回应”。真正的答案往往在容器外面的宿主机内核里，这也是我后来每次排查都先上宿主机开 dmesg、看 proc/sys 的原因。

经历这次以后，我把 conntrack 的水位、insert_failed 计数和 MTU 探测脚本都加进了宿主机初始化检查和日常巡检告警里。再遇到“服务活着但连接超时”的告警，至少不会再从应用日志里大海捞针了。如果你想在自己的环境里提前预防，最值得做的一件事，就是在每台节点上把dmesg -T | grep nf_conntrack和cat /proc/sys/net/netfilter/nf_conntrack_count这两条命令加到监控脚本里。这次的“无法解释”，说到底只是因为内核的无声抱怨一直没有被人听见罢了。