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

Android 上的 Clash 類用戶端需要持續處理接管的網路連線。如果耗電排名偏高、鎖定螢幕後斷線或手機發熱，請先分辨三種情況：實際處理流量所耗的電力、系統如何歸算 VPN 流量，以及背景服務遭到終止後不斷重新連線。這些情況的處理方式不同，只關閉通知或全面放寬背景權限，通常無法找出真正原因。

先查看耗電統計，再進行同條件比較

前往「設定」→「電池」→「電池用量」，找出目前使用的代理用戶端。部分系統會將此項目稱為「耗電排行」。記下統計的起訖時間、前景與背景執行時間、電量變化，以及當時使用 Wi-Fi 或行動網路。用戶端佔「本週期耗電量的 30%」，不代表消耗了整顆電池容量的 30%。

VPN 會轉送其他應用程式的流量。不同 Android 版本和手機廠商的流量、耗電歸算方式各不相同，因此用戶端排名偏高只能做為線索，不能直接證明核心持續處於高負載。下載大型檔案、上傳雲端相簿或播放影片，都可能讓排名上升。

進行兩輪鎖定螢幕測試，建立基準

1. 暫停下載、影片播放和系統更新，選擇訊號穩定的同一個 Wi-Fi 網路，讓裝置維持相近溫度，測試時不要充電。
2. 啟動用戶端，固定使用一個可連線的節點，鎖定螢幕 60 分鐘。記錄開始與結束時的電量、有無斷線、用戶端流量增幅，以及日誌中的錯誤。
3. 在相近條件下停止用戶端，再鎖定螢幕 60 分鐘。兩輪測試期間，盡量讓其他應用程式和同步工作維持一致。
4. 如果差異只有 1 個百分點，請延長觀察時間並再測一輪。電量百分比是粗略讀值，短時間內的差異不足以做出結論。

例如，記錄表可以寫成「代理開啟：82% → 79%；代理關閉：81% → 79%」。這只是記錄格式範例，不代表實際裝置測試結果或合格標準。應持續追蹤的是多次重現的額外耗電，以及是否同時出現重新連線、逾時或異常流量。

VPN 常駐通知與背景服務各自負責什麼

Android 通常透過 VpnService 建立虛擬網路介面來接管 VPN 連線。持續執行的 VPN 服務一般需要使用前景服務機制，並向系統顯示通知。通知本身通常不是主要耗電來源；實際耗電來自資料處理、加解密、喚醒網路，以及重試連線。

• 狀態列 VPN 圖示：代表系統目前有 VPN 連線，不表示目前使用的節點一定可用。
• 用戶端服務通知：可顯示執行狀態、傳輸速率或中斷連線按鈕。如果速率更新太頻繁，且用戶端支援相關設定，可降低更新頻率。
• 背景執行權限：決定服務離開前景後能否繼續運作，與是否顯示通知是兩種不同的設定。

Android 13 以上版本提供通知執行階段權限，但前景服務的系統要求並未因此取消。關閉應用程式通知不是省電方法，也無法確保服務運作更穩定。排查期間建議保留服務狀態通知，方便確認鎖定螢幕後服務是否仍在執行。

「一律開啟 VPN」不是萬用的背景保活開關

常見路徑為「設定」→「網路和網際網路」→「VPN」→點選對應用戶端旁的設定按鈕。系統可能提供「一律開啟 VPN」和「封鎖未使用 VPN 的連線」選項。前者用於維持 VPN 使用狀態；後者會在 VPN 無法使用時封鎖網路連線。兩者都無法修復無法連線的節點或錯誤的 DNS 設定。

電池最佳化白名單：只將目前使用的用戶端加入

電池最佳化白名單是用來解除背景限制，並非直接降低耗電。合理的目標是避免服務遭到終止後不斷重新建立連線，而不是讓應用程式長時間喚醒 CPU。只有在鎖定螢幕後斷線、服務消失或系統明確提示背景執行受限時，才逐項調整並重新測試。

原生 Android 與 Pixel 常見設定路徑

1. 長按用戶端圖示，前往「應用程式資訊」→「應用程式電池用量」，允許背景使用；若有「不受限制」選項，可用來確認問題是否由背景限制造成。
2. 部分較舊系統的路徑為「設定」→「應用程式」→「特殊應用程式存取權」→「電池最佳化」，切換至「所有應用程式」，找出用戶端並選擇「不進行最佳化」。
3. 返回主畫面後啟用代理，鎖定螢幕觀察 15 分鐘，再解鎖確認服務是否持續執行，以及應用程式能否建立新連線。

不同 Android 版本可能只提供其中一種設定路徑，不必為了找齊選單而重複修改。如果設為不受限制後仍然斷線，應改查節點、網路和日誌，而不是繼續把所有應用程式都加入白名單。

手機廠商系統還需要檢查的項目

這些設定路徑可能會隨系統更新而改名，建議優先使用系統設定搜尋，不要照著其他品牌的截圖尋找完全相同的按鈕。最近使用的應用程式畫面中的「鎖定應用程式」，有時只能防止一鍵清除，無法取代電池最佳化設定。允許自動啟動不代表用戶端已啟用「開機啟動」；如果需要重新開機後連線，還要確認用戶端本身是否提供這項功能。

鎖定螢幕後斷線且耗電增加：先檢查是否不斷重連

