故障排查 预计阅读 13 分钟

Clash 速度慢分层排查法:先分清节点、线路还是本地设置的问题

把「慢」拆成三层逐一验证:节点侧看延迟与倍率,线路侧看跨境高峰拥塞,本地侧查 DNS、分流命中与系统代理冲突。附每层可直接执行的测试步骤与判断依据。

先定义“慢”：延迟、带宽与响应时间不是一回事

Clash 或 mihomo 面板里显示的延迟只有几十毫秒，网页仍可能打开缓慢；反过来，一个延迟为 180 ms 的节点也可能稳定跑满宽带。原因是延迟、丢包、可用带宽和网站响应时间描述的是不同环节。排查前若只盯着节点列表中的一个数字，很容易把线路拥塞误判成客户端故障。

现象 优先检查 判断重点
点击网页后停顿 2 至 5 秒，随后加载正常 DNS、本地规则、IPv6 首个请求是否卡在域名解析或连接回退
测速开始很快，数秒后降到较低速度 节点负载、线路拥塞、限速 持续吞吐是否稳定，是否只在晚高峰下降
视频能打开，但频繁降低清晰度 持续带宽、丢包、分流结果 视频域名是否进入预期策略组
浏览器正常，游戏或商店客户端很慢 TUN 模式、UDP、系统代理覆盖范围 目标程序的连接是否真正进入 mihomo
所有节点同时变慢 本地网络、运营商线路、DNS 直连基线是否也发生下降

建立可重复的测试基线

开始切换节点之前，先固定测试条件。建议关闭正在同步文件、下载更新或播放视频的应用，让同一台设备连接同一个路由器，并选定两个测试目标：一个用于观察网页首开时间，另一个用于持续下载。每轮测试至少进行 3 次，记录中位数，不要用单次峰值下结论。

  1. 在客户端切到“直连”模式，记录本地宽带的延迟和下载速度。
  2. 恢复“规则”模式，固定同一个测试节点和同一个测试地址。
  3. 分别在上午、晚间 20:00 至 23:00 测试，比较时段差异。
  4. 记录客户端当前模式、节点名称、下载速度、首开等待和是否出现超时。

第一层：节点侧检查延迟、负载与协议状态

节点侧问题通常表现为同一策略组内只有少数节点明显变慢，切换到其他地区或其他入口后立即恢复。这里要区分“延迟测试能通过”和“节点具备稳定吞吐”两个结论。Clash 面板中的延迟测试通常是通过指定 URL 发起连接并测量响应时间，它能筛除失联节点，但不能直接代表大文件下载速度。

用策略组做同条件横向比较

进入客户端的“代理”页面，找到当前规则实际引用的策略组。以常见桌面客户端为例，可沿“代理”→“节点选择”查看组内节点；如果使用 Clash Verge Rev，可在“设置”→“Clash 设置”确认当前运行模式，再回到“代理”页面切换节点。不要一边更换节点，一边修改 DNS、TUN 或规则，否则无法判断是哪项变化产生效果。

  • 先选 3 个同地区节点，分别执行延迟测试 3 次。
  • 延迟波动超过 100 ms，或连续出现超时，优先视为节点或入口不稳定。
  • 延迟稳定但下载速度低，再进行至少 60 秒的持续下载测试。
  • 同地区全部偏慢时，增加一个不同地区节点作为对照。
  • 只有单个节点慢，直接更换节点通常比继续调整本地参数更有效。

倍率不等于速度

订阅面板中常见的“0.5 倍”“1 倍”“2 倍”通常表示流量计费倍率，不是速度倍数。一个 2 倍节点不会天然比 1 倍节点快两倍；它可能采用不同线路，也可能只是流量扣除比例不同。判断速度仍应依据实测吞吐、丢包和时段稳定性。

自动测速组可能选到“低延迟、低带宽”节点

url-test 策略组会按测试 URL 的响应结果自动选择节点。若测试目标返回的数据很小，某个节点可能因握手快而胜出，但其持续带宽并不理想。可以适当增大测试间隔，避免频繁切换；也可以把稳定性接近的节点放入同一组，而不是把所有地区混在一起。

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

