Android Clash Meta 耗電異常：背景常駐、電池最佳化白名單與 TUN 取捨

先分清流量耗電、背景重啟與耗電統計歸因

先觀察手機實際掉電速度，再查看 Clash Meta 在電池用量中的排名。Android VPN 會集中處理其他應用程式的連線，系統可能將部分網路活動計入 VPN 應用程式；「耗電占比最高」不代表核心一直滿載運作。持續下載、雲端相簿備份、播放影片和行動網路訊號微弱，都可能比代理處理本身更耗電。

Clash Meta 是用戶端與核心相關的名稱，mihomo 則是常見的核心名稱。不同 Android 用戶端的設定入口、設定覆寫方式和背景服務實作各有差異。排查前請記下用戶端版本、核心版本、Android 版本和目前的設定檔名稱；不要將 Linux 上的 systemd 常駐設定或 TUN 權限指令直接套用到手機。

在相同條件下記錄兩組數據

選擇穩定的 Wi-Fi，維持相同訊號、螢幕亮度和背景同步設定。先暫停下載與備份，避開剛開機、系統更新或充電後機身發熱的時段。
進行一輪 60 分鐘的螢幕關閉測試，記下起始與結束電量、是否斷線，以及裝置是否發熱。關閉代理的對照測試應維持相同的應用程式負載；若應用程式因無法連網而停止同步，這輪結果就不能直接比較。
再用相同應用程式進行相同時間的螢幕開啟測試。影片畫質、遊戲影格率或網路制式若有變動，就要重新建立基準。

例如，記錄顯示 60 分鐘內從 80% 降到 77%，代表這輪下降了 3 個百分點；這只是計算範例，並非 Clash Meta 的實測基準。電池百分比有進位誤差，單次下降 1% 不適合用來判斷最佳化效果。至少重複測試兩輪，並一併記錄機身溫度、重新連線次數和通知是否即時送達。

健康檢查：先拉長間隔，再處理重複測速

節點測速會發出網路請求。節點數量多、測速間隔短時，即使沒有主動瀏覽，也會產生週期性連線。在行動網路下，這些請求還可能讓無線模組頻繁離開低耗電狀態。先檢查 proxy-providers 的健康檢查，再確認 url-test、fallback 等策略群組是否也在執行相同測試。

欄位	用途	排查起點
`health-check.interval`	Provider 節點健康檢查間隔，單位為秒	先試 900 秒
`health-check.lazy`	Provider 未使用時略過週期性檢查	視需求設為 true
`proxy-providers.*.interval`	HTTP 類型 Provider 的設定更新間隔	可從 86400 秒開始測試
`proxy-groups.*.interval`	自動選擇類策略群組的測試間隔	確認是否與 Provider 重複

以下是合併至現有 Provider 項目的局部欄位，並非完整訂閱設定。保留該項目原有的 type、url、path 和健康檢查 url；測試網址請沿用已確認可連線的網址，不要為了套用範例而任意更換。

interval: 86400
health-check:
  enable: true
  interval: 900
  lazy: true

例如，原本每 60 秒測試 80 個節點，若每輪都完整執行，連續一小時理論上約會進行 4800 次節點測試；改為 900 秒後則約為 320 次。此估算不包含重試、首次載入和手動測速，也不等於實際 HTTP 請求數或省電比例。節點不穩定時，可以先設為 300 秒，再逐步權衡切換速度與背景活動。

訂閱更新和節點測速要分開調整。每天更新設定，不代表節點每天才檢查一次；兩者的 interval 位於不同層級。
減少重複檢查。同一批節點同時被多個自動選擇群組引用時，請逐一檢查各群組的設定；不要只修改 Provider，就以為所有自動探測都已停止。
確認實際生效的設定。用戶端的覆寫、訂閱更新和介面設定都可能覆蓋檔案內容。重新載入後，請查看執行中的設定或記錄，確認檢查頻率。

記錄、面板與失敗重試：避免持續背景活動

日常使用可先設為 info，排查耗電時再試試 warning，並縮短詳細記錄的保留時間。debug 適合短時間重現問題，不適合整夜開著觀察。記錄輸出量會受到連線數量與用戶端實作影響，調整記錄層級並不代表能按固定比例省電。

log-level: warning

