Clash 手機耗電異常排查：背景執行、系統限制與省電設定

在手機上開啟 Clash 或採用相容 Mihomo 核心的用戶端後，系統通常會持續顯示 VPN 圖示。這個圖示只代表裝置的網路連線正通過本機 VPN 介面，不能直接證明代理用戶端是電量下降的唯一原因。實際耗電的環節可能是行動網路反覆重新連線、某個 App 持續傳輸、DNS 查詢過於頻繁、節點連線不穩，也可能是系統不斷終止並重新啟動背景服務。

排查時應先分清楚「電池用量占比高」與「實際耗電速度快」。如果手機一整天只消耗少量電力，Clash 在 App 清單中的百分比仍可能看起來很高，因為系統顯示的是該時段的耗電占比，而非額外耗掉的電量。反之，待機時機身發熱、每小時電量持續明顯下降，或行動網路活動長時間未歸零，才比較接近需要處理的異常狀態。

持續啟用 VPN 為何會列入耗電統計

Android 與 iOS 上的 Clash 類用戶端，通常透過系統 VPN 介面接管網路流量。App 會將裝置送出的封包讀入本機虛擬網路介面，再依設定處理 DNS、比對規則並轉送代理。即使規則結果是 DIRECT，流量仍可能先通過這條本機處理路徑。因此，系統會把部分網路活動、CPU 使用時間與背景執行時間計入 VPN 用戶端。

持續執行不等於持續高負載

裝置鎖定且沒有活躍連線時，正常的本機 VPN 服務可以維持低活動狀態。少量連線保活、健康檢查或系統切換網路，會讓服務偶爾被喚醒，但不應長時間占用大量 CPU。若待機耗電明顯，重點不是只看「背景執行了幾小時」，而是檢查這段期間是否伴隨大量流量、頻繁喚醒、節點重新連線或高頻率記錄日誌。

行動網路比穩定的 Wi-Fi 更容易放大差異。行動訊號較弱時，基頻晶片需要提高發射功率；網路在 Wi-Fi 與行動數據之間來回切換時，代理連線也可能重新建立。此時電池頁面可能把部分活動歸到代理用戶端，但根本原因其實是網路環境與連線重建共同造成。

規則模式仍有運算成本

規則模式會依網域名稱、IP、程序資訊或規則集決定連線去向。一般設定中的單次比對成本通常很低，不會只因規則數量多就立刻造成明顯耗電。不過，過大的規則集、重複規則、過多遠端規則提供者、頻繁更新，以及持續進行網域嗅探，都會增加記憶體用量與背景活動。問題通常來自多項功能疊加，而不是某一條 DOMAIN-SUFFIX 規則。

先判斷問題來自用戶端、設定檔或其他 App

有效的排查方式是一次只變更一個變因。如果同時關閉 TUN、刪除規則、切換節點並修改省電設定，雖然可能暫時降低耗電，卻無法確認是哪一步生效。建議先備份目前可正常使用的設定，再依下列順序進行對照測試。

1. 確認統計期間。查看系統電池頁面的時間範圍，排除剛完成系統升級、App 更新、照片備份或大型檔案下載的時段。
2. 記錄實際耗電速率。在相同網路下關閉螢幕待機 30 至 60 分鐘，記下起訖電量、裝置溫度，以及是否持續上傳或下載。
3. 檢查流量來源。在用戶端的連線頁面中，查看是否有某個 App 反覆建立連線。瀏覽器分頁、雲端硬碟、照片同步、即時通訊備份與影音 App，都可能持續在背景運作。
4. 改用穩定節點。選擇已確認可連線的節點，暫時停用會頻繁自動切換的策略群組，觀察重新連線次數是否下降。
5. 改用精簡設定進行對照。只保留必要的 DNS、少量規則與單一代理策略，並關閉不必要的偵錯功能。若耗電恢復正常，再逐項加入規則集、嗅探與健康檢查。
6. 最後再對照關閉 VPN。只有比較相同環境下關閉代理後的數據，才能判斷本機 VPN 路徑是否造成可測量的差異。

