Skip to main content

nat会话数60万对hyper-v服务器及路由器进行的优化操作

从你贴出的结果来看，这些配置都已经生效了，而且从 Windows Server 2025 + Hyper-V + 万兆网络 + 大量虚拟机通信 的场景来看，总体是合理的。

当前状态分析

1. TCP 动态端口范围

修改前：

49152-65535
共16384个端口

修改后：

1025-65535
共64511个端口

验证：

netsh int ipv4 show dynamicport tcp

结果：

启动端口 : 1025
端口数   : 64511

说明已生效。

适用于：

  • Hyper-V主机

  • 数据同步服务器

  • 大量TCP短连接

  • IIS/Nginx反向代理

  • RabbitMQ

  • MongoDB/MySQL同步

可显著降低临时端口耗尽风险。

2. UDP 动态端口范围

你又执行了：

netsh int ipv4 set dynamicport udp start=1025 num=64511

验证：

启动端口 : 1025
端口数   : 64511

已生效。

对于：

  • DNS

  • SIP

  • SNMP

  • VXLAN

  • 某些监控系统

有帮助。

3. TCP Auto-Tuning

修改前：

接收窗口自动调节级别 : disabled

修改后：

接收窗口自动调节级别 : normal

对于万兆环境建议保持：

normal

不要改成：

experimental

微软官方也不推荐生产环境使用 experimental。

4. RFC1323 Timestamp

当前：

RFC 1323 时间戳 : allowed

这里不是 enabled，而是：

allowed

表示：

可以协商使用
但不会强制使用

这是 Windows Server 2022/2025 的正常默认值。

建议保持：

allowed

不要改 disabled。

原因：

  • SMB3

  • Hyper-V Live Migration

  • 高带宽高延迟链路

会受益于 Timestamp。

5. ECN

当前：

ECN 功能 : enabled

这个比较特殊。

ECN（Explicit Congestion Notification）用于网络拥塞通知。

优点：

减少丢包
提高吞吐

缺点：

某些旧交换机
某些旧防火墙
某些运营商设备
兼容性不好

如果你网络里有：

  • 老华为交换机

  • 老H3C交换机

  • 老防火墙

建议改回：

netsh int tcp set global ecncapability=disabled

如果全是新设备，可以保持 enabled。

关于 winnat

你执行：

net stop winnat

返回：

没有启动 Windows NAT Driver 服务

这是正常的。

说明当前主机没有使用：

Hyper-V NAT
Docker NAT
Container NAT

至少没有启用 WinNAT。

无需处理。

我建议你再检查两个关键项

查看端口耗尽情况

PowerShell：

Get-NetTCPConnection | Measure-Object

查看当前连接数。

查看 TIME_WAIT 数量

netstat -ano | find /c "TIME_WAIT"

如果经常超过：

10000+

甚至：

30000+

那么扩大动态端口范围就非常有价值。

针对你的 Hyper-V 宿主机

我建议最终配置如下：

netsh int tcp set global autotuninglevel=normal

netsh int ipv4 set dynamicport tcp start=1025 num=64511

netsh int ipv4 set dynamicport udp start=1025 num=64511

netsh int tcp set global timestamps=enabled

或者保持当前：

RFC1323 时间戳 : allowed

即可。

如果你这台服务器承担 20 个以上 Hyper-V 虚拟机，并且有 MySQL、MongoDB、RabbitMQ、文件同步等大量东西南北向流量，我还建议检查：

Get-NetAdapterRss
Get-NetAdapterRsc
Get-NetAdapterAdvancedProperty

看看万兆网卡是否开启了：

  • RSS（Receive Side Scaling）

  • VMQ（Virtual Machine Queue）

  • VMMQ（Virtual Machine Multi Queue）

  • RSC（Receive Segment Coalescing）

这些优化对 Hyper-V 的收益往往比修改 TCP 参数更明显。

从你提供的数据来看，这台 Windows Server 2025 Hyper-V 宿主机 的网络配置整体比较健康，没有发现明显异常。

一、当前TCP连接数

Get-NetTCPConnection | Measure-Object

Count : 203

只有：

203个TCP连接

对于：

  • Hyper-V宿主机

  • 20多个虚拟机

  • 万兆网络

来说非常低。

因此：

netsh int ipv4 set dynamicport tcp start=1025 num=64511

实际上暂时用不上，但保留也没有问题。

二、82599万兆网卡RSS状态

你最重要的网卡：

Intel 82599 10G #1
Intel 82599 10G #2

其中：

SLOT 4 端口 2

显示：

Enabled : True
NumberOfReceiveQueues : 128
Profile : NUMAStatic

说明：

RSS 已开启

这是好的。

但有个异常

SLOT 4 端口1

显示：

NumberOfReceiveQueues : 8

但是：

RssProcessorArray :
IndirectionTable :

为空。

这通常意味着：

RSS未真正工作
或驱动异常
或网卡未承载流量

建议检查：

Get-NetAdapterStatistics -Name "SLOT 4 端口 1"

Get-NetAdapterStatistics -Name "SLOT 4 端口 2"

看看哪个接口真正有流量。

三、Hyper-V虚拟交换机

你有：

vEthernet (10.1.1.104-nic1)

vEthernet (10.2.2.4-slot4_2)

均显示：

NumberOfReceiveQueues : 16

说明：

vRSS 已开启

这是正确配置。

