Clash 网速慢的分层诊断：节点质量、线路路由与本机设置逐层定位

先区分慢在哪里：打开、传输还是连接不稳定

Clash 网速慢并不是一个单一故障。网页点开后等待数秒，但文件下载很快，通常要先看 DNS、建连和目标服务响应；下载开始很快，随后降到低速，更值得检查线路拥塞、节点限速和丢包；只有某个应用慢，则要先确认它是否进入代理、命中了哪条规则。把症状分清，比直接开启 TUN 或更换 DNS 更有效。

这里的 Clash 指客户端及其代理工作流；实际支持的配置由正在运行的内核决定。使用 mihomo 的客户端与旧版 Clash 客户端，DNS、TUN 和协议支持可能不同。排查前在客户端的「关于」或内核信息页记录客户端版本与内核版本，不要仅凭应用名称判断支持范围。

建立一份可复现的测试记录

• 固定网络：同一台电脑、同一路由器，先用网线或靠近路由器的 Wi-Fi；暂停云盘同步、系统更新和其他下载。
• 固定目标：使用同一网页、同一文件来源。不同测速站的服务器和并发数不同，不能直接比较结果。
• 固定策略：记录规则模式、实际代理组和节点名称；测试期间不要让自动选择组切换节点。
• 固定时长：连续传输约 30 秒，记录稳定阶段速度，重复 3 次；不要只记第一秒的峰值。
• 记录时间：至少写下测试时刻、系统代理或 TUN 状态、延迟与吞吐量单位。

节点层：延迟低不代表下载带宽高

客户端的节点延迟通常来自内核通过该节点请求一个指定 URL，测得的耗时受测试目标、连接复用、节点出口与服务响应影响。它不是节点的带宽测试，也不一定等同于 ICMP ping。订阅中自带的「倍率」「高速」等名称同样不能替代实际传输测试。

用相同条件比较两到三个节点

1. 打开实际承载目标请求的代理组，临时手动选定节点 A。如果当前策略指向嵌套代理组，还要确认最后落到哪个节点。
2. 请求同一个延迟测试 URL，连续测 3 次，留意波动和超时，而不只是最小值。
3. 使用同一文件来源进行约 30 秒传输，关闭上一轮下载再测试节点 B。
4. 查看客户端连接列表，确认这些请求确实通过选定节点，避免规则将测速域名分流到其他策略。

示例中的 A 可能更适合频繁的小请求，B 对持续下载更有优势。但目标网站的出口路由不同，换一个服务可能得到相反结果。若只有一个节点慢，而其他节点在同一时段正常，优先检查该节点的负载、限速或到目标网站的路径，不必马上修改本机配置。

自动测速组的作用边界

url-test 主要按指定 URL 的延迟选节点；fallback 通常按顺序使用可用节点。两者都不保证选择最大吞吐量。排查时先手动锁定节点，确认问题后再恢复自动策略。不要把测速间隔压到几秒：频繁探测会增加请求量，也会让观察结果更难与实际使用对应。

线路层：高峰拥塞、本地网络与目标出口

一条代理连接经过本地网络、运营商、节点入口、节点出口和目标服务。客户端中的单个延迟数字无法指出哪一段拥塞。如果每天晚间变慢、白天恢复，且多个节点一起下降，先按时段和入口线路对比，而不是不断刷新订阅。

用三个对照缩小范围

• 直连与代理：先测试可直连的常用站点。两者都慢，优先排查 Wi-Fi、路由器负载或宽带；直连正常而代理普遍慢，再检查代理入口和运营商路径。
• 宽带与手机热点：同一设备、同一节点改用热点。热点明显改善，说明原网络或运营商路径更可疑；同时注意蜂窝信号和热点自身的波动。
• 不同目标：同一节点访问两个服务。只有一个服务慢，可能涉及该服务的 CDN、出口路径、限速或账号状态，不能直接判定整个节点不可用。

