节点测速怎么选最快的节点？按延迟、速度、丢包和晚高峰复测筛选
简答：最快的节点不一定是延迟最低的节点。用 Clash Verge Rev 先在同一测试条件下排除超时节点，再比较客户端延迟、实际下载速度和连续测试中的超时次数，最后在你的使用高峰复测；网页、视频、会议、游戏和下载应按不同指标选择。本文是第三方使用指南，不是相关客户端或节点服务的官方页面。
定义：节点测速是用统一的测试地址、模式和时间，比较节点的响应延迟、实际带宽、连续可用性与目标业务表现，而不是只看一次延迟数字。
先看结论：最快节点要这样筛
如果你现在只会点击一次“测速”并按最低毫秒数排序，先不要直接下结论。Clash Verge Rev 的延迟测试本质上是通过选定节点发起 HTTP 请求；项目隐私说明写明，用户主动测试代理或策略组时，会通过该代理访问测试地址或配置的测试地址。因此，这个结果适合比较测试请求的响应时间，但不能单独代表下载速度，也不能直接换算成丢包率。可参考 Clash Verge Rev 隐私说明。
| 阶段 | 你要记录什么 | 处理方式 |
|---|---|---|
| 统一准备 | 同一设备、同一网络、同一模式、同一测试地址 | 关闭后台下载、云盘同步和视频播放，避免不同条件互相比较 |
| 批量初筛 | 延迟、测试是否成功、连续测试中的超时次数 | 先排除持续超时或无法完成测试的节点 |
| 实际速度 | 固定测速服务器或同一文件的下载速度 | 只比较同一地点、同一时间、同一工具下的结果 |
| 真实业务 | 目标网站打开、视频缓冲、会议语音或文件传输表现 | 保留与实际用途最匹配的节点，不盲目追求最低延迟 |
| 晚高峰复测 | 同一节点在高负载时段的延迟、速度和超时情况 | 选择表现变化较小的节点作为日常或备用节点 |
上表中的“淘汰”是本文的操作建议，不是客户端或平台规定的硬性阈值。你可以把时间、节点名称、模式、测试地址、延迟中位数、超时次数、下载速度和实际用途一起记下来，避免只凭一次测试结果换节点。
在 Clash Verge Rev 中完成第一轮节点测速
- 先更新配置。打开 Clash Verge Rev，进入配置或订阅页面，确认当前使用的是刚更新的配置文件。官方文档说明，客户端支持通过远程订阅或本地配置导入节点；如果订阅导入出现连接错误，可尝试文档列出的其他导入方式。参考 Clash Verge Rev 订阅导入文档。
- 固定代理模式。进入客户端的代理或策略组页面，先不要在规则模式、全局模式之间来回切换。Clash Verge Rev 文档将规则模式定义为按规则决定流量出口，全局模式则让流量从手动选择的节点或本地网络出去。为了比较节点，建议先固定一种模式，并记录模式名称。参考 Clash Verge Rev 名词解释。
- 执行批量延迟测试。在代理或策略组页面使用界面提供的延迟测试功能，等待一轮测试完成。不同版本的按钮位置和名称可能有差异，不要把一次 HTTP 测试结果写成“节点丢包率”。对同一批节点连续测试多轮，记录成功次数、超时次数和延迟变化。
- 先排除不可用节点。如果某个节点多次无法完成测试、经常超时，或在同一条件下反复出现异常结果，先将它放入待复核列表，不要因为某一次显示过低延迟就保留。这里统计的是客户端测试请求的成功与超时，不是 Windows 直连
ping得到的节点丢包率。 - 保留一组候选。从剩余节点中选出若干个延迟较低且测试结果较稳定的候选，再进入实际速度测试。不要只保留一个节点，因为单个节点在不同时间段的表现可能变化。
Clash Verge Rev 官方文档还说明，系统代理主要依赖应用遵守系统代理约定，而 TUN 模式通过虚拟网卡接管流量；因此，浏览器测试、命令行测试和不支持系统代理的程序，可能得到不同结果。测试时必须记录是系统代理还是 TUN 模式。参考 Clash Verge Rev 快速入门 和 系统代理与 TUN 模式说明。
延迟、速度、丢包和稳定性分别怎么看
| 指标 | 代表什么 | 适合判断什么 | 不能单独证明什么 |
|---|---|---|---|
| 延迟 | 测试请求往返并得到响应所需的时间 | 网页交互、接口响应和操作跟手程度 | 不能单独证明下载速度或持续稳定性 |
| 实际速度 | 通过代理传输数据时的吞吐表现 | 视频、文件下载、更新和大文件传输 | 不能代表所有网站和所有时间段 |
| 超时次数 | 连续测试中没有在设定时间内完成请求的次数 | 发现间歇性不可用或波动明显的节点 | 不能在没有连续测试的情况下推导出丢包率 |
| 稳定性 | 不同时间、不同请求和真实业务下表现是否持续 | 会议、长期办公和日常主力节点选择 | 不能只用一次测速结果确认 |
为什么最低延迟不一定最快？延迟测试只访问一个测试地址，数据量很小；实际下载还会受到节点出口带宽、目标网站方向、本地宽带、测速服务器、并发连接和时间段影响。假如一个节点响应很快，但持续下载时速度下降或频繁超时，它更适合作为低交互延迟候选，而不一定适合作为下载主力。
怎样测丢包更接近节点表现？优先在客户端内对同一节点连续进行多轮测试，记录完成次数和超时次数。如果只在 Windows 命令提示符中运行普通 ping，系统代理模式下通常测到的是本地到目标地址的直连路径，不能直接说明节点链路情况。只有当客户端明确支持转发 ICMP，且当前流量确实经过对应节点时，命令行结果才有进一步参考价值。本文不把一次 HTTP 延迟测试换算为丢包率。
第二轮：用实际速度和目标业务验证
- 统一测速工具。候选节点必须使用同一个测速网站、同一个测速服务器或同一个可公开访问的测试文件。不要拿节点 A 的客户端延迟、节点 B 的下载工具速度和节点 C 的视频体验直接排名。
- 关闭本地干扰。暂停系统更新、云盘同步、后台下载和其他视频播放；尽量使用同一 Wi-Fi 或网线环境。测速过程中不要同时改变 DNS、MTU、路由器或客户端内核，否则无法判断差异来自节点还是本地设置。
- 按用途验证。网页和接口交互优先看延迟与连续成功率；视频优先看启动、缓冲和持续播放；视频会议优先看语音是否断续、画面是否频繁降质；下载优先看持续吞吐和长时间是否降速。游戏还要关注实际应用的延迟波动与丢包，但普通系统
ping不能自动代表游戏流量。 - 固定时间复测。同一批候选至少在日常使用时间和你最容易变慢的时段各测一次。晚高峰结果只说明该时间和该网络环境下的表现，不应写成永久排名。
记录模板可以直接照抄：日期时间｜节点名称｜客户端模式｜测试地址或工具｜延迟｜成功/超时次数｜下载速度｜实际业务表现｜备注。如果测试工具没有提供丢包率，就填写“未直接测得”，不要用延迟数字代替。
按使用目的选择节点，而不是只选最低延迟
| 使用场景 | 优先观察 | 选择建议 |
|---|---|---|
| 网页浏览、后台操作 | 延迟、成功率、DNS 和页面打开速度 | 选择响应较快且连续测试少超时的节点 |
| 视频播放 | 持续速度、缓冲、目标服务方向 | 用同一视频或同一服务连续观察，不只看客户端延迟 |
| 视频会议、跨境办公 | 延迟波动、超时、语音和画面连续性 | 优先选择跨时段变化较小的节点，并保留备用节点 |
| 游戏或实时交互 | 实际应用延迟、抖动、丢包 | 在支持对应流量接管的模式下测试，普通直连 ping 不作为唯一依据 |
| 文件下载、系统更新 | 持续带宽、长连接稳定性、节点容量 | 进行较长时间的实际下载测试，观察是否中途降速 |
| AI 服务或特定网站 | 目标网站可连接性、响应时间和持续稳定性 | 直接用目标业务验证，通用测速地址只能作为初筛 |
如果多个节点速度接近，建议保留一个日常主力节点、一个不同地区或不同线路方向的备用节点，以及一个在当前网络下响应较快的候选。节点名称中的地区、线路或倍率只能作为筛选线索，不能代替实际测试；未核实的线路类型和服务承诺不要当作测速结论。
Clash 的 URL-Test 自动选择怎么用
如果你的配置使用 mihomo 内核，可以用 url-test 策略组进行周期性健康检查。mihomo 官方文档给出的字段包括 url、interval 和可选的 tolerance；其中 url 是健康检查地址，interval 以秒为单位控制周期测试，tolerance 用于控制切换所需的延迟差。参考 mihomo Url-Test 文档。
配置示例可以写成：
proxy-groups:
- name: "自动选择"
type: url-test
proxies:
- 节点A
- 节点B
- 节点C
url: "https://www.gstatic.com/generate_204"
interval: 300
tolerance: 50
这段配置只适合说明字段关系，不代表所有订阅都能直接粘贴使用。节点名称必须与配置中的实际名称一致；测试地址应能正常响应；如果策略组通过代理提供者引入节点，还要注意 mihomo 文档所说的检查范围和配置方式。通用字段文档还说明，健康检查地址用于测试，周期单位是秒，超时值和失败次数也可以单独设置。参考 mihomo proxy-groups 配置文档。
自动选择的结果仍然是“测试地址下的自动选择”，不是对所有网站的永久最快排名。遇到特定业务变慢时，仍应切换到手动选择并用目标网站复核。
三个常见结果异常，应该怎么处理
- 全部节点都超时：先检查配置是否更新成功、客户端是否真正启用代理、测试地址是否可访问，再固定模式重新测试。不要马上认定所有节点都不可用。
- 只有部分节点超时：记录超时节点和成功节点，重复测试确认是否稳定复现；反复超时的节点先移出候选，其他节点继续进行实际速度测试。
- 延迟很低但下载很慢：改用统一测速工具或同一文件做持续下载，检查本地后台流量和测速服务器；若只有某个目标网站慢，再用该目标业务验证，而不是继续按延迟排序。
- 客户端速度快、实际网站慢：检查规则模式是否把目标域名分到了直连或其他策略组，并确认测试时使用的节点与实际业务一致。系统代理和 TUN 的接管范围不同，必要时记录当前接管模式后再复测。
如果排查涉及 MTU，不要把 MTU 探测混入本页的节点排名流程。Windows 中的 ping -f -l 主要用于本地路径分片排查，不能直接测出节点带宽；建议先完成节点初筛，再单独处理 MTU 或 DNS 问题。
常见问题
节点测速看延迟还是看速度？
两者都要看，但顺序不同：先用延迟和测试成功率排除明显异常节点，再用统一工具比较实际速度，最后用目标网站或应用验证。网页交互更看重响应和稳定性，下载和视频更看重持续带宽。
客户端显示的延迟就是节点丢包吗？
不是。延迟测试通常是通过节点访问测试地址并等待 HTTP 响应，单次结果不能直接换算丢包率。要观察间歇性问题，应对同一节点连续测试并记录超时次数；如果工具不显示丢包率，就明确写“未直接测得”。
Windows 的 ping 能不能用来选最快节点？
只能作为本地网络基线或特定条件下的辅助信息。系统代理模式下，普通 ping 往往不会经过客户端节点；因此它测到的可能是本地到目标主机的直连路径。不能把这个结果直接当成节点延迟或节点丢包率。
为什么白天最快的节点，晚些时候会变慢？
一次测速只代表当时的设备、网络、测试地址和节点状态。应在你实际容易变慢的时段复测，并记录同一节点的延迟、超时次数、持续速度和目标业务表现。没有连续观测，就不能下永久排名结论。
URL-Test 会不会自动选到所有网站都最快的节点？
不会。URL-Test 按配置的健康检查地址进行周期测试，结果反映的是该地址和当时条件下的响应表现。遇到特定网站、视频会议或下载任务，仍需用目标业务手动复核。
应该保留几个节点？
没有统一固定数量。实用做法是保留一个日常主力、一个备用和若干经过复测的候选，数量以方便切换和记录为准。不同地区、线路或倍率只是筛选线索，不能代替实际测速。
常见问题
节点测速看延迟还是看速度？
先用延迟和测试成功率排除明显异常节点，再用统一工具比较实际速度，最后用目标网站或应用验证。不同用途的优先指标不同。
客户端显示的延迟就是节点丢包吗？
不是。客户端延迟测试通常是 HTTP 请求响应时间，不能直接换算丢包率。应连续测试同一节点并记录超时次数；没有丢包统计时就写未直接测得。
Windows 的 ping 能不能用来选最快节点？
只能作为本地网络基线或特定条件下的辅助信息。系统代理模式下，普通 ping 往往不会经过节点，结果不能直接代表节点延迟或丢包。
为什么白天最快的节点，晚些时候会变慢？
一次测速只代表当时条件。应在实际容易变慢的时段复测，并比较同一节点的延迟、超时次数、持续速度和目标业务表现。
URL-Test 会不会自动选到所有网站都最快的节点？
不会。URL-Test 按配置的健康检查地址周期测试，只代表该地址和当时条件下的表现，特定网站或业务仍需单独验证。