手機掛著 Clash 很耗電？排查 Android 背景執行、DNS 輪詢與省電設定

先做對照測試：區分使用流量、待機耗電與電量統計

手機開著 Clash 時發熱，不代表代理核心一直占滿 CPU。影片下載、雲端相簿上傳，以及訊號不佳時行動網路重傳，都可能同時發生。Android 的本機 VPN 會接收其他應用程式的流量，系統電池頁面可能將部分網路活動歸到 VPN 客戶端；各家系統的統計方式也不盡相同。先看手機整體耗電，再查看應用程式排行，別只盯著耗電最高的項目。

進行兩輪測試，每輪至少 60 分鐘

1. 固定測試條件：使用同一個 Wi-Fi、相近的起始電量與室溫；暫停下載和系統更新，測試時不要充電。
2. 關閉代理測試一輪：鎖定螢幕 60 分鐘，記錄起迄電量、是否發熱、背景執行的應用程式與訊號狀況。
3. 開啟代理測試一輪：使用相同節點與設定，鎖定螢幕 60 分鐘。重複測試兩到三組，並盡量交替測試順序。
4. 再做一組行動網路測試：若只有行動網路時明顯異常，優先檢查訊號、網路切換與連線重試，不要立刻更換 TUN 堆疊。

例如，電量從 80% 降到 77%，只能記錄為「這一小時下降 3 個百分點」，不能據此推算精確耗電量。以下欄位供記錄使用，並非本站實測結果。電量顯示可能有四捨五入誤差；差異很小時，延長測試至 3～6 小時會更有參考價值。

背景執行：保留必要權限，避免服務反覆重啟

Android 客戶端通常透過 VpnService 建立本機 VPN 介面，再將流量交由核心處理。系統顯示常駐通知，不代表持續高負載；反之，若強制隱藏通知或限制背景活動，服務遭終止後又自動啟動，也可能造成斷線與重複初始化。

先確認 Android 的三個設定位置

• 電池限制：Android 13～15 常見路徑為「設定」→「應用程式」→「查看所有應用程式」→選取客戶端→「應用程式電池用量」。部分系統會顯示為「電池」→「不受限制／最佳化／受限制」。實際名稱依手機而異。
• VPN 設定：原生 Android 常見路徑為「設定」→「網路和網際網路」→「VPN」→點選客戶端旁的設定按鈕，查看「一律開啟 VPN」和「封鎖未使用 VPN 的連線」。後者是在 VPN 中斷時封鎖流量，並非省電選項。
• 廠商的背景管理：在應用程式資訊頁檢查「自動啟動」、「背景執行」等選項。先只調整目前使用的客戶端，不要一次放行所有背景應用程式。

如果鎖定螢幕後連線穩定，也沒有服務退出紀錄，就不必為了「更強的背景保活」額外啟用定時重啟、第三方守護工具或週期性網路請求。若鎖屏後已經斷線，先允許客戶端正常在背景執行，再觀察耗電變化。省電與維持連線必須分開驗證，不要靠反覆切換權限碰運氣。

只讓確實需要的應用程式使用 VPN，可以減少核心處理的連線數量，但不保證整支手機更省電：被排除的應用程式仍可能在背景下載。每次調整後，請檢查瀏覽器、訊息通知、地圖與區域網路存取，避免把功能失效誤當成省電成功。

排程工作：先檢查健康檢查，再查看訂閱更新

待機時仍定期連網，常見原因包括節點健康檢查、自動選擇策略，以及訂閱或規則更新。這些並非同一種排程：節點探測用來測試可用性，訂閱更新會下載設定或節點清單，規則更新則會重新整理比對資料。若把三者都設成每幾十秒執行一次，很容易產生額外請求。

一併檢查探測間隔與節點數量

