iPhone 執行 Clash 耗電異常：背景運作機制與省電設定

先瞭解 Clash 為何能在鎖定螢幕後繼續運作

iPhone 上的 Clash 類型客戶端通常會透過 iOS Network Extension 建立本機 VPN。啟用連線後，網頁、即時通訊與系統服務產生的網路資料會先進入封包隧道，再由 Clash 核心依照規則決定直連、代理或拒絕。即使主應用程式退到背景，甚至被系統從最近使用的 App 中清除，負責隧道的網路延伸功能仍可繼續運作。這就是鎖定螢幕後代理連線不會立即中斷的原因，也是電池頁面可能持續記錄網路活動的原因。

在背景運作不代表螢幕熄滅後會一直滿載執行。沒有網路請求時，延伸功能大部分時間應處於等待狀態；收到推播、照片同步、郵件更新或應用程式請求時，才需要處理連線、查詢 DNS、比對規則並轉送資料。實際耗電量取決於傳輸量、喚醒頻率、節點品質、DNS 設定、記錄層級及策略群組檢查。

鎖定螢幕後仍會出現的正常網路活動

• 即時通訊應用程式維持連線並接收推播。
• iCloud 照片、檔案或裝置備份繼續上傳。
• 郵件帳號執行背景擷取，系統服務同步時間與帳號狀態。
• 策略群組依設定的間隔執行 URL 測試或節點健康檢查。
• 規則提供者、代理提供者或訂閱到達更新週期後發出請求。
• 隨需連線規則偵測到目標網路變更並重新建立隧道。

因此，在「設定」→「電池」清單中看到 Clash，不能直接證明耗電異常。iOS 顯示的是選定時段內各項目的相對比例：其他 App 使用量很少時，網路延伸功能即使只消耗少量電力，也可能顯示較高比例。判斷時還應綜合電量下降幅度、背景活動時間、行動網路訊號與實際流量。

如何分辨正常耗電與異常耗電

最有效的方法不是盯著單次百分比，而是進行一組條件固定的對照測試。開始前將電量充至 80% 以上，關閉正在下載的內容，暫停照片同步，保持螢幕熄滅，並確保兩輪測試使用相同的 Wi-Fi、相同位置與接近的時間長度。電量低於 20% 時，系統調度策略會改變，不適合用來比較。

進行一次 30 分鐘對照測試

1. 前往「設定」→「電池」，確認最近一小時沒有大型遊戲、影片匯出或系統更新。
2. 連線至穩定的 Wi-Fi，關閉個人熱點，將 Clash 切換至常用設定與規則模式。
3. 鎖定螢幕靜置 30 分鐘，記錄開始與結束時的電量，同時查看 Clash 對應的背景活動。
4. 關閉 Clash 的 VPN 連線，在相同網路下再靜置 30 分鐘。
5. 兩輪測試各重複一次，避免電量顯示取整造成誤判。

30 分鐘測試中的 1 個百分點只是排查觸發線，並非所有 iPhone 的統一標準。電池容量、健康度、環境溫度與電量顯示取整都會影響結果。更可靠的異常訊號包括：鎖定螢幕後持續發熱、每小時穩定下降數個百分點、背景網路流量明顯增加，或執行記錄每隔幾秒重複出現相同的連線錯誤。

電池頁面應該查看哪些欄位

在「設定」→「電池」中切換至「顯示活動」，分別查看「螢幕開啟」與「背景」活動。若 Clash 只顯示較長的背景時間，但整台裝置耗電量下降很少，通常只是網路延伸功能保持可用。若背景時間、耗電比例與行動數據同時升高，才需要繼續定位。行動數據可在「設定」→「行動服務」中查看，測試前後記錄數值，比單看百分比更直觀。

高頻健康檢查是常見的耗電來源

URL 測試策略群組會定期存取檢測網址，比較候選節點的回應結果。代理提供者也可以設定健康檢查。單次請求的流量通常很小，但若設定包含 40 個節點、檢查間隔為 30 秒，理論上每小時可能觸發約 4,800 次節點探測。網路狀況不佳時，還會疊加 DNS、TCP 或 TLS 重試，造成頻繁喚醒。

行動裝置沒有必要將策略群組重新整理設為每幾秒一次。日常使用可先將自動測試間隔調整為 600 秒；線路變化較少時可設為 900 秒。只有在手動排查節點時，才暫時執行一次測試。對於 Clash Meta（mihomo）相容設定，也可以同時啟用延遲檢查的惰性行為，讓目前未使用的策略減少主動測試。

proxy-groups:
  - name: 自動選擇
    type: url-test
    use:
      - mobile-provider
    url: http://www.gstatic.com/generate_204
    interval: 600
    tolerance: 100
    lazy: true

