Clash 节点怎么选：延迟、倍率、地区与协议判断方法

SELECTION BASELINE

先确定节点筛选目标

选择 Clash 节点时，延迟最低不等于实际体验最好。一个节点是否适合当前任务，至少取决于连接稳定性、可用带宽、网络路径、目标地区、流量倍率和客户端支持情况。网页浏览、视频播放、大文件下载、实时通话与远程开发对线路的要求并不相同，只看一次延迟数字很容易得出错误结论。

普通网页访问更看重连接建立速度和稳定性。视频播放需要持续带宽，偶尔出现一个较高延迟通常不影响缓冲后的播放，但短时间丢包和明显抖动会造成清晰度下降。语音、会议和游戏更依赖低抖动、低丢包以及稳定的往返时间。大文件下载则主要观察连续吞吐量，同时要考虑节点倍率带来的流量消耗。

开始筛选前，先把用途分成三类：日常默认节点、特定地区节点和高带宽临时节点。日常节点应优先稳定，适合作为规则模式下的大部分代理流量出口；特定地区节点用于访问具有区域差异的服务；高带宽节点用于更新、同步或下载，但不一定适合长时间保持连接。这样的分类比试图找到一个覆盖所有场景的“最快节点”更可靠。

LATENCY TEST

正确理解 Clash 延迟测试

Clash 客户端里的延迟测试通常不是系统命令中的 ICMP Ping。常见实现会通过该代理节点请求一个测试地址，记录建立连接并获得响应所需的时间。这个结果更接近代理链路上的 HTTP 或 HTTPS 连通性，但仍然只是一次小流量测试，不能直接代表持续下载速度。

同一个节点连续测试可能出现不同结果。原因包括本地 Wi-Fi 波动、运营商网络拥塞、代理服务器负载、跨境路由变化、DNS 解析时间和测试目标响应速度。第一次测试还可能包含域名解析、TCP 建连或 TLS 握手成本，后续测试则可能复用缓存，因此数字通常更低。判断时应看多次结果的范围，而不是只保留最小值。

延迟数字应怎样读取

• 数值稳定：多次结果接近，即使不是列表最低值，也通常适合作为日常节点。
• 数值跳动明显：例如相邻测试相差数百毫秒，说明路径或负载不稳定，需要继续观察。
• 显示超时：可能是节点不可用，也可能是测试地址无法通过该节点访问，不能只凭一次超时立即删除配置。
• 延迟低但下载慢：小请求响应快，不代表服务器有足够出口带宽，也不代表高峰期能维持吞吐量。
• 延迟高但播放稳定：只要持续带宽充足且丢包较低，已缓冲的视频仍可平稳播放。

更实用的方式是连续测试三到五次，记录中位数和波动范围。例如两个节点的中位延迟分别为 80 毫秒和 110 毫秒，但前者经常跳到 600 毫秒，后者始终保持在 100 至 130 毫秒，那么后者通常更适合会议、远程终端和持续浏览。

如果所有节点同时超时，应先检查订阅是否已更新、配置是否成功加载、设备网络是否正常，以及 Clash 内核是否正在运行。若只有某个策略组超时，还要确认组内节点是否有效。启用 TUN 模式不会自动降低节点延迟；TUN 只改变流量进入代理内核的方式，实际链路质量仍由本地网络、节点服务器和目标网络共同决定。

REGION AND ROUTE

按地区与实际网络路径选择

地区标签表示节点服务器或入口所在区域，但地理距离只是影响延迟的一个因素。数据包经过哪些运营商、是否绕路、入口与出口是否分离，都会改变实际结果。位置较近的节点可能因为互联质量较差而延迟更高；位置较远的节点也可能借助稳定线路获得更小的抖动。

筛选日常节点时，可以先从地理位置接近的地区开始测试，再保留一到两个不同地区作为备用。不要把全部候选都放在同一个地区，因为区域性网络故障、服务器维护或晚高峰拥塞可能同时影响一批节点。备用节点的意义不是长期闲置，而是在主节点连续超时或速度下降时快速切换。

地区选择的常见判断

节点名称中的地区不一定完整描述网络路径。有些服务使用中转入口，节点名称标记的是出口地区，而本地首先连接的是另一处入口；也有名称包含线路代号或运营商缩写。无法确认时，应以实际测试和服务提供方给出的节点说明为准。

