文章

从 28% 丢包到 0%：一次 v2ray 卡顿排查与搬瓦工 CN2 GIA 升级实录

记录一次 v2ray 卡顿问题的完整排查过程，从 28% 丢包定位到搬瓦工普通线路拥堵，最终升级到 CN2 GIA ECOMMERCE 的全过程与前后 benchmark 对比。

发表于
作者 puppylpg
14 分钟阅读
从 28% 丢包到 0%：一次 v2ray 卡顿排查与搬瓦工 CN2 GIA 升级实录
  1. 问题：v2ray 突然很卡
  2. 诊断：先排除本地网络
  3. 关键发现：DNS 污染 + 节点高丢包
  4. 为什么普通线路会这么差
    1. 中国电信骨干网分层
  5. 解决方案：升级到 CN2 GIA ECOMMERCE
    1. 机房选择
  6. 升级与迁移过程
  7. 升级前后 benchmark 对比
  8. 总结
  9. 后续：当升级后的速度又慢下来
    1. 排查思路
    2. 关键发现
      1. 1. DNS 与 IP 没问题
      2. 2. ICMP 被屏蔽，但 TCP 443 可达
      3. 3. 反向路由确认走了移动 CMIN2
      4. 4. VPS 本身不是瓶颈
    3. 协议对照实验：VMess vs REALITY
    4. 那问题到底在哪？
    5. 做了哪些清理
    6. 现在的判断

问题：v2ray 突然很卡

某天打开浏览器，发现通过 v2ray 访问 YouTube、Google 都慢得难以忍受。本地代理端口是 10808，v2rayN 显示连接正常，但网页就是转圈。

第一反应通常是怀疑节点挂了，但 v2rayN 并没有报错。为了定位问题，我决定从本地网络、代理进程、节点链路三个层面做一次系统排查。

诊断：先排除本地网络

先用 curl 走 socks5 代理测速：

1
2
3

curl -x socks5h://127.0.0.1:10808 -o /dev/null \
  -w "HTTP %{http_code}, 总耗时 %{time_total}s\n" \
  https://www.google.com/

结果：HTTP 000，连接超时。但本地直连百度却非常流畅（0.07 秒），这说明问题不在本地宽带，而在代理链路。

进一步检查端口监听，确认 xray 进程在跑：

1

netstat -ano | grep 10808

输出显示 xray.exe 正在监听 0.0.0.0:10808，进程本身没问题。

关键发现：DNS 污染 + 节点高丢包

当我用 --resolve 强制 Google 的正确 IP 再测试时，代理居然能打开 Google，只是很慢。这说明 socks5h 的远程 DNS 解析返回了被污染的 IP。

同时，ping 节点 IP 65.49.202.163 的结果触目惊心：

1
2

发送: 50， 收到: 36， 丢失: 14 (28% 丢包)
平均延迟: 185ms

28% 的丢包率，足以让任何基于 TCP 的代理体验崩溃。WebSocket + TLS 对丢包尤其敏感，每丢一个包就要重传，页面打开时间会被放大数倍。

为什么普通线路会这么差

要理解这个问题，需要先搞清楚中国电信的几类国际出口线路。

中国电信骨干网分层

网络AS 号特点适用场景
163 / ChinaNetAS4134最早的公众骨干网，容量大、便宜、高峰期极拥堵普通访问
CN2 GTAS4809 接 AS4134国际段走 CN2，进国内后走 163中等质量
CN2 GIAAS4809全程 CN2，质量最高、价格最贵、容量有限视频会议、稳定代理
CTGNetAS23764中国电信全球网络，实际等效于 CN2 GIA企业精品线路

搬瓦工文档里对这几条线路的描述很准确：普通 163 和 CN2 GT 在晚高峰都会拥堵，只有 CN2 GIA / CTGNet 能提供稳定的跨太平洋连接。

我当前的 20G KVM - PROMO 套餐走的就是普通线路，位于 USCA_2 机房，所以高峰期丢包严重。

