Windows 11 上 UWP 與商店應用不走 Clash？用環回豁免核對系統代理與分流

先分清兩種「不走代理」

第一種是根本沒碰到 Clash 監聽埠：系統代理對許多 Win32 程式有效，但 UWP 容器內的網路堆疊預設禁止連向 127.0.0.1 上的本機服務，於是你的 Clash 即使開著 系統代理，應用也連不上本機 mixed／HTTP 埠，表現就像「完全沒走代理」。第二種是已經進 Clash，卻被規則或 DNS 送走：連線紀錄裡看得到處理序或目標網域，但命中了直連、錯誤的策略組，或解析路徑與規則不一致。本文前半處理第一種；若環回已放行仍異常，再依後半段核對分流與解析。

為什麼 UWP 與商店應用對「系統代理」特別挑剔

傳統桌面程式常透過 WinINet／WinHTTP 讀取使用者或電腦層級的代理設定；而許多商店分發的應用跑在 AppContainer 裡，出於安全模型，預設禁止向本機環回建立連線。Clash 類客戶端在「僅系統代理」模式下，通常是在本機回環位址上監聽埠，再把流量轉送到上游節點——這與 UWP 的預設限制正好衝突。於是你會看到強烈對比：Microsoft Store 裡應用更新失敗，而同一台機器上的 Win32 瀏覽器存取外網完全正常。理解這一點後，除錯目標就從「換一顆更快的節點」變成「讓目標應用能合法連到本機代理埠」，再搭配規則細調。

第一步：確認 Clash 的「系統代理」埠與開關

開啟你正在使用的客戶端（例如 Clash Verge 系列），確認系統代理已開啟，並記下 HTTP／SOCKS 或 mixed 埠號是否與 Windows 設定裡一致。可在「設定」→「網路和網際網路」→「Proxy」查看手動 Proxy 位址是否為 127.0.0.1 加上對應埠。若你剛重灌或切換過核心，偶爾會出現介面顯示已開、系統設定卻未寫入的情況，此時應先回到首次安裝與系統代理排查那篇文章的順序，把「代理寫入系統」這一步做實，再談 UWP。否則後面做再多 Loopback 豁免也是連錯埠。

第二步：用連線紀錄判斷流量有沒有進 Clash

在重現問題的同時開啟 Clash 的連線紀錄或即時連線面板。若點選商店下載、登入 Xbox 帳號時完全沒有新連線，優先懷疑環回隔離或應用未使用系統代理；若紀錄裡已出現相關網域，但延遲極高或交握失敗，再轉向節點品質、TLS 攔截、DNS 與分流順序。不要把兩類問題混在同一輪修改裡，否則會在「加規則」和「換節點」之間空轉。若你需要處理序層級接管，也可對照TUN 模式深度解析評估是否改以 TUN 統一接管，但 TUN 牽涉驅動與路由優先順序，仍建議先完成本機代理路徑的確認。

第三步：CheckNetIsolation 與環回豁免（LoopbackExempt）

微軟提供 CheckNetIsolation 工具用於診斷與設定網路隔離。要對某個應用套件放行本機環回，需要它的套件系列名稱（Package Family Name，PFN）。在具系統管理員權限的 PowerShell 中，可用 Get-AppxPackage 查詢，例如商店常見套件名稱以 Microsoft.WindowsStore 開頭，其 PackageFamilyName 欄位即後續指令需要的值。放行範例（請把 PFN 換成你機器上查到的真實字串）：

# Run in elevated PowerShell; replace PFN with your PackageFamilyName from Get-AppxPackage
CheckNetIsolation.exe LoopbackExempt -a -n="Microsoft.WindowsStore_8wekyb3d8bbwe"

-a 表示加入豁免清單。若不確定 PFN，可先對特定應用執行 Get-AppxPackage *關鍵字* 縮小範圍。對 Xbox、Game Bar、剪取工具等系統元件，同理查到 PFN 後分別加入。可用 CheckNetIsolation.exe LoopbackExempt -c 清空清單（請謹慎使用），或 -d 刪除單筆豁免。操作完成後請完全結束並重新啟動目標 UWP 應用再測，避免舊處理序快取網路堆疊狀態。

批次放行與「全家桶式」豁免的取捨

社群中偶見一次豁免大量 UWP 的指令稿，短期能省事，但從攻擊面來看，等於放寬一批應用對本機服務的存取邊界。較穩健的做法是：只為確實需要走本機代理且你信任其廠商的套件加入豁免；其餘維持預設隔離。若你同時執行公司 VPN、其他「加速器」或封包分析工具，也要避免它們與 Clash 爭奪同一環回埠或重複改寫系統代理，否則紀錄裡會出現間歇性「有時進有時不進」的假陽性。

