Clash 行動端耗電異常排查與背景執行策略優化

手機端 Clash 耗電偏高通常與背景保活、全域路由和日誌級別有關,本文給出分平台的省電設定與排查順序。

先定性:電量統計裡的數字被高估了

關鍵詞:耗電歸因。Android 和 iOS 的電量統計有一個共同特點:凡是經過 VPN 通道的流量,產生的網路耗電都記在 VPN 應用程式名下。Clash 在行動端以 VPN 形態運作,Android 走 VpnService 介面,iOS 走 Network Extension,微信視訊、短影片、地圖導航走過的每一位元組流量都從 Clash 的隧道裡過一遍,基頻喚醒與射頻發射的耗電隨之全部歸到 Clash 頭上。處理程序本身的 CPU 消耗,往往只佔統計數字的零頭。

判斷真異常看兩個指標。Android 進「設定 → 電池 → 應用程式耗電排行」,點開 Clash 條目看 CPU 前景與背景活動時間;iOS 進「設定 → 電池」,看 Clash 一行下面的背景活動時長。規則模式常駐一整天,Clash 自身 CPU 時間通常只有幾分鐘,佔比在 5% 上下浮動屬於正常水準。佔比連續幾天超過 15%,且 CPU 時間以小時計,才需要往下排查。

心理預期也要排除。代理常駐之後使用習慣往往同步變化,國外網站的內容看得多了,續航自然縮短。嚴格做法是做半天對照:關掉 Clash,保持相近的使用強度,對比螢幕開啟時間與待機掉電,先確認差值真實存在,再決定要不要折騰設定。

讀數口徑

電量排行裡的百分比是「歸因佔比」而非「處理程序功耗」。看 Clash 是否異常,以 CPU 活動時間為準,不要只看百分比排名。

背景保活:省電策略與不斷線的平衡

關鍵詞:電池最佳化白名單。行動端最普遍的矛盾是:系統為了省電殺背景程序,隧道被殺代理就斷;用戶端為了不斷線加強保活,保活手段本身又耗電。正確的解法不是讓 Clash 更激進地保活,而是把它從系統的省電名單裡移出來,讓系統別動它。

Android 的標準操作是把 Clash 加入電池最佳化白名單。路徑:設定 → 應用程式 → 特殊應用程式權限 → 電池最佳化,找到 Clash 改為「不最佳化」。加入白名單後系統不再限制它的背景網路與喚醒,靠前景服務就足以穩定維持隧道,不需要任何額外手段。

中國大陸品牌的 ROM 還有第二層限制。小米 MIUI 要另外開啟「自動啟動」,並在最近使用的應用程式介面把 Clash 卡片下拉鎖定;華為 EMUI 在「應用程式啟動管理」裡關掉自動管理,改為手動並允許背景活動;OPPO、vivo 的設定項目名稱不同,邏輯一致:允許背景執行、允許背景高耗電。缺了這一步,白名單也擋不住 ROM 自己的清理策略。

常駐通知不要關。Clash 的 VPN 通知屬於前景服務通知,是 Android 合規的保活機制。嫌通知礙眼把通知權限整個關掉,前景服務隨之降級,處理程序被殺後反覆重新啟動,每次重新啟動都要重建隧道、重新交握,反而更耗電。

iOS 側沒有手動保活這回事。Network Extension 由系統託管,隧道的啟動與停止交給系統排程。Clash Plus 的按需連線(On Demand)保持開啟即可,系統會在有網路需求時啟動隧道、閒置時掛起,比手動頻繁開關省電得多。

省電類工具與 VPN 衝突

各類「省電大師」「背景清理」工具會把 VPN 隧道當成可清理對象,殺掉隧道又觸發用戶端重新連線,一殺一連循環耗電。裝了這類工具,先把 Clash 加進它們的忽略名單,或者直接解除安裝,系統內建的電量管理已經足夠。

路由模式與規則集:比對開銷的主要來源

關鍵詞:規則模式。路由模式決定多少流量要走加密轉發,這是耗電差異最大的一項設定。全域路由(Global)下所有流量進代理,每一位元組都要過加密與轉發,耗電最高,只適合臨時排查連通性。規則模式(Rule)讓中國大陸站點直連、僅代理命中規則的流量,日常應當常駐規則模式。直連(Direct)模式等於關閉代理,不在討論範圍。

規則集不是越多越好。每個新連線都要逐條過一遍規則,幾萬條 GEOSITE 規則意味著每次比對都有 CPU 開銷。訂閱設定內建的規則集通常已經夠用,不要再疊加第三方大型清單;規則數量翻倍,比對開銷跟著翻倍,收益卻往往感受不到。

DNS 用 fake-ip。redir-host 模式下,代理網域要先做真實 DNS 解析再進規則比對,每次解析都是一次網路往返與基頻喚醒。fake-ip 模式直接回傳保留區段的假位址,網域原樣交給遠端解析,省去本機解析的等待與喚醒,行動端建議開啟。

DNS 上游別貪多。nameserver 裡堆七八個上游,並發查詢時每個上游都要發送封包,無線電模組被反覆喚醒。留兩三個低延遲上游即可,例如電信業者 DNS 加一組公共 DNS。

mode: rule
log-level: warning
dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - 223.5.5.5
    - 119.29.29.29

這份片段可以併入訂閱設定的覆寫段,或按用戶端設定頁逐項對應填寫,改完重新載入設定後生效。

日誌與介面刷新:容易被忽略的兩項

關鍵詞:日誌級別。log-level 開在 debug 或 info,每條連線的建立、比對、關閉都會寫一條日誌,頻繁的檔案寫入與喚醒在行動端是實實在在的耗電。日常使用固定為 warning 或 error,只在排查問題時臨時調回 info,用完調回去。

介面常駐同樣耗電。連線面板、日誌面板是即時刷新的,開著介面看連線捲動,CPU 與螢幕都保持喚醒。看完就退出,不要讓用戶端長期停留在前景。

節點自動測速要收斂。部分用戶端預設週期性對全部節點做延遲測試,間隔太短等於定時把節點清單整個跑一遍,幾十上百個節點各發一次探測。關閉自動測速,或把間隔拉長到 30 分鐘以上,手動測速足夠日常選節點。

分平台省電設定清單

一張表先給結論,後面按平台展開:

設定項目省電取向說明
路由模式規則(Rule)全域模式全量加密轉發,耗電最高
DNS 模式fake-ip省去本機真實解析的網路往返
DNS 上游2~3 個並發查詢時每個上游都會發送封包
日誌級別warning / errordebug 與 info 每條連線寫日誌
自動測速關閉或 ≥30 分鐘週期探測會跑遍整個節點清單
電池最佳化加入白名單防止系統殺背景程序導致反覆重新連線

Android(Clash for Android / FlClash)

iOS(Clash Plus)

標準排查順序

遇到耗電問題按固定順序走,每步只改一個變數,改完觀察半天到一天:

  1. 看電量統計裡的 CPU 與背景活動時間,確認是真異常還是歸因虛高。
  2. 檢查路由模式,全域改回規則。
  3. 日誌級別降到 warning,關閉自動測速。
  4. 精簡 DNS 上游與規則集,確認 fake-ip 已開啟。
  5. 核對電池最佳化白名單與 ROM 背景權限,常駐通知保持開啟。
  6. 做半天對照測試;仍異常則把日誌臨時調到 info 擷取一段,連同機型與系統版本一起回報給用戶端專案。

絕大多數案例走到第三步就能回落到正常水準。真正由用戶端缺陷導致的耗電是少數,按順序排查可以避免來回折騰。

下載用戶端