手機 Clash 耗電快？Android 背景執行與省電設定指南

先釐清是持續耗電還是背景斷線

先做兩件事：查看系統電池用量統計，並記錄鎖定螢幕後的連線狀況。持續發熱、背景數據用量增加，以及鎖定螢幕後代理連線中斷，是不同問題。前兩種情況需要減少實際網路活動；只有後者才需要檢查背景執行限制。直接關閉所有省電限制，或許能恢復連線，卻也可能讓原本頻繁的節點測速繼續耗電。

Android 行動版用戶端通常透過系統 VPN 介面接管流量，由 mihomo 等核心解析設定檔、比對規則並處理連線。iOS 用戶端通常使用 Network Extension 的隧道擴充功能。VPN 圖示只表示隧道已連線，不代表手機一直處於高負載，也無法單憑圖示判斷耗電原因。

建立可重複檢查的基準

1. 記下手機型號、作業系統版本、用戶端版本與核心版本。核心資訊通常可在用戶端的「關於」頁面或執行記錄中找到，選單名稱依實際 App 而異。
2. 固定使用同一個 Wi-Fi 網路、節點與規則模式，並暫停系統更新、照片備份及大型檔案下載。
3. 鎖定螢幕觀察 60 分鐘，記下開始與結束時的電量、是否斷線、用戶端背景流量，以及記錄中的重新連線次數。
4. 每次只調整一類設定，再重複觀察。至少測試兩輪，避免把電量百分比的整數跳動當成定論。

例如，某一輪電量從 80% 降至 77%，另一輪從 80% 降至 78%，只能表示兩輪分別減少了 3 與 2 個百分點。這只是記錄方式的示例，並非本站實測結果；短時間內的差異也會受訊號、溫度及電池估算影響。

Android 背景執行：只放行必要的用戶端

先沿用預設電池策略。若鎖定螢幕後連線正常，就不必額外授予不受限制的背景權限。只有在鎖定螢幕後服務遭到終止、VPN 圖示消失，或記錄顯示程序重新啟動時，才檢查用戶端的電池最佳化設定。

依作業系統尋找電池設定

• Pixel／接近原生 Android 14 的系統：長按用戶端圖示 →「應用程式資訊」→「應用程式電池用量」→ 檢查「允許背景使用」。部分系統還會提供「不受限制」、「最佳化」及「受限制」三個選項。
• Samsung One UI 6：「設定」→「應用程式」→ 選擇用戶端 →「電池」→「不受限制」。接著查看「設定」→「電池」→「背景使用限制」，避免用戶端被加入深度休眠清單。
• 其他 Android 系統：在應用程式資訊中尋找「耗電管理」、「背景執行」或「自動啟動」。不同廠牌與系統更新可能會變更選單名稱，請以手機上實際顯示的頁面為準，不必照抄其他機型的操作路徑。

自動啟動控制的是開機或程序結束後的啟動機會；電池最佳化控制背景執行限制；最近使用的應用程式鎖定則只會影響部分廠牌的清理行為。這三者不是同一個開關。請逐項調整並記錄結果，不要把所有會連網的 App 都加入白名單。

永遠開啟 VPN 不等於省電

Android 的「永遠開啟 VPN」主要用於維持 VPN 連線策略；「封鎖未使用 VPN 的連線」則會在隧道無法使用時限制其他網路存取。兩者都不是電池最佳化開關，也無法解決節點本身不穩定的問題。只有確實需要持續接管流量時才啟用，並事先確認重新開機、切換網路及鎖定螢幕後能否正常恢復。

iOS 背景 App 重新整理：與 VPN 隧道分開設定

在 iOS 17 或 iOS 18，可前往「設定」→「一般」→「背景 App 重新整理」檢查 App 權限。這項設定主要影響一般 App 在背景重新整理的機會，不能視為 VPN 隧道的總開關。承載流量的隧道擴充功能與用戶端主畫面的執行機制不同；關閉背景 App 重新整理不一定會中斷 VPN，開啟也不保證隧道永不中止。

• 如果只會手動匯入設定檔、手動更新訂閱，可以先關閉用戶端主 App 的背景 App 重新整理，再測試隧道是否正常。
• 如果需要自動更新訂閱，請確認用戶端是否支援這項功能、是否需要背景 App 重新整理，以及系統實際允許的執行條件。
• 前往「設定」→「電池」查看活動記錄；開啟低耗電模式後，再觀察重新整理工作與連線恢復是否受到影響。

不要把 Android 的「背景鎖定」經驗套用到 iOS。也不要反覆從 App 切換器滑掉用戶端來測試省電：強制結束主 App 可能會影響後續背景工作，隧道的實際行為仍取決於用戶端的實作方式。請先使用用戶端內的連線開關，明確比較開啟與關閉的差異。

按需求連線，減少不必要的在線時間

如果用戶端提供按需求連線、信任的 Wi-Fi 或網路變更觸發選項，先確認哪些網路需要代理，再設定觸發條件。按需求連線控制的是隧道何時建立，不是節點測速頻率。條件太多或彼此衝突，可能造成切換網路時反覆連線；請先設定一個條件，確認 Wi-Fi 與行動網路切換正常後，再加入其他條件。

測速間隔：減少批次探測與重複工作

優先檢查自動策略組與代理提供者的健康檢查。若對 40 個節點每 60 秒探測一次，並假設每輪會測試所有節點，每小時約有 2,400 次探測；改為 600 秒則約為 240 次。這是排程請求次數的估算值，實際次數也會受延遲檢查、失敗重試及實作細節影響，不能直接換算成固定耗電量。

