先固定测试条件：区分延迟、吞吐与首屏等待

排查顺序是先确认流量走向，再比较节点和线路，最后调整本地接管与 DNS。Clash 面板里显示的毫秒数不等于下载速度。节点延迟通常来自对指定测试地址的一次请求，结果还会受到连接复用、目标站点和测试实现影响；它不能直接代表大文件传输能力。

先把“慢”写成可重复的现象。例如“同一视频播放 1080p 经常缓冲”“网页第一次打开等候 5 秒，刷新很快”，或“下载前几秒正常，之后持续下降”。这几种情况的检查重点不同，不宜同时修改规则、DNS 和 TUN。

现象优先检查对照方法
网页开始加载前等很久DNS、连接建立、目标站响应比较首次访问与重复访问
视频缓冲、大文件持续低速节点出口、线路拥塞、带宽限制固定文件，连续测试三次
只有一个应用慢代理接管、UDP、进程规则观察该应用的新连接
所有访问都慢，包括直连Wi-Fi、路由器、宽带与后台占用暂停下载，改用有线网络

建立一组能复测的记录

  • 记录客户端版本、实际内核名称与版本。客户端界面版本不等于 mihomo 内核版本。
  • 固定一个下载资源、一个网页和一个节点，暂停云盘同步、系统更新及其他测速任务。
  • 每轮测试 30～60 秒，重复三次；记录测试时间、网络类型、节点、规则命中和持续速率。
  • 区分单位：100 Mbps 的理论换算是 12.5 MB/s，实际应用吞吐还要扣除协议开销。

第一层：确认节点是否具备持续传输能力

打开客户端的「代理」或「代理组」页面，先选定一个具体节点。自动选择组可能在测试期间切换成员，导致两次结果看似属于同一策略组，实际上走了不同出口。记录最终节点名称，比只记录“自动选择”更有用。

低延迟节点不一定下载更快

假设节点 A 的测试延迟是 45 ms、节点 B 是 120 ms，仍不能据此判定 A 的视频体验更好。A 可能存在带宽限制或出口拥塞，B 则可能有更稳定的持续吞吐。这里的数字仅用于说明比较方法，不是本站实测结果。

  1. 在同一个手动选择组中选节点 A，访问固定目标，记录三次持续速率。
  2. 只切换到节点 B，不改模式、不换 DNS，重复同样的测试。
  3. 再换一个来源独立的下载目标。如果仅某个站点低速，优先考虑目标 CDN、账号限速或出口与该站的互联。
  4. 检查订阅服务的剩余额度、到期时间和设备限制。配置可以导入，不代表服务端仍允许正常使用。

不要把所有节点同时做大流量测速。并发测速会争抢本地带宽，还可能消耗订阅流量。节点列表中的连通性测试适合快速筛掉失败项；需要比较吞吐时，逐个测试更容易得到可解释的结果。

换协议时保持服务器条件可比

协议支持由内核、节点配置与服务端共同决定。只有服务方提供了对应入口，才能比较不同协议；不能把订阅中的类型字段随意改成另一种协议。较公平的对照是同一服务方、相近地区、相同目标与相同时间段，再比较其提供的不同入口。

如果某个基于 UDP 的入口在当前网络表现异常，而另一个 TCP 入口稳定，这只是当前网络路径存在差异的线索。原版 Clash、Clash Meta 与 mihomo 的协议支持并不完全相同，遇到“不支持的代理类型”应先核对内核，而不是反复修改密码或节点名称。

第二层：区分本地接入、跨网线路与出口拥塞

节点可用但速度在晚间明显下降，常见原因是某一段链路拥塞。完整路径至少包括设备到路由器、本地运营商到节点、节点出口到目标站。只测节点服务器的延迟，无法覆盖全部路径。

用两组对照缩小故障范围

  • 同设备换网络：电脑分别连接家庭宽带与手机热点，保持节点和目标不变。热点正常、宽带异常时，重点检查宽带路径、路由器和 Wi-Fi。
  • 同网络换时段：在非高峰与晚间各测三次。如果多个节点只在晚高峰下降，继续比较不同服务方或不同接入线路。
  • 同出口换目标：一个目标慢、其他目标正常时，检查目标服务的区域调度、出口 IP 限制和 CDN 路径。
  • 同网络改有线：有线稳定、无线抖动时，先处理无线信号和信道干扰，节点切换不能解决无线链路丢包。

Windows 可运行 ping -n 20 192.168.1.1，macOS 或 Linux 可运行 ping -c 20 192.168.1.1，观察到本地网关的稳定性。这里假定网关为 192.168.1.1，实际地址应从系统网络设置读取。网关不响应 ICMP 时，不能仅凭超时判定网络中断。

tracert 或 traceroute 可以提供路径线索，但普通命令的流量不一定经过应用代理，也不一定与视频使用相同传输方式。中间路由器可能限制 ICMP 回复，因此某一跳不回应、后续跳正常，并不等于这一跳正在丢弃业务流量。

第三层：检查规则命中与应用接管

进入客户端的「连接」页面，部分界面称为「活动连接」，清理筛选条件后重新打开目标网页。重点查看目标域名或 IP、命中规则、策略链及最终出站。规则模式按顺序匹配；在常规规则列表中，前面的匹配项会影响后续规则是否有机会生效。

