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

一、先区分打开慢、下载慢与连接中断

Clash 显示节点延迟正常，但视频仍然缓冲，并不矛盾。节点卡片上的延迟通常来自一次测试请求，只反映当时访问测试地址的响应情况；持续下载速度还受节点负载、跨网链路、目标站点限速和本地无线网络影响。排查前先把“慢”变成可以重复观察的现象。

建立一次可重复的基线

1. 暂停云盘同步、游戏下载和系统更新，保持设备、位置与目标文件一致。
2. 在客户端的“代理”页面展开当前策略组，暂时手动选定一个节点，避免自动选择组在测试途中切换出口。
3. 对同一个目标连续测试 3 次，每次记录开始时间、首屏等待和稳定下载速度；大文件可观察约 30 秒，注意流量消耗。
4. 每轮只改一个变量，按“节点 → 接入网络 → 本地设置”的顺序比较。

二、节点层：延迟低不代表带宽充足

先打开客户端的“代理”页面，找到当前规则使用的策略组，再选择具体节点。Clash Verge Rev 等图形客户端常见入口为侧栏“代理”“连接”“日志”；其他客户端名称可能不同，应以当前界面为准。不要只看节点卡片，还要到“连接”页面确认测试请求实际经过了刚选的节点。

用三个对照判断节点问题

• 同地区换节点：保持目标不变，比较两个同地区节点。如果只有其中一个长期偏慢，更可能与该节点的负载、限速或出口有关。
• 跨地区换出口：一个地区普遍慢，另一个地区恢复，说明路径或目标站点到该出口的连接值得进一步检查，不等于本地客户端配置损坏。
• 换目标文件：同一节点访问其他站点正常，只有一个下载源慢，应检查该站点的账户限速、CDN 分配或单连接限制。

不要连续点击全量测速后立刻比较下载。批量测试会短时增加请求，部分客户端的“延迟测试”与“下载测速”也不是同一项功能。先停止测试，再进行单节点对照；若订阅有流量上限，大规模吞吐测试本身也会消耗额度。

检查订阅更新是否改变了选择

进入“订阅”或“配置”页面，确认当前启用的 Profile，查看最后更新时间与更新结果。订阅更新后节点名称或组成员可能变化，原来的手动选择不一定仍然有效。回到“代理”页重新确认，再到“连接”页验证实际链路。不要为了测速把带有账户令牌的订阅地址粘贴到公开网站。

三、线路层：用换网络和分时段定位拥堵

节点名称中的地区通常描述出口位置，并不能完整表示入口、跨网或中转路径。同一出口在不同运营商网络下可能表现不同。若节点切换的效果不稳定，下一步应比较接入网络，而不是立刻重写 DNS。

1. 先排除无线链路：保持节点不变，电脑靠近路由器，条件允许时改用网线。观察同一目标是否恢复，避免把弱信号或无线干扰误认为代理线路拥堵。
2. 再比较手机热点：让同一台电脑改连热点，保持节点和目标不变。若热点明显更快，问题更偏向原宽带路径、路由器或原接入网络；热点测试会使用移动流量。
3. 记录高峰差异：例如分别在 10:00、20:30、23:30 运行同一组测试。只有晚间普遍下降，更符合共享链路负载上升的特征，但仅凭时间变化不能断定具体拥堵位置。

普通 ping 通常发送 ICMP，不会因为开启系统 HTTP 代理就自动经过代理节点，因此不能用它的结果直接代表代理下载速度。路由追踪也可能遇到中间设备不响应，单跳超时并不能独立证明该跳丢包。更有价值的是同一设备、同一目标在不同网络下的应用层对照。

四、DNS 层：先确认解析路径，再改配置

DNS 异常常表现为首次打开很慢、部分域名失败，或解析到不合适的 CDN 地址；它通常不能解释连接建立后持续稳定的低吞吐。若下载已经持续进行但速率偏低，应优先完成节点与线路对照。

检查三处可能分开的解析入口

• 系统 DNS：影响未被客户端接管的解析。Windows 可在终端执行 ipconfig /all 查看当前网卡的 DNS 服务器。
• 内核 DNS：打开当前配置的 DNS 段，检查 dns.enable、enhanced-mode 和上游地址。使用 mihomo 的客户端还可能通过覆写生成最终配置，应检查运行中的配置，而不只是订阅原文件。
• 浏览器安全 DNS：浏览器可能独立使用加密 DNS。Chrome 的常见入口为“设置”→“隐私和安全”→“安全”→“使用安全 DNS”；测试时记录原值，临时关闭作对照，完成后按需要恢复。

如果启用了 fake-ip，应用看到合成地址属于该模式的正常工作方式，不应仅凭地址不是公网 IP 就认定解析错误。反过来，浏览器使用独立解析、应用缓存旧地址或域名被排除在接管范围外，都可能使规则匹配与预期不同。

