iPhone 运行 Clash 耗电异常:后台运行机制与省电设置

先看懂 Clash 为什么能在锁屏后继续工作

iPhone 上的 Clash 类客户端通常通过 iOS Network Extension 建立本地 VPN。开启连接后，网页、即时通信和系统服务产生的网络数据会先进入数据包隧道，再由 Clash 内核按照规则决定直连、代理或拒绝。主应用退到后台甚至被系统从最近任务中清理后，负责隧道的网络扩展仍可继续运行。这是锁屏后代理连接没有立即中断的原因，也是电池页面可能持续记录网络活动的原因。

后台工作不等于屏幕熄灭后一直满负载。没有网络请求时，扩展的大部分时间应处于等待状态；收到推送、照片同步、邮件刷新或应用请求时，扩展才需要处理连接、查询 DNS、匹配规则并转发数据。实际耗电由传输量、唤醒频率、节点质量、DNS 设置、日志级别和策略组检查共同决定。

锁屏后仍会出现的正常网络活动

• 即时通信应用维持连接并接收推送。
• iCloud 照片、文件或设备备份继续上传。
• 邮件账户执行后台获取，系统服务同步时间与账户状态。
• 策略组按设定间隔执行 URL 测试或节点健康检查。
• 规则提供者、代理提供者或订阅到达更新周期后发起请求。
• 按需连接规则检测到目标网络变化并重新建立隧道。

因此，看到 Clash 出现在「设置」→「电池」列表中，并不能直接证明耗电异常。iOS 显示的是选定时段内各项目的相对占比：其他应用使用很少时，网络扩展即使只消耗少量电量，也可能显示较高比例。判断时还要结合电量下降、后台活动时长、蜂窝信号和实际流量。

正常耗电与异常耗电怎么区分

最有效的方法不是盯着单次百分比，而是做一组条件固定的对照。开始前将电量充到 80% 以上，关闭正在下载的内容，暂停照片同步，保持屏幕熄灭，并确保两轮测试使用相同的 Wi-Fi、相同位置和相近时长。低于 20% 电量时系统调度策略会变化，不适合用来比较。

做一次 30 分钟对照测试

1. 前往「设置」→「电池」，确认最近一小时没有大型游戏、视频导出或系统更新。
2. 连接稳定 Wi-Fi，关闭个人热点，将 Clash 切到常用配置和规则模式。
3. 锁屏静置 30 分钟，记录开始与结束电量，同时查看 Clash 对应的后台活动。
4. 关闭 Clash 的 VPN 连接，在同一网络再静置 30 分钟。
5. 两轮都重复一次，避免电量显示取整造成误判。

30 分钟测试中的 1 个百分点只是排查触发线，不是所有 iPhone 的统一标准。电池容量、健康度、环境温度和电量显示取整都会影响结果。更可靠的异常信号是：锁屏后持续发热、每小时稳定下降数个百分点、后台网络流量明显增长，或运行日志每隔几秒重复同一条连接错误。

电池页面应该看哪些字段

在「设置」→「电池」中切换到“显示活动”，分别查看“屏幕开启”和“后台”活动。若 Clash 只显示较长后台时间，但整机耗电下降很小，通常只是网络扩展保持可用。若后台时间、耗电占比和移动数据同时升高，才需要继续定位。蜂窝数据可在「设置」→「蜂窝网络」中查看，测试前后记录数值比单看百分比更直观。

高频健康检查是常见耗电来源

URL 测试策略组会定期访问检测地址，比较候选节点的响应结果。代理提供者也可以配置健康检查。一次请求的流量通常很小，但如果配置包含 40 个节点、检查间隔为 30 秒，那么每小时理论上可能触发约 4800 次节点探测。网络状况不佳时还会叠加 DNS、TCP 或 TLS 重试，造成频繁唤醒。

移动端没有必要把策略组刷新设成几秒一次。日常使用可以先把自动测试间隔调到 600 秒；线路变化较少时可设为 900 秒。只有在手动排查节点时，才临时执行一次测试。对于 Clash Meta（mihomo）兼容配置，可以同时启用延迟检查的惰性行为，让当前没有被使用的策略减少主动测试。

proxy-groups:
  - name: 自动选择
    type: url-test
    use:
      - mobile-provider
    url: http://www.gstatic.com/generate_204
    interval: 600
    tolerance: 100
    lazy: true

