一、先确认节点被使用，再比较四项指标
选择 Clash 节点，不能只把列表按延迟从小到大排序。延迟关系到响应速度，倍率关系到流量消耗，地区关系到出口位置，协议关系到客户端兼容性与传输方式。四项都合适，仍要用实际业务验证稳定性。
开始前，先完成订阅导入并启用配置。桌面客户端通常在「代理」页选择策略组，在「连接」页查看请求实际使用的规则和出口；不同客户端的菜单名称会有差异。若还未完成首次配置，可先按订阅导入说明操作。
- 在「代理」页找到目标网站使用的策略组，记录原来的选项。
- 测试期间改为手动选择，避免自动测速组在测试中途更换节点。
- 关闭旧页面或结束相关旧连接，再重新发起请求；已建立的连接通常不会随节点选择立即迁移。
- 在「连接」页确认目标请求走向刚选的节点，而不是
DIRECT或另一组策略。
二、延迟怎么看：低数值不等于下载快
客户端测的是测试请求，不是所有业务
Clash 类客户端常见的节点测速是向指定 URL 发起请求，测量经节点访问该地址的耗时，并非简单的 ICMP ping。测试 URL、连接复用、DNS、内核实现以及节点当时的负载，都会影响读数。比较时必须使用同一个测试地址和同一种测试方式。
例如，A 节点显示 45 ms，B 节点显示 90 ms，只能说明这一次测试中 A 对测试目标的响应更快。若 A 的带宽拥塞，打开大文件可能反而比 B 慢。一个节点访问测试站点正常，也不能证明它访问视频站点或游戏服务器正常。
用重复测试区分偶然低延迟与稳定低延迟
- 先少量筛选：选 3 个符合地区要求的节点，每个测 5 次，间隔约 10 秒，不要连续对整份订阅反复测速。
- 看波动：示例 A 为 42、45、43、280、46 ms；示例 B 为 78、81、79、83、80 ms。A 的典型响应更快，但出现了一次明显尖峰，需要进一步观察。
- 记录超时：5 次里出现 2 次超时，比单次最低值更值得关注。超时也可能来自测试目标或本地网络，换一个已知可用目标复核。
- 补一次晚间测试：白天表现与 20:00—23:00 的拥塞情况可能不同，长期选择应覆盖实际使用时段。
这些数字是读数示例，不是本站实测排名。网页浏览优先看响应和失败率；视频与下载还要看持续吞吐；语音与游戏更关注抖动、丢包以及 UDP 是否真正可用。
三、倍率怎么看：先算流量，再判断是否值得
节点名中的 0.5x、1x、2x 通常是服务提供方的流量计费标注，不是 Clash 协议字段，也不是速度倍数。名称中的「2 倍」不能解释为带宽翻倍。客户端一般只是展示名称，不负责决定服务端如何扣量。
| 名称标注 | 示例传输量 | 按倍率估算扣量 | 需要核对的事项 |
|---|---|---|---|
| 0.5x | 10 GB | 5 GB | 是否限时、限地区或另有速率限制 |
| 1x | 10 GB | 10 GB | 上传与下载是否均计入 |
| 2x | 10 GB | 20 GB | 额外成本是否换来所需线路或出口 |
上表假定“被计费的总传输量 × 倍率”就是扣量口径。实际以服务说明和账户统计为准，客户端流量、运营商流量与账户扣量可能因统计范围和单位不同而有差异。节点名称没有标注时，不要自行认定为 1x。
按月用量选择，不按名称猜性能
假设每月视频流量约 60 GB，使用 2x 节点会对应约 120 GB 的计费量；同一口径下，0.5x 则约为 30 GB。若低倍率节点能稳定满足播放需求，就没有必要只因名称带有「专线」而换到高倍率。反过来，低倍率节点频繁缓冲，也不适合承担实时会议。
速度测试本身同样传输数据。若以 100 Mbps 持续下载 30 秒，理论数据量约为 375 MB，尚未考虑协议开销。限量套餐应先用短测试筛选，再对少数候选节点做持续验证。
四、地区怎么看：区分入口位置与实际出口
节点名里的「香港」「日本」「美国」通常描述预期出口地区，但命名由提供方决定。有些线路先进入中转服务器，再从另一地区出站；客户端配置中的 server 地址也可能只是入口。入口距离近，不等于出口一定近。
按需求核对出口，而不是只看国旗
- 一般浏览：先选距离与路由较合适的地区，比较晚高峰响应和连接成功率。地理距离只是参考，运营商互联和线路绕行同样重要。
- 地区内容：使用目标服务认可的出口地区，并遵守其服务条款。IP 查询站显示某地区，不代表所有平台都会给出相同判断。
- 工作账户：优先稳定出口，减少短时间跨地区反复登录。节点重连后是否更换 IP，需要另行观察，名称相同不代表固定 IP。
- 游戏：以游戏服务器所在地区和实际路由为准。到代理入口只有 20 ms，也不意味着到游戏服务器只有 20 ms。
验证出口时，在「连接」页确认 IP 查询请求确实走了选定节点，再查看查询结果。随后直接打开目标服务做验证。分流规则可能让两个网站使用不同出口，因此一个查询页面的结果不能代表所有应用。
五、协议怎么选：兼容性优先，再看网络表现
订阅中的协议必须由当前内核支持。原版 Clash 与 Clash Meta（现常称 mihomo）的协议支持范围不同，客户端界面名称相近，也可能使用不同内核。到客户端的「关于」或内核信息页面查看实际内核名称与版本，再对照该内核文档；仅升级界面程序不一定会同步切换内核。
| 协议 | 选择时关注什么 | 不能直接推断什么 |
|---|---|---|
| Shadowsocks | 加密方法是否受支持，服务端与节点配置是否允许 UDP | 不能仅凭协议名认定延迟最低 |
| VMess / Trojan | 传输方式、TLS 与相关参数是否完整匹配 | 使用 TLS 不代表必然高速或免受拥塞影响 |
| VLESS | 需要支持该协议及所用传输特性的内核 | 订阅能被导入，不代表所有扩展参数都有效 |
| Hysteria2 / TUIC | 使用支持它们的内核，确认本地与线路允许 UDP 通行 | 基于 QUIC 不代表所有网络都更快 |
如果当前 Wi-Fi 限制 UDP，依赖 UDP 传输的节点可能连接失败，而使用 TCP 传输的候选节点仍能工作。相反，在某些丢包环境中，特定协议与实现可能表现更好，但应在同一网络、相近时间内验证，不能把协议名当作线路质量排名。
游戏需要的是完整 UDP 路径
游戏能否通过节点运行，取决于应用流量是否被接管、内核与节点是否支持所需 UDP 转发、服务端是否开放，以及规则是否选择正确出口。普通系统 HTTP 代理通常不能接管游戏的全部 UDP 流量，必要时才考虑客户端支持的 TUN 模式。
TUN 是本机流量接管方式，不是节点协议，也不会自动降低延迟。启用后仍需查看路由、DNS 与连接记录。公司网络、其他 VPN 或虚拟网卡可能造成冲突；排查时一次只改变一个设置，并保留恢复原配置的方法。
六、按浏览、视频、游戏做一轮对照测试
先按地区和内核兼容性排除不适用节点，再按倍率筛出可接受成本，最后比较延迟和真实业务。这样比从几十个名称里挑最低数字更容易复现，也便于之后换网复测。
| 使用场景 | 优先指标 | 具体测试动作 |
|---|---|---|
| 网页与文档 | 响应稳定、请求失败少 | 用相同的 3 个常用站点，分别记录首次加载和刷新表现 |
| 视频播放 | 持续吞吐、缓冲与流量倍率 | 固定同一视频和清晰度，播放 5 分钟，观察缓冲次数与缓冲区变化 |
| 语音与会议 | 抖动、丢包、连续可用性 | 在应用通话统计中观察 10 分钟，不只检查节点测速结果 |
| 在线游戏 | 实际服务器延迟、丢包、UDP 路径 | 固定区服，在训练或非排位场景测试 10 分钟并记录游戏内数据 |
一个可直接照做的选择流程
- 保留 3 个候选节点，例如同一地区的两个 1x 节点和一个 0.5x 节点，确认都能被当前内核加载。
- 使用相同测试 URL，各测 5 次，记下典型延迟、最高值与超时次数。
- 在同一网络下测试实际业务，暂停系统更新和其他大流量下载，避免背景任务干扰。
- 记录时间、网络类型、节点名称、倍率、出口地区与业务结果，不记录订阅链接或节点密钥。
- 选一个主用节点，再保留一个不同线路的备用节点。晚高峰复测后再决定长期使用哪个。
例如，A 节点 45 ms 但 5 分钟播放缓冲 3 次，B 节点 85 ms 且无缓冲，两者均为 1x，那么视频场景更适合先选 B。这是判断示例，不是固定阈值；实时交互场景还应额外检查应用内延迟与丢包。
七、常见问题：自动选择、超时与切换后的验证
自动选择是否总能挑出最快节点？
url-test 策略组通常依据指定测试 URL 的延迟自动选择，不能直接衡量视频吞吐、地区可用性或倍率成本。组内混入多个地区与不同倍率节点时，自动选择可能不符合业务要求。先把符合要求的节点归入同一组，再考虑自动测试；具体组结构见策略组使用说明。
节点显示超时，就一定已经失效吗？
不一定。测试地址不可达、DNS 异常、本地网络限制或瞬时拥塞都可能造成超时。先用另一候选节点和另一个可用测试目标交叉验证，再检查「日志」中的解析失败、握手失败或连接超时信息。排错顺序可参考连接检查步骤。
切换节点后，为什么速度与地区都没变？
先确认选对策略组，再重新建立目标连接。浏览器长连接、应用连接池和后台下载可能继续使用原来的出口。必要时结束该应用的相关连接并重开，同时观察「连接」页中的节点与规则；不要仅靠刷新客户端的流量数字判断是否切换成功。