Linux 新连接偶发超时但端口没耗尽：conntrack 表、丢包计数与回收参数排查

线上接口的并发连接数没有到上限，应用日志却开始出现“connect timeout”。这类故障很容易被误判成端口耗尽：真正卡住新连接的，可能是连接跟踪表已接近上限、网卡在丢包，或者旧状态回收跟不上流量变化。排查时要把内核表、网卡计数和请求时间线放在一起看，不能只跑一遍 ss 就下结论。

先把“端口没满但连不上”拆成三条线

一次故障复盘里，最有价值的不是“把超时调大”，而是确认连接在哪一层消失。客户端发起 SYN 后，如果服务端根本没有看到请求，方向应转向链路、网卡或防火墙；如果握手到了内核但状态无法建立，连接跟踪表和规则计数更可疑；如果 TCP 已建立而应用迟迟不读，才轮到进程和线程池。

把以下三类时间点记到同一份记录里：客户端错误出现的分钟、服务端 nf_conntrack_count 的峰值、网卡 drop 或防火墙拒绝计数的变化。时间对不上，结论就只能算猜测。

连接跟踪表是否真的到了边界

cat /proc/sys/net/netfilter/nf_conntrack_count
cat /proc/sys/net/netfilter/nf_conntrack_max
conntrack -S 2>/dev/null || true

nf_conntrack_count 是当前跟踪项数量，nf_conntrack_max 是允许的上限。前者长期贴近后者，并且与超时分钟重合，才有容量证据。conntrack -S 能补充查看插入失败、丢弃等统计；命令不可用时不要自行补零，保留 proc 文件和内核日志即可。

网卡丢包和规则计数要与请求日志对时

确认表容量没有撞线后，马上看接口级计数，而不是只看吞吐：

ip -s link show dev eth0
ss -s
dmesg -T | tail -n 80

关注 RX/TX 的 dropped、errors 是否在故障窗口跳升。ss -s 只能告诉你套接字的大致分布，不能证明数据包没有在更早的路径丢失。若主机前面还有防火墙或负载均衡，应把它们的拒绝、丢弃、连接速率计数一并导出，至少对齐到分钟级。

这里别急着改内核参数。先做一次短时采样：每 10 秒记录 count、max、接口 dropped 和应用 connect timeout 数量，连续保留 5 分钟。只有计数变化同向，才值得进入参数处理阶段。

处理顺序：先止血，再决定是否调整回收

如果确认是异常来源造成连接跟踪项暴增，优先在入口限速、阻断明确的异常源，或临时摘除故障实例；如果只是业务流量增长，才评估增大跟踪表上限。修改前记录当前值和内存余量，修改后观察新连接成功率、应用延迟和 count 是否回落。

sysctl net.netfilter.nf_conntrack_max
free -m
sysctl -w net.netfilter.nf_conntrack_max=262144

上面的数值只是演示检查路径，不是通用推荐值。生产环境应按连接项大小、内存预算和峰值连接速率压测后确定。若问题来自大量半连接、长时间闲置或错误重试，单纯把 max 调大只会把故障推迟，还可能增加内存压力。

复测要验证“新连接恢复”，不是只看数字变漂亮

处理完成后，用固定客户端、固定目标端口做小批量新连接测试，同时记录成功率和 P95 建连耗时。复测至少包含一次正常低峰和一次接近故障时的流量窗口，避免刚好避开触发条件。

for i in $(seq 1 20); do
  timeout 3 bash -c 'cat  /dev/tcp/203.0.113.10/443' \
    && echo ok || echo timeout
done

可见成功状态是：新连接测试不再集中超时，应用的 connect timeout 与接口 dropped 在同一窗口回落，连接跟踪表有余量且没有新的插入失败。若只有 count 降了而握手仍失败，说明根因还在链路、规则或监听队列。

常见问题

conntrack_count 接近 conntrack_max 就一定会超时吗？

不一定，但这是容量压力的强信号。要结合插入失败、丢弃计数和超时时间点判断，不能单凭比例下结论。

把 nf_conntrack_max 调大能解决所有新连接问题吗？

不能。它只处理跟踪表容量不足；接口丢包、入口规则、监听队列和下游变慢都需要各自的证据。

为什么 ss -s 正常，客户端还是 connect timeout？

ss 主要反映主机当前套接字状态，无法覆盖路径上的丢包、连接跟踪插入失败或前置设备拒绝。应把它和内核、网卡及入口设备计数对齐。

把这次故障变成可复用的检查项

下次遇到类似现象，先保存四份证据：应用建连错误、nf_conntrack_count/max、接口错误计数、入口设备规则计数。确认故障层级后再选择限流、清理异常来源或调整容量。真正的验收标准是新连接恢复并且内存、延迟、丢包没有引入新的副作用。