hyper-v 70万nat会话数流量分析

结合你前面提供的所有数据（Hyper-V、sar、conntrack、iptables NAT），已经基本可以定位问题方向了。

一、当前流量路径

你的架构大概是：

互联网
   │
   ▼
rulr-4 / rulr-5（NAT代理）
   │
   ├── rulr2-01
   ├── rulr2-02
   └── rulr2-03

外部约 60 万 NAT 会话：

rulr-4 ≈ 36万
rulr-5 ≈ 34万

合计：

≈ 70万连接

与描述的60万级连接基本一致。

---

二、最重要的发现

从 sar -n SOCK 看：

rulr-4

367779
365949
367271
369945

约：

36~37万 Socket

---

rulr-5

338756
341389
344627
344251

约：

33~34万 Socket

---

但是后端：

rulr2-01

803
810

只有：

800个连接

---

rulr2-02

118000
122000

约：

12万连接

---

rulr2-03

117000
123000

约：

12万连接

---

说明：

rulr2-02
rulr2-03

承担主要业务连接

rulr2-01
几乎没接到流量

负载均衡根本没均匀。

---

三、iptables输出暴露的问题

你贴出的 NAT 表：

75M 3632M DNAT tcp dpt:6031

这一条特别异常：

75M packets
3632M bytes

而其它规则：

6100
6101
6102
...

只有几千包。

---

说明：

6031端口承担了绝大部分业务。

例如：

6031
 ↓
172.18.0.200
 ↓
容器
 ↓
rulr2-02/rulr2-03

---

因此真正热点在：

6031

不是整个代理。

---

四、网络是否到瓶颈

根据你之前的 sar：

eth0

rxkB/s ≈ 200
txkB/s ≈ 180

即：

200 KB/s

换算：

≈ 1.6 Mbps

---

即便考虑采样误差：

< 10 Mbps

---

而宿主机是：

Intel 82599
10G

所以：

10Gbps
↓
实际只有几Mbps

差了上千倍。

---

结论：

❌ 不是带宽瓶颈

---

五、Hyper-V数据也证明不是网卡瓶颈

你抓到：

Packets Received/sec

3066

仅：

3000 PPS

---

10G网卡正常能承受：

100万 PPS以上

---

当前：

3000 PPS

连 1% 都不到。

---

六、CPU中断情况

你抓到：

% DPC Time

Total:
0.52%

---

说明：

网卡中断压力极低

如果真是网卡瓶颈：

DPC
20%
30%
40%

都常见。

---

你这里只有：

0.5%

非常健康。

---

七、真正可疑的地方

从目前证据看：

网络没满

网卡没满

CPU没满

conntrack没满

端口没满

---

最可疑的是：

NAT状态表查找开销

你目前：

rulr-4
≈37万连接

rulr-5
≈34万连接

---

虽然：

nf_conntrack_max=1048576

没到上限。

但是：

30~40万活跃连接

已经足以让：

conntrack hash
NAT lookup

消耗明显 CPU。

---

建议查看：

conntrack -S

重点看：

insert_failed
drop
early_drop
search_restart

---

八、进一步验证

在晚高峰（20:00~22:00）执行：

sar -n TCP,ETCP 60

看：

active/s
passive/s
retrans/s

---

特别关注：

retrans/s

如果：

>100
>1000

说明开始拥塞。

---

再看：

sar -n DEV 60

重点：

%ifutil

---

如果：

<10%

则绝对不是带宽问题。

---

九、我目前的判断

综合所有证据：

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

最大的异常反而是：

rulr2-01 ≈ 800连接

rulr2-02 ≈ 12万连接

rulr2-03 ≈ 12万连接

这说明后端负载均衡没有真正做到 1:1:1 分流。

下一步我建议直接查看 rulr-4/rulr-5 上负责分流到 rulr2-01、02、03 的具体 iptables（或 haproxy/nginx）配置，包括：

iptables-save

或者：

iptables -t nat -S

中涉及 rulr2-01、rulr2-02、rulr2-03 的 DNAT 规则。

把这部分贴出来，我可以直接帮你计算实际流量命中比例，并判断为什么 rulr2-01 几乎没有接到会话。