flowchart LR
    A[用户电脑] --> B[本地宽带]
    B --> C[国际出口]
    C --> D[美国机房]
    D --> E[目标网站]
    
    subgraph 普通线路["普通 163 / CN2 GT"]
        C -->|高峰期拥堵| D
    end
    
    subgraph CN2_GIA["CN2 GIA / CTGNet"]
        C -.->|全程高速| D2[美国 CN2 GIA 机房]
    end
    
    style 普通线路 fill:#ffe3e3
    style CN2_GIA fill:#e8f5e9

解决方案：升级到 CN2 GIA ECOMMERCE

搬瓦工提供了 SPECIAL 20G KVM PROMO V5 - CN2 GIA ECOMMERCE 套餐，年费 $169.99。由于我当前套餐还有 159 天剩余，按未使用天数折算后补差价 $48.83，还能叠加一个 6.58% 的循环优惠码。

机房选择

CN2 GIA 套餐可选多个机房。搬瓦工官方推荐洛杉矶 USCA_9，原因有三：

  1. 容量最大：8×10Gbps CN2 GIA/CTGNet 链路
  2. 三网优化：电信 CN2 GIA + 移动 CMIN2 + 联通 CUP
  3. 对中国路由最好：延迟通常 130-150ms

另外还有 USCA_6（圣何塞）、CABC_6（温哥华）、USNY_8（纽约）等可选，但对大陆用户来说，洛杉矶 USCA_9 性价比最高。

升级与迁移过程

  1. 在搬瓦工后台提交升级到 CN2 GIA ECOMMERCE
  2. 进入 KiwiVM 的 Migrate to another datacenter
  3. 选择 USCA_9（DC9 AMD+NVMe, CT CN2GIA, CMIN2, CUP）
  4. 等待迁移完成，获取新 IPv4 地址
  5. 在 Cloudflare 把域名 A 记录从旧 IP 65.49.202.163 改为新 IP 95.169.10.75
  6. 本地执行 ipconfig /flushdns
  7. 重启 v2rayN，让 xray 重新解析域名

迁移完成后，新 IP 是 95.169.10.75，先 ping 一下：

1
2

发送: 50， 收到: 50， 丢失: 0 (0% 丢包)
平均延迟: 153ms

丢包直接归零，延迟也降了 30ms。

升级前后 benchmark 对比

指标升级前（USCA_2 普通线路）升级后（USCA_9 CN2 GIA）
节点 IP65.49.202.16395.169.10.75
Ping 丢包28%0%
Ping 延迟185ms153ms
代理打开 Google3.78s0.84s
代理打开 YouTube13.14s0.95s
下载 10MB完全失败3-6 Mbps

本地直连百度的速度没有变化（始终在 0.04 秒左右），证明改善完全来自国际线路质量的提升。

总结

这次卡顿的根因不是 v2rayN 配置错误，也不是本地网络问题，而是搬瓦工普通线路在晚高峰的严重丢包。升级到 CN2 GIA ECOMMERCE 并迁移到 USCA_9 后，丢包从 28% 降到 0%，Google 和 YouTube 的打开速度分别提升了 4 倍和 13 倍。

对于个人翻墙用途，洛杉矶 CN2 GIA 20G 套餐已经足够。如果未来还想进一步优化，可以考虑把协议从 VMess + WebSocket + TLS 换成抗封锁能力更强的 VLESS + Vision + REALITY，但就当前体验而言，CN2 GIA 已经解决了核心痛点。

后续：当升级后的速度又慢下来

更新于 2026-06-28。

升级当晚的 benchmark 确实很漂亮，但过了几天我又感觉代理变卡了——YouTube 缓冲、网页转圈，完全没体会到 CN2 GIA 的优势。于是我做了一次更深入的排查，甚至临时搭了一套 VLESS + REALITY 做对照实验。

排查思路

为了不凭感觉下结论，我从三个层面验证：

  1. 本地网络：确认不是家里宽带的问题；
  2. DNS 与路由：确认流量真的走到了 CN2 GIA / CMIN2；
  3. 协议对照：在同一台 VPS、同一域名上，同时跑 VMess + WebSocket + TLS 和 VLESS + REALITY，看速度差异。
