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