Clash 速度慢分层排查:先分清是节点、线路还是本地设置

先建立基准：延迟、带宽和稳定性不是同一个指标

Clash 面板里的延迟通常只是一次 HTTP 连通测试耗时。它能回答节点是否可达、建立连接大约需要多久，却不能直接代表下载速度。一个延迟 85 ms 的节点可能只能跑到 8 Mbps；另一个延迟 160 ms 的节点可能稳定达到 90 Mbps。前者响应快但出口拥堵，后者距离较远但带宽充足。

正式排查前先固定测试条件。不要一边切节点、一边改 DNS、一边开启 TUN。变量同时变化后，即使速度恢复，也无法确认是哪项设置起作用。建议先保留当前配置，并记录测试时间、节点名称、代理模式、下载速度和延迟。

四组基准数据

1. 直连基准：关闭 Clash 的系统代理和 TUN，访问运营商测速页面。若直连只有 20 Mbps，代理不可能稳定跑满 100 Mbps。
2. 国内下载基准：下载一个至少 200 MB 的国内镜像文件，观察 30 秒后的稳定速度，排除 Wi-Fi 和本地宽带问题。
3. 节点延迟：对同一地区的 3 至 5 个节点分别测试三次，不采用第一次结果，记录后两次的范围。
4. 代理吞吐：选择单个节点下载同一个测试文件，每次至少持续 60 秒，避免把刚开始的突发速度当成稳定速度。

换算时注意单位。测速页面常用 Mbps，下载器常用 MB/s，二者相差约 8 倍。80 Mbps 对应的理论下载速度约为 10 MB/s，考虑协议、TCP 和加密开销后，实际看到 8 至 9.5 MB/s通常正常。

第一层：判断是不是节点本身变慢

节点层问题发生在代理服务器本身或节点提供方的出口。典型表现是同一订阅中只有少数节点慢，切换到同地区其他节点后立刻恢复；或者该节点全天速度都低，而其他节点不受影响。

不要只按延迟排序

自动选择策略组通常根据测试 URL 的响应时间挑选节点。该方法适合判断可用性，但无法测出节点的持续传输能力。测试 URL 返回的内容很小，节点即使只剩少量带宽，也可能得到漂亮的延迟数字。

以三次测试为例：节点 A 延迟为 72、81、76 ms，下载稳定在 2.1 MB/s；节点 B 延迟为 145、151、148 ms，下载稳定在 11.4 MB/s。网页浏览重视首包响应时，A 可能体感更快；下载大文件或观看高码率视频时，B 更合适。

识别节点过载

• 上午速度正常，晚间固定时段下降到白天的三分之一以下。
• 延迟从约 100 ms 周期性跳到 500 ms 以上，并伴随连接重置。
• 同一地区的多个节点中，只有一个节点持续低速。
• 短连接网页还能打开，持续下载数十秒后速度不断下降。
• 切换到另一协议或另一入口后恢复，但本地设置完全未变。

节点名称中的“倍率”通常用于计算订阅流量消耗，不代表速度等级。标记 0.5 倍的节点不一定慢，2 倍节点也不等于速度翻倍。选节点时应分别看延迟、稳定吞吐、丢包表现和流量成本。

节点层的处理办法

1. 先在同一地区内切换节点，保持代理模式和测试文件不变。
2. 关闭自动选择，临时固定到单个节点，避免测试过程中策略组自行切换。
3. 更新一次订阅，确认节点地址、端口和协议参数没有被服务方调整。
4. 若只有一个节点异常，将测试时间和稳定速度记录下来，再反馈给节点提供方。

第二层：判断是不是跨境线路和运营商路径拥堵

线路层位于本地宽带与代理节点之间。节点服务器本身可能有充足带宽，但从当前运营商到该入口的路径绕行、丢包或晚高峰拥堵，实际速度仍会下降。此时切换同机房的多个节点，结果往往都差不多。

线路问题的三个明显特征

• 与时间相关：工作日上午能达到 70 Mbps，20:00 至 23:00 只能达到 10 Mbps。
• 与运营商相关：同一个节点在家庭宽带慢，切到手机热点后明显恢复。
• 与地区相关：某一地区整组节点都慢，换到另一地区后吞吐恢复。

普通 ping 使用 ICMP 数据包，部分服务器会降低其优先级或直接不响应。因此“ping 丢包 100%”不一定等于代理不可用，“ping 只有 40 ms”也不保证 TCP 或 UDP 传输顺畅。Clash 的 HTTP 延迟测试更接近实际代理连接，但仍只是小流量探测。

用对照法定位运营商路径

1. 固定一个节点和一个 200 MB 以上的下载地址，用家庭宽带测试 60 秒。
2. 保持节点不变，切换到 4G 或 5G 手机热点，再测试 60 秒。
3. 分别在上午、晚高峰重复，记录稳定速度而不是峰值。
4. 如果热点达到 8 MB/s，而家庭宽带只有 900 KB/s，本地 Clash 配置通常不是首要嫌疑。

如果同地区节点普遍拥堵，优先换地区，而不是继续在同一组里逐个试。物理距离较近通常意味着较低延迟，但线路质量比直线距离更重要。实际选择应以当前运营商的测试结果为准。

第三层：检查 Clash 客户端与本地网络设置

当所有节点同时变慢，而且更换网络后差异不大，应检查本地层。常见位置包括系统代理端口、代理模式、TUN、DNS、浏览器代理扩展、安全软件和虚拟网卡。排查原则仍是一次只改一项。

先核对代理模式和端口

以 Clash Verge Rev 2.3.x 搭配 mihomo 1.19.x 的界面为例，可在「设置」→「Clash 设置」中查看混合端口。常见值是 7890，但配置文件也可能使用 7897、7899 或其他端口。系统代理指向的端口必须与当前内核监听端口一致。

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

