游戏卡顿白皮书 › L5 数据中心网络设备
云 NAT 网关连接/端口上限 Cloud NAT gateway connection / port limits
原因 ID dc-nat-gateway · 主责 运维团队·网络运维 · 配合 研发团队·服务器开发
在含图示和实验的完整版中打开此卡片 →
私有子网中的服务器访问外部（平台认证、支付、外部 API）时，由 NAT 网关替换地址和端口后发出。发往同一目的地的并发连接超过网关的端口上限，新连接就会失败。
起因 多台服务器向平台认证、支付这类同一外部地址大量建立短连接，或长时间保持连接不关 → 结果 NAT 网关无法再为该目的地分配源端口，新连接失败 → 画面表现 游戏内一切正常，只有登录、支付、奖励发放这类需要调用外部的功能失败或变慢（连不上/无限加载、吞操作/回档）
症状 连不上/无限加载 , 吞操作/回档 因素 丢包, 延迟
谁会遇到 仅特定功能, 全服
何时出现 刚登录/维护结束后, 晚高峰, 人多的时候
负责方 主责 运维团队·网络运维 · 配合 研发团队·服务器开发
研发团队要做的事 调用外部 API 时复用连接（HTTP keep-alive、连接池），不要每个请求都新建连接；池中保留的空闲连接要以短于 NAT 空闲超时（AWS 350 秒）的间隔发送 keepalive，或者主动先关闭；失败时逐步拉长重试间隔并随机打散；按外部调用分别记录失败率和延迟。
运维团队要做的事 给 NAT 网关增加 IP 地址（AWS 公有 NAT 网关默认只能关联 2 个弹性 IP，更多需申请提高配额）；按可用区、子网拆分网关；对端口分配失败指标设告警（AWS ErrorPortAllocation、Azure SNAT Connection Count 的 Failed、Google Cloud dropped_sent_packets_count 的 OUT_OF_RESOURCES）；Google Cloud NAT 调大每台 VM 的最小端口数，或改用动态端口分配。
数值参考 AWS NAT 网关每个 IP 地址对同一目的地（IP、端口、协议）最多可建立 5.5 万个并发连接，最多可关联 8 个 IP 来扩展。350 秒没有数据的连接会被清除，之后再通过这个连接发送的数据包会收到 RST。Azure NAT Gateway 每个公网 IP 有 64,512 个 SNAT 端口（最多 16 个 IP）。Google Cloud NAT 把每个 NAT IP 的 64,512 个端口分给各台 VM，而每台 VM 的最小端口数默认为 64 个（静态分配），所以在默认设置下，一台 VM 向同一目的地同时能建立的连接通常被限制在 64 个。
监控图上 查看位置 AWS 看 CloudWatch 的 NAT 网关指标 ErrorPortAllocation、ActiveConnectionCount、PacketsDropCount（Azure 看按 Failed 状态筛选的 SNAT Connection Count 和 Dropped Packets，Google Cloud 看 dropped_sent_packets_count 中 reason 为 OUT_OF_RESOURCES 的值），与游戏服务器外部调用失败的时刻对照 确认依据 外部调用失败的时刻 ErrorPortAllocation（Azure 为 Failed 状态的 SNAT Connection Count，Google Cloud 为 OUT_OF_RESOURCES 丢弃）大于 0，且失败集中在发往认证、支付服务器这类连接密集的一两个目的地的调用上 排除依据 端口分配失败为 0，而游戏服务器的 connect 以 EADDRNOTAVAIL 失败、TIME_WAIT 数接近临时端口范围，看“服务器间连接的临时端口耗尽”。能连上只是响应慢，看“依赖外部服务” 确认手段 运维工具即可确认（无需游戏代码）
深入了解 “服务器间连接的临时端口耗尽”是单台服务器的临时端口用光；这里的上限卡在 NAT 网关上，由网关后面的服务器共用（Google Cloud NAT 按 VM 分配）。服务器侧的 TIME_WAIT 和临时端口范围都还有余量，却只有外部调用失败，就是这个原因。已关闭连接的端口也不会马上再用于同一目的地（Azure 有冷却期，Google Cloud 在 TIME_WAIT 期间不可用），所以短连接重复得越多，越快碰到上限。
出处 NAT gateway basics AWS 每个 IPv4 地址对同一目的地（目的 IP、端口、协议）可建立 5.5 万个并发连接，最多关联 8 个 IP 来扩展（公有 NAT 网关的弹性 IP 默认 2 个，申请提高配额后可增加）；带宽从 5 Gbps 自动扩展到 100 Gbps，处理能力从每秒 100 万个包自动扩展到 1,000 万个包，超出上限则丢弃 NAT gateway metrics and dimensions AWS ErrorPortAllocation：无法分配源端口的次数（大于 0 表示并发连接过多），ActiveConnectionCount，IdleTimeoutCount（因空闲 350 秒被清理的连接），PacketsDropCount Troubleshoot NAT gateways AWS 空闲 350 秒后连接过期，之后再发送会收到 RST；建议 keepalive 间隔短于 350 秒；碰到连接上限时按可用区部署网关、增加 IP、减少连接数 Source Network Address Translation (SNAT) with Azure NAT Gateway Microsoft Azure 每个公网 IP 有 64,512 个 SNAT 端口（最多 16 个 IP），发往同一目的地的每个连接都需要不同的端口，已关闭的端口要经过冷却期才能再用于同一目的地 Metrics and alerts for Azure NAT Gateway Microsoft Azure 按 Failed 状态筛选的 SNAT Connection Count 大于 0 时，可能是 SNAT 端口耗尽；Dropped Packets IP addresses and ports Google Cloud 每个 NAT IP 的 TCP、UDP 各有 64,512 个端口；每台 VM 的最小端口数默认 64（静态分配）、32（动态分配）；为 VM 预留的端口数限制了它到同一目的地的并发连接数；已关闭的连接在 TIME_WAIT 期间不能复用 Logs and metrics Google Cloud dropped_sent_packets_count 的 reason 为 OUT_OF_RESOURCES：因 NAT IP 或端口不足而丢弃的数据包 相关原因
同一层：L5 数据中心网络设备
其他层中同样导致“连不上/无限加载”的原因
查看含图示和实验的原卡片