proxy-providers:
  mobile-provider:
    type: http
    url: https://example.com/subscription.yaml
    path: ./providers/mobile.yaml
    interval: 86400
    health-check:
      enable: true
      url: http://www.gstatic.com/generate_204
      interval: 600
      lazy: true

範例中的訂閱網址只代表欄位位置，實際使用時請保留現有的有效網址。interval: 600 表示每 600 秒檢查一次，tolerance: 100 表示候選延遲差異不足 100 毫秒時不頻繁切換。提供者的 interval: 86400 表示每 24 小時更新一次設定檔，這與節點健康檢查的間隔不是同一項設定。

客戶端介面的調整順序

1. 前往「設定」→「參數設定」，尋找延遲測試、健康檢查或策略群組測試間隔。
2. 先將低於 60 秒的週期調整為 600 秒，觀察半天。
3. 關閉未使用策略群組的自動測試，只保留一個主要的自動選擇群組。
4. 更新訂閱後只手動測試一次，不要連續點擊完整測速。

不同客戶端的欄位名稱可能略有差異。如果介面沒有提供對應開關，應在確認設定由自己維護後再編輯 YAML。訂閱服務自動產生的設定可能在下次更新時覆寫本機修改，可以使用客戶端的覆寫功能保留間隔設定。

精簡規則、DNS 與記錄負擔

規則數量並非越少越快。Clash 核心會使用適合的資料結構處理網域與 IP 規則，幾千條正常規則通常不會單獨造成明顯耗電。更值得處理的是重複規則集、頻繁更新的遠端規則、過多的腳本邏輯，以及將所有連線都送入複雜處理鏈的設定。行動裝置應優先保留明確且穩定的分流需求。

規則設定先處理三個問題

• 刪除失效的遠端規則集：持續請求無法連線的網址會產生逾時與重試。
• 減少重複的提供者：同一網域分類不必從多個來源分別載入。
• 延長更新週期：穩定的規則集可使用 86400 秒的更新週期，不需要每 10 分鐘擷取一次。

rule-providers:
  direct-sites:
    type: http
    behavior: domain
    format: yaml
    path: ./rules/direct-sites.yaml
    url: https://example.com/direct-sites.yaml
    interval: 86400

規則仍會依照由上到下的順序比對。高頻且明確的本地域名規則可以放在較前方，最後保留 MATCH 作為後援。不要為了省電任意刪除區域網路直連、系統服務或 DNS 相關規則，否則連線失敗後的重複嘗試反而可能增加喚醒次數。

DNS 設定避免過多並行請求

設定多個 nameserver 與 fallback，不代表每次查詢都會全部依序執行，但複雜的回退與過濾會增加請求量。行動裝置通常保留 2 個穩定的主要 DNS 即可。使用加密 DNS 時，也要確認對應伺服器在目前網路中可連線；若伺服器經常逾時，每次網域解析都可能等待並重試。

dns:
  enable: true
  ipv6: false
  enhanced-mode: fake-ip
  nameserver:
    - 223.5.5.5
    - 119.29.29.29

是否關閉 IPv6 應依目前網路狀況判斷。電信商網路與家用寬頻都穩定支援 IPv6 時，可以保留；若記錄中持續出現 IPv6 連線逾時，而實際代理節點只提供 IPv4，再考慮關閉。不要只憑耗電感受就同時更改 DNS、節點與規則，否則無法確認是哪項設定發揮作用。

記錄層級維持在 info 或 warning

debug 記錄適合短時間定位規則命中、DNS 請求與連線失敗，不適合全天開啟。大量連線會持續產生記錄，並增加記憶體與儲存操作。排查結束後，將記錄層級恢復為 info；設定穩定且客戶端支援時，也可以使用 warning。問題尚未重現前不要清空記錄，先截取 3 至 5 分鐘的重複片段更有價值。

如何設定隨需連線與 TUN 模式

隨需連線可在符合條件時自動啟用 VPN，例如離開家用 Wi-Fi 後連線，回到信任的網路後中斷。規則簡單時，能減少手動操作；條件互相衝突時，則可能在 Wi-Fi 與行動網路切換、路由器訊號波動或裝置喚醒時反覆建立隧道。

為隨需連線保留明確條件

• 只依已知 Wi-Fi 的 SSID 或網路類型判斷，避免多條範圍重疊的規則。
• 不要同時設定「所有 Wi-Fi 連線」與「指定 Wi-Fi 中斷」，卻忽略規則順序。
• 若出現每隔幾十秒重新連線的情況，先關閉隨需連線 30 分鐘進行對照。
• 經常在捷運、電梯或地下停車場切換網路時，可暫時關閉自動重新連線，測試耗電是否有所變化。

如果全天都需要規則分流，維持一次穩定連線通常比頻繁連線與中斷更節省資源。若只在少數 App 或特定網路中使用，則可透過清楚的隨需條件縮短隧道運作時間。省電的目標不是讓 VPN 盡可能頻繁重啟，而是減少不必要的活躍處理與失敗重試。

