在 Android 上設定 VPN 分流，重點不是單純選一個節點，而是決定「哪些 App 進入 VPN、哪些 App 維持直連，以及規則由哪一層負責執行」。例如，瀏覽器、影音 App 或工作工具可能需要經過代理；銀行、地圖、智慧家居與本地服務則可能更適合直接連線。若所有流量都套用同一條路徑，可能增加不必要的繞行，也可能讓部分 App 因出口地區改變而要求重新驗證。

Android 的分流功能通常由 VPN 用戶端透過系統 VPN 介面實作。不同用戶端對「指定 App 代理」「指定 App 直連」「允許清單」「排除清單」的命名不完全一致，有些用戶端還會將 App 分流與網域規則、IP 規則分開管理。因此，設定前先確認目前使用的是官方 Android 客戶端、支援訂閱匯入的相容客戶端，還是以 sing-box、Clash Meta 等核心為基礎的應用程式，避免照著另一個介面的步驟操作。

90+

國家覆蓋

200+

線路數

不限

同時在線裝置

Android VPN 分流到底在控制什麼

Android VPN 分流可以從三個層面理解。第一層是裝置層級：用戶端是否建立系統 VPN 介面，是否接管裝置流量。第二層是 App 層級：某個應用程式的連線是否被納入 VPN，或被列入排除清單。第三層是目的地層級：已經進入 VPN 的請求，最後應該走代理出站、直連出站，還是被阻擋。

如果選擇「所有 App 都進入 VPN」，通常最容易理解，但本地服務、支付工具與區域敏感 App 也會看到遠端出口。如果選擇「僅指定 App 進入 VPN」，則只有清單中的應用程式使用 VPN，其餘 App 直接使用目前的 Wi‑Fi 或行動網路。另一種常見模式是「所有 App 進入 VPN，但排除指定 App」，適合大部分流量都需要統一路徑，只想讓少數應用程式直連的情境。

需要注意的是，App 分流不等於只攔截畫面上看到的主程式。部分 Android App 會透過獨立的背景服務、下載程序、WebView 或推播元件連線。若主程式已進入 VPN，但相關服務沒有被同樣處理，可能出現圖片載入失敗、通知延遲、登入狀態不同步或內容地區判斷不一致。

  • ✅ 先確認用戶端已取得 Android 系統 VPN 權限，再開始調整 App 清單。
  • ✅ 需要指定出口的 App，優先使用明確的允許清單，避免遺漏不必要的背景流量。
  • ✅ 需要本地網路的 App，可放入直連或排除清單，並在實際功能中驗證。
  • ❌ 不要同時啟用兩個 VPN 用戶端，否則系統通常只會保留其中一個 VPN 介面。
  • ❌ 不要只看狀態列的 VPN 圖示，圖示只能說明通道存在，不能證明每個 App 都按規則傳輸。

先選擇正確的分流模式

設定指定 App 代理前，先釐清自己的需求是「少數 App 使用 VPN」，還是「少數 App 不使用 VPN」。這兩者看似相反，實際上會影響規則維護成本。若平時只有瀏覽器、影音或某一個工作 App 需要指定線路，使用允許清單通常更安全；若大部分 App 都需要同一條路徑，只有銀行、地圖或本地服務要直連，排除清單會比較省事。

模式 流量結果 適合情境 需要留意
全域 VPN 大部分裝置流量進入 VPN，再由規則決定出站 需要統一測試出口，或多數 App 都使用同一路徑 本地服務也可能受到出口地區與 DNS 規則影響
允許清單 只有選定的 App 進入 VPN，其餘 App 直連 只有少數 App 需要代理 新安裝的 App 不會自動加入清單
排除清單 大部分 App 進入 VPN，被排除的 App 直連 只有少數本地 App 不應經過 VPN 背景服務與系統元件可能仍受整體 VPN 影響
應用程式內代理 由單一 App 自己使用代理設定 只想控制某個支援代理的 App 不一定能處理該 App 的所有背景連線

如果用戶端同時提供「VPN 模式」與「系統代理模式」，也要分清兩者差異。Android 系統代理通常只會影響遵循系統代理設定的應用程式；VPN 模式則透過系統 VPN 介面處理更廣泛的流量。部分遊戲、命令列環境或自行建立網路連線的 App 可能不理會系統代理，但仍可能被 VPN 介面接管。實際結果要以該用戶端的 Android 實作與 App 行為為準。

