在 Android 上使用 VPN 時，並不是所有應用程式都需要經過同一條代理通道。影片、瀏覽器、AI 工具或通訊軟體可能需要代理連線，但銀行 App、公司內網、智慧家居控制程式或本地影音服務，反而適合維持一般網路。Android VPN 分流的核心，就是透過應用程式清單或規則，指定哪些 App 使用 VPN，哪些 App 直接連線。

「指定 App 代理」看似只是勾選幾個程式，實際上還會受到用戶端模式、Android VPNService 權限、TUN 虛擬網卡、DNS 設定與系統省電策略影響。不同用戶端的名稱可能是「分應用代理」、「按 App 分流」、「繞過選定的 App」或「僅代理選定 App」。開始之前，先確認自己使用的是哪一種模式，不要只看到「分流」就直接套用設定。

Android VPN 分流的運作原理

Android 的 VPN 用戶端通常透過系統提供的 VPNService 建立虛擬通道。當 VPN 連線啟用後，用戶端可以接收裝置上的部分或全部網路封包，再根據應用程式、網域、IP 位址或預設策略決定要送往代理節點，還是交回一般網路。這個過程不等於每個 App 都有獨立的 VPN 連線，而是由同一個 VPN 服務在本機進行流量判斷。

如果用戶端只提供系統代理模式，通常只能影響遵守 Android 系統代理設定的應用程式；有些遊戲、串流 App、背景服務或自行建立網路連線的程式可能不會套用。TUN 模式則會建立較完整的虛擬網卡，能處理更多不使用 HTTP 代理的流量，但也需要用戶端正確處理 DNS、IPv6、UDP 與應用程式識別。

Android 的 App 分流一般透過套件名稱辨識程式，而不是隻看桌面上顯示的名稱。同一家公司可能同時安裝正式版、測試版、精簡版或工作設定檔版本，它們的套件識別可能不同。因此，清單中出現多個相似名稱時，應先開啟目標 App 確認版本，再逐一測試，不要一次勾選所有看起來相同的項目。

App

按應用程式指定哪些流量進入或排除 VPN，適合管理瀏覽器、遊戲與通訊工具。

TUN

透過虛擬網卡接收更多類型的連線，適合需要處理非 HTTP 請求的情境。

DNS

名稱解析也會影響分流結果，避免 App 已指定代理但網域仍由錯誤路徑解析。

另外，分流只決定流量走哪一條路，不會自動修復節點失效、訂閱過期或 App 本身的登入問題。若所有 App 都無法連線，應先檢查節點與協定；若只有單一 App 異常，才進一步查看套件選擇、DNS 或該 App 的獨立網路設定。

先選對用戶端與工作模式

若服務提供 Android 官方客戶端，通常最適合先使用官方版本。登入後匯入訂閱，讓用戶端取得節點與服務端規則，再從設定中尋找分應用代理功能。官方客戶端的優點是操作步驟較少，Android 權限提示也通常較容易對應；缺點是可自訂的網域規則、DNS 策略和例外條件可能比較有限。

Clash Verge 主要是桌面端用戶端，Android 使用者不應把 Windows 或 macOS 的操作畫面直接套到手機上。Android 上常見的是支援 Clash 設定格式的行動用戶端，實際功能取決於該 App 是否支援 TUN、應用程式清單與規則覆寫。sing-box Android 則通常可使用 TUN 與規則路由，適合需要精細控制的人，但設定檔結構、DNS 分流和路由規則較複雜。Shadowrocket 主要是 iOS 用戶端，不能當作 Android 的操作方案。

協定也會影響可用功能。Shadowsocks、VMess、Trojan、Hysteria2 與 WireGuard 都可能由不同用戶端接收，但支援範圍、UDP 處理、TUN 行為和 DNS 整合不一定相同。不要因為訂閱中看得到某個協定，就預設所有 Android 用戶端都能完整載入其參數。若匯入後節點名稱出現但無法連線，應檢查用戶端版本與該協定是否真的受支援。

判斷重點：想快速完成指定 App 代理，先使用支援應用程式分流的 Android 用戶端；若只開啟系統代理而沒有 TUN，部分 App 可能完全不會套用設定。