规则模式与全局模式做一次短对照

  1. 在「代理」页面记录当前策略组所选节点。
  2. 记录规则模式下目标连接的实际出站，确认它不是意外命中 DIRECT，也不是选中了另一组中的慢节点。
  3. 临时切换全局模式，并在全局策略中选择同一个节点。
  4. 关闭目标应用的旧连接，重新发起请求。已有连接不一定会因模式切换立即改走新路径。
  5. 测试后恢复规则模式。若全局正常、规则异常，优先修正规则与策略选择。

全局模式并不自动接管设备的全部流量。它决定的是进入内核之后如何选择出站；应用是否进入内核，仍取决于系统代理、应用自身代理设置或 TUN 接管。浏览器正常、游戏或命令行异常时，先检查入口，不要先认定节点失效。

用显式代理绕开系统代理设置差异

下面使用本机 HTTP 或 mixed 代理端口 7890 请求一个小页面。先确认客户端实际端口；SOCKS 专用端口不能直接套用此命令。Windows PowerShell 中使用 curl.exe，避免某些环境将 curl 解释成其他命令；macOS 与 Linux 使用 curl。

curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 30 --output /dev/null --silent --show-error --write-out "connect=%{time_connect}s first_byte=%{time_starttransfer}s total=%{time_total}s\n" https://example.com/

Windows 请将命令开头改为 curl.exe，并把 /dev/null 改为 NUL。示例地址只适合观察请求是否完成，不适合带宽测速。显式代理下的 time_connect 主要反映连接本地代理的时间；首字节时间还包含代理隧道建立、远端连接和服务器响应，不能直接称作“节点延迟”。

DNS 排查：首次打开慢与解析路径不一致

网页第一次访问慢、刷新明显变快时，DNS 是检查方向之一，但 TLS 建连与网页缓存也会产生类似现象。先在「日志」页面临时把日志级别调到 debug，复现一次，再查找目标域名的解析失败、超时或重复请求；完成后恢复原级别，避免大量日志影响排查。

分清系统解析与内核解析

系统执行 nslookup example.com 的结果不一定代表 mihomo 内部使用的结果。浏览器可能开启安全 DNS，内核可能启用 fake-ip，TUN 也可能配置 DNS 劫持。应该先确认请求由谁解析，再决定在哪一层调整。

  • 使用 fake-ip：常见的 198.18.0.0/16 是映射地址范围，看到该范围内的地址不等于解析损坏；应继续检查映射和连接是否正常。
  • 启用 DoH：解析器地址本身的解析与连接路径需要可达。不要让代理节点域名解析反过来依赖尚未建立的代理连接。
  • 涉及 IPv6：检查系统 IPv6 连通性、目标 AAAA 记录及接管配置。只在明确的对照测试中临时关闭某一层 IPv6，并在测试后恢复。
  • 修改订阅配置：优先使用客户端支持的覆写或扩展机制；直接编辑订阅生成文件，可能在下次更新时被覆盖。

不要一次照搬整套 DNS 配置。nameserver、proxy-server-nameserver 等字段在不同内核与版本中的支持情况需要核对。更换解析器后，应重新建立目标连接；仅刷新网页未必会清除系统、浏览器和内核的全部缓存。

TUN 与本地性能：只在接管路径异常时调整

TUN 通过虚拟网络接口接入流量，适合处理不遵循系统代理设置的应用，但它不是提速开关。如果显式代理正常、开启 TUN 后所有应用变慢，应重点检查路由、DNS 接管及其他网络软件的交互。

按顺序检查四项

  1. 权限与服务：确认客户端要求的服务模式或管理员权限已满足，日志中没有创建接口、添加路由失败。
  2. 重复接管：暂时退出其他 VPN 或另一个代理客户端，保留一个接管入口后复测。不要长期停用系统防火墙。
  3. 进程占用：在 Windows「任务管理器」或 macOS「活动监视器」查看客户端与内核进程。若传输时某个核心持续满载，再比较日志级别、规则规模与内核版本。
  4. MTU 与 UDP：如果小网页正常、大传输卡住，或只有使用 QUIC 的应用异常，再检查路径 MTU、UDP 转发能力及相关日志。不要把某个固定 MTU 值当成所有网络的通用答案。

对于支持设置的浏览器，可以临时关闭 QUIC 后完全退出并重启，观察 TCP 路径是否改善。若改善，只能说明 UDP 路径值得继续查，不能证明某种协议一定更快。完成测试后恢复原设置，避免把临时诊断措施遗留为长期配置。

收尾：按证据处理，不连续叠加配置

对照结果下一步
仅一个节点持续低速换可用节点，并向服务方提供时段与测试目标
同节点在手机热点正常检查家庭网络、运营商路径和高峰拥塞
全局正常，规则模式慢核对命中规则、策略链和最终节点
显式代理正常，TUN 异常检查路由、DNS 劫持与重复接管
仅第一次访问慢继续区分解析、握手和目标站响应时间

需要反馈问题时，提供客户端与内核版本、操作系统、网络类型、出现时间、复现步骤和脱敏日志。分享前移除订阅地址、访问令牌、节点密码及管理接口密钥；不要直接公开整份配置。

客户端选型可查看选型指南，系统代理与 TUN 的基础设置见使用文档。最终目标是找到能重复验证的差异：哪个节点、哪段网络、哪条规则或哪种接管方式导致变慢。确认原因后只保留必要改动，再用最初那组目标复测。