📚 本文是 科学上网完全指南（2026最新版） 系列教程之一。客户端的选型、订阅导入、规则分流先看总览页，这篇只聚焦一个高频动作——测速：延迟到底怎么看、怎么测、测速失败和”延迟高却难排查”这些问题怎么解决。

先泼一盆冷水：你在 Clash 里点「测速」看到的那个毫秒数，根本不是”这个节点有多快”。 它测的是时延，不是带宽——一个延迟只有 30ms 的节点，下载可能比延迟 200ms 的还慢。

很多人拿到机场订阅，第一件事就是一顿狂点「测速」，然后照着数字从低到高挑节点，结果还是卡、还是慢。问题就出在没搞懂测速到底在测什么。这篇把延迟是怎么来的、怎么测才对、测速失败和”数字好看但体感拉胯”该怎么排查，一次性说透。

一、先搞清楚：测速测的到底是什么

Clash 里的「测速」，本质是向节点发出一个小小的 HTTP 请求，然后记录从发出到收到响应的时间，也就是延迟（Delay / Latency），单位毫秒（ms）。

它有两个关键特点，直接决定你怎么用这个数字：

  • **它测的是”路通不通 + 路有多远”，不是”路有多宽”**。一个测速请求可能只有几 KB，延迟低只能说明这条链路时延小，不代表传大文件时带宽高。
  • 延迟和带宽是两个维度。打游戏、视频会议看重延迟（越低越跟手）；下大文件、看高清视频看重带宽（越大越快）。两者经常不同步——延迟 50ms 的节点，下载可能比延迟 200ms 的还慢，因为它的出口带宽被限了。

所以别把那个延迟数字当「快慢」的唯一标准。下面先讲怎么正确测，再讲测不准怎么排查。

二、怎么测：客户端内置测速

以 Clash Verge Rev 为例，最常用的测速方式在「代理」页面：

  1. 打开 Clash 客户端，进入「代理」（Proxies）页。
  2. 找到你要测的节点组（策略组），点组名右侧的「测速」按钮。
  3. 客户端会向组内每个节点发测速请求，几秒后每个节点后面会显示延迟数字，数字越小表示时延越低。

也可以勾选多个节点后批量测速，或右键单个节点单独测。Android（ClashMetaForAndroid / CMFA）、iOS（Stash）等客户端的操作大同小异，都是在节点列表里找「测速 / 全部测速」。

只看单个数字还不够时，可以结合两个信息一起判断：

  • 延迟数值：100ms 以内体验很好，100–200ms 日常可接受，300ms 以上卡顿明显。
  • 波动：同一个节点多测几次，如果数字忽高忽低（比如一会 80ms 一会 400ms），说明线路不稳，比一直 200ms 更难受。

三、让节点自动选最快：url-test 自动测速

手动一个个点太麻烦，尤其是机场有几十个节点时。Clash 支持 url-test 策略组，让它自动测速、自动切到延迟最低的节点：

proxy-groups:
  - name: "🚀 自动选择"
    type: url-test
    proxies: [节点A, 节点B, 节点C, ...]
    url: "https://www.gstatic.com/generate_204"
    interval: 300   # 每 300 秒测一次并切换

配置说明：

  • type: url-test 让组内周期测速，自动选延迟最低的节点。
  • url 是测速用的地址，选一个稳定、不消耗太大流量的目标（见下节）。
  • interval 是测速间隔（秒）。设太短会频繁发测速请求，节点多时流量和后台开销都不小，300 秒（5 分钟）是常见平衡点。

url-test 适合「我只想稳、不在乎落地在哪个地区」的场景。如果你需要固定地区（比如看奈飞要锁定某个区），那还是用 select 手动选固定节点更合适——测速只是帮你判断哪个顺，不是越自动越好。

四、测速地址（URL）怎么选

