先對症狀分類：是「不吃代理」還是「碰不到本機代理埠」？
在開始下指令之前，建議先用兩句話描述你的現象。第一，同一台電腦上，Chrome 或 Edge 開啟「會顯示出口 IP」的網頁時，是否已經變成節點所在區域？若答案是肯定的，代表 Clash 的出口鏈路大致正常，問題多半落在「哪些行程會讀系統代理」以及「UWP 是否被允許連到本機的 Clash 埠」。
第二，Store 或 Xbox 的錯誤碼是「連線逾時、無法連到服務」，還是「已連線但下載極慢」？前者常與DNS、防火牆、或流量根本沒進 Clash有關；後者則可能是規則把微軟 CDN 指到較遠的節點。本文主軸放在前一類裡最常見、卻又最容易被忽略的一環：UWP 對 localhost 的預設隔離，以及用 TUN 改走較底層轉發時，與「僅系統代理」相比多了哪些變數。
若你尚未釐清 TUN 與系統代理的差異，可先閱讀Clash TUN 與系統代理對照教學，再回到本文專注在 Windows 11 的 UWP 特例，兩篇並讀會更省時間。
為什麼 UWP 常常「不吃」你以為已經開好的 Clash？
多數 Clash 圖形客戶端在 Windows 上會幫你打開系統代理，把 HTTP 或 HTTPS 流量導向本機的混合埠（常見如 7890）或 SOCKS。傳統 Win32 程式只要使用系統堆疊、或讀取 WinINet／WinHTTP 的代理設定，就會跟著走；因此你會覺得「瀏覽器沒問題，Clash 一定是好的」。
然而，透過 Microsoft Store 分發的 UWP（以及部分以沙箱模型包裝的 AppContainer 應用）在網路層有額外預設：禁止連線到本機位址（loopback）。設計初衷是避免惡意商店 App 掃描或操控你電腦上其他本機服務。副作用是：當 Clash 監聽在 127.0.0.1 時，這些應用即使理論上願意使用系統代理，也可能在嘗試連到本機代理埠的階段就被擋下，表現成「完全直連」或「連線失敗」，讓人誤以為它們無視代理設定。
另一個常見誤會是把所有「內建程式」都當成 UWP。實際上像檔案總管、部分設定小幫手與舊版元件仍可能是 Win32；是否受回環限制，要以套件識別與實測為準，而不是憑圖示猜測。
系統代理能解決什麼、解決不了什麼？
系統代理解決的是「應用程式願意問作業系統：我該走哪個 HTTP／SOCKS 代理？」這條路。對尊重系統設定的軟體而言，這是最輕量、也最不容易引發整機路由變動的做法。缺點也很明確：不讀系統代理的行程不會 magically 變乖；而讀了代理、卻被 OS 擋在 localhost 門外的 UWP，則屬於讀了也連不上的另一種情況。
因此，在 Windows 11 上若你只想靠系統代理讓 Store 這類程式走 Clash，通常要嘛讓它們能連到本機代理埠（也就是處理回環隔離），要嘛改用監聽在區網介面、或以其他方式繞過「本機位址」語意的做法——後者牽涉面較廣，實務上仍以回環豁免或 TUN 較常見。
當你開始調整規則時，請記得代理決策最後仍由 Clash 的 rules 與策略組決定；若規則把微軟更新網域指到直連，行為會與「UWP 問題」疊在一起，更難查。建議搭配YAML 規則分流教學確認命中順序，再回頭看本機回環議題。
實測步驟一：用 CheckNetIsolation 解除 localhost 回環限制
微軟內建的 CheckNetIsolation 工具可列出目前已豁免回環的 AppContainer 套件，也可把指定套件加入豁免清單。以下流程以系統管理員身分開啟「終端機」或 PowerShell 較穩妥，因為部分環境對權限較敏感。
步驟 A：確認 Clash 正在監聽本機埠。在客戶端介面確認混合埠或 HTTP 埠口號，並用瀏覽器或 curl 對本機測試一次，排除「Clash 根本沒聽在 127.0.0.1」這種低級錯誤。
步驟 B：查出目標 App 的 SID 風格套件名。最務實的方式之一，是到「設定 → 應用程式 → 已安裝的應用程式」點選該程式，選「進階選項」檢視其套件識別資訊；或使用你能信任的套件管理／診斷工具協助列出 PackageFamilyName。記錄時請逐字比對大小寫與底線，錯一個字元就不會生效。
步驟 C：列出目前豁免清單。執行 CheckNetIsolation LoopbackExempt -s，觀察是否已有其他套件被加入。若清單很長，代表機器過去可能跑過一鍵腳本；仍建議你確認目標套件是否真的在列。
步驟 D：新增豁免。使用 CheckNetIsolation LoopbackExempt -a -n="<PackageFamilyName>" 將指定 UWP 加入允許連線到本機的清單。完成後完全關閉該 App 再重開，必要時登出／重開機一次，避免行程快取舊行為。
步驟 E：驗證。再次開啟 Store 或 Xbox，觀察下載、登入或連線是否已改由 Clash 日誌出現對應連線。若仍無紀錄，請往下進入 TUN 與規則排查，而不是反覆重打同一行指令。
安全提醒：回環豁免等於放寬該套件對本機服務的連線能力，請只加你信任的套件，並在測試結束後視需求用 -d 移除不再需要的項目，維持最小權限習慣。
實測步驟二：改以 TUN 承載流量並檢查「有沒有進 Clash」
當你發現豁免清單已加、但特定程式仍不穩，或你希望不必逐一套件豁免，可以改評估 TUN 模式：透過虛擬網卡在較底層把符合條件的 IP 流量導入 Clash，再依規則分流。對許多不讀系統代理的程式，這條路往往比反覆調整 WinHTTP 更直接；缺點是設定錯誤時較容易出現整機無網，因此要搭配 DNS 與路由一併理解。
建議實測順序如下。第一，在客戶端先確認 Wintun 或等效驅動就緒，並以管理員權限允許建立介面。第二，暫時關閉其他整機 VPN 或第二套代理，避免雙重預設路由。第三，開啟 TUN 後，用「會顯示 IP 的網頁」與 Store 各測一次，同時觀察 Clash 連線紀錄：若網頁與 Store 的目標網域開始出現在日誌中，代表流量已進核心，剩下是規則命中到哪個策略組的問題。
第四，若 TUN 開啟後整機斷線，請先回到TUN 教學中的「整機上不了網」一節，依序檢查 DNS、fake-ip、與路由，不要同時改十個參數。第五，當 Store 類流量命中 DIRECT 或國內策略時，行為會像「沒代理」，這時應調整規則或策略組，而不是誤判 TUN 沒開。
實務上，許多使用者會長期同時開啟系統代理與 TUN：前者照顧瀏覽器與開發工具，後者補上不吃系統代理或需要透明轉發的程式。重點是理解兩者各自解決的痛點不同，本文的 UWP 回環問題剛好落在兩者交界，因此兩種手段都應會用、會查證。
仍異常時：別忘了 DNS、IPv6 與防火牆
並非所有 Store 連線問題都源於回環。當你已豁免套件、也開了 TUN，仍出現大量逾時，請再檢查三件事。第一，DNS：Clash 在 fake-ip 模式下若上游 DNS 或 fake-ip-filter 設定不當，可能出現「解析看起來成功、實際連線卻去錯地方」的現象；可對照DNS 模式排查文交叉驗證。
第二，IPv6：若系統或路由器優先走 IPv6，而你的規則或節點對 IPv6 支援不完整，少數微軟服務會表現成間歇性失敗。可在測試階段暫時關閉未使用的 IPv6 介面做對照，確認是否為雙堆疊造成的路徑分裂。
第三，防火牆與第三方過濾軟體：新建立的虛擬網卡偶爾會被問是否允許通訊；若拒絕，會出現「只有瀏覽器正常」的假性復原。請在 Windows 安全性中心檢視「允許的應用程式」，確認你的 Clash 客戶端在私人／公用網路下的勾選符合實際使用情境。
建議決策流程（濃縮版）
把上文收斂成一條可執行的判斷鏈：先確認瀏覽器走代理無誤；若僅 UWP 異常，優先懷疑 localhost 回環隔離，用 CheckNetIsolation 查與加豁免；若你希望整體覆蓋面更大、或豁免管理太麻煩，再啟用 TUN 並用連線日誌確認流量是否進核心；最後才動大規模規則改寫。每往下一層，變因越多，越應該用日誌與單因次實驗縮小範圍。
這套順序的好處是：即使你最後選擇長期只用 TUN，你也已理解「為什麼當初只開系統代理時 Store 像死掉一樣」，未來遇到類似症狀不必從零開始撞牆。
寫在最後
Windows 11 桌面上的 Clash 使用者，最常卡住的並不是「不會匯入訂閱」，而是同一套設定在不同行程上生效方式不同：瀏覽器讀系統代理、UWP 可能被 AppContainer 擋在本機埠之外、TUN 則改寫承載方式但帶來 DNS 與路由責任。把這幾條線分開看，排查會快很多。
相較自行拼湊核心、驅動與腳本，整合度高的 Clash 客戶端通常已把系統代理開關、TUN 與日誌檢視放在同一個介面，對需要兼顧商店應用與日常瀏覽的一般使用者友善許多。若你希望少花時間在環境折騰、多把精力放在規則與節點品質，可以從本站提供的安裝包開始：
若你想深入策略組與 Rule Providers，可繼續閱讀YAML 規則分流教學；需要開源授權、上游專案或回報問題時，也可在獨立段落查閱各客戶端官方說明，與本站下載入口分開理解即可。更多主題歡迎瀏覽技術專欄首頁。