行動版 url-test 起始設定

以下是 mihomo 的策略組片段，時間單位為秒。節點名稱必須與現有設定檔一致；不要直接用這段內容覆蓋整份訂閱。優先使用用戶端支援的覆寫或合併功能進行修改，避免下次更新訂閱時設定又被還原。

proxy-groups:
  - name: 行動裝置自動選擇
    type: url-test
    proxies:
      - 日常節點
      - 備用節點
    url: https://www.gstatic.com/generate_204
    interval: 600
    tolerance: 100
    lazy: true

• interval: 600：將定時測速間隔設為 10 分鐘，適合先用來比較省電效果；這不是所有設定檔都適用的最佳值。
• tolerance: 100：以毫秒為單位設定切換容差，減少因延遲些微變動而觸發切換。這不是連線逾時時間。
• lazy: true：策略組未使用時，減少定時探測；實際觸發行為請以目前 mihomo 版本為準。
• url：這裡設定的是探測網址，不是訂閱網址。請確認目前網路能穩定連線至該網址，避免把探測目標故障誤判為所有節點都故障。

如果只使用一個穩定節點，可以先用手動選擇組進行比較。不要同時縮短自動測速間隔，又開啟用戶端的全節點定期測速。也請檢查 proxy-providers 下的 health-check：它可能與策略組構成兩套探測工作。減少重複工作後，再依據斷線恢復需求調整頻率；間隔拉長也代表發現故障可能較慢。

訂閱與規則集：依內容變動調整更新頻率

訂閱更新、代理提供者更新、規則集更新與節點測速是四種不同工作。訂閱可能包含整份設定檔；代理提供者主要提供節點；規則提供者載入規則內容；測速則用來確認節點是否可用。把它們全都設成每分鐘執行，通常不會帶來相應的日常效益。

這些數值是用來建立比較基準，並非適用於所有服務的統一要求。節點經常變動的訂閱可以縮短更新週期；變動較少的規則集則可維持每日更新。mihomo 的 HTTP 類型 rule-providers 中，interval: 86400 代表 24 小時；用戶端完整訂閱的自動更新間隔可能以分鐘或小時為單位，設定前務必確認介面顯示的單位。

保留足以定位問題的記錄即可

日常使用 log-level: warning 即可；需要追查斷線時，暫時切換為 info，重現問題後再恢復。長時間使用 debug 會增加記錄產生與處理的負擔，持續開啟即時連線面板也會增加介面重新整理工作。減少記錄前，先保存重要錯誤訊息，否則無法判斷是驗證失敗、DNS 逾時還是隧道重新啟動。

TUN、DNS 與訊號微弱：確認實際流量來源

行動裝置上的 VPN 流量接管，不能簡單等同於桌面系統代理開關。能否依 App 略過代理、是否提供 TUN 選項，取決於用戶端與平台功能。部分 Android 用戶端支援依 App 分流，可讓確實不需要代理的 App 略過；iOS 一般個人 VPN 的使用情境，不能照搬 Android 的 App 排除清單。

先確認大量流量來自哪個 App，再檢查規則比對結果。影片自動播放、雲端硬碟同步與系統下載都會持續使用無線網路，即使用戶端沒有進行測速也會耗電。將流量交由 DIRECT 處理，可減少不必要的遠端代理路徑，但不代表流量完全不經 VPN 接管，更不代表停止傳輸。

別把 DNS 模式當成獨立的省電開關

• 先找出重複解析失敗、DNS 逾時與連線重試，再修改解析設定。Fake-IP 正常運作時，不應只因它在耗電排行中名列前茅就停用。
• 讓 DNS 解析路徑保持清楚。核心 DNS、系統加密 DNS 與其他 VPN 類工具同時使用時，請檢查是否設定了無法連線的解析目標或形成循環轉送。
• 切換網路後偶爾重新建立連線屬於正常現象；若在同一個網路下持續重試，就要核對節點是否連得上、解析結果及記錄時間。

行動網路訊號微弱會增加無線通訊的耗電量。請在同一地點先比較 Wi-Fi 與行動網路，再比較兩個節點，避免把訊號問題誤認為代理協定造成。延遲最低的節點也不一定最省電：穩定傳輸、減少重試與切換，通常比單次測速的低延遲數字更值得參考。

透過三輪比較，找出背景執行與省電的平衡

1. 第一輪，減少背景工作：固定使用同一節點，將測速間隔設為 600 秒、規則集設為每日更新，關閉持續除錯記錄，並維持系統電池策略不變。
2. 第二輪，確認背景限制：只有在鎖定螢幕後會斷線時，才放寬 Android 用戶端的電池限制；iOS 則分別檢查主 App 的背景重新整理與隧道連線狀態。
3. 第三輪，檢查實際使用狀況：恢復日常使用的 App，記錄影片播放、同步及行動網路用量，觀察耗電是否隨這些活動增加。

最後保留能滿足鎖定螢幕時連線、切換網路後恢復及日常瀏覽需求的最少背景工作。若持續發熱、短時間內流量暴增，或每分鐘反覆重新啟動，請先暫停連線並保存已移除敏感資訊的記錄，再前往故障排除查找原因。分享記錄前，請移除訂閱網址、權杖、節點密碼及可識別個人身分的資訊。

更換用戶端時，先確認作業系統與核心的相容性，不要同時更換用戶端、節點及所有規則。若需要重新設定，可依照使用指南逐項還原，並保留一份已確認穩定的設定作為比較基準。