Android 手機開代理很耗電？Clash 背景執行、省電白名單與設定調整

先分辨：正常轉送耗電，還是背景反覆重新啟動

先在相同條件下比較，再調整電池白名單。手機開啟代理後，多了一層流量轉送、加解密與規則比對，耗電增加並不意外。不過，螢幕關閉後仍持續發熱、每隔幾分鐘就有服務重新啟動，或行動網路待機耗電明顯加快，就值得進一步排查。一次解除所有限制或許能改善斷線，但無法直接證明耗電原因已經排除。

Android 上的 Clash 用戶端通常透過 VpnService 建立本機 VPN 介面，再將選定應用程式的流量交由核心處理。這和購買遠端 VPN 服務是不同概念；通知列出現鑰匙圖示，也不代表所有連線都經過遠端代理節點。規則符合 DIRECT 的連線仍可能經過本機轉送，只是不會經過遠端節點。

用兩組待機紀錄建立基準

不要用「昨天開代理、今天沒開代理」的整日電量變化下結論。應用程式更新、訊號變化與螢幕亮度都會影響結果。先完成以下短時間對照，再決定是否延長測試。

1. 記錄環境：記下手機型號、Android 版本、用戶端與核心版本、Wi-Fi 或行動網路，以及開始與結束時的電量。通常可在用戶端的「關於」頁面查看版本。
2. 固定條件：使用同一個 Wi-Fi、相同位置與相近電量區間；暫停系統更新、雲端相簿備份與大型檔案下載，測試期間不要充電。
3. 第一組：關閉代理：確認 VPN 服務已停止，關閉螢幕待機 60 分鐘，記錄電量與背景網路活動。
4. 第二組：開啟代理：維持相同的應用程式狀態，選定固定節點與規則模式，再待機 60 分鐘。不要同時執行「全部測速」。
5. 每次只改一項，再重新測試：例如先延長健康檢查間隔，其他設定維持不變；至少重複測試一次，避免把系統電量四捨五入的誤差當成最佳化成果。

例如，關閉代理時電量從 80% 降至 79%，開啟代理時從 80% 降至 77%，只能說這兩次測試相差 2 個百分點，不能據此推算所有手機一整天的耗電量。這只是紀錄格式範例，並非用戶端實測數據。如果一小時內的差異太小，可以延長至 3 小時；行動網路訊號較差時，應另做一組測試，不要和 Wi-Fi 數據混在一起比較。

背景持續執行：視需要加入電池最佳化例外清單

例外清單是用來減少背景程序遭終止，不是省電開關。只有遇到螢幕關閉後斷線、服務遭清理或反覆啟動時，才優先調整這項設定。持續顯示通知本身不代表用戶端一直處於高負載；更應觀察核心是否反覆初始化、連線是否頻繁重建。

Android 14 參考設定路徑

以接近原生介面的 Android 14 為例，可前往「設定」→「應用程式」→「查看所有應用程式」→選取 Clash 用戶端→「應用程式電池用量」，確認是否設為「受限制」。需要持續代理時，可測試「不受限制」。不同系統版本的名稱可能是「允許背景使用」等，請以裝置上的實際畫面為準。

• 廠牌電池管理：在系統設定中搜尋「電池最佳化」、「背景活動」或「自動啟動」。若系統另有應用程式啟動管理，只授權需要長時間代理的用戶端即可，不必解除所有應用程式的限制。
• 鎖定最近使用的應用程式：部分系統可鎖定應用程式卡片，避免手動清理時誤關，但這並非 Android 通用的背景執行保證，也不能取代電池設定。
• 通知與服務狀態：保留用戶端執行狀態的可見資訊。Android 13 以上版本的通知權限與前景服務執行狀態是不同設定，不能只因通知消失就判定 VPN 已停止。
• 省電模式：先確認問題是否只在系統省電模式開啟時發生。測試期間請維持相同設定，不要一組開啟、一組關閉。

確認「一律使用 VPN」是否符合需求

原生介面的系統通常可在「設定」→「網路與網際網路」→「VPN」→相應設定旁的齒輪圖示找到相關選項。若用戶端支援，畫面上會有「一律使用 VPN」及「封鎖未使用 VPN 的連線」。後者會在 VPN 無法使用時封鎖網路；它不是用來提升節點穩定性的選項。啟用前先了解斷線後的行為，避免把系統依設計封鎖流量誤判為 DNS 故障。

Android 通常只允許每位使用者或工作資料夾同時執行一個以 VpnService 為基礎的服務。啟動另一個 VPN 型防火牆、過濾器或代理應用程式時，可能會取代目前的服務。如果遇到連線反覆中斷，應先確認是否有這類服務互相衝突，而不是繼續增加背景執行權限。

健康檢查：先降低探測頻率，再考慮更換節點

節點檢查會發出實際網路請求。節點數量多、檢查間隔又很短時，可能增加無線網路喚醒與連線活動。尤其在行動網路下，頻繁發出短請求可能讓無線模組維持較長時間的活躍狀態；實際影響取決於網路與裝置，不能只看每次請求傳輸的資料量。

在 mihomo 中，代理提供者的健康檢查設定位於 proxy-providers 底下的 health-check。以下是既有提供者定義中的局部片段，並非完整設定；mobile-pool 必須換成既有的提供者名稱，並保留原有的類型、位址、路徑等欄位。

proxy-providers:
  mobile-pool:
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600
      lazy: true