interval: 300 表示每 300 秒测试一次，tolerance: 80 用于减少延迟差异较小时的频繁切换。这里的 URL 只负责可用性与响应测试，不应被当作完整带宽测试。修改订阅生成的配置前，还要确认客户端更新订阅时是否会覆盖本地改动。

第二层：线路侧判断高峰拥塞、丢包与路由变化

线路问题位于本地运营商、跨网互联、入口服务器和出口服务器之间。它经常具有明显的时间特征：白天速度正常，晚间 20:00 后延迟升高；或者移动网络正常，家庭宽带变慢。此时反复重装客户端、删除配置通常不会改变结果。

用时间和接入网络做交叉验证

对照结果 更可能的问题层 下一步
同一节点白天 150 Mbps，晚间降至 15 Mbps 高峰拥塞或节点晚间负载 换入口、地区或低峰时段复测
家庭宽带慢，手机热点正常 固定宽带出口或跨网路径 保留同节点，比较两种接入网络
所有节点与直连同时变慢 本地接入、Wi-Fi 或运营商故障 有线连接路由器并测试直连
亚洲节点正常，远距离节点普遍抖动 长距离路由与丢包 优先选择距离较近的入口

测试时应保持节点和客户端设置不变，只切换网络。例如先通过家庭 Wi-Fi 测试，再使用手机热点测试。若热点环境下速度从 12 Mbps 恢复到 90 Mbps，说明客户端和节点至少能够提供更高吞吐，问题更可能出现在家庭宽带到节点入口的路径上。

延迟波动比单个低延迟更值得关注

连续测试得到 58 ms、61 ms、64 ms，通常比 28 ms、190 ms、超时更稳定。后者虽然出现过更低数字，但抖动和丢包会导致 TCP 重传，下载速度随之下降。视频、远程桌面和游戏还会对抖动更敏感。

在 Windows 中可先用 PowerShell 检查节点入口端口能否建立 TCP 连接。把示例主机和端口替换为订阅节点实际使用的值：

Test-NetConnection example.com -Port 443
ping example.com -n 20

在 macOS 或 Linux 中可进行连续延迟观察：

ping -c 20 example.com
curl -x http://127.0.0.1:7890 -o /dev/null -s -w "connect=%{time_connect} total=%{time_total}\n" https://www.gstatic.com/generate_204

示例中的 7890 是常见混合端口，不是固定值。实际端口应在客户端“设置”→“端口设置”或配置文件的 mixed-port 字段中确认。若命令返回连接被拒绝，先检查 mihomo 是否运行、端口是否一致，而不是直接判断远端节点失效。

第三层：本地设置检查 DNS、规则命中与代理冲突

如果多个节点表现相近，而且更换网络后问题仍然存在，就应回到本地配置。常见症状包括网页首次打开慢、某个应用不走代理、规则模式慢而全局模式正常，以及开启 TUN 后速度突然下降。本地层应按“连接是否进入内核、规则是否选对策略、DNS 是否顺畅”的顺序检查。

先看连接日志，不要只看节点名称

打开客户端的连接或日志页面，然后重新访问出现问题的网站。常见客户端可从“日志”或“连接”页面查看目标域名、命中的规则和最终策略。应确认三个信息：域名是否被 mihomo 捕获、命中了哪条规则、最终使用了哪个策略组与节点。

  • 若连接记录中完全没有目标应用流量，检查系统代理或 TUN 接管范围。
  • 若目标域名命中 DIRECT，但预期应代理，检查规则顺序和规则集更新状态。
  • 若命中了错误地区的策略组，回到“代理”页面检查组内当前选择。
  • 若日志持续出现 DNS 超时，优先处理解析链路。
  • 若同一请求重复建立连接，检查系统中是否还有另一套代理软件。

Clash 规则从上到下匹配，先命中的规则生效。过于宽泛的规则放在前面，可能让后续精确域名规则失效。例如 GEOIP,CN,DIRECT 通常应位于域名规则之后、最终 MATCH 之前。调整时一次只移动一类规则，重新载入后再从连接日志验证。

