Clash 行動版耗電異常排查：背景執行、電池最佳化與連線策略

一、先建立可比較的耗電基準

直接查看「過去 24 小時」的電池排行，容易受到螢幕使用、影片播放、行動網路訊號與系統更新影響。建議選擇使用方式相近的一段時間，例如夜間待機兩小時或日常辦公一小時，分別測試關閉代理、僅啟用系統代理功能，以及啟用 TUN 或 VPN 接管後的變化。測試期間盡量維持相同網路、相同節點與相同的應用程式活動。

記錄四項關鍵資訊

1. 電量變化：記錄開始與結束時的電量，不要只看用戶端在系統統計中的百分比排行。排行是相對值，其他應用程式使用量較少時，代理用戶端即使耗電不高，也可能排在前面。
2. 裝置溫度：螢幕關閉後仍持續溫熱，通常表示存在反覆重連、大量日誌、密集測速或異常網路請求。
3. 服務連續性：觀察 VPN 圖示是否反覆消失、代理是否要等到解鎖螢幕後才恢復，以及用戶端日誌中是否在短時間內重複出現啟動記錄。
4. 網路條件：區分 Wi-Fi、行動網路、弱訊號與網路切換情境。行動網路訊號不佳時，基頻本身就會增加耗電，不能全部歸因於 Clash。

如果啟用代理後的電量變化只略高於基準，且沒有發熱或服務重啟，通常不需要繼續壓縮所有功能。過度限制背景活動反而可能導致系統終止 VPN 服務，接著由用戶端或系統重新啟動，形成「停止—啟動—重新建立連線」的循環，最後比穩定運作消耗更多電量。

二、檢查背景執行與系統電池最佳化

Android 廠商通常會同時提供系統級電池最佳化、應用程式背景活動限制、自動啟動管理與省電模式。不同入口可能會疊加生效：即使允許用戶端在背景執行，系統的深度省電策略仍可能在螢幕關閉後限制網路；即使允許自動啟動，應用程式也可能因被歸入「受限制」電池模式而停止 VPN 服務。

Android 的檢查順序

1. 開啟系統的應用程式資訊，找到目前使用的 Clash 或 mihomo 圖形化用戶端。
2. 進入電池或耗電管理，將應用程式從「受限制」調整為允許背景活動的模式。不同系統可能顯示為「不受限制」、「允許背景執行」或類似名稱。
3. 檢查自動啟動、關聯啟動與背景彈出介面等廠商擴充選項。這裡只需確保系統能在服務被回收後依正常機制恢復，不必同時開啟與代理無關的權限。
4. 確認系統省電模式是否會關閉 VPN、限制背景網路或延後排程工作。測試時先退出極致省電模式。
5. 在最近使用的任務介面鎖定應用程式只能作為輔助手段。部分系統仍會依電池策略回收服務，因此不能取代應用程式的電池設定。

如果問題表現為「鎖定螢幕十幾分鐘後斷網，亮起螢幕進入用戶端後又恢復」，應優先懷疑背景網路或 VPN 服務受到限制。如果表現為「代理一直可用，但用戶端背景活動時間很長」，則應繼續檢查健康檢查、訂閱更新、日誌層級與節點重連，而不是直接關閉背景權限。

頻繁重啟通常比持續常駐更耗電

代理服務啟動時需要讀取設定、載入規則集、初始化 DNS、建立虛擬網路介面並連線至節點。如果系統每隔一段時間回收服務，用戶端就必須重複完成這些操作。若日誌中連續出現設定載入、VPN 建立、介面建立與節點連線記錄，表示重點應放在系統背景策略或用戶端穩定性，而不是單純追求更短的背景常駐時間。

三、比較連線模式、節點穩定性與重連行為

行動版用戶端通常會透過系統 VPN 介面接管流量，其作用接近 Clash 設定中的 TUN 模式，但具體實作取決於用戶端與作業系統。相較於只讓少數應用程式讀取系統代理設定，VPN 或 TUN 的接管範圍更廣，需要處理更多連線、DNS 請求與路由判斷，因此固定耗電可能較高。行動版應用程式是否提供模式切換，應以用戶端實際選項為準。

TUN 或 VPN 模式為何可能增加耗電

