Clash 节点测速怎么选最快节点？
简答：最快节点不一定是 Clash 中显示延迟最低的节点。建议先批量测速排除超时节点，再对候选节点重复测试稳定性，最后用实际网页、视频会议、视频播放或文件下载验证；只有三项都合适，才适合作为常用节点。
定义：Clash 节点测速，是通过指定测试地址向每个代理节点发起请求并记录响应耗时的过程，显示的 ms 主要反映测试请求的延迟，不等于真实下载速度。
先记住：最低 ms 不等于最快节点
Clash 面板中的延迟通常是代理节点访问测试地址所需的响应时间。它适合做第一轮筛选，但不能单独代表带宽、持续速度、丢包或晚高峰表现。Clash Verge Rev 的隐私说明也明确提到，延迟测试会通过被测代理向测试地址发起 HTTP 请求，测试地址还可以由用户配置，结果因此会受到测试地址、当前网络和节点协议影响。可查看Clash Verge Rev 官方隐私说明。
最实用的判断顺序是：先看是否成功，再看延迟和波动，最后看真实场景速度。例如，一个节点显示 80ms，但持续下载速度很低；另一个节点显示 130ms，却能稳定播放视频或完成文件传输，后者对下载和视频使用可能更合适。
| 指标 | 用途 | 不能证明什么 |
|---|---|---|
| 延迟 ms | 初步判断响应快慢 | 不能证明下载速度和长期稳定性 |
| 多次测试结果 | 观察波动和偶发超时 | 不能完全代表晚高峰表现 |
| 丢包或频繁超时 | 排除不稳定节点 | 单次失败不能直接证明节点永久不可用 |
| 持续下载、视频或会议测试 | 验证实际使用体验 | 不能脱离本地 Wi-Fi、运营商和时间比较 |
三步选节点：初筛、复测、实测
- 初筛：打开 Clash 的代理或策略组页面，找到“延迟测试”“测试全部”或类似按钮。不同客户端和版本的文字可能不同，先确认当前选择的是目标代理组，而不是只测试单个节点。批量测试后，先排除超时、无响应和明显高于其他节点的项目。不要因为某个节点暂时显示最低 ms 就立即固定使用。
- 复测：保留 3—5 个候选节点，在相同网络、相同代理模式和相同测试地址下连续测试 3 次以上。记录每次结果，例如 92/95/98ms 通常比 70/260/超时更容易保持稳定。测试时不要同时切换 Wi-Fi、移动数据、TUN 模式或 DNS，否则无法判断变化来自节点还是本地设置。
- 实测：根据用途选择一个真实任务。网页和接口访问重点看打开速度；游戏或交互操作重点看延迟波动和丢包；视频会议重点看连续稳定性；视频播放重点看能否持续缓冲；大文件下载重点看持续速度。实测时固定同一个文件、视频清晰度或网站，避免只用一次瞬时速度下结论。
可直接照做的选择清单：① 测试成功；② 连续结果没有大幅跳变；③ 实际任务没有频繁卡顿或重连；④ 换回直连测试后，能区分问题来自节点还是本地网络；⑤ 记录测试时间，早晚高峰分别复测。
按使用场景选择：不要所有需求都追求最低延迟
| 使用场景 | 优先观察 | 选择建议 |
|---|---|---|
| 网页、普通办公 | 延迟、打开速度、失败率 | 选择延迟较低且连续访问不报错的节点 |
| 游戏或实时交互 | 延迟波动、丢包、重连 | 优先稳定，不能只看一次最低延迟 |
| 视频会议 | 持续稳定性、上行质量、卡顿 | 用固定会议或通话场景连续观察，不要只做一次测速 |
| 视频播放 | 持续吞吐、缓冲、清晰度保持 | 播放同一内容一段时间，再与其他候选节点比较 |
| 大文件下载 | 持续下载速度、断流和速度波动 | 使用同一文件测试，避免把瞬时峰值当成最终结果 |
节点地区、线路类型、协议和本地运营商都会影响结果。同一地区节点不一定拥有相同出口线路；跨境链路距离更长时，延迟可能更高，但实际吞吐未必更低。不同协议的握手过程也可能不同，因此不建议把不同协议节点的单次延迟直接当成完整排名。
用 url-test 自动选择：interval 与 tolerance 怎么设
如果配置使用 Mihomo 内核，可以通过 url-test 代理组按测试结果自动选择节点。官方文档示例包含 url、interval 和可选的 tolerance 字段；其中 tolerance 表示节点切换容差，单位是毫秒，具体字段可核对Mihomo 官方文档中的 url-test 配置。
proxy-groups:
- name: 自动选择
type: url-test
proxies:
- 节点A
- 节点B
- 节点C
url: "https://www.gstatic.com/generate_204"
interval: 300
tolerance: 50interval 控制自动测试的时间间隔，tolerance 用于减少节点之间只有小幅差异时的频繁切换。上面的数值只是字段示例，不代表所有网络都应使用同一组参数。修改前先备份配置；如果出现频繁跳节点，可提高容差或暂时改用手动选择；如果自动测试结果全部失败，应先恢复原配置，确认普通代理连接正常后再调整。
配置中的测试地址必须是当前网络能够访问、返回结果稳定的地址。Clash Verge Rev 的源代码显示，客户端会校验测试 URL，并在未设置自定义地址时使用默认测试地址；这属于客户端实现细节，具体行为仍应以所用版本为准，可参考Clash Verge Rev 官方延迟测试实现。
测速失败、全部超时、低延迟但实际很慢怎么办
情况一：只有个别节点超时
先重新测试一次，并确认订阅没有过期、节点信息没有被截断。若同一节点连续超时，而其他节点正常，可先将它从候选列表中移出；不要仅凭一次超时判断整个订阅或客户端故障。
情况二：全部节点都失败
- 先关闭 TUN，改用普通系统代理模式测试，确认基础代理是否能连接。
- 检查本机时间、网络连接、防火墙和代理端口是否正常。
- 更换测试地址后再测，但不要同时修改 DNS、MTU 和规则，避免无法定位变量。
- 查看客户端日志，区分订阅解析失败、端口冲突、DNS 失败和节点握手失败。
- 如果普通代理也无法访问，再检查本地网络或订阅本身；确认基础连接后，才继续排查 TUN、DNS 或规则。
情况三：延迟很低，但下载或视频很慢
这通常说明延迟指标与持续吞吐不是同一件事。固定测试文件、时间和网络，连续下载一段时间并记录平均表现；再换一个候选节点复测。若所有节点都慢，先做直连基准测试，排除 Wi-Fi 信号、运营商拥塞、本机后台下载或磁盘写入速度问题。
情况四：自动选择频繁跳节点
先切换到手动选择，确认多个节点都能正常连接，再检查 interval 是否过短、tolerance 是否过小，以及测试地址是否稳定。每次只改一个字段并保留回滚配置。
结论：一张节点选择速查卡
- 网页办公：优先低延迟、低失败率和打开稳定。
- 游戏或实时交互：优先低波动和低丢包，不追求单次最低 ms。
- 视频会议：优先持续稳定，必须做连续通话或传输验证。
- 视频播放：优先持续吞吐和缓冲表现。
- 大文件下载：优先长时间平均速度，不看瞬时峰值。
- 自动切换：使用 url-test 前先验证测试地址、interval、tolerance 和回滚方式。
推荐：如果你需要对跨境办公、线路延迟、丢包和节点连接进行更系统的复测，可了解边界云加速的网络诊断服务，再结合自己的客户端结果做选择。
本文为第三方使用指南，未核实任何特定订阅服务的价格、状态、速度或可用性；相关服务信息应以其公开页面和官方说明为准。
常见问题
Clash 节点测速显示多少 ms 才算快？
没有适用于所有网络和用途的固定标准。ms 只能作为初筛指标，网页和办公可优先比较相近条件下的低延迟节点；游戏、会议和视频还必须观察波动、丢包和持续表现。
为什么 Clash 显示延迟很低，实际下载却很慢？
延迟测试主要反映测试请求的响应时间，不等于持续带宽。节点拥塞、线路方向、协议、测试地址、本地 Wi-Fi 或运营商状态都可能导致低延迟但下载慢，应使用相同文件和相同网络做持续下载对比。
Clash 节点测速全部超时，应该先改 DNS 吗？
不建议一开始同时修改 DNS、MTU、TUN 和规则。先关闭 TUN，使用普通代理模式确认基础连接，再检查端口、日志、订阅和防火墙；只有确认问题与域名解析有关时，再单独测试 DNS。
url-test 会不会因为延迟差一点就频繁切换？
可能发生，尤其是测试结果接近、测试间隔过短或容差过小时。可以先手动选择节点确认基础连接，再适当调整 interval 和 tolerance，每次只修改一个参数并保留原配置。
测速时要不要切换 Wi-Fi 和移动网络？
不要在同一轮对比中切换。应固定网络、客户端模式、测试地址和测试时间；如果要比较不同网络，应分别建立测试记录，否则无法判断差异来自节点还是本地网络。