例如同一节点在 10:00 稳定达到 7.5 MB/s，21:00 降到 0.8 MB/s，而本地直连下载仍有 10 MB/s，这组记录支持进一步调查高峰期代理路径或节点负载，但不能仅凭它断定运营商限速。补充另一入口节点和手机热点结果，结论才更可靠。

丢包与路由工具的限制

对网关连续 ping 可以检查本地链路是否明显不稳；对远端 IP 的 ping 或 traceroute，只能辅助观察部分路径。中间路由器可能降低 ICMP 响应优先级，某一跳不回应不等于业务流量在此丢失。普通 traceroute 也不会自动呈现「本机经代理节点再到目标」的完整路径，不应把它当作代理隧道的全程报告。

本机层：先确认系统代理、规则与实际连接

系统代理通常只影响愿意读取系统代理设置的应用，不会自动接管所有 TCP、UDP 流量。终端、游戏和部分独立网络组件可能忽略它。TUN 则通过虚拟网络接口和路由捕获符合条件的流量，覆盖范围更广，但也增加了路由、权限和 DNS 联动因素。

按连接记录检查流量去向

1. 在客户端中确认当前为规则模式，再打开出现问题的网页或应用。
2. 进入客户端的连接列表，核对目标域名或 IP、匹配规则、策略链和传输量。客户端界面名称可能是「连接」或「Connections」。
3. 如果请求命中 DIRECT，检查前面的域名规则、规则集或局域网规则是否符合预期。
4. 如果请求命中了代理，却使用了另一组节点，检查规则指定的策略组，而不是仅修改主界面上最显眼的组。
5. 如果没有对应连接，先检查应用自身的代理配置、代理绕过列表，以及流量是否确实进入当前内核。

规则按顺序匹配，前面命中后一般不会继续寻找后面的规则。排查时可以临时切换全局模式，选同一节点再比较。如果全局模式恢复正常，重点检查规则与策略组；全局模式会改变其他应用的流量去向，测试结束后应恢复原模式。

用显式代理请求排除应用设置差异

以下命令适用于本机 HTTP 混合代理端口为 7890 的情况。先查看运行配置中的 mixed-port；如果实际端口不同，调整命令中的端口。macOS、Linux 可使用 curl，Windows PowerShell 建议使用 curl.exe，避免旧环境中的命令别名差异。

curl --proxy http://127.0.0.1:7890 --noproxy "" \
  --connect-timeout 10 --max-time 20 \
  -o /dev/null -sS \
  -w 'connect=%{time_connect}s tls=%{time_appconnect}s first_byte=%{time_starttransfer}s total=%{time_total}s\n' \
  https://www.gstatic.com/generate_204

curl.exe --proxy http://127.0.0.1:7890 --noproxy "" --connect-timeout 10 --max-time 20 -o NUL -sS -w "connect=%{time_connect}s tls=%{time_appconnect}s first_byte=%{time_starttransfer}s total=%{time_total}s\n" https://www.gstatic.com/generate_204

这个 204 请求用于观察连接与响应时间，不测试下载带宽。通过本地 HTTP 代理时，time_connect 主要反映连接本地代理端口的时间，不能当作节点往返延迟；TLS 和首字节计时是从请求开始累计的，也不是各阶段的独立耗时。命令表现正常而浏览器仍慢，下一步检查浏览器代理、扩展、自带安全 DNS和缓存。

DNS 层：解析慢、Fake-IP 与浏览器安全 DNS

DNS 更常影响首次打开和域名分流，通常不会直接提升已经建立连接的大文件吞吐量。页面第一次打开等 3 秒，刷新后很快，可能涉及解析、连接复用或缓存；不能仅凭这一现象确定 DNS 故障。需要结合日志，看是否出现解析超时，以及连接是否拿到了预期域名。

先查实际使用的解析链

