Clash Android 後台耗電嚴重怎麼辦：省電設定與後台保活平衡

先確認是正常常駐，還是異常耗電

Clash、Clash Meta for Android、FlClash 等用戶端啟動代理後，會透過 Android 的 VpnService 建立本機 VPN 介面。狀態列持續顯示鑰匙或 VPN 圖示，只代表介面處於啟用狀態，不等於處理器一直維持高負載運作。螢幕關閉後，穩定連線通常只保留前景服務、少量連線狀態與必要的網路喚醒。

判斷耗電是否異常，應同時查看電量下降幅度、後台活動時間與行動網路狀態。只看到電池頁面中 Clash 排名靠前，不能直接下結論。若一段時間內主要只有這個網路應用程式在運作，它自然會占有較高的耗電比例。

使用固定條件進行一次 8 小時基準測試

1. 將電量充至 80% 以上，記錄測試開始時間。
2. 維持同一個 Wi-Fi 或行動數據環境，測試期間不要頻繁切換網路。
3. 關閉影片播放、遊戲、雲端相簿同步與系統更新等明顯負載。
4. 保持 Clash 連線，關閉主動測速與設定檔編輯頁面，然後鎖定螢幕放置 8 小時。
5. 測試結束後開啟「設定」→「電池」→「電池用量」，記錄 Clash 的耗電量、後台活動時間及系統閒置耗電。

以一台電池健康度正常、容量約 5000 mAh 的裝置為例，在穩定 Wi-Fi 下鎖定螢幕 8 小時下降 2%–5%，通常不值得單獨處理。若下降達到 10% 以上，或電池頁面顯示用戶端持續在後台高負載運作，應繼續檢查延遲測試、重連迴圈、訂閱更新與 TUN 參數。不同晶片、訊號強度、系統版本及推播數量都會改變結果，這組數值適合用於排查，不是所有裝置的統一標準。

優先降低延遲測試與訂閱輪詢頻率

後台耗電最常見的來源不是 VPN 介面本身，而是週期性網路工作。策略群組中的 url-test、fallback 與負載平衡健康檢查會按間隔存取測試網址。節點越多，每輪測試需要建立的 DNS 查詢、TCP 連線與 TLS 工作階段就越多。包含 80 個節點的策略群組每分鐘測試一次，與每十分鐘測試一次相比，後台喚醒次數可能相差一個數量級。

將自動測速從 60 秒調整為 300–600 秒

在支援編輯策略群組參數的用戶端中，可檢查「設定」→「覆寫」或「設定」→「設定檔覆寫」中的健康檢查選項。不同用戶端的選單名稱可能有所差異。日常固定網路環境可將 interval 設為 300 秒；節點數量超過 50 個時，可先嘗試 600 秒。經常在 Wi-Fi 與行動網路之間切換的裝置，可維持 300 秒，避免失效節點長時間留在目前策略中。

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

lazy: true 表示策略群組未被實際使用時，減少不必要的健康檢查；是否生效取決於目前核心與用戶端對設定欄位的支援。tolerance: 80 可避免兩個節點只相差幾十毫秒時頻繁切換。頻繁切換會重建連線，對穩定性與耗電都沒有幫助。

不要把手動測速當成後台監控

• 節點清單中的「全部測速」適合用於確認故障，不適合長時間反覆點選。
• 單次測試先選擇目前的策略群組，不必同時測試訂閱中的所有節點。
• 測試逾時可設為約 5000 ms。逾時時間過長會讓失效節點占用更久的檢測時間。
• 連續執行三輪測速所得的細微差異，通常來自網路抖動，不需要因此頻繁更換節點。

訂閱自動更新維持每小時或每天一次

訂閱內容通常不會每分鐘變更。將自動更新間隔設為 1440 分鐘，也就是每天一次，已足以應付多數使用情境。節點提供者明確要求更短週期時，可改為 360 或 720 分鐘。若將訂閱更新設為每 15 分鐘一次，就會重複下載設定、解析 YAML、重建策略群組，並可能觸發節點健康檢查。

處理廠商省電策略，避免終止程序後反覆重連

將 Clash 強制限制在後台，看似可以省電，實際上可能適得其反。系統終止前景服務後，用戶端、自動化工作或網路變化又會將其喚醒，VPN 介面需要重新建立，DNS 與現有連線也必須重新初始化。反覆發生的「終止—喚醒—重連」比穩定常駐產生更多處理器喚醒與網路握手。