指定 App 代理的實際設定流程

以下流程適用於多數具備 App 分流功能的 Android 用戶端，按鈕名稱可能因版本或語言不同而略有差異。第一次設定時，建議只選一個容易測試的 App，確認方向正確後再逐步增加清單。一次加入大量程式，出了問題就很難判斷是哪一個例外規則造成影響。

匯入訂閱並啟用 VPN 權限

先在官方用戶端或相容用戶端中貼上完整訂閱連結。訂閱連結是設定來源，不是一般網頁；不要把它貼進瀏覽器後，看到文字或下載內容就判定匯入失敗。完成匯入後執行更新，確認節點清單、協定名稱與設定檔狀態正常。若使用的是本機設定檔，也要確認設定檔中包含對應的節點與路由內容。

接著選擇一個節點，按下連線。Android 通常會跳出「允許此連線要求」或類似的 VPN 權限提示，必須同意後，系統狀態列才會出現 VPN 圖示。若手機啟用了「永遠開啟 VPN」或「未使用 VPN 時封鎖連線」，測試期間要特別留意這些系統選項，因為它們可能讓被排除的 App 也無法正常直連。

選擇要代理或排除的 App

在用戶端設定中開啟「分流」、「分應用代理」或「App 管理」。先確認模式方向，再搜尋目標 App。以「僅代理選定 App」為例，勾選瀏覽器後，只有該瀏覽器的流量應進入 VPN；以「繞過選定 App」為例，勾選銀行 App，則是讓銀行 App 走一般網路，其餘符合規則的流量仍可使用 VPN。

如果清單提供「包含系統 App」、「排除系統 App」或「允許區域網路」等選項，第一次設定可先保持預設，避免同時改動太多變數。需要存取家中印表機、路由器管理頁面或區域網路儲存裝置時，再檢查是否有「繞過區域網路」或「允許區域網路連線」的開關。這些名稱相近的選項，處理的是區域網路路由，不一定等同於 App 分流。

套用設定並重新建立連線

儲存 App 清單後，先停止 VPN，再重新連線。有些用戶端會在切換分流模式時自動重建 TUN，但有些版本只在下一次連線時套用新規則。若 App 在切換前已建立長連線，重新啟動 App 也很重要，否則舊連線可能仍保留原本的路由結果。

完成後不要立即加入更多規則。先記錄目前的模式、節點、DNS 選項與目標 App，然後分別測試「被代理的 App」和「被排除的 App」。這樣即使結果不符合預期，也能快速回到上一個可工作的設定。

如何測試分流是否真的生效

測試分流不能只看 Android 狀態列的 VPN 圖示。圖示只代表 VPNService 已建立，不代表每一個 App 都按照預期走代理。較可靠的方法是準備兩類測試：一個明確被指定使用 VPN 的 App，另一個明確被排除或設定為直連的 App，分別查看它們的網路結果。

先在瀏覽器中開啟網路檢測頁，記錄目前的公開出口位址與地區資訊，再關閉或切換分流設定。被代理的 App 應呈現與 VPN 節點相符的出口；被排除的 App 則應使用一般網路出口。若兩者顯示完全相同，可能是 App 沒有被正確選取、用戶端只使用系統代理、TUN 沒有啟用，或該檢測請求其實由另一個背景服務完成。

接著測試實際功能，而不是隻測試首頁。瀏覽器可以開啟指定網站，不代表影片播放、圖片載入、檔案下載或帳戶登入都沒有問題；遊戲則要觀察登入、配對與遊戲內連線；通訊軟體還要測試前景與背景訊息。對於被排除的 App，可以測試本地服務、公司系統或一般網站，確認直連規則沒有被「全域代理」覆蓋。

測試對象 預期結果 若結果不符，優先檢查
指定代理的 App 透過 VPN 節點建立連線 App 是否選對、TUN 是否啟用、節點是否正常
指定排除的 App 維持一般網路或本地出口 是否誤用全域模式、排除方向是否設定相反
區域網路服務 可依設定存取路由器、印表機或內網 允許區域網路、DNS 與本地路由例外
背景通知 切換網路後仍能正常恢復 Android 省電限制、背景資料與 App 自啟動權限

