出口 NAT 端口耗尽排查实战：从间歇性超时到根因定位

很多网络故障最难受的地方，不是“彻底不可用”，而是“偶发、分散、看起来谁都像没问题”。 比如业务方反馈： 登录接口偶发超时； 调第三方 API 时成功率忽高忽低； 同一时间只有部分用户报错； 应用进程、CPU、内存都正常； ping 目标地址大多也通。 这类故障特别容易把排查团队拖进泥潭。应用团队怀疑网络不稳，网络团队看链路没断，系统团队看主机指标也没爆，最后所有人都在猜。 如果你做过云上出口治理、分支上网架构或大并发业务接入，八成见过一个高频元凶： 出口 NAT 端口耗尽 。 它不一定让整条链路彻底中断，却很容易制造“部分请求失败、偶发超时、业务波动”的灰度故障。更麻烦的是，如果只有基础监控，没有流量层证据，团队往往能看到现象，却解释不了根因。 本文不讲空泛理论，直接按一线排障视角拆一遍：出口 NAT 端口耗尽到底怎么识别、怎么缩小范围、怎么验证、怎么避免反复踩坑。 一、为什么 NAT 端口耗尽这么容易被误判 很多团队对 NAT 的理解停留在“把内网地址转换成公网地址”。这当然没错，但在真实生产环境里，NAT 真正稀缺的资源不是这句定义，而是： 可分配的源端口空间和连接生命周期管理能