先確認：瀏覽器正常，只有特定商店 App 無法使用

先讓 Clash 用戶端保持執行，確認訂閱已啟用、節點可連線，再開啟有問題的 App。如果瀏覽器能透過系統代理連上網路，但某個 UWP App 顯示離線、登入逾時或無法更新內容，就可以檢查回環限制。先別急著更換訂閱、修改 DNS，或將所有 App 都加入豁免。

本文適用於在 Windows 10、Windows 11 使用本機 HTTP 代理的疑難排解。各用戶端的介面名稱可能不同，但可以透過 Windows 內建的 CheckNetIsolation.exe 執行底層操作。文中的 7890 僅為設定範例，並非所有用戶端都使用此連接埠；操作前請先確認目前設定。

先檢查三件事

  1. 確認用戶端已啟用系統代理。在 Windows 11 中，前往「設定」→「網路和網際網路」→「Proxy」→「手動 Proxy 設定」，確認 Proxy 伺服器指向本機位址，例如 127.0.0.1:7890。Windows 10 的設定位置為「設定」→「網路和網際網路」→「Proxy」。
  2. 確認該連接埠是 HTTP 連接埠或 mixed-port。僅提供 SOCKS5 的連接埠無法直接做為 Windows 手動 HTTP Proxy 連接埠使用。
  3. 開啟用戶端的連線清單或記錄，再讓目標 App 更新一次。記下時間、是否出現連線、符合哪條規則，以及是否顯示連線失敗。

UWP 回環限制：為什麼本機代理也可能連不上

本機回環是指 App 存取同一台電腦上的網路服務，例如連線至 127.0.0.1 或 IPv6 位址 ::1。Clash、Clash Meta（mihomo）核心通常會在本機監聽代理連接埠；桌面 App 將請求送至該連接埠，再由核心依規則選擇直連或代理節點。

UWP 常用的 AppContainer 沙箱設有網路隔離規則。即使 App 讀取到系統代理設定，也可能因限制而無法存取本機代理監聽連接埠。因此，「設定中已啟用系統代理」和「App 能連上本機代理」是兩個不同條件。這時 App 可能直接顯示錯誤，也可能依自身邏輯嘗試其他網路路徑，不能一概認定它必然會繞過代理。

一般代理連線路徑：
App → 127.0.0.1:7890 → Clash / mihomo → 規則分流 → 目標服務

可能受限的位置：
AppContainer App → 本機回環連接埠受限 → 請求未送達代理核心

新增回環豁免可讓指定 App 略過這項回環隔離限制；但不會替 App 設定代理，也不保證 App 會使用系統代理。標題中的「解除」是指解除特定 App 的回環限制，實際操作是新增豁免，而非刪除豁免。

  • 這與規則模式不同：規則決定請求進入核心後的出口，無法解除請求抵達核心前的沙箱限制。
  • 這與訂閱不同：訂閱提供節點、策略群組或規則設定，不會修改 Windows 的 App 隔離狀態。
  • 這與 allow-lan 不同：allow-lan 是讓區域網路裝置存取代理；排查本機 UWP 的回環問題，不必先開放區域網路存取。

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

先在用戶端的設定或工具區尋找「UWP 回環」、「回環豁免」、「Loopback」或「UWP Loopback」選項。有些版本會開啟獨立工具，有些則沒有提供此功能。別為了尋找名稱相同的按鈕而安裝已停止維護的舊版用戶端；找不到選項時，直接使用下一節的系統命令即可。

勾選目標 App 並儲存

  1. 確認目標 App 已安裝，並先將它關閉，避免操作後繼續使用舊連線。
  2. 開啟用戶端的回環工具。如果系統顯示使用者帳戶控制提示，請確認程式來源後再授予系統管理員權限。
  3. 在清單中找到目標 App，確認顯示名稱和套件資訊，只勾選需要存取本機代理的 App。
  4. 按一下工具中的「儲存」、「套用」或相應的確認按鈕。只勾選而未儲存，通常不會變更系統狀態。
  5. 重新啟動目標 App，執行一項明確的網路操作，同時查看用戶端的連線清單。

如果清單中找不到目標 App，先確認它是否安裝在目前的 Windows 使用者帳戶下，再重新開啟工具。部分工具無法完整列出新版 App 或其他帳戶的套件；此時應查詢實際的套件系列名稱，而不是選擇名稱相近的項目。

