云主机CPU正常、NAT网关带宽也没跑满，应用却突然无法建立新的外部连接，重启一部分任务后恢复。这类问题可能不是带宽，而是大量内网连接共享少量公网IP时耗尽了SNAT映射或端口资源。
SNAT在做什么
内网客户端访问互联网时，NAT网关把私网源地址和端口转换为公网地址与端口，并维护回程映射。不同连接必须能被唯一识别。公网IP数量、端口分配策略、目标地址和协议共同决定可承载容量。
为什么热门目标更容易触发
大量实例同时访问同一个API主机和端口，映射组合高度集中。即使每台内网主机只有几百个连接，汇聚到一个公网IP后也可能成为瓶颈。访问很多不同目标时，部分实现可以复用相同公网端口，实际行为应以云服务或设备文档为准。
典型现象
| 现象 | 可能解释 |
|---|---|
| 已有连接继续工作，新连接超时 | 新的SNAT映射无法分配 |
| 只访问某个外部服务失败 | 目标集中或对端限流 |
| 增加公网出站IP后改善 | 映射容量得到扩展 |
| 任务批量启动时故障 | 连接风暴或重试同步发生 |
先排除对端限流
外部服务可能限制单一公网IP的连接数或请求频率，表现与SNAT耗尽相似。检查NAT网关分配失败指标、连接数和设备日志，同时读取对端429、503或连接拒绝证据。不能仅凭“换IP后恢复”就认定网关端口耗尽。
短连接如何放大消耗
每个请求都新建TCP连接，会让映射快速创建并在关闭后保留一段时间。HTTP Keep-Alive、连接池和HTTP/2多路复用可减少数量，但要设置最大寿命与空闲超时，避免长期占用或复用已失效连接。
UDP也有状态和超时
UDP没有TCP握手，但NAT网关仍要维护源目标映射，并在空闲后清理。DNS、日志或实时媒体的高并发UDP可能占用大量状态。缩短超时会影响迟到报文，延长又会增加占用，需要按业务与设备能力平衡。
增加公网IP如何规划
扩展出站IP池可以增加映射空间，也会改变第三方白名单、审计与费用。添加前确认服务如何在IP间分配连接，通知依赖方更新白名单并保留回滚。NAT网关与代理固定出口的架构差异可参考企业白名单的NAT与代理选型。
分散目标或部署私有连接
访问云服务时，私有端点、服务连接或区域内直连可能避免公共SNAT，但需考虑DNS、路由和访问策略。不能为省端口就随意绕过安全检查；架构变更要纳入威胁评估和成本比较。
监控哪些指标
- 当前活跃映射、峰值连接与新建速率；
- SNAT端口分配失败或丢弃计数；
- 按目标IP、端口和协议的连接分布；
- 公网IP池使用、带宽、包速率和错误；
- 客户端重试次数、连接池命中和请求延迟。
修复顺序
- 确认失败发生在新建连接，并定位受影响目标；
- 对齐NAT网关、客户端和外部服务日志；
- 修复连接泄漏、短连接和同步重试；
- 按容量增加出站IP、网关或分区；
- 更新外部白名单与审计规则；
- 在峰值模型下验证TCP、UDP和故障恢复。
怎样建立简单容量模型
按业务分别记录实例数、每实例并发、目标主机和端口、连接平均寿命、峰值新建速率以及TCP或UDP比例。再映射到每个NAT网关和公网IP，观察最热门目标占用了多少映射。容量规划要覆盖滚动发布、任务整点启动和第三方故障引发的重试峰值，不能只用日均连接数。
故障恢复后还要检查什么
端口分配恢复并不代表所有任务自动成功。核对失败请求是否被有限重试、写操作是否重复、长连接是否重新建立，以及外部服务是否因突增流量继续限流。对新增公网IP还要验证DNS、路由、第三方白名单、日志归属和安全告警，避免容量修复制造新的访问差异。
结论
SNAT端口是独立于带宽的有限资源。通过目标分布、映射失败和新建连接证据确认瓶颈后，先减少无效连接，再扩展公网IP或采用私有连接，才能避免容量问题周期性复发。