• 所有經過虛擬介面的連線都必須由核心讀取並依規則比對，包括部分系統服務與背景應用程式的流量。
• UDP、即時通訊與長連線可能需要維持工作階段狀態，網路切換後也可能重新建立。
• DNS 劫持、Fake IP 或增強 DNS 模式會增加本機查詢處理，但它們本身不一定會導致異常耗電，關鍵在於是否出現查詢迴圈、逾時重試或設定衝突。
• 行動網路與 Wi-Fi 切換時，舊連線會失效，新連線需要重新選擇出口。節點握手緩慢會放大這個階段的耗電。

如果用戶端支援只代理指定應用程式或略過區域網路流量，可以依實際需求縮小接管範圍。例如不需要代理的本機投影、列印服務或區域網路儲存存取，可以使用直連。不要為了省電任意排除需要代理的系統元件，否則可能造成部分應用程式無法連網、DNS 路徑不一致或連線外洩至錯誤出口。

節點不穩定是常見的隱性原因

節點延遲高不一定代表耗電高，但頻繁逾時與中斷會觸發重試、策略群組重新選擇，以及應用層連線重建。可以先固定一個已確認穩定的節點，暫時不要使用會頻繁切換的自動策略群組，觀察一段時間。如果溫度與背景活動明顯下降，再檢查策略群組的測試網址、測試間隔與切換門檻。

url-test 會依設定的間隔測試候選節點，並選擇符合條件的結果；fallback 著重可用性，會在目前節點失效時切換；load-balance 會依策略分配連線。節點數量很多、測試間隔很短時，週期性探測會產生額外的網路喚醒。行動版不需要把數十個節點都放進高頻自動測試群組，可以先篩選常用地區與品質穩定的節點。

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

上例僅用於說明控制候選數量與檢測頻率的思路，不代表所有訂閱都應採用相同數值。測試網址必須能穩定回傳預期結果；如果所在網路無法可靠存取該網址，用戶端會持續得到失敗結果，進而重複檢測或切換節點。

四、縮小規則、DNS 與週期性工作的排查範圍

規則數量多不代表一定會異常耗電。mihomo 會針對不同規則類型採用相應的比對方式，正常維護的規則集即使規模較大，通常也比網路重試造成的影響穩定。需要關注的是規則提供者頻繁更新、設定重複載入、複雜腳本行為、DNS 查詢迴圈，以及日誌持續寫入。

檢查規則提供者的更新週期

遠端規則集與訂閱需要定期請求檔案並重新載入。若多個規則提供者都設定了很短的更新間隔，行動裝置會頻繁喚醒網路。對變動不頻繁的網域或 IP 規則集，通常沒有必要每隔幾分鐘更新一次。先查看設定中的 rule-providers、訂閱自動更新與用戶端定時重新整理選項，確認沒有重複工作。

rule-providers:
  direct-list:
    type: http
    behavior: domain
    url: https://example.invalid/rules/direct.yaml
    path: ./ruleset/direct.yaml
    interval: 86400

範例中的網址只展示欄位結構。實際設定應使用訂閱或規則維護方提供的有效網址。調整更新週期後，需要重新載入設定，並觀察日誌中的規則下載與設定重新整理是否仍在短時間內重複出現。

辨識 DNS 重試與解析迴圈

DNS 設定異常時，常見表現包括網頁首次開啟緩慢、日誌中反覆查詢同一網域、節點網域無法解析，以及切換網路後長時間沒有連線。若加密 DNS 伺服器本身必須透過代理存取，而代理節點網域又依賴相同的解析路徑，就可能形成啟動依賴問題。應為節點解析保留可用的基礎 DNS 路徑，並依用戶端與核心文件設定 default-nameserver、nameserver 和代理伺服器網域解析。

Fake IP 模式會為網域分配虛擬位址，再由核心保存網域與連線的對應關係。它通常能改善規則比對與透明代理相容性，但部分區域網路服務、特殊應用程式或探測網域可能需要加入過濾清單。過濾範圍過寬會降低模式效果，過窄則可能讓不相容的應用程式不斷重試。排查時應針對日誌中反覆失敗的具體網域處理，不要直接複製過大的過濾清單。

降低除錯日誌造成的持續寫入

詳細日誌適合短時間定位故障，不適合長期維持。若日誌層級設為 debug，大量連線、DNS 與規則比對資訊可能持續寫入儲存空間，也會增加介面重新整理負擔。完成診斷後可恢復為 info、warning 或用戶端建議的日常層級。清理歷史日誌只能釋放空間，真正影響後續行為的是日誌層級與記錄頻率。

五、Android 與 iOS 的背景機制差異