• 检查运行配置中的 dns.enable、enhanced-mode、上游解析器和相关策略，而不是只看订阅文件的原始内容。
• 浏览器启用 DNS over HTTPS 时，解析可能沿浏览器自己的通道进行；暂时关闭它做对照，再决定最终使用哪条解析链。
• 确认上游解析器本身可达。把不可达的解析服务写进配置，会增加等待或触发回退。
• 若解析器使用域名，注意用于解析该域名的引导 DNS 配置，避免把解析依赖绕成循环。

Fake-IP 用映射地址关联域名和连接，便于内核进行域名规则匹配。常见配置范围为 198.18.0.1/16，并非网站真实服务器地址。看到应用获得这类地址，不代表节点异常。某些局域网服务或特殊应用需要通过 fake-ip-filter 等方式处理，但不宜把所有域名都排除，否则可能改变预期的域名识别行为。

不要机械地在 Fake-IP 与 redir-host 之间来回切换。每次只改一项，重启相关连接，必要时按客户端提供的操作清理 DNS 缓存，再重复同一测试。系统解析工具的结果也未必代表浏览器或代理内核的结果：显式 HTTP 代理请求往往把目标主机名交给代理处理，本地一次 nslookup 无法验证整个解析链。

TUN 层：覆盖范围、UDP 与路由冲突

TUN 是流量接管方式，不是带宽加速开关。普通网页在系统代理下已经正常时，打开 TUN 不必然更快。反过来，不读取系统代理的应用可能只有在 TUN 接管后才真正进入代理，这种改善来自流量路径改变，而不是 TUN 提升了节点容量。

比较两种模式时保持同一节点

1. 保留配置副本，记录节点、规则模式和 DNS 设置。
2. 先关闭 TUN，只用系统代理测试支持代理的浏览器或显式代理命令。
3. 再按客户端要求启用服务模式或授权，打开 TUN；确认路由和连接记录确实发生变化。
4. 如果仅 TUN 模式异常，检查其他 VPN、虚拟网卡、路由规则和 DNS 接管是否冲突。
5. 测试后恢复日常设置，不要在尚未确认路径时同时改 TUN 栈、DNS 和节点协议。

浏览器的 HTTP/3 通常使用 QUIC，即 UDP 流量。系统 HTTP 代理和 TUN 对它的处理可能不同，还取决于应用、内核以及节点的 UDP 支持。若视频加载或部分站点异常，可以临时关闭应用的 QUIC 做对照；TCP 正常而 UDP 异常时，再调查 UDP 路径，不要直接把结论推广到所有下载。

MTU 调整放在后面

小请求成功、较大传输反复停顿，且问题只出现在特定隧道组合时，可以进一步检查路径 MTU。常见物理以太网 MTU 为 1500，但封装可能减少可用载荷。若已有相关证据，可把 TUN 的 MTU 临时设为 1400 做一次对照，保留原值以便回退；1400 不是通用最优值。调整无改善，就恢复原设置，继续检查丢包与路由。

同时观察本机 CPU、内存和安全软件活动。如果只有该设备慢，传输时某个核心持续接近满载，可能涉及加密处理、流量检查或客户端开销。旧设备不宜一边运行多个测速任务一边比较协议。企业设备的安全策略应由管理员协助检查，不要为测试直接关闭防护。

收敛结论：一轮只改一个变量

有效排查的结果应是「哪一层、什么条件下、哪项对照出现变化」，而不是堆积一组可能原因。每改一次配置，都保留前后记录；如果三个选项一起改了，即使速度恢复，也无法知道是哪一个起作用。

向节点服务方或客户端维护者反馈时，附上客户端与内核版本、操作系统、发生时间、网络类型、模式、目标服务、3 次测试结果，以及相关报错片段。公开前删除订阅地址、认证信息、节点密码和访问令牌；完整配置与日志可能含有这些数据。

推荐顺序是：确认请求确实走代理，固定节点比较，检查时段与网络，再处理 DNS、TUN 和本机负载。需要核对规则术语时可查看术语表；出现明确报错时可转到故障排查。订阅更新用于获取配置，通常不能直接解决现有节点的线路拥塞。