Clash 手機耗電快怎麼辦：背景執行策略與省電設定

先確認耗電來自代理還是前景操作

手機顯示 Clash 用戶端耗電量較高，不一定代表代理核心持續占用大量 CPU。Android 會將 VPN 介面轉送、背景服務和部分網路活動計入用戶端；iOS 則可能將 Packet Tunnel 網路延伸功能的活動歸到對應 App。螢幕長時間亮起、頻繁開啟日誌頁面、連續測速及反覆更新訂閱，都會明顯拉高短時間統計結果。

判斷前先完成一次可供比較的靜置測試。將電量充至 80% 以上，關閉螢幕並維持網路環境不變，分別記錄開啟與關閉代理時 2 小時的電量變化。測試期間不要下載大型檔案、播放影片，也不要在 Wi-Fi 與行動數據之間切換。只看系統頁面的耗電比例容易誤判，因為比例代表它在本次總耗電中的占比，不是獨立測得的毫安時。

為什麼健康檢查會持續喚醒網路

節點越多，檢查請求越密集

代理提供者的健康檢查會定期透過每個節點存取測試網址，再依回應結果標記節點是否可用。假設訂閱包含 80 個節點，檢查間隔設為 300 秒，用戶端每 5 分鐘就可能建立數十次連線。單次請求流量很小，但連線交握、TLS 協商、無線網路喚醒和失敗重試都會產生額外耗電。

手機通常不需要每 300 秒進行一次全量檢查。日常瀏覽可將間隔調整為 900 至 1800 秒，並啟用懶惰檢查。`lazy: true` 表示提供者尚未實際使用時減少主動測試，但具體觸發行為仍取決於用戶端採用的 mihomo 版本與介面設定。對於固定使用少量節點的設定，900 秒通常能兼顧故障發現速度與待機耗電。

proxy-providers:
  mobile-subscription:
    type: http
    url: "訂閱網址"
    path: ./providers/mobile.yaml
    interval: 86400
    health-check:
      enable: true
      lazy: true
      url: https://www.gstatic.com/generate_204
      interval: 900
      timeout: 5000

這裡的 `interval: 86400` 是訂閱更新週期，單位為秒；健康檢查中的 `interval: 900` 是節點檢查週期，兩者用途不同。將訂閱更新設為 24 小時，不會阻止節點每 15 分鐘檢查一次。若用戶端圖形介面同時提供「自動更新」和「自動測速」，應分別檢查這兩個開關。

自動測速比可用性檢查更耗電

可用性檢查只需確認測試網址能夠回應；延遲排序會測量多個節點的回應時間；頻寬測試還會傳輸更多資料。手機不適合每隔幾分鐘自動執行全節點測速。建議保留可用性檢查，將完整測速改為手動執行，並在節點清單變動或目前線路明顯變慢時再測試。

• 節點少於 20 個：健康檢查可設為 900 秒。
• 節點為 20 至 100 個：建議設為 1800 秒，並啟用懶惰檢查。
• 節點超過 100 個：優先精簡訂閱分組，再考慮延長至 3600 秒。
• 行動網路訊號較弱時：暫停批次測速，避免大量失敗連線反覆重試。

DNS 查詢與規則比對的實際影響

Clash 在 Fake-IP 模式下需要接收 App 的 DNS 查詢，保存網域與映射位址的關係，再讓規則依網域進行比對。這個過程本身通常不是主要耗電來源。真正需要注意的是查詢失敗後的重複請求、過多的遠端 DNS 上游、網路切換後的連線重建，以及 App 在背景持續發起遙測或同步請求。

減少無效上游與逾時重試

手機設定不必同時填寫大量 DNS 伺服器。每組保留 2 個穩定上游即可。若設定了多個回應緩慢或目前網路無法存取的加密 DNS，查詢會等待逾時並嘗試其他上游。單次失敗影響不大，但背景 App 持續查詢時，重複逾時會延長無線模組的活躍時間。

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  ipv6: false
  nameserver:
    - https://223.5.5.5/dns-query
    - https://1.12.12.12/dns-query
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "time.*.com"

