Clash 网速慢的分层排查方法:节点、线路还是本地设置

排查前先明确问题范围

在动手调整任何设置之前,先花两分钟确认问题的具体表现,能省下后面大量的无效尝试。"网速慢"是一个笼统的描述,它背后至少对应三类不同的现象,而这三类现象指向的原因几乎完全不同:

• 打开网页/应用慢,但一旦加载完成播放流畅——通常是延迟(RTT)偏高,而不是带宽不足,重点看节点距离和线路质量。
• 持续下载/播放时速度上不去,卡顿反复出现——大概率是带宽或线路拥塞,重点看节点负载和传输协议。
• 只有特定网站或应用慢,其他一切正常——问题往往不在代理本身,而在分流规则把该流量导到了不合适的出站,或者该站点本身对代理 IP 做了限速。

把现象归类之后,再决定从哪一层开始排查。如果不确定,可以按下文给出的三层顺序依次检查,这个顺序是按"排查成本从低到高"设计的——先排除最容易验证的节点问题,再看线路配置,最后才动本地系统层面的设置。

第一层排查:节点本身的速度瓶颈

节点是链路的起点,也是最容易验证、最该先排除的一层。多数订阅提供多个地区、多条线路的节点,速度差异往往比想象中大。

用延迟测试初步筛选

客户端的节点列表通常带有延迟测试按钮(Clash Meta 内核对应的是基于 url-test 的健康检查),点击后会对每个节点发起一次 HTTP 探测并记录往返时间。延迟测试反映的是"能不能连上、连接建立快不快",不完全等于实际传输速度,但延迟长期超过 500ms 或直接显示超时的节点,基本可以排除。

• 延迟低于 150ms:一般可用于网页浏览、即时通讯。
• 延迟在 150~400ms:可用,但视频/游戏场景会有明显卡顿感。
• 延迟超过 400ms 或频繁超时:优先更换节点,不建议继续在此节点上排查后续问题。

排除节点负载过高的情况

共享节点在高峰时段(晚间 19:00–24:00 是多数订阅的高峰)容易出现带宽被大量用户瓜分的情况,表现为延迟测试结果正常,但实际下载速度很低。这种情况下延迟测试无法反映问题,需要手动做一次实测:切换到该节点后访问一个已知速度稳定的静态资源(例如某个公开的测速文件),对比不同节点、不同时间段的下载速度差异。如果同一节点在非高峰时段速度明显更好,基本可以判定是负载问题,而非配置问题。

分组策略里加自动测速与故障切换

如果订阅中同地区有多个节点,建议在 proxy-groups 里用 url-test 类型分组,设置合理的测试间隔,让客户端自动挑选延迟最低的节点,减少手动切换的频率:

proxy-groups:
  - name: 自动选择-香港
    type: url-test
    url: http://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    proxies:
      - HK-01
      - HK-02
      - HK-03

tolerance 表示容差范围,避免节点因几毫秒的延迟波动而频繁切换,造成连接反复中断。

第二层排查:传输线路与协议设置

确认节点本身没有明显问题后,下一步看的是"数据从本机到节点之间走的是什么路径、用什么协议封装"。这一层的调整往往比换节点更能带来速度提升,尤其是在网络环境本身对某些协议做了限速或干扰的情况下。

尝试切换传输协议

同一个节点如果同时提供多种协议(如 VMess、Trojan、Hysteria2、ShadowTLS 等),不同协议在同一网络环境下的表现可能差异很大。部分网络对 TCP 类协议的深度包检测更严格,而基于 UDP 的协议(如 Hysteria2、TUIC)在丢包率较高的线路上反而更稳定,因为它们自带前向纠错和拥塞控制机制,能更好地应对丢包。如果订阅同时提供多种协议节点,建议逐一测试:

1. 先测 TCP 类协议(VMess/Trojan)的实际下载速度。
2. 再测 UDP 类协议(Hysteria2/TUIC)在同一时间段的表现。
3. 记录两者差异,固定使用速度更稳定的一类协议。

检查是否命中了限速或干扰

某些网络环境会对识别出的代理流量进行限速而非直接封锁,表现为连接能建立、延迟测试正常,但传输速度被限制在一个很低的固定值(例如稳定卡在 200KB/s 左右,无论换哪个节点都是同样的数值)。这种情况下换节点没有意义,需要考虑更换传输层的伪装方式,例如启用 TLS 伪装或切换到抗干扰能力更强的协议。

确认 TUN 模式与系统代理的差异

TUN 模式在系统网络层接管全部流量,常见于需要处理非浏览器应用(游戏、后台服务)代理的场景,理论上不应该比系统代理慢,但如果本机同时开着其他虚拟网卡或安全软件的网络钩子,可能出现相互干扰导致的丢包重传。可以做一次对照测试:关闭 TUN 模式,改用系统代理模式测试同一节点的速度,如果系统代理模式明显更快,问题大概率出在本机网络驱动层面,而不是节点或协议。

第三层排查:本地客户端与系统配置

如果前两层都没找到问题,大概率是本地设置在拖后腿。这一层排查成本略高,但往往是长期反复出现速度问题的根源。

调整 DNS 解析设置

DNS 解析慢会造成"页面首次加载慢、但资源加载后很流畅"的假象,容易被误判为节点问题。建议在配置文件里为客户端指定独立的 DNS 服务器,并开启 fake-ip 模式减少不必要的真实 DNS 查询延迟:

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - 223.5.5.5
    - 119.29.29.29
  fallback:
    - https://1.1.1.1/dns-query
    - https://dns.google/dns-query

nameserver 用于处理国内域名解析,fallback 用于代理域名的解析,两者分开配置能避免国内网站被绕道解析导致的额外延迟。

精简分流规则

规则数量过多、规则集体积过大,会增加客户端匹配每条连接所需的时间,在低性能设备(尤其是路由器或旧手机)上表现更明显。检查是否加载了多个功能重叠的规则集,例如同时启用了两套广告过滤规则或多份地区分流规则,合并或删减重复规则可以减少匹配开销。同时确认规则顺序是否合理——高频匹配的规则(如国内直连域名)放在规则列表靠前的位置,能减少平均匹配次数。

关闭后台占用带宽的程序

云同步工具、系统自动更新、后台下载任务都会占用出口带宽,与代理流量竞争,表现为"代理本身没问题,但整体网速就是上不去"。测速前建议先检查任务管理器或活动监视器里的网络占用情况,暂停明显占带宽的后台进程后再测一次。

确认客户端版本与内核状态

使用较旧版本的客户端或内核,可能缺少后续版本对某些协议的性能优化。如果长期存在速度问题且以上排查均未发现原因,可以检查是否有新版本可用,更新后重新走一次上述三层排查流程,确认问题是否随版本更新解决。

建立一套可复用的排查流程

把上述内容整理成一份简单的检查清单,遇到速度问题时按顺序过一遍,能明显减少排查耗时:

1. 延迟测试筛掉明显异常的节点。
2. 同地区节点做实测下载速度对比,排除负载问题。
3. 切换协议类型,对比 TCP 类与 UDP 类的表现。
4. 关闭 TUN 模式做对照测试,排除本机网络层干扰。
5. 检查并调整 DNS 配置,确认解析速度。
6. 精简分流规则,减少匹配开销。
7. 排查后台占用带宽的程序。
8. 确认客户端与内核版本是最新的。

大多数速度问题在前三步就能定位。真正需要走到本地配置层面排查的情况相对少见,但一旦出现,往往是长期反复困扰的根源,值得花时间彻底排查一次而不是反复换节点应付。