先理解 Android 上的 VpnService 接管方式

Android 版 Clash 类客户端通常通过系统提供的 VpnService 建立本地虚拟网络接口。应用启动服务后,Android 会把符合范围的网络流量送入这个虚拟接口,再由客户端内核按照配置中的规则、策略组和节点处理连接。状态栏出现钥匙或 VPN 标识,表示系统的 VPN 通道正在使用,并不等于手机直接连接了某个传统企业 VPN 服务器。

这套流程可以分成三层理解。第一层是 Android 系统负责把应用流量交给虚拟接口;第二层是 Clash 或 mihomo 内核读取目标域名、目标地址、端口等信息并匹配规则;第三层才是根据 DIRECT、代理节点、拒绝连接或其他策略结果建立实际连接。订阅提供的节点与规则配置决定第三层如何工作,VpnService 则解决第一层的流量入口问题。

Android 同一用户空间通常只能同时保留一个主要 VPN 服务。若系统已经连接公司 VPN、其他代理客户端、防火墙或依赖 VpnService 的过滤工具,再启动 Clash 客户端时,旧服务可能被停止,或者新服务无法取得 VPN 权限。遇到“点击启动后立刻停止”,应先检查状态栏和系统的 VPN 页面,而不是反复更新订阅。

VpnService 与普通系统代理的区别

普通 HTTP 系统代理依赖应用主动遵守代理设置,部分应用、UDP 流量或自行实现网络栈的软件可能绕过它。VpnService 从系统网络层接收被纳入范围的流量,覆盖面通常更完整,因此 Android 客户端多采用这种方式。部分客户端界面会把它称为 VPN 模式、TUN 模式或服务模式,具体名称不同,但判断重点都是:是否创建了 Android 虚拟接口,以及哪些应用被包含在接口范围内。

这里的 Android VpnService 与桌面端手动开启 TUN 并不完全等同。桌面系统可能需要安装虚拟网卡、调整路由或提升权限;Android 则通过公开的 VPN API 完成授权。用户首次启动时看到系统确认对话框属于正常权限流程,只有确认后客户端才能建立通道。

首次启动时需要核对的关键设置

导入订阅后,不宜立即把所有异常归因于省电策略。先确保配置可以加载、节点能够连接、代理组已经选择,再处理后台保活。一个稳定的排查顺序,可以把配置错误和系统限制分开。

  1. 确认配置处于启用状态。配置列表里可能同时保存多个订阅或本地 YAML 文件。更新成功不代表新配置已经切换为当前配置,应检查激活标记、更新时间和配置名称。
  2. 检查策略组选择。配置中的代理组可能默认选中不可用节点,也可能处于自动测速状态。先选择一个已完成延迟测试、能够建立连接的节点,再测试网页。
  3. 接受系统 VPN 授权。首次启动通常会弹出连接请求。若对话框被取消,客户端可以正常打开界面,却无法接管系统流量。
  4. 确认运行模式。规则模式按照配置中的规则分流;全局模式通常让大部分流量进入指定代理;直连模式会绕过代理。测试时应记录当前模式,避免在直连模式下误判节点失效。
  5. 查看运行日志。配置解析失败、DNS 请求异常、节点握手失败和网络不可达通常会留下不同日志。日志比单纯观察网页能否打开更接近故障位置。

应用分流范围怎么设置

不少 Android 客户端支持“仅代理所选应用”或“排除所选应用”。前者是白名单思路,只有勾选的应用进入 VpnService;后者是黑名单思路,被勾选的应用保持直连。两种模式不要同时凭名称猜测,修改前应阅读当前页面的说明,并用一个浏览器进行验证。

支付、银行、局域网设备控制、投屏和智能家居应用是否需要排除,应根据实际网络要求决定。排除应用后,它的连接不会再经过 Clash 规则,因此在日志里看不到对应请求属于预期行为。若浏览器可以访问而某个应用始终不通,应用分流列表是优先检查项。

锁屏后断连的常见原因

“亮屏正常,锁屏几分钟后无法连接,解锁打开客户端又恢复”通常意味着配置本身可以工作,但后台服务被限制、进程被回收,或者网络在待机时发生切换。Android 原生的 Doze 机制、厂商电量管理、后台启动限制和内存清理都可能参与其中。

Doze 会在设备静止、熄屏并满足条件后限制后台活动和网络访问。前台服务一般比普通后台进程更不容易被停止,因此客户端启动后通常会显示持续通知。若用户关闭了通知权限、把通知频道设为不允许,某些系统仍能运行服务,但也有系统会更积极地限制无法正常展示通知的前台服务。建议保留客户端的运行状态通知,并避免使用系统清理工具一键结束它。

