手機掛 Clash 耗電異常排查:Android 後台策略與省電設定清單

掉電兩成先別怪用戶端:定位問題的 3 個信號

手機掛著代理過夜,早上起來發現掉了 20%~30% 的電量,第一反應容易歸咎到用戶端本身。但代理軟體的常駐耗電主要來自三個可量化的環節:系統是否允許它在後台持續運行、網路層是否頻繁喚醒 CPU、以及規則比對是否消耗多餘算力。判斷到底是哪一環出問題,先看三個信號。

信號一:打開系統設定裡的電池詳情,看 Clash 用戶端的「後台活動時長」是否接近整夜時長。如果接近,說明它沒有被系統限制,處於持續喚醒狀態,這本身是正常的代理工作方式,不是異常。信號二:看同一時段的「喚醒鎖定次數」或「App 待機異常」提示,次數異常高往往意味著探測間隔設定過短或者規則命中不穩定,導致頻繁重連。信號三:對比不開代理時的待機掉電速度,如果差距在 5% 以內,說明耗電大頭其實是其他後台應用,不該繼續在用戶端設定上糾結。

系統省電策略是頭號變數:後台白名單逐項設定

Android 從 Doze 機制開始,各廠商客製化系統又疊加了一層更激進的省電策略,這是導致代理頻繁掉線、進而觸發重連風暴的最常見原因。核心邏輯很簡單:系統判定 App 長時間處於後台且螢幕關閉後,會限制其網路存取和 CPU 喚醒,代理程序被凍結後,TUN 虛擬網卡的流量轉發隨之中斷,手機重新連網時又要重建一次連線,這個反覆重連的過程才是真正的耗電大戶。

不同廠商系統的設定入口和限制強度都不一樣,逐項檢查以下幾處:

• MIUI(小米):設定 → 應用設定 → 應用管理 → 找到 Clash 用戶端 → 省電策略選擇「無限制」,同時關閉「自啟動管理」裡對應的限制項。
• ColorOS / realme UI(OPPO/realme):電池 → 應用耗電管理 → 找到用戶端 → 允許背景執行 + 允許高耗電,並在「其他設定」裡關閉「休眠電量最佳化」對該應用的限制。
• OriginOS / Funtouch OS(vivo/iQOO):i管家 → 應用管理 → 權限管理 → 背景高耗電,把用戶端加入白名單;同時關閉系統內建的「智慧省電」對該應用的限制。
• EMUI / HarmonyOS(華為):電池 → 更多電池設定 → 應用啟動管理,將用戶端改為「手動管理」並勾選自啟動、關聯啟動、後台活動。
• One UI(三星):設定 → 電池 → 背景使用限制,把用戶端從「休眠中的應用程式」或「深度休眠應用程式」清單移出。
• 原生 Android / Pixel:設定 → 應用程式 → 找到用戶端 → 電池 → 將「電池使用情況」改為「不受限制」。

這一步幾乎決定了代理在後台能否穩定存活。沒有做系統白名單,後續所有用戶端內部的省電調校都是治標不治本。

TUN 模式常駐與省電的取捨

TUN 模式透過虛擬網卡接管全域流量,不依賴單個 App 設定代理,相容性最好,但代價是它需要一個常駐的後台服務持續監聽網路介面變化。這個服務本身耗電極低,真正拖累電量的是配合不當的省電策略:系統一邊限制後台程序喚醒,TUN 服務卻需要隨時回應網路切換(比如從 Wi-Fi 切到行動數據),兩者衝突就會導致服務被砍後自動重啟,重啟過程伴隨一次完整的路由表重建和 DNS 重新解析,這才是耗電尖峰所在。

如果確認不需要全域透明代理(比如只是給個別 App 分流),可以考慮關閉 TUN 模式,改用系統 VPN 介面或者應用層代理設定,減少一個常駐網路服務。但如果依賴 TUN 做全域分流或者需要攔截 UDP/ICMP 流量,保留 TUN 模式的同時把上一節的系統白名單做到位,比關閉 TUN 更划算。

測速間隔與並發探測:被忽略的耗電來源

策略群組設定裡的 url-test 類型會按固定間隔對節點發起延遲探測,這個間隔由 interval 欄位控制,單位是秒。很多訂閱預設寫得很短(比如 60 秒甚至更短),意味著用戶端每分鐘都要喚醒網路模組、對每個節點發起一次 HTTP 請求。夜間待機時手機本該進入深度休眠,卻被這類定時探測反覆喚醒,累積下來是一筆不小的電量支出。

proxy-groups:
  - name: 自動選擇
    type: url-test
    proxies: [節點1, 節點2, 節點3]
    url: http://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

把 interval 調大到 300~600 秒,對絕大多數使用情境沒有明顯影響,卻能顯著減少夜間喚醒次數。如果策略群組裡節點數量多,探測是並發發起的,節點越多單次喚醒的耗時和耗電也越高,沒必要把訂閱裡幾十個節點全部塞進同一個自動測速群組,精簡到常用的 5~10 個足夠。

規則複雜度拖累 CPU:如何精簡

規則段的比對是按順序從上到下逐條比對的,規則條數越多、越靠後命中,單次連線建立時消耗的 CPU 週期就越長。一份幾千條規則的社群規則集,如果放在規則清單最前面且大量網域靠字串精確比對而非分類規則集(RULE-SET),每一次新連線都要跑一遍冗長的比對邏輯,長期高頻次建連(比如後台 App 保活、推播心跳)會讓 CPU 佔用曲線出現頻繁的小尖峰,這些尖峰疊加起來也是耗電的一部分。

精簡思路很直接:把命中率高的規則(比如直連的台灣本地網域、常用的分流網域)放在規則清單靠前位置,減少平均比對次數;盡量使用 RULE-SET 引用維護好的分類規則集而不是逐條堆砌單條網域規則;刪除明顯重複或已經被上層規則覆蓋的條目。規則集本身的載入和索引方式已經做了最佳化,比逐條明文規則效率更高,規則數量少一個量級,比對開銷也隨之下降。

可照做的省電設定清單

按下面的順序逐項過一遍,基本能把非用戶端本身導致的耗電異常排除掉:

1. 打開系統電池設定,把 Clash 用戶端加入後台運行白名單,取消所有廠商客製化的「智慧省電」「休眠最佳化」限制。
2. 檢查自啟動權限、關聯啟動權限是否被關閉,後台被凍結的程序即便加了白名單也可能無法自行喚醒。
3. 確認是否真的需要 TUN 模式;不需要全域分流時,改用應用層代理可以少一個常駐服務。
4. 打開設定檔,把 url-test 策略群組的 interval 調整到 300 秒以上,減少定時喚醒頻率。
5. 精簡自動測速群組裡的節點數量,只保留常用的幾個,減少單次探測的並發開銷。
6. 檢查規則段條數,優先使用 RULE-SET 引用規則集,把高命中率規則挪到清單靠前位置。
7. 對比開啟代理前後的待機掉電速度,如果差距仍在 10% 以上,再回頭逐項複查前面幾步是否生效。