proxy-providers:
  mobile-provider:
    type: http
    url: https://example.com/subscription.yaml
    path: ./providers/mobile.yaml
    interval: 86400
    health-check:
      enable: true
      url: http://www.gstatic.com/generate_204
      interval: 600
      lazy: true

示例中的订阅地址仅表示字段位置，实际使用时应保留你现有的有效地址。interval: 600 表示 600 秒检查一次，tolerance: 100 表示候选延迟差异不足 100 毫秒时不频繁切换。提供者的 interval: 86400 是 24 小时更新一次配置文件，它与节点健康检查的间隔不是同一个设置。

客户端界面中的调整顺序

1. 进入「设置」→「参数设置」，查找延迟测试、健康检查或策略组测试间隔。
2. 将低于 60 秒的周期先调整为 600 秒，观察半天。
3. 关闭不使用的策略组自动测试，保留一个主要自动选择组。
4. 更新订阅后只手动测试一次，不要连续点击全量测速。

不同客户端的字段名称可能略有差异。如果界面没有提供对应开关，应在确认配置由自己维护后再编辑 YAML。订阅服务自动生成的配置可能在下次更新时覆盖本地改动，可以使用客户端的覆写功能保留间隔设置。

精简规则、DNS 与日志负担

规则数量并不是越少越快。Clash 内核会使用适合的数据结构处理域名和 IP 规则，几千条正常规则通常不会单独造成明显耗电。更值得处理的是重复规则集、频繁更新的远程规则、过量脚本逻辑，以及把所有连接都送入复杂处理链的配置。移动端应优先保留明确且稳定的分流需求。

规则配置先处理三个问题

• 删除失效的远程规则集：持续请求不可达地址会产生超时和重试。
• 减少重复提供者：同一域名分类不必从多个来源分别加载。
• 拉长更新时间：稳定规则集可使用 86400 秒更新周期，不需要每 10 分钟获取一次。

rule-providers:
  direct-sites:
    type: http
    behavior: domain
    format: yaml
    path: ./rules/direct-sites.yaml
    url: https://example.com/direct-sites.yaml
    interval: 86400

规则仍按从上到下的顺序匹配。高频、明确的本地域名规则可以放在较前位置，最终保留 MATCH 作为兜底。不要为了省电随意删除局域网直连、系统服务或 DNS 相关规则，否则连接失败后的重复尝试反而可能增加唤醒。

DNS 设置避免并发过多

配置多个 nameserver 与 fallback 不代表每次查询都会全部串行执行，但复杂的回退和过滤会增加请求量。移动端通常保留 2 个稳定的主 DNS 即可。使用加密 DNS 时，还要确认对应服务器在当前网络可达；若服务器经常超时，每次域名解析都可能等待并重试。

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

是否关闭 IPv6 要按当前网络判断。运营商网络和家庭宽带均稳定支持 IPv6 时，可以保留；若日志中持续出现 IPv6 连接超时，而实际代理节点只提供 IPv4，再考虑关闭。不要仅凭耗电感觉同时更改 DNS、节点和规则，否则无法确认是哪项设置起作用。

日志级别保留在 info 或 warning

debug 日志适合短时间定位规则命中、DNS 请求和连接失败，不适合全天开启。大量连接会持续生成日志并增加内存与存储操作。排查结束后，将日志级别恢复为 info；配置稳定且客户端支持时，也可使用 warning。不要在问题仍未复现前清空日志，先截取 3 至 5 分钟重复片段更有价值。

按需连接与 TUN 模式怎么设置

按需连接用于在满足条件时自动启用 VPN，例如离开家庭 Wi-Fi 后连接，回到受信任网络后断开。规则简单时，它能减少手动操作；条件互相冲突时，则可能在 Wi-Fi 与蜂窝网络切换、路由器信号波动或设备唤醒时反复建立隧道。

按需连接保留明确条件

• 只按已知 Wi-Fi 的 SSID 或网络类型做判断，避免多条范围重叠的规则。
• 不要同时设置“所有 Wi-Fi 连接”和“指定 Wi-Fi 断开”却忽略规则顺序。
• 出现每隔几十秒重连时，先关闭按需连接 30 分钟做对照。
• 经常在地铁、电梯或地下停车场切换网络时，可暂时关闭自动重连测试耗电变化。

如果你全天都需要规则分流，保持一次稳定连接通常比频繁连接、断开更省资源。若只在少数应用或特定网络中使用，则可通过清晰的按需条件缩短隧道运行时间。省电目标不是让 VPN 尽可能多地重启，而是减少不必要的活跃处理和失败重试。

