耗電排查的基本思路:先分類,再定位
行動裝置回報的「耗電嚴重」很少是單一原因,通常是設定層、系統層兩類問題疊加的結果。設定層指的是 Clash 或 mihomo 核心本身的運作參數,比如規則集刷新頻率、日誌輸出等級、DNS 查詢方式;系統層指的是 Android 或 iOS 對背景程序的省電限制,以及應用程式被系統判定為「非活躍」後觸發的降頻、休眠策略。排查時建議按下面的順序逐層縮小範圍:
- 先確認是否只在鎖定畫面/背景時耗電異常,還是前景使用也偏高——前者多為系統排程問題,後者多為設定或代理連線問題。
- 查看核心日誌輸出量,判斷是否存在頻繁重新連線、DNS 逾時重試、規則命中失敗導致的循環請求。
- 檢查訂閱與規則集的自動更新週期,確認是否設定了過短的輪詢間隔。
- 確認系統電池管理裡客戶端是否被標記為「受限」而頻繁被喚醒重新連線。
下面各章節按這四個層面展開,給出具體的檢查方式與調整參數。
規則集與訂閱輪詢:更新週期設定不當是常見誘因
mihomo 核心支援在設定檔中為 rule-providers 設定獨立的 interval 欄位,單位為秒,用於控制該條規則集的自動拉取週期。部分客戶端圖形介面預設沿用設定檔裡寫死的間隔,如果訂閱作者將間隔設定為幾分鐘等級,手機會在鎖定畫面狀態下週期性喚醒網路模組發起 HTTP 請求,這是行動裝置耗電排查中最容易被忽略的一項。
rule-providers:
reject-list:
type: http
behavior: domain
url: "https://example.com/rules/reject.yaml"
path: ./rules/reject.yaml
interval: 86400
建議將非高頻變動的規則集(廣告封鎖、直連清單等)的 interval 調整到 43200 秒(12 小時)以上,僅對分流規則頻繁變化的場景保留較短週期。同理,訂閱本身的自動更新(profile 層面的 update-interval 或客戶端 GUI 裡的「自動更新訂閱」選項)也應避免設定為 1 小時以內,否則手機會在背景被反覆喚醒執行一次完整的下載、解析、重新載入設定流程,這個流程本身涉及磁碟寫入與核心重新啟動,單次耗電成本並不低。
日誌等級與 DNS 並發:設定檔裡容易被忽略的耗電開關
日誌等級設定為 debug 或 info 時,核心會對每一次連線建立、規則比對、DNS 解析都寫入日誌條目,持續的磁碟 I/O 與字串格式化操作會帶來額外的 CPU 佔用。行動裝置日常使用建議將日誌等級調整為 warning,只有在主動排查連線問題時才臨時切回 debug,排查完成後及時切回。
log-level: warning
DNS 部分同樣值得檢查。啟用 enhanced-mode: fake-ip 搭配多個 nameserver 並發查詢是常見設定,但如果同時設定了過多的上游 DNS(尤其是海外伺服器)且未設定合理的 fallback-filter,每一次網域名稱解析都會並發發出多組請求並等待逾時判定最佳結果,這在行動網路訊號不穩定的場景下會顯著增加無線模組的活躍時長。
dns:
enable: true
enhanced-mode: fake-ip
nameserver:
- 223.5.5.5
- 119.29.29.29
fallback:
- "tls://8.8.8.8:853"
fallback-filter:
geoip: true
geoip-code: CN
精簡 nameserver 清單到兩到三個回應穩定的伺服器,並讓 fallback 僅在明確判定為境外網域時啟用,可以減少不必要的並發解析請求。
如果設定中啟用了 TUN 模式並同時開啟了逐包路由日誌或連線追蹤功能,行動裝置 CPU 佔用會比單純的系統代理模式更高。非必要場景下,一般上網可優先使用系統代理模式,僅在需要透明代理全域流量或處理 UDP 轉發時才切換到 TUN 模式。
Android:電池最佳化白名單與背景自動啟動權限
Android 系統從 6.0 引入的 Doze 模式與各廠牌客製化系統(如基於深度客製化的省電管理框架)會對長期駐留背景且螢幕熄滅後仍保持網路連線的應用程式進行限制,具體表現為服務被系統主動終止後由 VPN 框架嘗試重新連線,重新連線過程會短時間內多次喚醒網路硬體,造成「看似耗電但實際是被反覆重新啟動」的情況。解決方式是將客戶端加入電池最佳化白名單,並保留必要的自動啟動權限:
-
開啟系統電池管理設定
進入「設定 → 電池 → 電池最佳化」或對應廠牌系統裡的「省電策略」頁面,找到 Clash 客戶端應用程式。
-
將應用程式設為不受限制
選擇「不最佳化」或「允許背景活動」,避免系統在鎖定畫面後主動掛起該程序的網路連線。
-
檢查自動啟動與關聯啟動權限
在應用程式權限管理裡確認「自動啟動」處於開啟狀態,部分系統還需要額外允許「關聯啟動」,否則 VPN 服務被系統回收後無法自行恢復,只能靠使用者手動重新開啟應用程式。
-
確認通知常駐權限未被關閉
VPN 服務依賴前景通知維持程序優先度,如果通知權限被系統或使用者手動關閉,服務的存活時間會明顯縮短,進而觸發更頻繁的重新連線循環。
需要說明的是,加入白名單本身不會增加耗電,它只是阻止系統頻繁終止並重新啟動程序。真正的耗電來源仍是前兩章提到的規則輪詢週期與 DNS 並發設定,白名單調整解決的是「連線不穩定導致的間接耗電」,兩者需要同時處理才能看到明顯效果。
iOS:隨需連線與 VPN 設定檔的省電設定
iOS 平台的網路擴充框架(NetworkExtension)對背景代理程序的限制更為嚴格,系統會根據裝置的電量狀態、網路類型、使用頻率動態調整擴充程序的排程優先度。客戶端在 iOS 上通常以 VPN 設定的形式接入系統,設定檔中的「隨需連線」(On-Demand)規則直接決定了 VPN 通道的建立時機,設定不當會導致通道在不必要的場景下反覆建立與中斷:
- 進入客戶端設定裡的 VPN 設定管理頁面,找到「隨需連線」或「On-Demand Rules」選項。
- 確認規則不是設定為「一律連線」,而是按網路類型區分:例如僅在使用行動數據或指定 Wi-Fi 名稱之外的網路時才自動建立通道。
- 如果設定了「排除特定 Wi-Fi 不連線」,檢查清單是否涵蓋了住家、辦公室等長期停留的可信網路,避免在這些場景下 VPN 通道無意義地保持建立狀態。
- 在系統設定的「VPN 與裝置管理」中確認對應設定檔狀態正常,異常狀態下系統會以更高頻率嘗試重新協商通道,同樣會增加耗電。
iOS 上的網路擴充程序被系統掛起後無法像一般應用程式一樣保持背景活躍,規則集與訂閱的自動更新在擴充程序休眠期間不會執行,這是設計上的限制而非故障,不需要額外排查。真正需要關注的是通道建立頻率,而不是擴充程序是否「一直在跑」。
此外,iOS 上開啟的日誌等級同樣建議保持在較低檔位,原因與 Android、桌面端一致:擴充程序一旦被喚醒執行高頻日誌寫入,會延長該次喚醒的持續時間,間接影響系統對該擴充程序排程優先度的判定。
長期監控:借助面板工具持續觀察耗電趨勢
完成以上調整後,建議用客戶端內建的連線面板或流量統計功能觀察一段時間的運作狀態,而不是僅憑主觀感受判斷是否解決問題。重點關注三個指標:活躍連線數是否在鎖定畫面後仍持續增長、DNS 查詢次數是否明顯高於正常上網所需的數量級、規則集重新載入事件在日誌裡出現的頻率。如果活躍連線數在鎖定畫面後沒有明顯下降,通常說明存在背景應用程式持續發起網路請求的情況,這類問題的根源往往在系統層的其他應用程式而非 Clash 本身,可以透過臨時開啟分應用程式模式排查具體是哪個應用程式在鎖定畫面後仍保持活躍連線。
耗電問題的排查本質是一次逐層排除,設定層的規則輪詢週期、日誌等級、DNS 並發設定決定了核心本身的基礎負載,系統層的電池最佳化白名單與隨需連線規則決定了背景存活方式是否高效。兩者任一環節設定不當都會在續航表現上被放大,建議按本文順序逐一核對,而不是只調整其中一項後就下結論。