• interval: 600：健康檢查間隔為 600 秒。可先從 300～600 秒開始觀察，不必為了顯示最新延遲而每隔幾十秒檢查一次。
• lazy: true：提供者節點未被使用時，略過定期檢查。節點是否會被視為正在使用，取決於策略群組引用方式與使用狀態。
• url：請選擇目前網路可連線、節點可達且回應資料量小的測試網址。網址無法連線會造成誤判，不能靠縮短間隔補救。

估算一下數量級：如果每輪檢查 50 個節點、間隔 60 秒，理論上每小時最多會安排約 3000 次節點探測；間隔改為 600 秒，則約為 300 次。這個估算不代表實際耗電量會按比例變化，也未納入延遲檢查、逾時與其他策略群組的檢查，但有助於找出設定中重複執行的工作。

也要檢查 url-test、fallback 等策略群組本身的 interval，以及用戶端是否啟用了自動批次測速。提供者檢查與策略群組檢查可能同時執行。proxy-providers 的 interval 是訂閱內容更新間隔；這裡要調整的健康檢查間隔則是 health-check.interval，請勿改錯層級。

DNS 與連線重試：找出持續請求的根本原因

DNS 上游不是愈多就愈穩定。某個上游長期無法連線，或解析請求依賴尚未完成解析的代理連線，都可能讓應用程式不斷重試。若記錄中持續出現 i/o timeout、context deadline exceeded，先記下對應的網域、目標位址與時間；這些錯誤也可能來自連線或探測，不能只憑錯誤訊息就判定是 DNS 問題。

1. 確認只保留一條預期的連線路徑：檢查用戶端 DNS、Android「私人 DNS」以及其他過濾應用程式。原生系統可從「設定」→「網路與網際網路」→「私人 DNS」進入。不要一次修改這三處設定。
2. 短時間測試私人 DNS：如果設定了自訂服務提供者主機名稱，先記下原設定，再暫時切換為「自動」，確認是否與目前的 VPN 連線路徑衝突。測試結束後依實際需求還原。
3. 檢查 mihomo 欄位：dns.nameserver 是預設 DNS 上游；dns.proxy-server-nameserver 用於解析代理節點網域。是否使用後者，應依現有設定與核心文件判斷，不要未經確認就一併加上。
4. 找出重複請求來源：如果同一個應用程式不斷存取失敗的網域，先檢查它實際命中的規則、節點出口與解析結果，不要一再清除快取。

fake-ip 與 redir-host 是 DNS 處理模式，不是省電等級。切換模式可能影響應用程式相容性與快取行為，但不保證能降低耗電。現有網站都能正常存取時，不應只為省電就大幅修改 DNS；應優先排除明確的逾時與重複請求。

規則、TUN 與記錄：減少不必要的處理

規則模式不代表流量會繞過本機 VPN

mode: rule 會依規則選擇連線出口；DIRECT 只表示不經過遠端代理節點。如果應用程式流量已進入 Android 本機 VPN，仍可能交由核心處理。因此，不能保證「切回規則模式就不耗電」。不過，與不必要地將所有流量送往遠端相比，合理使用直連可減少額外的網路路徑與部分加密作業。

如果用戶端提供「分應用程式代理」或「排除應用程式」功能，可依需求縮小接管範圍。但請先確認頁面採用的是允許清單還是排除清單，兩者意思相反。將應用程式排除後，它的網路連線通常不再受這組代理規則控制，調整前應先評估連線需求。

不要套用桌面版 TUN 的省電做法

手機本來就常透過 VPN 介面接管流量，不應直接把桌面上的「關閉 TUN，只開系統代理」當成 Android 通用替代方案。是否支援其他運作模式，取決於個別用戶端。tun.stack 的可選值與實際表現也受核心和整合方式影響，不要只看名稱就選用；應在相同網路與工作負載下測試相容性與耗電情況。

排查完成後，恢復一般記錄等級

長時間保留詳細記錄會增加處理與儲存負擔。定位問題時可短暫啟用詳細記錄，重現問題後匯出必要片段，再將有效設定中的 log-level 恢復為 info 或用戶端原本的等級。待機測試時，不要在背景持續開啟即時連線更新、循環測速或自動捲動的記錄頁面。

調整後的驗收順序

建議依照以下順序完成檢查。目標是同時確認背景執行穩定、網路連線正常，且待機耗電量可以接受，而不是只讓電池用量排行上的某個數字變小。

1. 先確認背景執行：關閉螢幕 30 分鐘後再亮起，檢查 VPN 服務是否仍在執行、網路能否正常恢復，以及記錄中是否出現反覆啟動。
2. 接著確認設定：確認健康檢查間隔已套用至最終設定、自動批次測速沒有再次啟動，且更新訂閱後修改仍然保留。
3. 重新測量電量：依照前述相同條件測試 60 分鐘，記錄電量下降與異常連線；結果波動較大時，應延長測試時間，而不是繼續堆疊參數。
4. 最後恢復日常設定：關閉臨時啟用的詳細記錄，撤銷不再需要的測試權限，只保留確實有助於背景穩定執行的設定。

如果行動網路比 Wi-Fi 明顯耗電，先檢查訊號品質與節點路徑；如果只有某個節點持續逾時，固定切換至可用節點後再測試。如果更換用戶端後問題仍然存在，也應回頭檢查系統網路與背景應用程式，不要直接歸咎於某個核心。

需要重新確認匯入流程，可查看使用指南；遇到覆寫未生效、DNS 逾時或規則出口不如預期，再前往進階設定逐項確認。分享記錄前，請刪除訂閱網址、存取權杖、節點密碼與個人連線紀錄。