rules:
  - DOMAIN-SUFFIX,example.net,代理节点
  - DOMAIN-KEYWORD,stream,媒体策略
  - GEOIP,CN,DIRECT
  - MATCH,代理节点

用全局模式做短时对照

当规则模式很慢时，可以短暂切换到全局模式，用同一节点访问同一目标。如果全局模式立即恢复，而规则模式持续缓慢，问题通常不是节点带宽，而是规则命中、DNS 分流或某些资源走了不同路径。测试结束后应切回规则模式，再根据日志修正规则，不建议长期用全局模式掩盖配置问题。

DNS 慢常表现为“先卡住，后面很快”

域名解析超时会拉长首个请求。尤其在多个 nameserver 质量差异较大、IPv6 可解析但连接不可达，或系统 DNS 与 mihomo DNS 路径混用时，浏览器可能等待失败连接回退。可以在配置中统一 DNS 处理，并确认客户端已成功加载配置。

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://223.5.5.5/dns-query
    - https://1.1.1.1/dns-query

ipv6: false 适合用于验证 IPv6 回退是否造成等待，并不代表所有网络都应永久关闭 IPv6。如果本地和代理链路均完整支持 IPv6，可以恢复后重新测试。fake-ip 能让域名流量更早进入规则判断，但局域网设备、部分游戏和依赖真实地址的服务可能需要加入 fake-ip-filter。

检查系统代理与浏览器代理是否叠加

桌面环境里常见的冲突是：客户端已经设置系统代理，浏览器扩展又把流量转发到另一个端口；或者旧客户端退出后仍留下系统代理地址。此时请求可能绕行两次，甚至在本机形成失败重试。

  1. 进入客户端“设置”→“系统代理”，确认当前开关状态。
  2. 进入“设置”→“端口设置”，记录 HTTP、SOCKS 或 mixed 端口。
  3. 检查浏览器代理扩展，暂时改为跟随系统代理。
  4. 检查操作系统网络代理，确认地址通常为 127.0.0.1，端口与客户端一致。
  5. 完全退出其他代理客户端，再复测首开和持续下载。

若配置使用 mixed-port: 7890，HTTP 和 SOCKS 客户端都可以连接该端口。不要同时把同一浏览器请求先交给 SOCKS 扩展、再转到系统 HTTP 代理。对于只需要浏览器代理的场景，系统代理已经生效时，扩展通常只需保持直连或跟随系统设置。

TUN 模式专项：应用接管、MTU 与 UDP

TUN 模式通过虚拟网卡接管不遵循系统代理的应用流量，适合游戏客户端、命令行工具和部分商店应用。但它引入了额外的路由、DNS 劫持与数据包处理环节。若“关闭 TUN 正常，开启 TUN 变慢”，应检查 TUN 配置，而不是先更换全部订阅节点。

先判断是否只有 TUN 路径受影响

  1. 固定一个节点，在系统代理开启、TUN 关闭时测试浏览器。
  2. 保持节点不变，开启 TUN，再测试相同地址。
  3. 查看连接页面，确认两轮测试命中同一规则和同一节点。
  4. 若只有开启 TUN 后下降，检查虚拟网卡冲突、MTU 和网络栈。
tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

stack: mixed 是 mihomo 常见的兼容选择。若设备同时运行 VPN、虚拟机、容器网络或游戏加速工具，自动路由可能选错出口网卡。此时可先退出其他会创建虚拟网卡的软件，再重启客户端测试。不要同时修改 stack、MTU 与 DNS 劫持，否则难以定位具体原因。

MTU 不合适时的典型表现

MTU 问题可能造成小网页能开、大文件卡住，或者特定站点上传失败。可以从较保守的数值开始对照，例如在 TUN 配置中测试 mtu: 1400，确认有效后再逐步调整。不同系统、宽带拨号和上层隧道的合适数值并不相同，因此 1400 只是排查起点。

tun:
  enable: true
  stack: mixed
  mtu: 1400
  auto-route: true
  auto-detect-interface: true

如果修改 MTU 后大文件下载明显恢复，而节点和规则均未变化，说明分片或路径 MTU 发现可能参与了故障。若没有改善，应恢复原配置，继续检查 DNS 和线路，而不是不断降低数值。

