Clash 网速慢怎么排查:节点质量、线路路由与本机设置三层定位法

先固定测试条件：延迟、首包与下载速度分开记录

Clash 面板显示的延迟不是带宽。一次 URL 延迟测试反映的是经该节点访问指定测试地址的响应耗时，具体计时边界取决于客户端与内核实现。它不能证明大文件下载速度，也不能代表所有网站的访问体验。出现“节点只有 80 ms，但视频一直缓冲”时，需要分别观察连接建立、首字节和持续传输，而不是只按延迟排序。

本文适用于使用 Clash 或 mihomo 内核的客户端。Clash Meta 是 mihomo 的历史名称；不同内核版本支持的协议、DNS 字段及 TUN 选项不完全相同。开始前记录客户端版本和内核版本，备份当前配置。排查期间保持订阅、测试地址和客户端版本不变，不要同时升级内核、换 DNS、换节点。

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

• 固定环境：同一台设备、同一网络、同一下载地址。暂停云盘同步、系统更新与其他大流量任务。
• 固定策略：在实际命中的代理组中选定一个节点，避免自动测速组或负载均衡组在测试期间切换。
• 固定次数：每种条件连续测试 3 次，记录中位数；持续下载至少观察 30 秒。测试可能消耗较多流量。
• 固定指标：记录测试时间、目标域名、规则、代理链、延迟、下载速率及是否中途停顿。

表内数值仅演示记录与判读方法，不是本站实测结果。注意单位：8 MB/s 约等于 64 Mbps，实际还存在协议开销。宽带标称 100 Mbps，并不意味着下载器能显示 100 MB/s。

第一层：节点质量，区分单节点问题与目标站点限速

先选同一订阅中的 2～3 个节点，对同一个目标进行测试。节点名称里的地区不一定代表入口位置，也不保证出口路径与名称一致。选择备用节点时，应优先比较不同入口或线路，而不是只比较名称不同、实际共用入口的节点。

延迟测试超时，不等于节点完全不可用

测试地址不可达、目标拒绝访问、TLS 握手失败，都可能产生超时。先检查测试 URL，再用浏览器访问实际业务站点。反过来，测速地址能快速响应，也只证明这条特定请求成功，不能证明视频分片、下载域名和登录接口都正常。

1. 在客户端“代理”页面手动选择节点，随后在“连接”页面确认新请求确实经过该节点。页面名称以当前客户端版本为准。
2. 使用同一个 HTTPS 文件地址测试 3 次，再换第二个独立站点。单个站点慢而其他站点正常，优先考虑站点限速、CDN 或出口互联。
3. 分别记录晚高峰和非高峰结果。如果相同节点只在晚间持续降速，节点容量或共享链路拥塞比本地配置更值得检查。
4. 切换节点后重新建立测试连接。已有 HTTP/2、HTTP/3 或下载连接可能仍保留原路径；必要时只关闭对应测试连接。

用显式代理请求隔离浏览器因素

下面的 Windows PowerShell 命令通过本地 HTTP 代理访问示例站点，观察首字节与总耗时。7890 是示例端口，执行前必须替换成客户端实际显示的 HTTP 或 mixed 监听端口；它不是所有客户端的默认值。该小页面请求只用于检查连接过程，不能用于评估峰值带宽。

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

这里的 time_connect 主要反映到本地代理的连接，不能当作远端节点延迟。通过 HTTP 代理访问 HTTPS 时，后续计时还包含代理隧道及目标 TLS 握手等阶段。macOS 与 Linux 可使用 curl，并将 NUL 改为 /dev/null。若命令正常而浏览器卡顿，应继续检查浏览器扩展、缓存和安全 DNS，而不是立即更换订阅。

第二层：线路路由，先确认规则，再比较网络入口

“已经选了节点”不代表所有应用都会走它。在规则模式下，连接先按规则匹配，再进入对应策略或代理组。选择总开关里的一个节点，如果目标请求实际命中另一个分组，测速结果就没有可比性。尤其要留意下载域名、视频分片域名与页面主域名可能分别命中不同规则。

在连接记录中核对三个字段

• 目标：检查域名、目标 IP 和应用进程是否对应当前测试任务，不要误看后台更新请求。
• 规则：查看命中的规则类型与内容，例如 DOMAIN-SUFFIX、GEOIP 或最终的 MATCH。
• 代理链：确认最终为预期节点，而非 DIRECT、其他策略组，或自动组刚选出的另一节点。

可以短时切到全局模式，并在全局组手动选定同一节点做对照。若全局模式明显恢复、规则模式持续变慢，优先检查分组选择和规则顺序。全局模式只改变已进入内核的流量决策，不会自动接管未使用系统代理的程序；它不能替代 TUN。测试后恢复规则模式，避免改变日常访问路径。

家庭宽带与手机热点做交叉测试

保持节点与测试目标不变，将电脑从家庭宽带切换到手机热点。如果热点稳定、家庭宽带慢，问题更接近本地无线链路、路由器、接入网络或运营商到节点入口的路径。再用网线替代 Wi-Fi：网线恢复而无线仍慢，优先处理无线干扰与信号，不必继续修改代理规则。

