Clash 已连接却无法上网？安卓端逐项排查清单

安卓状态栏出现 VPN 钥匙图标，只能说明 Clash 已取得系统 VPN 权限并启动服务，不代表订阅有效、节点可达或 DNS 已正常工作。界面显示“已连接”时仍然断网，通常是流量进入了客户端，却在节点、规则、域名解析或应用分流中的某一层中断。

排查时不要同时修改多个选项。先确认故障范围，再按“网络基础 → 配置 → 节点 → 策略组 → DNS → TUN 与系统设置 → 应用分流”的顺序处理。每完成一步就重新打开测试页面，并记录结果。这样可以避免临时恢复后无法确定真正原因。

第一步：确认是代理故障还是手机本身断网

先做关闭与开启两组测试

在 Clash 主界面停止服务，等待状态栏 VPN 图标消失，然后分别使用 Wi-Fi 和移动数据打开两个平时可访问的网站。如果关闭 Clash 后仍然无法访问，问题不在代理配置，应先处理路由器、移动网络、飞行模式、欠费或系统网络限制。

关闭 Clash 服务，使用 Wi-Fi 测试普通网页和即时通信应用。
关闭 Wi-Fi，切换到 4G 或 5G，再重复测试。
重新启动 Clash，只使用同一网络复测。
记录是“所有应用断网”“只有浏览器断网”，还是“国内直连正常、代理目标不可访问”。

故障范围是最重要的分支条件。所有应用都断网，优先检查无效节点、DNS、VPN 冲突和错误的全局路由；只有个别应用异常，优先检查应用分流、绕过列表和该应用对 QUIC、IPv6 或证书环境的依赖；直连网站正常而代理目标不可访问，通常指向节点或策略组。

用 IP 与域名区分 DNS 问题

域名需要先解析为 IP，IP 连接则跳过域名解析。可以在浏览器访问路由器管理地址，例如 192.168.1.1；若局域网 IP 能打开而所有域名都失败，DNS 是首要检查对象。不要把公网 IP 测试当成绝对结论，因为部分网站会拒绝直接以 IP 访问。

现象	优先检查	暂不优先
关闭 Clash 也断网	Wi-Fi、移动数据、系统网络	策略组与规则
直连正常，代理目标失败	节点、订阅、策略选择	手机硬件
IP 可达，域名失败	DNS、私人 DNS、Fake IP	节点延迟排序
仅一个应用失败	应用分流、绕过、UDP	整份订阅失效

第二步：检查订阅状态与配置是否真正生效

确认选中的配置不是旧副本

不少问题来自“订阅更新成功，但运行的仍是另一份本地配置”。以 Clash Meta for Android 常见界面为例，进入「配置」，查看当前配置旁的选中标记、更新时间和文件名。若列表中存在多个名称相近的配置，应逐个核对来源，不要只看最上方条目。

检查订阅服务是否仍在有效期内，以及流量额度是否用尽。
在「配置」中对当前订阅执行更新，确认界面给出成功结果。
更新后重新选择该配置，再返回主页停止并启动服务。
如果更新返回 401、403 或 404，应处理订阅地址或账户状态。
如果更新提示 YAML 解析失败，应恢复服务方提供的原始配置，暂时停用自定义覆写。

订阅链接能够下载文本，不等于内容一定可运行。空节点列表、策略组引用不存在的节点、规则提供者下载失败，都可能让核心启动后无法完成正常转发。进入「日志」，重新启动服务，重点查看启动后的前 30 秒。连续出现 proxy not found、no such host、timeout 或规则集下载错误时，应按对应对象继续定位。

暂时停用可能覆盖原配置的设置

客户端的覆写功能可以修改端口、DNS、规则和运行模式。旧覆写与新订阅结构不兼容时，订阅本身虽然正常，最终交给 mihomo 内核的配置仍可能错误。进入「设置」→「覆写」或当前版本对应的覆写入口，暂时关闭最近添加的 DNS、规则与脚本覆写，然后重新载入配置。

第三步：验证节点和策略组选择

延迟数值不等于完整可用

在「代理」页面对当前策略组执行延迟测试。一次测试中，80–250 ms 通常可以继续验证；持续显示超时，或多个节点都固定在 5000 ms 左右，则说明测试请求未得到响应。延迟测试只验证测试地址的连接结果，不能证明所有 TCP、UDP 和目标域名都可用。

选择节点后，应返回主界面观察实时流量。打开网页时上下行长期保持 0 B/s，可能是应用没有进入 VPN、被绕过或系统服务未接管；有少量上行但下行始终为零，常见于节点不可达、握手失败或回程受阻；上下行均有数据而页面停在加载状态，则要继续检查 DNS、UDP 或应用协议。

手动选择固定节点，排除自动组干扰