方法二：使用 CheckNetIsolation 為指定套件新增豁免

在開始功能表按右鍵，選擇「終端機（系統管理員）」；Windows 10 也可能顯示「Windows PowerShell（系統管理員）」。下方查詢套件資訊的命令需要在 PowerShell 中執行。修改豁免清單需要系統管理員權限；查詢時也要留意目前使用者：若以另一位系統管理員的帳戶憑證啟動終端機，顯示的 App 清單可能不屬於原本登入的帳戶。

第一步：記錄目前的豁免清單

CheckNetIsolation.exe LoopbackExempt -s

-s 用來列出目前的回環豁免。先保留這次輸出，方便確認目標套件是否已在清單中。輸出可能包含 App 名稱和安全識別資訊；別只因清單很長就清空它，其他軟體可能需要現有設定。

第二步：查詢目標 App 的套件系列名稱

在 PowerShell 中執行以下命令，即可列出目前使用者的 App 套件名稱和套件系列名稱。清單太長時，可用第二個命令依實際名稱篩選。以下以 Microsoft Store 為操作範例，不代表商店的所有網路問題都由回環限制造成。

Get-AppxPackage | Select-Object Name, PackageFamilyName

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

參數 -n 要填的是 PackageFamilyName，不是開始功能表中的中文名稱，也不是包含版本號和架構的 PackageFullName。Microsoft Store 常見的套件系列名稱是 Microsoft.WindowsStore_8wekyb3d8bbwe，仍請以本機查詢結果為準。

第三步：只為查到的目標套件新增豁免

以下 PowerShell 程式碼會先查詢 Microsoft Store；若找不到就停止，避免使用空值繼續執行。若要排查其他 App，請將查詢名稱改成前一份清單中確認的實際 Name，不要把範例當成適用於所有 App 的修復命令。

$pkg = Get-AppxPackage -Name Microsoft.WindowsStore
if ($null -eq $pkg) {
    throw "找不到目前使用者的 Microsoft.WindowsStore，請先確認 App 名稱和登入帳戶。"
}
CheckNetIsolation.exe LoopbackExempt -a "-n=$($pkg.PackageFamilyName)"
CheckNetIsolation.exe LoopbackExempt -s

-a 代表新增。確認命令執行成功後，再用 -s 確認清單中已出現目標項目。若已確認本機的套件系列名稱，也可以直接執行下方這個命令；同樣需要系統管理員權限。

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

第四步：關閉 App 後重新測試

儲存工作並關閉目標 App；必要時在工作管理員中結束殘留程序，再重新開啟並更新內容。通常不必重新啟動整台電腦。測試時仍須讓用戶端保持執行、啟用系統代理，並使用先前確認可連線的節點。

遇到「拒絕存取」時，先確認是否使用系統管理員終端機；遇到無效參數時，檢查連字號、套件系列名稱，以及命令是否在複製時被換行截斷。受組織管理的裝置也可能受到管理原則限制，請交由管理員確認，別反覆關閉安全功能。

如何驗證：連接埠可連線、App 請求進入、出口正確

命令執行成功，只能證明豁免設定已提交，無法單獨證明 App 已透過代理連線。建議分成三個層次驗證，每次只變更一個條件，方便找出真正有效的設定。

驗證層次具體操作可確認的事項
代理連接埠測試本機 TCP 連接埠 7890連接埠是否有可連線的監聽服務
App 請求更新目標 App 並查看連線清單請求是否進入 Clash 或 mihomo
規則出口檢查網域、規則和策略鏈請求最後選擇直連還是代理

請在 PowerShell 中執行以下命令。若目前設定使用 7897，請將連接埠也改為 7897。輸出中的 TcpTestSucceeded : True 僅表示 TCP 連線成功，不代表監聽服務一定是 Clash，也無法證明 UWP 的回環存取權限正常。

Test-NetConnection -ComputerName 127.0.0.1 -Port 7890

也可以使用 Windows 內建的 curl.exe 明確指定 HTTP 代理，測試一般桌面程序透過該連接埠發出 HTTPS 請求的情況。使用完整的 curl.exe 名稱，可避免部分 PowerShell 版本中的同名別名。

