# hyper-v 70万nat会话数流量分析结合你前面提供的所有数据（Hyper-V、sar、conntrack、iptables NAT），已经基本可以定位问题方向了。 # 一、当前流量路径你的架构大概是： ```text 互联网 │ ▼ rulr-4 / rulr-5（NAT代理） │ ├── rulr2-01 ├── rulr2-02 └── rulr2-03 ``` 外部约 60 万 NAT 会话： ```text rulr-4 ≈ 36万 rulr-5 ≈ 34万 ``` 合计： ```text ≈ 70万连接 ``` 与描述的60万级连接基本一致。 --- # 二、最重要的发现从 sar -n SOCK 看： ## rulr-4 ```text 367779 365949 367271 369945 ``` 约： ```text 36~37万 Socket ``` --- ## rulr-5 ```text 338756 341389 344627 344251 ``` 约： ```text 33~34万 Socket ``` --- 但是后端： ## rulr2-01 ```text 803 810 ``` 只有： ```text 800个连接 ``` --- ## rulr2-02 ```text 118000 122000 ``` 约： ```text 12万连接 ``` --- ## rulr2-03 ```text 117000 123000 ``` 约： ```text 12万连接 ``` --- 说明： ```text rulr2-02 rulr2-03 承担主要业务连接 rulr2-01 几乎没接到流量 ``` 负载均衡根本没均匀。 --- # 三、iptables输出暴露的问题你贴出的 NAT 表： ```text 75M 3632M DNAT tcp dpt:6031 ``` 这一条特别异常： ```text 75M packets 3632M bytes ``` 而其它规则： ```text 6100 6101 6102 ... ``` 只有几千包。 --- 说明： 6031端口承担了绝大部分业务。例如： ```text 6031 ↓ 172.18.0.200 ↓ 容器 ↓ rulr2-02/rulr2-03 ``` --- 因此真正热点在： ```text 6031 ``` 不是整个代理。 --- # 四、网络是否到瓶颈根据你之前的 sar： eth0 ```text rxkB/s ≈ 200 txkB/s ≈ 180 ``` 即： ```text 200 KB/s ``` 换算： ```text ≈ 1.6 Mbps ``` --- 即便考虑采样误差： ```text < 10 Mbps ``` --- 而宿主机是： ```text Intel 82599 10G ``` 所以： ```text 10Gbps ↓ 实际只有几Mbps ``` 差了上千倍。 --- 结论： ❌ 不是带宽瓶颈 --- # 五、Hyper-V数据也证明不是网卡瓶颈你抓到： ```text Packets Received/sec 3066 ``` 仅： ```text 3000 PPS ``` --- 10G网卡正常能承受： ```text 100万 PPS以上 ``` --- 当前： ```text 3000 PPS ``` 连 1% 都不到。 --- # 六、CPU中断情况你抓到： ```text % DPC Time Total: 0.52% ``` --- 说明： ```text 网卡中断压力极低 ``` 如果真是网卡瓶颈： ```text DPC 20% 30% 40% ``` 都常见。 --- 你这里只有： ```text 0.5% ``` 非常健康。 --- # 七、真正可疑的地方从目前证据看：网络没满网卡没满 CPU没满 conntrack没满端口没满 --- 最可疑的是： ## NAT状态表查找开销你目前： ```text rulr-4 ≈37万连接 rulr-5 ≈34万连接 ``` --- 虽然： ```text nf_conntrack_max=1048576 ``` 没到上限。但是： ```text 30~40万活跃连接 ``` 已经足以让： ```text conntrack hash NAT lookup ``` 消耗明显 CPU。 --- 建议查看： ```bash conntrack -S ``` 重点看： ```text insert_failed drop early_drop search_restart ``` --- # 八、进一步验证在晚高峰（20:00~22:00）执行： ```bash sar -n TCP,ETCP 60 ``` 看： ```text active/s passive/s retrans/s ``` --- 特别关注： ```text retrans/s ``` 如果： ```text >100 >1000 ``` 说明开始拥塞。 --- 再看： ```bash sar -n DEV 60 ``` 重点： ```text %ifutil ``` --- 如果： ```text <10% ``` 则绝对不是带宽问题。 --- # 九、我目前的判断综合所有证据：

项目	状态
10G物理网卡	正常
Hyper-V交换机	正常
宿主机CPU	正常
DPC中断	正常
虚拟机带宽	正常
nf\_conntrack\_max	充足
ip\_local\_port\_range	充足
NAT连接数	偏高
后端负载均衡	明显不均衡

最大的异常反而是： ```text rulr2-01 ≈ 800连接 rulr2-02 ≈ 12万连接 rulr2-03 ≈ 12万连接 ``` 这说明后端负载均衡没有真正做到 1:1:1 分流。下一步我建议直接查看 rulr-4/rulr-5 上负责分流到 rulr2-01、02、03 的具体 iptables（或 haproxy/nginx）配置，包括： ```bash iptables-save ``` 或者： ```bash iptables -t nat -S ``` 中涉及 `rulr2-01、rulr2-02、rulr2-03` 的 DNAT 规则。把这部分贴出来，我可以直接帮你计算实际流量命中比例，并判断为什么 rulr2-01 几乎没有接到会话。