TUN 模式本身不等於異常耗電

iOS 上的全域網路接管通常依賴系統提供的封包隧道能力，客戶端介面可能稱為 VPN、TUN 或增強模式。它需要處理系統流量，因此比只為單一 App 設定 HTTP 代理的涵蓋範圍更廣，但正常閒置時不應持續高負載。真正需要檢查的是 UDP 工作階段數量、連線循環、DNS 逾時與節點丟包。

如果設定同時啟用流量嗅探，可先確認是否確實有依網域還原的需求。嗅探會讀取連線初始資訊，以協助規則判斷；連線量很大時會增加處理負擔。關閉前要檢查設定是否依賴嗅探取得的網域，否則部分規則可能退化為 IP 比對，或落入後援策略。

節點與行動網路訊號也會放大耗電

節點交握失敗、丟包與長距離鏈路會使連線反覆重傳。此時表面上是 Clash 消耗電力，實際原因可能是代理伺服器無法連線或目前網路品質不佳。先選擇穩定節點，停止自動切換，再觀察記錄中是否反覆出現 timeout、connection reset、TLS handshake timeout 等錯誤。

用具體數值判斷節點狀態

• 在相同 Wi-Fi 下連續測試 5 次，如果結果在 80 至 130 毫秒間小幅變化，通常比一次 60 毫秒、下一次 900 毫秒更穩定。
• 在丟包環境中，單次延遲低也不代表適合長連線。語音通話、推播反覆中斷時，應更換線路進行驗證。
• 節點連續 3 次逾時後先停用，不要讓自動策略每 30 秒重新探測。
• 在訊號微弱的區域測試時，將行動網路暫時固定為 LTE 進行對照，避免 5G 與 LTE 頻繁切換干擾結果。

查看行動網路模式可前往「設定」→「行動服務」→對應門號→「語音與數據」。此選項是否顯示及其名稱會因電信商而異。固定 LTE 只適合作為排查步驟；確認問題與網路切換無關後，可以恢復原本的自動設定。

依序完成一次省電排查

同時更改十個選項會讓結果失去參考價值。以下順序優先處理最常見、也最容易復原的因素。每完成一步，至少觀察 30 分鐘；涉及待機耗電時，最好觀察 6 至 8 小時。

1. 確認背景流量：暫停照片、雲端硬碟與系統更新，排除實際的大量資料傳輸。
2. 固定一個穩定節點：暫時退出自動選擇，觀察是否仍會發熱或快速掉電。
3. 延長檢查間隔：將健康檢查與 URL 測試設為 600 秒，關閉重複測速群組。
4. 檢查記錄：尋找每隔幾秒重複出現的 DNS 逾時、交握失敗或隧道重建。
5. 關閉隨需連線進行對照：確認是否由 Wi-Fi 與行動網路切換觸發連線循環。
6. 恢復正常記錄層級：從 debug 調回 info 或 warning。
7. 檢查遠端資源：移除失效的規則提供者，將穩定資源的更新週期設為 86400 秒。
8. 重建 VPN 設定：只有前述步驟無效時，才刪除舊的 VPN 設定，並由客戶端重新建立。

刪除 VPN 設定前，應先保存目前的訂閱網址、覆寫規則與策略選擇。路徑為「設定」→「一般」→「VPN 與裝置管理」→「VPN」，點開對應設定後執行刪除。重新開啟客戶端並允許加入 VPN 設定即可復原。不要刪除企業或工作帳號使用的其他 VPN。

何時應更新客戶端或核心

如果異常是在某次客戶端更新後開始，先查看該版本的變更記錄；若使用較舊版本，也應升級至下載頁提供的目前穩定版本。Clash Meta（mihomo）核心會持續修正協定、DNS 與網路堆疊問題，但設定相容性也可能改變。升級前匯出設定，升級後先使用原設定測試，不要在同一次操作中同時升級並大幅修改規則。

何時更像是電池或系統問題

關閉 Clash 後仍持續發熱，或「設定」→「電池」中多個系統項目同時出現長時間背景活動，問題可能不在代理設定。檢查「設定」→「電池」→「電池健康度與充電」中的最大容量；容量明顯下降、裝置剛完成系統升級或照片正在重新建立索引時，待機耗電都會改變。重新啟動裝置後再進行一次相同條件的對照，比反覆刪除訂閱更有效。

常見問題

排查 iPhone 上的 Clash 耗電問題，關鍵是分清「網路延伸功能保持連線」與「持續高負載」的差異。先在固定條件下進行對照，再處理高頻健康檢查、失效遠端資源、節點重新連線與複雜的隨需規則。每次只調整一個變數，才能找出真正影響續航力的設定。