判斷 Shadowrocket 是否增加耗電，應一併查看裝置總耗電量、系統電池用量歸因，以及連線是否反覆重建。本文適合已擁有自己的連線服務與訂閱、需要在持續連線和 On Demand 之間做選擇的使用者：先建立可比較的紀錄，再調整觸發條件，最後確認網路切換與鎖定螢幕後的狀況；不要只憑 VPN 圖示或單次用量占比下結論。
先分清背景執行、VPN 通道與實際流量
Shadowrocket（小火箭）是透過 App Store 發行的 Apple 平台付費用戶端，採一次性買斷。確認正版時，請核對官方圖示、開發者 Shadow Launch Technology Limited 與 App ID 932747118；系統需求與相容範圍以 App Store 頁面標示為準。購買用戶端與使用者已有的連線服務是兩回事，購買不包含線路方案。
返回主畫面後，App 介面雖不在前景，不代表系統 VPN 通道已停止。連線期間，相關網路延伸功能仍須處理經由通道傳輸的流量。反之，狀態列顯示 VPN 標誌，也不代表裝置正持續高速傳輸。閒置連線、播放影片，以及訊號微弱時反覆重新連線，耗電情況都不相同。
耗電可能來自加密處理、資料收發、維持連線、DNS 查詢，以及失敗後重試。螢幕亮度、背景同步與行動網路訊號也會影響裝置總耗電量。因此，「背景執行了多久」只能說明活動持續時間，無法直接換算成額外耗電量。
持續連線與 On Demand：差別在連線時機
持續連線適合需要較穩定網路路徑的使用情境。連線已建立時，後續請求通常不必重新等待通道啟動，但閒置期間仍可能需要維持連線，也可能有系統網路活動。On Demand 則由系統依照設定條件決定連線行為；它不是「螢幕熄滅就中斷」，也不只會辨識目前正在使用的 App。
| 設定方式 | 連線行為 | 需留意的代價 |
|---|---|---|
| 持續連線 | 維持通道，實際傳輸量取決於 App 活動。 | 閒置時維持連線、訊號微弱時重試，以及持續的背景傳輸。 |
| On Demand | 依網路或網域等已設定條件觸發系統連線行為。 | 首次連線需等待、條件反覆變動，以及觸發範圍過廣。 |
| 手動連線 | 由使用者在 Home 手動連線與中斷。 | 容易忘記開啟或關閉，需要養成明確的操作習慣。 |
如果通知、同步或其他背景請求經常符合觸發條件，On Demand 仍可能讓連線維持很長時間。若 Wi-Fi 與 Cellular 頻繁切換，或已設定的 SSID 條件互相衝突，反覆啟動通道也會增加連線開銷。不能只因為開啟按需連線，就認定電池續航一定會改善。
結論：先減少無效的重新連線
在網路穩定且設定相同的前提下比較兩種方式；若記錄顯示連線不斷中斷又重連，應先修正觸發條件或網路問題，再評估 On Demand 是否能省電。
利用系統 Battery 頁面建立可比較的紀錄
在 iPhone 或 iPad 的系統 Settings → Battery 查看電池用量；繁體中文系統對應「設定 → 電池」。不同系統版本的時間範圍與圖表入口可能不同，請選擇涵蓋本次測試的時段，並記錄螢幕活動和背景活動。系統顯示的 App 占比，是該統計範圍內的用電歸因比例，不代表電池容量下降了相同百分比。
-
固定測試環境
使用同一台裝置、同一個 Wi-Fi、相同的連線設定與相近的螢幕亮度。測試期間不要充電，並避開系統更新、照片大量同步和大型檔案傳輸。
-
記錄起始狀態
開啟系統 Settings → Battery，記下起始時間、電量與網路類型。另記錄 Shadowrocket 是否已連線，以及 Settings → On Demand 是否已啟用。
-
保持連線
先觀察持續連線 30 分鐘：依預先設定的使用方式操作，或鎖定螢幕靜置。結束後記錄電量與異常重連情況；不要把螢幕亮著使用和鎖定螢幕靜置混在同一組。
-
測試按需連線
改用已確認的 On Demand 條件，再觀察相同的 30 分鐘。盡量維持相同的 App 活動，並記錄實際是否觸發連線，不要只記錄開關狀態。
-
重複確認
在相近時段再測一次，並交替測試順序。綜合系統電池圖表與每次的總耗電量判斷；短時間內電量沒有變化，不代表完全沒有耗電。
這裡的 30 分鐘只是方便執行的觀察時段，不是續航測試結果。電量百分比會經過四捨五入，背景工作也會波動；若兩次差異很小，應延長紀錄並重複觀察，而不是宣稱固定的「省電百分比」。裝置發熱時，也應一併檢查訊號、螢幕與其他 App 活動。
Settings → On Demand 設定檢查步驟
在 Shadowrocket 的 Settings → On Demand 檢查目前的按需設定。先記下原有條件，再一次只修改一項。條件名稱與可選動作以目前介面為準；SSID 應填入裝置實際連線的 Wi-Fi 名稱，網域條件也不能當成通用網址篩選器。
- 先查看預設行為：確認未符合指定條件時會如何處理，避免只設定例外，卻忽略其他網路的連線行為。
- 接著查看 Wi-Fi：核對 SSID 的拼字、空格與大小寫。若家中不同頻段使用不同名稱，應分別測試，不要只看路由器裝置名稱。
- 再單獨查看 Cellular：離開 Wi-Fi 後，觀察是否依預期連線。訊號不佳造成的逾時，無法靠增加觸發條件解決。
- 最後查看網域：若設有網域觸發條件，應實際存取目標並確認連線行為。快取與既有連線會影響觀察結果，只開啟頁面一次不足以證明規則始終有效。
- 測試鎖定螢幕：分別檢查鎖定螢幕後、解鎖後及切換網路後的狀態，並記錄是否反覆重建連線。
例如，若希望在家中 Wi-Fi 不保持連線、使用 Cellular 時則連線，應先確認家庭網路確實符合日常使用需求，再設定對應條件。接著檢查「家庭 Wi-Fi、關閉 Wi-Fi、重新加入家庭 Wi-Fi」三種情境。切換時短暫等待可能是因為正在建立連線；若持續轉圈，應進一步排查連線問題，不能一概視為按需連線的正常情況。
Global Routing 與協定設定無法取代耗電診斷
On Demand 決定何時觸發連線，Global Routing 則決定連線後如何路由，兩者屬於不同層面。Home → Global Routing 下的 Proxy、Direct、Config、Scene 不應被視為四種省電模式。尤其是 Direct，不能簡單等同於系統 VPN 通道已關閉。
| 模式 | 檢查重點 |
|---|---|
Proxy | 主要以代理方式處理流量，檢查實際傳輸量與連線品質。 |
Direct | 主要直接連線至目標，不代表網路延伸功能一定停止運作。 |
Config | 依目前設定的規則分流，檢查符合的規則與最終策略。 |
Scene | 確認目前的情境設定及其實際採用的路由行為。 |
使用 Config 時，DOMAIN-SUFFIX、GEOIP、IP-CIDR 與 FINAL 等規則會決定請求的去向，不是電量控制指令。若某個 App 反覆請求失敗，應先確認它符合哪條規則、最後採用什麼策略，再判斷是否需要調整；不要為了減少背景活動就直接改成全部 Direct。
Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuard 的連線維持方式與傳輸特性各不相同，但不能脫離裝置、訊號與伺服器參數，做出通用的省電排名。應先確保使用者現有服務所要求的協定與參數正確，再一次比較一個變數；任意修改連接埠、傳輸方式或保活參數，可能讓穩定連線變成不斷重試。
- 比較路由模式時，維持 On Demand 條件不變。
- 比較協定時，確認伺服器確實支援對應設定，不要只修改用戶端名稱。
- 診斷完成後，關閉臨時啟用的詳細除錯紀錄，避免長期保留不必要的診斷活動。
發生逾時與重連時，先排除連線故障
電量增加且同時反覆連線失敗時，應對照連線錯誤與系統 Battery 顯示的時段。以下是連線記錄中可能出現的錯誤原文片段；完整格式會依協定與記錄來源而異。這些訊息指出可能的網路故障方向，無法直接證明耗電來自哪個元件。
錯誤：i/o timeout
原因：讀寫操作未能在指定時間內完成，可能與目前網路無法連線、訊號不穩或遠端沒有回應有關。
處理方式：保留原有設定，分別透過穩定的 Wi-Fi 與 Cellular 測試相同連線，確認是否只有某種網路會失敗；不要讓無效連線持續重試。
錯誤：connection refused
原因：連線目標主動拒絕請求，常見原因是連接埠不正確，或對應服務並未監聽。
處理方式：核對使用者現有服務的位址、連接埠與協定；必要時向自己的服務供應商確認狀態，修正後再恢復按需觸發。
若錯誤是在更新訂閱後開始，先確認目前選取的連線項目是否改變，以及原本的位址與協定參數是否仍適用。不要一再重新整理訂閱來處理所有逾時；更新訂閱只能取得設定內容，無法修復訊號不佳或遠端服務故障。傳送診斷截圖與記錄前，請遮蔽訂閱連結、驗證資訊及其他敏感內容。
結論：依使用需求維持連線
需要持續存取時，應優先確認連線穩定；若網路界線明確且閒置時間較長，再測試 On Demand。只有總耗電量、實際連線狀態與使用活動相互吻合時，才將某種設定保留為日常方案。