Clash 节点怎么选

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

Clash 节点列表中的名称、延迟和倍率，回答的是不同问题。地区关系到出口位置与服务可用范围；倍率关系到订阅额度消耗；协议关系到内核兼容性和网络传输条件；延迟只反映某次探测的响应情况。把所有节点按毫秒数排序，不能直接得到最适合当前任务的结果。

先在客户端确认当前 Profile 已启用，再进入「代理」或「策略组」页面。不同客户端的界面名称有差异，实际判断应以策略组名称、组类型和连接记录为准。切换节点之前，确认正在操作的组确实被目标网站的规则引用，而不是一个未参与当前连接的备用组。

1. 确定用途：网页浏览、视频播放、远程终端和大文件传输，对连接的要求不同。
2. 筛选出口：先保留目标服务允许的地区；没有地区限制时，再考虑延迟与稳定性。
3. 检查成本：读取订阅服务商对倍率和计费方向的说明，排除不适合长时间使用的节点。
4. 验证传输：确认协议受当前内核支持，需要 UDP 的应用还要验证完整 UDP 路径。
5. 比较实际连接：在相同网络、相同目标和相近时间内复测，最后保留一个主用和一个备用出口。

延迟测试测到了什么

HTTP 探测不是单纯的网络往返时间

Clash 与 mihomo 常见的延迟测试，会通过指定代理向测试 URL 发起请求。这与直接向节点服务器发送 ICMP Ping 不同。结果会受到本地到入口的路径、代理握手、出口到测试站点的路径，以及测试端点响应的共同影响。DNS、TLS 和连接复用是否参与，也取决于内核实现及本次连接状态。

例如，界面显示的 80 毫秒与 160 毫秒，只能在测试 URL、网络环境和测试方式一致时进行比较。这两个数字是说明比较方法的示例，不是本站实测结果。一个更靠近测试站点的出口，可能在该项测试中领先，却不一定更靠近你实际访问的业务服务器。

用固定条件复测，避免看一次结果下结论

同一轮比较只测试少量候选节点，避免并发探测本身占满本地连接。可在同一网络下分三轮记录结果，每轮间隔约 30 秒；这些是建议的操作参数，不是性能保证。比较中间水平和超时次数，不要只保留最小值。需要判断晚间使用体验时，应在实际使用时段复测。

测试期间暂停大文件同步，保持测试 URL 不变。如果全部节点同时超时，先检查本地网络、测试站点和订阅有效期。若只有一个节点持续失败，再检查该节点的协议参数与服务状态。不要因为一次超时就同时修改 DNS、TUN 和全部规则，否则很难定位变化来自哪里。

流量倍率怎样影响订阅额度

倍率通常是订阅服务商的计费约定，不是 Clash 协议字段。节点名里的「0.5x」「1x」「2x」可能只是服务商写入的名称，客户端不会仅凭名称决定扣费方式。实际倍率、上下行是否都计入额度、统计口径和生效时间，都要以服务商说明与账户账单为准。

倍率高不等于延迟更低，也不等于带宽更大。高倍率可能对应特定线路成本或地区资源，仍需实际验证。下载系统镜像、同步照片或长时间看视频时，应先找满足需求的低倍率节点；远程操作更在意响应和稳定性，可在预算允许时选择更合适的路径。

• 首次使用某个倍率节点，先记录账户剩余额度，再进行一段受控传输，等待服务商统计刷新后核对。
• 不要用客户端连接页里的单次流量，直接代替服务商账单；两者的计量位置可能不同。
• 多设备共享订阅时，把其他设备的消耗考虑进去，否则一次对照很容易得出错误结论。

节点地区看出口，不只看名称

节点名称中的地区通常由订阅提供方填写，可能表示入口、出口或线路分组。连接先到香港入口，再从日本出口访问网站时，目标网站通常看到的是日本出口 IP。物理距离较近也不保证路径更短，运营商互联与中转安排都会影响实际表现。

地区判断需要三项交叉验证

1. 确认连接出站：在客户端「连接」页面找到目标域名，查看命中的规则、策略组和最终节点。
2. 检查出口 IP：在同一个浏览器中访问可信的 IP 查询服务，记录它看到的公网 IP 与地区。先确保查询请求没有被规则分到 DIRECT。
3. 验证目标服务：使用实际目标网站确认可用性；IP 数据库可能滞后，不同服务对地区的识别也可能不同。

如果查询站显示的地区正确，目标服务仍提示地区受限，还要检查账号所属地区、支付资料、历史会话和服务自身政策。换一个地区标签相同的节点，不一定能解决这些限制。节点名称也不能证明 IP 类型、服务解锁能力或账号使用合规性。

