Windows Microsoft Store 應用無法使用代理？UWP 回環豁免設定與 CheckNetIsolation 指南

先判斷：是回環存取受限，還是應用未使用代理

瀏覽器能透過 Clash 用戶端連上網路，但某個 Windows 商店應用一直載入，不代表訂閱失效。如果用戶端在 127.0.0.1 監聽 HTTP 或混合代理連接埠，而目標應用是在受限的 AppContainer 中執行，應用可能無法連上這個本機入口。遇到這種情況，可以檢查是否需要設定 UWP 回環豁免。

不過，Microsoft Store 是應用程式的發佈管道，不是執行環境。商店中的傳統 Win32 軟體、封裝桌面應用程式和 UWP 應用，網路限制並不完全相同。只有確認問題涉及 AppContainer 的回環限制，設定豁免才有針對性；不能單憑「從商店安裝」就認定「一定要新增豁免」。

UWP、AppContainer 與 127.0.0.1 的關係

127.0.0.1 是 IPv4 回環位址，連線不會傳送到區域網路中的其他電腦。Clash 系列圖形用戶端通常會在本機啟動核心，再透過 HTTP、SOCKS 或混合連接埠接收應用程式的請求。Windows 系統代理則會告訴遵循此設定的應用：將請求交給這個本機入口。

AppContainer 是 Windows 的應用程式隔離機制，會依應用程式身分與能力限制資源存取，其中也包含網路存取範圍。即使代理服務與應用程式在同一台電腦上執行，受限的容器也不一定能連上代理服務。CheckNetIsolation.exe 提供的 LoopbackExempt 子命令可用來管理這類回環例外。

與 TUN 模式的差異

• 系統代理路徑：應用先讀取代理設定，再主動連接本機代理連接埠；回環限制可能就在這個步驟發生。
• TUN 路徑：用戶端透過虛擬網路介面和路由接管符合條件的 IP 流量，通常不需要應用主動連接 HTTP 代理連接埠。
• 適用範圍：TUN 的實際效果也會受到路由、DNS、權限和應用行為影響。它並不是「新增所有回環豁免」的另一種說法。

排查時，先保留一種明確的流量接管方式。例如，先關閉 TUN，只測試系統代理與單一應用的回環存取。不要同時修改代理模式、DNS、規則和豁免，否則即使恢復連線，也很難判斷是哪項設定發揮作用。

操作前：確認代理入口與測試基準

以下以 127.0.0.1:7890 為例。7890 並非所有用戶端的固定連接埠，請以目前用戶端設定及實際生效的設定檔為準。mihomo 設定中的 mixed-port 同時提供 HTTP 與 SOCKS 服務；單獨的 socks-port 則不能填作 Windows HTTP 系統代理入口。

1. 在用戶端設定中確認 HTTP 或混合連接埠，並確認核心正在執行。
2. 在 Windows 11 中，開啟「設定」→「網路和網際網路」→「Proxy」→「手動設定 Proxy」→「使用 Proxy 伺服器」，查看位址和連接埠。Windows 10 則可在「設定」→「網路和網際網路」→「Proxy」中查看。
3. 如果這些設定由用戶端管理，請透過用戶端開關進行調整，避免系統介面與用戶端狀態互相覆寫。
4. 記下目標應用名稱、失敗操作和發生時間，方便稍後對照連線清單或記錄。

可以先在 PowerShell 確認範例連接埠是否能建立 TCP 連線，再明確指定代理發出 HTTPS 請求：

Test-NetConnection -ComputerName 127.0.0.1 -Port 7890
curl.exe --proxy http://127.0.0.1:7890 --head --max-time 15 https://www.microsoft.com/

TcpTestSucceeded : True 只表示連接埠可以連線；HTTP 回應則有助判斷代理連線是否建立。遠端回傳 403 等狀態碼，不代表代理連接埠失效。這裡使用 curl.exe，是為了避免 Windows PowerShell 中 curl 別名造成參數差異。

這兩項檢查由桌面程序發起，無法證明 UWP 應用已取得回環存取權限。如果基準測試本身就失敗，應先解決監聽連接埠或上游連線問題，而不是繼續調整容器權限。也不要因此啟用「允許區域網路」或將監聽位址改成 0.0.0.0；擴大監聽範圍與新增回環豁免是兩回事。

命令列操作：查詢、新增與刪除回環豁免

1. 記錄現有清單，找出正確的套件識別碼

在開始功能表搜尋 PowerShell，選擇「以系統管理員身分執行」。如果使用其他系統管理員帳戶的憑證提升權限，套件查詢可能會對應到另一個使用者；請先在目標應用所屬的使用者工作階段查詢套件資訊，再於提升權限的視窗中變更設定。

CheckNetIsolation.exe LoopbackExempt -s

Get-AppxPackage |
  Sort-Object Name |
  Select-Object Name, PackageFamilyName

-s 用來顯示現有豁免。新增前請儲存輸出或截圖，以便確認某項設定是否原本就存在。Get-AppxPackage 預設會列出目前使用者的套件；依顯示名稱猜測套件名稱容易出錯，請從輸出中讀取 PackageFamilyName。

例如，要查詢 Microsoft Store 本身的套件身分，可以執行：

Get-AppxPackage -Name Microsoft.WindowsStore |
  Select-Object Name, PackageFamilyName

常見結果中的套件系列名稱為 Microsoft.WindowsStore_8wekyb3d8bbwe。這與包含版本號、架構等資訊的 PackageFullName 不同；下方的 -n 參數應使用套件系列名稱。如果查詢沒有輸出，請先確認應用是否安裝在目前帳戶下，不要直接將顯示名稱拼進命令。

