Android Clash 背景耗電怎麼辦？電池最佳化白名單與背景執行設定

先分辨耗電偏高與背景執行遭終止

Android 代理用戶端長時間執行時，會處理經由 VPN 介面的封包、套用分流規則、查詢 DNS，並維持必要連線。耗電量與實際流量、網路品質、測速工作及核心設定有關；狀態列出現 VPN 圖示，不代表裝置一直處於高負載。

另一種狀況是鎖定螢幕後代理中斷，解鎖後才恢復。這通常應先檢查背景限制，而不是繼續降低測速頻率。將用戶端加入電池最佳化白名單，是為了提高背景執行的穩定性，不會直接降低耗電；允許持續執行後，系統統計的背景執行時間反而可能增加。

建立一組可重複檢查的待機測試

系統顯示的「應用程式耗電比例」不等於手機的電量下降百分比。例如手機總共耗電 10 個百分點，某應用程式占這段期間耗電量的 30%，不能解讀為它讓手機少了 30 個百分點的電量。部分系統也會將 VPN 轉送相關的網路活動計入代理應用程式，耗電歸因方式並不完全一致。

每次只調整一個項目

1. 在系統「設定」→「電池」→「耗電詳細資料」或「電池用量」中，記錄起始電量、用戶端背景執行時間和網路類型。
2. 使用相同的 Wi-Fi 和相近的起始電量，暫停系統更新、雲端相簿備份及大型檔案下載，鎖定螢幕觀察 60 分鐘。
3. 記錄結束電量、是否中斷連線、裝置是否發熱，以及用戶端傳送和接收的資料量。若用戶端沒有流量統計功能，可查看系統中的應用程式資料用量。
4. 每次只變更一項條件，例如將測速間隔從 60 秒改為 600 秒，再以相同方式觀察；至少重複兩輪，避免將短暫的網路波動誤當成結論。

此處的 60 分鐘是建議的測試時間，並非裝置實測結果。電量以整數顯示，短時間內可能看不出差異；若需要更長時間的觀察，可再進行一輪夜間待機測試。行動網路與 Wi-Fi 應分開比較；弱訊號下反覆重新連線造成的耗電，不能全歸因於代理核心。

測速間隔與健康檢查：先減少重複探測

手動點選一次「全部測速」通常只會執行一次工作；策略群組的自動探測和代理集合的健康檢查則可能定期執行。若訂閱同時包含多個 url-test、fallback 策略群組，以及啟用健康檢查的 proxy-providers，就要逐一確認探測範圍，不能只看介面上的單一開關。

從 60 秒調整為 600 秒代表什麼

假設一個策略群組有 30 個候選節點，每 60 秒檢查一輪，粗略以每個節點每輪探測一次計算，一小時約會探測 1800 次；改為 600 秒後，約為 180 次。這只是方便理解頻率的估算，實際次數仍會受延遲載入、逾時、連線重用及核心實作方式影響，不代表耗電量會按相同比例下降。

以下是 mihomo 代理集合的部分設定範例，只示範健康檢查參數，並非可直接匯入的完整訂閱：

health-check:
  enable: true
  url: https://www.gstatic.com/generate_204
  interval: 600
  timeout: 5000
  lazy: true

• interval: 600 的單位是秒；timeout: 5000 的單位是毫秒，請勿混淆。
• 未使用該代理集合時，lazy: true 可略過定期檢查；實際行為仍依目前的核心實作而定，不代表停止所有網路請求。
• 範例中的探測網址必須能透過目前的網路和代理出口連線。若長時間逾時，應檢查網址是否可連線，不要縮短間隔反覆重試。
• 對於可手動選擇節點的 select 群組，可先手動測速，再選定一個節點；缺點是發生故障時可能需要手動切換。

自動故障切換與降低探測頻率之間需要取捨。600 秒只是方便開始測試的參考值，不保證適用所有網路。訂閱管理工具也可能在更新時覆蓋本機變更，建議使用用戶端提供的覆寫或持久化設定功能，並在更新後確認實際生效的設定。

DNS、規則與記錄：檢查異常重試

DNS 查詢本身是正常的網路活動。真正需要排查的是同一個網域持續解析失敗、加密 DNS 無法建立連線，或 DNS 請求的連線出口又依賴尚未完成的解析，造成不斷重試。這時連線頁面可能反覆出現相同目標，記錄中也會持續出現逾時或解析失敗訊息。

依照以下順序檢查

1. 在用戶端的「記錄」頁面暫時將層級設為 info，觀察 1–2 分鐘，確認重複錯誤來自 DNS、節點連線還是健康檢查。
2. 檢查 DNS 上游位址、所選代理節點及相關路由是否可連線。若設定為透過代理傳送 DNS 請求，應先確認該代理能否成功建立連線。
3. 使用 mihomo 且啟用 respect-rules 時，請依照核心文件檢查 proxy-server-nameserver 的設定要求，避免代理節點網域的解析依賴代理本身。
4. 關閉持續輸出的 debug 記錄；完成問題定位後，可恢復用戶端預設層級，或在支援的情況下改用 warning。

