Clash 速度慢怎么办:节点、线路、本地设置三层逐级排查

先确认“速度慢”具体发生在哪里

Clash 显示已连接，但网页打开慢、视频频繁缓冲或下载速度低，不一定都是节点性能问题。完整连接包含本地应用、Clash 内核、DNS 解析、代理节点、运营商线路和目标网站。任何一段出现拥塞，都可能在 iPhone 上表现为“开了 Clash 就变慢”。

排查前先固定变量。选择同一个 Wi-Fi、同一个测速网站、同一个浏览器和同一个代理节点，每轮测试至少持续 30 秒，连续做 3 次。不要一边切节点一边切网络，否则无法判断改善来自哪里。

记录四组基线数据

例如，直连下载为 280 Mbps，开启代理后稳定在 85 Mbps，说明瓶颈位于代理链路或节点。若直连本身只有 18 Mbps，代理通常无法突破当前接入网络的上限。若测速速度正常，但网页首次打开要等待 3 至 5 秒，更应优先检查 DNS，而不是继续测试带宽。

第一层：检查节点本身的负载与协议

先在 Clash 的策略组页面确认当前实际选中的节点。使用“自动选择”或“故障转移”策略组时，首页显示的组名不等于最终出口节点；应进入「代理」或「策略」页面，展开对应策略组查看被选中的具体节点。

用固定文件测试持续吞吐

1. 保持当前节点不变，关闭正在进行的云同步、系统更新和视频播放。
2. 选择一个可重复访问的 100 MB 至 500 MB 测试文件，观察 30 秒后的稳定速度。
3. 等待 2 分钟后重复两次，记录最低值、中位值和最高值。
4. 只切换节点，不修改 DNS、规则模式或本地网络，再完成同样测试。

如果某节点三轮结果分别是 72 Mbps、69 Mbps、74 Mbps，表现较稳定。若结果在 8 Mbps、91 Mbps、17 Mbps 之间剧烈变化，常见原因是节点负载高、上游带宽共享或丢包。此时继续调整本机规则通常没有明显作用。

节点协议与设备性能

不同协议的加密、封装和传输方式会占用不同程度的 CPU。较新的 iPhone 通常可以轻松处理常见 Shadowsocks、Trojan、VLESS 和 WireGuard 流量，但老设备在高带宽、复杂加密或持续发热时可能降频。测试时可打开 iOS「设置」→「电池」，查看 Clash 客户端在测速期间是否持续占用较高电量，并确认设备没有处于明显发热状态。

• 只有单个节点慢：优先判断为节点负载、节点出口或节点配置问题。
• 同一地区全部节点慢：可能是该地区入口、出口或运营商互联拥塞。
• 所有协议都慢：继续检查中间线路和本地网络。
• 某一协议单独慢：检查该协议的传输参数、UDP 支持与服务端配置。

第二层：区分节点问题与中间线路问题

从 iPhone 到代理节点之间还要经过家庭路由器、宽带运营商、移动网络和跨网互联。节点本身空闲，并不代表你到节点的线路顺畅。最简单的区分方法，是保持节点不变，只切换接入网络。

完成 Wi-Fi 与蜂窝网络交叉测试

1. 在 Wi-Fi 下选择一个固定节点，完成三轮延迟与下载测试。
2. 关闭 Wi-Fi，使用 4G 或 5G，再测试同一节点。
3. 如果蜂窝网络明显更快，重启光猫与路由器，并检查宽带晚高峰表现。
4. 如果 Wi-Fi 更快，检查蜂窝网络信号、流量限速和当前基站负载。

例如，同一节点在家庭 Wi-Fi 下延迟 240 ms、下载 12 Mbps，在 5G 下延迟 96 ms、下载 83 Mbps，这通常不是节点整体故障，而是家庭宽带到该节点的路径较差。反过来，如果两种网络都稳定在 10 Mbps 左右，而直连分别达到 200 Mbps 和 150 Mbps，则节点端限制的可能性更高。

识别晚高峰与持续丢包

线路拥塞常在当地时间 20:00 至 23:00 集中出现。可以在上午、下午和晚间各做一次相同测试。如果白天稳定、晚间突然下降，不必频繁修改配置，先切换入口地区或不同运营商线路更有效。

延迟偶尔从 80 ms 跳到 180 ms 不一定影响下载；如果每隔几秒就出现超时，视频、语音和游戏会更容易卡顿。部分客户端只显示成功请求的延迟，超时节点可能看起来仍有一个正常数值，因此还要观察连接日志中是否连续出现 timeout、connection reset 或 context deadline exceeded。

检查家庭路由器与 Wi-Fi

• 优先使用 5 GHz 或 6 GHz Wi-Fi，避免拥挤的 2.4 GHz 信道。
• 靠近路由器复测，排除墙体遮挡和弱信号造成的重传。
• 暂时关闭路由器上的二次代理、家长控制和流量整形，避免重复处理。
• 确认局域网中没有设备正在上传照片、同步网盘或下载大型更新。
• 如果路由器和 iPhone 都运行代理，只保留一层作为测试，避免流量被重复转发。

第三层：检查 Clash 本地设置

当多个节点、多个接入网络都偏慢时，再检查 Clash 本地配置。重点不是一次修改十个开关，而是每次只改一项，复测后再决定是否保留。

先用规则模式与全局模式做对照

在客户端的「代理」或「模式」页面，把 Rule 临时切换为 Global，保持同一个节点完成测试。如果全局模式明显更快，说明规则模式可能让测速域名走了 DIRECT、选到了另一个策略组，或命中了不合适的规则。测试完成后应切回 Rule，再查看连接日志中的规则命中结果。

