反复重装客户端
重装只影响虚拟网卡与配置，不改变线路。按工单记录，重装三次以上仍未解决的案例中，有 82% 最终定位到 DNS 或本地带宽占用。
01
Scope
先分清是"全都慢"还是"某个站慢"
这一步决定了后面五个检查点要不要走。两类慢的原因几乎不重叠，混在一起查只会浪费时间。
打开两个不同类型的站点各访问一次：一个视频站，一个文档站。若两个都慢，问题在本机或出口；若只有文档站慢，问题多半在 DNS 解析或者目标站点自己回源慢，与线路无关。实测在同一个连接上，视频站的吞吐能跑到 42 Mbps 而文档站首屏要 3.1 秒，这种情况换十次线路也不会有改善。
判定的具体依据是看速度面板的下行速率读数。如果面板显示下行有流量但页面仍在转圈，说明数据到了但解析或渲染卡住，方向应指向 DNS；如果面板上的速率本身就贴着零，说明数据没到，方向才指向线路与网卡。
02
Checkpoints
六个检查点与各自的判据
| 序号 | 检查点 | 判定读数 | 对应处理 |
|---|---|---|---|
| 1 | DNS 解析 | 首包成功率低于 90% | 开启内置解析 |
| 2 | 虚拟网卡速率 | 协商速率只有 10 Mbps | 重装网卡驱动 |
| 3 | MTU 与分片 | 大包全部超时、小包正常 | 把 MTU 调到 1,380 |
| 4 | 出口队列 | 面板速率波动超过 60% | 换出口或固定线路 |
| 5 | 时段拥塞 | 同一线路白天快晚上慢 | 避开 20:00 至 23:00 |
| 6 | 本地带宽占用 | 其他进程占用超过 50 Mbps | 关掉后台更新 |
六个检查点按从本机到出口的顺序排列，越靠前越容易自己修，也越容易被忽略。按工单归类，前三个检查点覆盖了 61% 的案例，其中 DNS 一项单独就占了 27%。也就是说，接近三成的"慢"根本不是线路问题，而是解析绕了弯路。
03
How to
逐项怎么操作
- 换 DNS 看首包在设置里勾选内置解析，重连后对同一批 20 个站点再访问一次。实测在 5% 丢包的模拟环境下，首包成功率由 71% 升到 96%，代价是连接时多 40 毫秒协商。
- 看虚拟网卡的协商速率Windows 在适配器状态里能看到链路速度。正常应为 100 Mbps 或 1 Gbps，若显示 10 Mbps，说明驱动协商失败，卸载重装客户端即可恢复。
- 试小包定位 MTU用 ping 加 1,472 字节不分片参数测试，全丢说明路径 MTU 更小。把客户端 MTU 调到 1,380 后重试，实测分片相关的超时从 18% 降到 0.4%。
- 看面板速率的波动幅度连续观察 60 秒，若峰值与谷值相差超过 60%，说明出口侧在排队。此时固定到另一条线路，实测完成同一文件下载的时间缩短 2.3 秒。
- 对比不同时段把同一测试放到下午三点与晚上九点各跑一次。晚间读数若低 40% 以上，属于时段拥塞，换线路的收益很小，调整使用时间更实际。
- 查本机其他进程任务管理器按网络排序，找出还在跑的系统更新或云盘同步。实测一个后台同步进程能把可用带宽吃掉 50 Mbps 以上，而且完全不影响 CPU 读数。
04
Waste
三件通常没用的事
手动挨个试所有出口
32 个地区逐个试完约需 40 分钟，而自动推荐的首选命中率已经是 85%。除非你有明确的目标地域，手动挑不如让客户端自己算。
把 MTU 一路调小
调到 1,200 以下会让每包有效载荷明显变少。实测 1,200 相比 1,380 的吞吐损失约 9%，虽然有连接成功率，但代价是持续性变慢。
05
Escalate
需要找客服时带上什么
客服在线时段是 9:00 到 24:00，邮箱 [email protected]。要让沟通一次到位，请在信里写清四件事：客户端版本号、所用出口地区、测试时段、以及速度面板上的上下行读数。这四项决定了问题能不能被复现，缺任何一项都会多一轮往返。
不必附带截图里的账号信息。客户端日志不含访问内容，只有线路编号、握手耗时和错误码，直接附日志文件比附截图更有用。按 2026 年 9 月的统计，附了日志的工单首次响应后的解决率为 78%，未附的为 41%。