Clash 节点怎么选:延迟、倍率、地区与协议四项对照

1. 先按用途筛选，再比较延迟

Clash 中显示的节点，通常是一组连接远端代理服务器的参数。节点能连通，不代表适合所有任务；延迟低，也不代表下载快。选择时先确定目标：日常网页更在意响应时间，视频更在意持续吞吐与地区可用性，远程会议还要检查抖动、丢包和 UDP 通路。

建议按“目标服务可用 → 出口地区符合要求 → 倍率可接受 → 晚高峰稳定 → 延迟较低”的顺序筛选。先排除不满足硬条件的节点，再在剩余候选中做比较，比直接点击最低毫秒数更可靠。

维度	实际检查	不能据此推断
延迟	同一测试 URL 下重复测试，观察波动和超时	带宽上限、所有站点的访问速度
倍率	套餐说明与用量面板中的实际扣费规则	线路一定更快或更稳定
地区	目标服务识别的出口 IP 地区	节点名称与物理服务器位置完全一致
协议	客户端内核支持、UDP 能力与当前网络表现	某种协议在所有网络下都最快

2. 延迟测试：看重复结果，不只看最低值

HTTP 延迟不是 ICMP ping

Clash 系客户端常用一个小型 HTTP 或 HTTPS 地址检测代理可用性，返回以毫秒表示的结果。它不是简单地对服务器执行 ICMP ping。具体耗时包含哪些阶段，受内核实现、连接复用、协议握手和测试地址影响；它主要反映该次探测通过代理访问指定地址的表现。

同一节点访问不同站点，可能经过不同的出口路由或 CDN。测试地址快速返回，只说明这条探测路径表现正常，不能保证视频站、代码托管服务和远程会议都一样顺畅。测速 URL 也可能单独不可达，因此全组超时时，应先排查测试目标，而不是立即删除订阅。

固定条件，做五轮记录

保持同一设备、同一网络、同一测试 URL；暂停下载、云盘同步和其他占用带宽的任务。
选出 3 个候选节点，每个测试 5 次，相邻测试间隔约 10 秒，记录毫秒数与超时次数。
优先比较中位数和波动范围。再在常用时段复测，例如当地时间 20:00—23:00。
用实际业务验证：网页连续打开几次，视频观察数分钟缓冲情况，会议检查声音中断和丢包。

例如，一组假设记录为 A：45、48、220、超时、190 ms，B：80、82、79、85、81 ms。A 的最低值更小，B 的五次结果却更集中。对交互式网页和会议，B 通常更值得继续验证。这里的数字用于说明比较方法，不是某条线路的实测成绩。

延迟、吞吐与抖动分别看

一个 40 ms 的节点可能只有较小的可用带宽，一个 150 ms 的节点也可能稳定传输大文件。下载速度受服务器负载、跨网拥塞、远端限速和本地宽带共同影响。测试吞吐会消耗流量；先用小规模测试筛选，再对少数候选观察持续速度，不必对全部节点运行大文件测速。

3. 流量倍率：按服务端规则计算用量

“0.5 倍”“1 倍”“2 倍”通常是订阅服务商的计费标记，并不是 Clash 内核的统一计费字段。客户端节点名称中的倍率只是文字，改名不会改变扣费方式。实际扣量以服务商的规则和用量面板为准，还要确认是否合计上传与下载、是否存在分时倍率或独立流量池。

计费用量 = 纳入计费的传输量 × 节点倍率

示例：下载 8 GB，上传 2 GB，按双向合计计费
0.5 倍：10 GB × 0.5 = 5 GB
1 倍：  10 GB × 1   = 10 GB
2 倍：  10 GB × 2   = 20 GB

以上是理想化算例。统计周期、单位换算和协议开销可能造成客户端统计与服务端面板不完全一致。不要仅凭一次小流量测试的差值判断计费错误；可以先记录面板读数，进行一段可控传输，再等待面板统计刷新后核对。

网页与即时通信：总量通常较小，可以优先考虑响应与稳定性。
系统镜像与大型更新：先确认是否需要代理，再比较低倍率节点的持续速度。
长时间视频：把每日观看量计入预算，避免只关注单次播放是否流畅。

高倍率可能对应服务商定义的特殊线路，也可能只是产品定价。它不是带宽或稳定性的技术保证。需要长期使用时，把相同时段的实际表现与扣量一起记录，才能判断成本是否合理。

4. 出口地区：以目标服务识别为准

节点名称中的“香港”“日本”“美国”通常表示预期出口地区，但名称不是验证结果。中转入口与最终出口可能分属不同地区，IP 数据库也可能更新滞后。访问者真正需要确认的是：目标服务看到了哪个出口 IP，以及该服务把这个 IP 识别成哪个地区。

地区正确，也不等于服务可用

流媒体和其他地区限定服务可能同时检查 IP 地区、机房或住宅网络属性、账号地区、付款资料与风控状态。某个节点能打开登录页，不代表能播放全部内容；能播放一个节目，也不代表整个片库都可用。“解锁”应落实到具体服务、具体内容和测试时间，不宜只看节点标签。

在目标服务对应的策略组中选择节点，关闭旧页面或结束旧连接后重新访问。
查看客户端连接记录，确认该服务的实际请求命中了预期策略与节点。
核对出口 IP 地区，再在目标服务中执行实际操作，例如播放指定内容。
若表现不一致，检查账号地区、应用定位权限、IPv6 路径以及是否有相关域名直连。