进入「代理」，找到规则实际引用的策略组，例如 PROXY、节点选择 或服务方自定义组名。
暂时不要选择 自动选择、故障转移 或负载均衡子组。
选定一个延迟测试有结果的具体节点。
连续测试两个不同站点，并保持至少 30 秒。
再切换另一个地区、另一种协议的节点复测。

如果固定节点可以访问，而自动组不行，问题位于自动测试地址、容差设置或组内候选节点。若所有节点都失败，不要反复切换同一地区的相似条目，应检查订阅状态、网络是否限制对应端口，以及日志中的握手错误。

核对运行模式

Clash 常见运行模式包括规则、全局和直连。排查阶段可以短暂切换，但要理解结果：

规则模式：流量按规则匹配到直连、代理或拒绝策略，是日常使用的常见选择。
全局模式：大部分流量交给全局策略组。若全局组仍选中失效节点，切换模式不会恢复。
直连模式：用于验证客户端接管后能否直接出站，不用于验证代理节点。

规则模式失败而全局模式正常，说明节点具备基本连接能力，下一步应查看规则匹配结果。打开「日志」，访问失败目标，找到对应连接记录，确认它最终进入了哪个策略组。若目标被错误送入 DIRECT、REJECT 或一个失效组，应调整规则来源或覆写，而不是修改节点端口。

第四步：排查 DNS、私人 DNS 与 Fake IP

先处理 Android 私人 DNS 冲突

Android 的私人 DNS 使用加密解析。部分网络无法连接指定的私人 DNS 主机时，系统会表现为“Wi-Fi 已连接但域名打不开”。进入系统「设置」→「网络和互联网」→「私人 DNS」，临时改为“自动”或“关闭”，再重新启动 Clash。不同厂商可能将该入口放在「连接与共享」或「更多连接」中。

如果关闭私人 DNS 后立即恢复，说明原私人 DNS 主机与当前网络或 Clash 的 DNS 接管路径不兼容。此时应保留一套解析链路：要么由 Android 私人 DNS 负责，要么由 mihomo 的 DNS 模块负责，避免两套强制规则互相覆盖。

检查 DNS 配置字段

mihomo 配置中常见的 DNS 结构如下。地址仅用于说明字段关系，不应脱离订阅环境直接整段替换：

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: false
  enhanced-mode: fake-ip
  nameserver:
    - 1.1.1.1
    - 8.8.8.8
  fallback:
    - tls://1.1.1.1:853

enable 控制内核 DNS 模块；listen 是本地监听地址；enhanced-mode 常见值为 fake-ip 或 redir-host。使用 TUN 接管时，还要确认 DNS 劫持与监听端口匹配。若配置将请求劫持到 1053，但 DNS 模块并未监听该端口，域名请求会进入空目标。

用 redir-host 对照 Fake IP 兼容问题

Fake IP 会为域名返回保留地址，再由内核根据映射完成转发。它通常能提供稳定的规则匹配，但个别局域网设备、银行应用、投屏工具或依赖特殊 DNS 响应的应用可能不兼容。表现为大多数网站正常，只有特定应用登录失败、局域网域名失效或设备发现异常。

可以复制一份配置，将 enhanced-mode 从 fake-ip 临时改为 redir-host 对照测试。若问题消失，应优先为具体域名补充 Fake IP 过滤，而不是长期关闭所有增强解析能力。修改后需要重新载入配置并重启服务，单纯返回主界面通常不会让旧映射立即失效。

第五步：处理 TUN、系统 VPN 与手动代理冲突

确认同一时间只有一个 VPN 服务

Android 的 VPN 接口通常只能由一个应用占用。Clash 启动后若被其他 VPN、防火墙、流量过滤器或工作资料 VPN 替换，客户端界面可能短时间仍显示运行，但系统流量已不再经过它。进入系统「设置」→「网络和互联网」→「VPN」，确认当前已连接项目确实是正在使用的 Clash 客户端。

停止其他使用 Android VPNService 的应用。
关闭其他 VPN 项目的“始终开启 VPN”。
排查期间关闭“阻止未使用 VPN 的连接”。
重新授权 Clash 的 VPN 请求，再观察状态栏图标。

“阻止未使用 VPN 的连接”适合配置稳定后使用。排障阶段如果 Clash 服务崩溃、配置加载失败或被系统回收，该选项会阻断全部网络，使现象看起来像节点失效。

清除 Wi-Fi 中遗留的手动代理

部分用户曾在 Wi-Fi 高级设置中填写 127.0.0.1 和 7890。如果客户端当前使用 TUN/VPN 接管，或本地 mixed-port 已改成其他值，这个手动代理会把浏览器流量送往没有监听的端口。进入系统「设置」→「Wi-Fi」→「当前网络」→「代理」，排障时先设为“无”。

端口 7890 常被用作 mixed-port，7891 常见于 SOCKS 或重定向配置，9090 常用于外部控制接口，但具体值完全取决于当前配置。不要仅凭常见端口推断本机监听状态，应在客户端设置或日志中查看实际端口。

切换 TUN 栈进行兼容测试

