先確認是否為本機回環限制

瀏覽器能透過 Clash 開啟網頁，但某個 Windows 商店 App 無法登入、載入清單或取得內容，可能是 AppContainer 網路隔離所致。典型情況是：App 讀取系統代理設定，嘗試連線至本機的 127.0.0.1:7890，卻在連上 Clash 監聽連接埠之前就受到限制。此時更換節點或調整分流規則，通常不會改變這個結果。

UWP App 通常在 AppContainer 中執行，預設無法任意存取本機回環服務。回環豁免的作用，是允許指定的 App 容器存取本機服務；這不是代理設定，也不會自動指定節點或修改 DNS。App 仍須採用能經過 Clash 的網路路徑。

操作前確認以下三項

  • Clash 核心正在執行，而且一般瀏覽器透過同一個代理可以存取目標服務。
  • 目前使用系統代理或 App 自身的本機代理設定，而不只是開啟用戶端視窗。
  • 問題只出現在特定 App；若所有 App 都無法連線，應先檢查訂閱、節點、連接埠與網路連線。

本文指令適用於 Windows 10、Windows 11 的 PowerShell 環境。範例連接埠統一使用 7890，實際操作請以目前生效的設定為準。不要因為教學使用這個數值，就覆蓋用戶端目前正常運作的監聽連接埠。

確認系統代理與 Clash 監聽連接埠

在 Windows 11 開啟「設定」→「網路和網際網路」→「Proxy」；Windows 10 的路徑也是「設定」→「網路和網際網路」→「Proxy」。確認手動代理或設定指令碼符合用戶端目前狀態。若使用本機手動代理，常見位址是 127.0.0.1，連接埠則應對應 Clash 的 HTTP 或混合連接埠。

# 設定片段：僅說明監聽欄位，並非完整設定
mixed-port: 7890
allow-lan: false
mode: rule

mixed-port 可同時接受 HTTP 和 SOCKS 代理連線。Windows 手動代理使用的是 HTTP 代理入口，不可任意填入僅接受 SOCKS 的連接埠。若設定分別使用 port 和 socks-port，應選擇前者。

在 PowerShell 中檢查連接埠是否正在監聽，並使用明確指定的代理發出請求，以排除系統代理設定的影響：

Get-NetTCPConnection -State Listen -LocalPort 7890 |
  Select-Object LocalAddress, LocalPort, OwningProcess

curl.exe --proxy http://127.0.0.1:7890 --head --max-time 15 https://www.microsoft.com/
  • 沒有監聽記錄：先確認核心是否已啟動、設定是否成功載入，以及連接埠是否輸入錯誤。
  • 監聽正常但請求逾時：查看 Clash 記錄，檢查節點、規則與目標服務，不要直接進行豁免操作。
  • 請求收到 HTTP 回應：表示這次桌面處理程序的代理請求已完成；即使回應是重新導向或拒絕存取，也應進一步區分網路連線與服務權限問題。

這個 curl.exe 指令不是用來測試 UWP，只能驗證本機代理連線路徑。netsh winhttp show proxy 查詢的是 WinHTTP 代理設定，不能取代對使用者系統代理的檢查。不要只為了修復一個 UWP App，就直接重設整台電腦的 WinHTTP 設定。

方法一：使用用戶端的回環豁免工具

部分 Windows 版 Clash 圖形用戶端提供外部回環管理工具，選單名稱可能包含「UWP 回環豁免」、「Loopback」或「UWP Loopback」。工具的位置與是否內建，視用戶端及版本而異；並非所有 mihomo 用戶端都有相同選單。找不到入口時，直接使用下一節的系統指令即可，不必另外安裝其他代理用戶端。

  1. 先儲存目前設定，並記下發生問題的 App 名稱。
  2. 在用戶端設定中找到回環管理入口並啟動工具；出現使用者帳戶控制提示時，確認程式來源後再授權。
  3. 在 App 清單中找到目標 App，勾選對應項目。建議只授權確實需要存取本機代理的 App。
  4. 按下工具中的儲存或套用變更。只勾選但未儲存，通常不會寫入系統豁免清單。
  5. 完全關閉目標 App 後重新開啟，再執行相同的登入或載入操作。

如果 App 清單中沒有目標項目，先確認它已安裝在目前的 Windows 使用者帳戶下。有些 App 由多個套件或獨立元件組成，介面顯示名稱不一定等於實際發出請求的套件名稱。此時應使用 PowerShell 查詢套件識別資訊，而不是勾選所有名稱相近的項目。

方法二：使用 CheckNetIsolation 新增豁免

1. 查詢 PackageFamilyName

在目前登入使用者的 PowerShell 中執行以下指令。這裡以 Microsoft Store 套件為例，僅示範如何查詢識別資訊，不代表它的各種下載或登入故障都能透過回環豁免解決。

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

常見的套件系列名稱是 Microsoft.WindowsStore_8wekyb3d8bbwe，但仍應以本機輸出為準。查詢其他 App 時，可以先列出目前使用者的套件，再依顯示的 Name 縮小範圍：

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

PackageFamilyName 與 PackageFullName 不同。後者通常包含版本、架構等資訊，不要直接將它傳給下方的 -n 參數，也不要照抄 App 安裝目錄路徑。若查詢沒有輸出，請先確認套件名稱、安裝使用者與 App 類型。

2. 在系統管理員終端機中新增並確認