先观察断连属于哪一种

  • VPN 图标消失:更像是 VpnService 被停止、应用进程被清理,或另一个 VPN 服务抢占了系统通道。
  • VPN 图标仍在,但所有连接失败:可能是上游网络变化后旧连接没有恢复,也可能是节点、DNS 或虚拟接口状态异常。
  • 只有部分应用失败:优先核对应用代理范围、规则命中、IPv6、DNS 与目标应用自身的后台限制。
  • 从 Wi-Fi 切到移动数据后失败:检查客户端是否能在网络切换后重建连接,以及移动网络是否具备可用的数据权限。
  • 打开客户端立即恢复:通常指向后台限制。界面进入前台后,系统重新给予执行机会,服务或内核随之恢复。

排查时可以做一个可重复测试:保持同一配置和同一节点,打开一个可持续刷新的页面,锁屏等待十分钟,再解锁观察 VPN 图标、客户端运行状态和日志时间线。随后分别使用 Wi-Fi 与移动数据重复。一次只改一个设置,才能判断究竟是哪项省电策略产生影响。

如果日志在锁屏期间完全中断,解锁后才继续出现,重点检查进程保活与电池限制。如果日志持续记录请求,但大量出现超时,则应转向节点可用性、网络切换和 DNS。若服务被系统停止,部分客户端会在日志末尾留下服务销毁或内核退出信息;不过进程被直接终止时,日志可能来不及记录完整原因。

省电白名单与后台运行设置

不同品牌手机使用的菜单名称不一致,但目标基本相同:允许客户端在后台持续运行、取消针对该应用的电池优化,并允许必要的后台网络活动。设置入口可能位于“应用信息”“电池”“应用启动管理”或“特殊应用权限”中。

建议按以下顺序调整

  1. 将电池用量设为不受限制。在客户端的应用信息中找到电池设置,选择“不受限制”“允许后台活动”或含义相近的选项。Android 原生系统常见入口是应用信息中的电池用量管理。
  2. 关闭自动管理。部分系统提供自动启动、关联启动和后台活动三个开关。关闭自动管理后,根据页面说明允许客户端自启动及后台运行。
  3. 保留前台服务通知。允许客户端展示运行通知。通知不仅用于显示状态,也与 Android 前台服务机制有关。
  4. 允许后台数据。检查移动数据与 WLAN 权限,确保后台数据没有被禁用。启用系统数据节省模式时,可将客户端加入“不受限制的数据使用”名单。
  5. 在最近任务中锁定应用。某些厂商系统提供任务卡片锁定功能,可以降低一键清理时被结束的概率。它不能替代电池白名单,但可作为补充。
  6. 重启客户端服务。权限变化后停止并重新启动 VpnService;必要时重启手机,再验证锁屏和网络切换。

将客户端设为不受电池优化限制,通常会增加一定后台耗电,因为内核需要维护虚拟接口、DNS 处理和必要的连接状态。实际耗电还取决于流量、规则规模、日志级别、节点协议以及应用是否持续产生网络请求。应先保证连接稳定,再逐项减少不必要的高开销设置,而不是同时关闭所有后台权限。

开机后是否会自动恢复

客户端能否开机启动,取决于应用是否实现相关能力、系统是否允许自启动,以及 VPN 授权和系统策略是否仍然有效。部分 Android 版本提供“始终开启的 VPN”选项,可在系统 VPN 设置中指定应用;但客户端是否适合启用该选项,应以其功能说明为准。

“阻止未使用 VPN 的连接”属于更严格的系统级选项。启用后,如果指定的 VPN 服务尚未建立,设备可能无法联网。调试配置、切换客户端或订阅节点不可用时,这会让故障表现更明显。需要持续强制流量经过 VPN 时才应考虑开启,并提前确认客户端能稳定自启动和恢复服务。

DNS、私人 DNS 与网络切换问题

后台运行正常并不代表解析链路一定正常。Android 的“私人 DNS”使用系统级加密 DNS 设置,Clash 配置也可能启用内置 DNS、Fake-IP 或基于规则的 DNS 处理。两者在不同客户端和配置下可能形成不同路径。出现“能连接 IP,但域名打不开”“部分应用一直转圈”时,应把 DNS 单独列为检查对象。

测试时可以暂时把 Android 私人 DNS 调整为自动,再重启客户端服务。如果问题消失,说明原先指定的私人 DNS 主机、当前网络或配置中的 DNS 路径可能存在兼容问题。这里不宜长期依靠随机切换解决,而应检查配置是否明确启用 DNS、监听方式是否适合 Android 客户端,以及规则是否要求解析特定域名。

Fake-IP 模式会为域名返回保留地址段中的映射地址,再由内核还原域名并匹配规则。它有利于保留域名信息和提高规则匹配的一致性,但某些局域网服务、特殊应用或依赖真实地址判断的场景可能需要加入过滤项。Redir-Host 等其他模式的解析流程不同,不能直接照搬过滤设置。

Wi-Fi 与移动数据切换后的恢复