flowchart TD
    A[感觉代理卡] --> B{本地直连百度?}
    B -->|正常| C[问题在国际链路]
    B -->|也卡| D[本地网络问题]
    C --> E[检查 DNS 解析到的 IP]
    E --> F[确认 95.169.10.75]
    F --> G[traceroute / mtr 看路由]
    G --> H{是否经过 59.43 或 223.120?}
    H -->|是| I[线路本身在走优质骨干]
    H -->|否| J[可能没有真正走到 CN2/CMIN2]
    I --> K[协议对照实验]
    J --> L[检查 VPS 套餐与机房]
    K --> M[判断是协议被 QoS 还是线路容量问题]

关键发现

1. DNS 与 IP 没问题

puppylpg.top 仍然解析到升级后的 95.169.10.75，没有走 Cloudflare 代理，也没有解析回旧 IP。

2. ICMP 被屏蔽，但 TCP 443 可达

1
2

ping 95.169.10.75      # 全丢包
tracert 95.169.10.75   # 第三跳后全超时

一开始我以为 IP 不通，后来用 Test-NetConnection 测 TCP 443 发现是通的。这说明：国际线路普遍屏蔽 ICMP，不能拿 ping 丢包判断代理质量。

3. 反向路由确认走了移动 CMIN2

从 VPS 侧做反向 traceroute 回我家公网 IP，路径很清晰：

1
2
3
4
5
6
7

1  10.26.0.1        BWG 内网
2  10.26.255.0      BWG 内网
3  45.78.0.74       BWG/QuadraNet 上联
4  223.120.200.57   CMIN2（中国移动国际精品网）
5  223.120.197.1    CMIN2
6  223.120.161.5    CMIN2
...221.183.x.x...   中国移动国内骨干

第 4 跳进入 223.120.x.x，说明 USCA_9 的 CMIN2 优化确实生效，不是虚假宣传。

4. VPS 本身不是瓶颈

  • 负载 load average 只有 0.08；
  • 到 GitHub 下载速度 ~400 Mbps；
  • 到中国移动北京 DNS ping 稳定在 124 ms。

所以问题不在 VPS 的 CPU、网卡或带宽。

协议对照实验：VMess vs REALITY

我在同一台 VPS 上临时起了一个 Xray 容器，新增 VLESS + Vision + REALITY 监听 8443 端口（dest 用 www.cloudflare.com），然后本地分别用两种协议跑 50MB 下载测速：

协议Google 打开耗时50MB 下载速度
VMess + WS + TLS1.54s~8.4 Mbps
VLESS + REALITY1.25s~6.5 Mbps

结果出乎意料：两者速度差不多，REALITY 并没有更快。

如果 VMess+WS+TLS 被移动 QoS 限速，REALITY 应该明显拉开差距。但实测没有，说明瓶颈不在协议层面。

那问题到底在哪？

结合所有证据，最可能的结论是：

瓶颈在“我家移动宽带 → CMIN2 入口”这一段，以及 CMIN2 本身的容量。

  • 升级后的 VPS 是“对的”，线路也确实走了 CMIN2；
  • 但 CMIN2 不是无限带宽，晚高峰该挤还是挤；
  • 我家是移动 CGNAT（100.96.0.1），共享公网 IP，出口 QoS 由省移动决定；
  • 同一时段 fast.com 能跑到 24 Mbps，但 Cloudflare 测速只有 6–8 Mbps，说明不同 CDN 路径差异也很大。

做了哪些清理

实验结束后，我已把临时创建的 Xray REALITY 容器、配置文件、本地 Docker 测试容器全部删除。VPS 上只保留了原来的 V2Ray 4.x / 5.x 两套服务，没有残留端口或配置。

现在的判断

  • 换协议（VMess → REALITY）收益不大，不需要为了速度迁移；
  • 如果想进一步验证，可以在晚高峰 21:00–23:00 和凌晨 01:00 各跑一次 fast.com，确认是不是只有晚高峰卡；
  • 如果全天都卡，那可能是本地移动 CGNAT 出口质量差，换电信/联通热点一试便知；
  • 如果只是晚高峰卡，那就是 CMIN2 容量问题，搬瓦工这条线路在该时段满载，加钱上更高配套餐也未必能解决。

一句话总结：CN2 GIA-E / CMIN2 不是没用，只是它不是魔法，救不了你家宽带到国际出口的最后一公里拥堵。

life, vps, v2ray, network
v2ray xray bandwagon cn2-gia vps networking
本文由作者按照 CC BY 4.0 进行授权