Clash 网速慢的分层排查：节点质量、线路拥塞与本地设置逐项定位

先区分延迟高、下载慢与网页首开慢

Clash 客户端显示的延迟，通常是内核通过指定代理访问测试地址所得的探测结果，不等于持续下载带宽。测试地址、超时时间和客户端实现都会影响数值。一个显示 80 毫秒的节点，仍可能因出口限速而只有很低的下载速度；显示 220 毫秒的远距离节点，也可能具有更高的持续吞吐量。

排查前先把“慢”写成可观察现象。记录操作系统、客户端名称、内核版本、当前配置、代理模式、实际选中节点，以及问题发生的网络环境。客户端版本与内核版本不是同一项，应分别从版本信息或启动日志中记录，不要只写“最新版”。

建立固定测试条件，避免一次改动多个变量

先关闭后台大文件下载、云盘同步和其他测速任务。无线网络尽量固定在同一位置；具备条件时用有线连接补测一次。路由器开启的其他 VPN、透明代理或分流服务也要记入测试条件，避免把两层代理的结果当成单层连接。

1. 测本地基线：关闭客户端的系统代理和 TUN，确认浏览器没有独立代理，再访问本地网络可直接连接的测速服务，记录下载、上传与延迟。这一步判断接入带宽，不代表代理出口性能。
2. 固定目标：选择一个允许测试的 HTTPS 下载资源，所有节点使用同一 URL、相同下载方式与并发数。不要让不同测速服务器成为额外变量。
3. 固定出口：把实际命中的策略组切到手动选择的单一节点，避免自动选择或故障转移在测试中途更换出口。
4. 重复三轮：每轮持续约 30 秒，轮次间隔约 15 秒，记录中位数，并注明时间段。大流量测试会消耗订阅额度，按需缩短。

切换节点后，应停止原下载并建立新连接。已有 TCP 连接通常不会因为策略组切换而自动迁移到另一个出口。需要清理连接时，优先只关闭测试应用对应的连接，避免打断其他正在进行的任务。

例如，记录表可以写成“节点 A：2.1、2.4、2.2 MB/s，中位数 2.2 MB/s”。这只是记录格式示例，不是本站实测。比较时同时记录失败次数；三次中两次超时，比单次峰值更能说明可用性。

节点质量：比较单节点吞吐与目标站点表现

节点质量包括入口可达性、服务器负载、限速策略，以及出口到目标网站的连通情况。客户端里的“一键测速”若只进行延迟探测，不能据此判断节点带宽。先在同一订阅中挑选两到三个候选节点，逐个完成固定目标测试，再看真实使用场景。

用连接记录确认测试确实经过目标节点

1. 打开客户端的「连接」页面，开始一个新的下载请求。
2. 按目标域名或进程筛选，查看命中规则与完整策略链。
3. 确认最终出口是刚选择的节点，而不是 DIRECT 或另一个独立策略组。
4. 若采用 proxy-providers，检查该代理集合的更新与健康检查状态；它与整个配置文件的更新不是同一件事。

如果节点 A 对多个目标都慢，而节点 B 在同一时间明显更快，优先考虑 A 的负载、带宽限制或路径问题。如果同一节点只有某个网站慢，其他下载正常，更像是出口到该站点的路由或 CDN 分配差异，不宜直接判定整个节点失效。

线路拥塞：用时间与接入网络做交叉验证

节点名称中的地区通常描述出口位置，不能完整说明从本地到入口、再到出口的路径。两个不同地区的节点也可能共用入口或中转，因此“换地区仍然慢”并不能排除线路问题。

建立两个对照维度

• 同网络、不同时段：例如分别在 10:00 与 21:00 测同一节点和目标。连续多天晚间明显下降，比偶发一次慢速更支持高峰拥塞判断。
• 同时间、不同网络：在几分钟内比较家庭宽带与手机热点。保持客户端、节点和目标不变，同时留意热点自身信号与资费限制。
• 同网络、不同入口线路：在服务方有明确线路说明时，比较不同入口的节点；不要仅按名称猜测线路独立性。

如果家庭宽带下多个节点都慢，而热点下恢复，问题范围更接近家庭接入、运营商互联或本地路由器。若同一节点在两个网络都慢、其他节点正常，则更应检查该节点及其出口。以上都是定位证据，不是仅凭一次结果就能确定的结论。

还可以观察路由器是否在大流量上传时出现延迟激增。上传打满造成的排队延迟会影响网页和交互请求；暂停上传后恢复，说明应先检查带宽占用与路由器队列管理。中间路由器不回应探测包很常见，单个跳点的丢包比例不能直接当成业务连接丢包。

规则与 DNS：确认慢请求的实际路径

