Clash 速度慢怎么排查:节点、线路与本地设置分层定位

先区分延迟高、吞吐低与连接卡顿

Clash 速度慢不是一个单独故障。网页首次打开慢，可能卡在 DNS 解析或连接建立；下载持续只有几百 KB/s，才更接近吞吐瓶颈；视频开始流畅、几分钟后缓冲，则要检查线路波动、出口拥塞以及应用实际使用的连接。先记录症状，再调整配置，能避免把一个问题变成多个变量。

Clash 是代理内核，mihomo 是沿 Clash Meta 路线发展的兼容内核。桌面或移动客户端还负责界面、系统代理与配置管理。同名设置在不同客户端的位置可能不同，因此排查时应同时记录客户端名称、客户端版本和内核版本，不要只写“装了最新版”。

建立基线：固定目标、时间与连接方式

测速按钮通常只测试一个指定网址的响应时间，不代表所有网站的可用性，更不是带宽测试。自动选择策略组可能在测试期间换节点。排查时先切换到可手动选择的策略组并固定节点，暂停后台下载与云盘同步，再进行对照。

1. 记录原始状态。保存配置备份，记下规则模式、系统代理、TUN 开关及当前出口节点。确认只运行一个代理客户端。
2. 测试本地网络。在可直连的可信下载站点测试一次。如果直连也慢，先比较有线网络、靠近路由器的 Wi-Fi 和手机热点。
3. 固定代理测试目标。选用允许测速、文件足够大的 HTTPS 下载资源。每次测试约 30 秒，忽略最初 5 秒的波动，连续做 3 次。
4. 记录应用实际路径。在客户端“连接”页面查找目标域名，确认请求进入了预期策略组，而不是只看主界面上的节点名称。
5. 每轮只改一个变量。换节点时不同时改 DNS；测试 TUN 时不同时切到手机热点。每轮结束后关闭旧下载并重新发起连接。

下面是一份记录格式示例，不是本站实测结果。实际填写时用自己的数据，并保持测试文件、设备和时段一致。不要用一次峰值代替整个测试过程。

第一层：节点质量与策略组选择

延迟最低的节点，不一定下载最快

延迟测试反映的是小请求的往返体验。节点可能响应很快，但出口带宽紧张、并发限制较严，或者到目标站点的路径不佳。相反，地理距离较远的节点即使延迟稍高，也可能有更稳定的持续吞吐。网页交互与大文件下载应分别测试，不能只按延迟排序得出结论。

• 选择同一订阅中的 2～3 个节点，优先比较不同入口或不同线路，而不是只比较名称相近的节点。
• 检查订阅服务的流量余额、速率限制和到期状态。更新订阅可刷新节点信息，但不会自动增加服务端带宽。
• 核对策略组嵌套关系。规则指向 Proxy 时，Proxy 可能继续指向另一个自动组；应展开到最终节点确认。
• 切换节点后关闭旧下载任务再重试。已经建立的连接可能继续沿用原出口，不能把旧连接当成新节点的结果。

避免自动切换干扰对照

url-test 主要依据指定 URL 的延迟选路；fallback 更侧重按顺序选择可用项；load-balance 可能将不同连接分配到不同节点。三者都不能直接证明某个节点的持续下载能力。若正在使用这类组，先通过已有的手动选择组固定出口，再测同一资源。

如果只有某个节点慢，而其他节点在相同条件下正常，问题范围已经缩小。此时反复重装客户端、清理全部配置的收益很低，应进一步确认该节点的入口与出口线路，或向订阅服务提供具体测试记录。

第二层：接入线路、出口路径与高峰拥塞

一次代理访问至少涉及本机到节点入口、节点转发，以及出口到目标站点几段路径。节点名称中的地区通常不足以说明入口运营商或中转方式。两个不同名称的节点也可能共用入口；只换名称而不换路径，未必能绕开拥塞。

用三个对照缩小范围

1. 同节点换网络。在家庭宽带与手机热点之间对比。热点明显改善时，说明接入网络或其到节点的路径更可疑，但还不能直接认定是运营商限速。
2. 同网络换时段。例如分别在 10:00 与 21:00 做三轮测试。若多个晚上都出现相似下降，才更支持高峰拥塞判断。
3. 同出口换目标。对比两个不同服务的合法下载资源。如果只有一个站点慢，应考虑该站点的 CDN 分配、单连接限制或对代理出口的策略。

测速站常使用多连接，而浏览器文件下载可能只使用一个或少量连接，所以两者数字不一致并不罕见。测速结果高、单文件慢时，应继续比较单连接表现，而不是直接判定客户端“丢速度”。视频网站还会根据缓冲和码率控制下载节奏，不适合当作唯一带宽基准。

第三层：系统代理、规则与本地监听端口