Android：重點檢查 VPN 服務是否被回收

Android 用戶端通常透過 VpnService 建立本機 VPN。系統通知列中的常駐通知通常與前景服務有關，能讓系統知道該網路服務正在持續執行。若手動關閉通知權限、限制背景活動或啟用廠商的深度休眠，可能影響服務穩定性。具體行為取決於系統版本與用戶端實作，因此應結合系統電池記錄與用戶端日誌判斷。

Android 還可以查看應用程式崩潰、無回應或啟動次數等系統資訊。若用戶端本身頻繁退出，先升級至適用目前系統版本的穩定版本，並確認同一份設定是否能正常載入。設定檔過大、語法錯誤或記憶體壓力都可能造成啟動失敗，但不能只憑「代理中斷」就推斷核心崩潰。

iOS：區分應用程式介面與網路延伸功能

iOS 上的相容用戶端通常透過 Network Extension 提供代理或 VPN 功能。應用程式介面進入背景後，網路延伸功能仍可由系統管理，因此從多工介面移除應用程式，不一定等同於按下用戶端內的停止按鈕來結束通道。電池統計也可能將部分網路活動歸入用戶端、系統網路服務或正在傳輸資料的應用程式。

排查 iOS 耗電時，應檢查低耗電模式、行動網路品質、隨選連線規則與用戶端內的節點測試計畫。若設定了隨選連線，網路環境變化會觸發規則評估；若同時設定高頻健康檢查，在 Wi-Fi 與行動網路之間頻繁切換時，連線重建會更加明顯。測試階段可固定網路並暫停非必要的節點測試，再比較電池曲線。

無論使用哪個平台，都不建議照搬另一個系統的背景設定名稱。應圍繞三個事實進行檢查：代理通道是否保持連續、系統是否反覆終止服務、設定是否持續觸發網路工作。設定入口不同，但診斷邏輯一致。

六、分階段完成行動版耗電排查

階段一：確認是否與代理直接相關

1. 在相同網路環境下，記錄一段關閉代理後的待機電量。
2. 啟用代理並固定單一穩定節點，不進行下載、影片播放或大規模同步。
3. 比較掉電量、溫度與背景活動。若差異很小，應繼續觀察更長週期，不要根據短時間的百分比波動下結論。

階段二：排除系統反覆回收

1. 允許用戶端正常在背景執行，並退出系統極致省電模式。
2. 觀察鎖定螢幕後代理是否中斷，解鎖後是否重新出現啟動日誌。
3. 若服務頻繁恢復，請檢查電池最佳化、自動啟動、背景網路與 VPN 權限。

階段三：減少週期性網路工作

1. 暫停訂閱自動重新整理與遠端規則集的高頻更新。
2. 減少自動策略群組的候選節點，延長健康檢查間隔。
3. 將日誌從除錯層級恢復為日常層級。
4. 固定一個穩定節點，排除節點逾時與策略群組反覆切換。

階段四：檢查 DNS 與接管範圍

1. 查看日誌中是否存在連續 DNS 逾時、重複查詢相同網域或節點網域解析失敗。
2. 確認基礎 DNS 能在代理尚未建立時完成必要解析。
3. 依需求調整應用程式略過、區域網路直連與 TUN 接管範圍，每次調整後重新測試。

階段五：恢復功能並驗證

找到明顯改善耗電的變數後，不要立即結束測試。逐項恢復訂閱更新、策略群組與原有規則，每恢復一項就觀察一段時間。如果恢復某項後異常重新出現，就能進一步縮小範圍。例如只有啟用某個自動策略群組後才發熱，應檢查該群組的節點數量、測試網址與間隔，而不是刪除整份設定。

結論：穩定運作優先於過度限制背景活動

Clash 行動版耗電異常通常不是由單一開關造成，而是系統電池限制、VPN 服務重啟、不穩定節點重連、密集健康檢查、訂閱重新整理與 DNS 逾時共同作用的結果。最有效的處理方式是先建立關閉代理與穩定代理的對照基準，再檢查服務是否連續運作，接著減少週期性工作並驗證 DNS 與節點品質。

對需要全天維持代理的裝置而言，穩定常駐往往比反覆終止與恢復更省電。對只在特定情境使用代理的裝置，則可以在用戶端內主動停止服務。完成設定後至少觀察一個完整的日常使用週期，並分別記錄 Wi-Fi 與行動網路的表現，才能得到可靠結論。