规则从上到下匹配，命中后不再继续。域名规则、规则集和 GEO 类规则的顺序不合理，可能导致目标网站走错出口。下载站域名直连，但其资源域名经过代理，也会出现页面打开正常、文件下载慢的情况。

精简高频健康检查

节点健康检查不会直接占满带宽，但数量很多、间隔过短时，会持续唤醒网络扩展并产生额外连接。包含 80 个节点的策略组若设置为每 30 秒检查一次，每小时可能产生 9600 次请求。日常使用可先把 interval 调整到 600 秒，规则提供者更新间隔可设置为 86400 秒。

proxy-groups:
  - name: 自动选择
    type: url-test
    proxies:
      - 节点 A
      - 节点 B
      - 节点 C
    url: https://www.gstatic.com/generate_204
    interval: 600
    tolerance: 80

rule-providers:
  common:
    type: http
    behavior: classical
    path: ./ruleset/common.yaml
    url: https://example.com/rules/common.yaml
    interval: 86400

这里的测试地址应选择稳定、返回内容很小且当前网络可访问的 URL。不要同时给多个大型策略组设置 30 秒或 60 秒检查。若客户端提供「设置」→「参数设置」→「健康检查」路径，可先关闭不使用策略组的自动测试。

检查 TUN 模式与 MTU

TUN 模式会接管更多系统流量，适合需要透明代理的应用，但错误的 MTU 可能造成分片、重传或部分网站加载缓慢。常见测试值是 1500、1400 和 1280。不要一次跨越多个值；先记录当前配置，再改为 1400 复测。如果问题只出现在蜂窝网络或特定 WireGuard 链路，可继续测试 1280。

tun:
  enable: true
  stack: mixed
  mtu: 1400
  auto-route: true
  strict-route: false

这段写法适用于支持 Clash.Meta 或 mihomo 配置语法的客户端，旧版 Clash 内核未必支持全部字段。iOS 客户端也可能把这些选项放在图形界面的「设置」→「参数设置」→「TUN」中。修改后应断开并重新建立系统 VPN，让网络扩展重新加载配置。

确认没有重复代理

iOS 同一时间通常只允许一个主要 VPN 配置活动，但浏览器代理、路由器代理和 Clash 仍可能形成多层转发。进入 iOS「设置」→「通用」→「VPN 与设备管理」→「VPN」，确认当前连接的是预期客户端。再打开「设置」→「无线局域网」→当前网络→「配置代理」，日常由 Clash 接管时通常应保持“关闭”。

DNS 慢与带宽慢要分开处理

DNS 主要影响域名解析和首次连接。典型表现是：输入网址后等待数秒，但页面一旦开始加载，图片和视频速度正常。若大文件已经开始下载后仍长期只有几百 KB/s，单独更换 DNS 通常无法解决持续带宽瓶颈。

用 IP 与域名表现做判断

• 所有网站首次打开都慢，刷新后变快：优先检查 DNS 超时与缓存。
• 只有特定域名慢：检查该域名的规则命中、IPv6 结果和 CDN 路径。
• 测速站延迟正常但下载低：回到节点和线路层排查。
• 日志反复出现 DNS timeout：切换可访问的 nameserver，并检查监听地址。

支持 mihomo 语法的配置可以先采用一组简单 DNS 设置进行对照。以下示例启用 fake-ip，主解析使用两个明确的 DNS 服务器，并避免同时堆叠过多 fallback。不同网络对公共 DNS 的可达性不同，应以当前地区的实测结果为准。

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: false
  enhanced-mode: fake-ip
  nameserver:
    - 1.1.1.1
    - 223.5.5.5
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"

1053 是 Clash DNS 常用的本地监听端口示例，不是外部 DNS 服务端口。若客户端已经自动管理 DNS，不要再让另一套本地服务占用同一端口。修改前可在「设置」→「参数设置」→「DNS」保存当前值，测试结束后按结果决定是否恢复。

单独测试 IPv6

部分网络能返回 AAAA 记录，但实际 IPv6 路径质量较差，表现为网站先等待、随后回退到 IPv4。可暂时把 dns.ipv6 设为 false 进行对照。如果关闭后首开速度明显改善，说明需要继续检查本地 IPv6、节点 IPv6 支持或目标站点的 IPv6 路径，而不是长期把所有问题归因于节点。

按结果选择下一步动作

完成三层测试后，应根据对照数据处理，而不是继续随机切换设置。下面的对应关系可以快速缩小范围。

使用最小配置做最终隔离

如果问题仍无法定位，可以建立一份只含 1 个节点、1 个策略组和 2 条规则的临时配置。监听端口使用常见的 7890，关闭脚本、规则提供者、流量嗅探和额外健康检查，只保留必要功能。最小配置正常，说明原配置中存在冲突或额外开销；最小配置仍慢，则应回到节点、线路或设备层继续处理。

mixed-port: 7890
mode: rule
log-level: info
ipv6: false

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - 测试节点

rules:
  - MATCH,PROXY

测试完成后，不要直接把临时配置当作长期配置。它的作用是隔离变量，不包含日常需要的直连、局域网、隐私和应用分流规则。确认原配置的问题范围后，再逐组恢复 DNS、规则集、TUN 和健康检查，每恢复一项就进行一次相同测试。

排查时常见的三个误区

只看节点延迟

延迟适合筛掉无法连接或响应明显过慢的节点，但不能表示带宽、丢包和晚高峰负载。至少加入一次持续 30 秒以上的下载测试。

同时修改 DNS、MTU 和规则

一次修改多项，即使速度恢复，也无法知道是哪一项生效。正确做法是保存原配置，每次只改一个变量，并记录修改前后的三轮结果。

把全局模式长期当作提速开关

全局模式适合做对照测试，它会让更多流量经过同一代理，并不天然更快。确认是规则命中问题后，应修正规则或策略组，再回到 Rule 模式。