Clash 网速慢的分层排查顺序:节点、线路到本机设置

开始前：区分打开慢、下载慢与连接中断

“Clash 网速慢”可能指三件不同的事：网页首次打开等待很久、下载速度持续偏低，或者视频播放一段时间就停顿。它们分别更接近解析与建连耗时、持续吞吐能力，以及链路稳定性。先描述症状，再调设置，能减少无效尝试。

• 首次打开慢，随后正常：优先观察 DNS、连接建立和目标网站响应，不要直接认定节点带宽不足。
• 大文件一直慢：先比较节点和运营商线路，同时检查服务端是否对单连接限速。
• 时快时慢、频繁重连：检查 Wi-Fi、丢包、节点负载和后台网络切换。
• 只有某个应用慢：先确认该应用是否进入代理，以及它实际命中了哪条规则。

固定测试条件

暂停网盘同步、系统更新和其他下载。固定同一个目标、同一个设备和同一段测试时长，每次只改一个变量。建议每组测试做 3 次，每次观察约 30 秒；若是付费流量，先确认测试消耗可接受。

记录当前客户端名称、内核类型、代理模式，以及系统代理和 TUN 的开关状态。Clash 是客户端生态中的常见名称，mihomo 是原 Clash.Meta 延续发展的内核；不同客户端和内核支持的设置并不完全相同，菜单名称也会变化。

第一层：节点质量，先看持续传输再看延迟

代理页中的延迟测试通常通过指定 URL 探测节点可用性与请求耗时。结果受测试地址、连接复用和客户端实现影响，不是节点到所有网站的速度排名。显示 60 ms 的节点，下载未必比 180 ms 的节点快。

用两个节点做对照

1. 进入客户端「代理」页，找到目标网站实际使用的策略组。若组内还有嵌套策略组，继续展开，确认最终节点。
2. 选定节点 A，重新建立目标连接，记录首次响应时间、稳定下载速度和是否出现停顿。
3. 切换节点 B，再建立新连接，以相同条件重复测试。已有连接可能继续使用旧出口，不能仅切换后盯着原下载任务。
4. 回到节点 A 再测一次，排除目标服务器刚好波动造成的误判。

例如，A 的探测延迟为 70 ms，稳定下载只有 1.2 MB/s；B 的延迟为 160 ms，稳定下载达到 7 MB/s。对大文件而言，B 更合适；对交互请求，仍需看实际响应与抖动。节点名称中的地区和倍率只能作为选择信息，不能证明物理路径或可用带宽。

节点层能确认什么

• 同一时间、同一网络下，只有一个节点慢：优先怀疑该节点负载、入口、出口或对应路径。
• 多个节点访问同一站点都慢，其他站点正常：继续检查目标服务、出口地区和规则，而不是立刻重装客户端。
• 订阅更新后速度变化：检查节点是否被替换、策略组是否重选。更新订阅本身不会增加带宽。

第二层：运营商线路，比较网络与时间段

节点到本机的路径会经过本地接入、运营商网络与节点入口。节点名称相同，不代表宽带和移动数据经过相同路径。晚间拥塞、跨网互联以及中间路由变化，都可能造成速度下降。

按这个顺序缩小范围

1. 先排本地无线：靠近路由器，或用有线网络复测。5 GHz Wi-Fi 在信号良好时通常更适合高速传输，但隔墙覆盖未必优于 2.4 GHz。
2. 再换接入网络：保持同一电脑和节点，改连手机热点。注意移动数据费用，并暂停电脑后台更新。
3. 最后比时间段：分别记录白天和晚间的相同测试，不要把不同日期、不同节点的数据直接比较。

假设同一节点在家庭宽带上只有 0.8 MB/s，换手机热点后达到 6 MB/s，这说明接入网络或沿途路径值得优先检查，但还不能据此断言某一家运营商主动限速。热点同时改变了接入方式、出口与路由，需要进一步对照。

可以使用系统的 ping 或路由跟踪工具观察基础网络，但它们的 ICMP 流量未必经过 HTTP 系统代理。节点入口也可能不响应 ICMP。单次超时或中间一跳高延迟，不能独立证明代理链路丢包；应结合终点表现与真实业务传输判断。

第三层：规则命中，确认慢连接走了哪个出口

Clash 规则模式按顺序匹配连接，通常由首条命中的规则决定策略。订阅里有节点，并不表示所有应用都会使用它。目标可能命中 DIRECT，也可能进入一个与手动选择不同的策略组。

从连接记录查实际路径

1. 打开客户端「连接」页，再发起一次目标请求。对长连接，先关闭对应页面或暂停任务后重试。
2. 按域名、目标 IP 或进程筛选，查看命中规则、策略链和最终节点。部分客户端需展开连接详情才能看到完整信息。
3. 检查网页主域名之外的资源域名。页面能打开但图片、视频慢，可能是资源域名走了另一条规则。
4. 若连接页没有记录，先检查应用是否使用系统代理或被 TUN 接管。没有记录也可能与连接结束过快、界面过滤条件有关。

在确认目标确实进入客户端后，可以短暂切到全局模式，并明确选择一个节点，建立新连接对照。如果同一资源明显改善，重点检查原规则、策略组和出口差异。全局模式不会自动接管原本绕过客户端的应用，也不能单凭一次改善断定规则文件损坏。

用显式代理排除系统代理差异