選擇結論： 需要代理的 App 很少時，先用允許清單；需要直連的 App 很少時，再用排除清單。不要一開始就用全域模式掩蓋分流範圍不清的問題。

動手設定指定 App 代理與直連

以下流程適用於大多數支援 Android App 分流的官方客戶端或相容客戶端。介面名稱可能顯示為「分應用代理」「按 App 分流」「應用程式代理」「排除 App」或「Bypass Apps」，但判斷邏輯基本相同。

  1. 先匯入訂閱並更新設定。 開啟客戶端的訂閱管理，貼上面板提供的訂閱連結，完成更新後確認節點清單已解析。不要把訂閱連結填入 Android 原生 VPN 的伺服器欄位，原生欄位通常無法直接解析訂閱格式。
  2. 選擇一條測試線路。 初次設定時先固定節點，不要一邊修改規則一邊切換不同國家或協定。Shadowsocks、VMess、Trojan、VLESS、Hysteria2 等協定的連線方式不同，但分流判斷仍由用戶端和 Android VPN 介面共同完成。
  3. 啟用 Android VPN 權限。 點擊連線後，系統會要求允許用戶端建立 VPN 連線。確認申請來源是目前使用的客戶端，再允許設定。若拒絕權限，節點可能顯示已選取，但 App 流量不會真正進入通道。
  4. 進入 App 分流頁面。 在設定、路由、分流或應用程式清單中，先選擇允許清單或排除清單。不要先勾選大量 App，再回頭猜測目前模式；應先讀懂頁面上的說明文字。
  5. 加入需要代理的 App。 例如將瀏覽器或特定工作工具加入允許清單。若同一服務有主程式與獨立下載工具，應分別確認套件名稱，不要只加入其中一個。
  6. 加入需要直連的 App。 在排除清單中選擇銀行、地圖、智慧家居或其他依賴本地網路的應用程式。部分用戶端會把「直連」與「不經 VPN」分成兩個選項，前者通常仍由規則引擎處理，後者則是直接排除於 VPN 之外。
  7. 保存設定並重新連線。 修改 App 清單後，先停止 VPN，再重新連線一次。Android 可能保留舊的 VPN 介面狀態，重新建立通道可避免新規則尚未套用。
  8. 逐一驗證。 先測試一個已指定代理的 App，再測試一個已指定直連的 App，最後測試未列入清單的 App。每次只改一項設定，才能知道是哪個規則造成結果變化。

如果客戶端提供規則模式，還要確認 App 分流與網域規則的優先順序。有些用戶端先按 App 判斷，再按網域選擇出站；有些用戶端則將「App 排除」視為最高優先級。當一個 App 已加入代理清單，但其中某個網域仍顯示直連時，應查看連線記錄，確認是 App 規則、網域規則、IP 規則還是 DNS 策略最後命中。

分流測試記錄
VPN 狀態：已連線
測試 App：已加入代理清單
預期結果：請求由代理出站
實際結果：查看連線記錄確認

直連測試 App：已加入排除清單
預期結果：請求不經 VPN
實際結果：在 App 內測試本地功能與網路連線

用出口、DNS 與 App 功能確認規則生效

驗證指定 App 代理時，不能只在瀏覽器中查詢出口 IP，因為瀏覽器可能使用自己的代理設定或快取。更可靠的做法是直接在已加入代理清單的 App 內執行實際請求，例如開啟需要登入的頁面、載入圖片、播放一段內容或完成一次 API 請求，再觀察是否符合預期。若 App 本身沒有顯示出口資訊，可使用同一用戶端的連線記錄，查看該 App 建立的網域連線最後使用哪個出站。

驗證直連 App 時，應檢查它是否能正常使用所在地區的服務，例如本地地圖、區域付款頁面、區域網路設備或公司內部資源。直連不代表一定更快，也不代表所有本地位址都能存取；它只表示這些流量沒有按照代理出站。若 App 仍顯示遠端地區，可能是 App 自己保存了帳號地區、快取或定位結果，不能只根據頁面文字判斷分流。

DNS 也需要單獨觀察。某些用戶端會讓 DNS 查詢統一經過 VPN，即使某個 App 被排除在 VPN 流量之外；另一些設定則會讓直連 App 使用本地 DNS。這可能造成「網頁流量直連，但網域解析結果仍像代理環境」的差異。遇到特定網域無法開啟時，應同時檢查 App 分流、DNS 模式與網域規則，不要只反覆切換節點。

