Clash 安卓版网速慢怎么排查：节点、线路、本地设置三层定位法

先建立可重复的测速基线

Clash 显示“已连接”只代表 Android VPN 接口或本地代理已启动，不代表当前节点具备稳定吞吐量。排查前应先把测试条件固定下来，否则 Wi-Fi、移动网络、节点和目标网站同时变化，很难判断速度损失发生在哪一层。

用四组结果区分故障范围

关闭 Clash，在当前 Wi-Fi 下测速一次，记录下载、上传和空闲延迟。
保持同一 Wi-Fi，启动 Clash，选择当前节点再测一次。
仍然保持 Clash 开启，只切换到另一个地区、另一种协议或另一条线路，再测一次。
关闭 Wi-Fi，改用 4G 或 5G，重复当前节点与备用节点的测试。

每组测试至少执行两次，单次持续 20 至 30 秒。测速服务器、测试时段和目标文件应保持一致。下载速度还要统一单位：100 Mbps 约等于 12.5 MB/s，浏览器显示 8 MB/s 时，对应链路速率约为 64 Mbps，不能直接拿 MB/s 与运营商标注的 Mbps 比较。

测试场景	示例结果	优先判断
关闭 Clash，Wi-Fi 测速	286 Mbps，延迟 18 ms	本地宽带基线正常
开启 Clash，节点 A	22 Mbps，延迟 96 ms	节点或中转线路可能受限
开启 Clash，节点 B	173 Mbps，延迟 72 ms	客户端设置基本正常，节点 A 异常
移动网络，节点 A	118 Mbps，延迟 88 ms	家庭宽带到节点 A 的路径可能拥塞

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

如果同一网络下只有少数节点慢，问题通常位于节点层。常见原因包括节点负载过高、出口带宽不足、协议握手反复重传、订阅中的节点已经失效，以及策略组实际选中的节点与界面预期不一致。

从代理页确认真实出口

在常见的 Clash Meta Android 客户端中，可进入「代理」页面，展开正在被规则引用的策略组，再查看带有选中标记的具体节点。不要只看顶层组名。例如规则指向的是「节点选择」，而「节点选择」内部又引用「自动选择」，最终出口可能由 URL Test 自动切换，并不是刚才手动点击的地区。

进入「代理」→ 当前策略组，记录实际选中的节点名称。
点击右上角测速入口，或对策略组执行延迟测试。
选择三个不同地区或不同线路标识的节点，逐一测试实际下载。
测试期间关闭自动切换，避免测速中途更换出口。
进入「日志」，确认目标域名命中了预期规则和策略组。

延迟测试出现 80 ms、95 ms、110 ms 这类接近结果时，不应只选最低的一个。连续测试三轮，如果某节点分别为 72 ms、310 ms、超时，说明抖动明显；另一个节点稳定在 105 至 118 ms，实际网页和视频体验往往更可靠。

识别节点负载和限速

节点晚高峰变慢、凌晨恢复，通常与节点并发或上游拥塞有关。可以在 08:00、20:00、23:30 三个时段记录同一节点速度。如果结果从 160 Mbps 降至 18 Mbps，而其他节点仍保持 120 Mbps 以上，应优先切换节点，而不是反复修改 Android 设置。

另一个典型特征是小文件打开正常，大文件下载稳定停在固定速度。例如网页首屏很快，但下载始终维持 2.0 MB/s 左右。这可能是节点端带宽分配、订阅套餐速率限制或单连接限速。使用两个不同来源的大文件测试，再尝试支持多连接的下载任务，可以区分目标站限速与节点整体吞吐不足。

更新订阅并排除失效条目

进入「配置」页面，对当前订阅执行更新，然后重新选择配置。若订阅提供方已经更换服务器地址，而手机仍在使用缓存配置，旧节点可能表现为间歇可连、握手缓慢或速度极低。更新后应再次检查策略组，因为节点名称变化可能导致原有手动选择回退到第一个条目。

第二层：判断运营商线路与跨网拥塞

节点本身正常，但家庭 Wi-Fi 下明显慢、移动网络下恢复，说明问题可能位于本地运营商到代理入口之间。即使两个节点都位于同一地区，其入口运营商、中转方式和回程路径也可能完全不同。

用网络切换定位入口路径

最有效的对照不是反复重启 Clash，而是保持节点不变，只切换接入网络。假设节点 C 在家庭宽带下为 14 Mbps，在 5G 下为 126 Mbps；关闭 Clash 后两种网络都能达到 200 Mbps 左右，那么手机性能和节点出口通常不是主要限制，家庭宽带到节点入口的路径更值得怀疑。

Wi-Fi 慢、移动网络快：检查宽带跨网路径、路由器和 IPv6。
Wi-Fi 与移动网络都慢：检查节点负载、协议或客户端设置。
仅某个目标网站慢：检查规则命中、目标站出口限制和 DNS 结果。
所有节点晚间一起慢：可能是本地接入或上游中转的时段性拥塞。

