Android 代理 App 耗電排查：電池最佳化、背景執行與 TUN 模式

先釐清：耗電增加、用電歸因與背景斷線

Android 代理 App 耗電太快，不能只看電池用量排名判斷。用戶端透過 Android 的 VpnService 接管連線後，系統可能會將部分網路活動及相關耗電記在 VPN App 名下；不同 Android 版本與手機品牌的歸因方式也不盡相同。用戶端排名靠前，不代表它單獨耗用了整部手機相同比例的電量。

先在相同條件下比較整部手機的電量變化，再確認連線是否穩定，最後才調整背景權限與設定。 如果只有螢幕熄滅後斷網，應優先檢查背景限制；若待機耗電明顯增加，則要檢查健康檢查、重新連線、實際背景流量與行動網路訊號。兩種問題可能同時發生，但處理方式不同。

建立可比較的待機紀錄

每輪至少 60 分鐘，每次只改一個變因

選擇相同地點、相同網路及相近電量，例如每次都從約 80% 開始。暫停系統更新、相片備份與大型檔案下載，關閉用戶端的即時連線面板，並讓螢幕保持熄滅。第一輪停止代理服務，第二輪啟用同一份訂閱，第三輪只調整一項可疑設定。每輪至少觀察 60 分鐘；低負載情境可延長至 2～3 小時。

• 記錄整機變化：開始與結束時的電量、測試時間、螢幕使用時間，以及是否正在充電。
• 記錄網路環境：Wi-Fi 或行動數據、訊號是否明顯波動，以及是否在兩種網路間切換。
• 記錄用戶端狀態：產品名稱與版本、核心版本、設定檔名稱，以及是否啟用應用程式分流。
• 記錄執行中的工作：是否播放音訊、接收訊息、備份相片或開啟個人熱點。

例如，一輪測試 2 小時，電量從 80% 降至 76%；另一輪從 80% 降至 73%，平均每小時分別下降 2 個和 3.5 個百分點。這只是示範計算方式，並非產品實測結果，也不是合格標準。電量百分比會有取整誤差，單次相差 1 個百分點不足以判斷；應重複測試，並排除溫度、訊號與背景工作差異。

電池最佳化例外：按穩定性需求調整

Android 的 Doze、應用程式待機限制，以及手機品牌的背景管理，都可能影響背景網路連線與工作執行。將用戶端設為「不受限制」，可減少部分省電政策的干預，但無法修復節點逾時、DNS 循環或錯誤規則，也不能保證程序永遠不會被終止。只有遇到螢幕熄滅後斷線、服務反覆消失等情況，才需要優先檢查背景權限。

依 Android 版本尋找 App 電池設定

1. 長按用戶端圖示，開啟「應用程式資訊」，先查看「電池」或「應用程式電池用量」。
2. 以部分 Android 13 原生介面為例，設定路徑為「設定」→「應用程式」→「查看所有應用程式」→用戶端→「應用程式電池用量」，可選擇「不受限制」。其他版本可能會顯示為「允許背景使用」，實際選項請以裝置為準。
3. 部分 HyperOS 裝置可依序前往「設定」→「應用程式設定」→「應用程式管理」→用戶端→「省電策略」，尋找「無限制」選項。若目前版本沒有這條路徑，可在設定中搜尋「省電策略」。
4. Samsung 裝置可前往「設定」→「電池」→「背景使用限制」，檢查用戶端是否列在休眠或深度休眠清單中；不同 One UI 版本的上層選單可能有所不同。
5. 每次只調整一項，螢幕熄滅後測試 30～60 分鐘，再確認通知列中的服務、網路連線與記錄檔是否持續正常。

「允許自動啟動」、「鎖定最近使用的工作」與「電池最佳化例外」分屬不同控制層。鎖定最近使用的工作通常只會降低 App 被一鍵清除的機率，並非 Android 對背景常駐的保證。若需要重新開機後自動連線，再一併檢查用戶端的開機啟動設定及系統自動啟動權限；若不需要自動連線，就不必為了待機測試而開啟。

若加入例外後整機耗電反而增加，請回頭檢查連線與記錄檔：原本受限制的高頻工作可能開始持續執行。例外設定只會讓工作有機會執行，不會提升工作本身的效率。

VPN 常駐與 TUN：先確認實際流量接管方式

Android 上常見的 Clash 系列用戶端通常會透過 VpnService 建立虛擬網路介面，再由核心或搭配的轉送元件處理連線。桌面版教學提到的「關閉 TUN，只開系統代理」，不能直接套用到手機：Android 的 Wi-Fi 代理是依網路設定的連線入口，並非所有 App 都會遵循，也不是通用的全裝置系統代理。

用戶端介面中的「TUN」、「VPN 模式」、「網路堆疊」可能指不同層級的實作。有些產品沒有可單獨關閉的 TUN 開關；關閉 VPN 服務就代表不再接管流量。網路堆疊選項也取決於用戶端與核心版本，不能把換用某種堆疊視為通用省電方法。

依使用需求選擇流量接管範圍

• 只需要少數 App 使用代理：若用戶端支援「僅允許所選 App」，可只加入確實需要的 App。請先看清楚介面上的模式說明，確認勾選代表「經由 VPN」還是「略過 VPN」。
• 需要依規則分流：保留規則模式，並確認中國大陸服務或區域網路目的地符合預期的直連規則。流量被接管後才命中 DIRECT，不代表完全沒有經過 VPN 處理路徑。
• 需要持續連線：可評估啟用系統的「一律開啟 VPN」。部分原生系統的設定路徑為「設定」→「網路和網際網路」→「VPN」→點選對應連線的設定按鈕。
• 需要防止流量繞過：再考慮啟用「封鎖未使用 VPN 的連線」。這是連線策略，不是省電選項；與 App 略過 VPN、區域網路存取等設定搭配前，務必實際測試。