假設某個節點群組有 80 個節點，每 60 秒完整探測一次，單看排程量，每小時就有 4800 次探測嘗試；改成每 600 秒一次則為 480 次。實際次數也會受延遲檢查、失敗處理方式與客戶端實作影響。這只是設定規模的示例，並非耗電實測，也不表示所有節點都會同時建立連線。

• 排查期間，先關閉不必要的自動測速，或將 60 秒的間隔調整為 600～1800 秒。
• 暫時改用手動選擇策略，觀察使用同一節點時的鎖屏耗電，排除自動切換過於頻繁的影響。
• 一般訂閱可先設定為每 24 小時更新一次；若需要更快取得變更，再縮短間隔。
• 不要同時保留多組針對相同節點的密集探測。健康檢查和策略組測試可能會各自發出請求。

mihomo 的 provider 設定範例

以下片段僅用於替換現有 proxy-providers 中某個 HTTP provider 的對應欄位；請保留原有名稱、訂閱網址與路徑，不要直接貼到 YAML 頂層。這裡的 interval 和健康檢查中的 interval 單位都是秒，timeout 的單位則是毫秒。

interval: 86400
health-check:
  enable: true
  url: https://www.gstatic.com/generate_204
  interval: 600
  timeout: 5000
  lazy: true

lazy: true 可減少未使用 provider 的定期檢查，但不會停用使用中節點的所有探測。檢測網址必須能透過對應節點連線；若該網址在目前網路無法連線，可能會將網址故障誤判為節點故障。部分舊版 Clash 核心可能不支援這些欄位，匯入前請確認核心類型，儲存後再查看設定錯誤提示。

客戶端的「訂閱自動更新」可能獨立於 YAML 中的 provider 更新。兩處都要檢查，不能只修改其中一個數字。託管設定也可能在下次更新時覆蓋手動修改，建議優先使用客戶端支援的覆寫或合併功能。

DNS 輪詢：從記錄檔找出重複請求，別盲目更換解析器

一般 DNS 查詢通常由應用程式解析網域時觸發。啟用 fake-ip 本身不會要求手機定期查詢所有網域；它主要會改變網域對應與連線處理方式。所謂「DNS 輪詢耗電」，實際原因可能是應用程式重試、健康檢查、加密 DNS 連線重建，或 DNS 設定形成迴圈。

開啟短時間記錄檔，檢查三種情況

1. 同一網域每隔幾秒就出現：先確認是否來自訊息通知、廣告請求、同步工作或測速網址。有需要時暫停相關應用程式，觀察請求是否停止。
2. 大量逾時後立刻重試：檢查 DNS 上游是否可連線、是否依賴尚未建立的代理連線，以及用來解析上游網域的引導解析器。
3. 本機位址反覆互相轉送：檢查客戶端 DNS 是否又轉向遭自身攔截的入口。不要同時把 127.0.0.1 的監聽連接埠設為上游，以免形成迴圈。

排查時先保留一組已確認可連線的 DNS 上游，暫停重複的覆寫，再逐項恢復。不要為了省電清空所有解析規則，也不要刻意拉長快取失效時間：這可能導致網域切換後的位址遲遲無法更新。nameserver-policy 用來依網域選擇解析器，不是關閉所有排程的總開關。

也請記錄 Android「設定」→「網路和網際網路」→「私人 DNS」的設定。系統私人 DNS、瀏覽器安全 DNS 和客戶端內建 DNS 可能同時存在；實際路徑取決於 VPN 路由方式和應用程式實作。TUN 對 53 埠的攔截，不代表能接管所有加密 DNS。需要進行對照測試時，一次只修改一項，測完後還原成符合自身隱私需求的設定。

記錄檔等級與連線頁面：排障完成後減少額外負擔

除錯記錄檔會增加格式化、寫入與介面重新整理的負擔。定位問題時可以暫時開啟，但不適合長時間停留在即時記錄檔頁面。若連線清單每秒重新整理，也會增加前端工作量；測試鎖屏耗電時，請返回背景，不要讓儀表板持續亮著。