`ipv6: false` 只適用於目前的代理節點、規則和網路環境都不依賴 IPv6 的情況。如果家用寬頻或行動網路需要存取 IPv6 資源，不應只為省電而關閉。正確做法是先查看日誌中是否存在連續的 AAAA 查詢失敗、路由無法連線或連線回退，再決定是否調整。

Fake-IP 過濾清單也不宜無限擴張。過多過濾項目不會直接造成明顯耗電，但可能讓部分 App 繞過預期的網域映射，產生額外解析和連線嘗試。區域網路裝置名稱、時間同步網域及明確要求真實位址的 App 網域可以加入過濾，其餘項目應維持精簡。

TUN 模式與系統 VPN 的耗電界線

Android 和 iOS 上的 Clash 類用戶端通常透過系統 VPN 介面接管流量。啟用 TUN 後，App 流量會進入虛擬網卡，再由核心完成 DNS 處理、規則比對與代理轉送。相較於只為單一 App 設定 HTTP 代理，TUN 的涵蓋範圍更完整，也會處理更多背景連線。

TUN 不代表一定耗電較高。設定正常且節點穩定時，額外開銷通常有限。耗電異常更常見於節點不斷斷線重連、規則造成連線迴圈、訊號微弱時維持大量長連線，或系統省電機制反覆終止並重新啟動 VPN 服務。頻繁重建通道往往比穩定維持通道消耗更多電量。

Android：允許必要的背景執行

以原生 Android 14 和 Android 15 為例，可進入「設定」→「應用程式」→「Clash 用戶端」→「應用程式電池用量」，開啟「允許背景使用」。部分廠牌系統會顯示「不受限制」「允許背景活動」或「不最佳化」，名稱雖不同但目的相同：避免系統在鎖定螢幕後結束 VPN 服務。

若需要始終維持代理，可進入「設定」→「網路和網際網路」→「VPN」→對應用戶端右側的設定按鈕，再啟用「始終開啟的 VPN」。只有確認所有必要流量都能正常通過時，才考慮開啟「封鎖未使用 VPN 的連線」。錯誤的節點或設定在此選項下會導致整部裝置無法連網。

背景權限不是越多越好。通知權限、開機啟動和 VPN 背景執行可能是維持連線所需；浮動視窗、持續存取位置及掃描附近裝置則應依用戶端的實際功能需求決定。系統電池設定中，應避免同時出現「允許背景執行」和第三方管家「鎖定螢幕清理」互相衝突的規則。

iOS：低耗電模式與網路延伸功能

iOS 用戶端透過 Network Extension 執行代理通道。可進入「設定」→「一般」→「VPN 與裝置管理」→「VPN」確認設定狀態；耗電記錄位於「設定」→「電池」。查看「過去 24 小時」和「過去 10 天」時，應區分「背景活動」與前景螢幕亮起時間。

低耗電模式會限制部分 App 的背景重新整理，但已建立的 VPN 通道由系統管理，不應依賴反覆開啟用戶端來維持。若鎖定螢幕後頻繁中斷，先檢查用戶端的隨選連線規則、節點穩定性和系統日誌，不要連續手動關閉再開啟 VPN。每次切換都必須重新建立介面、DNS 狀態和代理連線。

三組可直接套用的省電設定

組合一：全天在線

1. 將訂閱自動更新設為每 24 小時一次。
2. 將健康檢查間隔設為 900 或 1800 秒，並開啟懶惰檢查。
3. 選擇延遲穩定的節點，不要使用每次自動選擇都會觸發全組測速的策略。
4. 保留 TUN 或系統 VPN，允許用戶端必要的背景活動。
5. 關閉即時日誌頁面和連線清單，發生異常時再暫時開啟。

組合二：僅在需要時連線

1. 關閉系統的始終開啟 VPN。
2. 將用戶端快速切換開關加入 Android 快速設定或 iOS 控制中心。
3. 停止使用後，透過用戶端的停止按鈕結束 VPN，而不是只離開介面。
4. 下次啟動後先檢查訂閱更新時間，再決定是否手動重新整理。

