想在 Android 上讓不同 App 使用不同網路路徑，核心不是單純開啟或關閉 VPN，而是設定「應用程式分流」或「每個 App 的 VPN 規則」。啟用後，可以讓指定 App 透過 VPN 通道連線，同時讓其他 App 維持一般網路；也可以反過來，只讓少數 App 直連，其餘流量全部交給 VPN。這種方式能減少不必要的流量經過代理，也有助於處理本地服務、銀行 App、遊戲與串流 App 之間互相衝突的情況。
Android 的分流功能通常由 VPN 用戶端建立系統 VPN 介面，再根據應用程式識別資訊決定封包是否進入通道。不同用戶端的名稱可能是「應用程式分流」、「App 例外」、「繞過 VPN」、「僅代理選定 App」或「排除應用程式」，但概念大致相同。設定前應先確認目前使用的是支援分流的官方 Android 用戶端，或是能正確解析訂閱設定的相容客戶端；單純匯入節點而不支援應用程式規則的工具，無法完成這項設定。
Android VPN 分流的運作方式
Android 本身會把 VPN 用戶端視為一個系統網路介面。當用戶端連線後，系統會詢問是否允許該應用程式建立 VPN；使用者確認後，符合規則的流量便會交給用戶端處理。應用程式分流則是在這個層級上加入判斷：用戶端根據 App 的套件名稱或系統識別資訊，將流量送入 VPN，或明確排除在 VPN 之外。
最常見的第一種模式是「包含清單」。在這個模式中，只有你選取的 App 會使用 VPN，其餘 App 直連。它適合只需要特定瀏覽器、AI 工具、影音服務或工作 App 使用指定線路的情境。第二種模式是「排除清單」，也就是大部分 App 都走 VPN，只有選取的 App 直連。這種模式適合希望維持全域保護，但又需要讓本地支付、區域服務或公司內網不經 VPN 的情境。
分流只決定流量是否進入 VPN，不等於改變 App 內部的地區設定、帳戶地區或服務權限。某個 App 直連後，實際出口會由目前的行動數據或 Wi-Fi 網路決定；某個 App 走 VPN 後，出口則由所選節點與協定決定。DNS 也可能受到用戶端設定影響，因此驗證時不能只看 App 是否能開啟，還要確認實際出口與名稱解析是否符合預期。
2
主要分流模式
5
支援平台
110+
國家覆蓋
210+
線路數
設定前的用戶端與規則準備
開始之前，先確認 Android 裝置已安裝官方用戶端，或確認第三方客戶端支援目前的訂閱格式與協定。常見協定包括 Shadowsocks、VMess、Trojan、Hysteria2 與 WireGuard，但「支援匯入節點」不代表一定支援 App 分流。部分工具可以使用訂閱更新節點，卻只提供全域、規則與直連等流量模式；部分工具則可以依 App 套件名稱建立規則。兩者需要分開確認。
如果尚未取得用戶端，可以先從新手指引瞭解安裝與訂閱匯入流程。從使用者面板複製訂閱連結後，應在用戶端的「從 URL 匯入」、「新增訂閱」或相近入口貼上。訂閱連結包含帳戶存取資訊，不要公開貼出，也不要為了轉換格式而提交到來源不明的網站。匯入完成後，先更新訂閱，再選擇一條可用節點，最後才開始設定 App 規則。
先列出需要直連與需要代理的 App
建議不要一開始就勾選大量應用程式。先按照用途分成兩組：第一組是必須透過 VPN 的 App，例如需要特定地區出口的瀏覽器、影音服務或遠端工作工具；第二組是希望維持本地網路的 App，例如支付工具、銀行服務、家用設備控制程式或需要連線到區域內網的 App。這樣做可以避免規則名稱與實際需求混在一起。
還要留意一個 App 可能依賴其他服務。影音 App 可能需要 Google Play 服務、推播服務或內嵌網頁元件；遊戲也可能透過獨立的登入服務、更新服務與內容分發網域連線。若只排除主程式，卻讓必要元件走另一條路，可能出現登入失敗、通知延遲或內容載入不完整。排查時應先觀察完整功能，再決定是否需要調整相關 App。
- ✅ 先確認訂閱已成功更新，再建立 App 分流規則。
- ✅ 把需要代理與需要直連的 App 分成兩份清單。
- ✅ 記下目前使用的節點、協定與分流模式，方便之後復原。
- ✅ 對銀行、支付、公司內網等 App，優先測試直連模式。
- ❌ 不要同時開啟兩個 VPN 用戶端，避免系統只保留其中一個 VPN 介面。
- ❌ 不要把訂閱連結或包含節點憑證的截圖分享給其他人。
Android 應用程式分流的實際設定步驟
以下流程適用於大多數提供 App 分流功能的 Android 用戶端，實際按鈕名稱可能因版本而不同。介面若沒有「應用程式分流」字樣，可以在連線設定、路由設定、進階設定或 VPN 設定中尋找「繞過 VPN」與「僅代理選定 App」等選項。
- 開啟用戶端並更新訂閱。進入節點或訂閱頁，執行更新操作，確認清單中出現可選節點。若更新失敗，先檢查訂閱連結是否完整、目前網路是否能開啟面板，以及 Android 是否限制用戶端使用行動數據。
- 選擇一條測試線路。先使用同一條線路完成測試，不要在設定分流的同時頻繁更換節點。若用戶端提供地區、線路類型或協定選項，應先使用容易辨識的設定，方便之後判斷問題來自規則還是節點。
- 進入路由或應用程式設定。找到「App 分流」、「應用程式代理」、「VPN 例外」或相近功能，先閱讀目前模式。常見選項會讓你在「僅選定 App 走 VPN」與「選定 App 直連」之間切換。
- 選擇正確的模式。如果你只想讓少數 App 走 VPN，選擇僅代理選定 App；如果你想讓大部分 App 走 VPN，只排除幾個本地服務，則選擇排除清單或繞過 VPN。不要只根據勾選數量判斷，應以模式文字為準。
- 勾選需要測試的 App。先加入一個或少數幾個 App，儲存後重新連線。一次加入太多程式，會讓你無法知道是哪個規則造成登入、通知或載入問題。
- 重新建立 VPN 連線。修改規則後，先在用戶端主動斷線，再重新連線。部分 Android 用戶端會在儲存設定後自動重啟通道，但手動重連能降低舊路由仍留在記憶體中的可能性。
- 逐一驗證結果。分別開啟被選取的 App 與未被選取的 App，檢查頁面、登入、圖片、通知與主要功能。若用戶端提供連線記錄，也可以觀察規則命中或路由模式是否符合預期。
| 設定目的 | 應選模式 | 適合的檢查方式 |
|---|---|---|
| 只有指定 App 使用 VPN | 僅代理選定 App | 比較指定 App 與一般瀏覽器的出口 |
| 大部分 App 使用 VPN | 排除選定 App 或繞過 VPN | 確認被排除 App 可正常使用本地服務 |
| 測試規則是否更新 | 儲存後重新連線 | 查看用戶端狀態與實際網路請求 |
| 排查單一 App 異常 | 暫時只保留一條規則 | 清除該 App 工作階段後重新登入 |
如何確認 App 分流真的生效
判斷分流是否成功，不能只看 Android 頂端的 VPN 圖示。該圖示通常只代表系統存在一個 VPN 連線，不會告訴你某個 App 是否命中代理規則。更可靠的做法是選擇一個會發出明確網路請求的 App，記錄它的出口位址、頁面內容或服務地區，再與直連 App 進行比較。測試期間要保持同一個 Wi-Fi 或行動網路，避免網路環境變動幹擾結果。
可以先測試「僅代理選定 App」模式：將瀏覽器加入清單，開啟 IP 檢測頁面，記錄看到的出口資訊；接著開啟未加入清單的另一個瀏覽器或本地服務，確認它沒有套用相同的 VPN 路徑。需要注意的是，有些 App 會使用系統 WebView 或外部瀏覽器完成登入，畫面看似在同一個 App 內，實際請求卻由另一個元件送出，因此不能只依畫面位置推斷規則歸屬。
DNS 是另一個容易忽略的部分。若 App 可以連線，但網域解析結果不符合預期，可能是分流規則只處理了傳輸路徑，DNS 仍由系統或本地網路處理。不同用戶端對 DNS 分流、遠端解析與防洩漏的支援不同，遇到特定網域無法載入時，應查看用戶端的 DNS 選項與日誌，而不是立刻認定節點失效。
設定失敗、通知延遲與耗電問題
如果 App 分流沒有生效，第一個檢查點是模式是否選反。很多用戶端把「繞過 VPN 的 App」列成勾選清單，勾選後代表直連；另一些用戶端則把清單定義為「通過 VPN 的 App」。同樣的勾選動作，在不同工具中可能得到相反結果。請先清除目前規則，只保留一個測試 App，再重新連線，這比在複雜清單中逐項猜測更有效。
第二個檢查點是 Android 的背景限制。省電模式、背景活動限制、待機最佳化與廠商自訂的自動清理功能，都可能讓 VPN 用戶端在螢幕關閉後停止維持通道。若問題只在鎖定螢幕、切換 App 或長時間待機後出現，應把用戶端設為允許背景活動，並檢查系統是否限制其使用電池與網路。不同品牌介面名稱不完全相同，通常可在應用程式電池設定或背景使用權限中調整。
通知延遲不一定是分流錯誤。若推播服務被排除在 VPN 外，通知可能依本地網路狀態傳送；若推播服務跟隨主程式進入 VPN，則需要確認節點與長連線是否穩定。部分 App 在背景時會暫停網路請求，重新回到前景才恢復，因此排查時應分別測試前景使用、螢幕關閉與重新開啟 App 三種狀態。
耗電增加通常與 VPN 通道持續運作、加密處理、頻繁重連或背景 App 不斷發出請求有關。分流可以減少部分流量進入通道，但不代表必然降低耗電。較實用的做法是選擇穩定的節點，避免讓不需要即時連線的 App 長時間留在 VPN 清單中，並檢查用戶端是否因網路切換而反覆重連。調整後至少觀察一段完整使用情境，再比較設定前後的電池消耗，避免只根據單次使用下結論。
- ✅ 分流失效時先確認清單含義，而不是立即重裝用戶端。
- ✅ 重新連線後再測試，確保新規則已寫入系統 VPN 介面。
- ✅ 只在鎖定螢幕後異常時，檢查 Android 背景與電池限制。
- ✅ 通知問題要分開測試前景、背景與重新開啟 App 的狀態。
- ❌ 不要把多個 VPN、系統代理與私人 DNS 同時改動，否則難以定位問題。
- ❌ 不要因為某個 App 無法載入，就直接判定所有節點或整個訂閱失效。
日常使用的分流整理方式
完成測試後，建議把規則整理成用途清楚的最小集合。需要特定出口的 App 放進代理清單，需要本地網路的 App 放進直連或排除清單，其餘程式則維持預設模式。規則越少，日後遇到服務更新、App 改名或系統升級時越容易維護。若用戶端支援匯出設定，也應先保存一份不含訂閱憑證的設定記錄；不要把完整訂閱內容與公開設定檔一起分享。
如果同一部 Android 裝置有工作與個人用途，可以按照使用情境建立兩組設定，但切換前要確認用戶端是否真正載入新規則。對於經常變更網路的使用者，建議優先選擇清晰、容易復原的規則：先使用全域或直連模式確認基本連線，再啟用 App 分流，最後只加入必要的例外。遇到問題時，恢復到上一個可用設定，比一次刪除所有節點與重新建立帳戶更安全。
Android VPN 分流的重點不是把所有 App 都分配到不同路徑，而是讓每一條規則都能被解釋、驗證與復原。先理解用戶端的包含與排除模式，再用單一 App 驗證出口、DNS 與背景行為，最後才擴充清單。這樣既能避免本地服務被錯誤代理，也能降低長時間連線時的耗電與排查成本。