Clash怎么测速选择节点？延迟、稳定性与实际速度判断方法
简答：Clash里通常进入“代理”或“Proxies”页面，在目标策略组点击测速按钮，先批量比较节点延迟，再通过两到三轮复测观察波动和失败情况。低延迟只说明测试地址响应较快，不代表下载速度、视频体验或会议稳定性一定更好。最后切换节点，并用实际目标网站或应用确认新连接确实经过了目标节点。
定义：Clash节点测速，是通过指定测试地址经某个节点发起请求并记录响应延迟或是否超时，用来判断节点的可达性和相对响应表现。
先做这三步：最快完成测速和选节点
- 打开代理页面：在 Clash Verge Rev、FlClash 或其他兼容 Clash/Mihomo 内核的客户端中，进入“代理”“Proxies”或类似页面，找到包含节点的策略组。
- 执行批量测速：点击策略组或节点旁的测速按钮；部分界面显示为测速图标、Test All、延迟测试或重新测试。等待结果出现后，先排除 Timeout、未连接和明显高于其他节点的结果。
- 复测并实际验证：不要只凭一次最低延迟做决定。至少在两个到三个时间段重复测试，再切换到候选节点访问实际需要使用的网站或应用。
不同客户端的按钮名称和位置可能不同，无法确认时以当前版本界面和客户端文档为准。Clash Verge Rev 的隐私说明确认，用户主动进行延迟测试时，客户端会经节点向测试地址发送 HTTP 请求；测试地址也可能由用户配置。可参考Clash Verge Rev 项目对延迟测试的说明。
测速页面里，节点、策略组和自动选择是什么关系？
节点是具体的代理出口；策略组是把多个节点或其他策略组放在一起的选择规则。你在代理页面看到的“Proxy”“节点选择”或地区分组，往往是策略组，不一定是单个节点。
手动选择适合你想固定使用某个节点的情况；URL-Test会按测试地址比较响应结果并倾向选择延迟较低的节点；Fallback更侧重当前节点不可用时按顺序切换到可用节点。Mihomo 官方配置示例明确区分了这两类策略：URL-Test按测试结果选择，Fallback按节点顺序进行可用性切换，详情可查看Mihomo官方配置示例。
因此，测速节点和切换策略组不是一回事：你可以先测试组内节点，再决定是手动固定、交给URL-Test自动选择，还是使用Fallback处理临时不可用。
延迟、Timeout和下载速度分别代表什么？
| 结果 | 通常表示 | 不能直接说明 | 建议 |
|---|---|---|---|
| 较低延迟 | 经当前测试地址响应较快 | 不等于下载速度一定高 | 作为初筛指标，再做实际访问验证 |
| 延迟波动大 | 链路或节点状态不稳定，也可能受测试时间影响 | 不能只看最低一次结果 | 重复测试并记录平均表现和失败次数 |
| Timeout | 在设定时间内没有获得符合条件的响应 | 不一定能证明节点永久失效 | 换测试地址、稍后复测，并检查本地网络 |
| 访问速度慢 | 可能与出口、目标站、拥塞、协议或本地网络有关 | 不能由一次延迟值解释 | 直接测试目标网站或下载任务 |
Mihomo API文档把延迟定义为针对指定测试URL测得的毫秒值，并允许对策略组或单个节点发起测试；因此，延迟结果始终与“节点+测试地址”这一组合有关，不能脱离测试地址理解。相关字段和接口说明见Mihomo API文档。
如果你的目标是下载、视频或大文件传输，客户端的普通延迟测试不能替代带宽测试。实际速度还会受到目标网站、出口位置、服务器负载、本地Wi-Fi、运营商线路和当前时段影响。
推荐的多轮测速方法：不要只挑最低毫秒数
- 第一轮批量初筛：在同一个策略组内测试所有节点，去掉Timeout、未连接和明显异常的节点。
- 第二轮重复测试：对剩余节点再次测速，记录每个节点的结果是否稳定。例如某节点第一次很低、第二次明显升高，就不要只保留第一次最低值。
- 第三轮按场景验证：分别打开你实际使用的网站、视频服务、代码仓库、办公系统或会议应用。不同目标的访问路径不同，测试地址的结果不能完全替代真实业务验证。
- 保留两个候选：一个作为日常使用节点，一个作为备用节点。不要把所有判断都交给自动选择，也不要在一个节点异常时反复刷新同一结果。
建议记录“节点名称、测试时间、延迟、是否超时、实际访问结果”五项信息。这样比单看颜色或排序更容易判断长期稳定性。
按使用场景选择节点：应该优先看什么？
| 使用场景 | 优先观察 | 选择建议 |
|---|---|---|
| 普通网页 | 可达性、延迟、规则是否命中 | 优先选延迟稳定且页面能正常打开的节点 |
| 视频或大文件 | 持续下载速度、缓冲、长连接稳定性 | 不要只按最低延迟排序，必须做实际播放或下载验证 |
| 在线会议或实时通信 | 延迟波动、丢包、断线和上行表现 | 优先稳定节点，必要时保留手动备用节点 |
| 软件更新或代码下载 | 目标站点可访问性、持续传输速度 | 分别验证目标域名，避免只测试通用地址 |
| 对响应时间敏感的应用 | 稳定延迟、连接建立速度 | 先筛掉波动明显的节点，再比较实际连接表现 |
一个节点对测试地址响应快，并不表示它对所有目标网站都走相同路径。若只有某个网站慢，应先确认规则模式是否把该域名分配给了正确的策略组，再判断是否需要换节点。
自动选择、故障转移和手动选择怎么选？
手动选择：适合你已经通过多轮测试找到稳定节点，或者某个业务必须固定出口的情况。切换后要重新建立连接，避免旧连接仍沿用原节点。
URL-Test：适合节点数量较多、希望根据测试结果自动挑选的情况。但它依赖测试地址和检查周期，自动选出的节点仍需要用真实业务验证。Mihomo官方文档中的URL-Test配置包含测试URL和检查间隔，具体字段以当前文档为准。
Fallback：适合更关心“当前节点失效后能否切到备用节点”的情况。官方配置说明显示，Fallback会在当前节点超时时按代理顺序选择可用节点，可查看Mihomo Fallback策略组文档。
简单决策可以这样做：节点少且你需要可控，就用手动选择；节点多且希望自动挑选，就考虑URL-Test；需要主备切换，就考虑Fallback。具体是否支持、名称如何显示，要以客户端当前版本为准。
测速后仍打不开网页：按现象排查
- 测速有结果，但网页打不开：先检查系统代理是否开启，确认客户端的本地代理端口没有被其他程序占用；再看规则模式是否把目标域名分到了直连或错误的策略组。
- 节点全部Timeout：先确认订阅或配置仍然有效，再切换网络测试；如果只有某个测试地址失败，可更换测试地址后复测。不要仅凭一次Timeout断言节点永久失效。
- 显示已连接，但应用没有走代理：桌面端检查系统代理，移动端检查VPN或TUN状态；如果只有浏览器异常，还要检查浏览器自身代理设置。
- 切换节点后旧页面没变化：关闭并重新打开目标连接，或重新加载页面。长连接、下载任务和应用缓存可能不会因为切换节点立即迁移。
- 规则模式下不同网站表现不同：查看连接记录或请求日志，确认目标域名实际命中了哪个策略组；必要时临时使用全局模式做对照测试，验证问题是在规则还是节点。
排查完成后建议恢复原来的规则模式和代理选择，不要长期用全局模式替代规则配置。
适用范围与注意事项
本文适用于已经导入配置、能够打开代理或策略组页面的 Clash/Mihomo 客户端用户。不同客户端、系统和版本的菜单名称可能不同，本文不把某个界面路径当作所有客户端的统一规则。
本站是第三方使用指南站，不是任何客户端或节点服务的官方网站。涉及配置来源、服务状态、价格和可用性的信息，应以对应服务或软件的公开说明为准，本文未对具体服务商作测速、排名或可用性承诺。
常见问题
Clash测速入口在哪里？
通常在“代理”“Proxies”或策略组页面，节点或策略组旁会有测速图标、Test All、延迟测试或重新测试按钮。不同客户端名称可能不同，以当前版本界面为准。
Clash测速显示Timeout是什么意思？
表示节点通过当前测试地址发起请求后，在设定时间内没有获得符合条件的响应。先确认网络、配置和测试地址，再换地址或稍后复测，不要仅凭一次Timeout判定节点永久失效。
为什么延迟最低的节点下载还是很慢？
延迟测试只反映节点经指定测试地址的响应时间，不等于持续下载带宽。下载速度还会受到目标网站、出口路径、拥塞、本地网络和时段影响。
测速后怎么确认切换真的生效？
先确认策略组当前选中的节点名称，再重新打开目标网页或应用连接；同时查看客户端连接记录或请求日志，确认目标请求命中了预期策略组。
URL-Test和Fallback哪个更适合自动选节点？
URL-Test更偏向根据测试结果选择相对低延迟节点；Fallback更偏向当前节点不可用时按顺序切换备用节点。具体支持字段和界面名称以当前客户端及其内核文档为准。
为什么测速结果和实际访问体验不一致？
测试地址、目标网站和实际应用的网络路径可能不同。还可能受到规则分流、DNS、长连接复用、服务器负载和本地网络影响，因此应把延迟初筛与真实业务验证结合起来。