# nat会话数60万对hyper-v服务器及路由器进行的优化操作 从你贴出的结果来看，这些配置都已经生效了，而且从 **Windows Server 2025 + Hyper-V + 万兆网络 + 大量虚拟机通信** 的场景来看，总体是合理的。 ### 当前状态分析 #### 1. TCP 动态端口范围 修改前： ```text 49152-65535 共16384个端口 ``` 修改后： ```text 1025-65535 共64511个端口 ``` 验证： ```cmd netsh int ipv4 show dynamicport tcp ``` 结果： ```text 启动端口 : 1025 端口数 : 64511 ``` 说明已生效。 适用于： - Hyper-V主机 - 数据同步服务器 - 大量TCP短连接 - IIS/Nginx反向代理 - RabbitMQ - MongoDB/MySQL同步 可显著降低临时端口耗尽风险。 --- #### 2. UDP 动态端口范围 你又执行了： ```cmd netsh int ipv4 set dynamicport udp start=1025 num=64511 ``` 验证： ```text 启动端口 : 1025 端口数 : 64511 ``` 已生效。 对于： - DNS - SIP - SNMP - VXLAN - 某些监控系统 有帮助。 --- #### 3. TCP Auto-Tuning 修改前： ```text 接收窗口自动调节级别 : disabled ``` 修改后： ```text 接收窗口自动调节级别 : normal ``` 对于万兆环境建议保持： ```text normal ``` 不要改成： ```text experimental ``` 微软官方也不推荐生产环境使用 experimental。 --- #### 4. RFC1323 Timestamp 当前： ```text RFC 1323 时间戳 : allowed ``` 这里不是 enabled，而是： ```text allowed ``` 表示： ```text 可以协商使用 但不会强制使用 ``` 这是 Windows Server 2022/2025 的正常默认值。 建议保持： ```text allowed ``` 不要改 disabled。 原因： - SMB3 - Hyper-V Live Migration - 高带宽高延迟链路 会受益于 Timestamp。 --- #### 5. ECN 当前： ```text ECN 功能 : enabled ``` 这个比较特殊。 ECN（Explicit Congestion Notification）用于网络拥塞通知。 优点： ```text 减少丢包 提高吞吐 ``` 缺点： ```text 某些旧交换机 某些旧防火墙 某些运营商设备 兼容性不好 ``` 如果你网络里有： - 老华为交换机 - 老H3C交换机 - 老防火墙 建议改回： ```cmd netsh int tcp set global ecncapability=disabled ``` 如果全是新设备，可以保持 enabled。 --- ### 关于 winnat 你执行： ```cmd net stop winnat ``` 返回： ```text 没有启动 Windows NAT Driver 服务 ``` 这是正常的。 说明当前主机没有使用： ```text Hyper-V NAT Docker NAT Container NAT ``` 至少没有启用 WinNAT。 无需处理。 --- ### 我建议你再检查两个关键项 #### 查看端口耗尽情况 PowerShell： ```powershell Get-NetTCPConnection | Measure-Object ``` 查看当前连接数。 --- #### 查看 TIME\_WAIT 数量 ```cmd netstat -ano | find /c "TIME_WAIT" ``` 如果经常超过： ```text 10000+ ``` 甚至： ```text 30000+ ``` 那么扩大动态端口范围就非常有价值。 --- ### 针对你的 Hyper-V 宿主机 我建议最终配置如下： ```cmd 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 ``` 或者保持当前： ```text RFC1323 时间戳 : allowed ``` 即可。 如果你这台服务器承担 20 个以上 Hyper-V 虚拟机，并且有 MySQL、MongoDB、RabbitMQ、文件同步等大量东西南北向流量，我还建议检查： ```powershell 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连接数 ```powershell Get-NetTCPConnection | Measure-Object Count : 203 ``` 只有： ```text 203个TCP连接 ``` 对于： - Hyper-V宿主机 - 20多个虚拟机 - 万兆网络 来说非常低。 因此： ```cmd netsh int ipv4 set dynamicport tcp start=1025 num=64511 ``` 实际上暂时用不上，但保留也没有问题。 --- ## 二、82599万兆网卡RSS状态 你最重要的网卡： ```text Intel 82599 10G #1 Intel 82599 10G #2 ``` 其中： ```text SLOT 4 端口 2 ``` 显示： ```text Enabled : True NumberOfReceiveQueues : 128 Profile : NUMAStatic ``` 说明： ```text RSS 已开启 ``` 这是好的。 --- ### 但有个异常 #### SLOT 4 端口1 显示： ```text NumberOfReceiveQueues : 8 ``` 但是： ```text RssProcessorArray : IndirectionTable : ``` 为空。 这通常意味着： ```text RSS未真正工作 或驱动异常 或网卡未承载流量 ``` 建议检查： ```powershell Get-NetAdapterStatistics -Name "SLOT 4 端口 1" Get-NetAdapterStatistics -Name "SLOT 4 端口 2" ``` 看看哪个接口真正有流量。 --- ## 三、Hyper-V虚拟交换机 你有： ```text vEthernet (10.1.1.104-nic1) vEthernet (10.2.2.4-slot4_2) ``` 均显示： ```text NumberOfReceiveQueues : 16 ``` 说明： ```text vRSS 已开启 ``` 这是正确配置。 --- ## 四、RSC状态 你执行： ```powershell Get-NetAdapterRsc ``` 结果： ```text IPv4Enabled : True IPv4Operational : False FailureReason : ForwardingEnabled ``` 这是正常现象。 原因： ```text Hyper-V Virtual Switch 开启转发模式 ``` RSC会自动失效。 微软设计如此。 因此： ```text False ``` 不是故障。 --- ## 五、建议检查VMQ Hyper-V性能最关键的是： ```powershell Get-NetAdapterVmq ``` 如果看到： ```text Enabled : True ``` 则正常。 如果： ```text Enabled : False ``` 建议开启： ```powershell Enable-NetAdapterVmq -Name "SLOT 4 端口 2" ``` --- ## 六、建议检查VMMQ Windows Server 2022/2025非常重要。 执行： ```powershell Get-NetAdapterVmq ``` 和： ```powershell Get-VMSwitch ``` 以及： ```powershell Get-VMSwitchTeam ``` 看看是否启用了： ```text VMMQ Virtual Machine Multi Queue ``` 对于： ```text 20台以上虚拟机 10G以上网卡 ``` 收益很大。 --- ## 七、82599网卡的特殊优化 Intel 82599 是老牌但非常稳定的万兆芯片。 推荐检查： ```powershell Get-NetAdapterAdvancedProperty -Name "SLOT 4 端口 2" ``` 重点关注： ### Jumbo Frame 建议： ```text 9014 ``` 或： ```text 9000 ``` 前提： - 交换机支持 - 对端支持 --- ### Interrupt Moderation 建议： ```text Enabled ``` --- ### Receive Side Scaling 建议： ```text Enabled ``` --- ### Flow Control 如果用于Hyper-V内部同步： 建议： ```text Rx & Tx Enabled ``` --- ## 八、根据你目前输出的结论
项目状态
TCP动态端口✅ 正常
UDP动态端口✅ 正常
Auto Tuning✅ 正常
RSS✅ 已开启
vRSS✅ 已开启
RSC✅ 正常（Hyper-V导致）
TCP连接数✅ 极低
TIME\_WAIT风险✅ 几乎没有
82599万兆网卡✅ 工作正常
Hyper-V交换机✅ 正常
目前看不到需要进一步调整 TCP 参数的地方。 下一步最值得检查的是： ```powershell Get-NetAdapterVmq Get-NetAdapterAdvancedProperty -Name "SLOT 4 端口 2" Get-NetAdapterStatistics -Name "SLOT 4 端口 2" ``` 尤其是 VMQ 和 Jumbo Frame 配置，它们对 Hyper-V 虚拟机间的大流量传输影响比前面那几条 `netsh` 命令更大。 不准确，或者更准确地说： ```powershell Get-NetTCPConnection | Measure-Object ``` 只能统计 **当前 Windows 宿主机 TCP/IP 协议栈中的连接**，并不能统计 Hyper-V 虚拟机内部的连接。 你的结果： ```text Count : 203 ``` 表示： ```text 宿主机自身只有203个TCP连接 ``` 包括： - RDP - SMB - DNS - Hyper-V管理流量 - 宿主机运行的服务 而不包括： ```text VM内部的TCP连接 VM内部的NAT会话 VM内部的Docker连接 VM内部的应用连接 ``` --- ### 你的网络结构大概率是 ```text Internet │ ▼ 路由器/防火墙 │ ▼ Hyper-V宿主机 │ ▼ 虚拟交换机 │ ┌──┼──────────┐ │ │ │ VM1 VM2 VM20 ``` 如果 NAT 服务运行在某个 VM 里面： ```text OpenClash Linux NAT 软路由 RouterOS pfSense OpenWRT ``` 那么： ```powershell Get-NetTCPConnection ``` 看到的仍然可能只有： ```text 100~500个连接 ``` 因为 60 万 NAT 会话全部存在于 VM 内部。 --- ### 如何确认 NAT 在哪里 查看宿主机是否存在 NAT： ```powershell Get-NetNat ``` 如果返回： ```text No MSFT_NetNat objects found ``` 说明： ```text 宿主机没有承担NAT ``` --- 查看宿主机连接跟踪： ```powershell Get-NetTCPConnection | Group-Object State ``` 例如： ```text Established : 150 TimeWait : 30 Listen : 20 ``` 说明宿主机压力很小。 --- ### 如果 NAT 在 OpenWrt VM 例如： ```text OpenWrt VM 192.168.1.1 ``` 查看： ```bash cat /proc/sys/net/netfilter/nf_conntrack_count ``` 或者： ```bash conntrack -C ``` 才能看到： ```text 600000 ``` 这样的会话数。 --- ### 如果 NAT 在 Windows VM 查看： ```powershell Get-NetNatSession | Measure-Object ``` 或者： ```powershell Get-NetNatSession ``` --- ### 对于你的环境 你之前描述： - Hyper-V - 40个虚拟机 - OpenClash - 大量代理流量 - 万兆交换机 我判断： ```text 60万 NAT 会话 ``` 极有可能在： - OpenWrt VM - Linux VM - RouterOS VM - pfSense VM 里面，而不是宿主机。 因此： ```powershell Get-NetTCPConnection | Measure-Object ``` 得到的： ```text 203 ``` 只是宿主机自身连接数，不能反映整体业务流量。 --- 如果你想评估 **Hyper-V 宿主机是否会因为 60 万 NAT 会话受到影响**，更有价值的是查看： ```powershell Get-Counter '\Network Interface(*)\Bytes Total/sec' Get-Counter '\Hyper-V Virtual Switch(*)\Bytes/sec' Get-Counter '\Hyper-V Virtual Network Adapter(*)\Bytes/sec' ``` 以及： ```powershell Get-NetAdapterStatistics ``` 这样可以看到： - 实际吞吐量（Gbps） - PPS（每秒包数） - 丢包 - 队列压力 这些指标比 `Get-NetTCPConnection` 更能反映 Hyper-V 宿主机在高峰期是否接近瓶颈。