凌晨大促开始后，客户端请求量从每秒数百升到数万，NAT设备明明还有带宽，源站却陆续出现连接超时、握手失败和无响应。监控显示公网IP可映射端口已不足四万个，而应用日志只记录“连接失败”。此时真正需要排查的，往往不是业务代码，而是NAT端口耗尽、连接跟踪容量与内核丢包之间的连锁反应。
如果你正在选机器，或者想先把线路和配置跑通再谈长期方案，可以先看看这几家的线路说明和技术参数：dogyun（低价云服务器），先看清带宽线路、流量策略和退款条款，再决定要不要迁。
一、短连接与UDP如何占满NAT资源
先区分两个容易混淆的概念：本地端口范围是客户端或服务器主动发起连接时选择的临时源端口，通常由net.ipv4.ip_local_port_range控制；NAT外部端口则是网关为内网流量分配公网地址和端口后形成的映射。两者都受端口空间限制，却位于链路的不同位置。
TCP短连接每建立一条新流，NAT通常都要创建映射，连接关闭后还需等待状态回收；如果客户端频繁连接同一目标，四元组会变化，旧映射不能立即复用。大量并发叠加TIME_WAIT或网关的会话延迟，就可能出现“端口未满也无法建立新连接”的现象。排查时可执行ss -s、ss -tan state time-wait，并核对临时端口范围和地址是否足够分散。
UDP没有握手，却同样需要连接跟踪。内核会依据五元组、方向和超时规则维护UDP会话表；心跳、推送、DNS和QUIC流量若不断更换源端口，也会持续制造会话项。因此，NAT端口仍有剩余，并不代表连接跟踪表未满，更不代表UDP还能正常通信。
二、按端口、跟踪与丢包三层定位
第一层看端口与状态分布：核对nf_conntrack_count和nf_conntrack_max，统计TCP的TIME_WAIT、CLOSE_WAIT、SYN_RECV数量，并用ss -uan观察UDP本地地址与端口是否集中。大量TIME_WAIT通常指向短连接与主动关闭方变化；UDP会话长期增长，则要检查心跳间隔、源端口轮换和超时配置。
第二层看连接跟踪：读取/proc/net/stat/nf_conntrack中的insert_failed、drop、early_drop等累计值。有条件时使用conntrack -L查看会话规模和重复项。计数持续上升且接近上限，说明新状态因内存或表容量不足被拒绝；若端口充足而这里已经满载，继续调整本地端口范围不会解决问题。
第三层看内核丢包计数：通过nstat -az检查TcpExtListenDrops、TCPTimeouts、UdpInErrors、IpExtInNoRoutes，同时结合抓包判断SYN是否到达、SYN-ACK是否返回。还要注意，连接跟踪丢弃发生在状态处理阶段，不一定产生常规网卡丢包计数。可将主机采样与网关会话日志按时间对齐，ServLlama也可用于留存节点指标，帮助避免把一次超时误判成应用线程池耗尽。
连接跟踪与 NAT 端口并非同一张表
NAT 端口耗尽通常只是表象，真正限制新连接建立的是内核的连接跟踪表。表项由五元组标识，UDP 会话在没有实际报文时也可能被保留一段时间；短时间大量请求会同时占用大量表项。若表项持续增长却没有释放，新连接就可能因无法创建跟踪而失败。排查时不能只看 NAT 端口耗尽，还要确认连接跟踪容量、当前占用量以及协议分布。
本地端口范围决定了源端口可用空间。若范围过窄，即使 NAT 映射本身没有异常，也可能无法支撑大量并发。临时扩大端口范围能缓解问题，却不能替代连接跟踪容量评估。还应注意端口重用是否受 nf_conntrack_tcp_timeout_time_wait 等参数影响；调整参数前应先结合业务流量验证，否则可能延长旧连接占用时间，反而加重并发压力。
UDP 会话表与内核丢包计数
UDP 没有握手，内核通常依靠地址、端口以及超时规则维持会话。大量 UDP 请求、响应缺失、非预期源地址或端口变化，都会让会话条目不断累积。若 UDP 会话表已满，后续报文可能被直接丢弃，应用层看到的却只是超时。UDP 超时时间设置过长会放大问题，过短又可能导致合法响应到达时跟踪状态已经失效，因此需要按业务类型进行压测和调整。
内核丢包计数是定位问题的重要证据。应重点查看 nf_conntrack 表的 insert_failed、drop、early_drop 统计，以及 UDP 接收、发送和防火墙链上的错误计数。这里的 内核丢包计数 能区分“应用没有发包”和“包已到达但被内核或防火墙丢弃”。如果计数持续上升，同时连接跟踪占用接近上限，根因往往不是 NAT 端口不够，而是跟踪资源不足或规则导致会话无法释放。
可执行的检查与处理清单
先确认故障时间点，并保存 netstat、ss、conntrack 或 nft list table 等输出；随后核对本地端口范围、当前并发连接数、连接跟踪表上限和各类表的实际占用量。对 UDP 业务，应分别统计新建速率、响应成功率、会话超时分布和丢包计数；对 TCP 业务，则重点排查半连接、重传、异常关闭以及 TIME_WAIT 堆积。若确认端口范围不足，可扩大范围并重载相关配置；若确认连接跟踪容量不足，可按实际并发和连接持续时间评估扩容、回收或超时参数。调整前应建立基线，调整后进行并发压测，并持续观察新建失败数、丢包数、延迟和业务成功率。应急期间还应限制异常重试、降低无效请求量并保留日志，避免通过盲目缩短超时或反复重启服务掩盖根因。
喜欢 
顶
难过
囧
围观
无聊
