为什么服务器没坏，网络却断了？
验证与回滚
说到NAT，很多问题都出在细节上。有一次，我正在部署一个容器集群，突然监控报警：几台ECS无法拉取Docker镜像，连接外部API全部超时。登录服务器检查进程正常，路由表正确，ping内网网关也通。就在一筹莫展时，我瞥了一眼云控制台的NAT网关监控，看到“最大连接数”曲线已经顶到天花板——端口耗尽了。
对于刚接触公有云的朋友来说，NAT网关就像是一个“翻译官”。它让内网的服务器共用同一个公网IP去访问互联网。每次服务器发起一个外部连接，NAT网关就会分配一个临时的源端口，并在回包时把数据“翻译”回对应的内网机器。这个临时端口是有限的——一个公网IP只有65535个端口可用（实际上还要扣除一些保留端口）。当并发连接数超过上限，新的连接就会被丢弃，表现为网络中断。这种故障非常隐蔽，因为服务器自身状态是完好的，所有错误都发生在网关层面。
端口耗尽到底是怎么发生的？
先看关键判断
要理解端口耗尽，我们先看一个生活中的场景：假设你家只有一个门牌号码（公网IP），但家里有100个人（内网服务器）要出门办事（访问外部服务）。每个人出门时都要拿一个“编号牌”（源端口），回来时凭牌进门。而编号牌一共只有65535个，如果同时出门的人太多，牌子不够用，后面的人就出不去。这个“编号牌”就是端口的本质。
在技术层面，当服务器发起HTTP请求、数据库连接、API调用等，操作系统会随机分配一个源端口（1024-65535），并在连接结束后释放。但如果短连接特别多，连接释放后端口会进入TIME_WAIT状态，需要等待一段时间才能重新使用。如果业务设计不合理（比如每次请求都新建连接而不复用），端口回收速度跟不上新建速度，就会导致可用端口逐渐减少，最终爆满。
公有云的NAT网关通常按规格限制了最大连接数，例如小型NAT网关可能只支持5万连接，中型支持50万连接。一旦并发连接超过这个值，NAT网关就会开始丢包，拒绝新连接。而且NAT网关本身的端口资源也是有限的，即使你的业务服务器内存很大、CPU空闲，端口耗尽仍然会触发网络中断。
如何快速判断是NAT网关连接数爆满？
我的处理经验
当你遇到服务器无法访问外网，但内网通信正常时，可以按照以下步骤排查：
- 第一步：检查服务器自身网络。ping公网IP（如8.8.8.8）如果超时，而ping内网网关正常，说明问题出在出口设备上。
- 第二步：查看NAT网关监控指标。在云控制台找到NAT网关的监控面板，看“连接数”、“新建连接数”、“丢弃包数”是否有峰值或达到上限。
- 第三步：登录服务器查看端口使用情况。运行
netstat -an | grep TIME_WAIT | wc -l统计TIME_WAIT数量，如果这个数字很大（几万甚至十几万），说明短连接压力巨大。 - 第四步：检查业务日志。看是否有连接超时、Connection refused等错误，特别是多个服务向外调用时集中爆发。
如果以上几个迹象同时出现，几乎可以锁定是NAT网关端口耗尽导致的网络中断。此时哪怕你重启服务器、重启应用也无法立即恢复，只有等旧连接逐步释放，或者手动调整网关配置才能快速解围。
延伸阅读：此处可内链到“NAT配置案例”相关文章。
补充参考：此处可内链到“NAT故障排查实例”。
调优方法：从治标到治本
知道了原因，调优就有明确方向。下面按照从快速应急到根本优化的顺序，给出具体方案。
紧急恢复：临时提升NAT网关规格
在公有云控制台，可以直接修改NAT网关的规格（例如从小型升级到中型），这通常能立刻将最大连接数提升数倍。升级过程一般不中断现有连接，是应急首选项。但注意，大规格意味着更高费用，并且如果业务增长过快，迟早还会再次触顶。所以这只是争取时间的手段。
启用连接复用（端口转换）
大多数云厂商的NAT网关支持开启“端口复用”或“SNAT连接复用”功能。启用后，NAT网关会尽量把多个内网连接映射到同一个外部端口上，大幅提高端口利用率。例如，A服务器访问百度，B服务器也访问百度，NAT网关可以将两个内部连接复用同一个外部端口号（取决于协议和目的地址）。开启此功能后，同样的规格能支撑的连接数可以增加5到10倍。具体操作在NAT网关的“SNAT规则”或“高级配置”中。
优化业务代码：拥抱长连接与连接池
这是最根本的解决方案。如果业务代码每次发送请求都新建TCP连接，并在收到响应后立即关闭，会制造大量短连接和TIME_WAIT。改用连接池（如HTTP连接池、数据库连接池）后，复用已有连接，显著减少并发端口占用。对于HTTP服务，使用keep-alive；对于数据库，配置最小空闲连接数。改造成本不高，但效果立竿见影。另外，如果应用内频繁调用外部API，可以考虑合并请求或使用异步批量操作。
调整操作系统内核参数
从服务器层面，可以调整TCP参数加速端口回收：
net.ipv4.tcp_tw_reuse：允许将TIME_WAIT状态的连接用于新连接（需要配合tcp_timestamps开启）。net.ipv4.tcp_fin_timeout：缩短FIN_WAIT2状态的等待时间。net.ipv4.tcp_max_tw_buckets：限制TIME_WAIT连接总数，超出则直接释放。
需要特别提醒：net.ipv4.tcp_tw_recycle 在内核4.12以后已被移除，并且可能造成NAT环境下的连接问题，不建议使用。调整参数前先备份sysctl.conf，并在业务低峰期重启网络服务或重启服务器使配置生效。
架构层面：使用多个NAT网关或分散出口
如果单网关的连接数瓶颈无法突破，可以考虑为不同业务子网分配独立的NAT网关，或者将部分对外访问改为通过负载均衡器转发。另外，对于不需要固定公网IP的场景，可以给每台服务器绑定弹性公网IP，绕过NAT网关直接出网。当然这样会增加公网IP费用，但彻底消除了端口耗尽风险。
NAT：防患于未然：监控与告警
故障定位思路
端口耗尽并不是突然发生的。在NAT网关的监控中，连接数曲线会逐步攀升，直到撞上限。所以最好的策略是提前设置告警阈值。建议在连接数达到规格上限的70%时触发警告，80%触发紧急告警，留给运维人员充足的缓冲时间。同时，关注新建连接数趋势，如果新建连接数持续增长而释放速率不变，就要提前介入。
另外，可以定期在服务器上执行netstat -s | grep 'connections'查看协议统计，关注SYN超时、RST包数量等异常指标。一旦发现异常，立刻分析是业务突发还是代码缺陷。
想继续深入：此处可内链到“NAT优化清单”文章。
总结
配置前的检查
NAT网关连接数爆满（端口耗尽）是公有云环境中一类隐蔽但常见的网络中断原因。它的本质是源端口资源竞争，故障表象却是服务器“明明活着却连不上外网”。通过监控曲线、端口使用状态和业务日志可以快速定位。调优时先升级规格应急，再启用连接复用，最终落脚点永远是优化业务代码减少短连接，并配合内核参数微调。只要养成监控告警的习惯，这类问题就再也不会让你深夜爬起来了。
延伸阅读