查看連線清單比只看節點延遲更有用

節點延遲測試只代表某次探測請求的回應時間，不能證明背景沒有持續流量。如果連線清單中每隔幾秒就出現相同網域，應先確認它屬於哪個 App，再判斷是推播、廣告請求、遙測、同步，還是失敗後重試。無法完成交握的背景工作可能不斷建立新連線；即使單次流量很少，也會頻繁喚醒網路與 CPU。

如果鎖定螢幕後連線數量仍持續增加，可以暫時關閉最近安裝或更新的 App 進行對照。也可切換至 DIRECT 策略觀察：如果請求仍持續出現，代表流量是由終端 App 產生；如果只在特定代理節點下重複出現，則應檢查節點穩定性、通訊協定相容性與遠端連線狀態。

設定層面常見的高頻耗電來源

健康檢查間隔過短

url-test、fallback 等策略群組可透過探測網址判斷節點狀態。健康檢查本身有其用途，但當節點很多、間隔又很短時，用戶端會定期向每個候選節點發出請求。數十個節點持續以分鐘為間隔進行測試，帶來的不是單次延遲測試，而是一整天反覆發生的網路喚醒。

手機應依實際需求適度延長檢查間隔，並減少不會用到的候選節點。若用戶端支援按需或延遲偵測，可讓策略群組在需要時再檢查，但具體欄位仍應以目前核心與用戶端文件為準。不要直接從其他設定片段複製不熟悉的參數，因為不同版本支援的策略群組欄位可能不同。

偵錯日誌長期維持詳細層級

詳細日誌適合在連線失敗時觀察 DNS、規則命中與代理交握，不適合長期作為日常設定。大量連線產生的日誌需要格式化並寫入記憶體或檔案，也會讓診斷頁面持續更新。問題重現完成後，可將日誌層級調回用戶端建議的日常層級，並清除容量異常的歷史日誌。

如果只有開啟日誌頁面時，耗電與溫度才明顯上升，原因可能是介面持續繪製新記錄，不一定是核心轉送本身。離開日誌頁面、鎖定螢幕後再次測試，即可快速區分介面更新與背景網路處理。

DNS 失敗與循環查詢

DNS 設定錯誤可能導致網頁開啟緩慢、App 反覆重試，以及相同網域遭頻繁查詢。尤其在網路切換、私人 DNS、系統加密 DNS 與用戶端 DNS 同時介入時，需要確認各查詢路徑沒有互相阻擋。Mihomo 的 fake-ip 模式會將網域映射至保留位址，再由核心還原網域並套用規則；看到保留位址本身並不代表異常。

排查 DNS 時，先選擇一組目前網路可以連線的解析器，確認一般網域能穩定解析後，再恢復複雜的分流解析。不要只為省電就隨意關閉 IPv6 或更改所有 DNS 伺服器，這類修改可能掩蓋真正的網路問題，也可能讓部分 App 等待逾時後才改用另一種通訊協定。

嗅探、程序比對與大型規則集

網域嗅探可以從連線中還原網域資訊，讓沒有直接網域資訊的流量也能比對規則；程序比對則需要用戶端與系統提供對應能力。這些功能都有明確用途，但不宜在手機上同時開啟所有進階功能，再判斷基本耗電狀況。可以先保留網域與 IP 規則，確認運作穩定後，再加入嗅探與程序規則。

遠端規則集的更新頻率也值得檢查。規則提供者通常不需要在短時間內反覆下載。如果訂閱或規則網址無法連線，用戶端可能依內部機制重試；此時應修正網址、網路路徑或更新週期，而不是讓失敗的工作持續留在背景執行。

Android 背景執行限制與省電設定

