選擇 Android VPN 時，協定名稱與節點數量只是基本條件。真正影響日常使用的，往往是應用程式切到背景後能否維持連線、省電策略是否會終止 VPN 程序，以及分應用代理能否準確排除本地服務。本文聚焦這些 Android 特有問題，提供可重現的檢查流程，而不是只看客戶端畫面上的「已連線」。
測試時必須分辨「線路故障」與「客戶端被系統回收」。前者通常表現為 VPN 程序仍在執行、系統鑰匙圖示仍顯示，但目標要求逾時；後者則常伴隨常駐通知消失、VPN 標記撤銷，重新開啟客戶端後才恢復。兩種現象看似都是斷線，處理方式卻完全不同。
Android VPN 為什麼會在背景斷線
Android 客戶端通常透過系統的 VPNService 建立虛擬網路介面。應用程式在前景時，核心程序、設定介面與網路狀態都容易保持活躍；螢幕關閉或應用程式進入背景後，系統會根據電量策略、背景限制與裝置製造商的程序管理規則重新分配資源。如果客戶端沒有穩定執行前景服務，或使用者將其設為受限制的電量模式，連線就可能遭系統終止。
這裡的「前景服務」不是要求設定頁面一直顯示，而是客戶端透過常駐通知告知系統：VPN 核心正在執行使用者可感知的持續工作。常駐通知消失通常是重要訊號，但不能只靠通知判斷線路品質。有些客戶端會保留通知，卻因上游網路變化而暫時無法傳輸；也有系統會摺疊通知，但 VPN 介面仍然有效。
網路切換也是常見觸發點。裝置從無線網路切換到行動網路，或從一個存取點漫遊到另一個存取點時，底層網路位址與路由都會改變。能正確回應網路回呼的客戶端會嘗試重建傳輸層連線；處理不完整的客戶端可能保留舊工作階段，介面仍顯示已連線，實際要求卻停留在已失效的路徑上。Hysteria2、TUIC 等採用 UDP 與 QUIC 思路的實作，可利用協定本身的機制改善部分網路波動情境，但實際恢復能力仍取決於客戶端實作、伺服器設定，以及目前網路是否允許相應流量，不能只憑協定名稱下結論。
系統的「永遠開啟 VPN」可在連線意外退出後要求重新建立 VPN。若同時啟用「封鎖未使用 VPN 的連線」一類設定，VPN 尚未就緒時，普通流量會被攔截。這適合要求流量不得繞過隧道的情境，但設定錯誤時也會表現為整部裝置無法連網。排查期間應先確認客戶端本身能穩定連線，再決定是否啟用嚴格封鎖。
| 觀察現象 | 較可能的原因 | 優先檢查項目 |
|---|---|---|
| 鎖定螢幕後 VPN 標記與常駐通知同時消失 | 應用程式程序遭背景策略終止 | 電量限制、背景執行權限、前景服務狀態 |
| VPN 標記存在，但所有目標要求都逾時 | 上游線路失效，或網路切換後工作階段未恢復 | 重新連線、切換協定、核對底層網路 |
| 瀏覽器可用，特定應用程式無法使用 | 分應用清單或網域分流規則不相符 | 應用程式套件名稱、代理模式、規則命中紀錄 |
| 出口 IP 正確，但 DNS 歸屬不符合預期 | DNS 未進入隧道，或與系統私人 DNS 產生互動 | 客戶端 DNS 設定、私人 DNS、IPv6 路徑 |
| 網路切換後介面仍顯示已連線，但無法存取 | 客戶端保留了舊網路上的傳輸工作階段 | 斷線重連、網路變更處理、客戶端版本 |
省電策略應該如何設定
Android 系統中的「最佳化」「受限制」「不受限制」等名稱，會隨系統版本與裝置製造商而變化，但判斷原則一致：VPN 核心需要持續處理網路資料，不適合被視為長期閒置的普通背景應用程式。若系統提供單一應用程式的電量管理，應讓正在使用的 VPN 客戶端具備持續在背景執行的條件。
同時也要注意，允許背景執行不等於允許客戶端任意自動啟動。部分裝置會將電量策略、背景啟動、關聯啟動與通知權限拆分到不同入口。VPN 已由使用者主動連線後，最重要的是不要終止核心服務；如果希望裝置重新啟動後自動恢復，還要檢查客戶端是否支援啟動時連線，以及系統是否允許相關啟動行為。
- ✅ 將正在使用的 VPN 客戶端移出受限制的電量模式，避免鎖定螢幕後核心程序直接遭到終止。
- ✅ 保留客戶端的常駐連線通知，以便判斷前景服務是否仍在執行。
- ✅ 在無線網路與行動網路之間切換後，重新檢查出口 IP，而不是只看連線按鈕的顏色。
- ✅ 若需要嚴格防止繞行，先完成穩定性驗證，再設定系統的永遠開啟與封鎖選項。
- ❌ 不要同時執行多個會爭用系統 VPN 介面的客戶端；後啟動的客戶端可能會取代目前的連線。
- ❌ 不要把「清理背景」當作網路修復步驟；這類操作往往會連同 VPN 核心一起終止。
- ❌ 不要只因協定交握成功，就認定設定已完成；DNS、IPv6 與分應用規則仍需分別核對。
省電白名單也不是越多越好。只需針對實際負責 VPNService 的客戶端進行調整，不要替所有網路工具解除限制。若使用訂閱型通用客戶端，真正執行核心的是匯入訂閱的客戶端；訂閱提供方的網頁或輔助應用程式不一定負責隧道處理，調整錯誤對象並不會改善保活。
分應用代理不是普通的分流
分應用代理決定哪些 Android 應用程式會進入 VPN 虛擬介面，通常依據應用程式套件名稱運作；網域或 IP 分流則發生在流量進入客戶端核心後，根據目標位址、網域、規則集或連接埠決定走代理線路還是本地直連。兩者位於不同層級，不能互相取代。
例如，將瀏覽器加入代理應用程式清單，只代表該瀏覽器的連線交由 VPN 核心處理。核心內部仍可能根據規則，讓某些網域直連。反過來，即使規則集中寫入某個國際網站網域，如果對應的應用程式根本不在代理清單內，該流量也不會進入核心，自然沒有機會命中網域規則。
常見客戶端會提供「僅代理選取的應用程式」與「繞過選取的應用程式」兩種模式。前者適合範圍明確的情境：清單以外的應用程式維持本地網路；後者適合大部分流量都經過 VPN、只排除本地服務的情境。設定時必須先確認目前模式，不能只看清單中是否出現應用程式名稱。同一份清單在兩種模式下會得到相反結果。
系統元件與嵌入式網頁會增加判斷難度。某個應用程式顯示的登入頁，可能由系統 WebView 或外部瀏覽器承載，要求不一定全部歸屬於原應用程式。推播、下載服務與媒體播放也可能呼叫獨立元件。遇到「主頁面可開啟、登入或播放失敗」時，應檢查參與要求的元件，而不是立刻判定節點不支援目標服務。
共用網路也需要單獨驗證。Android 裝置本身透過 VPNService 傳送的流量，與熱點下游裝置的轉發流量並不是同一回事。多數普通客戶端的分應用清單只認得本機應用程式套件名稱，不能據此推論下游裝置也會經過相同隧道。需要共用線路時，應確認客戶端是否明確提供相關轉發能力，並在下游裝置上核對出口。
協定與 Android 客戶端如何匹配
Shadowsocks、VMess、Trojan、VLESS、Hysteria2 與 TUIC 都可能出現在訂閱中，但協定本身不負責 Android 背景保活。保活取決於客戶端的 VPNService、核心程序管理、網路變更處理與系統策略。因此，同一份訂閱匯入不同客戶端後，背景表現可能不同；這不一定代表線路發生變化，也可能是客戶端核心版本與實作路徑不同。
Shadowsocks、VMess、VLESS 與 Trojan
Shadowsocks 設定相對直接，客戶端生態成熟，適合規則清楚、優先考量相容性的情境。VMess 與 VLESS 常見於支援多種傳輸方式的客戶端生態；VLESS 本身不提供與 VMess 相同的驗證與加密組合，安全性與傳輸特徵需要結合 TLS、Reality 或其他承載設定理解。Trojan 通常運作於 TLS 承載之上，憑證名稱、系統時間與伺服器設定不相符，都可能導致交握失敗。
這些協定能否在背景穩定執行，主要取決於客戶端是否可靠維護前景服務、是否在網路變更後重建連線，以及訂閱轉換過程是否遺失傳輸參數。只複製伺服器位址與連接埠，不足以還原完整節點；路徑、主機名稱、傳輸層、安全層與憑證驗證選項都可能是必要欄位。
Hysteria2 與 TUIC
Hysteria2 與 TUIC 通常採用以 UDP 為基礎的現代傳輸設計，在抖動或封包遺失情境下，可能呈現不同於傳統 TCP 承載的恢復特徵。但如果目前網路限制 UDP、客戶端核心版本不相容，或憑證與壅塞控制設定不匹配，也可能出現交握失敗、連線後沒有流量或頻繁回退。Android 推薦方案不應只押注單一協定，客戶端至少應讓使用者能在不同網路條件下切換已驗證的節點類型。
IEPL 專線、中轉線路與直連線路描述的是網路路徑，不是客戶端協定。直連表示裝置直接存取節點入口，路徑更取決於目前電信業者至入口的公網品質；中轉通常先連入中轉入口，再由服務端轉送至出口；IEPL 專線則強調特定區段採用專線承載。即使使用 IEPL，裝置到入口的接入段仍會受本地網路影響；即使協定相同，不同路徑也可能呈現不同穩定性。
| 方案面向 | 主要決定因素 | Android 端核對重點 |
|---|---|---|
| Shadowsocks | 加密設定、伺服器相容性與線路路徑 | 客戶端核心支援、UDP 需求、規則模式 |
| VMess / VLESS | 傳輸參數、安全層與伺服器設定 | 訂閱欄位是否完整、網路切換後能否重建 |
| Trojan | TLS 設定、憑證名稱與系統時間 | 憑證驗證、SNI 設定、背景服務狀態 |
| Hysteria2 / TUIC | UDP 可達性、核心相容性與伺服器參數 | 目前網路是否限制 UDP、切換網路後的恢復表現 |
| IEPL / 中轉 / 直連 | 入口位置、承載路徑與目前接入網路 | 不要與協定混為一談，按實際路徑重新測試 |
訂閱匯入後的實測流程
訂閱連結通常會回傳一組節點或客戶端可識別的設定內容。匯入時應優先使用客戶端提供的「從剪貼簿匯入」「新增訂閱」或掃描 QR Code 入口，不要在不受信任的網頁中貼上訂閱位址。訂閱連結本身可能包含存取憑證，應按照帳戶憑證管理，避免公開截圖或轉發。
- 確認客戶端相容性。先核對客戶端是否支援訂閱中的協定與傳輸參數。客戶端能讀取節點名稱，不代表其核心一定支援節點使用的完整設定。
- 匯入並更新訂閱。檢查匯入結果是否包含預期節點，留意更新失敗、憑證錯誤與格式不受支援等提示。不要將空清單誤判為所有線路都離線。
- 建立基本連線。先關閉複雜分流，使用可控的全域代理或客戶端預設模式，驗證節點能否建立連線。基本連線尚未通過時，不應同時修改大量規則。
- 核對出口 IP。分別查看連線前後的公網出口歸屬。若沒有變化，應檢查應用程式是否進入 VPN、瀏覽器是否重用了舊連線，以及系統中是否存在其他 VPN 設定。
- 核對 DNS 與 IPv6。檢查網域解析要求是否經過預期路徑，並分別觀察 IPv4 與 IPv6。只有其中一類位址經過隧道時，目標服務仍可能看到本地網路路徑。
- 加入背景情境。保持連線後切換應用程式、關閉螢幕，再回到瀏覽器或目標應用程式發起新要求。測試重點是新連線能否成功，而不是舊頁面是否仍停留在快取內容。
- 加入網路切換。在不同接入網路之間切換，等待客戶端處理網路變更，再重新檢查出口與 DNS。若必須手動斷線才能恢復，應記錄為客戶端或協定組合的切換網路恢復問題。
- 最後啟用分流。基本鏈路穩定後，再逐步加入分應用清單、網域規則與直連規則。每次只變更一類設定，才能定位是哪一層導致異常。
DNS 洩漏與假連線如何排查
DNS 洩漏是指業務流量已經經過 VPN，但網域查詢仍交由本地網路或其他非預期解析器處理。它不一定會導致網頁無法開啟，卻可能暴露所存取網域的解析要求，也可能造成內容分區判斷衝突。Android 的私人 DNS、客戶端內建 DNS、瀏覽器加密 DNS 與系統解析路徑可能同時參與，排查時需要逐層簡化。
先確認客戶端是否接管 DNS，並查看分流規則是否將解析要求或解析器位址設為直連。接著檢查 Android 私人 DNS。私人 DNS 使用系統層級的加密解析；它與 VPN 客戶端的處理方式取決於客戶端路由與系統實作，不能籠統認定一定洩漏或一定安全。如果解析結果異常，可暫時恢復系統預設狀態進行比對，再決定由系統或客戶端統一負責解析。
瀏覽器也可能啟用自己的安全 DNS。此時系統測試與瀏覽器測試可能得到不同結果。排查時應分別驗證系統應用程式與瀏覽器，並留意瀏覽器是否重用連線、快取解析結果，或透過自身代理機制傳送要求。清除單一網站狀態或建立無快取工作階段，比反覆切換節點更容易排除快取干擾。
IPv6 也會製造「看起來已連線」的假象。如果客戶端只接管 IPv4，而目前網路與目標同時支援 IPv6，部分要求可能優先使用未進入隧道的 IPv6 路徑。正確做法是確認客戶端是否接管 IPv6、是否明確封鎖未經代理的 IPv6，或伺服器是否提供相應支援，而不是預設關閉系統網路能力後就不再檢查。
檢查順序
連線前：記錄出口歸屬與 DNS 路徑
連線後：重新查詢出口，不重用舊頁面
分應用：分別測試清單內與清單外應用程式
位址族：分別觀察 IPv4 與 IPv6
切到背景：恢復後發起新的網路要求
切換網路：再次核對出口與 DNS
發生異常時：每次只變更一類設定依使用情境選擇 Android 方案
如果主要需求是瀏覽器與少量國際應用程式，可以採用「僅代理選取的應用程式」，減少本地服務進入隧道的機會。此時要將實際承載登入、下載或播放的元件納入驗證範圍，並確認網域規則沒有將關鍵要求錯誤設為直連。
如果需要大部分應用程式統一經過 VPN，可以採用預設代理，並排除明確需要本地出口的應用程式。這種模式設定較省事，但必須注意系統元件、區域網路存取與本地服務的相容性。對於區域網路裝置存取，應查看客戶端是否提供繞過區域網路選項，避免列印、投放或本地管理頁面被送往遠端線路。
如果連線經常遇到網路切換，應將客戶端的自動重連與切換網路恢復列為首要驗收項目。協定選擇可以保留替代方案：目前網路不適合 UDP 時，切換至已驗證的其他承載；某條直連路徑波動明顯時，再比較中轉或專線路徑。不要在同一次測試中同時更換協定、節點、客戶端與 DNS，否則即使恢復，也無法確認是哪項調整生效。
對於需要長時間背景連線的情境，應啟用必要的背景執行權限、保留常駐通知，並在系統允許的情況下設定永遠開啟 VPN。嚴格封鎖適合已完成設定驗收的環境，不適合用來掩蓋連線不穩定。任何自動連線設定都應搭配出口與 DNS 複查，避免裝置重新啟動後只恢復介面狀態，卻沒有恢復實際流量路徑。