Clash 手機耗電快？Android 與 iOS 背景執行及省電設定排查

先釐清實際耗電量與電量統計歸屬

先在相同條件下比較，再調整設定。手機狀態列持續顯示 VPN 圖示，只代表系統隧道處於連線狀態，不代表處理器一直滿載運作。真正需要排查的是：螢幕鎖定後仍明顯發熱、待機耗電增加，或記錄中不斷出現連線失敗與重新連線。

Clash 是核心與設定生態的名稱，並非 Android 和 iOS 上完全相同的單一應用程式。Clash Meta 後續改用 mihomo 名稱；不同用戶端採用的核心、隧道實作與設定位置可能不同。尤其在 iOS 上，能匯入部分 Clash 格式設定，不代表完整支援 mihomo 的所有欄位。以下系統路徑與檢查方法大致通用，設定欄位則應以用戶端文件為準。

用兩個 30 分鐘時段建立基準

1. 挑選手機未充電、訊號穩定的時段。固定螢幕亮度、網路類型與節點，測試期間不要下載系統更新或同步大量照片。
2. 先停止用戶端連線，鎖定螢幕待機 30 分鐘，記下開始與結束時的電量、網路類型，以及機身是否發熱。
3. 接著啟用用戶端，在相同條件下鎖定螢幕待機 30 分鐘。測試期間不要反覆點選延遲測試或開啟即時記錄。
4. 如果兩個時段的電量差只有 1 個百分點，請延長測試時間再比較。電量顯示會四捨五入，單次短時間測試不足以判定原因。

例如，從 80% 降到 79% 與從 79% 降到 75% 的差異值得進一步調查；但這只是記錄格式範例，並非任何用戶端的實測結果。訊號不佳、背景備份與電池老化也會造成差異，不能只憑一張耗電排行截圖下結論。

TUN 常駐：維持流量接管，避免重複隧道

Android 用戶端通常透過系統 VPN 服務接管流量，部分用戶端會將相關開關稱為 VPN 或 TUN。iOS 用戶端則通常使用系統提供的 Network Extension 隧道功能。兩者都不適合直接套用桌面版「關閉 TUN，只開啟系統代理」的做法，因為手機的系統代理設定未必能涵蓋所有應用程式流量。

先檢查是否有兩種流量接管機制互相衝突

• 暫時停用其他 VPN、防火牆，或透過本機 VPN 運作的過濾工具，再啟動目標用戶端。同一系統使用者或設定範圍內，這類工具通常無法各自維持獨立的作用中 VPN 隧道。
• 查看用戶端狀態是否不斷從「已連線」變成「連線中」。如果每隔幾十秒就重新連線一次，應先處理重連問題，不要再疊加背景常駐選項。
• 先在固定 Wi-Fi 網路下測試，再改用行動網路測試。若只有訊號微弱或切換網路時發熱，請優先檢查網路與節點，不要直接認定是 TUN 實作有問題。

規則模式只會決定已接管流量的出站方式。符合 DIRECT 的連線仍可能經過用戶端處理，並不代表完全繞過隧道。若 Android 用戶端支援「依應用程式代理」，可讓確定不需要接管的應用程式略過 VPN，減少不必要的處理；但請確認名單設定是「僅代理所選應用程式」還是「略過所選應用程式」，兩者方向相反。

一般消費型 iOS 用戶端不一定提供 Android 式的任意應用程式分流。不要為了尋找同名開關而反覆修改系統設定。若裝置由組織管理，依應用程式設定 VPN 也可能受到管理政策限制。

Android 背景常駐：只解除確實受限的用戶端

螢幕鎖定後斷線與耗電增加，有時是同一個循環造成的：系統暫停用戶端，應用程式連線失敗，解鎖後又集中重連。處理方式不是把所有應用程式都設為「不受限制」，而是先確認用戶端確實受到系統限制。

依系統設定路徑逐項檢查

• Pixel 等接近原生 Android 的系統：前往「設定」→「應用程式」→「查看所有應用程式」→目標用戶端→「應用程式電池用量」，檢查「允許背景使用」等選項。部分 Android 版本會在此提供「最佳化」與「不受限制」設定。
• Samsung One UI：前往「設定」→「電池」→「背景使用限制」，檢查用戶端是否列在「休眠應用程式」或「深度休眠應用程式」中。舊版設定位置可能是「電池與裝置維護」→「電池」。
• 其他客製化系統：在應用程式資訊中搜尋「電池」、「背景」或「自動啟動」。只有在發現程序遭終止、重新啟動後無法恢復連線時，才依需要開放相應權限。

每次只調整一項，完成後鎖定螢幕 15～30 分鐘，再解鎖查看用戶端的連線時間與記錄。如果隧道持續存在且連線正常，就不必繼續開啟所有背景常駐權限。Android VPN 用戶端通常會透過前景服務維持運作，持續顯示通知本身並非耗電異常的證據。

iOS 背景連線：檢查隨選規則，別反覆強制關閉應用程式

iOS 的代理隧道延伸功能與用戶端前景介面並非採用相同的生命週期。退出前景介面後，隧道仍可能繼續運作；「背景 App 重新整理」也不是決定所有 VPN 隧道能否運作的總開關。因此，不建議把反覆從多工畫面上滑關閉用戶端當成日常省電方法。