若用戶端支援連線日誌，可以在測試時查看目標網域是否被規則命中，以及封包最後使用哪個出站。日誌中的網域解析、規則匹配和出站名稱比單純查看節點名稱更有參考價值。請注意不要把包含帳戶資訊、訂閱內容或完整網域請求的日誌公開分享。

測試結論：至少同時驗證一個應走 VPN 的 App 與一個應直連的 App，再檢查公開出口、實際功能和背景連線；只有看到 VPN 圖示，不能證明分流已正確完成。

常見故障與排查順序

指定的 App 沒有經過 VPN

先確認 App 是否選錯版本，尤其是工作設定檔、複製 App 或測試版。接著確認目前不是「繞過選定 App」模式，也沒有被更高優先級的規則覆蓋。如果用戶端使用系統代理而非 TUN，該 App 可能不讀取系統代理；此時可在用戶端中改用支援的 TUN 模式，或接受該 App 無法套用分流的限制。

有些 App 會把主要功能拆成前景程式、背景服務與獨立 WebView。你勾選的主程式可能能連線，但登入頁、推播服務或檔案下載仍由其他套件負責。遇到這類情況，不要立刻把整支手機改成全域代理，應先查看用戶端清單中是否有相關系統元件，並逐項測試。

排除的 App 反而無法連線

排除 App 不代表它一定能使用所有本地網路。Android 的私人 DNS、家長控制、企業管理設定、始終開啟 VPN，以及「封鎖未使用 VPN 的連線」都可能阻止直連流量。先暫時關閉封鎖未經 VPN 的選項，再確認一般網路是否恢復。若恢復正常，代表問題在系統強制路由，而不是 App 清單本身。

DNS 也是常見原因。App 可能已經直連，但網域解析仍交給 VPN 內的 DNS；也可能代理流量使用本地解析，造成地區或連線結果不一致。若用戶端提供 DNS 分流，先使用清楚且單一的設定測試，避免同時疊加私人 DNS、用戶端 DNS 和其他網路工具。

鎖定螢幕後規則失效

Android 省電策略可能限制 VPN 用戶端在背景執行，導致 TUN 停止、訂閱無法更新，或 App 在解鎖後才重新連線。可到系統的電池設定中，將用戶端從嚴格省電名單移除；同時確認背景資料、自動啟動和通知權限。不同品牌的 Android 介面名稱不一樣，重點是允許用戶端在背景維持 VPN 服務，而不是照抄某個品牌的選單路徑。

建立可維護的Android 分流規則

分流規則最重要的不是越多越好，而是能夠理解、測試和回復。建議先按照「需要代理」、「必須直連」和「暫時觀察」三類整理 App。需要代理的可以先放入瀏覽器、特定工作工具或確實需要該出口的程式；必須直連的則包括本地服務、公司指定網路或不適合經過代理的金融工具；尚未確定的 App 保持預設，等實際遇到問題再加入。

不要只依照 App 名稱建立規則。記錄套件版本、使用模式、DNS 選項與測試結果，日後更新 App 或重新匯入設定時，才知道問題是來自版本變更還是規則方向。若用戶端支援本機覆寫，長期自訂規則應放在覆寫區，而不是直接修改會被訂閱更新覆蓋的遠端設定。

使用 TUN 時，規則順序尤其重要。一般情況下，較明確的 App 或網域規則應先於較寬泛的全域規則；否則即使已經指定某個 App，後面的全域出站仍可能接管流量。不同用戶端採用的規則語法不完全相同，Clash 格式、sing-box JSON 設定和官方客戶端的 App 清單不能直接互換。匯入外部設定前，先確認格式、欄位與用戶端版本。

最後，為規則保留一個簡單的回復方案：記住原本的全域、規則或分應用模式，必要時匯出本機設定，並準備停止 VPN 後的普通網路測試。當某個 App 在更新後突然無法連線，先回復到最小規則集，再逐項加回設定，通常比盲目更換節點或重裝所有程式更快定位問題。

一句話總結：Android 指定 App 代理的正確順序是先確認用戶端與模式，再匯入設定、選擇 App、重建 VPN，最後用代理與直連兩類 App 對照測試；規則越清楚，日後排錯就越簡單。