先确认应用有没有经过客户端

系统代理不是全设备流量接管。部分应用不读取系统代理，命令行工具也可能只使用自己的参数或环境变量。TUN 模式通过虚拟网络接口接管符合路由条件的流量，但仍受平台实现、路由和排除项影响。浏览器正常而游戏或命令行慢，首先检查接入方式，不要立即归因于节点。

以 Windows 11 为例，可在「设置」→「网络和 Internet」→「代理」核对手动代理地址与端口。以 macOS 13 及之后的系统界面为例，可在「系统设置」→「网络」→当前网络服务→「详细信息」→「代理」核对。客户端启用系统代理后通常会自动填写这些内容；手工修改前应记录原值。

下面是监听设置片段，非完整配置。7890 只是示例值，测试时应读取客户端实际生效的端口；有些客户端由界面生成配置，直接编辑订阅文件可能在下次更新后被覆盖。

mixed-port: 7890
allow-lan: false
log-level: info

mixed-port 可在同一个端口接收 HTTP 与 SOCKS 代理请求。若应用仍指向旧端口，可能出现连接失败，或在失败后退回直连。allow-lan: false 用于限制局域网访问，修改它不会提升本机网速。

规则模式下检查实际命中

在客户端“连接”页面查看域名、目标 IP、命中规则及出站链路。国内下载站若被送入代理，速度可能反而下降；应代理的目标若命中 DIRECT，也可能表现为长时间等待。规则一般按顺序匹配，前面的宽泛规则会遮住后面的细分规则。订阅中的策略组名必须与规则引用一致。

可短时使用全局模式做对照，但它只是诊断工具。全局正常、规则模式慢，更应检查规则和策略组，而不是长期用全局模式掩盖问题。关于字段含义，可查阅代理模式说明与端口说明。

DNS、TUN 与设备负载的专项检查

DNS 优先解释“打开慢”，不是所有低速

DNS 解析发生在连接建立前，缓存和连接复用会让第二次访问变快。若页面要等数秒才开始加载，但开始下载后速度正常，应按时间线观察解析与建连。相反，一个已建立的长连接持续低速，单纯更换 DNS 通常不能解决。

• 检查系统、浏览器安全 DNS、客户端 DNS 是否存在独立配置。浏览器内置的加密 DNS 可能不经过客户端预期的解析流程。
• 使用 fake-ip 时，系统查询到映射地址不等于解析失败。例如 198.18.0.0/16 范围可被用作 fake-ip 地址池，需结合实际配置判断。
• 若怀疑 IPv6 路径异常，临时做 IPv4 与 IPv6 对照，并记录恢复方法。不要仅凭一个站点慢就永久关闭整个系统的 IPv6。

TUN 开关要做单变量对照

先在系统代理方式下测试明确支持 HTTP 代理的浏览器，再保持节点和目标不变测试 TUN。仅 TUN 模式变慢时，检查其他 VPN、虚拟机网络、路由冲突与客户端日志。切换接管方式后要确认目标仍走同一个出口，否则两轮结果不可直接比较。

MTU 不匹配可能表现为小请求正常、大响应卡住，但不能仅凭这一现象定案。不要照抄某个“通用最佳 MTU”。确需验证时，记录原值，在支持相应配置的客户端中一次调整一项，重新建立连接并复测；无改善就恢复。TUN 的 stack 支持和行为也随平台、内核版本变化，不宜把某一种栈写成必然更快的选项。

CPU 满载与日志写入也会影响吞吐

在 Windows「任务管理器」→「性能」→「CPU」中可将图表切换为逻辑处理器；在 macOS「活动监视器」→「CPU」中查看客户端与内核进程。总占用不高时，某个核心仍可能已接近满载。旧设备、复杂规则及并发连接都可能增加处理负担。

日常诊断先使用 info 日志级别，需要细节时短时切到 debug，重现一次问题后恢复。持续大量写入调试日志会增加开销，还可能记录敏感访问信息。提交材料前应遮蔽订阅链接、令牌、节点密码与个人域名。

按结果收尾：保留证据，恢复临时设置

排查结束时应能形成一个可复现的结论，例如“同一文件、同一网络，节点 A 连续三次约 1 MB/s，节点 B 约 7 MB/s”，而不是只留下“晚上很卡”。数值是示例，重要的是条件完整、结果能重复。向服务提供方反馈时，附上带时区的发生时间、接入运营商、节点标识、客户端和内核版本即可，勿发送完整订阅。

最后恢复临时使用的全局模式、调试日志和网络参数，确认订阅更新后设置仍按预期生效。测速会消耗实际流量，移动热点和按量服务应控制测试时长。如果问题仍不能定位，可按连接故障说明继续检查，或回到使用指南核对基础配置流程。