Clash Meta Android 耗電高？背景執行與電池最佳化設定排查

一、釐清 VPN 常駐、耗電歸屬與異常耗電

Android 狀態列出現 VPN 圖示，只代表系統已建立 VPN 介面，不表示 CPU 一直滿載。使用 Clash Meta 或其他搭載 mihomo 核心的 Android 用戶端時，前景服務通知通常是用來維持代理服務；隱藏通知也不會讓流量轉送自動停止。判斷耗電情況時，應查看同一時段的電量變化、實際流量與記錄，而不是只看通知是否常駐。

Android 電池用量統計也可能將部分經 VPN 轉送的網路耗電計入 VPN 應用程式。不同系統版本與品牌的統計方式並不一致，因此「用戶端在應用程式耗電排行第一」不能單獨證明核心異常。背景照片上傳、影片預載與系統更新，都可能在用戶端的連線清單中顯示為持續流量。

先記下這四項資訊

系統與核心：在「設定」→「關於手機」查看 Android 版本；在用戶端的「關於」或核心資訊頁面記下用戶端版本與 mihomo 版本。兩者不是同一個版本號。
耗電時間範圍：在「設定」→「電池」→「電池用量」查看統計區間，避免把充電前後的資料混在一起。
網路狀態：記下使用 Wi-Fi 或行動網路、訊號強弱，以及是否頻繁切換基地台。訊號微弱時的無線通訊耗電可能高於代理處理本身。
運作狀況：分辨是否持續發熱、螢幕關閉後斷線、切換網路後重新連線，或只有開啟記錄頁面時耗電增加。

二、用固定時間範圍建立耗電比較

不要同時修改背景權限、DNS 與代理節點。每輪只調整一個條件，才能找出差異來源。建議使用訊號穩定的同一個 Wi-Fi，暫停正在下載的應用程式，並維持相同的螢幕亮度與測試時間。以下時間是排查用的測試區間，不是裝置實測結果，也不是通用的正常耗電標準。

測試階段	操作與時間	記錄項目
系統基準	停止代理服務，關閉螢幕靜置 60 分鐘	開始與結束電量、網路類型、是否有背景工作
代理閒置	啟用原有設定，關閉螢幕靜置 60 分鐘	開始與結束電量、總流量、重新連線次數
固定負載	以相同畫質播放同一部影片 30 分鐘	是否發熱、連線是否穩定、用戶端流量
單項複測	只調整一項設定，重複對應階段	設定變更、異常記錄是否消失

電量百分比是粗略讀數。單次測試只差 1 個百分點，不足以判定設定有效；可在條件相近時再測兩輪。測試期間不要充電，也不要開啟螢幕錄影。停止代理後，如果系統啟用了「無 VPN 時封鎖連線」，應先記下設定並暫時關閉，否則基準階段可能完全無法連網，不能直接與正常連網狀態比較。

從連線清單找出背景流量來源

開啟用戶端的「連線」頁面，觀察關閉螢幕前仍持續增加流量的連線。優先暫停雲端硬碟同步、照片備份與應用程式商店更新，再重新測試。有些用戶端會顯示應用程式名稱，有些只顯示目標網域或 IP；不能只憑共用的 CDN 網域判定是哪個應用程式。若閒置時幾乎沒有流量卻持續發熱，再檢查錯誤重試、速度測試工作與記錄。

三、電池最佳化白名單：解決斷線，不是直接省電

將用戶端設為「不受限制」，主要是減少系統在背景凍結或終止代理服務的情況。這不保證能降低耗電，反而可能讓背景應用程式持續連網。只有出現關閉螢幕後服務消失、通知反覆重新建立，或重新亮屏後大量重新連線時，才應優先檢查背景限制。

各品牌選單會因系統版本與地區而異。以下列出常見路徑；找不到時，可在系統設定中搜尋「電池最佳化」、「背景活動」或「自動啟動」。從桌面長按用戶端圖示進入「應用程式資訊」，通常是最穩定的入口。

系統或品牌	常見設定路徑	排查重點
Pixel／接近原生 Android	「設定」→「應用程式」→ 用戶端 →「應用程式電池用量」→ 允許背景使用；部分版本可選「不受限制」	Android 版本不同，選項名稱可能是「電池」或「背景使用」
小米／Redmi	「設定」→「應用程式設定」→「應用程式管理」→ 用戶端 →「省電策略」→「無限制」	另外檢查「背景自動啟動」；將應用程式鎖定在最近使用的應用程式中，不能取代電池策略
華為／榮耀	「設定」→「應用程式和服務」或「應用程式」→「應用程式啟動管理」→ 用戶端 → 關閉自動管理	視需要允許自動啟動、關聯啟動與背景活動；部分榮耀機型的選項名稱不同
OPPO／一加／realme	長按圖示 →「應用程式資訊」→「耗電管理」或「電池耗電管理」→ 允許背景活動	若需要在重新開機後自動恢復，再檢查自動啟動管理
vivo / iQOO	「設定」→「電池」→「背景耗電管理」→ 用戶端 → 允許背景高耗電	同時查看「應用程式」→「權限管理」中的自動啟動選項
Samsung One UI	「設定」→「應用程式」→ 用戶端 →「電池」→「不受限制」	在「電池」→「背景使用限制」中，確認用戶端是否被加入「深度休眠應用程式」

分別檢查常駐 VPN 與背景權限

原生 Android 常見路徑為「設定」→「網路和網際網路」→「VPN」→ 用戶端旁的設定按鈕。「一律開啟 VPN」用於維持指定 VPN；「無 VPN 時封鎖連線」則會限制未經 VPN 的連線。這些不是省電開關，也不能用來修復失效的訂閱。若用戶端不支援相關功能，選項可能無法使用。