比较直连规则与代理规则

进入「日志」页面，打开速度异常的网站，观察连接记录中的规则名称与最终策略。如果本应代理的域名命中了 DIRECT，流量会直接走本地运营商；如果本应直连的大型下载站被送到远距离节点，也会增加绕路和带宽消耗。

例如规则集将软件镜像站错误归入代理组，原本 20 ms 的本地路径可能变成“手机 → 境外节点 → 国内镜像”的往返路径。此时节点测速正常，但单个站点下载慢。临时把该域名加入直连规则后复测，可以验证是否为分流问题。

rules:
  - DOMAIN-SUFFIX,example-download.com,DIRECT
  - DOMAIN-SUFFIX,example-video.com,PROXY
  - MATCH,节点选择

修改规则时应优先使用客户端的覆写功能或独立规则提供者，避免每次更新订阅后丢失本地改动。完成测试后查看日志，确认域名确实命中新规则，而不是被前面更高优先级的规则提前截获。

检查 IPv4 与 IPv6 路径差异

部分网络的 IPv6 直连速度很好，但代理节点只稳定支持 IPv4；也可能出现 DNS 返回 AAAA 记录后，连接尝试 IPv6 超时，再回退到 IPv4。表现通常是网页开始加载前停顿 2 至 5 秒，而下载开始后速度正常。

可在客户端「设置」→「网络」或「设置」→「DNS」中查看 IPv6 开关，暂时关闭后复测。不同客户端版本的菜单名称略有差异，核心是让 DNS 解析和 mihomo 内核的 IPv6 能力保持一致。若关闭后首包恢复，应继续检查路由器的 IPv6 前缀、DNS 返回结果和节点协议支持，不必长期依赖反复重连。

第三层：核对 Android 本地设置

当多个节点、Wi-Fi 与移动网络都出现相近的低速结果，就要检查手机本地层。Android 的省电策略、VPN 冲突、TUN 参数、DNS、MTU 和其他网络工具都可能影响 mihomo 内核收发数据。

解除后台与省电限制

进入 Android「设置」→「应用」→ 当前 Clash 客户端 →「电池」，选择允许后台运行或不受限制；再进入「移动数据与 WLAN」，确认后台数据可用。不同品牌系统路径可能是「设置」→「电池」→「应用耗电管理」。省电模式会限制后台 CPU 和网络活动，锁屏后尤其明显。

测试时保持屏幕点亮 5 分钟，再锁屏 5 分钟，对比同一持续下载任务。如果亮屏为 90 Mbps、锁屏后降至 6 Mbps，重新点亮又恢复，基本可以确认后台调度参与了限速。

排除 VPN 与网络工具冲突

Android 同一用户空间通常只能激活一个系统 VPN 接口。广告过滤器、企业 VPN、私人 DNS 工具和其他代理客户端可能与 Clash 争用接口。进入系统「设置」→「网络和互联网」→「VPN」，确认当前活动连接只有目标客户端，并检查是否启用了始终开启的其他 VPN。

私人 DNS 本身不一定降低吞吐量，但当其服务器不可达时，会造成域名解析等待。进入「设置」→「网络和互联网」→「私人 DNS」，临时切换为自动，再测试首次打开网页的时间。如果下载速度不变，但网页等待从 4 秒降到不足 1 秒，问题主要在 DNS，不是节点带宽。

比较系统代理与 TUN 模式

系统代理模式只处理遵循 Android 代理设置的应用，部分游戏、QUIC 流量和自行实现网络栈的应用可能绕过。TUN 模式通过 Android VPN 接口接管更广泛的流量，但会增加一层虚拟网卡处理。排查时不要同时改变节点、DNS 和 TUN，应只切换一个变量。

在「设置」→「网络」或「设置」→「TUN」中记录当前状态。
使用同一节点，在普通 VPN 接管方式下完成一次 30 秒测速。
启用 TUN 后重新授权 Android VPN，再执行相同测试。
比较下载速度、上传速度、延迟和目标应用是否被正确接管。

如果普通模式为 140 Mbps，TUN 模式只有 38 Mbps，应继续检查 MTU、协议栈和 DNS 劫持，而不是直接认定节点故障。反过来，如果浏览器正常但某个应用不走代理，TUN 模式可能解决的是接管范围，不是线路速度。

调整 MTU 处理分片问题

MTU 不匹配会导致数据包分片或丢弃，常见表现是小网页正常、图片和视频卡住、上传速度异常低。TUN 常用 MTU 可从 1500 开始测试；在移动网络、额外隧道或部分宽带环境中，可依次测试 1480、1420、1400。每次只修改一个值，并完全停止后重新启动内核。

