翻墙慢，到底是节点问题还是本地问题？VPN 测速五步定位法

翻墙能连上，但卡到不能用

这篇文章解决一个很具体的问题：代理是通的，网页也能打开，但慢到让人想砸键盘。

这种情况比完全断网更难处理，因为「慢」可能发生在五个完全不同的层：你的本地网络、你到节点的那段链路、节点本身、协议和 MTU、以及对面那个网站。换节点只能解决其中一层，而多数人一上来就在换节点。

下面五步按成本从低到高排，每一步都有明确的判断标准。测速工具本身的选择和使用流程见中国网络测速方法，这篇讲的是怎么读那些数字。

先说结论

一、没有基线，所有数字都是废的。 先测不开代理时的延迟／下载／抖动，再测开代理的。差值才是代理的成本，单独一个「我只有 8Mbps」说明不了任何事。

二、三个指标各自指向不同的病。 延迟高＝远或绕路；速度低＝带宽或限速；抖动大＝拥堵或丢包。卡顿的元凶通常是抖动，不是平均速度——这是最常被误判的一条。

三、分清节点和线路，只要五分钟。 同一地区测三个节点：三个都慢＝线路问题，换节点没用；只有一个慢＝那台机器的问题，切走就行。

四、协议和 MTU 要测，不要猜。 UDP 类协议在丢包链路上更好，但在对 UDP 限速的网络里会更差。MTU 用 ping 加不分片标志就能测出来，第四步有命令。

五、有时候问题根本不在你这边。 对面网站的 CDN 把你解析到了一个糟糕的节点，或者它本身就在限速。第五步教你怎么把这种情况和自己的问题分开。

六、达标数值有官方口径，不用猜。 YouTube 官方建议持续速度：4K 20 Mbps、1080p 5 Mbps、720p 2.5 Mbps；Netflix 官方建议 1080p 5 Mbps 以上、4K 15 Mbps 以上。对照表在第七节。

说明：本站在中国境内没有测量节点，本文不提供任何「实测数据」。所有数值要么是厂商官方文档给出的建议值（已标注来源），要么是你自己测出来的。这篇文章教的是方法和判读标准。

第一步：先测没有代理的时候（多数人跳过的一步）

完全退出代理客户端，然后测三个数并记下来：

为什么这一步不能省：假设你家宽带晚上实际只有 30 Mbps，那代理跑出 25 Mbps 已经很接近上限了——这时候你换多少个节点都不会更快，因为瓶颈在你家那根线上。没有基线，你会把本地的问题当成节点的问题，然后一直换下去。

再记一件事：测两次，一次白天一次晚高峰（21–23 点）。如果你的裸宽带在晚高峰本身就掉一半，那后面所有「晚上特别慢」的现象都有了解释，和代理无关。

第二步：三个指标，三种病

开启代理，连上你平时用的节点，测同样三个数。然后对照下表——这张表是全文的核心：

关于抖动，必须单独说一句。 很多人只盯着下载速度，但对看视频、开会、打游戏来说，抖动比平均速度更能决定体验。一条平均 20 Mbps 但抖动 80ms 的线路，看 1080p 会不断转圈；一条稳定 8 Mbps、抖动 5ms 的线路反而很顺。

所以如果你测出来速度够（对照第七节），却还是卡，别再纠结带宽了，去看抖动和丢包。

先排除本地 Wi-Fi：抖动大的时候，先用网线或把手机贴着路由器再测一次。2.4GHz 频段的 Wi-Fi 在密集住宅里抖动很大，这个锅经常被算到节点头上。

第三步：是这个节点，还是这条线路？

这一步五分钟，能省掉大量无意义的切换。

做法：在同一个落地地区里，挑三个不同的节点，各测一次延迟和速度。

顺便做一件事：连上之后打开 IP 地址查询，看出口 IP 的实际归属地和你选的节点名字对不对得上。名字写「日本」但出口在别处，这本身就解释了一部分延迟。

