conntrack表满解决方法：调短tcp_established_timeout

golang学习网今天将给大家带来《conntrack 表满解决方法：缩短 tcp_established_timeout》，感兴趣的朋友请继续看下去吧！以下内容将会涉及到等等知识点，如果你是正在学习文章或者已经是大佬级别了，都非常欢迎也希望大家都能给我建议评论哈~希望能帮助到大家！

conntrack表满后秒满的根本原因是net.netfilter.nf_conntrack_tcp_established_timeout默认值过大（432000秒），导致空闲ESTABLISHED连接长期滞留；需分场景设为300–3600秒，并同步调低TIME_WAIT、CLOSE_WAIT等关联超时，且锁定nf_conntrack_max防止动态下调。

conntrack 表满后清空又秒满，本质是连接老化过慢

根本原因不是 conntrack 表容量不够，而是 net.netfilter.nf_conntrack_tcp_established_timeout 默认值太大（通常 432000 秒，即 5 天）。大量处于 ESTABLISHED 状态但实际已无数据交互的 TCP 连接长期滞留，占满表项。即使手动执行 conntrack -F 清空，新连接快速建立后立刻复现满表。

缩短 tcp_established_timeout 的安全取值范围

不能无脑设成 60 秒——这会误杀长时空闲但合法的连接（如数据库连接池、SSH 保活连接、MQTT 持久会话）。合理做法是分场景调整：

• 若业务多为短连接（HTTP/1.1、REST API），可设为 300（5 分钟）到 900（15 分钟）
• 若含中长连接（WebSocket、gRPC stream），建议 1800（30 分钟）起步，观察 conntrack -L | grep ESTABLISHED | wc -l 峰值
• 生产环境首次调整，先设为 3600（1 小时），持续监控 24 小时内 /proc/sys/net/nf_conntrack_count 和丢包率

必须同步调低其他关联 timeout，否则单改 established 不生效

tcp_established_timeout 只是冰山一角。conntrack 对每个连接状态有独立超时策略，若只改它，连接可能卡在 TIME_WAIT 或 CLOSE_WAIT 状态继续占位。需配套调整：

• net.netfilter.nf_conntrack_tcp_timeout_time_wait：默认 120 秒，可降至 30
• net.netfilter.nf_conntrack_tcp_timeout_close_wait：默认 60 秒，建议设为 20
• net.netfilter.nf_conntrack_tcp_timeout_fin_wait：默认 120 秒，建议设为 30
• 所有修改后必须运行 sysctl -p 生效，且检查 sysctl net.netfilter.nf_conntrack_tcp_established_timeout 确认值已更新

验证是否真解决问题，别只看 conntrack -L

清空后立即跑 conntrack -L | grep ESTABLISHED | wc -l 没用——此时连接还没老化。真正要看的是：

• 持续 10 分钟内，/proc/sys/net/nf_conntrack_count 是否稳定在阈值 70% 以下
• 用 ss -s 对比 tcp 行的 estab 数和 conntrack -C 输出，二者应逐渐收敛（说明老化机制起效）
• 抓包验证：对一个空闲 ESTABLISHED 连接发空 ACK，10 秒后查 conntrack -L，该连接应已消失

最易被忽略的一点：Kubernetes Node 上若启用了 nf_conntrack_max 自动缩放（如某些云厂商定制内核），tcp_established_timeout 调小后可能触发 max 值动态下调，反而加剧问题——得一并锁定 net.netfilter.nf_conntrack_max 为固定值。

理论要掌握，实操不能落！以上关于《conntrack表满解决方法：调短tcp_established_timeout》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！