VPN 下视频通话卡顿：先找出出问题的方向

画面流畅而语音断续，说明了一件具体的事：媒体路径对音频的丢包或延迟，已经超过了对画面的损伤。通话需要小包稳定地双向投递，而下载速度快的测速结果对此毫无说明力。真正值得看的指标，是每个方向的丢包、延迟和延迟抖动。先弄清是哪个方向出问题，比任何测速都更快缩小排查范围。

先问其他参会者：他们是否听到你断续，你耳中对方的声音是否卡顿，两个问题是否在同一时刻开始？

先定方向，再看路径

单向的音频问题指向一组特定原因。麦克风选择、应用的输入权限或设备被静音都会造成它，某个方向上丢包的网络路径同样如此。对方声音卡顿而你这边发送正常，是另一类现象，要查的路径也不同。在动 VPN 之前先记下症状，可以避免去修一条根本没参与的链路。

ping 你自己挑的网站，走的是与会议媒体中继不同的路径。这可以当作参考背景，但它不是对通话的测量。

通话统计到底说明了什么

多数会议客户端会在通话中显示连接统计：收发包数、丢包、往返时间，有时还有抖动。要读该应用自己的定义，因为一个产品的抖动数值并不是另一个产品的。模式比任何单个数字都重要：共享屏幕时丢包上升、只在有人上传时延迟攀升，或者接收方向干净而发送方向不干净。这些模式分别指向不同的部件。

如果客户端报告了中继或媒体服务器所在区域，记下来。那个区域才是通话数据包真正去的地方，它可能离 VPN 出口标注的国家很远，也离地图上的距离很远。

上传饱和看起来就像抖动

上行使链路被打满，是家庭办公环境里语音断续最常见的原因。上传队列饱和时，小小的音频包排在大量数据后面，结果就是通话难以应付的延迟抖动。云备份、照片同步和其他家用设备可能在无人察觉时把它打满。先暂停你自己可选的上传，再重复同一通电话，然后再去改任何网络设置。

如果只有链路空闲时质量才变好，问题就是负载下的排队，而不是 VPN 的路由。降低视频质量只是减少需求，并不能告诉你哪个队列造成了延迟。

一次只改一个跳点

用有线网络，或站到接入点旁边测试，同时保持 VPN 和应用不变。如果中断消失，问题就在本地无线路径，而换出口国家本来会错过它。然后如有需要，再对比服务商的一个备用接入点。更近的出口并不自动更快，因为路由和会议服务的媒体中继位置才决定真正重要的路径。

分流隧道排除是合理工具，但它改变的不只是性能：会议流量会走到隧道之外，另一个网络能看到这条直连。先确认公司政策，并记住辅助进程可能并不跟随主程序。

在正常后台活动的状态下，重新测一次真实对话，两个方向都要听。会议页面打开很快，并不是你要测的那个结果。