还要区分“目标服务地区”和“代理节点地区”。访问一个部署在全球 CDN 上的网站时，节点可能被分配到靠近出口的边缘服务器，因此出口地区会影响内容分发路径。对于没有区域要求的日常访问，优先选稳定且路径短的节点；只有目标服务明确依赖地区时，才把出口位置作为首要条件。

TRAFFIC RATE

判断倍率与真实流量成本

节点倍率通常是订阅服务采用的流量计费系数，不是 Clash 协议本身的属性。标记为 1 倍的节点，使用 1 GB 数据一般按 1 GB 计入套餐；标记为 2 倍时，同样的传输量可能按 2 GB 计算。具体统计范围和计算方法应以订阅服务的说明为准，Clash 客户端只负责使用配置中的节点，不负责统一定义倍率规则。

倍率高也不必然意味着速度更快。高倍率可能对应成本更高的线路、较少拥塞的入口或特定地区资源，但节点当前负载仍会变化。相反，低倍率节点也可能在非高峰时段提供足够速度。因此倍率应作为成本指标，与延迟、稳定性和吞吐量分开评估。

按任务分配倍率

1. 日常浏览和即时通信优先使用稳定的普通倍率节点，减少频繁手动切换。
2. 系统镜像、游戏更新和云端同步会产生大量流量，应先检查剩余配额，再比较低倍率节点的持续速度。
3. 对地区或线路有明确要求的临时任务，可以使用较高倍率节点，完成后切回默认策略。
4. 测速本身也会消耗流量，连续运行大文件测速会快速增加用量，不适合对所有节点反复执行。

PROTOCOL REVIEW

比较常见代理协议与客户端支持

订阅中可能同时出现 Shadowsocks、VMess、VLESS、Trojan、Hysteria2、TUIC 等节点。协议决定连接与传输方式，但协议名称本身不能单独证明节点更快。服务器位置、线路带宽、拥塞程度、传输层配置和客户端内核版本往往影响更大。

Shadowsocks

Shadowsocks 配置相对直接，常见 Clash 内核通常支持多种加密方式。实际可用性取决于客户端内核是否支持节点指定的加密方法或扩展形式。如果订阅导入后节点报出 cipher、plugin 或 unsupported 等相关错误，应先核对内核支持，而不是反复测试延迟。

VMess 与 VLESS

VMess 和 VLESS 常与 TCP、WebSocket、gRPC、TLS 等传输配置组合使用。VLESS 本身不等于固定的线路质量，Reality、TLS 或其他安全传输参数也需要内核正确支持。旧版 Clash 内核与基于 Clash Meta、现称 mihomo 的内核在协议及扩展支持范围上可能不同。订阅中出现新字段时，应使用仍支持相应配置格式的客户端和内核。

Trojan

Trojan 通常运行在 TLS 连接上，配置中会涉及服务器名称、证书验证和传输层参数。设备时间错误、域名解析异常或服务器证书问题都可能导致握手失败。此类故障一般表现为节点无法建立连接，不应被误判为单纯的高延迟。

Hysteria2 与 TUIC

Hysteria2 和 TUIC 采用基于 UDP 的传输设计，在部分高延迟或存在一定丢包的网络中可能获得较好的吞吐表现，但前提是本地网络、路由设备和运营商路径能够正常传输 UDP。某些公司网络、公共 Wi-Fi 或防火墙会限制 UDP，此时节点可能超时，切换到基于 TCP 的候选节点更容易判断问题来源。

协议选择应遵循兼容优先：先确认客户端内核能够解析配置并建立连接，再比较体验。如果多个协议节点使用相同入口和相近线路，实际差距可能很小。无需因为协议名称较新就把它设为默认，也不应在没有错误日志的情况下随意修改订阅生成的协议参数。

PROXY GROUPS

使用 Clash 策略组自动筛选

节点数量较多时，可以利用策略组减少手动切换。Clash 与 mihomo 配置中的常见策略组包括 select、url-test、fallback 和 load-balance。它们解决的问题不同，不能只看组名判断行为。

• select：由用户手动选择节点或下级策略组，适合默认出口和特定地区选择。
• url-test：定期测试候选节点，并根据测试结果选择满足条件的低延迟节点。
• fallback：按候选顺序检查可用性，前面的节点不可用时切换到后续节点。
• load-balance：按照配置策略把不同连接分配给多个节点，不等于把单个下载连接的带宽简单相加。