手机离开 Wi-Fi 后,底层网络、出口地址和 DNS 环境都会变化。客户端需要感知默认网络改变,并让后续连接使用新的网络。如果切换后 VPN 图标仍在但无法访问,可以先等待数秒,再在客户端内停止并启动服务。若每次切换都必须手动重启,应检查客户端版本、后台网络权限和系统对 VPN 的限制。

同时启用双卡、数据节省、热点共享或局域网访问时,问题会更复杂。热点设备的流量是否经过手机上的 VpnService,受 Android 版本、厂商实现和客户端能力影响,不能仅凭手机自身已代理就推断热点流量也被接管。需要分别在手机与热点终端上测试出口和 DNS。

日志定位与完整排查顺序

Android Clash 客户端的日志通常包含规则命中、连接目标、所选策略、DNS 处理和错误信息。排查时可以临时把日志级别调到信息级或调试级,但长期开启详细日志会增加写入与处理开销。记录完成后应恢复日常级别。

常见日志线索

  • timeout 或连接超时:目标不可达、节点响应慢、网络切换未恢复或 DNS 请求没有完成。
  • connection refused:目标端口明确拒绝连接,也可能是本地监听或上游服务没有启动。
  • 配置解析错误:YAML 缩进、字段格式、订阅转换结果或当前内核不支持的配置项需要检查。
  • 持续命中 DIRECT:当前规则把流量判定为直连,应核对规则顺序、模式和目标域名。
  • 没有任何目标应用日志:应用可能被排除在 VpnService 外,或其流量没有进入当前客户端。

需要进一步确认系统是否把进程停止时,可以使用 Android 开发者工具查看设备日志,但这属于进阶方法。连接电脑并授权调试后,可围绕应用包名、VPN 服务和进程状态筛选信息。不同客户端包名不同,应从应用信息或安装包信息中确认,不能直接套用其他软件的包名。

adb shell dumpsys vpn
adb shell dumpsys deviceidle
adb shell dumpsys activity services

dumpsys vpn 可辅助查看当前 VPN 状态,dumpsys deviceidle 用于观察设备空闲与 Doze 情况,服务列表则可帮助确认目标进程和服务是否仍存在。这些命令的输出会随 Android 版本变化,适合用来验证现象,不应把某一行固定输出当作所有设备都适用的结论。

推荐的排查流程

  1. 在前台固定使用一个已验证节点,确认规则模式下可以正常访问。
  2. 确认系统 VPN 图标存在,并检查没有其他 VPN、防火墙或代理工具占用通道。
  3. 查看目标应用是否被纳入分应用代理范围。
  4. 关闭屏幕进行定时测试,记录 VPN 图标、日志中断时间和恢复方式。
  5. 把客户端加入电池优化白名单,允许后台活动、后台数据和运行通知。
  6. 分别测试 Wi-Fi、移动数据以及两者之间的切换。
  7. 若只有域名请求失败,再检查私人 DNS、配置 DNS 模式和 Fake-IP 兼容项。
  8. 仍然异常时,备份必要配置,更新到受维护的客户端版本,并使用同一订阅重新复测。

如果更新客户端后出现配置无法加载,不应直接把旧配置中的所有字段复制到新内核。Clash Meta(mihomo)在兼容传统 Clash 配置的基础上扩展了规则与协议能力,但不同客户端封装的内核版本、字段支持和默认行为可能不同。应先阅读客户端的错误日志,定位具体字段,再参考对应内核文档调整。

稳定运行后的耗电优化

连接稳定后,可以从日志、测速频率和不必要的后台请求入手控制耗电。频繁进行全节点延迟测试会同时建立大量连接;过短的订阅自动更新周期也会增加唤醒次数。自动测速组的测试间隔应根据实际使用调整,不需要为了追求每分钟最新结果而持续探测所有节点。

规则数量本身通常不是唯一耗电来源,更值得关注的是持续活跃的应用、连接重试、DNS 循环失败和详细日志。如果某个失效节点被策略组持续选中,后台应用可能不断重连,既影响体验也增加耗电。日志里出现密集重复错误时,应先更换节点或修正规则。

省电白名单的目标是让 VpnService 在需要时可靠运行,不是要求客户端永久保持高活动状态。合理配置下,没有流量时内核可以减少工作;产生连接时再完成规则匹配和转发。通过系统电池统计观察一整天的数据,比短时间盯住瞬时百分比更有参考价值。

最终可保留一套简洁基线:一个稳定配置、明确的规则模式、必要的应用代理范围、允许后台运行、正常显示前台通知,并记录私人 DNS与客户端 DNS 的组合。后续遇到锁屏断连时,先回到这套基线复测,再判断是系统更新、客户端版本还是订阅配置发生了变化。

继续配置 Android Clash 客户端

先选择适合 Android 的客户端,再按使用指南导入订阅、检查代理模式与系统 VPN 授权。