Clash Verge Rev 节点测速怎么选？延迟、速度与稳定性判断方法
简答：先在 Clash Verge Rev 的代理页批量测速，再对低延迟节点重复测试，最后用真实网页或办公任务验证。测速结果只说明节点到测试地址当时是否可达，不能直接等同于下载速度、晚高峰稳定性或所有网站都能正常使用。
定义：Clash Verge Rev 节点测速，是通过客户端向指定测试地址发起请求并记录响应延迟或超时，用于筛选候选节点的初步方法。
先给结论：不要直接选择最低延迟节点
如果你只想快速选一个可用候选节点，可以先在代理页对整个代理组执行延迟测试，然后保留延迟较低且不是偶发超时的节点。接下来至少复测几轮，并打开实际需要使用的网页、下载任务或办公连接。
原因是 Clash Verge Rev 的延迟测试本质上是对指定测试地址进行请求。项目源码显示，代理页可以使用节点卡片或代理组标题旁的测试按钮发起检测，也允许使用自定义测试地址；mihomo 文档则将 url 定义为健康检查地址，将 timeout 定义为超时时间。测试目标不同，结果就不能直接横向比较。查看 Clash Verge Rev 代理页测试按钮源码，查看 mihomo 代理组健康检查字段。
| 结果 | 通常表示 | 下一步 |
|---|---|---|
| 较低延迟 | 节点到当前测试地址的响应时间较短 | 继续复测，不要直接断定下载快 |
| 较高延迟 | 当前路径响应较慢，可能受距离、线路或拥塞影响 | 与同地区节点在相同时间再次比较 |
| Timeout | 在限定时间内没有完成测试 | 换测试地址或网络后复测，并查看日志 |
| Error | 测试请求出现错误，原因可能不止是延迟高 | 检查节点协议、配置、核心状态和测试地址 |
| 延迟低但网页慢 | 测试地址响应快，但目标业务的链路或规则不理想 | 用真实目标网站和持续下载验证 |
Clash Verge Rev 节点测速的可操作步骤
- 先固定测试条件。记录设备系统、当前网络类型、测试时间、使用的代理组、测试地址和是否开启系统代理。不要一边切换 Wi-Fi、移动网络和代理模式，一边比较结果。
- 打开代理页面。找到包含节点的代理组。对单个节点，点击节点卡片上的延迟测试按钮；对整个代理组，点击组标题附近的批量测试按钮。按钮名称和图标可能因版本或语言不同而变化，但源码中对应的是节点级和代理组级的延迟检测操作。参考代理页测试逻辑。
- 先做一次批量初筛。不要把所有节点都立刻用于真实下载。先排除持续 Timeout、持续 Error 和延迟明显偏高的候选，只留下同一地区或同一用途下的若干节点。
- 对候选节点重复测试。建议在同一网络和同一测试地址下连续测试至少三轮，并记录每轮结果。这里的“三轮”是操作建议，不是软件硬性要求；如果结果波动很大，应优先保留波动较小的节点，而不是只保留某一次最低值。
- 再做真实场景验证。网页用途看页面首屏和连续打开情况；下载用途看一段持续传输中的速度变化；远程办公看登录、长连接和文件传输是否中断。延迟测试成功并不代表这些任务一定成功。
- 最后确认流量确实经过所选节点。检查当前代理组显示的活动节点，并确认系统代理或对应应用的代理设置已启用。若测速正常但网页仍直连或打不开，先检查规则模式、系统代理、TUN 状态和 DNS，不要只重复点击测速。
测试地址应保持一致，才能进行相对比较。mihomo 的代理组文档说明，url 是健康检查地址，interval 控制周期性测试，timeout 控制超时；API 文档还显示，节点延迟记录与测试 URL 相关，因此换地址后应视为另一组结果。查看 mihomo 延迟测试 API 说明。
延迟、速度、丢包和稳定性应该怎么看
延迟适合做第一轮筛选，表示一次测试请求从发出到获得响应所需的时间。它对网页点击、远程桌面交互和办公登录有参考价值，但不能代表大文件下载速度。
下载速度要通过持续传输观察。某个节点可能因为测试地址响应很小而显示低延迟，但在持续下载、长响应或高并发任务中表现不同。因此需要使用你的真实业务场景进行验证。
丢包和抖动通常要通过连续请求、日志或实际连接中断来观察。单次延迟测试没有返回“丢包率”就不要自行推算丢包率，也不要把一次 Timeout 直接定性为节点长期不可用。
稳定性重点看重复测试是否大幅波动、网页是否频繁重连、长连接是否中断，以及晚间使用时是否明显变差。测试记录应包含时间段，因为不同时间的网络负载可能不同。
| 使用场景 | 优先观察 | 不应只看 |
|---|---|---|
| 普通网页 | 延迟、首屏打开、连续访问 | 单次最低毫秒数 |
| 文件下载 | 持续速度、波动、是否中断 | 代理页延迟 |
| 远程办公 | 长连接、登录、会议或文件传输稳定性 | 自动组当前排名 |
| 特定网站或应用 | 目标域名规则、实际响应和连接日志 | 对其他测试地址的结果 |
select、url-test 和 fallback 怎么选
select是手动选择，适合你已经通过真实任务确认某个节点，并希望在登录、办公或长连接期间固定出口的情况。
url-test根据健康检查结果自动选择候选节点，适合日常浏览等可以接受节点自动切换的场景。它关注的是测试地址和配置参数下的检测结果，不等于对所有目标网站进行全面测速。
fallback按照节点排列顺序使用第一个通过检查的节点，后续节点主要承担备用作用，并不是“自动选择延迟最低的节点”。mihomo 文档明确说明，当前节点超时后，fallback 才会按顺序选择第一个可用节点。查看 mihomo fallback 说明。
| 代理组类型 | 选择逻辑 | 适合场景 |
|---|---|---|
| select | 手动固定节点或组 | 排障、固定出口、长连接 |
| url-test | 按健康检查结果自动选择 | 日常浏览、候选节点自动筛选 |
| fallback | 按顺序使用第一个可用节点 | 主节点加备用节点 |
| load-balance | 按策略分配连接 | 需要分散连接且能接受出口变化的场景 |
如果你正在排查“到底是哪一个节点有问题”，优先使用手动选择并固定一个节点；如果直接使用自动组，节点可能在测试或失败后切换，导致你无法判断问题来自节点、规则还是本地网络。
三种常见测速异常的分流处理
全部节点 Timeout
先不要删除订阅或重写配置。确认当前配置确实加载成功，检查核心是否运行，再换一个可访问且不需要登录的测试地址进行复测。如果仍然全部超时，暂时固定一个节点查看日志，并检查系统时间、网络连接、代理端口和本地安全软件是否拦截。测试地址本身不可达时，所有节点都可能被误判。
测速正常但网页打不开
先确认当前网页请求是否匹配了代理规则，再检查系统代理或 TUN 是否真的启用。随后查看连接日志中的最终策略和活动节点。如果只有某个域名失败，优先检查该域名的规则、DNS 解析和目标服务响应，不要根据一个网站推断所有节点都不可用。
节点频繁自动切换
先切换到 select 组并手动固定一个候选节点，完成网页或办公任务复测。若固定后稳定，问题可能与 url-test 的测试地址、间隔、容差或节点波动有关；若固定后仍失败，再回到节点协议、规则、DNS 和本地网络排查。修改配置前先复制配置文件或新建测试配置，确认无误后再决定是否保留。
可直接使用的节点评分记录表
不要把评分表当成绝对排名，而是用来避免凭一次结果做决定。每次记录时保持测试地址、设备、网络和时间一致。
| 节点 | 第1轮延迟 | 第2轮延迟 | 第3轮延迟 | 是否 Timeout | 真实任务结果 | 结论 |
|---|---|---|---|---|---|---|
| 节点 A | 填写 | 填写 | 填写 | 是/否 | 网页/下载/办公 | 保留/复测 |
| 节点 B | 填写 | 填写 | 填写 | 是/否 | 网页/下载/办公 | 保留/复测 |
| 节点 C | 填写 | 填写 | 填写 | 是/否 | 网页/下载/办公 | 保留/复测 |
最终选择建议采用“延迟不过高、重复结果波动可接受、真实目标任务成功、使用期间不频繁断线”的组合标准。节点名称中的地区或线路标签只能作为筛选线索，不能替代测速和实际验证。
常见问题
Clash Verge Rev 节点测速在哪里？
打开代理页面，在节点卡片上使用单节点延迟测试按钮，或在代理组标题附近使用批量测试按钮。具体图标和语言可能因版本不同而变化。
节点延迟越低就一定越快吗？
不一定。延迟测试只反映节点到指定测试地址的响应情况，不能直接代表下载速度、长连接稳定性或某个目标网站的实际体验。
Clash Verge Rev 测速显示 Timeout 怎么办？
先确认配置和核心已正常加载，再检查测试地址、网络和代理组设置；可在固定条件下换测试地址复测，并查看日志。不要仅凭一次 Timeout 删除节点。
url-test 和 fallback 哪个更适合自动选节点？
url-test 更偏向根据健康检查结果自动选择候选节点；fallback 按配置顺序使用第一个可用节点，适合主节点加备用节点，不是单纯追求最低延迟。
测速正常但网页仍然打不开怎么办？
检查当前规则是否把目标域名交给了正确代理组，再确认系统代理或 TUN 是否生效，并查看连接日志中的最终策略和活动节点。