修改前先备份配置，每次只调整一处。订阅管理客户端应优先使用其支持的覆写功能，避免下一次更新覆盖修改。DNS 上游的访问路径也需要可用；随意换成一个必须经过当前代理才能到达的地址，可能让排查更加复杂。具体字段应以所用内核文档为准，不要把 mihomo 的配置直接套到所有旧 Clash 内核。

清理缓存后再比较

Windows 修改 DNS 后，可在命令提示符执行下面的命令，再完全退出并重新打开测试应用。它只清理系统解析缓存，不会清空浏览器全部缓存，也不会提高线路带宽。

ipconfig /flushdns

五、规则层：核对实际出口与连接模式

打开客户端“连接”页面，重新访问目标网站，按域名筛选新连接，检查命中的规则、策略组与最终节点。基于 Clash 规则的路由通常按从上到下顺序匹配；一条过宽的前置规则，可能让原本应该直连的服务绕到远端，也可能让需要代理的服务走直连。

1. 确认当前模式为 Rule，记录目标连接的规则与出口。
2. 临时切到 Global，并在全局策略组选择同一个待测节点，再访问相同目标。
3. 若全局正常而规则模式异常，重点检查分流规则和组选择；若两种模式都慢，回到节点、路径与目标站点层。
4. 测试后恢复 Rule，防止本地服务或国内业务长期绕行。

下面是规则顺序的最小示意，只用于说明“具体域名规则在前，兜底在后”。其中 PROXY 必须是实际配置中存在的策略组；不要用这段内容替换整份订阅。

rules:
  - DOMAIN-SUFFIX,example.com,PROXY
  - MATCH,DIRECT

切换节点或规则后，旧的长连接可能继续使用原出口。可以暂停下载后重新开始，或在“连接”页面只关闭目标连接，再观察新连接。关闭所有连接会中断会议、传输等任务，不宜作为每一步的默认操作。

六、本地接管层：系统代理、TUN 与应用协议

系统代理主要供遵循系统代理设置的应用使用，并不自动覆盖所有程序。TUN 通过虚拟网络接口接管流量，具体范围受路由、权限、排除项和内核实现影响。TUN 不是带宽加速开关：如果浏览器已经正确经过系统代理，单纯打开 TUN 通常不能解决节点拥堵。

用显式代理测试隔离接管问题

先在客户端“设置”中查找端口设置或运行配置里的 mixed-port。以下命令假定混合端口为 7890，实际是 7897 或其他值时必须替换。Windows 使用 curl.exe，macOS、Linux 使用 curl；示例只访问公开测试域名，不测试大文件带宽。

curl --proxy http://127.0.0.1:7890 -o /dev/null -sS -w "connect=%{time_connect}s tls=%{time_appconnect}s first_byte=%{time_starttransfer}s total=%{time_total}s\n" https://example.com/

在 Windows 上将上面命令中的 curl 改为 curl.exe，并把 /dev/null 改为 NUL。这些时间是从请求开始累计的时间点；使用本地代理时，time_connect 主要反映连接本地代理的耗时，不能当作节点往返延迟。first_byte 还包括目标服务端处理时间。

• 显式代理正常，应用慢：检查应用是否使用系统代理、是否有自己的代理地址，以及新请求是否出现在“连接”页面。
• 仅 TUN 下异常：检查服务模式或管理员权限、路由冲突和 DNS 接管状态；先恢复客户端默认相关设置，再做单项对照。
• 仅视频或实时应用异常：部分应用使用 QUIC 或其他 UDP 协议。HTTP 代理测试正常，不代表 UDP 路径正常，还需确认节点与客户端支持并允许对应流量。

不要一开始就随机修改 MTU、关闭 IPv6 或替换整套 DNS。只有出现特定网络下大包卡住、某类地址持续失败等可重复证据时，才值得针对该项继续检查。若怀疑设备性能，观察任务管理器或活动监视器：下载时内核进程是否持续占满一个逻辑核心，路由器是否同时承担大量连接。

七、保留排查记录，按证据决定下一步

一轮排查结束后，保留能复现问题的最小组合，而不是保存几十次无条件说明的测速截图。下面几项足以帮助判断问题边界，也方便向订阅服务方或客户端维护者描述现象。

• 环境：操作系统、客户端名称、客户端与内核版本，从“关于”或启动日志中复制真实值。
• 路径：宽带或热点、测试时间、节点代号、目标域名；避免公开账户信息。
• 设置：Rule 或 Global、系统代理或 TUN、目标命中规则与最终出口。
• 结果：每组 3 次测试的等待时间与稳定速率，以及换节点、换网络后是否改善。

需要提交日志时，仅临时提高日志等级并复现一次，随后恢复常用等级。分享前遮盖订阅令牌、节点密码、个人 IP 和访问记录。更多基础操作可参考Clash 配置手册中的代理模式、规则分流与 TUN 章节；如果尚未完成首次连接，应先按使用文档确认配置已启用，再进行速度比较。