端口不一致通常表现为完全无法访问，但在浏览器扩展、系统代理和应用内代理同时存在时，也可能出现请求绕路、重复代理或部分程序速度异常。测试阶段只保留一种入口：要么开启客户端的系统代理，要么让目标应用明确使用 HTTP/SOCKS 端口。

确认规则没有把测速请求送错策略组

Rule 模式会从上到下匹配规则，首次命中后停止。测速网站首页、下载域名和统计域名可能命中不同策略。如果下载域名被送到 DIRECT，而页面本身经过代理，测速结果就不能代表节点速度。

打开客户端的连接记录，找到正在传输的域名，检查对应的规则和策略组。日志中应能看到请求命中了哪个规则，以及最终使用哪个节点。若要做纯节点测试，可临时切到 Global 模式并固定单个节点；测试结束后再切回 Rule，避免日常流量全部走代理。

TUN 模式慢时怎么拆分

TUN 会接管更多系统流量，适合不读取系统代理的程序和部分游戏。它也增加了虚拟网卡、路由和 DNS 处理环节。若系统代理模式正常、开启 TUN 后明显变慢，按以下顺序测试：

1. 关闭 TUN，保留系统代理，重复同一下载测试。
2. 重新开启 TUN，确认没有同时运行其他 VPN、加速器或旧版虚拟网卡。
3. 在客户端的 TUN 设置中切换可用堆栈，例如 system 与 mixed，每次切换后重启内核。
4. 检查 MTU。默认值出现部分网站卡顿时，可依次测试 1500、1400、1280，并记录变化。
5. 若只有 UDP 应用异常，单独检查节点协议是否支持稳定的 UDP 转发。

MTU 不应凭感觉长期设得很低。值过大可能导致分片或特定连接停顿，值过小则增加包头开销。只有在“网页能开但大文件停住”“部分图片长期加载不完”这类症状下，才值得做分档测试。

DNS 慢不等于节点带宽慢

DNS 异常主要拖慢首次打开和域名解析。页面开始下载后仍能跑满带宽，通常说明节点吞吐正常。若每个新网站都要等待 3 至 5 秒，但进入后加载很快，应优先检查 DNS，而不是更换节点。

dns:
  enable: true
  ipv6: false
  enhanced-mode: fake-ip
  nameserver:
    - 223.5.5.5
    - 1.1.1.1

这段配置只是排查示例，不应直接覆盖现有订阅。使用 fake-ip 时，局域网设备、企业内网和少数依赖真实地址的应用可能需要加入过滤规则。DNS 上游也要结合当前网络选择，境内解析与代理侧解析承担的任务不同。

排除浏览器和后台程序干扰

• 关闭浏览器中的代理扩展，避免扩展端口与系统代理叠加。
• 暂停云盘同步、系统更新和游戏更新，查看任务管理器中的实时网络占用。
• 暂时关闭 HTTP/3 后重复测试，用于判断 UDP 路径是否异常；验证后恢复原设置。
• 使用有线连接或 5 GHz、6 GHz Wi-Fi，避免在拥挤的 2.4 GHz 频段测速。
• 将日志级别保持在 info。长期使用 debug 会产生大量日志，不适合作为日常配置。

按症状执行固定排查流程

实际处理时不需要把所有设置都改一遍。先根据症状选择最短路径，再用对照测试确认结果。

场景一：延迟低，但下载只有几百 KB/s

1. 固定当前节点，不看延迟数字，测试持续下载 60 秒。
2. 切换同地区另一个节点。如果速度恢复，原节点过载的概率较高。
3. 同地区仍慢时换到另一个地区，判断是否为线路拥堵。
4. 所有地区都慢时关闭 TUN、浏览器扩展和后台下载，再测本地层。

场景二：白天快，晚上固定变慢

先保留一组白天与晚间数据。例如白天 11:00 为 78 Mbps，晚间 21:30 为 14 Mbps，手机热点同一节点仍有 55 Mbps。这组结果更指向家庭宽带的晚高峰路径，而不是 Clash 客户端故障。处理方向是换地区入口、换线路类型或避开拥堵时段。

场景三：浏览器快，游戏或下载器慢

先确认该程序是否读取系统代理。许多游戏和部分下载器不会使用 HTTP 系统代理，需要 TUN 或应用内 SOCKS5 设置。若程序允许手动代理，可填写 127.0.0.1 和当前 SOCKS/mixed 端口，例如 7890。设置后在连接记录里确认流量确实进入 mihomo。

场景四：开启 Clash 后国内网站也变慢

查看连接记录，确认国内域名是否命中 DIRECT。若误入代理组，检查规则顺序和规则集更新状态。不要直接把所有流量改为直连来掩盖问题；应找到错误命中的规则，确认规则集是否加载成功。

处理优先级：先做低风险操作，再改底层参数

推荐顺序是：更新订阅、固定节点、换同地区节点、换地区、换网络对照、关闭 TUN 对照、检查规则与端口、最后调整 DNS 和 MTU。这个顺序从外部变量逐步进入本地底层，回退成本较低。

每次测试保留至少 60 秒稳定数据，并在修改后重启内核。不要同时更换配置文件、DNS、TUN 堆栈和节点，否则结论无法复用。排查结束后，应恢复 Rule 模式、关闭临时调试日志，并删除不再使用的手动代理设置。

如果需要进一步理解 DIRECT、PROXY、策略组、规则匹配和 fake-ip 的关系，可查看术语手册与进阶配置。第一次配置客户端时，则按使用指南重新核对订阅、系统代理和模式选择。