觀察結果 可能原因 處理方向
代理 App 與直連 App 都看到相同出口 App 清單未套用、模式選反，或兩個 App 都沒有使用系統 VPN 重新確認允許清單與排除清單，並重建 VPN 連線
代理 App 無法連線，但其他流量正常 App 網域被直連規則命中，或該 App 不相容目前傳輸方式 查看連線記錄，分開測試網域規則與節點協定
直連 App 開啟速度變慢或無法使用本地功能 排除設定未生效，或 DNS、路由仍由 VPN 接管 檢查 Android VPN 的 App 排除設定與 DNS 模式
App 重新開啟後規則失效 省電策略暫停客戶端，或 VPN 連線在背景中斷 允許客戶端背景運作，並關閉對該客戶端的過度省電限制

常見故障與修正順序

最常見的問題是「看起來已連線，但指定 App 沒有按照規則走」。第一步應確認 Android 狀態列的 VPN 圖示與客戶端內的連線狀態一致；第二步查看 App 清單是否仍然存在，因為更新客戶端、清除資料或重新匯入設定後，部分應用程式選擇可能被重置；第三步檢查目前模式是允許清單還是排除清單，很多錯誤都源自把兩者理解反了。

如果只有某一個 App 失敗，先暫時將它從分流清單移除，再使用全域 VPN 測試。全域模式可以用來判斷問題是在 App 規則，還是在節點、協定或 App 本身。如果全域模式可以使用，允許清單模式不行，通常應從套件選擇、規則優先順序與 DNS 分流開始排查；如果全域模式也失敗，則不應繼續修改 App 清單，而要先檢查訂閱更新、節點連線與 Android 權限。

Android 的省電管理也會影響長時間分流。裝置進入休眠、切換 Wi‑Fi 與行動網路，或系統限制客戶端背景活動後，VPN 通道可能被暫停。此時可能出現前景 App 能使用、背景通知失效，或重新開啟 App 後才恢復的情況。可以在系統設定中確認客戶端的背景使用權限，並觀察連線中斷後是否自動重建。不要為了維持連線而同時安裝多個 VPN 工具，這會讓診斷更加複雜。

  • ✅ 先停止其他 VPN、代理或網路加速工具，只保留一個測試環境。
  • ✅ 更新訂閱後重新檢查節點與 App 分流清單是否仍在。
  • ✅ 先用全域模式確認節點可用，再回到允許清單或排除清單。
  • ✅ 透過連線記錄確認實際命中的 App、網域與出站。
  • ❌ 不要在 Wi‑Fi、行動網路、節點和分流模式同時變更，否則無法定位原因。
排查結論： 先確認 VPN 通道，再確認 App 是否被納入，接著查看網域與 DNS 規則，最後才評估節點或協定。依層次排查，比反覆切換線路更有效。

完成第一次設定後，建議將規則整理成「需要代理」「需要直連」「暫不判斷」三類。需要代理的清單只放確實需要指定路徑的 App；需要直連的清單放本地服務與對出口變化敏感的 App；其他應用程式先維持預設，等實際遇到問題再加入。清單越短，日後更新 Android 或重新安裝客戶端時越容易複核。

新安裝 App 後，不要直接假設它會繼承相似應用程式的規則。Android 會以獨立套件識別不同 App，即使兩個 App 屬於同一家公司，也可能需要分別加入。更新 App 後若出現登入失效、內容地區錯誤或通知異常，先檢查規則是否仍針對正確套件，再檢查帳號與 App 快取。

如果需要在多個裝置上使用相似的網路策略，Android 的 App 清單通常不能直接等同於 Windows、macOS 或 Linux 的設定。桌面用戶端可能使用進程、網域、虛擬網卡與路由表判斷；Android 則受系統 VPN 介面、應用程式套件和省電策略影響。跨平台同步時可以保留「哪些 App 需要代理」的需求清單，但仍應在每個平台重新驗證。

06VPN 支援 Windows、macOS、iOS、Android 與 Linux，訂閱可交由相容客戶端匯入。Android 使用者若希望快速開始，可先從官方或相容客戶端完成訂閱更新，再依本文流程設定 App 分流。使用過程中，請將訂閱連結視為私人設定憑證，不要公開貼出或交給不可信任的線上解析服務。