Clash Verge Rev 节点测速怎么选最快节点？
简答：在 Clash Verge Rev 代理页先测试整组节点，再保留延迟较低且没有超时、错误的 3—5 个候选；随后用实际网页、视频或下载任务复测，最后在常用时段观察是否稳定。最低延迟只代表测速地址响应较快，不等于所有网站或下载都最快。
定义：节点测速是通过指定测试地址测量代理节点响应时间的过程，结果主要反映该节点到测试地址当时的链路表现，不等同于完整带宽或所有应用的实际速度。
先做这一步：代理页测速后建立候选名单
本文是第三方使用指南，Clash Verge Rev 的界面名称和按钮位置可能随版本、系统和配置变化。若你已经导入配置，先进入 Proxies 或“代理”页面，找到实际承载流量的策略组，不要直接把某个没有被规则引用的节点当成当前出口。
| 测速结果 | 通常表示什么 | 下一步 |
|---|---|---|
| 显示具体毫秒数 | 测试地址在超时范围内返回 | 加入候选，但还要做真实目标复测 |
| Timeout 或超时 | 测试地址未在规定时间内完成响应 | 先排除，不要仅凭一次结果断言节点永久不可用 |
| Error 或错误 | 测试请求发生异常 | 检查配置、测试地址和日志，再决定是否重测 |
| 未测试或短横线 | 当前没有可用的测速结果 | 点击单节点或整组测速 |
项目代码将节点延迟区分为未测试、测试中、超时、错误和已测得数值；项目隐私说明也明确，延迟测试会经由该代理向测试地址发送 HTTP 请求。因此，测速结果是某个测试请求的响应时间，不是长期下载速度保证。可查看 Clash Verge Rev 延迟测试实现 与 项目隐私说明。
- 在目标策略组旁点击测速按钮，等待整组结果完成。
- 按延迟排序，先留下低延迟且没有 Timeout、Error 的 3—5 个节点。
- 不要立刻开启自动切换，先手动选一个候选节点，便于观察实际流量。
- 用实际网页或工作服务复测，再决定是否长期使用。
单个节点和整组节点怎么测
整组测速适合第一次筛选：它会批量测量组内候选，便于快速发现延迟较低的节点。节点数量很多时，等待所有结果完成后再排序，避免只根据前几个返回结果做判断。
单节点测速适合复核：当两个节点延迟接近，分别点击节点卡片上的测速按钮，观察它们是否都能稳定返回。Clash Verge Rev 的延迟服务支持单个节点测试和批量测试，批量任务还会控制并发，避免所有请求同时发出。具体按钮图标可能变化，优先寻找节点卡片或策略组标题附近的测速、闪电或延迟按钮。
测速地址也会影响结论。项目隐私说明显示，延迟测试使用默认地址或你配置的测试地址；mihomo 的示例配置则使用一个返回简短响应的地址，并通过 url 和 interval 设置测试目标与周期。若测试地址本身不稳定，所有节点的结果都可能偏离你的实际使用场景。可参考 mihomo 策略组配置示例。
停止条件是：候选已经出现稳定的具体延迟，且你能用一个实际目标完成访问。此时不必为了追求更低的数字反复测速；重复测试只能说明不同时间点的结果变化，不能自动证明某个节点长期最快。
为什么最低延迟不一定下载最快
延迟通常只描述测试请求从客户端经节点到测试地址并返回所需的时间。网页打开、视频播放、文件下载和跨境办公还会受到出口带宽、拥塞、目标站点位置、协议处理、并发连接和本地网络的影响，所以“延迟最低”与“实际速度最快”不是同一个指标。
| 使用场景 | 优先观察 | 验证方式 |
|---|---|---|
| 普通网页 | 延迟、错误率、打开连续性 | 连续打开几个常用页面，观察是否出现间歇性失败 |
| 视频 | 缓冲、清晰度维持、长时间稳定性 | 播放同一内容一段时间，不只看首次打开速度 |
| 文件下载 | 持续下载速度和波动 | 使用同一文件、同一时间段比较候选节点 |
| 在线会议或跨境办公 | 延迟、丢包、持续稳定性 | 观察会议期间是否卡顿、重连或语音断续 |
| 需要固定出口的服务 | 出口是否稳定 | 优先手动选择，避免自动组频繁切换节点 |
每次比较尽量固定变量：同一设备、同一网络、同一目标、相近时间段和相同测试步骤。不要把一次测速、一次下载或一次网页打开结果写成长期排名，也不要把客户端显示的延迟当成服务商线路的永久性能。
按用途选择策略组：select、url-test、fallback、load-balance
策略组不是简单的节点文件夹，它决定客户端如何从多个节点中选择出口。mihomo 配置示例对常见类型的定义是：select 由用户手动选择，url-test 按测试结果选择延迟较低的节点，fallback 按节点顺序选择可用项，load-balance 按算法分配连接。具体含义以当前核心和配置为准。
| 类型 | 适合情况 | 不适合直接用来判断什么 |
|---|---|---|
select | 需要固定节点、方便复现问题 | 不能自动帮你筛选最快节点 |
url-test | 多个用途相近的节点，接受自动切换 | 不能保证真实下载或所有网站最快 |
fallback | 有明确主节点和备用节点顺序 | 不是按最低延迟排序 |
load-balance | 需要分配多个独立连接 | 不能理解为把一次下载的带宽简单相加 |
排查连接问题时，建议先使用 select 手动固定一个节点，确认系统代理、规则和实际网页都正常，再尝试 url-test。如果一开始就使用自动组，节点可能在测试期间切换，导致你无法判断到底是哪条线路在工作。
如果配置中存在多层策略组，沿着当前规则引用的组逐层展开，直到看到真正的节点名称。只在某个未被规则使用的地区组里选中节点，不代表普通网页流量会使用它。
选中节点后，如何确认实际流量确实走它
- 在代理页的主策略组中手动选定一个候选节点，记录节点名称。
- 确认当前模式不是“直连”，并确认系统代理已经开启；如果只想测试客户端自身，也要确认应用使用的是正确的本地代理端口。
- 打开客户端的连接记录或日志，访问一个固定网页，检查记录中的策略组、目标域名和出站方向。
- 如果客户端提供当前出口 IP 信息卡，只把它作为辅助线索；它能说明当前请求看到的出口，不代表所有规则都走同一个节点。
- 换到第二个节点重复同一访问，观察日志或出口信息是否发生对应变化。
验证边界要记住：浏览器能打开网页，不等于所有应用都已代理；代理端口能监听，不等于节点握手成功；节点显示已连接，也不等于视频、下载或办公服务一定稳定。项目说明显示，客户端的实际代理和 DNS 处理由 mihomo 核心完成，因此出现“已选节点但网页仍异常”时，应继续检查规则命中、系统代理、DNS 和日志，而不是只重复测速。
晚高峰复查与失败后的回滚方法
节点表现可能随时间、目标站点和本地网络变化。选出候选后，在你实际使用最频繁的时段再次测试，至少记录延迟、是否超时、真实目标表现和是否出现重连。若某节点只在单次测速中表现突出，但实际访问频繁失败，应保留其他候选，不要继续追逐最低数字。
- 所有节点都超时：先检查本地网络、配置是否更新、测试地址是否可达，再查看日志；不要直接断言所有节点同时失效。
- 测速正常但网页打不开：检查当前模式、规则命中、系统代理和 DNS；测速地址成功只证明该测试请求成功。
- 网页正常但下载慢：固定同一文件和时间段比较，确认是否是本地带宽、目标站点或其他软件占用。
- 自动组频繁切换：先切回
select固定节点；如果配置允许，再调整自动测试间隔或容差，避免在相近结果之间来回切换。
回滚时只需要回到原来的可用策略组或手动节点，不要为了添加测速组直接覆盖原订阅配置。任何自定义配置都应先备份；如果修改后代理组为空、配置加载失败或流量异常，先恢复原配置，再逐项添加变化。
常见问题
Clash Verge Rev 节点测速在哪里？
打开客户端的 Proxies 或“代理”页面，在节点卡片或代理组标题附近寻找测速、闪电或延迟按钮。不同版本的图标和布局可能不同；找不到时先确认当前配置已经加载并且代理组不是空的。
延迟最低的节点就是最快节点吗？
不是。延迟测试通常只测某个地址的响应时间，不能代表下载带宽、视频缓冲、办公连接或所有网站的实际表现。应使用相同目标完成真实复测，再结合稳定性选择。
应该测试单个节点还是整组节点？
第一次筛选用整组测速更高效，便于得到候选名单；两个节点结果接近时再做单节点复测。单节点测试还便于固定变量和查看日志。
url-test 和 select 哪个更适合选节点？
排查问题或需要固定出口时优先用 select；多个用途相近、可以接受自动切换时再用 url-test。url-test 根据测试结果自动选择，不等于持续下载速度排名。
节点显示测速成功，但实际网页打不开怎么办？
先固定该节点，检查当前模式是否为直连、系统代理是否开启、规则是否命中正确策略组，再查看连接记录和 DNS。测速成功只说明测试地址的请求成功，不能证明所有目标都可访问。