訂閱、健康檢查與重新連線：找出週期性喚醒

用戶端保持閒置，不代表設定中沒有定時工作。訂閱自動更新、代理提供者的健康檢查、url-test 策略群組測試，以及正在使用的 App 本身的心跳連線，都可能產生背景請求。多種機制可能重複測試相同節點；排查時要同時檢查用戶端設定與實際生效的設定。

先檢查以下四項

1. 健康檢查間隔：在 mihomo 設定中，代理群組及代理提供者健康檢查的 interval 通常以秒為單位。30 秒代表每小時有 120 次排程檢查，300 秒則為 12 次；實際請求數還取決於節點數量、延遲檢查與實作方式，不能直接換算成耗電比例。
2. 延遲檢查：若支援，可評估使用 lazy: true，減少未使用群組或提供者不必要的檢查。欄位必須放在正確的設定層級；用戶端覆寫也可能改變最終結果。
3. 訂閱更新：日常使用通常不需要每分鐘更新訂閱。依服務提供者的更新頻率，選擇每隔數小時更新或手動更新，避免反覆下載、解析並重新載入設定。
4. 失敗重試：若記錄檔持續出現逾時，先選擇一個連線穩定的節點，再觀察是否仍不斷重新連線。延長測速間隔無法解決目前使用的節點持續失效。

不要為了減少探測而一次刪除所有自動策略。先將過短的測試間隔調整為例如 300 秒，觀察節點切換體驗與待機數據；這只是排查起點，並非適用於所有訂閱的建議值。訂閱管理器可能在更新時覆蓋修改，建議優先使用用戶端支援的持久覆寫方式，並在更新後確認生效設定。

DNS、記錄檔與背景工作：找出持續活動來源

DNS 錯誤要修復連線流程，不能只靠切換模式

如果記錄檔反覆出現解析逾時，先檢查 DNS 上游是否可連線、代理伺服器的網域名稱能否解析，以及 DNS 連線是否又依賴尚未建立的代理。mihomo 的 proxy-server-nameserver 可用於解析代理節點網域名稱，但設定仍須符合既有的 DNS 路由設計，不能只複製一個欄位就認定問題已解決。

Fake-IP 會以虛擬位址維持網域名稱與連線之間的對應，並非耗電異常的充分原因。只有特定 App 確實發生相容性問題時，才有理由調整相關過濾或解析策略。Android 的「私人 DNS」也可能使 App 使用的解析路徑與用戶端設定不同；變更前先記下原本設定，避免同時調整兩層 DNS，最後無法判斷原因。

縮短診斷記錄時間，確認實際流量來源

• 正常使用時保留用戶端的預設記錄等級。暫時啟用 debug 時，擷取足以涵蓋故障的 5～10 分鐘記錄，之後恢復原設定。
• 不要讓連線清單或即時速度面板持續更新、亮屏執行，然後把這段耗電當成螢幕熄滅後的待機結果。
• 檢查是否有相簿上傳、雲端硬碟同步、影片預載等長時間連線；代理用戶端可能只是在轉送這些 App 的實際流量。
• 比較 Wi-Fi 與行動數據的結果。訊號較弱或頻繁重新連線時，無線通訊本身就可能增加耗電，即使代理設定完全沒變。

進階紀錄：透過 ADB 補充電池與閒置狀態資料

具備除錯經驗的使用者可透過電腦上的 ADB 讀取系統記錄。以下命令不需要 root，但須先啟用 USB 偵錯並授權電腦。輸出欄位及可查看的資訊會因 Android 版本而異，不能把單一計數直接換算成用戶端耗電量。

adb shell dumpsys battery
adb shell dumpsys batterystats --charged
adb shell dumpsys deviceidle

dumpsys battery 可協助確認電量、充電狀態與溫度；batterystats 可查看系統累計的電池活動；deviceidle 可檢視裝置閒置機制的狀態。不要為了測試，在主要使用的手機上隨意強制進入閒置狀態，這會改變正常使用條件。

連接 USB 可能同時為手機充電，因此這些命令較適合在測試前後擷取資料。若要進行穩定的長時間比較，請先中斷電源再開始紀錄；無線偵錯也會產生網路活動，不應預設為零額外耗電。分享記錄檔前，請刪除不想公開的訂閱網址、節點憑證、存取網域與 App 套件名稱等資訊。

最後檢查清單：分開驗證連線穩定性與耗電

1. 確認基準：使用相同網路與地點，至少完成服務啟用與停止兩輪對照；不要用電池用量排名取代整機掉電數據。
2. 確認背景設定：只有發生螢幕熄滅後斷線時，才逐項放寬電池限制、自動啟動等權限，並記錄每次變更。
3. 確認流量：按需求使用 App 分流，避免不必要的背景工作；並確認訊息、區域網路與必要 App 仍可正常使用。
4. 確認設定：檢查健康檢查間隔、訂閱更新、節點失敗重試，以及設定更新後覆寫是否仍然生效。
5. 確認診斷已結束：恢復一般記錄等級，關閉即時面板，再進行一輪螢幕熄滅後的測試。
6. 仍有異常再回報：提供手機型號、Android 版本、用戶端與核心版本、問題重現時間、網路類型及已去識別化的記錄檔。

如果只有在某次升級後，才出現相同條件下可重現的待機差異，請在回報中註明版本變更，不要直接歸因於所有 TUN 或所有 Clash 系列用戶端。選擇用戶端時，可前往下載頁確認平台支援與維護狀態；設定概念可參考使用手冊。最終目標是在保留必要連線穩定性的同時，減少有證據可追查的額外活動。