Clash 速度慢怎么排查:节点、线路、本地设置三层定位法

为什么要按三层排查,不要一上来就换节点

速度变慢是使用 Clash / Clash Meta(mihomo 内核)过程中最常见的反馈,但"变慢"背后可能是三层里的任意一层出了问题——节点本身质量下降、跨境传输线路拥堵、或是本地客户端配置不当。很多人的第一反应是换节点,换了几个还是慢,又怀疑是不是订阅出了问题,反复折腾却始终没找到根因,原因就是没有分层验证:三层问题的表现几乎一样(都是"卡"、"慢"、"加载不出来"),但排查方法完全不同,混在一起测只会浪费时间。

本文按照由远到近的顺序拆解:先确认节点本身是否健康(延迟、丢包、倍率),再确认跨境线路是否在拥堵(高峰时段、出口带宽),最后检查本地设置是否拖了后腿(DNS、规则命中、TUN 模式与系统代理冲突)。每一层给出可以直接执行的判断动作,而不是笼统的"换个节点试试"。

第一层:节点质量——延迟、丢包与倍率

节点质量是最容易验证也最该先查的一层。客户端界面里节点右侧显示的延迟数值,来自策略组的 url-test 探测,反映的是本机到节点再到测试地址的往返时间,数值本身只能作参考,更重要的是看它是否稳定。

除了延迟,还要关注丢包率和流量倍率。丢包率高会导致 TCP 反复重传,表现为网页加载卡顿、视频缓冲频繁,但延迟数值本身可能并不高——这也是很多人只看延迟数字判断"节点很好"却实际很卡的原因。流量倍率则直接影响可用带宽感受,同一批共享节点,低倍率往往意味着更少人挤占带宽,高峰期差异会更明显。

验证节点是否稳定的一个简单方法是把 url-test 策略组的探测间隔调短、把测试地址换成离目标服务更近的站点,连续观察几分钟的延迟曲线,而不是只看瞬时数值:

proxy-groups:
  - name: 自动选择
    type: url-test
    proxies: [节点A, 节点B, 节点C]
    url: "https://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 50

tolerance 表示容差范围,数值内的延迟差异不会触发切换,可以避免节点在临界值附近频繁跳动;interval 控制探测频率,过短会增加节点侧压力,过长则不能及时反映延迟变化,一般设置在 180~300 秒之间比较合理。

第二层:跨境线路与高峰时段拥塞

如果确认了某个节点本身延迟低、丢包少,但特定时间段依旧明显变慢,问题往往出在跨境传输线路上,而不是节点服务器本身。国际出口带宽是有限资源,晚间 20:00~23:00 这类高峰时段,同一批用户集中访问,叠加国际出口的整体带宽压力,即便节点服务器负载正常,实际可用速度也会打折。

识别这类问题的方法很直接:在不同时间段用同一个节点重复测速并记录结果。如果延迟和速度呈现明显的"昼夜规律"——比如凌晨速度正常、晚间集中变慢——基本可以判定是线路拥塞而非节点问题。反之如果全天任意时段都慢,大概率要回到第一层重新检查节点本身。

另外要区分"直连中转"和"落地直出"两种线路结构:前者流量在中间节点做一次转发,后者直接由落地服务器出口访问目标站点。中转结构在跳数增加的同时也可能引入额外拥塞点,如果同地区有多个节点可选,不妨分别测试,选出跳数更少、延迟曲线更平稳的一个作为日常使用节点,把延迟高但偶尔急用的节点留作备选,通过策略组的手动选择模式做区分,而不是依赖自动测速在两者之间来回切换。

第三层:本地配置——DNS、规则命中与模式冲突

排除了节点和线路两层之后,如果速度问题依旧存在,基本可以确定是本地客户端配置的问题。这一层最容易被忽视,却也是最常见的"隐性降速"来源。

DNS 解析方式

DNS 配置不当会导致域名解析走了错误路径,即便代理规则本身正确,访问体验也会变慢或者出现"部分网站能打开、部分打不开"的情况。mihomo 内核推荐使用 fake-ip 模式配合独立的 DNS 服务器,避免解析请求泄漏给本地运营商 DNS 或被污染:

dns:
  enable: true
  ipv6: false
  default-nameserver: [223.5.5.5, 119.29.29.29]
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - "https://doh.pub/dns-query"
    - "https://dns.alidns.com/dns-query"
  fallback:
    - "https://1.1.1.1/dns-query"

如果使用的是 redir-host 模式,解析结果依赖本地网络环境,容易受到运营商 DNS 污染或劫持影响,建议非特殊需要都改用 fake-ip。

规则命中与策略组选择

规则文件顺序错误或规则集未及时更新,会导致本该走代理的流量被判定为 DIRECT 直连,或者反过来把本地服务的流量也丢进了代理组,两种情况都会表现为"网速变慢"。可以在客户端的连接日志或流量面板里查看具体连接实际匹配到了哪条规则、走了哪个策略组,确认是否与预期一致,而不是单凭主观感觉判断。

TUN 模式与系统代理冲突

同时开启 TUN 模式和系统代理,或者 TUN 模式下 MTU 设置过大导致分片重传,都会造成明显的速度下降。一般建议二选一:需要接管全局流量、覆盖非浏览器应用时用 TUN 模式,只需要浏览器等少数应用走代理时用系统代理即可,避免两种接管方式叠加造成路径混乱。

三层排查流程小结与自查清单

把上面三层串起来,形成一个可以照做的排查顺序,能大幅缩短定位问题的时间,避免反复更换节点却始终没找到根因。

1. 先测节点

   切换 2~3 个同地区节点,连续观察延迟曲线与丢包情况,排除节点本身失效或负载过高的可能。

2. 再测线路

   用同一个确认健康的节点,在高峰与非高峰时段各测一次,判断是否存在明显的昼夜规律性降速。

3. 最后查本地

   检查 DNS 模式是否为 fake-ip、查看连接日志确认规则命中是否符合预期、确认 TUN 模式与系统代理没有同时开启。

4. 记录结果再下结论

   把三层的测试结果分别记下来,再决定是换节点、换时段使用,还是调整本地配置,避免同时改动多处导致无法定位到底哪一步起了作用。

大部分反复出现的"速度慢"问题,最终都能归到这三层中的某一层,而且往往不是单一原因,而是几层叠加放大了体感上的卡顿。按顺序逐层验证,比凭感觉反复换节点更省时间,也更容易把问题描述清楚,方便向订阅提供方或社区反馈具体现象。