在「開始」按鈕上按右鍵，選擇「終端機（系統管理員）」或「Windows PowerShell（系統管理員）」。盡量以目標 App 所屬的同一個帳戶取得系統管理員權限；若輸入另一位管理員的憑證來啟動終端機，請留意查詢到的 App 套件是否屬於正確的使用者。

CheckNetIsolation.exe LoopbackExempt -s

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

CheckNetIsolation.exe LoopbackExempt -s

-s 用來列出現有豁免，-a 用來新增指定 App。第一次查詢可保留變更前的狀態，第二次查詢則用來確認結果。輸出可能同時顯示 App 名稱與 SID；請確認目標項目，不要只以命令視窗沒有錯誤訊息作為判斷。

新增後，請完全關閉目標 App 再重新啟動。必要時在工作管理員中確認相關處理程序已結束。通常不必重新啟動整台 Windows；若 App 使用常駐背景處理程序，只關閉視窗可能不足以建立新連線。

3. 移除單一豁免

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

CheckNetIsolation.exe LoopbackExempt -s

-d 用來撤銷指定 App 的授權。排查時不要順手清除所有豁免，因為其他開發工具或本機服務可能仍依賴現有項目。若出現拒絕存取，先確認終端機是否已取得系統管理員權限；受組織原則管理的裝置，請聯絡管理員確認權限範圍。

豁免後仍未生效：依連線階段逐步排查

豁免清單中出現目標 App，只能證明授權已寫入，不能證明請求已經經過代理。建議在 Clash 中開啟連線記錄或日誌，再重試一次目標操作；每次只變更一個條件，避免同時更換節點、啟用 TUN、修改 DNS，最後無從判斷原因。

觀察結果 優先檢查 下一步
Clash 中沒有對應連線 App 是否使用系統代理、套件識別資訊是否正確 重新啟動 App，確認系統代理設定與實際連網元件
連線記錄顯示 DIRECT 規則順序與目前執行模式 檢查實際命中的規則，不要再重複新增豁免
已進入代理，但連線逾時 節點可用性、出口與目標服務 以相同目標交叉測試，查看連線錯誤
網域名稱解析失敗 App、系統與核心實際使用的解析路徑 確認由哪個元件處理 DNS 請求，再調整對應設定
只有登入或下載失敗 獨立背景服務、帳戶與服務端限制 分別檢查登入、清單載入與下載請求

App 不使用系統代理

回環豁免不會強迫 App 讀取 Windows 代理設定。若 App 使用獨立網路堆疊、直接連線至遠端，或由系統服務代為發出請求，替前景 App 新增豁免未必會影響實際連線路徑。商店頁面能開啟但下載失敗，也可能是下載階段改用另一套服務路徑。

規則已匹配，但出口不符合需求

連線已出現在 Clash 中時，應檢查 mode: rule 下命中的規則，以及策略群組最後選用的項目。伺服器可能依出口地區、帳戶狀態或存取頻率回傳錯誤；新增回環權限無法解決這類回應。也不要只因為節點延遲測試成功，就認定目標服務一定可用。

防火牆、組織原則與網路功能

本機防火牆、端點安全原則或 App 本身宣告的網路功能，仍可能限制連線。回環豁免並非解除所有網路限制的總開關。請保留具體錯誤碼、發生時間與相關日誌，逐一檢查個別處理程序的原則；不建議為了長期修復而關閉整套防火牆。

何時改用 TUN，何時保留系統代理

如果 App 明確不遵循系統代理設定，但需要由 Clash 接管其 IP 流量，可以評估 mihomo 的 TUN 模式。TUN 透過虛擬網路介面與路由處理流量，不必仰賴各 App 主動連線至 HTTP 代理連接埠；不過實際涵蓋範圍仍受路由、排除規則、DNS 設定與系統權限影響。

  • 只有少數 AppContainer App 需要存取本機代理：先使用系統代理，並按需求新增回環豁免，以便控制影響範圍。
  • App 直接連網、不採用代理設定：確認基本設定無誤後，再單獨測試 TUN，並觀察實際連線記錄。
  • 啟用 TUN 後仍保留系統代理：App 可能仍會主動連線至本機代理，因此回環限制依然可能存在；TUN 開關不一定能取代回環豁免。
  • 裝置正在使用企業 VPN 或其他虛擬網卡：先檢查路由與 DNS 是否衝突，不要同時啟用多套流量接管機制碰運氣。

allow-lan: true 不能取代回環豁免。這個欄位是允許其他裝置存取代理監聽服務，與授權本機 AppContainer 存取回環是兩回事。只為修復 UWP 就擴大監聽範圍，會增加額外的存取控管工作。

完成後的驗證與維護

  1. 保留新增前後的 LoopbackExempt -s 輸出，確認只新增了預期的 App。
  2. 重新開啟目標 App，分別測試登入、內容載入與下載，不要只檢查啟動畫面。
  3. 在 Clash 連線記錄中確認目標網域、命中規則與實際策略，確保流量路徑符合預期。
  4. 撤銷排查時暫時切換的全域模式、臨時 DNS 或其他無關變更，再重新測試。

一般 App 更新通常不會改變套件系列名稱，因此不必每次升級都重新授權。若 App 曾解除安裝後重裝、改用其他發行管道、切換 Windows 帳戶或重建系統，則需要重新查詢套件識別資訊與豁免清單。

排查結論應明確指出問題所在環節：本機連接埠是否正在監聽、App 能否存取回環、請求是否進入核心、規則將請求交由哪個策略處理，以及目標服務回傳了什麼。依此順序檢查，可將 AppContainer 權限問題與訂閱、節點、DNS 及服務端問題區分開來。