NAT 场景异常排查
做地址转换的 Linux 网关（含 Kubernetes 节点）依赖连接跟踪表来记住每条会话的转换关系。条目里同时保存原始方向与回复方向的元组，并可能带未回复标记：请求到达了但没有看到回包，就会出现持续的未回复条目。另一类现象是条目频繁重建，通常与空闲超时和应用心跳间隔不匹配有关，表现为长连接莫名中断。
基本信息
| 适用平台 | Linux netfilter 网关、负载均衡节点、容器节点 |
|---|---|
| 依赖模块 | nf_conntrack |
| 关键参数 | net.netfilter 下各类协议的空闲超时 |
| 观察对象 | 未回复标记的条目比例与条目重建频率 |
| 权限要求 | root 或 CAP_NET_ADMIN |
典型使用场景
- 网关后面的服务偶发超时，需要区分是回程缺失还是上游没响应。
- 转换后的连接在客户端看来一直「半死」，需要确认条目是否被提前回收。
- 长连接空闲一段时间后中断，而两端都没有主动关闭。
- 排查同一目标下部分来源不通用，需要按目标收敛条目。
- 容量评估：确认转换场景下表条目增长速度是否超出预期。
观察与对照
观察与对照
conntrack -L 2>/dev/null | grep UNREPLIED | head -20 # 未回复条目
conntrack -L -p tcp --dport 8080 2>/dev/null | head # 只看某目标端口
sysctl net.netfilter.nf_conntrack_tcp_timeout_established # 已建立连接超时
sysctl net.netfilter.nf_conntrack_tcp_timeout_time_wait # 关闭等待超时
conntrack -E -p tcp --dport 8080 2>/dev/null | head -20 # 事件流，看条目新建与销毁
ip route get 10.0.0.11 # 回程路由是否存在现象归因
| 现象 | 可能原因 | 处置方向 |
|---|---|---|
| 未回复条目持续出现 | 回程路径缺失 | 核对回程路由、邻居表与上游策略 |
| 条目频繁重建 | 空闲超时短于心跳间隔 | 对齐心跳与超时，或调整超时参数 |
| 长连接突然中断且无握手挥手 | 中间设备清理了会话 | 核对转换设备的会话表与超时 |
条目里的方向字段容易读反：回复元组描述的是回程，判断「请求有没有到」要看原始方向，两者混淆会得出相反结论。
调大超时参数会同时放大表占用：在容量紧张的网关上，先修好心跳与回收逻辑，再考虑放宽超时，否则只是把问题推迟到表满的时候。