以下 Windows PowerShell 命令假定客户端实际 HTTP 或混合代理端口为 7890。先在客户端设置中核对；如果实际端口为 7897，就修改命令。该请求用于观察阶段耗时，不用于测量最大下载速度。

curl.exe --proxy http://127.0.0.1:7890 --output NUL --silent --show-error --max-time 30 --write-out "connect=%{time_connect}s tls=%{time_appconnect}s first=%{time_starttransfer}s total=%{time_total}s\n" https://example.com/

time_connect 在这里主要反映到本地代理的连接，不能当作到远端网站的延迟。TLS、首字节和总耗时都是从请求开始累计的数值，不能直接相加。命令成功而浏览器慢时，继续检查浏览器扩展、独立代理设置与请求协议差异。

第四层：DNS 解析，区分等待解析与传输瓶颈

DNS 更常影响首次访问、域名分流与目标地址选择，而不是已建立连接的持续下载速度。若文件已稳定传输数分钟，速度仍然偏低，只更换 DNS 通常不能解决带宽问题。

先确认解析由谁处理

检查当前配置的 dns 部分、TUN 的 DNS 劫持设置，以及浏览器是否启用了安全 DNS。系统解析、浏览器 DoH 和内核 DNS 可能走不同路径。系统代理开启并不代表所有系统 DNS 查询都会进入 Clash。

• Fake-IP 模式：通常给域名返回映射地址，再由内核关联原域名处理连接。常见配置使用 198.18.0.0/16，最终应以实际 fake-ip-range 为准。
• Redir-Host 模式：返回真实解析地址。解析结果与后续的域名关联、规则匹配行为还取决于内核和接管方式。
• 自定义上游：检查上游是否可达，以及解析请求是否出现循环依赖。不要只根据公共 DNS 地址的知名度选择。

Windows 可用 Resolve-DnsName example.com 查看系统路径下的结果，但它不能代表浏览器独立 DoH 的结果。在 Fake-IP 生效时看到配置范围内的映射地址，并不是解析故障；也不应把这个地址当作目标服务器拿去评价线路延迟。

如何验证修改有效

1. 备份现有 DNS 配置，只修改一个因素，例如更换一个不可达的上游，不要同时切换模式和整套分流规则。
2. 按客户端支持的方式重新载入配置，必要时重启内核，确认日志没有 DNS 上游连接错误。
3. 在 Windows 执行 ipconfig /flushdns 清理系统缓存，再重新打开浏览器测试。浏览器和内核仍可能保有各自缓存。
4. 比较首次打开和再次打开的差异。如果只是首次等待减少、持续下载不变，就把结论限定在解析或建连阶段。

不要遇到慢就批量扩大 fake-ip-filter。它用于让特定域名不返回 Fake-IP，通常服务于局域网发现、特定应用兼容等需求，不是通用加速列表。修改前应能指出具体不兼容的域名和现象。

第五层：本机设置，检查接管、资源与协议

节点、网络和规则都没有明显异常时，再检查本机。此时重点不是找“加速开关”，而是确认有没有双重代理、资源瓶颈或应用层重试。

TUN 不是带宽加速器

TUN 通过虚拟网络接口接管流量，适合处理不遵循系统代理的应用。它改变的是流量进入内核的方式，不会提高节点套餐的带宽。不同协议栈、路由和 MTU 设置可能影响兼容性，但不存在适合所有设备的固定“最快值”。

若系统代理正常、只有 TUN 下慢，先用同一应用和节点复现，再查路由冲突、DNS 接管、其他虚拟网卡和内核日志。不要一次把 MTU、协议栈、DNS 模式全部改掉；否则即使恢复，也难以知道哪项起作用。

浏览器慢，还要注意 UDP 与 QUIC

HTTP/3 使用 QUIC，通常基于 UDP。若应用尝试的 UDP 路径不通，可能出现等待后回退的现象；节点协议、服务端和接管方式都需要支持相应流量。系统 HTTP 代理下的浏览器行为，也不等同于 TUN 接管后的行为。

可在浏览器开发者工具的网络面板观察协议和请求耗时，或临时关闭浏览器中的 QUIC 相关实验选项做对照，测试后恢复。只有看到 UDP 失败、回退等待等证据时才沿这条线排查，不要把禁用 QUIC 当成所有慢速问题的固定步骤。

复测与记录：把结论缩小到可执行的一项

每轮修改后，用原来的目标和测试时长重跑 3 次。保留有效改动，撤回没有帮助的尝试。一次测试只能支持有限结论：换节点有效，不代表 DNS 必须改；热点有效，也不代表客户端需要重装。

1. 节点差异明确：保留表现稳定的节点，记录异常节点与发生时间，向订阅服务方反馈。
2. 网络或时段差异明确：优先调整接入网络、无线条件或节点入口线路，不反复改本机 DNS。
3. 规则出口不符：调整对应域名的规则或策略组，再检查主请求与资源请求是否都符合预期。
4. 只有首次请求慢：围绕解析、TLS 和远端首字节继续排查，不拿小网页请求推算带宽。
5. 只有某种接管方式慢：保留可正常使用的方式，携带内核版本、复现步骤和脱敏日志进一步定位。

最有价值的结果不是“所有参数都调过”，而是“同一目标在节点 A 慢、节点 B 正常”或“只在 TUN 模式下复现”。这样的记录能把下一步落到具体层级。基础连通性还未确认时，可先按连接检查步骤建立一个稳定的对照环境。