適合遇到待機掉電、機身發熱、背景頻繁斷線或 v2rayNG 耗電比例異常的使用者。排查順序是先建立相同條件的基準，再修正系統背景策略，接著縮小代理流量範圍，最後檢查 DNS、節點重連與 Mux；完成後即可判斷耗電來自正常 VPN 轉送、網路重試，還是代理範圍過大。
先確認是代理耗電，還是電量統計偏差
Android 電池頁面顯示的百分比，是某個統計週期內的耗電占比，不代表應用程式單獨消耗了同等比例的整機電量。裝置只掉電 4%，其中 v2rayNG 占 25%，換算後的估計貢獻約為 1 個百分點；若裝置一晚掉電 18%，且 v2rayNG 持續使用行動網路，才需要進一步定位。
測試前固定螢幕亮度、網路類型、使用中的節點與應用程式集合。不要直接比較一次 Wi-Fi 待機和一次行動網路影片播放。建議從電量約 80% 開始，分別記錄 30 分鐘亮屏與 6 小時熄屏資料。測試期間關閉系統更新、照片同步及大型檔案下載，避免其他背景工作影響結果。
v2rayNG 會使用系統 VPN 介面接收流量，再交由 Xray 核心處理 DNS、路由及輸出連線。只要代理開啟，系統可能會將其他應用程式產生的網路活動歸到 VPN 應用程式名稱下，因此電池頁面中的 v2rayNG 占比會包含部分轉送成本。真正值得關注的是持續喚醒、重複撥號、大量 DNS 查詢及不必要的全量代理。
| 測試項目 | 記錄方式 | 需要留意的現象 |
|---|---|---|
| 6 小時熄屏 | 記錄開始與結束電量、網路類型 | 沒有主動工作時掉電超過 8%，裝置持續溫熱 |
| 30 分鐘網頁瀏覽 | 固定亮度並瀏覽相同頁面 | 開啟代理後的額外掉電量超過關閉時的兩倍 |
| 背景活動 | 查看系統電池詳細資料中的前景與背景時長 | 熄屏期間的背景活動接近整個測試時段 |
| 連線記錄 | 觀察相同錯誤是否持續重複 | 每隔數秒出現一次逾時、解析或重連記錄 |
修正系統省電策略與背景保活
省電策略不是越寬鬆就越省電。若系統頻繁終止 VPN 服務，v2rayNG 便會重新建立 VPN 介面、解析節點位址並建立連線，反而形成「終止—重新啟動—重連」循環。穩定保活通常比每隔幾分鐘冷啟動一次更省電，也能減少鎖定螢幕後的訊息延遲。
不同 Android 廠商的選單文字略有差異，核心目標相同：允許 v2rayNG 在背景執行，關閉針對該應用程式的自動凍結，同時保留系統 VPN 的常駐通知。以下路徑參考常見的 Android 14、Android 15 設定結構及 v2rayNG 1.10.x 介面。
取消電池限制
開啟系統「設定」→「應用程式」→「v2rayNG」→「應用程式電池用量」，選擇「不受限制」或同等選項。不要同時將應用程式加入廠商提供的睡眠凍結清單。
允許背景網路
前往「設定」→「應用程式」→「v2rayNG」→「行動數據與 WLAN」，開啟背景數據；需要在數據節省模式下執行時，再開啟「不受數據用量限制」。
加入背景白名單
在裝置的「電池」→「背景使用限制」或「應用程式啟動管理」中，允許自動啟動、關聯啟動與背景執行。若廠商系統只提供一個總開關，請關閉對 v2rayNG 的自動管理。
保留常駐通知
前往「設定」→「通知」→「v2rayNG」，保留 VPN 服務通知。通知用於顯示前景服務狀態，不應透過強制停止應用程式來隱藏通知。
重新建立一次連線
返回 v2rayNG 主介面，停止目前連線，等待 5 秒後重新啟動。鎖定螢幕 10 分鐘，再確認狀態列的 VPN 標記及網路存取均正常。
部分系統還有「鎖定最近使用的工作」選項。它主要防止一鍵清理時結束程序，不能取代電池白名單。完成上述設定後，不要再疊加多個所謂的背景增強工具；多個管理器同時調整程序優先順序，往往會造成重複喚醒。
結論：保活目標是穩定，不是持續高頻活動
正確狀態是 VPN 服務長時間存在，但熄屏時連線及 DNS 請求明顯減少。若背景時長很長卻沒有持續網路活動，通常屬於正常的前景服務；若記錄每隔幾秒出現一次重連，才需要處理節點、DNS 或網路切換。
用分應用程式代理與路由規則縮小處理範圍
全量 VPN 會接收裝置上所有應用程式的流量，包括系統同步、區域網路裝置探索、軟體更新及媒體備份。即使最終規則判定為直連，這些連線仍可能經過 VPN 介面及路由判斷。只代理確實需要的應用程式，可以直接減少連線數量、DNS 查詢及核心處理時間。
v2rayNG 的分應用程式代理適合應用程式集合相對固定的裝置。前往「設定」→「分應用程式代理」，啟用功能後選擇需要經過代理的應用程式，並確認目前模式是「僅代理已選應用程式」，不要將選擇邏輯弄反。不同介面版本可能會以「繞過已選應用程式」和「代理已選應用程式」兩個選項呈現，儲存前應核對說明文字。
記錄原始設定
修改前擷取目前的分應用程式代理與路由設定，並記錄正在使用的伺服器。出現存取差異時，可以逐項還原，不必重新匯入整份訂閱。
縮小應用程式集合
前往「設定」→「分應用程式代理」，先只選擇 2 至 5 個確實需要代理的應用程式。保留瀏覽器作為測試入口，方便驗證代理出口是否生效。
設定區域網路直連
前往「設定」→「路由設定」，確認私有位址區段走直連。常見範圍包括
10.0.0.0/8、172.16.0.0/12和192.168.0.0/16。減少重複規則
刪除作用相同且順序衝突的自訂規則。路由從上到下比對時，應將明確的攔截與直連條件放在通用代理規則之前。
重新測試半小時
維持相同節點與網路，完成 30 分鐘的日常操作。比較連線數、機身溫度及每小時掉電量，再決定是否繼續擴大應用程式集合。
| 流量類型 | 建議輸出 | 省電原因 |
|---|---|---|
| 家用路由器與區域網路裝置 | 直連 | 避免本地請求繞到遠端節點後因失敗而重試 |
| 不需要代理的系統更新 | 直連或不納入分應用程式代理 | 減少大流量經過 VPN 介面 |
| 需要固定代理出口的應用程式 | 代理 | 保留必要功能，避免接管整部裝置 |
| 廣告與已知追蹤網域 | 依規則阻擋 | 減少無效連線，但規則不宜無限堆疊 |
檢查 DNS 逾時、網路切換與重複重連
高耗電往往不是加密運算本身造成，而是失敗連線不斷重試。行動訊號較弱、節點網域解析失敗、IPv6 路徑無法連通，或 Wi-Fi 與行動網路頻繁切換時，核心會反覆執行 DNS 查詢及 TCP 撥號。記錄中同類錯誤密集出現，比單次錯誤更具診斷價值。
在 v2rayNG 主介面開啟記錄，先停止無關應用程式的網路活動，再觀察 2 至 3 分鐘。偶發的 context canceled 常見於主動切換節點或停止服務；若每隔幾秒重複出現逾時，則應檢查節點可達性、DNS 設定及目前網路，而不是單純放寬背景權限。
錯誤：dial tcp: i/o timeout
原因與解法：目標位址未能在限定時間內完成連線，常見原因是節點無法連線、訊號微弱或連接埠受限。先在相同網路下測試另一個可用節點，再切換 Wi-Fi 與行動網路進行對照，避免用戶端持續重撥失效位址。
錯誤：failed to find an available destination
原因與解法：網域解析、路由目標或輸出鏈路無法取得可用位址。檢查伺服器位址拼寫與 DNS 設定，更新訂閱後重新啟動核心，並確認沒有將節點網域錯誤地送回同一個代理輸出。
錯誤：context canceled
原因與解法：連線上下文已停止，手動中斷時屬於正常記錄；若熄屏後持續出現，請檢查系統是否反覆終止 VPN 服務，並重新設定電池白名單與背景執行權限。
錯誤：network is unreachable
原因與解法：目前網路沒有對應位址族可用的路由。切換網路進行對照，檢查節點位址是否只回傳無法連線的 IPv6 記錄，並避免在網路尚未恢復時連續點選重連。
DNS 設定應保持單一且容易理解。不要同時疊加多個遠端 DNS、FakeDNS 及複雜的回退條件後再判斷耗電。先使用一個穩定的本機或遠端解析方案，確認節點網域能夠解析；之後再依分流需求增加規則。DNS 連接埠通常是 53，加密 DNS 則由對應協議及端點決定，不能只將連接埠改成 853 就完成設定。
建議記錄項目
測試網路：Wi-Fi / 行動網路
測試時間：30 分鐘亮屏，6 小時熄屏
使用中的節點：固定同一部伺服器
逾時次數：記錄中 i/o timeout 的出現次數
重連間隔：連續錯誤之間的秒數
每小時掉電量：測試電量差 ÷ 測試時數結論：先消除連續失敗，再討論參數微調
節點每 5 至 10 秒重試一次時，調整 Mux 或分應用程式代理只能掩蓋部分現象。先讓記錄恢復到沒有連續逾時，再以相同測試條件比較省電設定，結果才有意義。
Mux 不是固定的省電開關
Mux 會讓多個邏輯連線共用底層連線，理論上可以減少頻繁交握，但不保證在所有網路及伺服器設定下都更省電。長連線較多、網路穩定且伺服器正確支援時，複用可能降低建立連線的次數；網路不穩、頻繁切換基地台或伺服器處理不佳時，一個複用連線失效會連帶觸發多路請求重建。
不要只根據「連線數較少」判斷耗電。還需要同時觀察首個封包延遲、失敗重試及熄屏後的連線維持情況。網頁短連線較多時可以測試開啟；即時通訊、持續下載或節點已使用自身流複用機制時，開啟後的收益可能很小。
| 情境 | Mux 測試方向 | 觀察指標 |
|---|---|---|
| 穩定 Wi-Fi、短連線較多 | 分別測試關閉與開啟 | 30 分鐘內的連線建立次數、首個封包延遲 |
| 行動網路頻繁切換 | 優先關閉後建立基準 | 切換後恢復時間、逾時與重連次數 |
| 持續下載或影片串流 | 通常不依賴 Mux 省電 | 傳輸量穩定性、裝置溫度、每小時掉電量 |
| 伺服器未正確支援 | 保持關閉 | 協議錯誤、連線中斷及頁面載入失敗 |
操作時開啟目前伺服器的編輯頁面，檢查傳輸或進階參數中的 Mux 設定。透過訂閱匯入的節點可能在更新後覆蓋手動修改，因此每輪測試前都要確認實際生效的值。使用自訂完整設定時，應檢查輸出物件中的複用設定，而不是只看主介面的顯示名稱。
結論：用兩輪對照決定 Mux
固定節點與網路，各測試 30 分鐘並記錄逾時次數及掉電量。差異小於 2 個百分點且連線穩定性相近時，維持預設值即可；若開啟後重連明顯增加，應將其關閉，並優先檢查伺服器支援情況。
依固定順序完成最終複測
排查結束後，需要恢復一套可重現的日常設定。有效設定應同時符合三個條件：鎖定螢幕後不斷線、記錄沒有連續錯誤、單位時間掉電量回到穩定範圍。只看其中一項容易誤判，例如強制終止背景服務雖然暫時降低耗電，卻會直接破壞通知與背景連線。
- 更新訂閱並選擇一個已確認可用的節點，不要在測試途中自動切換伺服器。
- 重新啟動 v2rayNG，保持螢幕關閉 10 分鐘，確認 VPN 狀態仍然存在。
- 執行 30 分鐘的固定應用程式測試，記錄開始電量、結束電量、網路類型及機身溫度變化。
- 執行 6 小時熄屏測試，關閉主動下載及大規模同步，但保留正常訊息接收。
- 檢查記錄中的逾時、解析失敗及重連次數，並與修改前的記錄比較。
- 連續兩輪結果接近後，再逐步加入其他需要代理的應用程式。
| 複測結果 | 判斷 | 下一步 |
|---|---|---|
| 熄屏穩定、記錄安靜、掉電下降 | 背景與路由調整有效 | 保留設定，逐步恢復必要應用程式 |
| 熄屏斷線，重新亮屏後才恢復 | 系統仍在限制背景服務 | 重新檢查電池白名單、背景數據及啟動管理 |
| 持續發熱並出現密集逾時 | 節點或網路路徑異常 | 更換已驗證的節點，並與另一個網路進行對照 |
| 連線穩定但全量代理耗電高 | 處理範圍過大 | 啟用分應用程式代理並補充直連規則 |
常見問題
為什麼開啟 v2rayNG 後，電池頁面中的占比很高？
系統可能會將經由 VPN 介面轉送的部分網路活動計入 v2rayNG。先查看整部裝置的實際掉電量、背景活動時長及記錄中的重試頻率，不要只根據應用程式占比判斷。
設定「不受限制」會不會一定更耗電？
不會直接等同於持續執行運算工作。它主要是避免系統反覆終止 VPN 服務。穩定待機通常比頻繁終止、重新解析及重連更容易控制，但仍需搭配分應用程式代理及正確路由。
開啟分應用程式代理後，部分應用程式無法連線怎麼辦？
先確認目前是「代理已選應用程式」還是「繞過已選應用程式」模式，再檢查目標應用程式是否依賴其他系統元件連線。暫時加入相關元件進行對照，不要直接切回全量代理來掩蓋問題。
v2rayNG 與 v2flyNG 的排查方法相同嗎？
系統背景權限、分應用程式代理及網路基準的思路相同，但兩者使用的核心及部分選單不同。v2rayNG 使用 Xray 核心，v2flyNG 使用 v2fly 核心，記錄欄位及具體參數應以各自介面為準。
更換協議能直接解決耗電問題嗎？
協議只是影響因素之一。節點丟包、DNS 逾時、網路切換及全量代理通常更值得優先檢查。只有在相同節點條件下完成對照測試，才能判斷 VMess、VLESS 或其他已設定協議是否造成實際差異。