Clash节点测速怎么选？按延迟、稳定性和用途判断
简答：Clash节点测速不能只选延迟最低的那个。更可靠的方法是：先在同一个策略组内测试具体节点，再连续复测至少三轮，记录延迟、超时次数和波动，最后用实际目标网站或应用验证。网页浏览优先看稳定性，视频和下载还要看持续吞吐，实时通信则要重点观察延迟波动与连接是否中断。
定义：Clash节点测速，是通过客户端或 mihomo 的健康检查地址，对具体节点或策略组发起可重复的网络请求并记录响应延迟与失败情况；它是筛选入口，不等于完整的下载测速、真实业务体验或所有流量都已通过代理。
先用一分钟速查：Clash节点到底怎么选
如果你现在只想先选一个节点，可以按下面顺序操作：
- 先找具体节点：不要只测试“代理”“自动选择”这类上层策略组。进入客户端的代理或策略组页面，确认当前组内有哪些具体节点；不同客户端的菜单名称可能不同，以当前界面为准。
- 固定测试条件：使用同一个测速地址、同一个超时时间和同一网络环境。mihomo API 的节点延迟测试需要提供
url和timeout参数，返回的是该次测试的毫秒数。可参考 mihomo API 文档。 - 连续测三轮：每轮间隔一小段时间，记录每个节点的结果。不要把一次超低延迟直接当成长期表现。
- 先淘汰异常节点：多次超时、结果大幅波动或测速成功但实际目标打不开的节点，优先放到候选列表后面。
- 按用途复核：网页、视频、下载和实时通信关注点不同，最后应使用你真正要访问的目标验证。
| 现象 | 优先观察 | 处理建议 |
|---|---|---|
| 延迟低但网页打不开 | 规则、DNS、连接日志、目标站响应 | 确认请求是否进入预期策略组，不要只看节点毫秒数 |
| 延迟不低但网页稳定 | 多轮波动、超时比例 | 网页浏览可保留，继续观察高峰期表现 |
| 测速经常超时 | 测速地址、网络环境、节点可达性 | 换同一组内其他节点复测，避免直接修改多个配置项 |
| 自动选择频繁切换 | 测试间隔、延迟差距、连接稳定性 | 先固定一个手动节点验证，再判断是否继续使用自动组 |
先分清三类对象：具体节点、自动选择和故障转移
具体节点是一个明确的代理出站；自动选择组会根据健康检查结果在成员中选择；故障转移组则通常按照成员顺序，在当前节点不可用时尝试后续成员。mihomo 文档将 url-test 定义为根据 URL 测试结果选择延迟较低的节点，并提供 tolerance 字段控制节点切换的延迟容差；fallback 则按代理顺序选择可用节点。具体行为应以当前内核和配置为准，可查看 url-test 文档和 fallback 文档。
| 方式 | 适合场景 | 注意事项 |
|---|---|---|
| 手动选择 | 排查问题、固定办公线路、观察单个节点 | 便于记录，节点失效后不会自动替换 |
| url-test | 希望在多个节点中按健康检查结果自动选择 | 测试 URL 不是你的真实业务地址，仍需实际访问验证 |
| fallback | 更关注不可用时按顺序回落 | 节点顺序会影响结果，不等于始终选择延迟最低者 |
在排查阶段，建议先从自动组切换到具体节点，记录“节点名称—测试时间—延迟—是否超时—目标是否可访问”。问题定位后，再决定是否恢复自动选择。
延迟测试测的是什么？为什么不等于下载速度
mihomo 的延迟接口会对指定节点发起带有测试地址的请求，并返回毫秒级延迟；策略组接口还可以返回组内节点的延迟结果和历史记录。这个数字反映的是该节点到指定测试地址的一次请求响应时间，并不是完整的带宽、持续下载速度或视频缓冲能力。相关字段和返回结构可参考 mihomo API 文档。
因此，以下几种结果并不矛盾：
- 延迟低但下载慢：建立连接较快，但持续传输能力、拥塞情况或服务端限速可能不同。
- 延迟高但网页可用：网页请求数量少、内容体积小，稳定性可能比极低延迟更重要。
- 测速成功但目标打不开：测速地址可达，不代表目标域名的规则、DNS、TLS 或应用连接流程都正常。
- 不同客户端数值不能直接横比：测试地址、超时时间、内核设置、网络接口和测试时刻可能不同。
如果配置启用了 mihomo 的统一延迟，内核会尝试减少不同代理类型在连接握手等环节造成的延迟差异；这仍然不代表测速数字可以替代真实业务测试。相关说明见 mihomo 全局配置文档。
三轮复测怎么记录：用稳定性淘汰偶然低延迟
建议在不改变本地网络、测速地址和超时时间的情况下，至少完成三轮测试。可以复制下面的记录模板到表格中：
| 节点 | 第1轮 | 第2轮 | 第3轮 | 超时次数 | 波动观察 | 实际访问 |
|---|---|---|---|---|---|---|
| 节点A | 填写毫秒数 | 填写毫秒数 | 填写毫秒数 | 0或次数 | 小/中/大 | 成功/失败 |
| 节点B | 填写毫秒数 | 填写毫秒数 | 填写毫秒数 | 0或次数 | 小/中/大 | 成功/失败 |
不建议凭一个固定数值判断“好”或“坏”。更实用的排序方法是：
- 先排除多轮超时或实际目标无法访问的节点；
- 再比较剩余节点的延迟波动，而不是只比较最低值；
- 网页浏览优先选择连续可用且波动较小的节点；
- 视频或下载场景要增加实际文件、页面或应用测试，并观察持续传输是否中断；
- 实时通信场景要观察连接是否反复重建，不能只看一次测速。
如果要比较晚高峰表现，应在不同时间段重复同一套记录，而不是把白天的一次结果当成全天结论。节点名称中的地区、线路或协议标签只能作为筛选线索，不能替代实际测试。
按用途选节点：网页、视频、下载和实时通信分别看什么
| 用途 | 主要指标 | 复测方法 | 不应单独依据 |
|---|---|---|---|
| 网页浏览 | 可访问性、延迟波动、超时次数 | 打开几个实际目标页面，结合连接记录确认请求是否命中预期策略 | 单次最低延迟 |
| 视频观看 | 持续吞吐、缓冲恢复、长连接稳定性 | 使用实际视频页面观察开始播放、清晰度切换和中途缓冲 | 测速地址一次成功 |
| 文件下载 | 持续速度、连接保持、失败重试 | 用你实际使用的下载源进行小规模重复测试，记录是否中断 | 节点地区名称 |
| 游戏或实时通信 | 延迟波动、连接重建、UDP或应用协议兼容性 | 在应用内观察延迟变化和掉线情况，必要时查看客户端连接日志 | HTTP延迟测试 |
| 跨境办公 | 办公系统登录、文件同步、会议连接和长时间稳定性 | 按真实办公流程逐项验证，并记录时间段和网络环境 | 只测试一个公共网页 |
如果客户端处于规则模式，实际请求可能根据域名、IP或规则集进入不同策略；全局模式、系统代理和 TUN 模式也可能改变哪些应用能够进入代理。测试时要记录当前模式，并通过连接记录确认目标请求实际使用的策略组。若出现“连接成功但网页打不开”，可继续参考站内的Clash连接成功但打不开网页排查指南。
常见异常分流：测速结果与实际体验不一致
测速超时，应该立刻换节点吗？
先不要同时修改 DNS、TUN、规则和订阅。确认测速地址可以访问、当前网络没有临时波动，再用同一条件测试同组其他节点。如果只有一个节点超时，可先将其标记为待排查；如果全部节点都超时，应优先检查本地网络、客户端运行状态、系统代理或订阅配置。
延迟很低，但目标网页打不开怎么办？
在客户端连接记录中查找该目标域名，确认请求是否出现、命中了哪个规则和策略组；随后检查 DNS 解析、IPv4/IPv6、TLS 错误和目标站返回状态。健康检查成功只能说明测试地址的请求完成，不能直接证明目标业务也可用。
自动选择为什么频繁切换节点？
先记录自动组的测试地址、测试间隔和节点历史，再临时手动固定一个节点观察。如果手动节点稳定而自动组频繁切换，可检查延迟差距是否很小、测试地址是否适合当前网络，以及当前客户端是否对自动组进行了固定选择或缓存。不要只通过提高或降低参数来掩盖实际连接问题。
节点名称写着某个地区，出口一定在该地区吗？
不一定。名称只能作为筛选线索，出口地区应通过实际出口信息和目标业务结果交叉确认；即使出口地区符合预期，也不能据此断言所有应用流量都经过同一路径。对具体归属、线路类型和服务状态无法核实的内容，应以服务方当前说明和实际复测为准。
复测后的回滚与验证清单
- 保留原来的策略组选择和配置备份，不要为了测速直接覆盖原配置。
- 完成测试后先恢复到手动节点或原自动组，确认网页、应用和办公连接是否恢复。
- 在连接记录中核对目标域名、规则命中和实际使用的节点。
- 如果修改过测速地址、策略组或客户端模式，逐项恢复，避免多个变量同时变化。
- 在不同时间段重复测试，并把结果标注为“本地网络、测试地址、客户端模式和时间”的组合结果，而不是永久排名。
不同版本的客户端界面、策略组字段和内核行为可能变化。本文只提供通用判断流程，具体菜单、字段和可用功能请以当前客户端与内核文档为准。本站是第三方使用指南站，不是相关客户端或节点服务的官方网站。
常见问题
Clash节点测速看延迟越低越好吗？
不一定。延迟只反映指定测速地址的一次请求响应时间，不能代表持续下载速度、视频缓冲或实时通信稳定性。应先排除超时和实际目标不可用的节点，再比较多轮结果和波动。
Clash测速成功但网页打不开，问题通常在哪里？
测速成功只说明测试地址可达。请检查连接记录中的目标域名、规则命中、实际策略组、DNS解析、IPv4/IPv6和 TLS 错误，确认请求是否真的进入预期节点。
Clash自动选择和手动选择哪个更好？
排查问题时手动选择更容易复现和记录；日常使用时，url-test 可按健康检查结果自动选择，fallback 更侧重按顺序回落。具体效果取决于当前配置、测速地址和客户端内核版本。
测试几次才能判断一个Clash节点？
至少进行三轮，并保持测试地址、网络环境、超时时间和客户端模式一致。若要判断晚高峰表现，还应在不同时间段重复同一流程。一次最低延迟只能作为初筛依据。
节点名称中的地区或线路标签能直接作为选择依据吗？
不能直接作为结论。地区、协议或线路标签可以帮助缩小范围，但实际出口、规则命中和业务可用性仍需通过出口信息、连接日志和真实目标访问交叉验证。