討論Android VPN 推薦時，不能只看節點數量或連線按鈕是否好用。Android 系統允許裝置製造商深度調整省電與背景管理，同一款用戶端在不同裝置上可能呈現完全不同的保活結果；另一方面，分應用程式代理雖然方便，卻也可能因包含規則、排除規則與 DNS 路徑沒有對齊，讓部分要求繞過預期路線。真正值得選擇的方案，應同時通過背景存活、網路切換、路由涵蓋與洩漏檢查。
本文所稱的「實測」，不以單次測速得到的峰值作為結論，而是按照可重複的操作檢查連線狀態。重點不是某個瞬間有多快，而是鎖定螢幕後是否仍能維持通道、從無線網路切換到行動網路後能否恢復、納入代理的應用程式是否確實透過目標出口存取，以及 DNS、IPv6 等要求是否走上錯誤路徑。
Android 裝置選擇標準：先看系統整合，再看線路
Android 代理用戶端通常透過系統的 VPNService 介面接管網路流量。狀態列出現鑰匙圖示，代表系統已允許用戶端建立虛擬網路介面，但後續如何路由 IPv4、IPv6 與 DNS，仍由用戶端設定與訂閱規則決定。因此，評估 Android 用戶端時，介面簡潔只是基本條件，更重要的是能否清楚顯示目前設定、使用中的協定、分流模式、連線記錄與失敗原因。
- ✅ 能明確選擇全域、規則分流或直連模式，並說明目前模式的實際作用。
- ✅ 能查看訂閱更新時間、節點名稱與協定類型，匯入失敗時提供容易理解的錯誤訊息。
- ✅ 支援依應用程式納入或排除代理，修改後會提示重新連線以套用規則。
- ✅ 能處理網路切換，並在通道中斷後自動嘗試恢復，而不是長時間停留在失效狀態。
- ✅ 提供連線記錄與 DNS 設定入口，方便判斷問題發生在解析、握手還是路由階段。
- ❌ 只顯示模糊的「成功」提示，卻無法確認協定、出口與分流結果。
線路類型也要結合使用情境判斷。直連線路由裝置直接存取遠端入口，路徑簡單，但跨境鏈路容易受到本地電信業者路由與尖峰壅塞影響。中轉線路先連線至境內或鄰近入口，再由中轉網路送往出口，通常更容易控制跨境區段的路徑。IEPL 專線則著重穩定的跨境傳輸路徑，與一般公網直連並不是同一類網路架構。這些線路都不能單獨取代用戶端保活：線路穩定但應用程式遭系統終止，連線仍會中斷。
背景保活：省電策略為何會造成斷線
Android 的背景限制不只一種。系統可能限制背景活動，裝置製造商的電量管理還可能凍結程序、延遲網路存取或阻止應用程式自行恢復。代理用戶端即使執行前景服務，也可能在長時間鎖定螢幕、記憶體不足或開啟省電模式後失去運作條件。常駐通知可以降低遭回收的機率，但不是跨裝置通用的保活保證。
排查時不要一開始就頻繁更換節點。先確認用戶端程序是否仍在執行、系統鑰匙圖示是否消失，再檢查出口位址是否回到本地網路。如果鑰匙圖示消失，問題較接近系統終止服務；如果圖示仍在但無法存取，可能是線路失效、握手逾時、DNS 解析失敗，或網路切換後舊工作階段沒有正確重建。
建議依照這個順序調整
- 在系統的應用程式電量設定中，將用戶端改為允許背景執行或不限制電量使用。不同品牌的選單名稱可能不同，應以系統對該設定的說明為準。
- 允許用戶端顯示持續連線通知。通知不只能查看狀態，也表示前景服務仍在執行；如果通知與鑰匙圖示同時消失，通常需要重新檢查背景權限。
- 若系統提供自動啟動、背景啟動或工作鎖定選項，可為用戶端開啟。某些裝置沒有這些入口，不必安裝額外工具強行尋找。
- 完成設定後重新連線，再依序執行鎖定螢幕、解鎖、切換網路與返回應用程式，觀察通道是否恢復以及出口是否保持一致。
- 仍然斷線時查看用戶端記錄。連線握手失敗與程序遭終止是兩類問題，處理方式不能混為一談。
背景測試還要涵蓋網路切換。Android 裝置離開無線網路後會改用行動網路，原本的 TCP 或 UDP 工作階段通常無法原樣延續，用戶端需要重新建立通道。此時短暫重新連線不等於保活失敗；真正的問題是用戶端長時間沒有恢復，或介面仍顯示已連線而出口已經改變。Hysteria2、TUIC 等基於 QUIC 與 UDP 的方案，針對不穩定網路進行設計，但實際恢復能力仍取決於用戶端實作、伺服器設定，以及目前網路是否允許 UDP 通訊。
分應用程式代理：納入、排除與 DNS 路徑
分應用程式代理常見兩種邏輯：一種只讓選取的應用程式進入通道，另一種讓所有應用程式進入通道，再排除選取的應用程式。兩種模式看似相反，誤選後結果也完全相反。設定前應先寫清楚目標，例如「瀏覽器與協作工具使用代理，其餘應用程式直連」，再依照用戶端文案選擇納入模式，而不是看到應用程式清單就直接勾選。
應用程式是否進入通道，與網域是否命中代理規則是兩個層級。依應用程式分流決定哪個應用程式的流量交給虛擬網路介面；網域與 IP 規則則決定進入用戶端後的連線使用代理或直連。若瀏覽器已納入，但規則將目標網域判定為直連，出口仍可能不是預期位置。反過來，應用程式被排除後，即使訂閱中存在相關代理規則，也無法接管它的連線。
| 檢查對象 | 常見誤區 | 正確驗證方式 |
|---|---|---|
| 應用程式範圍 | 把排除清單當成納入清單 | 分別使用已納入與未納入的應用程式存取出口查詢頁，比對結果 |
| 網域規則 | 以為應用程式進入通道後必然使用代理 | 查看連線記錄中的規則命中結果與最終出口 |
| DNS | 只檢查網頁出口，不檢查解析伺服器 | 在連線狀態下執行 DNS 洩漏檢測，並對照用戶端 DNS 設定 |
| IPv6 | 只設定 IPv4 路由 | 檢查用戶端是否接管 IPv6；不支援時依照用戶端說明處理 |
| 網路切換 | 看到連線圖示就以為工作階段已恢復 | 切換網路後重新檢查出口、DNS 與實際存取 |
DNS 洩漏通常指網域查詢沒有經過預期的解析路徑，導致本地網路仍能看見查詢要求，或解析結果與代理出口所在區域不一致。Android 用戶端可能使用通道內 DNS、系統 DNS、加密 DNS，也可能依規則讓不同網域選擇不同解析方式。瀏覽器自身的安全 DNS 設定還可能覆蓋部分系統行為，因此測試時要記錄瀏覽器設定，避免把瀏覽器獨立解析誤判為用戶端故障。
所謂「流量外洩」也需要準確描述。如果某個應用程式被主動排除，它直連是設定結果，不是技術性洩漏；如果應用程式原本應被納入，卻因路由缺失、IPv6 未接管或通道中斷而直接存取，才是需要修正的問題。最可靠的做法是先使用全域代理完成基準驗證，確認出口與 DNS 都正確，再開啟規則分流，最後加入依應用程式分流。一次只變更一個變數，才容易定位錯誤。
協定選擇：相容性、網路條件與耗電取捨
Android 用戶端支援的協定各不相同，訂閱連結也不一定能被所有軟體完整識別。訂閱連結通常會回傳一組節點設定，用戶端匯入後再解析 Shadowsocks、VMess、Trojan、VLESS、Hysteria2 或 TUIC 等協定。匯入成功只代表格式已被識別；若用戶端核心不支援節點所需的傳輸方式、TLS 參數或延伸設定，連線仍可能失敗。
| 協定 | Android 裝置注意事項 | 適合優先檢查的網路條件 |
|---|---|---|
| Shadowsocks | 實作成熟、設定相對直接，但本身是代理協定，是否接管整台裝置取決於用戶端的 VPNService 實作 | 先檢查加密方式是否受用戶端支援，再驗證 UDP 與 DNS 轉送 |
| VMess | 取決於用戶端與伺服器參數一致，裝置時間明顯不準時可能影響驗證 | 核對傳輸層、TLS 與時間設定，不要只是不斷更換位址 |
| Trojan | 通常搭配 TLS 使用，憑證、網域與伺服器設定需要相符 | 握手失敗時優先檢查網域解析、憑證狀態與系統時間 |
| VLESS | 協定本身較精簡，實際能力與所設定的傳輸層、安全層及用戶端核心有關 | 確認訂閱中的延伸參數已被目前用戶端完整識別 |
| Hysteria2 | 基於 QUIC 與 UDP，適合關注封包遺失環境下的傳輸表現，但並非所有網路都能良好支援 UDP | 連線失敗時改用其他網路交叉驗證，判斷是否存在 UDP 限制 |
| TUIC | 同樣使用 QUIC 與 UDP，用戶端版本與伺服器參數的相容性非常重要 | 檢查核心支援、壅塞控制設定，以及網路對 UDP 的處理方式 |
協定名稱不能直接等同於速度排名。連線體驗會受到線路路徑、入口負載、跨境鏈路、裝置效能、用戶端核心與目前網路策略共同影響。在無線網路上表現良好的 UDP 協定，換到限制 UDP 的網路後可能無法建立連線；基於 TCP 的方案雖然較容易通過某些網路環境，卻可能在封包遺失時出現明顯等待。合理的訂閱應提供與用戶端相容的設定，並允許依網路條件切換，而不是要求使用者長期固定使用單一協定。
匯入訂閱時，應從服務帳戶中複製訂閱連結，再於受信任的用戶端使用「從剪貼簿匯入」或「新增訂閱」。訂閱連結通常包含存取憑證，應視同帳戶金鑰保管，不要發布到公開頁面，也不要交給不明的線上轉換工具。更新訂閱前可以保留目前可用的設定；更新後若節點消失，應先檢查訂閱狀態與用戶端篩選條件。
可重現實測：從匯入到洩漏檢查
以下流程不依賴特定品牌裝置，也不需要虛構延遲數字。它將測試拆成多個可觀察結果，適合在更換用戶端、更新訂閱或調整省電策略後重複執行。
- 建立直連基準。連線前記錄目前出口所在區域與 DNS 檢測結果，供後續比對。不要把本地網路原本的異常歸因於代理用戶端。
- 匯入並核對訂閱。確認訂閱名稱、節點協定與更新時間能正常顯示。若只出現部分協定，請檢查用戶端核心是否支援對應格式。
- 先啟用全域模式。連線後再次檢查出口與 DNS。此階段先排除複雜規則的影響，確認基本通道能接管流量。
- 執行鎖定螢幕測試。鎖定螢幕並稍後解鎖，檢查持續通知、系統鑰匙圖示、用戶端狀態與出口位置是否一致。
- 執行網路切換測試。在無線網路與行動網路之間切換，等待用戶端完成重新連線，再檢查實際存取，不能只看圖示。
- 加入規則分流。切換至規則模式，透過記錄確認目標網域命中代理或直連規則。遇到錯誤時先修正规則，再加入應用程式分流。
- 加入依應用程式分流。分別測試一個應使用代理的應用程式，以及一個應直連的應用程式，確認兩者出口符合預期。
- 檢查 DNS 與 IPv6。確認解析要求與 IPv6 連線沒有繞過預期路徑。若用戶端不支援完整接管，請依照其說明調整系統設定。
如果測試失敗，應依現象分組處理。程序消失就回到電量與背景權限；通道存在但無法存取，就檢查節點、協定與 DNS；只有部分應用程式異常，就檢查應用程式範圍與網域規則；切換網路後失敗，則以另一種協定或線路交叉驗證。不要同時修改省電、協定、節點與分流規則，否則即使恢復，也很難知道真正有效的是哪項調整。
最終建議：不同使用方式怎麼選
如果主要需求是瀏覽器、協作工具與串流媒體應用程式，優先選擇支援清楚的分應用程式規則、DNS 設定與自動重新連線的用戶端。先將常用應用程式納入代理，再讓本地服務保持直連，可以減少不必要的繞路。若經常在不同網路間移動，應重點測試重新連線能力，並保留可在 TCP 與 UDP 網路條件下切換的協定方案。
如果希望裝置上的連線盡量統一經過通道，可以使用全域模式，並在用戶端相容時評估系統的「一律開啟」功能。此時仍要驗證 DNS 與 IPv6，不能把「全域」理解為自然涵蓋所有協定堆疊。若應用程式數量多、規則複雜，建議從簡單設定開始，確認基本連線穩定後再逐步加入規則。
用戶端與路由器方案也不能完全互相取代。Android 用戶端可以精確控制單一應用程式、跟隨裝置移動，並直接查看本機記錄；路由器方案適合統一處理家庭網路中的裝置，但通常無法像 Android 用戶端一樣方便地辨識每個應用程式。對經常離開家庭網路的裝置而言，用戶端仍是必要的連線層。