curl.exe --head --connect-timeout 10 --max-time 20 --proxy http://127.0.0.1:7890 https://www.microsoft.com/

收到 HTTP 回應，代表這次命令收到伺服器或中間節點的回應；仍應搭配記錄判斷完整結果。這不是直接測試目標 UWP App。最後請回到 App 中執行登入、更新等操作，並觀察相同時間點出現的新連線。若背景流量很多，可暫時關閉其他 App 以減少干擾。

已新增豁免仍無法使用：依症狀繼續排查

連線清單中完全沒有目標請求

先確認目標 App 確實受到 AppContainer 回環限制，並確認豁免對應目前安裝的套件。接著檢查 App 是否使用系統代理。有些程式採用自有網路堆疊，有些請求則由系統服務或其他程序發出；為介面所屬套件新增豁免，不會自動改變其他程序的網路行為。

  • Windows 設定中的手動 Proxy、PAC 自動設定和 WinHTTP Proxy 並非同一個設定位置。別把 netsh winhttp import proxy source=ie 當成通用修復方式；這會修改另一套 Proxy 設定，卻不一定影響目標 App。
  • Microsoft Store 的介面載入、帳戶登入和 App 下載可能使用不同元件。介面恢復正常不代表下載服務也採用相同連線路徑，應分別測試。
  • 清除商店快取或重新安裝 App，處理的是另一類問題，不能取代回環豁免驗證；沒有錯誤證據時，也不適合優先採取這些做法。

請求已出現，但規則結果是 DIRECT

這表示請求已進入核心，接下來應檢查規則和策略群組，而不是繼續新增豁免。查看連線對應的網域、目標 IP、命中的規則和實際出口。若設定將該服務分配至 DIRECT，新增回環豁免也不會強制改走代理。

可以短暫切換至全域模式進行對照，但也要在全域模式中選擇可用的代理策略；測試結束後請恢復原本的規則模式。別只因為「全域模式可用」就長期取代整份規則，應先找出特定網域和規則順序。

請求已透過代理，但仍無法登入

繼續檢查記錄中的 DNS 失敗、連線逾時、TLS 錯誤，以及帳戶地區、系統時間和服務狀態。節點能用來瀏覽網頁，不代表目標服務接受該出口。遇到憑證問題時，別透過關閉憑證驗證掩蓋錯誤；應先檢查系統時間、憑證鏈，以及是否有額外的 HTTPS 檢查軟體。

是否需要啟用 TUN 模式

TUN 會透過虛擬網路介面接管符合路由條件的流量，適合排查不遵循系統代理的 App，但它並不等於「新增回環豁免」。實際結果仍取決於用戶端、mihomo 設定、路由、DNS 和 Windows 網路隔離原則，無法保證啟用後所有 UWP 請求都能正常使用。

若決定測試 TUN，請先儲存目前設定，依用戶端要求安裝或啟用服務，再一次只變更一項設定。記錄啟用前後的連線和路由狀況；別同時修改 Fake-IP、規則、系統代理和防火牆，否則很難判斷是哪個步驟改變結果。相關設定可參閱進階設定。

撤銷豁免與日常維護

若不再需要某個 App 存取本機代理，可以撤銷該項豁免。以下仍以已確認的 Microsoft Store 套件系列名稱為例，-d 代表刪除指定項目，不會解除安裝 App，也不會刪除 Clash 設定。

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

別為了撤銷一項設定就清空所有豁免。App 更新通常會保留套件系列識別；重新安裝、更換發行管道或改用其他帳戶後，則應重新查詢，不必一味重複新增舊名稱。系統代理連接埠變更時，也要同步確認 Windows 的代理位址；回環豁免不會自動更新連接埠。

  • 瀏覽器也無法使用：先排查用戶端、監聽連接埠、訂閱和節點連線。
  • 只有隔離 App 無法使用，且沒有連入記錄：確認 App 類型、套件系列名稱和回環豁免。
  • 已有連入記錄：接著檢查規則、DNS、代理出口和目標服務，不要把所有問題都歸咎於 UWP。

排查順序可以固定為：確認本機代理可用、確認目標 App 身分、視需要新增豁免、重新啟動 App，再檢查連線和出口。這樣既能排除確實由本機回環限制造成的故障，也能避免把規則分流、系統服務代理和帳戶問題混為一談。