Android 原生系統與 Pixel 系列

開啟「設定」→「應用程式」→「Clash 用戶端」→「應用程式電池用量」，將後台用量設為「允許」。如果系統提供「最佳化」「受限制」「不受限制」三個選項，持續使用 VPN 時可選擇「不受限制」。不同 Android 版本的入口可能顯示為「設定」→「應用程式」→「特殊應用程式存取權」→「電池最佳化」。

小米與 HyperOS 裝置

• 進入「設定」→「應用程式設定」→「應用程式管理」→「Clash 用戶端」→「省電策略」，選擇「無限制」。
• 開啟系統「安全中心」→「應用程式管理」→「權限」→「自動啟動管理」，允許用戶端自動啟動。
• 在最近使用的工作畫面長按用戶端卡片並鎖定，降低一鍵清理導致服務終止的機率。

Samsung One UI 裝置

• 進入「設定」→「電池」→「背景使用限制」。
• 確認用戶端不在「深度睡眠應用程式」清單中。
• 需要長時間連線時，將用戶端加入「永不自動休眠的應用程式」。

OPPO、OnePlus 與 realme 裝置

通常可在「設定」→「應用程式」→「應用程式管理」→「Clash 用戶端」→「耗電管理」中啟用「允許背景活動」。部分版本還需要進入「設定」→「應用程式」→「自動啟動」，允許自動啟動。選單文字會隨 ColorOS 或 realme UI 版本變更，可在系統設定頂端搜尋「背景活動」或「電池最佳化」。

完成白名單設定後，不要再疊加自動清理工具。穩定後台的目標是讓一個 VPN 服務低頻運作，而不是讓系統每隔幾分鐘重新建立服務。若調整前的記錄中頻繁出現服務啟動、網路變更或設定重新載入，完成白名單設定後應明顯減少。

依需求選擇 TUN 模式、系統代理與 DNS 參數

Android 上的 Clash 用戶端通常透過 VpnService 接管流量，但用戶端內部仍可能提供不同的 TUN 堆疊、應用程式分流、DNS 增強與嗅探選項。功能越多不代表必須全部啟用。省電調整應以實際流量接管需求為界線。

只代理常用應用程式時，先設定應用程式分流

如果只有瀏覽器、即時通訊與少量工具需要代理，可在「設定」→「網路」→「存取控制」或「設定」→「VPN 服務」→「應用程式分流」中選擇需要接管的應用程式。排除本機影片播放器、區域網路投放、系統備份與大型遊戲下載程式後，可以減少不需要進入代理核心的連線數。

存取控制通常有「僅允許選取的應用程式」與「排除選取的應用程式」兩種邏輯。修改後應分別開啟一個代理應用程式與一個遭排除的應用程式進行驗證。不要同時啟用含義相反的清單，也不要批次排除 Android 系統元件，否則可能出現 DNS 查詢與實際連線路徑不一致。

TUN 堆疊以穩定為先，不要連續疊加參數

mihomo 核心常見的 TUN 堆疊包括 system、gvisor 與 mixed。具體可選項目取決於用戶端與核心版本。system 傾向使用系統網路堆疊，效能開銷通常較低；gvisor 使用使用者態網路堆疊，在部分相容情境中有其價值，但處理路徑較長；mixed 會依協定組合處理。不存在適用於所有裝置的固定最省電選項。

1. 保留用戶端預設堆疊，完成一次 8 小時閒置測試。
2. 只有在特定應用程式無法連線、UDP 異常或連線頻繁中斷時，才切換至另一個堆疊。
3. 每次只修改一個參數，清除舊記錄並重新連線。
4. 比較電量、斷線次數與記錄中的錯誤，不要只比較網頁開啟速度。

DNS 與嗅探設定維持最小必要範圍

fake-ip 會為網域回傳映射位址，再由核心依據映射關係執行規則比對。它本身不等於高耗電，但過大的規則集、重複 DNS 查詢、無法連線的上游 DNS 與持續逾時都會增加後台活動。出現耗電異常時，應檢查記錄中是否持續出現 DNS timeout、fallback 重試或同一網域的高頻查詢。

網域嗅探用於從連線中還原網域資訊，適合處理無法直接取得網域的流量。若目前規則已能正確比對，且沒有透明接管的相容性問題，不必為了參數齊全而擴大嗅探連接埠與協定範圍。關閉或縮小非必要功能後，應驗證影片、遊戲、訊息推播與區域網路存取是否正常。

