Clash Android 耗電異常排查：背景常駐、品牌省電策略與 VPN 常開

先確認耗電來源

Android 狀態列出現鑰匙或 VPN 圖示，只能表示系統正在維持 VPNService 通道，不能直接證明 Clash 核心持續處於高負載。mihomo 核心、用戶端介面、行動網路、Wi-Fi 掃描與代理中的應用程式，都會分別計入不同耗電項目。排查前，先把「整晚掉電 20%」拆解成可重現的資料。

進行一輪可比較的 8 小時測試

1. 將電量充至 80% 以上，關閉遊戲、雲端相簿備份與系統更新。
2. 記錄目前的網路類型、訊號強度、Clash 模式、選用節點與設定檔更新時間。
3. 第一晚保持 Clash 關閉，鎖定螢幕靜置 8 小時，記錄掉電比例。
4. 第二晚在相同地點開啟 Clash，使用同一個 Wi-Fi 與節點，再靜置 8 小時。
5. 進入「設定」→「電池」→「電池用量」，分別查看 Clash、Android 系統、行動網路與主要應用程式的占比。

例如，關閉 Clash 時 8 小時下降 3%，開啟後下降 6%，可將多出的 3 個百分點視為代理鏈路及其喚醒活動的約略成本。如果兩輪分別下降 4% 與 19%，且「行動網路」位居首位，應優先檢查訊號不佳與 Wi-Fi 斷線，而不是立即修改代理規則。

使用系統工具觀察背景活動

Android 14、Android 15 的選單名稱可能因品牌而異，但通常可在「設定」→「電池」→「電池用量」中點開 Clash，查看前景時間與背景時間。背景時間接近整晚，是 VPN 常開的正常表現；異常訊號則是鎖定螢幕後 CPU 使用率持續偏高、裝置維持溫熱，或 Clash 的耗電曲線出現連續陡升。

具備 ADB 環境時，可以在電腦上補充查看系統統計資料。以下指令不會修改用戶端設定：

adb shell dumpsys batterystats
adb shell dumpsys deviceidle
adb shell dumpsys connectivity
adb shell dumpsys vpn_management

不同 Android 版本提供的服務項目可能不同。如果最後一行提示找不到服務，使用前兩項即可。重點觀察鎖定螢幕期間的喚醒次數、網路活動與 Doze 狀態，不要只根據某一次瞬間 CPU 數值下結論。

先關閉高頻測速與自動更新

許多耗電問題並非來自正常轉發，而是用戶端在背景反覆執行 URL-Test、訂閱更新或節點健康檢查。一次測速通常會對策略組中的多個節點建立連線；若一組包含 80 個節點，間隔又設為 60 秒，理論上一小時可能觸發數千次連線嘗試。訊號不佳時的逾時與重試，還會進一步延長無線模組的活躍時間。

檢查策略組的測速間隔

開啟目前的設定檔，尋找包含 type: url-test、type: fallback 或 type: load-balance 的策略組。常見欄位如下：

proxy-groups:
  - name: 自動選擇
    type: url-test
    proxies:
      - 節點 A
      - 節點 B
    url: https://www.gstatic.com/generate_204
    interval: 600
    tolerance: 80
    lazy: true

interval: 600 表示每 600 秒檢查一次，比 60 秒更適合手機長時間常開。mihomo 支援的 lazy: true 會在策略組長時間未使用時，減少不必要的探測。具體欄位是否會由用戶端設定編輯器保留，應以匯出的 YAML 為準；部分訂閱會在每次更新時覆蓋本機修改。

用戶端選單名稱並不一致。常見入口是「設定檔」→「目前設定」→「覆寫」，或「設定」→「訂閱」→「自動更新」。若介面只允許設定訂閱更新週期，策略組測速間隔仍需在設定提供者或本機覆寫中調整。

控制規則規模與 DNS 負載

Clash 的規則比對通常不是手機長時間常開時的主要耗電來源，但設定檔過大、規則集頻繁更新、DNS 查詢反覆回退時，仍會增加記憶體占用與網路喚醒。問題常見於多套規則重複載入，或同時啟用大量實際流量判斷不會用到的 provider。

