先判斷是真正耗電，還是電池統計歸因造成的錯覺
先記錄螢幕關閉時的耗電情形，再調整保活設定。電池用量清單中 Clash 排名靠前，不一定代表代理核心異常：手機下載、播放影片或背景同步經過 VPN 通道時，系統可能會將部分網路處理耗電算在 VPN App 上。應一併觀察總耗電量、背景活動時間、傳輸流量及手機是否發熱，別只看單一百分比就下結論。
Android 客戶端通常透過 VpnService 接管流量；iOS 客戶端則可能使用 Network Extension 的 Packet Tunnel 擴充功能。Clash、Clash Meta（mihomo）是相關核心與生態系概念，不代表所有手機客戶端都有相同設定。尤其在 iOS 上，應先確認使用的 App 與核心，別直接套用 Android 的電池最佳化排除教學。
先留下排查紀錄
- 記下手機型號、作業系統版本、客戶端版本與核心版本。App 版本通常可在「設定」→「關於」中查看；核心版本可能需要從啟動日誌確認。
- 記下測試開始與結束時的電量、測試時間、Wi-Fi 或行動數據、訊號強度，以及螢幕是否全程關閉。
- 記下目前的代理模式、選用的策略群組、訂閱節點數量，以及是否啟用自動測速、詳細日誌與自動重新連線。
- 先備份目前的設定。若修改涉及訂閱覆寫，應使用客戶端支援的覆寫或合併設定，避免下次更新訂閱時變更遭到覆蓋。
分兩輪進行螢幕關閉測試，縮小問題範圍
選擇訊號穩定的地點，每輪觀察 60 分鐘。兩輪盡量使用相同網路、相近的起始電量，並暫停大型檔案下載、系統更新與照片備份。剛充完電、系統更新後正在建立索引，或手機明顯發熱時，先等狀態穩定再測。以下的 60 分鐘是排查時間，不代表續航保證。
- 第一輪建立基準：暫停代理服務，確認系統 VPN 已中斷連線，關閉螢幕靜置 60 分鐘。記錄總耗電量與背景流量。若有需要持續連線的服務，可改在閒置時測試。
- 第二輪維持原設定：啟動代理，使用平常的規則模式與節點，維持相同測試條件，再觀察 60 分鐘。記錄是否斷線、重新連線或持續發熱。
- 一次只改一個變數：若第二輪耗電明顯較高，下一輪只關閉定時測速，或只更換一個穩定節點。不要同時修改 DNS、路由、白名單與保活設定，否則無法找出原因。
- 重新測試，不要一次定論：電量顯示以整數跳動，短時間測試誤差較大。差異不明顯時，延長至 2～3 小時，並在另一天重測。
若停止代理後仍快速耗電，應先檢查訊號微弱、其他 App 的背景活動與系統同步。若只有啟用代理時才出現異常，再檢查通道流量、探測工作與重新連線狀況。需要透過代理才能存取的 App，可能會在第一輪持續重試，影響基準結果；遇到這種情況，兩輪測試都先停用這些 App 的背景工作。
Android 省電白名單：只排除需要常駐的客戶端
省電白名單的作用，是降低系統限制背景工作的機率，並不會減少核心本身的運算量。常見狀況是螢幕剛關閉時正常，過一段時間後連線中斷，亮起螢幕又恢復。這時才優先檢查背景限制。若手機一直發熱、流量持續增加，直接設為「不受限制」可能只是讓異常工作執行更久。
依系統檢查背景權限
- 接近原生 Android 14 的介面：可前往「設定」→「應用程式」→「查看所有應用程式」→選用的客戶端→「應用程式電池用量」，檢查背景使用權限。各廠牌介面可能顯示為「電池」或「電池用量」，並提供「不受限制」、「最佳化」、「受限制」等選項。
- 廠牌客製化系統：也要檢查應用程式資訊中的「自動啟動」、「背景活動」或「省電策略」。即使允許自動啟動，仍應確認是否另有背景網路限制。
- 鎖定最近使用的應用程式：部分系統可在最近使用的應用程式畫面鎖定 App，通常只影響清理行為，不能取代電池與背景權限設定。
先採用系統預設的最佳化策略。只有確認螢幕關閉後受到限制，才為代理客戶端單獨排除最佳化，不必把所有需要網路的 App 都加入白名單。修改後關閉螢幕觀察 30～60 分鐘，並測試從 Wi-Fi 切換至行動數據後能否恢復連線。亮起螢幕後能連線一次，不代表整段背景連線都正常。
常駐通知與 VPN 永遠開啟是不同設定
Android 前景服務通常需要顯示常駐通知。通知的作用是讓系統與使用者知道服務正在執行，本身通常不是主要耗電來源。隱藏通知不代表停止代理；反過來說，看到通知也不代表節點連線一定正常。
Android 13 及更新版本的通知權限與前景服務要求，應分開理解。拒絕通知權限，不代表前景服務就不再受系統管理。排查時保留服務通知，直接查看連線狀態，比隱藏通知來省電更有效。
在系統「設定」→「網路和網際網路」→「VPN」中，部分裝置會提供「永遠開啟 VPN」及「封鎖未使用 VPN 的連線」選項。前者用於維持所選 VPN 連線，後者則會在通道無法使用時限制其他網路連線。後者可能在斷線時讓所有 App 都無法存取網路，不應當作省電選項。選單名稱與支援情況依系統和客戶端而異。
健康檢查與自動測速：先降低頻率，再縮小範圍
節點健康檢查會主動送出請求。單次請求的資料量可能很小，但頻繁喚醒網路、連線逾時與加密交握都會增加背景負載；使用行動網路時，耗電也不會單純依資料量成正比。訂閱包含大量節點時，應分別檢查代理提供者的健康檢查、策略群組探測，以及客戶端自己的定時測速。
| 檢查項目 | 說明 | 排查方式 |
|---|---|---|
health-check.interval |
支援此設定的代理提供者健康檢查間隔，單位為秒 | 若目前為 300 秒，可試著調至 900 秒，再觀察切換速度是否可接受 |
策略群組 interval |
url-test、fallback 等群組的定期探測間隔 |
分別核對提供者的檢查設定，避免多處都設為 60 秒 |
lazy |
在支援此設定的檢查或策略群組中，控制未使用時是否延後探測 | 先依核心文件確認支援範圍，再考慮使用 true |
| 客戶端自動測速 | 介面額外發起的延遲或下載速度測試 | 先關閉定時測速，保留需要時的手動測試 |
| 訂閱更新間隔 | 重新取得節點與設定，不等於測試節點速度 | 若不需要頻繁更新，可設為 12 或 24 小時 |
以 80 個節點、每 60 秒一輪為例，若每輪都探測所有節點，一小時約會有 4,800 次節點探測；改為每 900 秒一輪，則約為 320 次。這是排程數量的示例，不是實測耗電結果，也未計入重試、延遲檢查或其他策略群組工作。這說明應先檢查頻率與範圍，而不是只盯著某次測速用了幾 KB。
手動選擇單一節點可作為對照，但不保證提供者的背景健康檢查也會停止。若介面已切換為手動選擇，日誌仍定期出現大量探測，就應繼續檢查提供者與客戶端層級的定時工作。
重新連線、DNS 與 TUN：檢查是否陷入循環，別盲目停用功能
手機透過 VPN 接管流量時，介面不一定會稱為「TUN 模式」，也未必提供與桌面版相同的開關。重點是找出異常工作循環：切換網路後不斷重新連線、DNS 請求持續逾時，或某個背景 App 反覆建立連線失敗。正常的流量接管與規則比對會產生負載，但不能只因為啟用了 TUN，就認定它是異常原因。
- 先排除節點問題：固定使用已知可用的節點，觀察 30 分鐘。若重新連線明顯減少，再檢查原節點的穩定度與自動切換條件。
- 接著檢查 DNS 逾時：暫時查看日誌，確認是否反覆出現解析逾時、連線失敗，或同一網域大量重試。DNS 請求逾時可能導致上層 App 持續重試，消耗網路與運算資源。
- 核對網路端設定：若曾手動設定 Android「私人 DNS」或其他 DNS 工具，先記下原設定，再依客戶端文件確認是否互相影響。不要同時任意修改多個 DNS 設定。
- 找出背景流量來源：在客戶端的連線面板中依流量或連線數查看，找出雲端硬碟上傳、照片備份、影片預載等工作。代理只是傳輸路徑，持續負載的來源可能是這些 App。
規則模式適合日常分流，但「直連」不一定代表資料完全繞過本機 VPN 處理：若流量已由通道接管，核心仍可能進行辨識與轉送。另一方面，全域模式也不會自動減少所有背景運算。不要把反覆切換模式當成省電方法，應搭配實際連線狀況與規則比對結果排查。
日誌只需短時間收集。暫時將日誌層級調為 debug，重現問題 2～5 分鐘後，恢復為 info 或客戶端預設層級。長時間保留詳細日誌、開啟即時連線面板並頻繁重新整理，都會增加額外負載。將日誌提供給他人前，請移除訂閱網址、權杖、節點憑證及其他敏感資訊。
iOS 背景保活：分清 App 介面與通道擴充功能
iOS 沒有與 Android「不受限制」完全相同的通用電池白名單。支援 Packet Tunnel 的客戶端通常由擴充功能處理通道；App 介面切至背景，不代表通道一定會停止；開啟「背景 App 重新整理」也不代表 VPN 擴充功能就能無限期保活。是否持續連線，應查看系統 VPN 狀態與客戶端連線紀錄。
檢查以下三個位置
- 電池用量統計：以 iOS 18 為例，前往「設定」→「電池」，選擇「過去 24 小時」或「過去 10 天」，並查看相應時段的活動情形。其他系統版本的統計期間與選單位置可能不同。
- VPN 設定：前往「設定」→「一般」→「VPN 與裝置管理」→「VPN」，確認目前使用的設定檔，避免把另一個 App 的連線誤認為目前客戶端的連線。
- 隨選連線：若客戶端提供「隨選連線」或自動連線規則，檢查 Wi-Fi 與行動數據切換時是否反覆觸發。可先暫時關閉進行對照測試，再決定是否恢復。
低耗電模式會調整部分系統背景行為，但不能因此斷定 VPN 一定會中斷，或一定更省電。若需要持續連線，應分別測試開啟低耗電模式後螢幕關閉與切換網路的情況。頻繁強制結束 App 也不是通用的保活方法；實際影響取決於客戶端與系統的實作方式。
若 App 沒有提供探測間隔、日誌層級或依 App 設定等功能，就別硬套其他平台的 YAML 片段。先確認客戶端實際支援的設定，再利用固定節點、減少定時測速、檢查隨選連線等可用方法進行對照。
依使用情境決定保活程度
| 使用情境 | 建議起始設定 | 需要接受的取捨 |
|---|---|---|
| 偶爾瀏覽網頁 | 依需求啟用或停用，先保留系統預設的電池最佳化 | 使用前可能需要手動連線 |
| 全天接收訊息與同步 | 視需要排除 Android 背景限制，保留適度的健康檢查 | 持續連線會有基本負載，需確認螢幕關閉時的穩定性 |
| 通勤途中經常切換網路 | 優先使用穩定節點，檢查自動重新連線與隨選規則 | 訊號微弱時的重試與網路切換可能增加耗電 |
| 只在特定網路環境使用 | 使用客戶端支援的網路條件規則 | 網路條件變更時，可能會重新建立通道 |
最後只需保留三項紀錄：相同條件下螢幕關閉時的耗電量、螢幕關閉期間是否斷線，以及切換網路後能否恢復。先減少重複探測與失敗重連，再視需要放寬保活權限。若連線已穩定，就不必為了電池用量清單的排名反覆更換 DNS 或重寫規則。
若仍找不出原因，請提供手機型號、系統與客戶端版本、核心版本、測試時段、網路類型，以及已去除敏感資訊的短時間日誌。描述「螢幕關閉 40 分鐘後連線中止，亮起螢幕後立即恢復」，比只說「很耗電」更容易分辨是背景限制、節點故障或通道異常。