DNS 查询所在地区与最终出口地区不是同一个概念。修改 DNS 服务器并不会自动把代理出口变成另一个国家。若部分请求走直连或 IPv6 绕过预期路径，应先修正接管与分流，再讨论节点地区。需要理解相关字段时，可查阅完整文档。

5. 协议类型：先看内核支持与传输条件

Shadowsocks、Trojan、VMess、VLESS、Hysteria2 和 TUIC 描述的是不同协议或协议体系。它们不是固定的速度等级。真实表现取决于协议参数、传输层、服务器实现、拥塞情况与本地网络限制。同一个协议换一台服务器，差异可能比更换协议更大。

Shadowsocks：检查加密方法与内核支持范围。使用额外插件的节点，还要确认客户端具备对应支持。
Trojan：常见部署使用 TLS，需要匹配服务器地址、端口、认证参数和 TLS 配置。
VMess / VLESS：除了协议名称，还要核对传输方式及 TLS 等参数；WebSocket、gRPC 等配置不能随意互换。
Hysteria2 / TUIC：基于 QUIC、依赖 UDP 通路。网络限制 UDP 时可能无法连接，不能只根据其他 TCP 节点可用就认定配置正确。

Clash 是客户端生态中的常见称呼，实际支持哪些协议由运行的内核及其版本决定。原版 Clash 与 Clash Meta（现称 mihomo）的能力范围不同。导入时出现“不支持的代理类型”，应先核对内核，而不是把 YAML 中的 type 改成另一个值；更改名称不会转换服务器协议。

6. url-test：在合格节点中自动选延迟

完成地区、倍率和业务可用性筛选后，再让 url-test 在候选范围内比较延迟。不要把不同地区、不同成本、不同使用限制的全部节点放入同一自动组，否则最低延迟节点可能不满足当前业务要求。

下面示例面向 mihomo。假定现有配置的 proxies 中已经有名为 HK-01、HK-02 的节点，且两者均已通过同一业务的验证。名称仅用于展示引用关系，使用时必须与现有节点名称完全一致。

proxy-groups:
  - name: HK-AUTO
    type: url-test
    proxies:
      - HK-01
      - HK-02
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true

interval: 300：检测间隔为 300 秒，不是 300 毫秒。
tolerance: 50：设置 50 毫秒的切换容差，减少因细小延迟差异造成的频繁切换。
lazy: true：启用惰性检测；组未被使用时，不应把它理解成始终按间隔持续探测。
url：使用稳定的小响应测试地址。示例地址通常返回 HTTP 204，但仍需确认当前网络和节点能够访问。

这不是完整配置。应把组条目合并到现有的 proxy-groups 列表，而不是在同一个 YAML 顶层重复添加该键。如果节点来自 proxy-providers，应按提供器结构使用 use 与适当的筛选条件，不要假设上面的静态节点引用能直接替代提供器配置。

7. fallback：按顺序保留可用备用

fallback 与 url-test 的目标不同：前者按候选顺序选择可用节点，后者比较探测延迟。希望平时固定使用首选线路、探测失败后再转备用时，可以使用 fallback。它不承诺在所有业务故障发生时立即切换。

proxy-groups:
  - name: HK-FAILOVER
    type: fallback
    proxies:
      - HK-01
      - HK-02
    url: https://www.gstatic.com/generate_204
    interval: 300
    lazy: true

  - name: PROXY
    type: select
    proxies:
      - HK-AUTO
      - HK-FAILOVER
      - HK-01
      - HK-02

此片段与上一节共用同一个 proxy-groups 列表；HK-AUTO 必须已经存在。随后让需要代理的规则引用 PROXY，并在客户端选择自动组、备用组或单节点。若原配置已经使用同名策略组，应修改原条目，而不是再创建一个同名条目。

例如，以下规则会把 github.com 及其子域名的匹配请求交给 PROXY。它应放在会提前匹配该流量的宽泛规则和最终 MATCH 规则之前；不要为了套用示例而覆盖现有全部分流规则。

rules:
  - DOMAIN-SUFFIX,github.com,PROXY
  # 继续保留现有规则，最终 MATCH 仍放在末尾

如果首选节点仍能访问探测地址，但目标视频服务报错，fallback 可能继续使用首选节点。这是探测目标与业务目标不一致造成的边界。切换节点主要影响新建连接，已建立的下载、视频或长连接也不一定自动迁移，需要应用重连。

8. 日常选节点的检查清单

确认路径：目标应用已经经过系统代理或 TUN，连接记录显示实际命中预期策略。
确认硬条件：目标地区和具体服务可用，UDP 等必要能力通过实际验证。
核对成本：从服务商面板确认倍率、上传计费与剩余流量，不只看节点名称。
比较稳定性：同条件测试五轮，再在常用时段检查波动、超时和持续速度。
建立候选组：把用途一致的节点放入自动组，并保留一个已经验证的手动选择。
保存修改：先备份配置，执行配置检查，再查看日志；订阅更新后确认自定义组没有被覆盖。

节点选择的重点不是找到一个永久最低的延迟数字，而是为具体业务保留一组条件明确、成本可控、能够复现验证结果的候选。线路状态会随时段和网络变化。发生异常时先区分接管、规则、探测地址与业务服务，再决定是否切换节点。