再换一个地区试。 如果所有地区都慢，而你的裸线（第一步）是正常的，那问题更可能在入口侧——也就是你到境外的那一段。不同线路类型（普通公网、CN2 GIA、IPLC 等）在这一段的差别很大，背景见 CN2 GIA、IPLC、IEPL 到底差在哪。

第四步：协议和 MTU，测出来而不是猜出来

协议：没有「最快」，只有「匹配不匹配」

两类协议的性格不同：

• UDP 类（Hysteria2、TUIC 等）——在丢包链路上表现明显更好，因为它们自己管拥塞控制，不受 TCP 那套保守重传的拖累。
• TCP/TLS 类（VLESS+Reality、Trojan、AnyTLS 等）——在对 UDP 不友好的网络里更稳。

关键在于：如果你所在的网络对 UDP 大流量限速，UDP 类协议会比 TCP 类更慢。这不是协议差，是环境不匹配。各协议的设计目标和取舍见 VLESS+Reality、Hysteria2、AnyTLS 到底解决了什么。

怎么测：同一个节点、同一个时段，两种协议各测一次。差别大到一眼能看出来，就按测出来的选；差不多，就选客户端支持更好的那个。客户端里怎么并存多套协议配置见 Clash 使用教程。

MTU：一个被反复猜错的参数

先说规范怎么写的。QUIC 的标准 RFC 9000 第 14 节明确规定：「QUIC MUST NOT be used if the network path cannot support a maximum datagram size of at least 1200 bytes」（如果网络路径不能支持至少 1200 字节的最大数据报，就不应使用 QUIC）。同一节还给出，按 IPv6 最小 IP 包 1280 字节推算，IPv6 下的最大数据报是 1232 字节，IPv4 下是 1252 字节。

所以「我的 MTU 应该设多少」这个问题有一个可以测出来的答案，不需要在论坛上抄别人的数字。

Windows 上怎么测（按微软官方文档，/f 表示在 IP 头里把「不分片」标志置 1，「对排查路径最大传输单元（PMTU）问题很有用」；/l 指定 echo 请求里数据字段的字节长度）：

ping /f /l 1472 baidu.com

• 返回正常 → 路径支持这个大小。把 1472 往上加，直到失败。
• 提示需要分片（Packet needs to be fragmented but DF set） → 把 1472 往下减，直到成功。

找到最大能通过的那个值之后，加上 28 字节（IP 头 20 + ICMP 头 8）就是路径 MTU。比如 1472 通过，那路径 MTU 是 1500。

macOS / Linux 上用 ping -D -s 1472 baidu.com（-D 是不分片，-s 是数据长度），判读方式相同。

什么时候需要动 MTU：如果你测出来的路径 MTU 明显小于 1500（常见于 PPPoE 拨号、某些移动网络、嵌套隧道），而客户端还按 1500 发包，就会不断触发分片或丢弃，表现为「小页面正常、大文件和视频卡死」。这个症状很有特征性——如果你的现象是「打开网页很快，一下载就卡」，优先怀疑这里。

⚠️ 别乱调。 没有出现上述症状就不要动 MTU，默认值在绝大多数环境里是对的。先测，测出问题再改。

第五步：问题在对面

前四步都正常，但某个特定网站就是慢——这时候问题很可能不在你的链路上。

三种常见情况：

1. CDN 把你解析到了一个糟糕的节点。 同一个网站，从不同出口访问会被分配到不同的 CDN 边缘节点。用 DNS 记录查询 看看这个域名在你当前环境下被解析到了什么地址——换一个落地地区，解析结果和速度可能完全不同。
2. 网站本身在限速或在做风控。 如果这个站点对你的出口 IP 评级不好，它可能给你更低的优先级、更多的验证码。这类现象和速度无关，但体验上很像「慢」。
3. 大文件下载被单连接限速。 很多站点对单个连接限速，但对并发不限。如果是这种，换节点没用。

怎么分开：拿一个大站（比如任意一个国际测速站点）和你觉得慢的那个站分别测。前者快、后者慢 = 问题在对面；两者都慢 = 回到第二步。

六、一张决策树，走到底就是答案

