一次出口连接数超限事故引发的架构反思：代理、NAT 与大厂实践

一次”上网时断时续、新页面打不开但 ping 网关正常”的事故，最终定位在出口 NAT 连接数超限——这比带宽打满更隐蔽。

一、现象与定位

用户侧表现：已建连接还能跑、新连接建不起来；部分终端间歇性掉线。查出口网关发现 NAT 会话表接近上限、CPU 偏高。带宽利用率其实并不满，所以一开始容易被误判成”运营商问题”。连接数（并发会话数）是出口网关的硬指标，没有足够余量，再大带宽也会”连不上”。

二、根因

网关 NAT 会话规格不足，或内网存在 P2P、病毒扫描、大量短连接把会话表占满；部分终端疯狂建连，挤掉正常用户的会话槽位。强制代理、集中上网的架构下，所有流量汇到单一出口，连接数压力被放大。

三、架构反思与改进

把 NAT/出口功能从业务网关剥离到独立的高性能 NAT 网关或负载均衡设备，会话规格留足余量；对单 IP 做会话数限速，防个别终端占满；开启连接数监控与阈值告警，提前发现劣化；必要时按业务分出口（办公/生产/访客），避免互相挤占。大厂做法本质是：连接数当成和带宽同等重要的资源来规划与监控。

三、出口连接数治理要点

• 根因 → 单设备 NAT 会话表上限或代理单点瓶颈。
• 扩展 → 出口水平扩展，按业务分流到多出口。
• 监控 → 盯连接数而非只看带宽，提前扩容。

连接数超限比带宽打满更隐蔽：带宽看着空闲，会话表满了新连接全拒。大厂做法是用连接数而非带宽做容量评估，并设硬上限告警。