nat网关容量需综合并发连接数、新建连接速率、端口分配能力、eip数量及conntrack水位五项指标；默认支持200万并发连接/分钟、10万新建连接/秒，超85%水位即触发丢包；eip数量按ceil(峰值并发×冗余系数÷60000)估算；conntrack内存占用约1–2kb/连接；带宽能力依赖连接分散度。
nat 网关的负载承受能力不能只看“能跑多大带宽”，关键得结合连接状态、资源消耗和业务模型来综合判断。实际压测或容量规划时，必须同时盯住并发连接数、新建连接速率、端口分配能力、eip数量与连接跟踪表水位这五个硬指标。
并发连接数与新建连接速率是核心瓶颈点
单个公网NAT网关实例默认支持：
- 每分钟最多 200 万并发连接（即连接跟踪表容量）
- 每秒最多 10 万新建连接（TCP/UDP SYN 到 ESTABLISHED 的建立速率）
当监控中“并发连接水位”持续高于 85%，或“新建连接水位”频繁触顶，说明连接表已逼近极限。此时即使带宽空闲，也会出现连接丢弃、端口分配失败（端口分配失败丢失数持续增长）。
EIP 数量直接影响 SNAT 端口供给能力
每个弹性公网IP（EIP）在 SNAT 场景下可提供约 6.4 万个可用端口（65535 - 1024）。若大量客户端访问同一目的地址（如调用同一个 API 域名），所有连接会复用同一条 SNAT 映射，极易耗尽单个 EIP 的端口。
建议按以下公式粗估所需 EIP 数量：
EIP 数 ≥ ceil(（峰值并发连接数 × 1.2） ÷ 60000)
其中 1.2 是冗余系数；若业务存在突发性短连接（如 HTTP 轮询），应进一步上浮至 1.5～2.0。
连接跟踪表（conntrack）与系统资源强相关
每条活跃连接在内核 conntrack 表中占用约 1–2 KB 内存。65 万连接 ≈ 占用 1–1.3 GB 非分页内存。Windows NAT 或 Linux 自建方案中，若 nf_conntrack_count 接近 nf_conntrack_max，或 NatConnTrackTableFull 计数器持续上升，就会触发连接丢弃。
对应优化动作包括：
- 缩短非关键协议空闲超时（如 UDP 设为 120 秒，TCP ESTABLISHED 设为 300 秒）
- 关闭不用的协议转换（如禁用 IPv6 NAT）
- 避免让 NAT 网关处理 ICMP（Azure NAT 明确不支持 ping）
带宽不是独立维度，需匹配连接行为
NAT 网关的吞吐能力依赖连接分散度。例如：
- 单条 TCP 连接跑满 1 Gbps，但只占 1 个连接槽位 → 对新建/并发压力极小，但可能受单节点转发能力限制
- 10 万条并发连接各跑 100 Kbps → 新建速率和连接表压力拉满，更易触发限速或丢包
云厂商 NAT（如阿里云、Azure StandardV2）采用分布式转发架构，实际带宽能力随连接数自动弹性伸缩，但前提是流量能均匀打到多个转发节点——这就要求源 IP 和目的 IP 组合尽量离散。
不复杂但容易忽略
