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 连接数。

从你提供的 Ubuntu NAT 虚拟机数据来看，目前距离系统极限还非常远。

当前参数

1. 本地动态端口范围

cat /proc/sys/net/ipv4/ip_local_port_range

1024    65000

可用端口数：

65000 - 1024 + 1
= 63977 个

已经接近 Linux 推荐最大范围。

---

2. 当前 conntrack 会话数

conntrack -C

26223

即：

26223 个连接跟踪项

---

3. conntrack 上限

cat /proc/sys/net/netfilter/nf_conntrack_max

1048576

即：

1048576 个
≈ 104万

---

使用率计算

26223 / 1048576

≈ 2.5%

仅使用了：

2.5%

还有：

97.5%

剩余空间。

---

结论一：当前不存在 conntrack 瓶颈

如果系统因为 conntrack 满而出问题，会出现：

dmesg | grep conntrack

类似：

nf_conntrack: table full, dropping packet

而你目前：

26223 / 1048576

差距巨大。

---

结论二：当前不存在 Linux 端口耗尽

Linux NAT 最容易碰到的是：

源IP固定
+
端口耗尽

因为：

一个公网IP
最多约64000个源端口

你当前：

端口范围

1024~65000

≈63977个端口

已经足够大。

---

理论极限

如果：

1个公网IP

进行 SNAT：

10.1.1.1:50001
10.1.1.1:50002
...

理论最多：

63977 个并发连接

到同一个目标IP:PORT。

---

但 conntrack 有 104 万

为什么还能支持几十万连接？

因为：

不同目标IP
不同目标端口

可以复用源端口。

例如：

1.1.1.1:443
8.8.8.8:443
114.114.114.114:443

即使源端口相同也没问题。

conntrack 是按五元组区分的：

源IP
源端口
目的IP
目的端口
协议

---

如果你说高峰期有 60 万 NAT 会话

那么我建议高峰期查看：

查看实时 conntrack

watch -n 1 'conntrack -C'

或者：

while true
do
    date
    conntrack -C
    sleep 5
done

---

查看 conntrack 使用率

echo $(( $(conntrack -C) * 100 / $(cat /proc/sys/net/netfilter/nf_conntrack_max) ))

---

查看连接状态

conntrack -S

重点看：

insert
insert_failed
drop
early_drop

如果：

insert_failed > 0

说明 conntrack 已经开始吃紧。

---

查看 TCP 状态分布

ss -ant | awk '{print $1}' | sort | uniq -c

或者：

ss -s

重点看：

ESTAB
TIME-WAIT
SYN-RECV

---

需要特别关注的一点

你前面提到：

2台 Windows Server 2025
Hyper-V
40台虚拟机
大量数据交互

如果承担 NAT 的是 Ubuntu 虚拟机，那么真正需要监控的不是：

Windows 动态端口

而是：

nf_conntrack_count
nf_conntrack_max

CPU softirq

网卡 PPS

TIME_WAIT 数量

SYN_RECV 数量

因为在大规模 NAT 场景中，最先出问题的通常是：

CPU软中断
>
conntrack
>
端口范围

而不是 Windows 宿主机的动态端口。

建议在晚上业务高峰时再执行下面这一组命令：

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 架构。