测速用哪个地址，直接决定测出来的数字可不可信。几个原则：

  • 用「返回即走」的轻地址：比如 Google 的 gstatic.com/generate_204（返回 204 空响应）、Cloudflare 的 cp.cloudflare.com。这些地址不会加载大内容，测速快、不费流量。

  • 别用大文件页：拿 speedtest 那种要下几 MB 的地址做分组自动测速，每 5 分钟测一次，几十个节点一起跑，流量哗哗的。

  • 国内直连节点用国内地址：如果你想测国内直连的节点，用境外地址会失真，换 connect.rom.miui.com/generate_204 这类国内可达地址。

  • 机场自带测速地址：很多机场订阅自带 url 配置，直接用就行，通常是针对它们自己的线路优化的。

    有个细节值得留意：Mihomo 的测速请求可以用 headers 指定一个 User-Agent，部分节点对空 UA 或默认 UA 会返回异常（导致本可用的节点被判”超时”）。如果发现大批节点测速失败但实际能连，试着给测速配置加一个正常的浏览器 UA。这是排查”全灭但网络其实通”时很容易被忽略的一环。

五、测速失败 / 延迟高怎么排查（重头戏）

这里有两个最常见的坑，分开排查：一个是「测速根本测不出来」（失败、报错），一个是「测速数字看着没问题，但用起来卡」（延迟高，或者数字与体感不符）。

5.1 测速失败、报错误码或超时

先判断是「单个失败」还是「全灭」：

单个节点失败——多半是节点自身问题：挂了、入口被墙、或者机场临时下线。直接换一个节点，别纠结。

全部节点都失败 / 报 443 之类错误码——按顺序查：

  1. 代理是不是真在生效。确认系统代理开关是开的，或 TUN 模式已开启。有时候关了代理却去测速，当然全失败。
  2. 测速 URL 被阻断。某些网络环境会针对测速地址做干扰，换一个测速地址（比如换成 cp.cloudflare.com）再试。
  3. 订阅过期 / 节点信息失效。机场节点会定期更换地址和密码，订阅没更新时，拿到的可能是一堆失效节点。重新拉一次订阅。
  4. DNS 异常。DNS 解析失败也会让测速请求发不出去。检查客户端 DNS 配置，或重启客户端清缓存。
  5. 测速请求的 UA 被拒。见上一节：给测速配置加一个正常的浏览器 User-Agent，很多”全灭但实际能连”就是栽在这。
  6. 错误码 443。443 通常和 HTTPS 测速目标不可达有关（节点能连但握手失败，或目标被 RST）。换个测速 URL、换个节点基本能绕开。这正是知乎上被问得最多的「Clash 测速报 443」的典型场景。

5.2 延迟很高，或数字好看但实际卡

延迟高，先分清是「真高」还是「其实不慢」：

延迟确实高（300ms+，且体感也卡）——大概率是链路问题：

  • 本地到节点入口的距离占了时延大头，落地离你越远延迟越高，先换一个离你近的节点。
  • 协议不合适：Reality、Hysteria2 在弱网、跨网场景下通常比老协议（SS、老 VMess）表现好，可以切协议试试。
  • 多重代理叠加：系统级代理 + Clash 又开一层，等于绕了两趟，延迟直接翻倍。检查是不是叠了。

延迟很低但实际卡（数字好看，体感拉胯）——这是延迟和带宽脱节了：

  • 出口带宽被限：节点延迟 50ms，但出口给你限到 2 Mbps，看视频当然卡。
  • 链路丢包：延迟低但丢包严重，TCP 来回重传，感受比高延迟还差。
  • 高峰期拥堵：白天测速时线路空闲，晚上高峰出口塞满，延迟没变但带宽塌了。

怎么判断真实速度？跑一次真实下载比看延迟靠谱：用 speedtest 测一次、或者开个大文件下载看实际速度。延迟是”路况”，下载速度才是”车能跑多快”。

六、怎么按延迟挑节点（实操建议）

把上面的串起来，选节点可以按这个顺序：

  1. 先看延迟过滤掉离谱的：直接排除 300ms 以上、或者测速一直失败的节点。
  2. 再看波动：多个低延迟节点里，挑那个数字稳的（同测几次差距小）。
  3. 按用途定策略：
    • 打游戏、开会 → 用 url-test，自动选低延迟，关注稳定性。
    • 看流媒体、下大文件 → 手动选固定节点，重点看实际下载速度而非延迟。
    • 有地区要求（奈飞某区）→ 锁定该区节点，测速只用来挑该区内最稳的那个。
  4. 别迷信最低那个：延迟 30ms 的节点若出口限速，不如 80ms 但带宽充足的。真实体感才是唯一标准。

