conntrack表满会导致新TCP/UDP连接被内核静默丢弃，不发RST或SYN-ACK，应用层无错误感知；需按顺序排查：1.检查nf_conntrack_count与max是否超90%；2.分析conntrack状态分布与IP:端口热点；3.关联业务变更、SNAT、iptables规则及K8s配置；4.抓包验证并临时调高上限确认根因。
conntrack 表满时，新 TCP/UDP 连接会被内核直接丢弃（不发 RST，也不 SYN-ACK），因此上层应用收不到错误、超时重试后可能静默失败，业务日志完全无异常。定位需从网络层向下排查，顺序如下：
1. 确认 conntrack 表是否已满
执行命令查看当前使用量和上限：
- cat /proc/sys/net/netfilter/nf_conntrack_count —— 当前 tracked 连接数
- cat /proc/sys/net/netfilter/nf_conntrack_max —— 表容量上限
- 若 count 接近或等于 max（例如 >90%），即为瓶颈点
- 补充：用 conntrack -L | wc -l 可交叉验证，但较慢，生产环境慎用
2. 查看 conntrack 表项分布特征
判断是连接泄漏、短连接洪峰，还是特定协议/端口堆积：
- conntrack -S —— 查看各状态计数（如 expected、invalid、unreplied）
- conntrack -L | awk '{print $3,$5}' | sort | uniq -c | sort -nr | head -10 —— 统计最多的源 IP+目标端口组合
- 重点关注：TIME_WAIT 占比过高（常见于大量短连接未复用）、UNREPLIED 持续增长（连接发起后无响应，如后端不可达或防火墙拦截）
3. 关联业务行为与网络路径
conntrack 满不是孤立现象，需结合流量变化和组件配置分析：
- 检查近期是否有发布、定时任务、爬虫、健康检查变更（如探针频率从 30s 改为 2s）
- 确认是否启用了 SNAT（如 K8s Service、NAT 网关）—— SNAT 会强制创建 conntrack 条目，且无法被客户端主动清理
- 检查 iptables/nftables 规则中是否误加了 -m state --state NEW 或 -m conntrack 相关规则，导致额外跟踪开销
- 容器环境重点看 kube-proxy 模式（iptables vs ipvs）及 conntrack 相关 annotation（如 service.beta.kubernetes.io/topology-aware-hints 间接影响）
4. 验证是否为根本原因并临时缓解
避免“看起来像”实则误判：
- 在问题时段抓包（tcpdump -i any port 80 or port 443 -n），观察客户端 SYN 是否发出、服务端是否回复 SYN-ACK；若客户端发了 SYN 但无任何回包，且 conntrack 已满，则高度相关
- 临时调高上限测试：echo 131072 > /proc/sys/net/netfilter/nf_conntrack_max（注意需同步调整 net.nf_conntrack_buckets，一般为 max 的 1/4）
- 观察调高后问题是否消失；若仍存在，说明有其他瓶颈（如 socket 耗尽、SYN queue overflow）
