Microsoft Store 與 UWP 不走 Clash？回環豁免與 TUN 修復步驟
許多使用者在 Windows 上已為 Clash（或內建 Mihomo／Meta 核心的圖形客戶端）開啟系統代理，瀏覽器與傳統 Win32 程式都能分流，卻發現 Microsoft Store 仍顯示離線、無法更新，或特定 UWP（通用 Windows 平台）App 始終直連。這通常不是訂閱壞了，而是回環（loopback）網路隔離：沙箱化的 App 預設不能連到本機監聽的代理埠。本篇整理兩條實務路徑——以 CheckNetIsolation 做回環豁免，或改啟 TUN 模式讓流量在核心層被承接——並說明與 規則模式、DNS 對齊時的注意事項。
現象：為什麼「明明已開代理」，商店卻像沒開
Windows 的系統代理設定主要影響會讀取「網際網路選項」或相關 API 的程式。許多桌面軟體與 Chromium 系瀏覽器行為符合直覺；但 Microsoft Store、小算盤的線上功能、部分 Xbox 相關元件、以及多數從商店安裝的 UWP，跑在AppContainer 隔離模型底下，對連回本機位址（127.0.0.1 或本機主機名對應的 loopback）有額外限制。Clash 若監聽在本機 HTTP／SOCKS 埠，UWP 的連線請求可能在還沒進入規則引擎前就被平台擋下或改走預設路徑，外觀就像「完全不吃代理」。
另一種容易混淆的情況，是商店其實已嘗試連線，但 DNS 或 fake-ip 與微軟 CDN、授權端點預期不一致，導致頁面空白或錯誤碼。若您已確認非 UWP 的程式在相同節點下正常，優先懷疑回環隔離；若連 Edge 都異常，請一併參考 DNS 與 fake-ip 排查專文。
- 典型徵兆：Store 顯示離線、下載卡住、UWP 登入微軟帳號失敗，而 Chrome／Firefox 正常。
- 客戶端狀態：Clash 日誌幾乎看不到對應連線，或僅有間歇性條目。
- 模式：無論
Rule或Global，只要仍依賴「本機代理埠 + 系統代理」，問題可能依舊。
回環隔離在工程上代表什麼
簡化地說，UWP 被設計成預設不信任本機其他處理序提供的網路端點，以降低惡意本機服務竊聽或注入的風險。當 Clash 在本機開埠，流量若要「先進 Clash 再出去」，UWP 必須被允許與該本機埠通訊——這就是所謂的 loopback exemption（回環豁免）。若不做這一步，部分 App 會改以為無代理環境，直接對外連線，於是您觀察到「規則寫了微軟域名走代理，Store 卻仍像直連」的錯位感。
與 TUN 的關係
系統代理仰賴應用程式願意把流量送到本機埠；TUN 則在更底層把封包導向虛擬介面，由 Clash 接手。對「頑固」的 UWP，TUN 往往比反覆加豁免名單更省事，但需安裝驅動、處理與其他 VPN 的互斥。
路徑 A：以 CheckNetIsolation 做回環豁免
此路徑保留「僅系統代理、不開 TUN」的配置，適合暫時不想動虛擬介面、或與其他網路篩選驅動有相容性顧慮的使用者。核心工具是系統內建的 CheckNetIsolation.exe（需系統管理員權限的命令提示字元或 PowerShell）。
步驟 1：查出套件親屬名稱（Package Family Name）
以 PowerShell 為例，先縮小目標套件：
# Example: list Store-related packages (run in elevated PowerShell)
Get-AppxPackage *WindowsStore* | Select-Object Name, PackageFamilyName記下要豁免的 PackageFamilyName（格式類似 Microsoft.WindowsStore_8wekyb3d8bbwe，後綴隨版本可能略有差異，以您機器輸出為準）。其他 UWP 可將萬用字元改成 App 名稱關鍵字。
步驟 2：加入回環豁免
# Replace with your PackageFamilyName from Get-AppxPackage
CheckNetIsolation LoopbackExempt -a -n="Microsoft.WindowsStore_8wekyb3d8bbwe"參數 -a 表示新增（add）。完成後重新開啟 Microsoft Store 測試下載與登入。若同一問題出現在另一個 UWP，對該套件的親屬名稱重複執行一次即可。
步驟 3：需要還原時
CheckNetIsolation LoopbackExempt -d -n="Microsoft.WindowsStore_8wekyb3d8bbwe"-d 為刪除（delete）。若您不確定曾加過哪些項目，可先查官方文件或使用說明中的列表參數（不同 Windows 版本顯示方式可能略有差異），避免誤刪其他套件條目。
安全與權限
回環豁免會放寬該 UWP 對本機網路端點的存取，請只對您信任的套件操作，並在完成測試後保留最小豁免集合。企業環境若有裝置管理政策，可能限制此類變更。
完成豁免後，請回到 Clash 確認系統代理已指向正確的本機埠、且客戶端仍處於您預期的模式（通常為 Rule）。若您才剛安裝 Clash，建議先對照 Clash for Windows 安裝與基礎設定 完成訂閱與啟用流程，再回來做 UWP 微調。
路徑 B：改走 TUN，為何常能一次解決
TUN 模式會建立虛擬網路介面，作業系統將符合條件的 IP 流量路由給 Clash，由核心依規則決定 DIRECT 或 PROXY。對 UWP 而言，這條路徑不再依賴「應用程式是否願意連 127.0.0.1」，因此許多商店與沙箱 App 會突然「變得遵守規則」。缺點是您必須處理驅動安裝、與其他虛擬網卡／安全軟體的相容性，以及少數反作弊或企業程式對 TUN 的排斥。
實務上，若您已在玩遊戲分流、語音最佳化，很可能早已啟用 TUN；此時 Store 仍異常，就要往 DNS、規則順序、MATCH 與微軟相關域名是否被誤判為直連等方向查。相對地，若您堅持只用系統代理，則路徑 A 的回環豁免幾乎是必做功課。
TUN 啟用與規則對齊（實務檢查）
- 在圖形客戶端以系統管理員身分啟動（若客戶端要求），開啟 TUN／虛擬介面選項，並確認無黃色錯誤提示。
- 模式維持
Rule，檢查微軟更新、Store、帳戶登入相關域名是否在訂閱規則中命中預期策略組（常見為「國外服務」或您自訂的 PROXY 組）。 - 開啟 Clash 連線日誌，於 Store 內重新整理或下載小 App，觀察是否有對應流程與策略命中；若完全無日誌，表示封包仍未進核心，回到 TUN 驅動與路由表。
- 若出現連得上但頁面異常，交叉測試 DNS：可暫時對照 fake-ip 與 nameserver 設定，一次只改一個變因。
需要同時讓 WSL2、Docker 桌面版與本機瀏覽器共用 Clash 時，路由與 localhost 行為會更複雜；此時可延伸閱讀 WSL2 與 Windows 上的 Clash 連通專文，避免把 UWP 問題與子系統網路混為一談。
兩條路徑如何選
| 方式 | 優點 | 取捨 |
|---|---|---|
| 回環豁免 | 不改路由表習慣、與純系統代理心智一致 | 需維護套件清單；新裝 UWP 可能要補登記 |
| TUN | 對 UWP／不讀系統代理的程式覆蓋面廣 | 驅動與相容性成本；與其他 VPN 可能互斥 |
若曾遇「關閉 Clash 後全機無網路」
這與 UWP 回環是不同維度的問題，但常在同一台工作機上先後遇到：系統代理或 PAC 未還原時，會讓使用者誤以為「商店壞了」。若您有類似經驗，請保留 Clash 退出後恢復系統代理 的操作筆記，遇到更新 Windows 或客戶端當機時可快速排除。
常見問題
豁免後仍無效？
請確認 Clash 實際監聽位址是否為本機（127.0.0.1）且與系統代理設定一致；若客戶端僅監聽區網 IP，UWP 與系統代理路徑可能仍對不上。另查是否有多個代理軟體競爭修改系統設定。
TUN 已開，Store 仍錯誤碼？
優先檢查規則是否將微軟 CDN 或帳戶端點誤判為直連，並檢視 DNS 解析是否被攔截。可短暫以日誌中顯示的域名加一條測試規則驗證。
回環豁免會不會不安全？
它放寬的是「該套件與本機服務通訊」的邊界，風險與您本機執行的服務可信度相關。僅豁免必要套件，並定期檢視列表。
實務檢查清單
- 確認現象僅限 UWP／Store，其他程式正常。
- 以管理員身分執行 CheckNetIsolation，核對 PackageFamilyName 後新增豁免。
- 或啟用 TUN，確認驅動無報錯並在日誌看到 Store 連線。
- 複查規則與 DNS／fake-ip，排除誤直連或解析失敗。
- 記錄關閉 Clash 時的系統代理還原方式，避免二次災情。
下一步
釐清 UWP 的 loopback 限制之後，Windows 上的 Clash 設定會變得可預期：要么精準豁免，要么用 TUN 承接流量。當兩條路徑與規則、DNS 對齊，Microsoft Store 與多數商店應用程式就能與瀏覽器共用同一套分流邏輯。