Clash Verge如何测试同一节点的延迟？

用 Clash Verge 测延迟很方便：在代理页点一下闪电形状的“延迟测试”按钮，节点旁边就出现一个数字。但这个数字是怎么来的、在哪里改测试地址、为什么同一个节点两次测出来差很多，很多人并不清楚。本文先讲原理，再按 Clash Verge Rev 的实际界面说明每一步在哪里操作，最后给一套能让结果“可比”的做法。

界面名称按 Clash Verge Rev v2.5.9 的简体中文界面核对（2026-10-31，对照官方源码里的中文语言文件）；其他版本位置可能略有不同，以你安装的版本为准。

先弄清它测的是什么

Clash 系客户端里的“延迟测试”，做的是这样一件事：通过这个节点，向一个测试地址发起一次 HTTP(S) 请求，从发出到收到响应所用的时间，就是显示的延迟。很多配置默认使用一个只返回 HTTP 204 的小请求地址作为测试地址。

这和命令行里的 ping 不一样：

• ping 测的通常是你的设备到某台主机的往返时间；
• 客户端的延迟测试是“经节点访问测试地址”的完整请求，包含与节点建立连接、节点再去访问测试地址的时间，所以数字通常比 ping 大；
• 测试地址不同、用 HTTP 还是 HTTPS 不同，结果都会不同；
• 显示“超时”，只说明在设定的等待时间内没有完成请求，不一定表示节点永久不可用。

具体实现因内核和客户端版本而异，这里说的是一般原理。

在 Clash Verge Rev 里，这些东西在哪

• 测延迟的按钮：左侧导航进入“代理”页，每个代理组标题栏右侧有一组图标，鼠标悬停显示“延迟测试”的那个会测整组；组里的单个节点，点节点卡片右侧的延迟数字（或“未测试”）可以只测这一个。
• 首页的快捷入口：首页“当前节点”卡片的“延迟测试”按钮只测当前在用的节点。
• 排序：代理组标题栏的排序图标可以在“默认排序 / 按延迟排序 / 按名称排序”之间切换。做记录时请保持“默认排序”，否则每测一次节点位置都会变，容易点错。
• 测试地址：代理组标题栏里有一个“延迟测试链接”输入框，可以给这个组单独指定地址；全局默认值在“设置”页的杂项设置里，叫“默认测试链接”，旁边是“测试超时时间”。这两项只影响客户端自己的 HTTP 测试请求，不会改动你的订阅配置。
• 统一延迟：“设置”页“Clash 设置”里的“统一延迟”开关打开后，内核会用不同的方式计算延迟（去掉握手等开销），数字会整体变小。整个测试周期内不要切换这个开关，否则前后数据不可比。
• 自动延迟检测：杂项设置里的这个开关会在后台定时测当前节点，做人工记录时建议关掉，免得和手动测试互相干扰。
• 代理模式与系统代理：代理页顶部的“规则 / 全局 / 直连”和“设置”页的“系统代理”都不影响延迟测试——它只经节点访问测试地址，不需要打开系统代理。

第一步：固定测试条件

• 记下客户端名称和版本（“设置”页能看到版本号），测试期间不升级。
• 确认“默认测试链接”并保持不变：可以用默认值，也可以改成自己指定的固定地址，但整个测试周期内不要换；代理组里的“延迟测试链接”也不要中途改。
• “统一延迟”开关保持测试开始时的状态，不要切换。
• 使用同一种网络连接，最好是网线直连；关闭正在下载或同步的程序；关掉“自动延迟检测”。
• 如果你使用“根据 URL 测试延迟选择代理”这类自动选择的策略组，测试单个节点时先把它改成手动选择的组，避免测试过程中被自动切走。

第二步：对同一个节点重复测试

1. 在代理页找到要测的节点，点它的延迟数字单独测一次，记下数值。
2. 等待十秒左右，再测。日常快速检查测 10 次左右就能看出大概；要比较不同地区、线路或时间段，至少采集 30 次有效样本，并记录测试时间、网络环境、测试目标和统计结果。每次等上一次出结果再点，不要连续快速点击。
3. 记录最小值、最大值、中位数和 P95（把结果从小到大排，取第 95% 位置的值）；出现超时要记下次数，不要略过。正式对比优先用中位数和 P95，并结合超时/丢包情况看；样本不足就如实写样本数，不要把快速检查写成完整的稳定性测试。
4. 想粗略估计抖动，可以计算相邻两次结果之差的平均值，并在记录里写明“这是自己的算法，只能在同一份记录里比较”，因为不同工具的算法并不相同，见抖动会影响哪些使用场景。

用代理组标题栏的“延迟测试”批量测整组时，请求是并发的，个别结果可能受干扰；需要认真比较的几个节点，建议再单独测一遍。

第三步：记录

至少记录这些字段：测试日期时间（精确到分钟）、客户端与版本、测试地址、网络连接方式、节点名称、十次的结果、超时次数、备注。截图时让系统时间一起入镜，并遮盖订阅链接、令牌等敏感信息。字段名可以参考本站测试档案里 CSV 的列名，方便以后和站内记录放在一起对照。

第四步：在不同时间窗口重复

同一个节点，在早间、午间、晚间、晚高峰和深夜分别重复同样的测试，连续几天。完整的安排见如何记录一个节点连续 7 天的速度变化。

常见误区

• 拿测试地址不同、或“统一延迟”开关状态不同的两组数字比较。
• 把延迟数字当成下载速度。延迟低不代表下载快，区别见为什么节点延迟低不代表下载速度快。
• 只测一次就下结论，或者把一次很低的数字当成长期表现。
• 整组全部“超时”：先检查“默认测试链接”能否在浏览器里打开、超时时间是否太短，再怀疑节点。

拿到十次结果之后

看范围（最大值减最小值），而不是只看平均；有超时的话，数一数占比；把同一个节点在不同窗口的范围放在一起比较。“多少毫秒算好”没有通用的标准，它取决于你的所在地和用途，所以更有意义的是同一个节点自己的变化，以及同一窗口内不同节点之间的差别。

一份记录的样子（假设数字）

假设十次结果依次是：92、95、90、310、93、91、超时、94、96、92（单位 ms）。可以这样记：成功 9 次、超时 1 次（占 10%）；最小 90、最大 310（不含超时）；中位数 93，平均约 117。平均值被那一次 310 拉高，中位数更接近多数时候的状态；而 310 和那次超时不应该删掉，它们恰恰是“这个节点偶尔会出问题”的证据。这组数字是编的，只用来演示怎么写。