如果服務仍在執行，但連線持續失敗，放寬背景權限可能只會讓失敗重試持續更久。開啟用戶端的「日誌」頁面，先使用 info 層級，並記錄鎖定螢幕前後的時間。留意反覆出現的逾時、網域解析失敗、連線重設，以及核心重新啟動等紀錄。

• 服務重新啟動：鎖定螢幕後通知消失，解鎖後又出現啟動訊息，應優先檢查背景限制和用戶端是否當機。
• 節點逾時：服務並未停止，但同一個節點不斷連線失敗。改用另一個已確認可用的節點，再以相同條件測試。
• 網路切換：從 Wi-Fi 切換至行動網路時中斷，應優先檢查系統切換網路、訊號微弱和隧道重建等問題，不要直接歸因於電池最佳化。
• 特定應用程式重試：只有某個同步應用程式持續建立連線，請檢查該應用程式的背景上傳和流量規則。

診斷期間先固定使用一個節點，減少自動切換帶來的變因。如果設定會對大量節點進行健康檢查，檢查間隔過短也會增加背景請求。例如，100 個節點每 30 秒各測試一次，理論上每小時約會發出 12,000 次測試請求；實際次數則取決於用戶端、延遲載入方式，以及策略群組是否正在使用。

支援相關設定的用戶端，可考慮將不必要的高頻檢查間隔調整為 300 或 600 秒，再確認切換體驗。這並不代表所有用戶端都提供相同的選單選項。訂閱託管的設定更新後可能會覆蓋本機修改；若要持續套用調整，請使用用戶端支援的覆寫功能。

TUN 與 DNS：減少重複接管和解析重試

Android VPN 接管不等於桌面版的 TUN 開關

桌面教學常會比較「系統代理」和「TUN 模式」這兩種設定；Android 用戶端通常已透過 VPN 介面接管流量。部分以 mihomo 為核心的用戶端還會提供 TUN 協定堆疊或相關選項，實際行為則取決於用戶端的實作方式。不能直接套用「關閉 TUN 就能省電」的結論，否則可能連代理接管也一起停止。

• 先保留用戶端的預設協定堆疊；只有在日誌和專案文件指出相容性問題時，才另外切換測試。
• 檢查是否同時啟用了其他本機 VPN、防火牆或網路過濾工具。一般個人設定通常無法同時維持兩個透過 VpnService 運作的 VPN。
• 如果用戶端支援依應用程式接管流量，可讓確定不需要代理的高流量應用程式排除在外；修改後請確認該應用程式的直連行為符合預期。

比起 DNS 解析模式名稱，應先檢查逾時問題

Fake-IP 會先回傳用於對應的虛擬位址；Redir-Host 則涉及真實位址解析。兩者主要差異在於解析和連線的處理路徑，不能只看模式名稱就判斷哪一種一定比較省電。真正需要處理的是上游 DNS 無法連線、加密 DNS 反覆無法建立連線，或解析請求在代理和解析器之間形成依賴循環。

1. 檢查日誌中是否持續出現 DNS timeout 或解析失敗，並確認失敗網域是否來自同一個背景應用程式。
2. 檢查「設定」→「網路和網際網路」→「私人 DNS」。如果設定了自訂主機名稱，可暫時切換至「自動」進行比較，測試後再視需要恢復原設定。
3. 確認用戶端使用的 DNS 上游可透過目前網路連線；如果上游使用網域名稱，還需要可用的引導解析路徑，避免解析器依賴尚未建立的代理連線。
4. 每次只修改一個項目，並重新測試鎖定螢幕和首次開啟網頁的情況。不要同時更換 DNS、節點和規則，否則無法判斷是哪項設定生效。

私人 DNS 和用戶端 DNS 的實際互動方式取決於系統版本和流量接管方式，不能假設其中一方一定會覆蓋另一方。排查完成後，請將暫時使用的 debug 日誌層級恢復為日常設定，並關閉持續更新的連線監控頁面，避免診斷工具本身增加系統負載。

整理穩定的背景執行設定

完成上述測試後，只保留最少且有效的調整。日常設定可從「只使用一個 VPN 接管、選擇可用節點、以正常間隔進行健康檢查、使用可連線的 DNS，並只為用戶端授予必要的背景權限」開始，再依需求增加功能。不要為了背景保活安裝會持續喚醒 CPU 的輔助工具，也不要為了省電反覆強制停止服務。

修改後的確認清單

1. 鎖定螢幕後恢復：先鎖定螢幕 15 分鐘快速檢查，再觀察 1 小時；解鎖後開啟新的網頁，不要只查看已開啟的頁面。
2. 切換網路：從 Wi-Fi 切換至行動網路，再切換回來，確認能重新建立連線，且日誌沒有長時間連續逾時。
3. 背景訊息：使用實際需要的通訊應用程式確認能否收到訊息，並區分應用程式本身的背景限制和 VPN 中斷。
4. 重新測量耗電：依照第一節的相同條件記錄耗電情況，至少重複兩輪，不要只憑一次短時間測試判斷最佳化成效。
5. 重新開機檢查：如果需要開機後自動連線，請重新啟動並解鎖裝置，檢查用戶端設定、系統 VPN 狀態和實際連線結果。

如果用戶端服務穩定、日誌正常，但行動網路耗電明顯高於 Wi-Fi，應繼續檢查訊號強度、5G 網路切換和上游線路品質。如果停止代理後仍持續發熱，請回到系統電池頁面，檢查其他應用程式和硬體狀態。分開確認代理耗電和整部裝置的耗電，才能避免反覆調整無關設定。