nat高峰期的检查

从你贴出的数据来看，可以得出几个比较明确的结论。

1. 当前根本不在业务高峰期

你采集时：

物理10G网卡：
183738 Bytes/sec

换算：

183738 × 8 ≈ 1.47 Mbps

不到 2Mbps。

而 Hyper-V 虚拟交换机：

1903091 Bytes/sec

换算：

1903091 × 8 ≈ 15.2 Mbps

仍然非常低。

对于万兆网：

10 Gbps = 10000 Mbps

当前利用率：

15 / 10000 = 0.15%

几乎空闲。

因此这些数据只能说明：

采集时服务器负载极低

无法反映晚高峰状态。

---

2. 203个TCP连接完全正常

宿主机：

Get-NetTCPConnection | Group-Object State

结果：

Established : 24
Listen      : 110
TimeWait    : 37

说明：

宿主机自身压力极低

24个已建立连接基本属于：

• RDP

• DNS

• Hyper-V管理

• SMB

• 监控

级别。

所以：

宿主机没有TCP连接压力

---

3. 60万NAT会话不在宿主机

从你的拓扑看：

Hyper-V
 ├─ OpenClash
 ├─ Ubuntu
 ├─ RULR
 ├─ MongoDB
 ├─ MySQL
 └─ ...

你以前提到：

60万 NAT Session

如果真达到：

600000+

那么一定在某台VM内部。

因为宿主机看到的：

Established 24

根本不可能对应60万会话。

---

4. 真正应该监控什么

对于你的场景：

Windows Server 2025
Hyper-V
40台VM
万兆交换机

最有价值的指标不是：

Get-NetTCPConnection

而是：

PPS

每秒包数

查看：

Get-Counter '\Network Interface(*)\Packets Received/sec'
Get-Counter '\Network Interface(*)\Packets Sent/sec'

---

VMQ队列

查看：

Get-NetAdapterVmq

---

CPU中断

查看：

Get-Counter '\Processor Information(*)\% Interrupt Time'

---

DPC延迟

查看：

Get-Counter '\Processor Information(*)\% DPC Time'

---

5. 你这个环境最大的风险是什么

其实不是端口数。

你已经改成：

1025-65535
64511个动态端口

够用了。

真正需要关注的是：

Intel 82599

这是非常经典的万兆卡。

但：

82599 不支持 VMMQ

只支持：

RSS
VMQ
SR-IOV

不支持新一代：

VMMQ
vRSS增强

所以当：

30~40台虚拟机
数十万连接

同时跑时，

瓶颈往往出现在：

CPU中断
VMQ队列

而不是TCP端口。

---

6. 建议晚高峰采集

晚上业务高峰时执行：

Get-NetAdapterStatistics

记录一次。

然后间隔30秒：

Get-NetAdapterStatistics

再记录一次。

我帮你计算：

实际吞吐量
PPS
单包大小

就能判断：

• 是否接近82599极限

• 是否出现小包风暴

• 是否需要开启SR-IOV

• 是否需要升级到X710/X550/E810

---

7. 你的当前状态

根据目前所有输出：

项目	状态
TCP动态端口	正常
UDP动态端口	正常
AutoTuning	正常
RSS	已开启
Hyper-V vRSS	已开启
宿主机连接数	极低
万兆网利用率	极低
NAT会话压力	不在宿主机
TCP参数瓶颈	未发现
网络瓶颈	未发现

因此目前可以确定：

Get-NetTCPConnection | Measure-Object
得到的203
只能代表宿主机自身连接数

与虚拟机里的60万NAT会话没有直接关系

如果要评估那 60 万 NAT 会话对宿主机的影响，需要在晚高峰时采集 VM 所在虚拟交换机的 PPS、吞吐量和 CPU 中断数据，而不是看 TCP 连接数。