一个容易被忽略的点：测速结果还受当前模式影响。如果客户端开的是「全局模式」，所有流量都走代理，测速数字反映的是节点真实链路；如果开「规则模式」，而测速用的域名恰好命中直连规则（比如你用了国内测速地址却测境外节点），数字就会失真。所以测速前先确认好模式，别在规则模式下用错了测速地址。

七、常见问题

Clash 怎么测速节点延迟？

打开客户端「代理」页面，选中节点组后点「测速」按钮，客户端会向每个节点发一个测速请求并显示延迟（毫秒）。也可以右键节点组或勾选多个节点后批量测速。延迟越低通常越快，但延迟低不等于带宽高，走流量大的场景还要看实际下载速度。

Clash 节点的延迟是什么？怎么才算好？

延迟（Delay）是一个测速请求从发出到收到响应的往返时间，单位毫秒。100ms 以内体验很好，100-200ms 日常可用，300ms 以上会有明显卡顿。它反映的是到节点的网络时延，不是节点流量入口的带宽，两者要分开看：打游戏、开会看重延迟，下载大文件更看重带宽。

Clash 测速失败、报错误码 443 或超时怎么办？

先分清是单个节点失败还是全部失败。单个节点失败多半是该节点本身挂了或入口被墙，换一个节点即可；全部失败检查：系统代理、TUN 模式是否正常开启；测速用的 URL 是否被阻断（换测速 URL 或节点）；订阅是否过期、节点信息是否已失效（重新拉订阅）；DNS 是否异常。443 错误码常和 HTTPS 测速目标不可达有关，换个测速地址通常能解决。

为什么测速显示延迟很低，实际却很慢？

这是延迟与带宽的天花板效应。测速只发一个小请求，不代表大流量下的带宽；延迟低但节点出口带宽被占满或限速、或链路丢包严重时，下载依旧慢。反过来延迟高也未必不能下得快。要判断真实速度，用测速站跑一次下载，或开个大文件下载实测，不要只看那个毫秒数。

为什么很多节点测速都失败，但我其实能连上网？

大概率是测速请求被拒，而不是网络真断了。两个高发原因：一是测速用的 User-Agent 为空或默认值，部分节点会拒掉，给测速配置加一个正常的浏览器 UA 即可；二是当前开的是规则模式，测速域名恰好命中了直连规则，数字失真或请求走错了路由。先确认模式和测速地址，再补 UA 试试。

Clash 怎么让节点自动选最快的（url-test）？

用 url-test 类型的策略组。它会周期性地测组内所有节点的延迟，自动切到延迟最低的那个，适合不在乎落地地区、只想稳快的场景。配置里 type 填 url-test，并设置 url（测速地址）和 interval（测速间隔，比如 300 秒）。注意 url-test 会频繁发送测速请求，节点多时频率高，按需使用。

哪个测速地址（URL）比较准？

推荐用稳定的境外 HTTP(S) 服务，比如 Google 的生成器地址 gstatic.com/generate_204（返回 204，不会加载大内容）、Cloudflare 的 cp.cloudflare.com，或机场自己提供的测速地址。别用依赖大文件下载的地址做分组自动测速，会浪费流量。国内直连节点则用国内可达地址如 connect.rom.miui.com/generate_204。

节点延迟一直很高怎么排查？

按顺序：确认你选的是落地离你近的节点（本地到节点入口的时延占大头）；换协议（Reality、Hysteria2 在弱网下表现常优于老协议）；检查是否开了多重代理或系统代理叠加；用 ping 或 tracert 看是本地网络问题还是节点问题；联系机场换线路。延迟高低主要由物理距离和线路质量决定，不是你本地配置能硬调下来的。

想在「选哪个客户端」上少踩坑，看 Clash 怎么办客户端选哪个：Clash Verge、Stash、CMFA 等对比；节点延迟再低，规则分流不对体验也打折，见 Clash / Mihomo 自定义规则完全指南。机场订阅、协议、TUN 模式这些前置概念都在 Clash 教程总览页 和 科学上网完全指南 里，一次看全。