翻墙慢
 │
 ├─ 先关代理测基线 ──── 裸线本身就慢？
 │                        └─ 是 → 【动作1】修本地网络/换时段，和代理无关
 │                        └─ 否 ↓
 │
 ├─ 开代理测三个指标
 │    ├─ 延迟高、速度还行 ────────→ 【动作2】换更近的落地地区
 │    ├─ 延迟正常、速度低
 │    │    ├─ 只在晚高峰慢 ───────→ 【动作3】换节点（拥堵）
 │    │    └─ 任何时候都是同一上限 → 【动作4】是限速，换服务或换套餐
 │    ├─ 抖动大/丢包 ────────────→ 先排除本地 Wi-Fi，再换节点或换协议
 │    └─ 三个数都正常但就是卡
 │         ├─ 只有某个站慢 ──────→ 【动作5】问题在对面，见第五步
 │         └─ 「打开网页快、一下载就卡」→ 测 MTU，见第四步
 │
 └─ 同地区三个节点都慢 ──────────→ 换地区或换协议，不要再换节点

五个动作，对应五种不同的钱和时间成本：动作 1 和 5 不花钱；动作 2、3 免费且立刻见效；动作 4 是唯一需要掏钱的，所以它应该是最后一个结论，不是第一个。

七、什么叫「够用」：按场景给数

这一节的数字全部来自厂商官方文档，不是我们的测试结果。

YouTube 官方给出的建议持续速度（System requirements & supported devices for YouTube）：

Netflix 官方建议的网络速度：720p 3 Mbps 以上、1080p 5 Mbps 以上、4K 15 Mbps 以上。

怎么用这张表：

• 测出来 10 Mbps 却卡 1080p → 带宽不是问题，去看抖动和丢包（第二步）。
• 测出来 3 Mbps 想看 4K → 这就是原因，不用再查了。
• 延迟：对看视频和浏览网页，延迟只要稳定，200ms 以内基本无感；对视频会议和游戏，抖动比绝对延迟更重要——一条稳定 150ms 的线路，体验好过在 60–200ms 之间乱跳的线路。

一个提醒：这些是解码端需要的持续速度，不是「测速跑出这个数就一定不卡」。测速测的是短时峰值，视频播放要的是长时间稳定。这也是为什么抖动那一列比速度那一列更值得看。

八、什么时候该停止排查

有三种情况，再测下去也没有意义：

1. 所有地区、所有协议、所有时段都慢，而裸线正常。 该查的都查完了，问题在服务侧。这时候该做的是问对问题再换，而不是继续测。
2. 昨天还好好的，今天所有节点突然一起变差。 这更像是一次事件而不是一个配置问题，先按机场突然全挂了：30 分钟自救清单走一遍流程。
3. 你已经改了三个以上的设置，而且不记得原始值了。 停下来，把配置恢复默认，重新从第一步开始。同时改多个变量的排查，得到的结论不可信。

一句话收尾：「翻墙慢」不是一个问题，是五个问题共用了一个症状。这五步的价值在于，每一步都把可能性砍掉一半——做完最多花二十分钟，而你换一个节点碰运气可能要碰一个月。

参考资料

• YouTube 帮助 — System requirements & supported devices for YouTube（各清晰度的建议持续速度：4K 20 Mbps、1080p 5 Mbps、720p 2.5 Mbps、480p 1.1 Mbps、360p 0.7 Mbps）（2026-09-21 核查）
• Netflix 帮助中心 — Netflix-recommended internet speeds（720p 3 Mbps 以上、1080p 5 Mbps 以上、4K 15 Mbps 以上）（2026-09-21 核查）
• RFC 9000 — QUIC: A UDP-Based Multiplexed and Secure Transport，第 14 节 Datagram Size（「QUIC MUST NOT be used if the network path cannot support a maximum datagram size of at least 1200 bytes」；IPv6 下 1232 字节、IPv4 下 1252 字节）（2026-09-21 核查）
• Microsoft Learn — ping 命令参考（/f 置「不分片」标志，「对排查路径最大传输单元（PMTU）问题很有用」；/l 指定 echo 请求数据字段长度，默认 32 字节）（2026-09-21 核查）