conntrack 表满之后，最先坏的是什么

现象很有迷惑性：已经在传的连接正常，新的 SSH 有时连得上有时连不上，HTTP 大量超时，dmesg 里出现 nf_conntrack: table full, dropping packet。

原因是 conntrack 满之后，内核丢弃新包而不是拒绝。对客户端而言这是超时而不是拒绝，所以表现为“网络很慢”而不是“连不上”，诊断方向很容易跑偏。

解法不是无脑调大 nf_conntrack_max，而是先看是谁在占：短连接密集的服务、NAT 后面的客户端、或者被扫描。netstat-nat 或者 /proc/net/nf_conntrack 的行数按源 IP 统计一眼就能看出来。

调参时要注意哈希桶：通常哈希桶数应设成最大值的一半以上，否则链表过长，性能会先于容量成为问题。