mihomo 的 TUN 实现可能提供 system、gVisor 或 mixed 等栈选项，客户端版本与系统支持情况不同。若更新系统或客户端后突然出现“服务能启动但所有连接超时”，可以进入「设置」→「网络」→「TUN」对应入口，记录当前值，再切换另一种受支持的栈复测。

切换后应完整停止服务，等待 5 秒，再重新启动。只在运行中切换开关，旧 VPN 接口和连接缓存可能仍然存在。若一种栈下 TCP 正常但语音、游戏或 HTTP/3 异常，应继续检查 UDP 支持，而不是直接判断节点整体不可用。

第六步：检查应用分流、绕过列表与省电限制

只有个别应用断网时查看应用分流

应用分流可以按 Android 应用包名决定是否进入 VPN。白名单模式只接管选中的应用，黑名单模式则绕过选中的应用。两种模式理解反了，会出现浏览器正常、目标应用完全不走代理，或只有少数应用可以联网。

进入 Clash 的「设置」→「网络」→「应用分流」或版本对应入口。
确认当前使用白名单还是黑名单逻辑。
临时关闭应用分流，让所有普通应用进入 VPN。
重新启动服务，测试此前失败的应用。
恢复分流时逐个添加应用，不要一次导入大批包名。

工作资料、应用分身和双开应用可能使用不同 UID。主空间中的应用已被选中，不代表工作资料中的副本也遵循相同规则。遇到只有分身应用失败时，应在对应用户空间中核对 VPN 权限与应用列表。

检查局域网绕过与路由排除

为保证打印机、投屏和路由器管理可用，配置常会绕过私有网段，例如 192.168.0.0/16、10.0.0.0/8 和 172.16.0.0/12。如果远端服务也通过这些地址段提供资源，过宽的绕过设置会让流量从本地接口直接发出并失败。

相反，如果局域网流量被全部送入远端代理，路由器管理页和本地设备也可能无法访问。查看日志中目标 IP 的出站策略，确认私有地址进入 DIRECT，需要远端访问的内部地址则按实际网络设计处理。

解除系统对后台服务的限制

部分 Android 系统会在锁屏后限制后台 VPN 服务，表现为刚启动时可用，几分钟后全部连接停滞。进入系统「设置」→「应用」→「Clash 客户端」→「电池」，选择“无限制”或允许后台活动；再进入「移动数据与 Wi-Fi」，允许后台数据和不受限数据使用。

如果故障只在锁屏 5–10 分钟后出现，而点亮屏幕后恢复，省电策略比节点更可疑。还应检查厂商系统中的自启动、后台弹出界面和锁定任务权限。每次只调整一项，并进行一次完整锁屏测试。

第七步：根据日志做最后定位

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

日志量很大时，先清空或记住当前时间，然后只访问一个失败目标。建议按以下格式记录：

网络：家庭 Wi-Fi
运行模式：规则
配置更新时间：2026-08-14 10:32
策略组：PROXY → 节点 A
测试时间：10:36:20
现象：域名加载 15 秒后超时
日志关键词：DNS timeout / connection refused

一条完整连接记录通常能回答三个问题：域名是否完成解析、规则把连接送到了哪里、出站连接在哪个阶段失败。timeout 表示等待超时，可能是节点、目标或中间网络不可达；connection refused 表示对端主动拒绝；network unreachable 常与路由、接口或 IPv6 有关；TLS 握手错误则应进一步核对时间、SNI、协议参数和网络干扰。

用最小配置区分客户端与订阅问题

如果完成前述步骤仍无法定位，可以使用服务方提供的原始订阅，关闭自定义覆写、应用分流和额外规则，只保留一个固定节点进行测试。原始配置正常，说明故障来自本地修改；原始配置仍失败，但同一订阅在另一网络正常，说明当前网络环境需要重点检查；多台设备、多个网络都失败，则应联系订阅提供方核对节点状态。

不要在测试期间同时更换客户端、订阅、网络、DNS 和节点。一次改变一个变量，至少完成一次启动、一次域名访问和一次日志检查。对于“已连接却无法上网”这类问题，稳定复现比频繁重装更有价值。

排查结果速查

测试结果	可能原因	下一步
关闭 Clash 后恢复	配置、节点、DNS 或 VPN 接管异常	按本文顺序继续检查
固定节点可用，自动组不可用	自动组候选或测试地址异常	调整组成员与健康检查
全局模式可用，规则模式失败	规则匹配或策略组引用错误	从日志确认实际出站
关闭私人 DNS 后恢复	系统解析链路冲突	统一由一套 DNS 方案接管
关闭应用分流后恢复	白名单、黑名单或 UID 选择错误	重新建立最小应用列表
切换移动数据后恢复	Wi-Fi 网络限制或路由异常	检查路由器 DNS、IPv6 与端口策略
锁屏后失效	省电策略回收后台服务	允许后台运行与不受限电池使用