诊断时优先使用规则模式并检查实际命中结果。Clash 与 mihomo 的规则通常按顺序匹配，前面的规则可能先于后面的域名规则生效。末尾的 MATCH 负责兜底；把目标域名追加到它后面，通常不会达到预期效果。

短时对照全局模式，而不是长期依赖它

在理解当前配置的前提下，可短时切到全局模式，并明确选择全局策略使用的节点。若同一节点在全局模式正常、规则模式异常，优先检查规则模式是否选到了不同策略组、直连出口或链式路径。测试结束后恢复原模式；全局模式可能改变本应直连的流量去向。

区分 DNS 等待与内容传输慢

• 只有首次访问慢，后续请求快：检查解析耗时、缓存与连接复用，不要立刻修改所有 DNS 字段。
• 域名请求失败，但其他站点正常：查看日志是否出现解析超时，核对上游 DNS 是否可达。
• 浏览器与其他应用表现不同：检查浏览器的安全 DNS 设置，它可能不遵循系统解析路径。
• 启用 Fake-IP 后出现 198.18.0.0/16 范围地址：这可能是正常的虚拟映射，不应仅凭该地址认定 DNS 故障；具体网段以配置为准。

在 mihomo 中，dns.nameserver、dns.proxy-server-nameserver 与 dns.nameserver-policy 分别涉及常规解析、代理服务器域名解析和按域名选择解析器，适用行为还取决于完整配置。不要把网上的一段 DNS 配置直接叠加到现有订阅上。修改前保留备份，单项调整后重新加载，并重新建立测试连接。字段说明可参阅完整手册的 DNS 章节。

系统代理与 TUN：检查应用覆盖和本地开销

系统代理主要服务于遵循系统代理设置的应用；TUN 通过虚拟网卡和路由接管更多 IP 流量，但实际覆盖范围仍受路由排除、应用绑定接口和客户端实现影响。TUN 不是提速开关，也不能突破节点限速。

先用显式代理隔离问题

下面命令以本机 HTTP 或混合代理监听 127.0.0.1:7890 为前提。先在客户端端口设置中核实实际值；7890 不是所有客户端的固定端口。Windows 可使用 curl.exe，避免部分 PowerShell 环境中的同名别名影响参数。

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}\nTLS=%{time_appconnect}\nfirst_byte=%{time_starttransfer}\ntotal=%{time_total}\n" \
  https://www.example.com/

这是适用于 macOS、Linux 等环境的短请求诊断命令，不是带宽测试。Windows 使用时将 curl 改为 curl.exe，输出目标改为 NUL，并把命令合并成一行。计时单位为秒，各项是从请求开始累计的时间；使用本地 HTTP 代理时，time_connect 主要反映到本地代理监听端口的连接，不代表到远端节点的延迟。

若显式代理请求正常、普通应用仍慢，检查应用是否遵循系统代理，是否安装了独立代理扩展，以及系统代理是否指向当前客户端端口。若请求提示连接被拒绝，先查内核是否运行、监听地址是否正确、端口是否被占用，不要先换 DNS。

分别测试两种接管方式

1. 保存现有设置，关闭 TUN，只启用系统代理，使用同一浏览器和目标测试。
2. 再关闭系统代理，只启用 TUN，确认测试请求出现在连接记录中，然后重复测试。
3. 观察任务管理器或活动监视器中的内核 CPU 占用，同时检查是否还有另一套 VPN 或虚拟网卡在改写路由。
4. 若仅 TUN 下出现卡顿，检查客户端日志、路由冲突和当前网络兼容性，再按客户端支持范围比较协议栈设置。

CPU 单核持续接近满载且吞吐受限，才是本地处理瓶颈的线索之一。不要同时修改 TUN 协议栈、MTU 和 DNS；特别是 MTU，应在存在大包传输卡住等证据时做对照，而不是把某个数值当成通用答案。

把排查结果收敛到可复现的问题

每次只改一项，保存修改前后的结果。以下对应关系可以帮助决定下一步，但仍需结合日志与重复测试：

向客户端维护者或订阅服务方反馈时，提供系统版本、客户端与内核版本、问题时段、接入网络、复现步骤和已脱敏日志。删除订阅 URL、令牌、认证信息及不必要的访问域名。只有发现内核兼容性问题或明确的修复记录时，才把升级客户端或内核作为下一步，并保留可恢复的原配置。

完整顺序是：先测本地基线，再固定节点比较吞吐，随后交叉验证线路，最后复核规则、DNS 与接管方式。需要继续处理订阅失败或延迟异常时，可查看疑难解答中的延迟排查；尚未确认导入与启用步骤时，先按订阅导入教程核对基础设置。