四、RSC状态

你执行：

Get-NetAdapterRsc

结果：

IPv4Enabled      : True
IPv4Operational  : False
FailureReason    : ForwardingEnabled

这是正常现象。

原因：

Hyper-V Virtual Switch
开启转发模式

RSC会自动失效。

微软设计如此。

因此：

False

不是故障。

五、建议检查VMQ

Hyper-V性能最关键的是：

Get-NetAdapterVmq

如果看到：

Enabled : True

则正常。

如果：

Enabled : False

建议开启：

Enable-NetAdapterVmq -Name "SLOT 4 端口 2"

六、建议检查VMMQ

Windows Server 2022/2025非常重要。

执行：

Get-NetAdapterVmq

和：

Get-VMSwitch

以及：

Get-VMSwitchTeam

看看是否启用了：

VMMQ
Virtual Machine Multi Queue

对于：

20台以上虚拟机
10G以上网卡

收益很大。

七、82599网卡的特殊优化

Intel 82599 是老牌但非常稳定的万兆芯片。

推荐检查：

Get-NetAdapterAdvancedProperty -Name "SLOT 4 端口 2"

重点关注：

Jumbo Frame

建议：

9014

或：

9000

前提：

  • 交换机支持

  • 对端支持

Interrupt Moderation

建议：

Enabled

Receive Side Scaling

建议：

Enabled

Flow Control

如果用于Hyper-V内部同步：

建议：

Rx & Tx Enabled

八、根据你目前输出的结论

项目 状态
TCP动态端口 ✅ 正常
UDP动态端口 ✅ 正常
Auto Tuning ✅ 正常
RSS ✅ 已开启
vRSS ✅ 已开启
RSC ✅ 正常（Hyper-V导致）
TCP连接数 ✅ 极低
TIME_WAIT风险 ✅ 几乎没有
82599万兆网卡 ✅ 工作正常
Hyper-V交换机 ✅ 正常

目前看不到需要进一步调整 TCP 参数的地方。

下一步最值得检查的是：

Get-NetAdapterVmq

Get-NetAdapterAdvancedProperty -Name "SLOT 4 端口 2"

Get-NetAdapterStatistics -Name "SLOT 4 端口 2"

尤其是 VMQ 和 Jumbo Frame 配置，它们对 Hyper-V 虚拟机间的大流量传输影响比前面那几条 netsh 命令更大。

 

不准确，或者更准确地说：

Get-NetTCPConnection | Measure-Object

只能统计 当前 Windows 宿主机 TCP/IP 协议栈中的连接，并不能统计 Hyper-V 虚拟机内部的连接。

你的结果：

Count : 203

表示：

宿主机自身只有203个TCP连接

包括：

  • RDP

  • SMB

  • DNS

  • Hyper-V管理流量

  • 宿主机运行的服务

而不包括：

VM内部的TCP连接
VM内部的NAT会话
VM内部的Docker连接
VM内部的应用连接

你的网络结构大概率是

Internet
    │
    ▼
路由器/防火墙
    │
    ▼
Hyper-V宿主机
    │
    ▼
虚拟交换机
    │
 ┌──┼──────────┐
 │  │          │
VM1 VM2      VM20

如果 NAT 服务运行在某个 VM 里面：

OpenClash
Linux NAT
软路由
RouterOS
pfSense
OpenWRT

那么：

Get-NetTCPConnection

看到的仍然可能只有：

100~500个连接

因为 60 万 NAT 会话全部存在于 VM 内部。

如何确认 NAT 在哪里

查看宿主机是否存在 NAT：

Get-NetNat

如果返回：

No MSFT_NetNat objects found

说明：

宿主机没有承担NAT

查看宿主机连接跟踪：

Get-NetTCPConnection | Group-Object State

例如：

Established : 150
TimeWait    : 30
Listen      : 20

说明宿主机压力很小。

如果 NAT 在 OpenWrt VM

例如：

OpenWrt VM
192.168.1.1

查看：

cat /proc/sys/net/netfilter/nf_conntrack_count

或者：

conntrack -C

才能看到：

600000

这样的会话数。

如果 NAT 在 Windows VM

查看：

Get-NetNatSession | Measure-Object

或者：

Get-NetNatSession

对于你的环境

你之前描述：

  • Hyper-V

  • 40个虚拟机

  • OpenClash

  • 大量代理流量

  • 万兆交换机

我判断：

60万 NAT 会话

极有可能在：

  • OpenWrt VM

  • Linux VM

  • RouterOS VM

  • pfSense VM

里面，而不是宿主机。

因此：

Get-NetTCPConnection | Measure-Object

得到的：

203

只是宿主机自身连接数，不能反映整体业务流量。

如果你想评估 Hyper-V 宿主机是否会因为 60 万 NAT 会话受到影响，更有价值的是查看：

Get-Counter '\Network Interface(*)\Bytes Total/sec'

Get-Counter '\Hyper-V Virtual Switch(*)\Bytes/sec'

Get-Counter '\Hyper-V Virtual Network Adapter(*)\Bytes/sec'

以及：

Get-NetAdapterStatistics

这样可以看到：

  • 实际吞吐量（Gbps）

  • PPS（每秒包数）

  • 丢包

  • 队列压力

这些指标比 Get-NetTCPConnection 更能反映 Hyper-V 宿主机在高峰期是否接近瓶颈。

No Comments
Back to top