Android VPN 分流的核心，不是把所有流量一律送進代理，而是先判斷哪些 App 需要遠端出口、哪些 App 應該維持本地直連。社羣平台、海外服務或需要特定地區出口的應用程式，可以指定經過代理；銀行、支付、公司內網與本地影音 App，則通常更適合直連。這樣做不只能減少不必要的流量轉送，也能降低部分 App 因出口地區改變而觸發重新驗證的機會。

Android 上的分流由三個部分共同完成：用戶端負責讀取訂閱、建立通道與套用規則；Android 系統負責授權 VPN 服務並接管網路請求；分流設定則決定哪些應用程式進入代理、哪些應用程式繞過代理。不同用戶端對「按 App 分流」、「排除 App」與「全域模式」的名稱可能不同，因此不能只看畫面上的 VPN 圖示判斷設定是否成功。真正的確認方式，是逐一檢查 App 的代理狀態、出口位置與實際連線結果。

Android App 分流到底在控制什麼

一般 Android VPN 用戶端會透過系統 VPN 介面建立虛擬通道。當某個 App 發出網路請求時，系統會將請求交給用戶端判斷：符合代理規則的流量送往節點，不符合規則的流量則直接使用目前的行動網路或 Wi-Fi。這個判斷可以按照 App、網域、IP 位址、地區資料庫或規則集完成，實際能力取決於用戶端與訂閱格式。

「代理指定 App」與「排除指定 App」是兩種相反的思路。前者是白名單模式，只讓列出的 App 經過代理，其餘 App 直連；後者是黑名單模式，讓大部分 App 經過代理，只把列出的 App 排除。若平常只有少數 App 需要特定出口，白名單通常較容易控制流量範圍；如果日常多數 App 都需要相同通道，黑名單則能減少逐一加入的工作。

還要分清「VPN 已連線」與「某個 App 已經使用代理」。Android 狀態列出現鑰匙或 VPN 圖示，只表示系統已授權一個 VPN 服務正在運作，不代表所有 App 都必然經過同一條節點。分流模式可能讓部分應用程式直連，也可能因 App 使用自有 DNS、QUIC、WebView 或背景服務而呈現不同結果。

90+

覆蓋國家

200+

可選線路

不限

同時在線裝置

如果使用 LWVPN，Android、Windows、macOS、iOS 與 Linux 都可使用相應用戶端；Android 端應先依官方說明取得相容用戶端，再匯入訂閱。訂閱內可能包含 Shadowsocks、VMess、Trojan、VLESS、Hysteria2 或 WireGuard 等不同設定，能否正常使用取決於用戶端是否支援該協定及其傳輸參數。不要因為某個 App 能讀取訂閱網址，就推定它能完整解析其中所有節點。

先選相容的 Android 用戶端

最穩妥的起點，是先確認服務方提供的 Android 官方用戶端或建議的相容客戶端。如果需要較細緻的規則控制，可以考慮支援 Android VPN 介面、訂閱匯入與 App 分流的 sing-box 或其他相容用戶端；Clash 系列 Android 客戶端則要確認其實際支援的設定格式與規則語法。Shadowrocket 主要是 iOS 用戶端，不應直接當作 Android 的安裝選項。

選擇用戶端時，建議檢查以下幾項：

  • ✅ 能否透過 Android 系統 VPN 介面接管流量，而不是隻設定瀏覽器代理。
  • ✅ 是否支援服務方提供的訂閱格式，以及訂閱中的節點協定與傳輸參數。
  • ✅ 是否有「按應用程式代理」或「排除應用程式」功能。
  • ✅ 是否能查看連線記錄、DNS 請求與規則命中狀態。
  • ❌ 不要從來源不明的網站下載名稱相近的 APK，也不要為了繞過錯誤而關閉憑證驗證。
  • ❌ 不要同時開啟兩個會建立 VPN 介面的用戶端，兩者通常會互相搶佔系統通道。

Android 官方用戶端通常比較適合希望快速連線、少量調整的使用者。它可能把分流選項放在連線設定、應用程式管理或進階路由中。sing-box 類用戶端通常提供更細緻的路由規則，但需要理解設定檔、DNS 模式與 TUN 行為。規則越複雜，調試成本越高；如果只需要讓一兩個 App 使用代理，應優先採用清楚的 App 清單，而不是一開始就加入大量網域規則。