长期登录的业务应尽量保持出口地区稳定。频繁跨地区切换可能触发额外验证；切换后，已有 TCP 连接通常不会自动迁移到新节点，需要重新建立连接才能验证新出口。是否关闭旧连接，应结合当前下载、通话和远程会话是否允许中断来决定。

协议选择先看兼容与 UDP

Shadowsocks、Trojan、VMess、VLESS、Hysteria2 和 TUIC 等名称，描述的是不同的代理协议或传输体系，不是速度等级。具体支持范围取决于客户端搭载的内核及其版本。使用 Clash Meta（mihomo）内核的客户端，与已经停止维护的旧 Clash 客户端，支持范围不能混为一谈。

导入配置出现不支持的代理类型、解析失败或握手错误时，先在客户端「关于」或内核信息中确认实际内核，再对照配置要求检查。不要只看应用名称，也不要在不清楚参数含义时随意改写 type、network、SNI 或 TLS 选项。

Hysteria2、TUIC 使用基于 QUIC 的传输，对底层 UDP 可达性有要求。某些网络会限制 UDP，这时协议本身受支持也可能连接失败。反过来，某节点能代理网页 TCP，并不能证明它能承载游戏或语音的 UDP 流量。

系统代理通常不会自动接管所有应用的 UDP。应用不遵从系统代理时，需要确认 TUN 或应用自身代理配置是否覆盖该流量。即使在节点配置中启用了 udp: true，也仍需服务端支持，并由客户端接管和规则正确路由。不要通过关闭证书验证来处理普通网络波动。

手动选择与自动测速怎样配合

select 适合固定出口和人工判断；url-test 适合在条件相近的候选节点间按探测结果自动选择。后者不会替你评估订阅倍率、账号地区要求或目标服务是否可用。把高倍率和低倍率、多个不兼容地区混进一个自动组，可能出现数字更好但用途不符的切换。

下面是一个需合并进现有 Profile 的 mihomo 策略组片段，不是完整配置。日常-A 与 日常-B 必须替换成当前配置中真实存在的节点名称，并先确认两者倍率与出口要求一致。测试 URL 会由内核发起请求；应选用当前网络和代理路径均能稳定访问的端点。

proxy-groups:
  - name: 日常自动
    type: url-test
    proxies:
      - 日常-A
      - 日常-B
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

  - name: 日常选择
    type: select
    proxies:
      - 日常自动
      - 日常-A
      - 日常-B

interval: 300 表示自动探测间隔为 300 秒；tolerance: 50 是 50 毫秒的切换容差，用于减少延迟接近时的频繁切换，并非最大允许延迟。这个配置不会自动接管全部流量，现有规则还必须引用 日常选择，连接才会进入该组。

例如，规则 DOMAIN-SUFFIX,example.com,日常选择 会把匹配域名后缀的连接交给这个策略组。规则通常按顺序匹配，前面已有命中项时，后面的规则不会再接管这条连接。更多语法可查看策略组配置说明。

按场景完成最后一次验证

网页与远程操作：优先稳定响应

普通浏览可优先选择低倍率、连续探测稳定的节点。SSH、远程桌面和管理后台则更在意交互延迟与会话连续性，建议固定手动出口，避免自动切换干扰排查。节点测试正常但终端断连时，还应检查目标服务器、防火墙及空闲连接超时。

视频与下载：优先持续传输和成本

视频先验证目标服务能否正常播放，再观察缓冲是否持续；大文件下载则使用同一个来源比较一段稳定传输，而非只看启动瞬间的速度。不要把测速站跑出的吞吐直接当作所有下载源的表现，也不要为了反复测速消耗大量订阅额度。

游戏与语音：单独确认 UDP 路径

先验证游戏或语音应用是否真的进入代理，再看应用自身显示的延迟、抖动与丢包。网页探测通过只能作为初筛。若切换节点没有变化，应检查规则是否仍走 DIRECT，以及应用是否沿用旧连接，而不是继续盲目更换协议。

1. 保存一个稳定主用节点和一个已验证的备用节点，记录各自地区及倍率。
2. 连接目标服务，在客户端核对实际出站，不只看组内高亮项。
3. 观察真实任务表现，并核对账户额度变化是否符合预期。
4. 遇到失败时，每次只改一项：节点、接管方式、规则或 DNS，修改后重新验证。

最终选择顺序是：用途与地区先满足，倍率可接受，协议和流量接管兼容，再比较延迟与实际稳定性。毫秒数适合用来缩小候选范围，不适合独自决定所有场景下的节点选择。