不要為了省電而同時更改 DNS 模式、上游伺服器及整套規則，否則很難判斷是哪項設定有效。fake-ip 是 DNS 與連線對應機制，不是獨立的省電開關；redir-host 也不保證比它省電。請先使用用戶端支援的設定，再針對實際錯誤進行處理。

規則數量並非唯一指標。只因規則很多就刪除重要規則，可能會讓原本直連的大流量服務改走代理，反而增加處理負擔。依需求分流有助減少不必要的轉送，但調整後應確認應用程式實際使用的連線出口，不要只看規則名稱判斷。

電池最佳化白名單與各品牌的背景執行設定

只有確實需要在鎖定螢幕後持續連線時，才逐步放寬背景限制。建議先將用戶端的電池策略改為允許背景執行，再進行鎖定螢幕測試；若仍遭系統結束，再檢查自動啟動和最近使用的應用程式鎖定功能。以下列出常見設定位置；選單名稱會因系統版本、地區和機型而異，找不到時可在設定中搜尋「電池最佳化」、「自動啟動」或「背景活動」。

最近使用的應用程式畫面中的「鎖定」僅是輔助措施，不等於加入電池白名單，也無法解除所有系統限制。全域省電模式、超級省電模式、系統清理工具及背景資料限制仍可能影響 VPN 服務。請分別檢查，不要一次關閉整支手機的所有電池管理功能。

常駐通知、VPN 與 TUN 模式的差異

Android 用戶端通常透過系統 VpnService 建立虛擬網路介面，將符合條件的應用程式流量交由核心處理。這與桌面版透過系統代理位址連線的方式不同，不能將桌面版的「關閉 TUN、只開系統代理」直接套用到 Android。Android 的 VPN 圖示也不代表目前使用了某種遠端代理通訊協定。

保留服務通知，減少頻繁更新

持續執行的 VPN 服務通常會顯示前景服務通知。靜態通知本身並非主要耗電來源；每秒更新傳輸速率、持續計算統計資料或不斷輸出記錄，才是值得檢查的額外工作。若用戶端提供「即時流量」、「通知速率」或「更新間隔」選項，可先關閉即時速率，或將 1 秒更新改為 5 秒，再觀察差異。

不要用強制阻擋通知取代正常的背景設定。Android 13 及更新版本的通知權限、VPN 服務狀態與廠商的背景執行策略是不同設定，隱藏通知也不代表服務會停止。若要確認服務是否仍在執行，請查看用戶端的服務狀態及系統 VPN 頁面。

謹慎啟用「永遠開啟的 VPN」

部分系統可在「設定」→「網路和網際網路」→「VPN」→ 用戶端旁的設定按鈕中啟用「永遠開啟的 VPN」。這項功能是用來維持 VPN 使用策略，不是省電功能，也無法修復節點故障。「未連線 VPN 時封鎖連線」會在 VPN 無法使用時阻止相關網路連線，啟用前請確認能接受無法上網的情況。

此外，一般使用情況下通常只能有一個 VPN 服務同時啟用。本機 VPN 廣告過濾工具、封包擷取工具或其他 VPN 用戶端，可能會與代理用戶端互相取代。若服務反覆中斷，應先排除這類衝突，而不是繼續增加背景權限。

調整後的驗收與還原

建議依序處理：先排查異常流量和錯誤訊息，再減少重複測速與記錄造成的負擔，最後依鎖定螢幕後是否斷線設定背景執行。若目標是維持待機穩定，不能只看電量，也要確認重要應用程式能否及時連線。

• 待機：使用相同網路進行 60 分鐘比較，記錄起始和結束電量及流量；不要只比較系統中的應用程式耗電排名。
• 切換網路：從 Wi-Fi 切換到行動數據，再切回 Wi-Fi，確認用戶端能否恢復連線，以及記錄中是否持續出現錯誤。
• 鎖定螢幕：確認日常需要的訊息、同步或網頁連線是否正常；也請留意背景應用程式本身可能受到系統限制。
• 更新設定：更新訂閱後，重新確認健康檢查間隔、DNS 和記錄層級，並確認持久化覆寫仍然生效。
• 還原設定：若降低探測頻率導致故障切換太慢，請恢復較短的間隔；若加入白名單後穩定性沒有改善，請撤銷不必要的權限。

如果幾乎沒有網路流量時仍明顯發熱，請記下用戶端版本、核心版本、系統版本及短時間內的錯誤記錄，再向相關專案回報。公開記錄前，請刪除訂閱網址、權杖、節點憑證和個人瀏覽記錄。若想進一步了解設定匯入與基本操作，請參閱使用指南；常見連線問題可查看常見問題與故障排查說明。