Clash 节点怎么挑:延迟、流量倍率、地区与协议的取舍方法

先确认出站：节点选择是否真正生效

挑节点之前，先确认目标连接确实经过正在调整的策略组。Clash 的规则模式按 rules 从上到下匹配；浏览器请求如果命中 DIRECT，更换代理节点不会改变这条请求的路径。某个流媒体规则也可能指向独立策略组，与首页显示的默认代理组无关。

1. 打开客户端的「配置」或「Profiles」，确认当前启用的订阅配置，而不是只更新了另一份配置。
2. 在「代理」或「Proxies」中，找到规则实际引用的策略组，先手动选定一个节点。
3. 访问目标网站，再打开「连接」或「Connections」，查看目标域名、命中规则与出站链路。菜单名称随客户端而异，重点是核对这三个字段。
4. 切换节点后建立新连接再测。已有 TCP 长连接通常不会自动迁移，必要时停止原任务并重新连接。

延迟看稳定性：不要只选最低的一次

客户端显示的延迟，通常来自通过节点访问测试 URL 的探测，不等于设备到节点服务器的单纯 ICMP 延迟，也不等于下载速度。结果会受到测试地址、DNS、连接建立、协议握手、连接复用和内核实现影响。两个节点只有在同一网络、同一测试地址下比较，数值才更有参考意义。

用五轮记录筛选候选节点

先选 3 个候选节点，每隔约 30 秒测试一轮，共测 5 轮。避免同时运行大下载；保留超时结果，不要只记录成功的最低值。下面是判断方法示例，不是本站对任何服务的实测数据。

上例中，日常浏览优先试 A，而不是只因为 B 出现过 25 ms 就选 B。C 如果能满足目标服务的地区要求，也可能比不稳定的 B 更合适。探测超时本身不能直接证明丢包率；要判断丢包，还需要结合网络诊断与真实连接表现。

晚高峰再测一次实际任务

• 浏览：连续打开 5 个常用页面，观察首次加载、图片和脚本是否反复等待。
• 视频：固定同一视频与清晰度，观察 3 分钟的缓冲情况，不只看开始播放是否迅速。
• 下载：使用同一合法测试文件，分别记录开始后的短时速度与持续 60 秒的表现，避免多任务抢占带宽。

白天正常、晚间明显下降，常见原因是线路或服务端负载变化。换协议未必解决这类问题，应优先比较另一条线路，并在平时实际使用的时间段复测。

流量倍率：先算用量，再比较速度

节点名中的「0.5 倍」「1 倍」「2 倍」一般是订阅服务的计费标记，不是 Clash 内核的通用限速参数。客户端不会因为节点名字写了「2 倍」就把下载速度加倍。最终扣量规则以服务方说明与账户用量记录为准，部分服务还会分别计算上传、下载或特定时段。

用同一单位估算账户消耗

假设服务按“计费流量 × 倍率”扣量，且一次任务计入 2 GiB：0.5 倍约扣 1 GiB，1 倍约扣 2 GiB，2 倍约扣 4 GiB。这只是计算示例；协议开销、双向计费以及 GB 与 GiB 的单位差异，都可能让账户记录与本地文件大小不同。

• 网页与即时通信：通常先看稳定性，倍率作为次要条件。
• 视频与大文件：先估计每月用量，再选择能持续满足需求的低倍率节点。
• 临时重要任务：可以使用高倍率但更稳定的候选；任务结束后再切回日常节点。

地区选择：看出口与目标服务，不只看地理距离

节点名称中的地区可能表示出口位置，也可能只是服务方的线路标签。入口服务器、转发线路和最终出口可以位于不同地方。设备距离某个地区较近，不代表访问那里的节点一定最快；运营商互联、绕路与高峰拥塞都可能改变结果。

日常网站与流媒体的判断不同

日常浏览先从邻近地区的稳定线路试起，再比较真实页面加载。流媒体则要先确认目标内容对账户地区、出口 IP、内容授权与服务条款的要求。出口被识别为某个国家或地区，也不代表该地区所有内容都可播放。

1. 手动固定候选节点，确认目标域名命中了预期策略组。
2. 通过该出站检查出口 IP 与地区，再进入服务自身的播放页面验证。
3. 固定清晰度播放至少 3 分钟，检查是否反复缓冲、降画质或出现地区提示。
4. 若页面与播放结果不一致，检查媒体域名是否被另一条规则分流，而不是立即归因于节点失效。

开发场景也要按目标验证。代码托管、软件包仓库与容器镜像可能使用不同 CDN，测试主页很快并不代表拉取依赖也快。对需要稳定登录状态的服务，尽量保持出口地区一致，避免自动组在不同地区之间频繁切换。

协议取舍：先兼容，再检查 UDP 与网络环境

Shadowsocks、VMess、VLESS、Trojan、Hysteria2、TUIC 是不同的代理协议或方案名称，不是速度等级。同样的协议部署在不同线路上，体验可能相差很大。选择时先确认客户端所带内核支持该协议及其参数；旧版 Clash 与 Clash Meta（mihomo）的支持范围并不相同。

Hysteria2、TUIC 基于 QUIC，依赖可用的 UDP 网络路径；某些网络对 UDP 的限制可能使其无法连接或表现不稳。常见基于 TCP 的代理传输也会受到拥塞与线路质量影响。协议名称无法替代实际测试，更不适合直接用于“最快协议”的统一排名。

网页正常但语音或游戏失败时，应检查 UDP、TUN 接入与分流规则。若客户端提示不支持的代理类型，先处理内核兼容性，不要把证书验证关闭当作通用修复。订阅中的认证信息、服务器地址和传输参数需要与服务端一致。

策略组配置：日常自动选择，关键任务手动固定

url-test 适合从候选中按测试结果自动选择，但它不检查流量倍率、视频授权或开发任务是否成功。将所有地区、所有倍率混入同一个自动组，可能得到较低的探测延迟，却不符合实际需求。

mihomo 配置片段

下面只展示 proxy-groups 片段。假定当前配置的 proxies 中已有名称完全一致的 JP-A 与 SG-A 两个节点；替换成实际名称后合并到现有配置，不要在同一 YAML 中重复添加顶层 proxy-groups 字段。

proxy-groups:
  - name: Daily
    type: select
    proxies:
      - Auto
      - JP-A
      - SG-A

  - name: Auto
    type: url-test
    proxies:
      - JP-A
      - SG-A
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

• type: select：手动选择。日常可选 Auto，长时间下载或登录敏感任务可固定单个节点。
• interval: 300：自动探测周期为 300 秒，不是订阅更新周期。
• tolerance: 50：以毫秒为单位的切换容差，用于减少小幅延迟差异引起的切换；不是限速值，也不是超时阈值。
• url：应选择能够稳定访问的轻量 HTTPS 测试地址。更换地址后，旧数值与新数值不宜直接比较。

以上字段按 mihomo 的常用配置说明，其他内核需对照对应文档。规则还必须引用 Daily 才能影响目标流量；仅创建策略组不会自动改写分流。可在策略组字段说明中核对结构，并在规则字段说明中检查引用关系。

按场景收尾：保留主用与备用节点

最终保留一个主用节点、一个不同线路的备用节点即可。记录测试日期、所用网络、目标任务、倍率与结果；遇到问题先用同一任务切换备用线路复测。如果所有节点同时变差，优先检查本地网络、接入模式、DNS 与当前配置，而不是继续扩大候选列表。

选择原则可以压缩成一条操作顺序：先确认连接走对策略组，再筛稳定性；有地区要求先验证服务，无地区要求再比较延迟；大流量任务计算倍率，最后才在兼容的协议之间取舍。