匯入訂閱時，請只使用服務方提供的原始連結。訂閱連結可能包含存取憑證，應避免貼到線上轉換工具、公開羣組或共享筆記。若匯入後節點顯示空白、協定標記為未知，或更新時出現解析錯誤，應先檢查用戶端相容性與訂閱格式，不能靠反覆切換分流模式解決。

匯入訂閱後設定指定 App

完成用戶端安裝後，先不要立即建立複雜規則。建議按照「匯入訂閱、選擇節點、確認全域連線、設定 App 分流、重新測試」的順序進行。每完成一層就確認一次結果，這樣即使最後分流不如預期，也能知道問題是在節點連線還是規則套用。

  1. 取得訂閱連結。登入服務面板後複製 Android 用戶端可使用的訂閱網址。複製時確認沒有多餘空格、換行或標點符號。
  2. 建立遠端設定。在用戶端的「訂閱」、「設定檔」或「遠端資源」入口貼上連結，儲存後執行更新。
  3. 選擇節點或策略羣組。先依目標服務所在地選擇出口，再確認節點狀態可以正常連線。直連、中轉與 IEPL 專線代表不同路徑，不是單純的速度等級。
  4. 先用全域模式測試。暫時讓測試流量都經過代理，確認用戶端與節點本身沒有問題。
  5. 開啟 App 分流。選擇「代理指定應用程式」或「排除指定應用程式」，加入需要調整的 App，儲存規則並重新啟動 VPN 服務。
  6. 逐個檢查結果。先測試被指定的 App，再測試被排除的 App，最後檢查其他未列出的應用程式是否符合預期。

不同用戶端的選單名稱可能不同，但判斷邏輯大致一致。若畫面提供「僅代理選取的 App」，通常代表白名單模式；若提供「排除選取的 App」，通常代表黑名單模式。有些客戶端會把規則套用在目前設定檔，有些則會將規則寫入全域設定。儲存後若沒有任何變化，請檢查目前啟用的是否是剛剛修改的設定檔。

Android 可能會顯示 VPN 連線授權提示、電池最佳化提示或背景執行限制。這些權限會影響連線能否在螢幕關閉後維持，但不等於分流規則本身。若用戶端頻繁在背景停止，應在系統電池設定中檢查該 App 是否被限制；若只是一個指定 App 無法通過，則應回到規則、DNS 與應用程式自身設定排查。

操作結論：先以全域模式確認節點可用，再切換至指定 App 分流；不要在基礎連線尚未確認前直接修改大量規則。

如何確認指定 App 真的走代理

分流設定完成後，不能只看 Android 狀態列。應使用「對照測試」：在相同 Wi-Fi 或行動網路下，先關閉 VPN 記錄一次結果，再開啟 VPN 並測試同一個 App。對需要特定地區出口的服務，可以觀察登入地區、內容可見性或服務端顯示的連線位置；對一般 App，則可檢查是否能正常載入、是否出現額外驗證，以及用戶端記錄中是否有對應的網域請求。

最有效的方法通常包括三層：

  • 連線層：確認用戶端顯示已連線，且目前使用的是預期節點或策略羣組。
  • 規則層：查看用戶端記錄是否顯示該 App 的網域命中代理規則或直連規則。
  • 應用層：重新開啟 App，觀察登入、內容載入、圖片、通知與背景同步是否符合預期。

若指定 App 前景流量經過代理，但通知仍然延遲，可能是通知服務由另一個程序處理，或 Android 的背景限制阻止了連線。若 App 的首頁可以載入，圖片或影片卻失敗，則要檢查它是否使用不同網域、CDN、IPv6 或 UDP 傳輸。只把主網域加入規則，並不一定能涵蓋 App 的所有服務端點。

DNS 也可能造成「看起來已分流，實際結果不一致」。部分用戶端會讓 DNS 請求跟隨代理，部分模式則可能使用系統 DNS。如果 DNS 在本地解析、連線卻走遠端出口，某些服務可能回傳不同的伺服器；如果 DNS 請求被代理而本地服務需要內網解析，則直連 App 反而可能無法工作。設定 DNS 時，應以用戶端說明與目前模式為準，不要一次啟用多個互相衝突的 DNS 選項。