先確認用戶端在一般背景策略下能穩定執行，再決定是否需要一律開啟 VPN。不要把所有應用程式都加入電池白名單；只允許確實需要持續執行的用戶端不受限制。修改後先測試關閉螢幕 60 分鐘，再確認從 Wi-Fi 切換至行動網路後能否恢復。

四、檢查 TUN、應用程式分流與重新連線循環

Android 用戶端通常透過 Android VPNService 接管系統流量；這與桌面用戶端透過系統權限建立 TUN 裝置的方式不同。介面上的「TUN」、「VPN 模式」或「網路堆疊」可能是用戶端自行定義的名稱。不能直接套用 Windows 的服務模式設定，也不能假設每款 Android 用戶端都能在 system、gvisor、mixed 之間切換。

先縮小流量接管範圍，再比較網路堆疊

如果用戶端支援應用程式分流，可建立只包含瀏覽器與必要應用程式的測試範圍，比較閒置流量是否減少。不要同時啟用多個 VPN 類應用程式；本機封包擷取、防火牆與廣告封鎖工具也可能占用 VPN 連線。
在規則模式下，DIRECT 表示使用直連出站，不一定代表該連線未經 VPN 介面。若要排除特定應用程式，請檢查用戶端是否有應用程式略過功能，而不只是新增直連規則。
如果網路切換後記錄持續出現逾時，先改用已確認可連線的節點，再觀察同一個目標是否恢復。失效節點與無法連線的 DNS 都可能造成反覆嘗試。
只有用戶端明確提供網路堆疊選項時，才逐一比較相容性。沒有任何一種網路堆疊能保證適用所有手機且耗電最低；切換後應同時確認網頁、即時通訊、UDP 服務與休眠後恢復狀況。

不要為了降低統計數字而關閉 VPN，卻仍以為所有應用程式都在使用代理。HTTP 混合連接埠，例如 7890，只是本機監聽連接埠；Android 應用程式不會因為該連接埠存在就自動使用它。必須由應用程式明確設定代理，或由用戶端接管系統流量。

五、DNS、網域嗅探與健康檢查的背景耗用

DNS 要求失敗後反覆重試，比單純啟用 DNS 功能更值得注意。在用戶端記錄中搜尋 timeout、DNS、network is unreachable，確認閒置時是否仍持續出現錯誤。先確認手機時間正確，且網路可連線至設定中的解析器，再決定是否調整 DNS。

fake-ip 不是獨立的省電開關

enhanced-mode: fake-ip 會透過虛擬位址保留網域對應，方便規則比對；這不表示每個要求都會傳送至遠端伺服器。也不能只看 redir-host 這個名稱，就判定它更省電。任意切換模式可能影響區域網路裝置探索，或依賴實際解析結果的應用程式；應將這類情況視為相容性問題處理。

以下僅為欄位示意，並非完整的訂閱設定。223.5.5.5 是明文 DNS 範例；其查詢可見性與加密 DNS 不同，也不保證所有網路都能連線。現有設定若使用 nameserver-policy、proxy-server-nameserver 或加密 DNS，請保留相關解析依賴，不要整段取代。

DNS 欄位示意

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5

降低不必要的速度測試頻率

健康檢查：檢查 proxy-providers 中的 health-check.interval，以及 url-test、fallback 群組的 interval。這些間隔通常以秒為單位。若目前設定為 60 秒，可在穩定性允許時改為 600 秒進行比較；不要把訂閱更新間隔和速度測試間隔混為一談。
節點數量：100 個節點每 60 秒全面檢查一次，理論上每分鐘約會產生 100 次探測；實際數量也會受到按需檢查與使用情況影響。減少參與測試的節點，比反覆手動「全部測速」更容易控制背景要求。
網域嗅探：如果目前的規則不需要透過嗅探補全網域，可暫時關閉用戶端的嗅探功能並重新測試。依賴網域還原的規則可能因此改變比對結果，不能只看耗電而不確認分流是否正常。
記錄層級：排查完成後，將 log-level 從 debug 改回 info 或 warning，並關閉持續更新的記錄頁面。不要把螢幕持續亮著的監控狀態當成日常關閉螢幕時的耗電情況。

六、依症狀逐步調整設定，保留可重現的結果

症狀	優先檢查	重新測試方式
關閉螢幕後斷線，亮屏後恢復	電池最佳化、背景活動權限、深度休眠清單	允許背景執行後關閉螢幕 60 分鐘，確認通知與連線是否恢復
閒置時仍持續有流量	背景同步、節點健康檢查、應用程式更新	暫停單一來源，觀察連線清單是否停止增加
切換網路後發熱	節點連線狀態、DNS 逾時、反覆重新連線	固定使用 Wi-Fi，再單獨測試一次網路切換
只有使用行動網路時耗電較高	訊號強度、頻繁切換網路、行動數據傳輸	在同一地點與 Wi-Fi 比較，避免直接歸因於核心
只有查看記錄時耗電較高	除錯記錄、介面更新、螢幕亮度	恢復一般記錄層級，關閉頁面後重新測試

合理的完成條件是：背景連線穩定、閒置流量來源明確、錯誤記錄不再反覆出現，而且在相同條件下可重複觀察到耗電差異。不要追求適用所有機型的固定百分比，也不要為了維持背景執行而一次關閉所有省電限制。

若問題仍未解決，請整理手機型號、Android 版本、用戶端與 mihomo 版本、使用的網路、測試時間，以及已遮蔽敏感資訊的錯誤片段。說明問題是否只在特定訂閱設定下發生，以及更換節點後是否恢復。這些資訊有助於區分用戶端、規則設定與網路環境問題。基本設定方式請參閱入門指南；連線與 DNS 的進一步排查，請參閱故障排除。