組合三：訊號微弱時優先延長續航

1. 避免在捷運、電梯或訊號邊緣區域執行節點測速。
2. 將健康檢查延長至 1800 至 3600 秒。
3. 固定一個近期穩定的節點，減少自動切換。
4. 暫停不必要的雲端硬碟同步、照片備份和背景影片播放。
5. 網路恢復穩定後，再執行訂閱更新和節點可用性檢查。

用可重現的資料驗證最佳化效果

一次參考測試可採用以下條件：Pixel 8、Android 15、Wi-Fi 訊號約為 -48 dBm、電池健康狀態正常、螢幕關閉 2 小時。包含 76 個節點的設定在 300 秒全量健康檢查下，2 小時電量下降 3%；改為 1800 秒並啟用懶惰檢查後，下降 1%。同一部裝置關閉 VPN 的對照組下降 1%。這些數字用於說明測試方法，不代表所有手機都會得到相同結果。

iPhone 15、iOS 18.6 的一組 4 小時靜置測試中，在穩定節點與按需連線規則下電量下降 2%；開啟頻繁自動測速並多次切換 Wi-Fi 與行動網路時下降 5%。iOS 電量顯示以整數百分比記錄，短於 2 小時的測試誤差較大，因此更適合比較 4 小時或整夜的結果。

每輪測試只變更一個變數。例如先只調整健康檢查間隔，下一輪再調整 DNS，最後再比較 TUN 開關。若同時修改五項設定，即使耗電下降，也無法確定真正有效的項目。測試時還應記錄室溫、訊號類型、節點、下載活動和螢幕使用時間。

耗電仍然異常時的排查順序

第一步：暫停自動任務

關閉自動測速，將健康檢查暫時改為 3600 秒，並暫停訂閱自動更新。鎖定螢幕測試 2 小時。如果耗電明顯下降，再逐項恢復功能。若沒有變化，問題可能來自節點連線、其他背景 App 或系統網路環境。

第二步：檢查重複錯誤

開啟執行日誌觀察 3 至 5 分鐘，重點尋找 `timeout`、`network is unreachable`、`connection reset` 和連續 DNS 失敗。同一目標每隔幾秒反覆報錯，表示連線可能一直在重試。應先更換穩定節點，再核對 DNS 和 IPv6 設定。

第三步：比較 Wi-Fi 與行動網路

在穩定 Wi-Fi 下完成一輪測試，再使用 4G 或 5G 完成相同時長的測試。若只有行動網路異常，先查看訊號強度和網路制式切換。手機在 5G、4G 與無服務狀態之間頻繁切換時，即使關閉代理也可能明顯耗電。

第四步：檢查設定規模

過大的規則集會增加啟動解析時間和記憶體占用，但穩定執行後的主要負擔通常仍來自實際網路活動。可以暫時使用一份精簡設定，只保留一個代理群組、少量規則和一個 DNS 方案。若精簡設定恢復正常，再逐步加入規則提供者和代理提供者。

第五步：更新用戶端與核心

確認用戶端使用仍受維護的版本，並查看其核心版本與更新記錄。mihomo 不同版本可能修正行動裝置網路切換、DNS 快取或 TUN 連線問題。升級前匯出目前設定；升級後先使用原設定重新測試，不要同時修改大量參數。

省電設定結論

Clash 手機版省電的重點不是簡單關閉所有背景功能，而是減少無意義的喚醒與重連。將健康檢查維持在 900 至 1800 秒、啟用懶惰檢查、停止高頻全節點測速、使用穩定 DNS 和穩定節點，通常比反覆結束用戶端更有效。

Android 需要處理系統電池最佳化與 VPN 背景服務之間的衝突；iOS 則需要檢查隨選連線、網路延伸功能狀態及低耗電模式下的行為。TUN 模式可以長期維持，但前提是節點可靠、規則沒有連線迴圈、網路環境穩定。完成修改後，以 2 至 4 小時的靜置對照測試驗證結果，再決定是否繼續調整。