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 为固定值。