TUN 模式本身不等于异常耗电

iOS 上的全局网络接管通常依赖系统提供的数据包隧道能力，客户端界面可能将其称为 VPN、TUN 或增强模式。它需要处理系统流量，因此比只给单个应用填写 HTTP 代理覆盖面更广，但正常空闲时不应持续高负载。真正需要检查的是 UDP 会话数量、连接循环、DNS 超时和节点丢包。

如果配置同时开启流量嗅探，可先确认是否确有基于域名恢复的需求。嗅探会读取连接初始信息以辅助规则判断，在连接量很大时会增加处理工作。关闭前要检查配置是否依赖嗅探得到的域名，否则部分规则可能退化为 IP 匹配或落入兜底策略。

节点与蜂窝信号也会放大耗电

节点握手失败、丢包和长距离链路会使连接反复重传。此时表面上是 Clash 占用电量，实际原因可能是代理服务器不可达或当前网络质量差。先选择一个稳定节点，停止自动切换，再观察日志中是否反复出现 timeout、connection reset、TLS handshake timeout 等错误。

用具体数值判断节点状态

• 同一 Wi-Fi 下连续测试 5 次，若结果在 80 至 130 毫秒间小幅变化，通常比一次 60 毫秒、下一次 900 毫秒更稳定。
• 丢包环境中，单次延迟低也不代表适合长连接。语音、推送反复断开时应换线路验证。
• 节点连续 3 次超时后先停用，不要让自动策略每 30 秒重新探测。
• 在弱信号区域测试时，将蜂窝网络暂时固定为 LTE 做对照，避免 5G 与 LTE 频繁切换干扰结果。

查看蜂窝模式可前往「设置」→「蜂窝网络」→对应号码→「语音与数据」。该选项是否显示以及名称会随运营商而变化。固定 LTE 只适合作为排查步骤；确认问题与网络切换无关后，可以恢复原来的自动设置。

按顺序完成一次省电排查

同时更改十个选项会让结果失去参考价值。下面的顺序优先处理最常见、最容易恢复的因素。每完成一步，至少观察 30 分钟；涉及待机耗电时，最好观察 6 至 8 小时。

1. 确认后台流量：暂停照片、网盘和系统更新，排除真实的大流量传输。
2. 固定一个稳定节点：暂时退出自动选择，观察是否还会发热或快速掉电。
3. 拉长检查间隔：将健康检查和 URL 测试设为 600 秒，关闭重复测速组。
4. 检查日志：寻找每隔数秒重复出现的 DNS 超时、握手失败或隧道重建。
5. 关闭按需连接对照：确认是否由 Wi-Fi 与蜂窝切换触发连接循环。
6. 恢复正常日志级别：从 debug 调回 info 或 warning。
7. 检查远程资源：移除失效规则提供者，把稳定资源更新周期设为 86400 秒。
8. 重建 VPN 配置：只有前述步骤无效时，才删除旧 VPN 配置并由客户端重新创建。

删除 VPN 配置前，应先保存当前订阅地址、覆写规则和策略选择。路径为「设置」→「通用」→「VPN 与设备管理」→「VPN」，点开对应配置后执行删除。重新打开客户端并允许添加 VPN 配置即可恢复。不要删除企业或工作账户使用的其他 VPN。

什么时候应该更新客户端或内核

如果异常从某次客户端更新后开始，先查看该版本的变更记录；若使用较旧构建，也应升级到下载页提供的当前稳定版本。Clash Meta（mihomo）内核会持续修正协议、DNS 和网络栈问题，但配置兼容性也会变化。升级前导出配置，升级后先使用原配置测试，不要把升级与大规模改规则放在同一次操作中。

什么时候更像是电池或系统问题

关闭 Clash 后仍持续发热，或「设置」→「电池」中多个系统项目同时出现长时间后台活动，问题可能不在代理配置。检查「设置」→「电池」→「电池健康与充电」中的最大容量；容量明显下降、设备刚完成系统升级、照片正在重新索引时，待机耗电都会变化。重启设备后再做一次相同条件的对照，比反复删除订阅更有效。

常见问题

排查 iPhone 上的 Clash 耗电，核心是把“网络扩展保持连接”和“持续高负载”分开。先用固定条件对照，再处理高频健康检查、失效远程资源、节点重连和复杂按需规则。每次只调整一个变量，才能找到真正影响续航的设置。