业务突然大面积超时，内核日志刷表已满的告警，网络看起来正常，重启服务也没能缓解。
排查方向其实有限，先把可能性排一排。连接跟踪表容量太小，扛不住当前并发；大量短连接快速进出，表项来不及回收；某些连接长时间不释放，把表占满了。
上来先看当前表项数量和上限
sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max调大上限并持久化
sysctl -w net.netfilter.nf_conntrack_max=1048576缩短已建立连接的超时
sysctl -w net.netfilter.nf_conntrack_tcp_timeout_established=600末了确认内核日志不再告警
dmesg -T | grep -i conntrack改之前我把相关日志按时间截了一段存着，事后对时间线用得上。
中途换过一次思路，把范围缩到最小的那一层，反而快了。
别只看报错消失，验证要多做一步。表项数量稳定在容量的一半以下，内核不再打印表满告警，新建连接正常。
容易忽略的是，调大表会占用更多内存，每条约几百字节，几十万条就要多算上百兆，容量和内存要一起评估。报错文案容易误导，真正的原因往往在相邻那一层的日志里。