# nat高峰期的检查 从你贴出的数据来看，可以得出几个比较明确的结论。 # 1. 当前根本不在业务高峰期 你采集时： ```text 物理10G网卡： 183738 Bytes/sec ``` 换算： ```text 183738 × 8 ≈ 1.47 Mbps ``` 不到 2Mbps。 而 Hyper-V 虚拟交换机： ```text 1903091 Bytes/sec ``` 换算： ```text 1903091 × 8 ≈ 15.2 Mbps ``` 仍然非常低。 对于万兆网： ```text 10 Gbps = 10000 Mbps ``` 当前利用率： ```text 15 / 10000 = 0.15% ``` 几乎空闲。 因此这些数据只能说明： ```text 采集时服务器负载极低 ``` 无法反映晚高峰状态。 --- # 2. 203个TCP连接完全正常 宿主机： ```powershell Get-NetTCPConnection | Group-Object State ``` 结果： ```text Established : 24 Listen : 110 TimeWait : 37 ``` 说明： ### 宿主机自身压力极低 24个已建立连接基本属于： - RDP - DNS - Hyper-V管理 - SMB - 监控 级别。 所以： ```text 宿主机没有TCP连接压力 ``` --- # 3. 60万NAT会话不在宿主机 从你的拓扑看： ```text Hyper-V ├─ OpenClash ├─ Ubuntu ├─ RULR ├─ MongoDB ├─ MySQL └─ ... ``` 你以前提到： ```text 60万 NAT Session ``` 如果真达到： ```text 600000+ ``` 那么一定在某台VM内部。 因为宿主机看到的： ```text Established 24 ``` 根本不可能对应60万会话。 --- # 4. 真正应该监控什么 对于你的场景： ```text Windows Server 2025 Hyper-V 40台VM 万兆交换机 ``` 最有价值的指标不是： ```powershell Get-NetTCPConnection ``` 而是： ### PPS 每秒包数 查看： ```powershell Get-Counter '\Network Interface(*)\Packets Received/sec' Get-Counter '\Network Interface(*)\Packets Sent/sec' ``` --- ### VMQ队列 查看： ```powershell Get-NetAdapterVmq ``` --- ### CPU中断 查看： ```powershell Get-Counter '\Processor Information(*)\% Interrupt Time' ``` --- ### DPC延迟 查看： ```powershell Get-Counter '\Processor Information(*)\% DPC Time' ``` --- # 5. 你这个环境最大的风险是什么 其实不是端口数。 你已经改成： ```text 1025-65535 64511个动态端口 ``` 够用了。 真正需要关注的是： ### Intel 82599 这是非常经典的万兆卡。 但： ```text 82599 不支持 VMMQ ``` 只支持： ```text RSS VMQ SR-IOV ``` 不支持新一代： ```text VMMQ vRSS增强 ``` 所以当： ```text 30~40台虚拟机 数十万连接 ``` 同时跑时， 瓶颈往往出现在： ```text CPU中断 VMQ队列 ``` 而不是TCP端口。 --- # 6. 建议晚高峰采集 晚上业务高峰时执行： ```powershell Get-NetAdapterStatistics ``` 记录一次。 然后间隔30秒： ```powershell Get-NetAdapterStatistics ``` 再记录一次。 我帮你计算： ```text 实际吞吐量 PPS 单包大小 ``` 就能判断： - 是否接近82599极限 - 是否出现小包风暴 - 是否需要开启SR-IOV - 是否需要升级到X710/X550/E810 --- # 7. 你的当前状态 根据目前所有输出：
项目状态
TCP动态端口正常
UDP动态端口正常
AutoTuning正常
RSS已开启
Hyper-V vRSS已开启
宿主机连接数极低
万兆网利用率极低
NAT会话压力不在宿主机
TCP参数瓶颈未发现
网络瓶颈未发现
因此目前可以确定： ```text Get-NetTCPConnection | Measure-Object 得到的203 只能代表宿主机自身连接数 与虚拟机里的60万NAT会话没有直接关系 ``` 如果要评估那 60 万 NAT 会话对宿主机的影响，需要在晚高峰时采集 VM 所在虚拟交换机的 PPS、吞吐量和 CPU 中断数据，而不是看 TCP 连接数。 [![图片.png](https://bost.lesrec.cn/uploads/images/gallery/2026-06/scaled-1680-/fgIowUYnxKXPDxqh-EpNzZubwSv.png)](https://bost.lesrec.cn/uploads/images/gallery/2026-06/fgIowUYnxKXPDxqh-EpNzZubwSv.png) 从你提供的 Ubuntu NAT 虚拟机数据来看，目前距离系统极限还非常远。 ### 当前参数 #### 1. 本地动态端口范围 ```bash cat /proc/sys/net/ipv4/ip_local_port_range 1024 65000 ``` 可用端口数： ```text 65000 - 1024 + 1 = 63977 个 ``` 已经接近 Linux 推荐最大范围。 --- #### 2. 当前 conntrack 会话数 ```bash conntrack -C 26223 ``` 即： ```text 26223 个连接跟踪项 ``` --- #### 3. conntrack 上限 ```bash cat /proc/sys/net/netfilter/nf_conntrack_max 1048576 ``` 即： ```text 1048576 个 ≈ 104万 ``` --- ### 使用率计算 ```text 26223 / 1048576 ≈ 2.5% ``` 仅使用了： ```text 2.5% ``` 还有： ```text 97.5% ``` 剩余空间。 --- ## 结论一：当前不存在 conntrack 瓶颈 如果系统因为 conntrack 满而出问题，会出现： ```bash dmesg | grep conntrack ``` 类似： ```text nf_conntrack: table full, dropping packet ``` 而你目前： ```text 26223 / 1048576 ``` 差距巨大。 --- ## 结论二：当前不存在 Linux 端口耗尽 Linux NAT 最容易碰到的是： ```text 源IP固定 + 端口耗尽 ``` 因为： ```text 一个公网IP 最多约64000个源端口 ``` 你当前： ```text 端口范围 1024~65000 ≈63977个端口 ``` 已经足够大。 --- ### 理论极限 如果： ```text 1个公网IP ``` 进行 SNAT： ```text 10.1.1.1:50001 10.1.1.1:50002 ... ``` 理论最多： ```text 63977 个并发连接 ``` 到同一个目标IP:PORT。 --- ### 但 conntrack 有 104 万 为什么还能支持几十万连接？ 因为： ```text 不同目标IP 不同目标端口 ``` 可以复用源端口。 例如： ```text 1.1.1.1:443 8.8.8.8:443 114.114.114.114:443 ``` 即使源端口相同也没问题。 conntrack 是按五元组区分的： ```text 源IP 源端口 目的IP 目的端口 协议 ``` --- ## 如果你说高峰期有 60 万 NAT 会话 那么我建议高峰期查看： ### 查看实时 conntrack ```bash watch -n 1 'conntrack -C' ``` 或者： ```bash while true do date conntrack -C sleep 5 done ``` --- ### 查看 conntrack 使用率 ```bash echo $(( $(conntrack -C) * 100 / $(cat /proc/sys/net/netfilter/nf_conntrack_max) )) ``` --- ### 查看连接状态 ```bash conntrack -S ``` 重点看： ```text insert insert_failed drop early_drop ``` 如果： ```text insert_failed > 0 ``` 说明 conntrack 已经开始吃紧。 --- ### 查看 TCP 状态分布 ```bash ss -ant | awk '{print $1}' | sort | uniq -c ``` 或者： ```bash ss -s ``` 重点看： ```text ESTAB TIME-WAIT SYN-RECV ``` --- ## 需要特别关注的一点 你前面提到： ```text 2台 Windows Server 2025 Hyper-V 40台虚拟机 大量数据交互 ``` 如果承担 NAT 的是 Ubuntu 虚拟机，那么真正需要监控的不是： ```text Windows 动态端口 ``` 而是： ```text nf_conntrack_count nf_conntrack_max CPU softirq 网卡 PPS TIME_WAIT 数量 SYN_RECV 数量 ``` 因为在大规模 NAT 场景中，最先出问题的通常是： ```text CPU软中断 > conntrack > 端口范围 ``` 而不是 Windows 宿主机的动态端口。 建议在晚上业务高峰时再执行下面这一组命令： ```bash date uptime conntrack -C cat /proc/sys/net/netfilter/nf_conntrack_max ss -s cat /proc/sys/net/ipv4/ip_local_port_range sar -n DEV 1 5 mpstat -P ALL 1 5 ``` 从这些数据基本可以准确判断： - 是否接近 60 万会话； - 是否存在 conntrack 压力； - 是否出现 CPU softirq 瓶颈； - 是否需要继续扩大 conntrack 或优化 NAT 架构。