Windows 可先运行 ipconfig 找到当前默认网关，再执行 ping -n 30 192.168.1.1；这里的地址仅作示例，必须改为实际网关。若本地网关已经出现明显丢包或几十毫秒的反复抖动，应先停止代理层面的调整。不过，部分路由器会降低 ICMP 响应优先级，不能仅凭一次 ping 结果认定链路故障。

第三层：本机设置，核对系统代理、TUN 与端口

系统代理依赖应用主动使用操作系统的代理设置。部分命令行工具、游戏和自带网络栈的程序不会遵循该设置。TUN 通过虚拟网卡与路由接管匹配的 IP 流量，但仍受到路由排除项、权限和其他 VPN 的影响。两者可以在受支持的客户端中同时启用；发生异常时，应逐项关闭做隔离，而不是把它们视为必然冲突。

按单变量顺序测试接管方式

1. 先测试显式代理：用前面的 curl 命令直接连接本地代理端口，排除系统代理开关是否生效的干扰。
2. 再测试系统代理：暂时关闭 TUN，开启系统代理，用遵循系统代理的浏览器访问同一目标。Windows 11 可到“设置”→“网络和 Internet”→“代理”核对手动代理地址与端口。
3. 最后测试 TUN：暂时关闭系统代理，按客户端要求安装服务或授予权限后开启 TUN。确认测试连接出现在内核连接列表中，再比较速度。
4. 隔离其他接管程序：逐个退出其他 VPN、代理客户端与网络加速工具。企业设备涉及安全策略时，先联系管理员，不要直接卸载驱动或停用防护。

端口冲突与资源占用

如果客户端日志提示监听失败，先确认端口是否被占用。在 Windows 执行 netstat -ano | findstr :7890，检查是否有本地地址端口恰为 7890 的 LISTENING 项，再根据 PID 在任务管理器中辨认进程。不要只看到匹配行就结束进程；那也可能是其他连接或相似端口。修改客户端监听端口后，系统代理和显式代理命令也要同步更新。

下载时同时观察任务管理器中的 CPU、内存与网络。若某个逻辑处理器持续接近 100%，吞吐可能受本机处理能力限制；整个 CPU 的平均占用不高也不能完全排除单线程瓶颈。日志级别长期设为 debug 会增加记录量，排查后可恢复日常级别。比较内核版本或 TUN 网络栈前，先保留原配置和回退路径。

DNS 与协议细节：首开慢、视频慢和间歇停顿分别处理

DNS 问题常表现为首次打开等待很久，但建立连接后下载正常；纯粹的持续低吞吐则未必与 DNS 有关。先看连接日志是否反复出现解析超时，区分域名解析、连接远端与 TLS 握手阶段。把 DNS 地址换成另一个公共服务器，并不能保证请求走代理，也不能保证线路更快。

Fake-IP 与 nameserver-policy 的检查范围

在 mihomo 中，dns.enhanced-mode: fake-ip 用虚拟地址映射帮助内核恢复域名，它不是带宽加速选项。nameserver-policy 用于给匹配域名指定解析器；它决定解析策略，不等同于业务流量的代理规则。若使用域名形式的 DNS 上游，还需考虑上游自身的地址解析与可达性，避免形成依赖循环。

• 浏览器启用安全 DNS 时，请求可能与系统 DNS 走不同路径。可以暂时关闭浏览器安全 DNS做一次对照，记录结果后恢复原设置。
• TUN 中的 DNS 劫持配置只接管其规则覆盖的 DNS 流量。常见的 53 端口劫持不代表能直接改写所有应用内的 DoH 请求。
• 修改 DNS 后要重新建立测试连接。Windows 的 ipconfig /flushdns 只清理系统解析缓存，不等于清空浏览器、应用和内核的全部缓存。
• IPv6 的 DNS 记录、系统路由和代理支持应配套检查。只在配置中改一个开关，不能证明应用的 IPv6 流量已被接管。

UDP、QUIC 与 MTU 放到后面排查

浏览器可能使用基于 UDP 的 HTTP/3。若当前节点、协议或接管路径的 UDP 支持不完整，会出现部分站点反复回退或加载异常。应先通过客户端日志和浏览器网络信息确认，再对该浏览器或该目标做临时 TCP 对照，不要为了一个站点全局阻断 UDP。

若小页面正常，但大文件、特定 HTTPS 请求或 TUN 模式下频繁停顿，且节点与规则已排除，可以进一步怀疑路径 MTU 或隧道封装问题。此时才考虑在原值基础上，将 TUN MTU 临时调整为 1400 做一次对照；该数值是诊断候选值，不是通用最佳配置。无改善就恢复，不要把随机降低 MTU 当作常规提速步骤。字段支持与生效方式请以当前内核文档为准，可结合协议手册核对。

收敛结果：按现象决定下一步，而不是持续叠加配置

每次只修改一个条件，测试后写下“改变了什么、结果是多少、是否恢复”。完成定位后，撤销临时全局模式、测试 DNS 和实验性 MTU，保留能解释问题的最小修改。需要反馈时，提供客户端与内核版本、系统版本、接管模式、测试时段和脱敏后的错误日志；不要公开订阅地址、节点密码或控制接口密钥。

如果旧客户端已不适合当前系统，先通过客户端对比确认平台与内核，再按使用指南重新建立最小可用配置。换客户端可以解决部分兼容问题，但不能替代节点、线路与本机三层的交叉验证。