Clash 手機耗電高？Android 背景執行與 iOS 按需連線設定指南

先釐清耗電來源：隧道、網路流量與背景工作

手機狀態列持續顯示 VPN，不代表代理核心一直處於高負載。Android 用戶端通常會透過系統 VPN 介面建立虛擬網卡，再交由核心處理流量；iOS 相容用戶端則通常透過 Network Extension 的封包隧道運作。實際耗電量還取決於傳輸資料量、是否頻繁重新連線，以及行動網路訊號是否穩定。

本文所說的「Clash 手機版」，包括使用 Clash 或 mihomo 核心的 Android 用戶端，以及支援相關訂閱或規則格式的 iOS 用戶端。這些並非同一款 App。尤其在 iOS 上，不能直接照搬 Android 用戶端的設定選單、TUN 開關或 YAML 欄位。

• 隧道處理負載：流量經過虛擬網卡、規則比對與協定加解密，都會增加處理負擔；播放影片、下載檔案和分享熱點時尤其明顯。
• 應用程式流量負載：雲端相簿、訊息同步、短影音預載即使走直連，也可能經過隧道。規則設為 DIRECT，不一定代表流量會繞過系統 VPN 層。
• 排程工作負載：節點健康檢查、訂閱更新、規則集下載與失敗重試都會喚醒網路。執行得越頻繁，越容易抵銷待機省電效果。
• 無線網路負載：訊號微弱、Wi-Fi 與行動網路切換，以及反覆建立連線，都可能讓無線模組維持較長時間的運作。

進行 2 小時待機對照，別只憑感覺調整設定

先做短時間對照，再決定是否修改背景執行設定。Android 可前往「設定」→「電池」→「電池用量」查看統計；iOS 18 可前往「設定」→「電池」查看電量曲線與各 App 的活動狀況。不同廠牌的選單名稱可能不同，找不到時可在系統設定中搜尋「電池用量」。

1. 固定測試條件：選擇相同地點與網路，並讓起始電量相近，例如每次都從約 80% 開始；暫停系統更新、照片備份與大型檔案下載。
2. 記錄基準值：在不需要代理的測試時段關閉隧道，鎖定螢幕待機 2 小時，記錄起始與結束電量、背景活動及網路狀態。
3. 記錄原始設定：恢復隧道與原有規則，再進行 2 小時鎖定螢幕測試。不要同時變更節點、測速間隔與系統省電設定。
4. 逐項重新測試：一次只延長自動測速間隔，或只調整一項背景限制；其他條件維持不變，至少重複測試兩輪。

例如，某輪測試記錄為關閉隧道時 80%→78%，開啟隧道時 80%→75%，只能說兩次相差 3 個百分點，還不能直接歸因於 TUN。這些數字只是記錄範例，並非本站實測結果或通用正常值；若第二輪剛好遇上訊號不佳而重新連線，或相簿正在同步，測試結果就不具比較意義。

每輪至少記錄以下六項

• 手機型號、作業系統版本、用戶端版本，以及用戶端顯示的核心版本。
• 測試開始與結束時間，以及電量百分比。
• 使用 Wi-Fi 或行動網路，以及訊號是否穩定。
• 隧道狀態、規則模式與目前選用的節點。
• 自動測速間隔、訂閱更新間隔與規則集更新間隔。
• 鎖定螢幕期間是否發生中斷、重新連線、通知延遲或手機發熱。

Android 背景執行：依中斷狀況調整電池最佳化

將 App 加入電池最佳化例外清單，解決的是「程序受系統限制而無法持續運作」，不是「降低代理處理流量的耗電」。如果鎖定螢幕後網路一直正常，就不必先解除所有背景限制；若鎖定螢幕十多分鐘後就斷網，再檢查用戶端的背景權限。

Android 14 原生系統的檢查順序

1. 前往「設定」→「應用程式」→「查看所有應用程式」→選擇用戶端→「應用程式電池用量」。部分裝置會顯示為「電池」。先確認目前是否允許背景使用。
2. 若選擇「受限制」後出現鎖定螢幕時斷線，先改為「最佳化」並重新測試；若仍遭中斷，且確實需要持續連線，再試著選擇「不受限制」。實際選項依系統版本而異。
3. 確認用戶端的 VPN 常駐通知是否正常顯示。Android 前景服務通常需要持續顯示通知，不要把關閉通知當成省電步驟；隱藏通知也不代表服務仍在執行。
4. 若廠牌系統另有「自動啟動」、「背景執行」或「鎖定背景工作」等設定，只為需要常駐的用戶端視需求開啟。不必一併解除其他無關 App 的限制。

檢查系統 VPN 時，可在原生 Android 的「設定」→「網路和網際網路」→「VPN」中選取對應用戶端。如果開啟「一律開啟 VPN」與「封鎖未使用 VPN 的連線」，用戶端停止後整台裝置無法上網，可能是預期的防護行為，不一定代表節點失效。排查前先記下這兩個開關原本的狀態。

如何選擇 TUN 與分流代理

Android 一般 App 通常不像桌面瀏覽器，能統一遵循用戶端設定的 HTTP 代理連接埠。因此，只關閉 VPN/TUN、保留本機監聽連接埠，不代表整台裝置仍能依規則上網。若要接管全裝置流量，請保留隧道；若只有少數 App 需要代理，可確認用戶端是否支援透過 Android VPN 設定 App 包含或排除清單。

