VPS连接数突然打满怎么办？conntrack表、NAT状态与短连接风暴排查
VPS突然出现新连接超时、容器请求失败，内核日志还提示nf_conntrack: table full，通常不是简单的“带宽用完”。Linux连接跟踪表负责记录经过防火墙和NAT的连接状态，短时间大量新连接、异常扫描、容器网络或UDP会话都可能让表项快速增长。
先确认是不是连接跟踪耗尽
sysctl net.netfilter.nf_conntrack_count
sysctl net.netfilter.nf_conntrack_max
dmesg -T | grep -i conntrack | tail -n 20
ss -s
cat /proc/net/nf_conntrack 2>/dev/null | head重点看当前使用量与上限的关系、日志是否持续出现table full，以及连接状态的构成。只有看到表项逼近上限，才能把排查重点放到conntrack；如果主要是CPU、网卡队列或上游线路问题，调表容量并不能修复。
把来源拆成四类
| 来源 | 观察信号 | 下一步 |
|---|---|---|
| 业务短连接 | ESTABLISHED很少，SYN/TIME_WAIT快速增长 | 检查HTTP keep-alive、连接池和重试策略 |
| 容器或NAT | 宿主机连接正常，容器出口失败 | 核对转发路径、规则和容器网络模式 |
| UDP会话 | UDP表项多、持续时间长 | 确认应用超时与会话回收策略 |
| 异常流量 | 来源地址集中或端口扫描明显 | 先做入站最小化和上游安全组核验 |
低风险恢复顺序
- 保存
ss -s、conntrack计数、接口流量和应用日志，建立故障时间线。 - 在云安全组和主机防火墙层面减少不必要的入站暴露，不要直接删除整套规则。
- 降低异常客户端重试和短连接并发，优先让应用复用连接、设置合理超时。
- 确认内存余量与云平台限制后，再评估调整
nf_conntrack_max；修改前记录原值并准备回滚。
如果服务运行在Docker或其他容器网络中，要同时检查宿主机和容器命名空间可见的规则与统计。某些云平台会限制内核参数或网络模块，配置写入成功也不代表实际生效。
验收与防复发
恢复后持续观察连接跟踪使用率、SYN速率、TIME_WAIT趋势、容器错误率和应用重试次数。不要用一次清表或重启作为“已解决”的证据；需要确认在业务峰值下表项仍有余量，并且异常来源已经被隔离或修复。
连接跟踪排查应在自有或获授权的VPS上进行。不要通过放大连接、扫描第三方主机或绕过网络策略来验证容量。