mihomo 日常使用的記錄檔等級可以先採用以下設定。它位於設定檔頂層，與 dns、tun 同層；正確值是 warning，不是 warn。

log-level: warning

• 重現問題時，可暫時改為 info，記錄 5～10 分鐘即可。
• 需要更深入診斷時再啟用 debug，避免測試期間持續匯出大量記錄檔。
• 分享記錄檔前，請遮蔽訂閱網址中的權杖、節點憑證與個人存取紀錄。
• 若客戶端另有獨立的介面記錄檔設定，也請一併檢查；核心記錄檔等級不一定會控制所有前端記錄。

降低記錄檔等級主要是減少記錄開銷，無法修復節點封包遺失或 DNS 迴圈。若錯誤仍頻繁出現，應處理錯誤來源，而不是只把記錄檔隱藏起來。

TUN 堆疊與節點協定：依實機測試結果選擇

在 Android 上，VpnService 會提供虛擬網路介面，再由客戶端決定如何處理收到的封包。桌面教學中的 TUN 開關，不能直接套用到 Android 的實作。有些行動客戶端會自行建立介面，YAML 中的 tun 欄位不一定能控制所有行為。

先確認有哪些選項，再進行單一變因測試

mihomo 常見的堆疊選項包括 system、gvisor 和 mixed，但行動客戶端是否提供這些選項、如何整合，須以該版本為準。沒有任何一種堆疊能保證適用所有手機或最省電。若預設堆疊運作穩定，先維持原設定；只有在 CPU 持續高負載、UDP 異常或遇到已知相容性問題時，才測試其他受支援的堆疊。

1. 記下目前客戶端與核心的完整版本號，並備份可用的設定。
2. 只切換堆疊，維持節點、規則、DNS 與測試網路不變。
3. 依客戶端提示重新建立 VPN，分別測試鎖屏待機與實際使用情境。
4. 檢查網頁、語音通話、遊戲 UDP、IPv6 與區域網路裝置存取；若功能退步，請還原原設定。

節點端的封包遺失、壅塞與協定實作也會影響耗電。網路不穩時持續重新連線，比一次正常交握更值得優先排查。先更換成使用相同協定的穩定節點，再比較協定差異；不要同時更換節點、關閉 IPv6、切換堆疊，否則無法判斷哪項設定真正有效。

省電調整清單：依風險由低至高執行

iPhone 使用者也應在相同網路條件下進行對照測試，但不要照搬 Android 的電池白名單或 VpnService 選單。iOS 客戶端通常仰賴 Network Extension；訂閱更新、測速與記錄檔設定，請在個別 App 中檢查。本文的 mihomo YAML 片段也只有在客戶端明確支援相應設定時才適用。

仍然耗電？提交可重現的問題紀錄

完成上述步驟後，若手機仍持續發熱，請準備一份最小重現紀錄，比只說「背景很耗電」更容易找出問題。向客戶端專案的問題回報頁提交資訊時，至少應包含以下內容：

• 手機型號、系統版本、客戶端版本與核心版本，以及問題是否在升級後首次出現。
• Wi-Fi 或行動網路條件、是否鎖定螢幕、測試起迄時間，以及開啟與關閉代理兩組的整體耗電紀錄。
• 健康檢查與更新間隔、記錄檔等級、TUN 堆疊，以及是否啟用應用程式分流。
• 已移除敏感資訊的短時間記錄檔，註明首次異常的時間，以及是否伴隨服務重新啟動或網路切換。

若關閉代理後仍明顯耗電，請改查訊號、背景同步、電池健康度與系統更新工作。排查順序應是先測量，再減少無效喚醒，最後才調整底層實作。每次只修改一項，並保留可還原的設定，測試結果才有比較基準。更多基本操作請參閱使用指南；若有連線異常，請繼續查閱完整文件。