第四步：若紀錄已出現連線，核對分流與規則順序

當 Microsoft Store 或 Xbox 相關流量已經進入 Clash，卻仍提示區域不可用或下載失敗，需區分「平台商業限制」與「網路路徑問題」。網路路徑側請檢查：相關網域是否被過寬的 GEOIP,CN,DIRECT 提前命中；是否有應走代理的 CDN 網域被誤直連；以及 MATCH 兜底是否把未知流量送到錯誤策略組。具體寫法可參考自訂規則教學：讓指定 App 走指定節點，記住較精確的 DOMAIN 規則應排在過寬規則之前，並結合連線紀錄增量維護，而不是一次匯入巨型規則集。

第五步：DNS、fake-ip 與「看起來像沒代理」的錯覺

部分商店介面在 DNS 階段就會因污染或錯誤解析落到不可達位址，表現為秒失敗，容易誤判為「沒走 Clash」。建議在問題時間窗內固定使用 Clash 內建 DNS 或你明確理解的 DoH 設定，避免系統 DNS、路由器 DNS 與 Clash DNS 混用導致解析與規則脫節。若啟用 fake-ip，要同時理解哪些規則需要 no-resolve、以及客戶端是否會快取舊解析結果。整體思路與Docker Desktop 與 Win11 主機代理、DNS 對齊一文強調的「同一時刻只保留一條清晰的解析路徑」一致，只是本文面向的是 UWP 側環回與系統代理。

TUN 模式是否是「銀彈」

TUN 透過虛擬網路卡把流量導入 Clash，往往能繞過「應用不讀系統代理」或部分沙箱限制，但並非沒有代價：驅動簽章、路由優先順序、與公司 VPN 衝突，以及遊戲反作弊對虛擬網路卡的敏感等，都是需要納入評估的變數。若你僅在少數 UWP 上遇到麻煩，優先用 Loopback 豁免通常較輕量；若整機多類應用都有接管困難，再閱讀TUN 模式權衡是否切換。切忌在未讀紀錄的情況下同時開啟系統代理與多個 TUN 類軟體，否則除錯難度會指數級上升。

與 WSL、Docker 情境的邊界

WSL2 與 Windows 共用 Clash 討論的是虛擬網路卡與 localhost 轉送；Docker Desktop 討論的是引擎獨立網路堆疊。UWP 環回問題與上述情境機制不同，但以紀錄驅動的排查方法相同：先看連線是否進入 Clash，再分層處理。把三類筆記分開保存，日後遇到「只有某一個容器／子系統不正常」時能快速定位，而不是每次都從零重裝客戶端。

建議排查順序（檢查表）

1. 確認 Clash 正在執行，系統代理埠與 Windows 設定一致。
2. 重現問題時觀察連線紀錄：無連線則優先處理 Loopback 豁免。
3. 以 Get-AppxPackage 取得 PFN，CheckNetIsolation.exe LoopbackExempt -a -n="..." 加入後重啟應用。
4. 若紀錄已有連線，檢查分流命中順序、GEOIP 與兜底策略。
5. 對齊 DNS 與 fake-ip 行為，一次只改一類變因。
6. 仍複雜時再評估 TUN 或排除多代理衝突。

常見問題

小結

Windows 11 上 UWP 與 Microsoft Store 類應用「看起來不走 Clash」，很多時候是環回隔離擋住了對本機代理埠的存取，而不是訂閱失效。以 CheckNetIsolation 做 Loopback 豁免後，再依連線紀錄核對系統代理、分流與 DNS，就能把多數「只有商店不正常」的案例收斂到可重現的幾步操作裡。與只談安裝或區網放行的文章相比，本文補齊了桌面代理在 WinRT 應用上的常見盲區；對以 Google 搜尋為主的台港使用者而言，把「Loopback」「CheckNetIsolation」與「系統代理」寫進同一篇，也有助於之後用關鍵字找回這份檢查清單。

相較在論壇貼文裡碎片化試錯，使用維護積極的客戶端、從本站下載頁取得安裝檔並搭配使用教學建立固定除錯順序，長期成本更低。規則型代理在可觀測性與分流精度上仍具優勢；當你需要讓系統元件與商店應用穩定走出口時，先把環回豁免與系統代理對齊，再談節點與規則細節，會少踩很多冤枉路。→ 立即免費下載 Clash，開啟流暢上網新體驗。