2. 只為目標應用新增豁免

以下範例只針對 Microsoft Store 本身，不會一併授權商店下載的其他應用。只有實際查詢結果與範例相同時才可直接執行；其他應用請使用各自查到的套件系列名稱。

CheckNetIsolation.exe LoopbackExempt -a -n="Microsoft.WindowsStore_8wekyb3d8bbwe"
CheckNetIsolation.exe LoopbackExempt -s

執行後，確認清單中是否出現相符的身分，並檢查命令是否傳回錯誤。如果出現拒絕存取的提示，請先確認終端機已提升權限；若提示名稱或參數有誤，請重新核對套件身分及英文半形引號。成功加入清單後，請完全關閉目標應用再重新開啟，避免沿用原本失敗的連線。

3. 撤銷這次新增的豁免

CheckNetIsolation.exe LoopbackExempt -d -n="Microsoft.WindowsStore_8wekyb3d8bbwe"
CheckNetIsolation.exe LoopbackExempt -s

-d 用來刪除指定應用的豁免。只撤銷這次新增的項目：如果該項目在操作前就已存在，不應為了測試而直接刪除。不要執行批次授權所有套件的指令碼，也不要清空整份清單來取代指定撤銷，因為現有的開發工具或其他應用可能需要其中的項目。

圖形介面操作：在回環清單中勾選目標應用

Windows「設定」沒有通用的 UWP 回環豁免核取方塊。如果電腦已安裝 Fiddler Classic，可透過工具列中的 WinConfig 開啟回環豁免工具；部分介面也可從「Tools」→「Win8 Loopback Exemptions」進入。雖然入口保留了 Win8 字樣，管理的仍是 Windows AppContainer 回環設定。

1. 先完成前述代理連接埠檢查，並記錄目前的系統代理值。
2. 開啟 Fiddler Classic，取消勾選「File」→「Capture Traffic」，避免封包擷取代理接管目前的測試流量。
3. 開啟 WinConfig，依提示授予系統管理員權限，並等待應用程式容器清單載入。
4. 只勾選需要排查的目標應用，點選「Save Changes」儲存；不要使用「Exempt All」批次授權。
5. 關閉工具與 Fiddler Classic，再次確認系統代理仍指向 Clash 用戶端實際使用的連接埠，然後啟動目標應用進行測試。

要撤銷時，重新進入 WinConfig，取消這次新增的勾選並儲存即可。圖形工具與命令列管理的是同一類系統設定，可使用 CheckNetIsolation.exe LoopbackExempt -s 交叉確認。沒有安裝該工具的電腦，直接使用系統內建命令即可，不必為此額外架設封包擷取環境。

如何驗證：比對應用請求、規則命中與撤銷結果

豁免清單中出現應用名稱，只能證明設定已寫入，不代表目標功能一定恢復。驗證時應針對同一個失敗操作，例如重新整理商店頁面或載入應用內的線上內容，同時觀察用戶端的連線記錄。

1. 固定測試條件：維持相同的訂閱、代理群組和規則模式，關閉封包擷取工具，並記錄測試時間。
2. 重新啟動目標應用：必要時在工作管理員中結束對應程序，再重新開啟。只關閉視窗可能仍會留下背景程序。
3. 查看連線：在用戶端的「連線」或「記錄」介面確認目標網域、目標位址、命中規則及輸出策略；介面名稱依用戶端而異。
4. 檢查實際結果：區分「請求已進入代理」與「登入或下載成功」。伺服器的地區限制、帳戶狀態和憑證錯誤仍須分別處理。
5. 必要時比對撤銷前後：只刪除這次新增的項目，再重複操作；測試後依實際需要還原設定。

有些連線是由系統服務或輔助程序發起，不能只依程序名稱篩選。應用也可能先從快取顯示頁面，因此單次「成功開啟」的證據力有限。綜合時間、目標網域和規則命中情況，比只看視窗能否顯示內容更可靠。

如果連線已進入 mihomo，卻命中 DIRECT，回環存取通常已不是目前的阻斷點。此時應檢查規則依序比對的結果、規則集是否已更新，以及代理群組是否選擇預期策略。規則模式不代表所有流量都會經過代理，新增豁免也不會改變這一點。

仍無效時的排查順序

清單中已有豁免，但用戶端看不到連線

先確認豁免對應的確實是發出網路請求的套件，而不是名稱相似的啟動程式。接著檢查應用是否遵循 Windows 系統代理、是否有獨立的代理選項，以及是否已重新啟動。對於不使用系統代理的應用，回環豁免不會憑空建立代理路徑；可在保留原設定的前提下，單獨測試 TUN 接管。

用戶端看得到連線，但實際功能仍失敗

先檢查命中策略與連線錯誤，再分辨 DNS 解析失敗、上游逾時、TLS 錯誤和 HTTP 錯誤回應。應用程式下載可能會連線至多個網域，首頁載入成功不代表內容傳遞位址也採用相同策略。請針對實際失敗的連線調整，不要直接將所有網域改用同一種輸出方式。

應用程式更新或重新安裝後又無法使用

一般版本更新通常不會改變套件系列名稱，但更換發佈管道、安裝預覽版或遷移 Windows 帳戶後，實際套件身分可能不同。請重新執行套件查詢與 -s，以目前環境為準。若企業裝置由原則管理，請聯絡管理員確認限制，不要以關閉防火牆取代指定授權。

完整的判斷流程應為：本機代理可用 → 應用確實使用該入口 → 必要的回環權限已放行 → 連線命中預期規則 → 實際請求成功。依此順序驗證，才能分別處理 Windows 容器限制、用戶端設定和遠端服務問題。