分應用代理在解決什麼問題？
在 Android 上使用 Clash／Meta／CFA（Clash for Android）系列客戶端時，許多人會長期維持「規則模式」並搭配訂閱裡成千上萬條域名規則。這樣做在一般瀏覽與影音情境通常沒問題，但只要遇到金融、身分驗證、區域鎖較死的在地 App，就可能出現 OTP 發不出去、人像辨識打不開、或 App 認定你不在「它所期待的網路環境」。此時即使你願意在 YAML 裡寫細緻規則，也常因為套件名稱、內嵌 WebView 與多行程架構而不易一次寫對。
分應用代理把工作拆成較粗的粒度：你不是去猜某個 CDN 的子網域名稱是否該 DIRECT，而是以「這一整支 App」為單位，決定它要不要進入 VPN 隧道。常見作法有兩種：一是在全域代理的前提下，把一些敏感或在地服務放進繞過名單（bypass／略過）讓它們強制直連；二是反過來，只把少數確實需要代理的 App 放進僅代理名單（allow／僅以下應用走代理），剩餘全部直連。
本文假設你已能正常匯入訂閱、開啟主開關，並大致理解規則與策略組的關係。若目前是「一開啟就連不上、節點全紅」，建議你先閱讀技術專欄內訂閱匯入與連線排查類文章把基礎網路與 DNS 站穩，再回到分應用微調會省很多來回時間。
兩種清單怎麼選：繞過 vs. 僅代理
不同分支客戶端在選單用詞會略有出入，但語意不外乎下列兩組邏輯。你可以把它們想成 XOR 問題的兩種寫法：一種是預設「通過」，再挖洞；另一種是預設「不通過」，再放行。
| 模式類型（常見中英文） | 預設行為 | 清單內 App 的行為 | 典型適用 |
|---|---|---|---|
| 繞過名單／略過／Bypass | 多數 App 仍可依規則走代理隧道 | 強制直連，規則裡對該套件通常不再生效為「進隧道」那一段 | 日常使用代理，但要讓數家銀行、電子支付維持原網路程式 |
| 僅代理名單／允許／Allow list | 其餘 App 多半直連 | 只讓這些進入 VPN／代理路徑 | 只希望瀏覽器與 Telegram、Discord、Spotify 等少數對外連線經過節點 |
需要留意：分應用層級的決策通常發生在套件（package）層級，對於會透過共用 WebView、系統元件或無痕式背景程序拉線的設計，有時光看「主 App icon」並不足夠——例如某購物 App 內建的「金融小視窗」其實是另一個子程序，便要一併納入與繞過或僅代理邏輯一致的處置，否則會出現「主畫面能刷、付款頁卡住」的假性故障。
步驟一：找到分應用代理並確認前置條件
在 Clash for Android 相容客戶端中，請先進入主設定頁（可能叫做「設定」「Setting」「進階」依版本而不同），搜尋關鍵字如「分應用」「應用程式」「Per-App」或「Bypass」。開啟前請確認你已授予Android VPN 權限，且電池優化對該客戶端設為無限制或可背景執行——否則清單剛調好，隧道卻常被系統掛起，表面上看起來會像規則沒套用。
若你的介面同時區分規則模式與全域模式，建議在多數日常使用情境仍以規則模式為基底；分應用只是再疊一層對「特定套件」的先決擋板。請避免在分不清目前策略組的情境下反覆切換模式，以免造成日誌難以解讀。你也可以把「當前使用中的設定檔名稱」記下來，確認分應用開關是否綁定在那份 Profile 之下，避免因有多份備份設定而調錯檔。
步驟二（繞過名單）：讓銀行／支付與在地服務直連
當你已習慣用規則讓對外站台走代理，但希望數位錢包、身分驗證、國稅或小額繳費等 App 百分之百貼在地網路時，請在分應用選單中切換為「繞過」型態，並依下列順序勾選：
- 所有你實際在用的電子銀行、信用卡與第三方支付，包含其附屬的「身分驗證」「OTP」「安全元件」小包名（若在清單中可辨識）。
- 區域強依賴的政府或公共設施類 App，這類程式常對 IP 異常較為敏感。
- 若你希望國內短影音／外送／叫車等完全不受代理影響，也可一併放進繞過，減少與國內 CDN 之間來回切換所造成的延遲尖峰。
完成後請強制結束 App 並重新開啟，再依序試：在繞過名單內開啟目標程式，對照路由器或 IP 探測工具應仍能看見你那條電信／家裡寬頻的出口；接著再打開未被繞過的瀏覽器造訪測試站，確認仍可使用代理線路。
步驟三（僅代理名單）：只指定少數 App 走 Clash
若你的訴求是不希望整支手機的流量都進隧道，又不想花時間維護超長規則，僅代理名單是很好的折衷：你在清單中只勾Firefox、Chrome、某個國外即時通、某個區域影音客戶端等少數對象即可。對應的流量會依你目前的規則與策略組分配節點；清單外 App 將大多維持直連或在客戶端定義為非隧道路徑，整體體驗對在地服務的干擾通常較低。
實務上建議將清單控制在「你真的需要離開本地路由」的那一撮 App，並避免把一些會大量喚醒背景網路的系統套件誤選進來；若發現電池異常耗能或通知大量重試，可回頭檢視是否過度放行。對於會使用 QUIC／UDP／WebRTC 的音訊與視訊程式，請配合技術專欄其他篇關於 RTC 類分流或 TUN／系統代理差異的文章，避免因傳輸協定繞過了你的預期路徑而誤判「代理沒開」。
步驟四：用日誌與 IP 驗證實際路徑
分應用設定最容易出現的問題不是「規則寫錯」，而是我以為它被繞過了／我以為它有走代理。請習慣用兩種方法交叉確認：
- 在支援連線紀錄的 Clash／Meta UI 裡過濾目標套件名稱或相關網域名稱，確認請求是 DIRECT 還是經過某個策略組；若顯示與預期相反，先回到清單模式是否選反（繞過與僅代理搞混最常見）。
- 對於可被操作的 App（例如瀏覽器），在只在清單內與故意移出清單兩種狀態下各開一次同樣測試頁比對公開 IP／ASN／地理區域；差異要能與你所選節點地區對得上。
若你發現繞過名單確實已勾選銀行 App，程式內建的 WebView 卻仍以代理出口打開銀網銀站台，很有可能是規則層對該網域名稱更早就送進了代理，而套件層並未覆蓋那一段行為——此時便要回到 YAML／覆寫，把對應金融網域顯式標為 DIRECT（或適當國內規則）與繞過名單雙管齐下。換句話說，分應用不是規則的替代品，而是一個降低摩擦的並行工具。
常見卡住點：雙程式、分身與工作設定檔
Android 對同一套程式使用雙開／工作設定檔／多使用者空間時，系統視為彼此獨立的套件實例或不同使用者上下文。請在分應用清單中逐一確認你實際點選的是哪個應用程式圖示對應的 App；若你只繞過了主空間的那一個分身，分身裡的電子銀行仍可能走隧道。部分廠牌 ROM 對「分身」的包名有特殊前綴或簽署，介面若不夠直白，便要搭配應用資訊畫面上的完整識別字串核對。
另一種常見情況是某些 App 內建了內網發現、mDNS或對本地閘道的探測——如果它們在僅代理模式下被強制套上代理，請求可能被導到你預期的節點地區而失去「區網視角」。遇到智慧家庭、印表機、NAS 這類問題時，往往不是節點壞掉，而是你該將該管理 App 放回直連側或調整對應 DOMAIN-SUFFIX 規則。
延伸：什麼時候反而該調規則，而不是調分應用？
分應用適合處理對整支 App 有共識的直連／代理決策；但如果你只想讓某一個國外網域走代理而其餘子網域直連，用 DOMAIN／DOMAIN-KEYWORD 粒度較準。對於強依賴 SNI／HTTP Host 的流量，請一併注意訂閱內對應區塊順序是否在較前就命中，否則你會在日誌裡看到「明明繞過了 App，仍然有某類連線跑偏」的假矛盾。
市面上不少「一鍵 VPN」或輕量化代理類 App，在 Android 新版本上對分應用、DoH、規則可視化與紀錄支援參差不齊，有些甚至只能粗粒度放行而無法同時相容 Meta 規則與 per-app 疊代；對需要長期自管訂閱、又不想把金融 App 暴露在過度複雜路徑裡的你來說，採經過社群長期維護、核心較接近官方 Meta（mihomo）路線並具備清楚的連線紀錄與分應用介面的 CFA 相容客戶端，往往能更穩地把「對外規則」與「在地 App」切開，減少反覆對照不明黑箱行為的成本。順手一提：若你希望一次取得對應平台整理了依賴與相容性說明的安裝包，請前往本站下載頁面取得更新。
把分應用當成一個對「敏感度高的 App」的保險開關，配合規則與 DNS 設計一起看，你就不需要在每次系統或小版本更新後從頭猜測哪條規則先撞線；遇到問題時，依本文順序復盤——模式對不對、清單有沒有覆蓋到正確的包名、日誌顯示的下一跳是不是符合預期——通常能比盲目重灌更快回到可用狀態。