1. 前往「設定」→「電池」，比較用戶端開始連線前後的活動情況與整台裝置的電量曲線。不同 iOS 版本可能顯示「過去 24 小時」或每日用量，請依目前系統提供的檢視方式查看。
2. 前往「設定」→「一般」→「VPN 與裝置管理」→「VPN」，確認目前作用中的設定。具體的「隨選連線」設定可能位於設定詳細資訊中，也可能由用戶端管理。
3. 若手動中斷連線後立刻又自動連上，請檢查是否啟用了隨選連線。若只在連上特定 Wi-Fi 後反覆切換，請檢查該網路對應的隨選規則。
4. 先固定使用一種網路觀察 30 分鐘，再測試 Wi-Fi 與行動網路切換。不要同時修改隨選規則、DNS 和節點，否則難以判斷哪項設定有效。

低耗電模式會限制部分背景活動，但不會自動修復失效節點、錯誤 DNS 或反覆觸發的連線策略。如果開啟低耗電模式後仍持續發熱，應回頭檢查連線記錄與流量來源，而不是繼續尋找更激進的系統省電開關。

DNS 查詢與失敗重試：先找出重複錯誤

一般 DNS 查詢通常會使用快取，看到網域解析記錄並不代表耗電異常。更值得注意的是：同一網域在短時間內連續解析失敗、上游 DNS 無法連線、解析路徑形成循環，或應用程式因連線失敗而不斷重試。

只暫時開啟記錄，觀察 2～5 分鐘

1. 在用戶端記錄頁面搜尋 timeout、DNS、failed 等關鍵字，確認錯誤是否持續重複出現。
2. 記下錯誤發生時間、網域與上游位址。單次逾時可能只是暫時波動；只有相同錯誤接連出現，才值得優先處理。
3. Android 前往「設定」→「網路與網際網路」→「私人 DNS」，先記下原本的選項。若目前填入自訂主機名稱，可在受控測試中改成「自動」，檢查與用戶端 DNS 路徑的互動；測試後再視需要還原。
4. iOS 請檢查是否安裝額外的 DNS 描述檔，或啟用了其他 DNS 應用程式。先減少同時存在的變因，再依用戶端說明還原需要的設定。

不要隨意關閉憑證驗證來解決加密 DNS 失敗。請先檢查系統日期、網路連線狀態與上游設定。fake-ip 也不是「開啟一定耗電、關閉一定省電」的選項；修改後可能影響應用程式相容性，只有在記錄或重現步驟指向解析問題時，才值得進行對照測試。

如果 mihomo 的 DNS 上游需要透過代理連線，請確認引導解析與節點網域解析都有可用路徑，避免解析依賴代理、代理又依賴相同的解析結果。使用訂閱提供的基本 DNS 設定，通常比同時拼湊多套來源不明的設定更容易排查。更多欄位說明請參閱設定參考。

速度測試、規則集與訂閱更新：拉長背景工作的間隔

耗電不一定來自實際瀏覽。多個策略群組頻繁測速、數個規則提供者反覆下載，都會增加背景網路請求。尤其在行動網路訊號微弱時，即使是小而頻繁的請求，也可能讓無線模組反覆啟動。

上表僅供對照測試參考，並非所有裝置的最佳設定。在 mihomo 中，url-test 策略群組的 interval 與規則提供者的更新間隔通常以秒為單位；用戶端的訂閱更新介面不一定採用相同單位。600 秒是 10 分鐘，86400 秒是 24 小時，設定前請先確認單位。

檢查重複測速，不要只看單一間隔

假設設定包含 4 個自動測試群組，每組列出 20 個節點，而且每 60 秒測試一次，理論上每輪會涉及 80 個測試項目。實際請求量還會受到延遲測試是否啟用、群組是否使用中與核心排程等因素影響，不能直接視為固定請求數，但足以提醒你檢查是否有重複測試。優先刪除未使用的測試群組，或在用戶端支援時啟用隨需測試。

修改前先複製設定。直接修改遠端訂閱下載的 YAML，下次更新可能會覆蓋修改；支援覆寫或合併的用戶端，應使用其可保存修改的設定入口。若 iOS 用戶端不支援這些 mihomo 欄位，請在用戶端自己的「自動測試」、「更新間隔」等設定中調整，不要強行貼上不相容的設定。

依症狀逐步調整：兼顧穩定連線與續航

日常使用可以先採用這組設定：規則模式、單一穩定的作用中節點、適當拉長自動測試間隔、依需求更新訂閱，以及預設或 info 記錄等級。Android 只有在用戶端確實遭系統終止時，才解除其背景限制；iOS 則依實際網路需求設定隨選連線，不必反覆手動開關隧道。

每次只調整一項，並至少保留一個條件相同的測試時段。若仍有明顯異常，請整理手機型號、系統版本、用戶端版本、核心版本、網路類型、測試前後電量與錯誤時間，再前往說明中心依症狀繼續排查。分享記錄前，請遮蔽訂閱連結、權杖、節點位址與個人瀏覽記錄；不適合直接公開上傳完整訂閱檔案。