減少重複規則與過密更新

開啟設定檔日誌，檢查啟動時載入的 rule-provider 數量。同一組網域不應同時以遠端規則集、內嵌 DOMAIN-SUFFIX 與腳本覆寫三種方式重複存在。遠端規則集的更新週期應依內容變化速度設定；廣告或一般網域清單通常每 12 至 24 小時更新一次即可，地理資料庫每天更新也沒有實際效益。

rule-providers:
  common-direct:
    type: http
    behavior: domain
    interval: 86400
    path: ./ruleset/common-direct.yaml

interval: 86400 代表 24 小時。規則提供器的下載由用戶端或核心發起，頻繁更新會喚醒網路並寫入儲存空間。若設定為每小時更新一次，而規則檔本身數週才變動，應直接延長週期。

檢查 DNS 循環與失敗重試

DNS 設定異常可能表現為網頁首次開啟緩慢、日誌反覆出現 timeout，以及用戶端在待機時仍持續發起解析。Fake-IP 模式本身適合規則分流，不代表一定耗電；真正需要排查的是 nameserver 無法連線、fallback 反覆逾時，以及 DoH 位址必須先解析自身網域所形成的依賴鏈。

• 為網域形式的 DoH 伺服器設定可連線的 bootstrap 解析路徑。
• 避免在系統私人 DNS、瀏覽器安全 DNS 與 Clash DNS 中層層疊加相同類型的轉發。
• 確認區域網路 DNS 沒有將請求轉回手機上的 Clash 監聽連接埠。
• 日誌持續出現 3 秒或 5 秒逾時時，先替換無法連線的上游，不要單純增加並行伺服器數量。

常見的 mixed-port 是 7890，但 Android 用戶端透過 VPNService 接管流量時，應用程式通常不需要手動填寫該連接埠。若再為瀏覽器額外設定 127.0.0.1:7890，並疊加系統 VPN，可能造成路徑混亂。除非正在測試局部代理，否則應讓應用程式流量只經過一套入口。

TUN、VPNService 與常駐圖示如何取捨

Android 上的 Clash 類用戶端通常會透過系統 VPNService 建立虛擬網路介面，再將流量交給 mihomo 核心處理。狀態列持續顯示 VPN 圖示是系統行為。只要代理處於啟用狀態，這項服務就應保持運作；強行隱藏通知、凍結程序或定期清理背景，反而可能造成通道頻繁重建。

哪些情境值得全天常開

• 訊息、協作與開發服務需要隨時依規則分流。
• 手機在 Wi-Fi 與行動數據之間頻繁切換，需要自動恢復代理路徑。
• 設定檔含有直連規則，大部分中國大陸流量不會繞行遠端節點。
• 用戶端已設定合理的測速與訂閱更新週期。

如果每天只在固定應用程式中短時間使用代理，按需開啟會更省電。全天常開的價值在於連線連續性，而不是提升速度。關閉 Clash 後，系統會撤銷 VPN 介面；再次開啟時，現有 TCP 連線可能需要重建，這是正常現象。

一般 VPN 與永遠開啟的 VPN

Android 原生設定中通常可以進入「設定」→「網路與網際網路」→「VPN」→ 對應 Clash 項目的齒輪按鈕，找到「永遠開啟的 VPN」。品牌系統也可能將入口放在「更多連線」→「VPN」。開啟後，系統會嘗試持續啟動該 VPN 應用程式；如果同時開啟「封鎖未使用 VPN 的連線」，Clash 啟動失敗時，其他應用程式可能會完全無法上網。

TUN 模式會接管更廣泛的 TCP、UDP 流量，適合不遵循系統 HTTP 代理的應用程式。在 Android 用戶端中，VPNService 本身通常已負責 TUN 接入，不應照搬桌面端「系統代理加 TUN」的組合思路。若用戶端提供「繞過區域網路」、「僅代理所選應用程式」或「分應用程式代理」，優先使用這些選項縮小處理範圍。