如果 MTU 1500 时上传只有 0.8 Mbps，改为 1400 后稳定到 18 Mbps，同时下载变化不大，可以保留较稳定的值。MTU 过低也会增加包头开销，因此不应直接降到很小，而应以 20 至 40 字节为步长定位。

tun:
  enable: true
  stack: mixed
  mtu: 1400
  auto-route: true
  strict-route: false

配置字段是否可用取决于客户端集成的 mihomo 内核版本。使用覆写前应先在「关于」或「设置」→「内核」中记录版本号，例如客户端 2.11.15、mihomo 1.19.12，并在修改后查看日志是否出现 unknown field、parse error 或 TUN create failed。

DNS 慢与实际带宽慢要分开处理

DNS 问题常被描述成“网速慢”，但它主要影响连接建立前的解析阶段。典型现象是输入网址后等待数秒，页面一旦开始加载就很快；已经建立连接的视频流和大文件下载速度基本正常。

观察首包等待与持续下载

每个新域名第一次打开慢，刷新后快：优先检查 DNS 缓存与上游解析。
域名解析快，但大文件始终低速：优先检查节点和线路吞吐。
部分域名返回错误地址：检查 fake-ip、规则集与 DNS 分流。
开启 TUN 后才出现解析超时：检查 DNS 劫持和端口占用。

mihomo 配置常见的本地混合代理端口是 7890，SOCKS 端口可能是 7891，DNS 监听端口常见为 1053。这些数值不是固定要求，但同一端口不能被两个服务同时占用。如果日志出现 address already in use，应检查其他代理、DNS 转发器或旧内核进程。

mixed-port: 7890

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  nameserver:
    - 1.1.1.1
    - 8.8.8.8

上面的地址只用于说明配置结构。实际选择上游 DNS 时，应考虑所在网络的可达性以及是否需要通过代理查询。若 DNS 请求本身被规则送往不稳定节点，解析时间也会随节点拥塞增加。

协议、内核与设备性能检查

在较旧或低功耗设备上，高吞吐加密、规则匹配和 TUN 转发可能占用明显 CPU。测速时可查看系统电量页面或性能监控：如果单个核心长期接近满载，速度稳定卡在某个水平，同时机身升温，设备处理能力可能成为限制。

对比协议而不是只对比地区

同一服务中的不同节点可能使用不同传输协议。测试时选择入口地区接近、线路等级相同但协议不同的节点，能减少变量。若一种协议在当前移动网络中频繁丢包，而另一种稳定，应保留适配当前网络的节点，不必根据延迟数字强行选择。

UDP 与 QUIC 也需要单独观察。网页基于 TCP 时正常，不代表游戏或 HTTP/3 正常。可临时关闭浏览器 QUIC 或让目标域名改走另一节点进行对照。如果关闭 QUIC 后视频启动恢复，但普通下载没有变化，应检查节点 UDP 支持和运营商 UDP 质量。

更新内核前先保留测试记录

客户端版本和 mihomo 内核版本会影响协议实现、TUN 栈及 DNS 行为。更新前记录四项信息：Android 版本、客户端版本、内核版本、当前配置更新时间。更新后使用同一节点和同一测速条件复测，才能判断变化来自软件还是网络时段。

如果更新后立即出现全面降速，可进入「日志」检查配置兼容错误，并暂时停用自定义覆写。旧配置中的废弃字段可能被忽略，也可能导致某个模块没有按预期启动。恢复基础订阅配置后速度正常，再逐项加回 DNS、TUN 和规则覆写，能快速定位冲突字段。

按结果执行的最终排查顺序

完整排查不需要一次改完所有设置。按照“节点 → 线路 → 本地”的顺序，每一步只改变一个变量，通常能在 15 至 30 分钟内缩小范围。

记录直连基线：关闭 Clash，在 Wi-Fi 和移动网络各测速两次。
确认真实节点：进入「代理」，查看规则实际引用的策略组与选中节点。
横向切换节点：测试至少三个入口，记录延迟、下载、上传和测试时段。
更新订阅：进入「配置」更新当前订阅，并重新确认策略组选择。
切换接入网络：保持节点不变，对比 Wi-Fi 与 4G、5G。
核对规则日志：确认慢速目标命中了预期的 DIRECT 或代理策略。
检查 Android 限制：解除后台电池限制，停止其他 VPN 和网络工具。
区分 DNS 与吞吐：比较首包等待和持续下载，不把解析慢误判为带宽低。
对比 TUN：在相同条件下切换模式，必要时测试 1500、1480、1420、1400 MTU。
检查版本与覆写：记录客户端和 mihomo 版本，停用自定义项后复测。

最终判断可以归纳为三类：只有个别节点慢，直接处理节点质量；同一节点在不同网络差异明显，重点处理运营商路径和路由器；所有节点、所有网络都慢，重点检查 Android 后台限制、TUN、DNS、MTU、内核版本和设备性能。保留测试表比反复点击重连更有效，也方便在订阅或网络环境变化后复核。