關閉持續更新的連線清單、即時速率圖和外部控制面板。螢幕關閉後用戶端是否仍更新這些畫面，取決於實際實作；可以先離開面板再重新測試。若機身溫度明顯下降，還要進一步確認差異是來自介面更新、寫入記錄，還是網路流量本身。

只開啟詳細記錄幾分鐘，檢查重複事件

連線逾時反覆出現：先換用較穩定的節點，再觀察重試是否減少。縮短逾時時間不一定比較省電；失敗後若連續重連，反而可能更頻繁。
DNS 請求失敗反覆出現：確認上游是否可連線、是否透過失效節點連線，以及是否發生解析迴圈。不要只靠不斷增加 DNS 上游來處理。
設定反覆載入或核心不斷啟動：優先檢查背景限制、用戶端當機和自動切換指令碼，不要繼續縮短測速間隔。

分享記錄前，請移除訂閱網址、驗證資訊、節點密碼和存取網域。記錄只要涵蓋一次從斷線到恢復的過程即可，通常不必提供一整天的完整內容。恢復穩定後，請將記錄層級調回日常使用值。

電池最佳化白名單：用於維持背景運作，不是省電開關

白名單的用途是減少系統對背景執行的限制。它可能改善螢幕關閉後斷網、VPN 被終止和排程工作延遲等問題，但不會自動降低耗電。如果用戶端原本運作穩定，就不必為了「省電」而開啟所有自動啟動、背景活動和高耗電權限。

反過來說，若應用程式不斷被系統停止又重新啟動，也會反覆建立 VPN、解析網域名稱並連線至節點。若出現「螢幕一亮就恢復、關閉螢幕幾分鐘後就斷線」，應先確保服務穩定，再評估健康檢查等週期性工作。

系統	常見設定位置	應觀察的結果
Pixel／接近原生 Android	設定 → 應用程式 → Clash Meta → 應用程式電池用量 → 允許背景使用	必要時選擇不受限制，並檢查螢幕關閉時的連線狀態
小米 MIUI／HyperOS	應用程式資訊 → 省電策略 → 無限制；在設定中搜尋「背景自動啟動」	確認手機重新啟動後是否能如預期啟動
Samsung One UI	設定 → 應用程式 → Clash Meta → 電池 → 不受限制	檢查應用程式是否被加入休眠或深度休眠清單
OPPO / OnePlus	應用程式資訊 → 耗電管理 → 允許背景活動	檢查服務在螢幕關閉後是否仍持續執行
vivo / iQOO	設定 → 電池 → 背景耗電管理	視需要允許背景高耗電和自動啟動

以上是常見的選單名稱，實際名稱可能因 Android 版本、地區韌體和廠商版本而異。找不到設定時，可長按應用程式圖示進入「應用程式資訊」，或在系統設定中搜尋「電池最佳化」、「背景活動」或「自動啟動」。在最近使用的應用程式中鎖定應用程式只是部分品牌提供的額外措施，不能取代電池權限設定。

Android VPN 與 TUN：先判斷需要接管哪些應用程式

Android 用戶端通常透過系統的 VpnService 建立虛擬網路介面，再將資料交由代理核心處理。這和 Linux 上啟用 tun.enable、設定路由及授予網路權限的部署方式不同。介面中的「VPN 模式」也不一定對應到可直接編輯的同一個 YAML 開關。

如果需要讓瀏覽器、聊天工具和不支援代理設定的應用程式都能分流，透過 VPN 接管通常更實用。若只有少數支援手動代理的應用程式需要連網，可以比較「本機代理連接埠」和 VPN 模式；但要先確認用戶端是否支援單獨啟動代理服務，以及目標應用程式是否確實使用該代理。

縮小接管範圍時的三個注意事項

依應用程式排除不需要代理的流量。在用戶端的「存取控制」或「依應用程式代理」中選擇應用程式，並確認目前設定的是「僅代理所選應用程式」還是「略過所選應用程式」。名單的涵義相反時，實際接管的範圍會完全不同。
規則中的 DIRECT 不等於略過 VPN。資料仍可能先進入虛擬介面，再由核心判斷是否直接連線。依應用程式排除通常會更早生效，但實際行為和 DNS 處理方式仍需測試。
本機連接埠不能取代完整 VPN。例如，只有用戶端確實在 127.0.0.1:7890 監聽時才能使用；Android 的 Wi-Fi HTTP 代理不會涵蓋所有應用程式和 UDP，也不會自動套用到行動網路。