分流排除與 YAML 中的直連規則並非同一層級：前者在用戶端與系統支援的情況下，可讓指定 App 繞過 VPN；後者通常只是在流量進入核心後，選擇直連出口。修改清單後，依用戶端要求重新建立連線，並分別測試瀏覽器、訊息與支付 App。

減少自動測速與規則集更新的喚醒次數

「測速」至少分為兩種：延遲探測與下載速度測試。延遲探測的請求量較小，但節點多、間隔短時仍會產生大量連線；下載測速則會實際傳輸資料，更不適合在背景頻繁執行。先關閉用戶端額外排程的全節點循環測速，再檢查訂閱中的健康檢查與自動選擇群組。

先把 60 秒改為 600 秒進行對照

假設一個提供者有 100 個節點，而且每輪都會探測所有節點：每 60 秒測試一輪，每小時約有 6,000 次探測；每 600 秒一輪則約有 600 次。這是依節點數與間隔計算的請求量範例，實際情況還會受延遲檢查、失敗重試與用戶端排程影響，不能直接換算成省下多少電量。

若 mihomo 設定支援相關欄位，可在既有 proxy-providers 項目的 health-check 中調整以下欄位。保留原本可用的探測 URL；以下僅為設定片段，並非可獨立匯入的完整設定。

health-check:
  enable: true
  interval: 600
  lazy: true

interval 的單位是秒；lazy: true 可減少提供者未使用時的定期健康檢查，但不會停止目前連線的資料傳輸。若設定中還有 url-test 或 fallback 群組，也要另外檢查其探測設定：提供者檢查與策略群組檢查可能同時存在，只調整其中一處未必能消除重複探測。

分別安排三類更新工作

訂閱更新可能會覆蓋本機修改。建議使用用戶端提供的覆寫或合併功能，並在訂閱更新一次後確認最後生效的設定。如果記錄檔每隔幾秒就顯示同一個規則網址下載失敗，應修正網址或網路路徑，而非一味拉長所有更新間隔。

iOS 按需連線：分清離開介面與停止隧道

iOS 用戶端的主畫面與由系統管理的隧道延伸功能是不同部分。主畫面不在前景，不代表隧道已停止；在多工畫面反覆向上滑掉 App，也不是可靠的省電方法。請在用戶端內查看連線狀態，並前往「設定」→「一般」→「VPN 與裝置管理」→「VPN」確認目前設定。

按需連線適用於網路範圍明確的情境

按需連線會由用戶端設定系統規則，在符合網路條件時建立或中斷 VPN，並非單純「螢幕熄掉就斷線」。能否依 Wi-Fi 名稱、網路類型或網域設定，取決於用戶端支援；如果只看到「按需連線」開關，不要假設已設定好合適的觸發條件。

• 全天都需要代理：先維持連線，減少頻繁測速，再觀察網路穩定時的待機耗電。
• 僅在特定網路使用：若用戶端支援，可依明確的 Wi-Fi 或網路條件設定按需規則，再確認離開該網路後的狀態。
• 偶爾使用：使用前手動連線，結束後在用戶端內中斷連線，最容易確認目前狀態，但要留意背景 App 之後會改用一般網路。

手動點選「中斷連線」後立即又重新連線，可能是按需規則仍符合條件，不一定是按鈕失效。若要暫停連線，也應檢查該設定的按需連線開關。反過來說，低耗電模式與背景 App 重新整理也不能取代 VPN 按需規則；不要只為了讓隧道常駐，就替所有 App 開啟背景重新整理。

依症狀調整設定，保留可還原的紀錄

鎖定螢幕後斷網，但待機耗電不高

先檢查 Android 背景限制與一律開啟 VPN 設定，或確認 iOS 按需規則是否確實生效。恢復穩定連線後再比較耗電；不要一邊頻繁重啟隧道，一邊評估電量。反覆恢復連線本身就會增加網路活動。

鎖定螢幕後仍發熱，記錄檔持續更新

優先檢查重複測速、規則下載失敗、節點重新連線與 DNS 逾時。將記錄檔等級恢復為用戶端預設的日常設定，並關閉持續封包擷取與除錯記錄；只保留排除問題所需的短時間記錄即可。DNS 異常應修復解析路徑，不要靠關閉流量接管來掩蓋問題。

只有行動網路耗電明顯

先在相同地點比較訊號強度，再固定使用穩定節點進行測試。不要同時修改 TUN 堆疊、MTU、DNS 模式與協定；尤其不能只憑耗電情況就套用特定 MTU 數值。若只有傳輸大型檔案時出現異常，先記錄速度、發熱與重新連線次數，再依網路問題繼續排查。

調整後的驗收清單

1. 鎖定螢幕 30 分鐘後，必要的 App 仍可正常上網並接收通知。
2. Wi-Fi 與行動網路切換後，連線能依預期恢復或停止。
3. 更新一次訂閱後，測速間隔與自訂規則仍正常生效。
4. 在相同條件下完成兩輪 2 小時待機測試，不再只看單次電量百分比。
5. 記下調整過的開關；若效果不明顯，就恢復原值，不要繼續疊加變更。

適合長期使用的設定，應兼具連線穩定、背景工作節制與行為可預期。Android 是否將 App 加入電池最佳化例外清單，應視鎖定螢幕後是否斷線而定；iOS 是否啟用按需連線，則應依使用情境與中斷後的網路需求決定。先減少不必要的工作，再處理系統背景執行限制，通常比一次開啟所有權限更容易找出原因。