一个简化的自动测试组可以按下面的结构组织。实际字段支持情况取决于所用内核版本，节点名称必须与配置中的代理项一致。

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

interval 控制测试间隔，过短会增加请求次数和资源消耗。tolerance 用于减少延迟差距很小时的频繁切换。不同内核版本对切换条件和健康检查字段的实现可能存在差异，修改前应参考当前内核对应的配置说明。

自动选择适合候选节点质量相近、地区用途一致的组。如果把不同地区、不同倍率和不同用途的节点全部塞进一个 url-test 组，最低延迟节点可能不符合地区要求，也可能带来更高流量成本。更合理的结构是先按地区或用途分组，再在组内自动测试，最上层使用 select 选择“自动节点”“特定地区”或“手动选择”。

规则模式会根据域名、IP、进程或其他规则把连接送入指定策略组。节点选择只决定策略组最终使用哪个出口，不会改变规则从上到下匹配、命中后停止的基本逻辑。发现某个网站没有走预期节点时，应同时检查规则命中和策略组当前选择，而不是只更换节点。

TEST PROCESS

建立可重复的节点筛选流程

可靠的筛选应在相近的本地网络条件和相近时段完成。使用 Wi-Fi 测试时，先确认设备信号稳定，暂停后台大文件下载、云同步和系统更新。移动网络与固定宽带的路由不同，在一个网络上表现最好的节点，切换网络后可能不再占优。

1. 更新订阅：确保客户端已加载当前配置，避免继续测试已下线或参数已变化的节点。
2. 执行一次全组连通性测试：排除持续超时、无法握手和配置不受支持的节点。
3. 选择少量候选：从目标地区保留三到五个延迟较低且波动较小的节点。
4. 重复测试：间隔数十秒测试多次，观察中位延迟、最大值和超时次数。
5. 进行实际任务验证：打开常用网页、播放一段视频或进行短时间下载，观察加载、吞吐和重连情况。
6. 检查倍率与配额：在体验接近时优先选择流量成本合适的节点。
7. 保留备用节点：选择不同服务器或不同地区的候选，避免主节点故障时重新从全部列表筛选。

测试结果最好按时段记录。某节点上午稳定、晚间明显降速，通常说明高峰期负载或网络互联发生变化。只在凌晨完成一次测速，不能代表日常使用时段。对于工作用途，可以分别在上午、下午和晚间做短测试，连续观察一到两天后再确定默认节点。

切换节点后，已有连接不一定立即迁移到新节点。浏览器连接池、下载任务、视频会话和终端长连接可能继续使用原出口，直到连接关闭或超时。验证新节点时，应重新打开测试页面或重启相关连接。若启用了系统代理或 TUN，还要确认目标应用的流量确实进入 Clash；仅在客户端界面选中节点，不代表所有应用都已经使用它。

ERROR CHECK

常见误判与处理方法

只选择列表中延迟最低的节点

最低值可能来自一次偶然测试，也可能只反映测试地址的响应。应增加重复次数，并用常用服务验证。若最低延迟节点频繁断开，稳定但稍慢的节点更适合作为默认出口。

测速失败就认定订阅失效

单个节点失败与整份订阅失效是两回事。先观察其他节点能否连接，再查看客户端日志中的 DNS、握手、超时、协议不支持或网络不可达信息。如果所有节点同时失败，才需要进一步检查订阅更新、配置加载和本地代理状态。

切换节点后仍访问失败

问题可能位于规则而不是节点。检查当前模式是否为规则、全局或直连，确认目标连接命中了哪个策略组。DNS 缓存、浏览器现有连接和目标服务自身故障也会造成切换后没有立即恢复。可先关闭原连接，再使用另一个已确认可用的网站进行对照测试。

把 TUN 模式当作加速选项

TUN 模式用于接管更多不遵循系统代理设置的流量，对游戏、命令行程序或特定应用的覆盖可能更完整，但它不会提高代理服务器带宽。开启后体验变化，通常是因为流量路径或 DNS 处理方式改变。出现异常时，应检查 TUN 权限、路由、DNS 和应用兼容性，而不是继续提高测速频率。

一次大文件测速消耗过多流量

大文件能够测试持续吞吐，但不需要对每个节点执行。先通过小请求筛选候选，再选择两三个节点做短时间实际下载。测试结束后及时停止任务，结合客户端流量统计和订阅面板核对用量。