不要只為了少一層處理就貿然關閉 VPN。先列出必須正常運作的應用程式，再測試通知、網頁、語音通話和行動網路切換。部分用戶端允許選擇使用者空間網路堆疊，名稱和支援範圍請以目前版本為準。沒有適用所有手機、最省電的網路堆疊；切換後需要重新建立 VPN，並重新測試 UDP、IPv6 和網域名稱解析。

系統的「一律使用 VPN」和「封鎖未使用 VPN 的連線」主要用於連線策略，不是效能最佳化設定。後者可能導致已排除的應用程式無法直接連線。測試依應用程式略過代理前，請先檢查這兩個選項，避免將系統主動封鎖誤判為規則失效。

使用系統電池記錄與 ADB 確認背景行為

優先開啟「設定 → 電池 → 電池用量」，查看代理用戶端的前景時間、背景時間，以及各時段的流量。不同品牌的統計方式不一，背景時間長只能表示服務持續執行，不能單獨證明異常。手機在網路穩定、螢幕關閉時仍持續發熱，才值得進一步檢查忙碌迴圈或大量重試。

如果有電腦，可在啟用 USB 偵錯並授權連線後，執行下列唯讀指令。ADB 可從 Android SDK Platform-Tools 取得，這些檢查不需要 root 權限。輸出內容可能很長，建議先存到電腦，再依程序名稱、UID 和時間範圍搜尋。

adb devices
adb shell pm list packages | grep -i clash
adb shell dumpsys battery
adb shell dumpsys batterystats --charged > battery-session.txt
adb shell dumpsys deviceidle > deviceidle-session.txt
adb shell dumpsys connectivity > connectivity-session.txt

grep 是電腦端的篩選指令；Windows PowerShell 可用 Select-String clash 取代。如果套件名稱不含 clash，第一個篩選條件可能找不到結果；此時需要在完整套件清單中，依用戶端的實際套件名稱搜尋。不要直接複製其他用戶端的套件名稱來解讀統計資料。

dumpsys battery：確認電量、充電狀態和溫度欄位；常見的溫度單位是攝氏度的十分之一，請依裝置輸出內容解讀。
batterystats --charged：查看自相關充電統計週期開始以來的記錄；這不是剛好涵蓋最近 60 分鐘的獨立報告，也不等同於精確的硬體功率測量。
dumpsys deviceidle：確認閒置狀態和相關白名單；無法直接從單一輸出結果計算省電量。
dumpsys connectivity：協助確認 VPN 與底層網路狀態；不同版本提供的資訊有所差異，報告中也可能包含網路識別資訊。

USB 連線時可能同時充電，影響耗電對照。效能記錄和掉電測試可以分開進行，不要把插著傳輸線時的電量變化當成螢幕關閉時的耗電結果。分享這些檔案前，也要檢查其中是否包含網路名稱、位址和應用程式使用資訊。

依症狀縮小排查範圍，再確認日常使用正常

現象	優先檢查	驗證方式
螢幕關閉後週期性發熱	健康檢查、同步工作、失敗重試	調整為 900 秒後，再重複進行 60 分鐘測試
螢幕關閉後斷網，亮起螢幕後恢復	電池限制、背景服務遭到停止	只授予用戶端必要的背景權限
只有行動網路下耗電明顯	訊號、頻繁切換網路、節點重連	在穩定的 Wi-Fi 下建立對照組
開啟面板後才明顯發熱	即時更新、連線清單、詳細記錄	關閉面板，並恢復日常記錄層級
調整依應用程式代理後，部分應用程式無法連網	名單設定方向、「一律使用 VPN」的封鎖選項	逐一驗證直連和代理應用程式

最後保留一份穩定設定：健康檢查先從 900 秒開始測試，依實際需求設定訂閱更新，只有重現問題時才啟用詳細記錄，並只為確實需要持續執行的用戶端授予背景權限。若節點失效後不易及時發現，再逐步縮短檢查週期，不必直接改回每隔幾十秒就測試全部節點。

完成調整後，請依序確認螢幕關閉時能否收到通知、Wi-Fi 與行動網路切換是否正常、語音通話是否順暢，以及重新開機後的連線狀態。省電和穩定性都需要一併驗收。若仍持續發熱或 CPU 使用率偏高，請提供用戶端與核心版本、系統版本、最小重現設定和短時間記錄；欄位說明可參考設定參考，基本連線問題則可繼續查看疑難排解。