mode: rule

dns:
  enable: true
  enhanced-mode: fake-ip
  ipv6: false

tun:
  enable: true
  stack: system
  auto-route: true
  strict-route: false

這段設定僅用於展示排查時需要注意的欄位，不應直接覆蓋現有訂閱。部分 Android 用戶端會透過圖形設定產生 TUN 參數，訂閱更新也可能覆蓋手動修改。實際調整前應複製目前的 Profile，並在副本中測試。

檢查網路切換、弱訊號與並行 VPN 衝突

行動網路訊號微弱時，基頻本身就會增加耗電。Clash 在 Wi-Fi 與行動數據之間切換後，還需要遷移或重建連線，因此通勤、地下停車場與雙 SIM 弱訊號環境中的耗電，不能全部歸因於代理用戶端。測試時可比較同一路線下「關閉 VPN」與「開啟 VPN」的兩次結果，並讓螢幕使用時間盡量接近。

關閉其他會占用 VPN 介面的服務

Android 同一位使用者通常只能維持一個主要 VPN 連線。防火牆、反追蹤工具、企業 VPN 與其他代理用戶端也可能使用 VpnService。多個應用程式輪流請求連線時，會表現為鑰匙圖示消失後再次出現、通知反覆重新整理、網路短暫中斷以及用戶端重新載入。

• 在「設定」→「網路與網際網路」→「VPN」中確認目前使用中的 VPN。
• 暫時關閉其他 VPN、防火牆或本機過濾服務，觀察 2 小時。
• 不要同時為兩個代理用戶端啟用「一律開啟的 VPN」。
• 若已啟用「封鎖未使用 VPN 的連線」，更換用戶端前先關閉此選項，避免切換期間完全無法上網。

檢查循環重連的記錄特徵

進入用戶端的「記錄」頁面，將層級維持在 info。正常閒置時，新增記錄的速度應該很低。若每隔幾十秒反覆出現 network changed、start service、reload configuration、DNS timeout 或連線逾時，應依時間順序找出觸發來源。排查階段不建議長時間使用 debug 層級，詳細記錄會增加寫入量，也會讓關鍵事件更難辨識。

如果重連只發生在螢幕關閉後，優先檢查電池最佳化與 Wi-Fi 休眠策略；如果固定每 60 秒發生，優先檢查健康檢查間隔與自動化工作；如果只在行動數據下出現，請檢查訊號、雙 SIM 切換、IPv6 與電信商網路的可達性。

一套可執行的省電調整順序

同時修改十幾個開關會失去對照條件。更穩妥的做法是從高頻工作開始，每完成一組調整就觀察至少半天。以下順序兼顧連線可靠性與排查效率。

1. 保留目前的設定副本。複製正在使用的 Profile，記錄核心版本、目前節點、TUN 堆疊與 DNS 模式。
2. 停止反覆測速。將健康檢查間隔改為 300–600 s，啟用受支援的延遲檢查。
3. 降低訂閱輪詢頻率。將自動更新調整為 720–1440 min，手動更新後確認設定能正常載入。
4. 設定後台白名單。允許後台活動、自動啟動與前景 VPN 服務穩定運作，並移出深度休眠清單。
5. 排除 VPN 衝突。關閉其他使用 VpnService 的應用程式，只保留一個使用中的用戶端。
6. 縮小接管範圍。透過應用程式分流排除不需要代理的大流量應用程式。
7. 最後調整 TUN。只有前述步驟無效時，才逐一比較 system、mixed 或用戶端提供的其他堆疊。

調整後的驗收標準

• 鎖定螢幕 8 小時內沒有週期性斷線通知。
• 記錄不再以固定的短間隔反覆載入設定或啟動服務。
• 電池頁面中的後台活動與實際 VPN 使用時間相符。
• 訊息推播、瀏覽器、終端機應用程式與區域網路存取都能依預期分流。
• Wi-Fi 與行動數據切換後，可在數秒內恢復連線，不需要手動重新啟動用戶端。

若完成所有步驟後，閒置耗電仍明顯高於關閉 VPN 時的基準，可新建一份只包含少量節點與基本規則的測試設定。測試設定正常時，問題多半位於原訂閱的策略群組、健康檢查或規則規模；測試設定仍異常時，再考慮用戶端版本、系統韌體或裝置網路模組的相容性問題。升級用戶端前記錄目前版本並備份設定，升級後使用同一組條件重新測量，才能判斷變更是否有效。