各 Android 手機廠牌管理背景服務的方式差異很大。Clash 類用戶端通常需要以前景 VPN 服務維持虛擬網路介面，通知列中的常駐通知是系統機制的一部分。如果系統將用戶端列為嚴格限制對象，鎖定螢幕後可能會終止服務；當用戶端或系統接著嘗試恢復 VPN，就會發生斷線、重新連線與重複初始化。

建議檢查的系統項目

• 電池使用策略：將用戶端設為允許背景執行，或排除嚴格限制。不同廠牌可能稱為「不受限制」、「允許背景活動」或「忽略電池最佳化」。
• 自動啟動與關聯啟動：如果系統提供獨立開關，應確保裝置重新啟動或 VPN 遭系統回收後，用戶端能依使用者設定恢復運作。
• 背景數據：允許用戶端使用背景數據。如果只能在前景連網，鎖定螢幕後代理交握與 DNS 請求可能會失敗。
• 一律開啟的 VPN：只有確實需要全時連線時才啟用。啟用後，系統會持續維護指定的 VPN；如果同時選擇「封鎖未使用 VPN 的連線」，用戶端異常結束時，其他 App 也會無法上網。
• 通知權限：部分系統會將前景服務通知與服務管理連動。保留必要的 VPN 狀態通知，更容易判斷服務是否遭到終止。

將用戶端設為不受限制，不代表它會持續以高負載運作，而是避免系統在錯誤時機終止 VPN。穩定維持一條閒置連線，通常比每隔一段時間就銷毀並重建核心、虛擬網路介面與代理連線更平穩。不過，如果用戶端本身持續產生流量，不受限制也會讓這些活動長時間執行，因此仍須搭配連線清單與流量統計判斷。

TUN 模式與系統 VPN 的關係

在 Android 上，圖形介面用戶端所稱的 TUN 模式通常建立於系統 VPN API 上，用來接收更多類型的 IP 流量。相較於只設定 HTTP 或 SOCKS 代理，它的涵蓋範圍更廣，因此會有更多 App 的連線顯示在用戶端統計中。涵蓋範圍擴大後，總流量與喚醒次數可能增加，但不能因此直接斷定「TUN 必然造成異常耗電」。

如果只有少數支援系統代理的 App 需要連線，可以對照測試系統代理模式；如果需要 UDP、不支援代理設定的 App，或完整的規則分流，則較適合使用 TUN。選擇時應以需要涵蓋的流量為依據。發生異常時，應先檢查具體連線、DNS 與節點重試，而不是把關閉 TUN 當成唯一解法。

iOS 背景執行與低耗電模式

iOS 上相容 Clash 的用戶端透過 Network Extension 提供 VPN 功能。使用者離開用戶端畫面後，VPN 延伸功能仍可處理網路流量，因此「App 不在前景」不代表代理已經停止。系統負責管理延伸功能的執行與資源，電池統計則可能將相關活動計入用戶端或網路用量。

低耗電模式會減少部分背景活動，但不保證正在使用的 VPN 會自動關閉。只要其他 App 繼續連網，VPN 延伸功能就需要處理對應連線。如果照片同步、雲端硬碟上傳、Podcast 下載或 App 更新集中進行，代理用戶端的耗電占比也可能隨之升高。

檢查隨選連線與網路切換

部分用戶端支援隨選連線規則，例如使用行動網路、指定 Wi-Fi 或網路變更時自動啟用 VPN。規則彼此衝突時，可能導致連線狀態頻繁切換。可以暫時關閉隨選規則，改為手動連線，並在穩定的 Wi-Fi 環境觀察一段時間；若耗電與斷線狀況改善，再逐項恢復各項網路條件。

從 Wi-Fi 切換至行動網路時，現有的 TCP、UDP 或 QUIC 連線可能需要重新建立。短時間出現網路活動屬於正常現象，但如果裝置靜置後仍不斷切換，應檢查 Wi-Fi 訊號、自動加入熱點設定，以及節點能否透過兩種網路穩定連線。