各品牌背景白名單設定

背景程序遭系統清理，與持續耗電是兩個方向相反的問題。白名單的目標是避免程序被錯誤終止，不是把所有權限全部開啟。建議先允許自動啟動與背景執行，再觀察 24 小時；只有鎖定螢幕後通道仍會中斷，才繼續調整電池最佳化。

系統版本、地區與裝置型號會改變選單名稱。找不到對應入口時，可在設定搜尋框輸入「電池最佳化」、「背景活動」或「自動啟動」。調整後鎖定螢幕 30 分鐘，再從另一部裝置向手機傳送訊息，接著切換一次 Wi-Fi 與行動數據，確認 VPN 圖示與網路連線是否持續。

最近任務頁的「鎖定應用程式」只能減少一鍵清理造成的終止，不能取代系統電池白名單。相反地，將 Clash 加入白名單後仍頻繁手動清理最近任務，也可能讓前景服務中斷。穩定的設定應盡量減少這類互相衝突的操作。

依日誌定位異常連線與循環重新啟動

如果手機鎖定螢幕後發熱，開啟 Clash 的日誌頁並依時間排序。正常待機可能出現少量連線、規則集檢查或網路變化記錄；異常情況通常會呈現同一個錯誤每隔幾秒重複一次。

重點辨識四類重複記錄

1. DNS timeout：上游解析無法連線，核心持續等待並嘗試其他伺服器。
2. connection refused：本機連接埠或遠端服務拒絕連線，某個應用程式仍在快速重試。
3. network changed：Wi-Fi 訊號不佳或雙卡數據切換，導致通道反覆重建。
4. provider update failed：訂閱或規則集位址無法連線，且更新週期設定得過短。

先將日誌層級維持在 info。debug 或 trace 會產生更多日誌寫入，只適合短時間重現問題。記錄 5 至 10 分鐘後恢復一般層級，並保存錯誤出現時間、網路類型與對應應用程式。

分應用程式代理也可用於定位問題。先讓 Clash 只處理瀏覽器，鎖定螢幕觀察；若耗電恢復正常，再分批加入社交、影音與同步工具。加入某一批後背景連線數量明顯增加，就檢查該批應用程式的推播、自動播放、雲端備份或輪詢設定。代理負責轉發連線，但發起頻率通常由具體應用程式決定。

一套從低風險到高影響的排查順序

不要同時修改十幾個開關，否則無法判斷哪個步驟有效。依照以下順序執行，每一步至少觀察一個完整的 8 小時待機週期。

1. 建立關閉 Clash 與開啟 Clash 的待機基準，確認額外掉電比例。
2. 將 URL-Test 間隔提高至 600 秒以上，訂閱更新改為每 12 至 24 小時一次。
3. 關閉用戶端延遲面板，將日誌層級恢復為 info。
4. 檢查 DNS timeout、provider 更新失敗與網路切換循環。
5. 精簡重複規則集，將規則提供器週期改為 86400 秒。
6. 透過分應用程式代理，定位持續產生背景連線的應用程式。
7. 允許 Clash 背景活動與自動啟動，避免省電策略反覆終止服務。
8. 確實有全天連線需求時，再啟用系統的「永遠開啟的 VPN」。

最後還要排除用戶端版本與設定檔不相容。升級基於 mihomo 的用戶端後，如果舊設定檔立即觸發當機或循環重新啟動，可先匯出設定檔，再新建一份只包含一個節點、一個策略組與基礎 MATCH 規則的最小設定檔。最小設定檔待機正常，表示問題集中在原設定檔；最小設定檔仍異常，則繼續檢查用戶端版本、系統 VPN 權限與品牌背景策略。

Android 代理長時間常開的合理目標是：VPNService 穩定、鎖定螢幕後連線不中斷、測速與更新以低頻執行，裝置不持續發熱。背景時間長不等於高耗電，VPN 圖示常駐也不代表故障。透過比較測試、日誌與逐項修改來定位問題，通常比反覆清理程序更快得到穩定結果。