svr4u 商家偷跑流量

这个不是很正常吗，只是这家掩饰做得不好让你发现了

还真的是重来没用过流量一直跑

ai分析结果

• 只读分析完成。结论：异常流量主要来自上游 KVM 虚拟交换网络错误投递的其他租户流量，不是本机 Docker、Caddy 或 iperf3 产生的。

关键证据：

• 
  

  运行约 40 天，eth0 累计：

  
  
  
  
  • 接收：341.8 GB / 3.63 亿包
  
  
  • 发送：812 MB / 450 万包
  
  
  • 收发比例约 421:1
  
  
  
  


• 
  

  实时空闲采样 10 秒仍收到 16.75 MB，约 13.4 Mbit/s、600 包/秒。

  
  


• 
  

  在明确关闭混杂模式的抓包中：

  
  
  
  
  • 99.94% 字节发往 00:00:5e:00:01:3c/3d，这是上游 VRRP 网关 MAC。
  
  
  • 发往本机 MAC 的数据只有约 9.9 KB。
  
  
  • 99.5% 的帧是 IPv6，源地址属于同一上游网段中的其他主机，目的地址则是外部互联网。
  
  
  
  


• 
  

  本机网卡状态为 promiscuity 0、allmulti 0，没有加入桥接，也没有 TC/XDP 配置。

  
  


• 
  

  内核日志确认：开机以来主网卡唯一一次进入混杂模式，是我本次约一秒的诊断抓包，随后立即退出。

  
  


• 
  

  Docker 容器累计网络量只有约百 MB，当前 CPU 接近 0；现有 TCP 连接只有 SSH，无法解释 342 GB 入站。

  
  

这说明上游把其他虚拟机发往网关的帧也投递给了你的 virtio 网卡。Linux 会把这些帧计入 eth0 RX 统计，之后才因目标 MAC 不匹配而丢弃。主机防火墙无法阻止这些字节到达网卡，也未必能阻止服务商面板计费。

建议立即向服务商提交工单，可直接附上：

VM id 在 eth0 promiscuity=0、allmulti=0 时仍收到其他租户发往 VRRP MAC 00:00:5e:00:01:3c 和 00:00:5e:00:01:3d 的单播流量。非混杂抓包中 99.94% 字节目标 MAC 非本机，10 秒 RX 增量 16,745,603 字节。请检查虚拟交换机

端口隔离、unicast flooding/port mirroring，并核查及重算相关流量计费。

@ucoo #3

我也是刚分析完， 发工单给他们了，关机了已经。

这厂商真垃圾