订阅与内核状态：排除旧配置和版本错配

订阅更新失败不会必然让所有节点离线，有时客户端仍在使用缓存配置，导致节点入口、规则集或 DNS 参数长期未更新。排查时应确认“订阅更新时间”和“当前运行配置”是同一份内容。更新订阅后还要执行应用或重新载入，不能只看到下载完成就认为内核已经切换。

检查订阅更新时间与配置载入结果

  • 在“订阅”或“配置”页面查看最后更新时间，确认不是数周前的缓存。
  • 手动更新后检查是否出现 HTTP 超时、鉴权失败或内容为空。
  • 更新成功后选择该配置并重新载入。
  • 进入日志页面，确认配置解析成功，策略组和规则集已生成。
  • 如果订阅包含覆写功能，检查本地覆写是否仍适配当前字段。

旧版 Clash 配置迁移到 mihomo 时，基础的代理、策略组和规则结构通常仍可使用，但部分扩展字段、TUN 参数和规则集行为可能随版本变化。出现配置载入错误时，应先根据日志定位字段，而不是删除整个订阅。内核版本可以在客户端“设置”→“内核”或“关于”页面查看；不同客户端的菜单名称会略有差异。

十分钟排查流程与结果判断

当故障正在发生时，可以按下面的顺序快速缩小范围。核心原则是每轮只改变一个变量，并记录变化前后的结果。

  1. 第 1 分钟：关闭后台下载，用直连模式测一次本地基线。
  2. 第 2 至 3 分钟：恢复规则模式，固定测试节点，记录延迟、首开时间和 60 秒下载速度。
  3. 第 4 分钟：切换同地区另一个节点。只有原节点慢，归入节点侧。
  4. 第 5 分钟：切换不同地区节点。全部代理节点慢但直连正常，继续判断线路或本地设置。
  5. 第 6 分钟：用手机热点复测同一节点。热点恢复，优先判断家庭宽带路径。
  6. 第 7 分钟：查看连接日志，核对规则、策略组和目标节点。
  7. 第 8 分钟：短暂切换全局模式。全局恢复则重点检查规则和 DNS。
  8. 第 9 分钟：关闭浏览器代理扩展和其他代理客户端，消除本地叠加。
  9. 第 10 分钟：对比 TUN 开关；只有 TUN 慢时，再检查虚拟网卡、MTU 和 DNS 劫持。
最终结果 判断 处理方向
换一个节点立即恢复 单节点负载或入口异常 更换节点，观察原节点后续状态
同地区都慢，其他地区正常 地区入口或对应线路拥塞 临时选择其他地区
热点正常，固定宽带慢 接入运营商或跨网路径问题 更换入口并分时段复测
全局正常，规则模式慢 规则命中或 DNS 分流问题 按连接日志修正规则
浏览器正常，独立应用慢 系统代理未覆盖该应用 检查 TUN 或应用内代理
关闭 TUN 恢复 TUN 路由、MTU 或虚拟网卡冲突 逐项调整 TUN 配置
直连和代理都慢 本地网络或运营商接入异常 改用有线、重测路由器与宽带

排查记录应该保留哪些数据

如果需要向订阅服务方、网络管理员或客户端项目反馈问题，只说“速度慢”很难复现。应提供可比较的数据，但不要公开订阅地址、节点密码或完整配置。推荐保留测试日期、时段、接入网络、客户端版本、mihomo 内核版本、节点地区、运行模式和测试结果。

测试时间：2026-06-20 21:30
接入网络：家庭宽带，有线连接
运行模式：规则模式，TUN 开启
本地直连：286 Mbps
节点 A：延迟 72 ms，持续下载 18 Mbps
节点 B：延迟 81 ms，持续下载 96 Mbps
手机热点 + 节点 A：74 Mbps
规则命中：MATCH → 代理节点
现象：晚间下降，白天恢复

这组记录可以直接支持判断：节点 A 在家庭宽带晚间路径下表现较差，而节点 B 和手机热点对照说明客户端基础设置并未完全失效。相比反复清空配置，这类分层证据更容易找到真正需要更换或调整的环节。

前往客户端下载页