Clash Android 分應用代理：指定 App 走代理的勾選與連通驗證
許多人並不需要「整支手機所有流量」都進隧道：只想讓通訊軟體、瀏覽器、少數工具 App走代理，其餘維持電信或 Wi‑Fi 直連；也有人反過來，希望遊戲與語音維持低延遲直連，但社交與新聞客戶端仍走代理。這類需求在工程上常稱為按應用分流或分應用代理。本篇以相容 Clash 核心的 Android 圖形客戶端為對象，整理應用程式清單勾選、與 TUN／規則（Rule）／全域（Global）模式的關係，並給出一套可重複操作的連通驗證流程，讓您確認「只有選中的 App 真的走了代理」，而不是心裡覺得有、實際上沒有。
為什麼手機更需要分應用代理
桌面環境裡，瀏覽器多半會遵守系統代理；Android 上卻常見原生 App 各自使用網路堆疊，不完全理會「系統 HTTP 代理」這種較表層的設定。若您只開傳統代理而沒有裝置級隧道，可能出現「瀏覽器正常、通訊軟體仍走直連」的錯覺。反過來，若一律開全機 VPN 式隧道，銀行 App、區域影音、遊戲反作弊或語音通話又可能變得敏感。分應用代理的價值，在於把攔截範圍縮到您願意承擔的那一群 App：降低副作用、也讓問題排查時的變因更少。
與站內其他 Android 主題的關係如下：《Clash Android 訂閱匯入失敗排查》處理的是「設定檔進不來」；《Android TV 側載與遙控》偏重大螢幕與背景保活。本篇補上圖形介面裡按應用勾選這塊高頻剛需，並與 DNS／fake-ip 類症狀區隔——若您懷疑是解析路徑問題，可併讀 《連得上卻沒網路？DNS 與 fake-ip》。
全域、規則與 TUN：先對齊名詞再勾 App
在談「應用程式清單」之前，請先把三個層次分開：模式決定「命中規則後流量往哪裡送」；TUN／VPN 權限決定「系統願不願意把封包交給客戶端」；分應用列表則是在上述前提下，再告訴核心「哪些 UID／套件名允許進入這條隧道」。少了最後一層，您以為在做分流，其實可能仍是全機進隧道；少了 TUN，則可能只剩少數遵守代理的 App 有效。
| 項目 | 您該記住的點 |
|---|---|
| Rule（規則） | 日常建議預設；域名／GEOIP 等規則決定走代理或直連。分應用代理通常與 Rule 並用，而不是互相取代。 |
| Global（全域） | 適合短測節點是否活著；長期開著容易讓「沒勾到的 App」也誤以為一切走代理出口，排查時請回到 Rule。 |
| TUN／VPN | 裝置級攔截，讓較頑固的 App 也經過 Clash；是否支援、以及與分應用清單的結合方式，依客戶端實作而定。 |
別把「分應用」當成萬用替身
若某 App 內建 DoH、私人 DNS 或獨立網路堆疊，仍可能出現「列表有勾、但解析與連線路徑與預期不一致」。此時要先關掉會繞過系統解析器的選項，再重測。
圖形客戶端：從權限到應用程式清單
各款相容 Clash 的 Android 前端，選單名稱可能叫「分應用代理」「Per-App Proxy」「繞過模式」「允許清單」等，邏輯都可收斂成兩類：僅允許清單內的 App 走代理，或清單內的 App 繞過代理改直連。下表用「白名單／黑名單」心智協助您判讀介面，實際請以您畫面上的英文或中文說明為準。
建議操作順序（通用）
- 完成訂閱匯入並確認節點可用（卡住請先走 訂閱匯入排查）。
- 授予 VPN／連線權限；若客戶端要求通知列常駐或電池白名單，一併處理，避免背景被凍結。
- 將代理模式切到
Rule，避免長期Global干擾判讀。 - 開啟分應用相關頁面，搜尋套件（例如瀏覽器、Telegram、微信），逐一套用白名單或繞過策略。
- 套用後強制停止目標 App 再重開，清除舊連線池；必要時重啟客戶端 VPN 開關。
廠牌型號的工作使用者、應用程式分身、雙開空間，在系統裡往往對應到不同的使用者 ID 或套件實例。若您只勾了主空間的圖示，分身裡的同一品牌 App 可能仍走直連。排查時請在清單裡核對顯示名稱與圖示底下的套件識別，必要時兩個都勾選後再驗證。
反向場景：遊戲直連、通訊走代理
電競或即時語音場景裡，延遲與抖動比「能不能開網頁」更關鍵。此時常見做法是：預設讓隧道覆蓋多數 App，但在分應用清單中把遊戲主程式、語音模組、或廠商商店更新程式設為繞過（Bypass），使其維持電信路徑；同時保留通訊、社群、瀏覽器在隧道內。這種反向勾選對「清單語意」要求更高——請再次確認您的客戶端是「勾選＝走代理」還是「勾選＝不走代理」，避免整晚玩錯邏輯。
實務心法
先選一個低風險 App（例如瀏覽器）做單點實驗：只勾它、其餘不勾，用下文驗證流程確認出口 IP 是否切換；成功後再批次加入通訊軟體，最後才處理遊戲繞過。
連通驗證：用證據說話，不靠感覺
「能開 YouTube」並不能嚴格證明「只有被勾選的 App 走代理」，因為您可能仍在全機隧道或規則誤命中。建議用可對照的觀測固定流程：
- 出口 IP 對照：在未開客戶端時，用系統瀏覽器查一次公網 IP；開啟分應用後，僅在被勾選的 App 內建瀏覽器或內嵌 WebView再查一次。若兩者應不同卻相同，代表分流未生效或該 WebView 未走隧道。
- 連線日誌：若客戶端提供即時連線紀錄，請同時觀察套件名／程序與命中策略。只勾選 Telegram 時，理應以 Telegram 相關連線為主出現在隧道側。
- 負向測試：刻意不要勾選某個地區銀行或支付 App，確認其仍能走原本直連路徑登入；若失敗，可能仍是全機代理或規則過寬。
- DNS 變因：Android 12 以後常見「私人 DNS」與客戶端 fake-ip 並存；症狀與分應用無關卻長得很像。請交叉閱讀 DNS 與 fake-ip 專文。
若您使用內建「規則測試」或「延遲測試」按鈕，請記得那量到的是客戶端到節點的 RTT，無法單獨證明「某一個第三方 App」已進隧道。分應用場景請仍以目標 App 實測＋日誌為主。
常見坑：背景限制、系統元件、WebView
下列情況會讓分應用「看起來設定正確、體感卻不對」：
- 電池最佳化：客戶端被休眠後，VPN 服務中斷，系統會悄悄把流量改走直連；請為客戶端解除休眠並允許背景活動。
- 省電模式與資料節省：部分廠商會限制背景網路，導致規則集或節點健康檢查異常，進而誤判節點不可用。
- 系統下載管理員、Captive Portal 登入頁：不一定出現在一般應用清單；公共 Wi‑Fi 認證頁打不開時，可暫時放寬或關閉分應用以完成入口認證。
- 內嵌瀏覽器：某些 App 的「內建網頁」與主程式分屬不同元件；若只勾主程式，內嵌頁仍可能走直連。
常見問題
勾了少數 App，為什麼感覺「全部都變慢」？
可能是 TUN 仍攔截全機，但規則層把大多數流量導向同一策略組；或您的訂閱規則本身過寬。請先回到客戶端確認分應用模式語意，再用日誌確認未勾選 App 是否仍大量命中代理。
只有 Chrome 走代理，其他 App 都不走？
常見於僅啟用本機 HTTP 代理埠而沒有裝置級隧道，或分應用清單只包含瀏覽器。請改為支援 VPN 服務的組合，並再次檢查清單範圍。
遊戲延遲變高，即使已設繞過？
遊戲可能透過共用網路庫或反作弊服務額外開連線；請在日誌中找實際連線的套件名，把相關元件一併加入繞過，或暫時關閉分應用對照基線延遲。
實務檢查清單
- 訂閱與節點已確認可用，模式為
Rule。 - 已釐清分應用清單是「白名單」還是「繞過名單」，並與目標場景一致。
- 主空間與分身／工作使用者內的同名 App 皆已核對。
- 完成 IP 與日誌雙重驗證，並做一項負向測試。
- 關閉會衝突的私人 DNS 或先改為自動，排除假陽性。
結語
分應用代理的本質，是把信任邊界畫在「套件清單」上，再用規則決定隧道內的流量如何出口。把名詞與語意對齊後，設定並不神秘；真正耗時的往往是驗證與廠商客製化系統的邊角案例。當您用日誌與 IP 對照把鏈路釘死，之後要加減 App 就只是維護清單，而不是重新猜測。