不要反覆清除背景 App

從 App 切換器滑掉用戶端，不一定會如預期般關閉 VPN 延伸功能，實際行為取決於用戶端實作與系統狀態。如果要進行關閉代理的對照測試，應在用戶端或系統 VPN 設定中明確中斷連線。反覆結束再重開 App，會觸發讀取設定、檢查訂閱狀態與初始化連線，不利於取得穩定的測試結果。

iOS 的電池統計適合觀察數小時或一整天的趨勢，不適合用幾分鐘內的百分比下結論。建議同時查看螢幕關閉期間的活動、行動數據用量與裝置溫度。如果只有某個網路環境發生異常，可重新連接該網路，或檢查 DNS、路由器與節點連線狀態，而不是先刪除所有設定。

依現象執行排查流程

情況一：待機耗電快，但流量很少

1. 離開用戶端的日誌、連線監控與即時測速頁面。
2. 暫停自動延遲測試，以及間隔過短的策略群組健康檢查。
3. 確認系統沒有頻繁終止並重新啟動 VPN 服務。
4. 改用穩定節點，觀察交握失敗與重新連線是否減少。
5. 使用精簡設定測試一小時，再逐項恢復進階功能。

情況二：待機期間仍有大量流量

1. 在連線清單中依網域、目標位址或 App 來源排序。
2. 暫停雲端硬碟、照片、媒體快取與系統更新，進行對照測試。
3. 檢查訂閱與遠端規則是否處於重複下載狀態。
4. 確認 DNS 失敗未導致 App 持續重試。
5. 分別使用 DIRECT 與代理策略，觀察請求是否仍持續出現。

情況三：只有使用行動網路時發熱

1. 查看行動網路訊號強度，並在訊號穩定的位置重新測試。
2. 關閉不必要的背景同步，減少大型檔案上傳與下載。
3. 選擇可透過目前電信業者網路穩定連線的節點。
4. 避免策略群組在多個節點之間頻繁自動切換。
5. 檢查 IPv4、IPv6 與 DNS 路徑是否發生長時間逾時。

情況四：鎖定螢幕後斷線，解鎖後恢復

1. Android 應檢查電池最佳化、背景數據、自動啟動與前景服務通知。
2. iOS 應檢查隨選連線規則，以及低耗電模式下的實際運作狀況。
3. 確認用戶端未設定為只在前景維持連線。
4. 查看系統是否在網路切換後撤銷 VPN 權限。
5. 保留一份能正常運作的精簡設定，排除設定載入失敗。

省電調整的合理範圍

手機省電的目標不是關閉所有背景功能，而是在保有所需分流能力的前提下，減少無意義的喚醒。日常設定可遵循四項原則：只保留實際會使用的節點、讓健康檢查間隔符合使用頻率、問題排除後將偵錯日誌恢復至日常層級，以及依合理週期更新遠端規則與訂閱。

節點通訊協定、加密運算與網路實作也會影響處理成本，但在實際使用情境中，螢幕、行動網路訊號、傳輸資料量與 App 行為通常影響更明顯。不要只憑通訊協定名稱判斷耗電，也不要用單次測試比較兩個節點。應在相同網路與相近流量下持續觀察，並記錄重新連線次數與裝置溫度。

如果更換設定後立刻發生異常，可以先還原上一份正常設定，再比較新增的規則提供者、策略群組、DNS 與嗅探設定。如果所有設定都在同一用戶端版本出現異常，應檢查系統更新、用戶端更新與 VPN 權限；如果只有特定網路環境有問題，則將重點放在訊號、路由器、DNS 與節點連線狀態。

完成排查後，建議保留一份簡短記錄，包括測試網路、用戶端版本、核心類型、設定變更、起訖電量與觀察時間。日後更新用戶端或訂閱後若再次發生問題，就能快速判斷變化來自系統、軟體或設定，不必從頭猜測。