conntrack表满时内核强制将tcp_established_timeout重置为300秒，与配置值无关；表现为长连接异常断开、insert_failed增长、ESTABLISHED连接集中存活250–350秒。
conntrack 表满直接导致 tcp_established_timeout 被内核强制重置为 300 秒
这不是配置生效或策略调整，而是内核在 nf_conntrack_table_full 触发后主动降级行为。只要 /proc/sys/net/netfilter/nf_conntrack_tcp_be_liberal 为 0（默认），且连接跟踪表满，内核就会把 tcp_established_timeout 临时压到 5 分钟——不管你在 /proc/sys/net/netfilter/nf_conntrack_tcp_timeout_established 里设的是 43200（12 小时）还是 3600（1 小时）。
常见错误现象包括：
- 长连接业务（如 WebSocket、数据库连接池、gRPC streaming）频繁断连，但抓包显示无 FIN/RST，仅表现为 read timeout 或 connection reset by peer
-
ss -s显示tcp连接数稳定，但conntrack -S中entries持续接近max，且insert_failed持续增长 - 应用层日志中出现大量“connection closed unexpectedly”，但服务端无主动 close 记录
为什么 300 秒 timeout 会放大连接雪崩风险
5 分钟超时本身不致命，问题出在「连接释放节奏失控」：原本 12 小时才回收的 established 连接，在表满后变成 5 分钟强制回收，导致同一客户端反复建连；而新连接又立刻占一个 conntrack slot，进一步加剧表满——形成正反馈循环。
关键影响点：