測試時最好先完全關閉 App，再從最近使用清單移除後重新開啟。部分 App 會在啟動時快取地區、DNS 或登入狀態，單純切換節點而不重啟 App，可能讓舊結果持續顯示。若服務有帳戶風控機制，也不要在短時間內連續切換多個國家或地區，以免觸發額外驗證。

常見問題與修正方式

指定 App 完全無法連線：先把模式切換至全域代理。如果全域模式也失敗，問題可能在節點、協定、網路入口或用戶端權限；如果全域模式正常，才回到 App 清單檢查是否選錯白名單與黑名單、是否漏儲存設定，或目前啟用的不是剛修改的設定檔。

未指定的 App 也經過代理：檢查目前是否仍處於全域模式。有些用戶端的「規則模式」與「全域模式」是獨立選項，完成 App 清單後仍需要手動切換。若使用 TUN 或類似系統層級接管，還要確認路由規則是否優先於 App 分流設定。

本地 App 無法使用：將該 App 加入排除清單，並確認它依賴的登入、圖片、推播與 API 網域是否也被直連處理。銀行與支付 App 可能會檢查出口、DNS、裝置環境與憑證狀態，分流只能改變網路路徑，不能保證所有風控條件都會通過。

連線後很快斷開：檢查 Android 電池最佳化、背景資料限制與用戶端的常駐通知權限。若使用 Hysteria2 或其他依賴 UDP 的傳輸，在公共 Wi-Fi、公司網路或行動網路限制 UDP 時，可以改用相容的 TCP/TLS 類協定作為對照。Shadowsocks、VMess、Trojan、VLESS、Hysteria2 與 WireGuard 的支援情況，仍應以目前用戶端和訂閱內容為準。

耗電或流量增加：VPN 服務需要維持通道，TUN 模式也可能讓更多系統流量進入用戶端處理。可以先縮小代理 App 範圍，避免把系統更新、雲端相簿同步與本地服務全部送入代理；同時檢查是否有 App 在背景持續重新連線。分流的目標不是讓所有流量都經過同一條線，而是把必要的流量交給合適的路徑。

  • ✅ 先確認節點能在全域模式下正常連線。
  • ✅ 以白名單或黑名單其中一種邏輯開始，不要同時堆疊多套規則。
  • ✅ 修改 App 清單後重啟 VPN 服務與目標 App。
  • ✅ 用用戶端記錄、出口結果與實際功能進行交叉確認。
  • ❌ 不要把 VPN 圖示當成所有 App 都已代理的證明。
  • ❌ 不要為了修正單一 App 而刪除整份訂閱或關閉安全驗證。

如果日常只有少數 App 需要特定出口，可以建立「指定 App 代理」清單，先加入確定需要的應用程式，再逐步補充其必要的網域。其他本地服務保持直連，通常比較容易維持登入狀態，也能避免不必要的流量消耗。如果工作上大部分應用程式都需要同一個出口，則可採用全域或規則模式，再將銀行、支付、公司內網與本地服務加入排除清單。

節點選擇方面，先按目標服務所在地區配對出口，再在同一地區比較直連、中轉與 IEPL 專線。直連路徑簡單，適合目前國際出口穩定的情況；中轉可作為避開部分不穩定路由的選項；IEPL 專線通常著重跨境區段的可控性，但本地 Wi-Fi、行動網路與目標服務一側仍會影響結果。不要只因節點名稱包含「高速」或「專線」就跳過實際測試。

最後，將設定分成「日常」、「影音」或「工作」等清楚的設定檔，並為每個設定檔保留簡單的用途說明。設定檔不宜加入無法確認的規則來源，也不要盲目下載大型規則集。每次修改後只變更一個條件，記錄哪個 App、哪個節點與哪種模式出現問題，之後更換網路時便能更快恢復可用狀態。

最終建議：Android App 分流的穩定做法，是以少量指定 App 開始，先驗證規則命中，再逐步處理 DNS、背景服務與備用協定；規則越精簡，日後越容易維護。