瀏覽器正常、商店 App 連不上：先確認是否為回環限制

在 Windows 開啟 Clash 系統代理後，瀏覽器能連上目標網站，Microsoft Store 或某個 UWP App 卻顯示網路無法使用，這種差異可能與 AppContainer 的網路隔離有關。系統代理通常會指向本機位址，例如 127.0.0.1:7890；受隔離的 App 連線至這個位址時，可能還沒連上 Clash 核心就先被 Windows 擋下。

不過，「從商店安裝」不代表「在 UWP 沙箱中執行」。Microsoft Store 也會發佈一般桌面程式，MSIX 套件也能封裝完整信任的桌面 App。只有先確認目標 App 的執行方式，回環豁免才有明確作用。App 忽略系統代理、代理連接埠設定錯誤或登入服務故障，也可能造成類似情況。

同時檢查以下三種情況

  • 一般桌面瀏覽器能連上相同服務：至少表示目前節點與基本代理連線可能正常；但若瀏覽器安裝了獨立代理擴充功能，就不能據此判斷系統代理已生效。
  • 操作目標 App 時沒有相應的連線紀錄：開啟 Clash 的連線或日誌頁面，再重新整理 App。沒有紀錄可能表示連線在抵達核心前就被攔截，也可能是 App 根本沒有使用系統代理。
  • 系統代理位址指向本機：確認位址是否為 127.0.0.1、localhost 或回環 IPv6 位址 ::1，以及連接埠是否與核心實際監聽的連接埠相同。

UWP 沙箱與 127.0.0.1 的連線關係

回環位址代表目前這台電腦，不是外部網路節點。常見的連線路徑是「App → 本機 HTTP 代理連接埠 → Clash 或 mihomo 核心 → 規則選定的出口」。系統代理設定只會告知遵循該設定的 App 要連到哪裡，不會解除 App 本身受到的網路隔離。

UWP App 通常在 AppContainer 中執行。Windows 預設會限制這類 App 存取本機回環服務，以維持 App 與本機服務之間的隔離。即使代理服務已啟動，App 仍可能無法連線至 127.0.0.1:7890。CheckNetIsolation LoopbackExempt 可為指定的 App 套件設定回環豁免，讓它能存取本機服務。

操作實際作用仍須檢查
啟用系統代理提供本機代理位址與連接埠App 是否讀取系統代理
新增回環豁免允許指定的 AppContainer 存取回環服務代理監聽、節點與分流規則
修改代理規則決定已進入核心的連線使用哪個出口連線是否先抵達核心
啟用 TUN透過虛擬網路介面接收 IP 流量路由、DNS、權限與 App 的網路行為

因此，新增豁免不代表強制 App 改走代理出口。連線進入核心後，仍可能符合 DIRECT，也可能遭到 REJECT 拒絕。回環限制與規則分流屬於不同層次，排查時應先確認流量能否進入，再檢查出口。

操作前檢查系統代理與監聽連接埠

  1. 保持 Clash 客戶端與核心執行中，並確認已啟用包含有效節點的設定。
  2. 在 Windows 11 中開啟「設定」→「網路和網際網路」→「Proxy」→「手動 Proxy 設定」→「使用 Proxy 伺服器」旁的「設定」。Windows 10 的入口同樣位於「設定」→「網路和網際網路」→「Proxy」，但開關配置不同。
  3. 檢查客戶端啟用系統代理後設定的位址與連接埠。若使用本機代理，位址通常是 127.0.0.1，連接埠則應與目前的 HTTP 或混合連接埠相同。
  4. 在 PowerShell 中確認該連接埠能否建立 TCP 連線，再設定 App 豁免。
Test-NetConnection -ComputerName 127.0.0.1 -Port 7890
netstat -ano | findstr ":7890"

TcpTestSucceeded : True 表示目前的 PowerShell 處理程序能連上這個連接埠，不代表 UWP 已獲准存取，也不代表代理出口已可使用。netstat 結果應出現相應的 LISTENING 監聽紀錄；若只有其他連線狀態，不能據此認定核心正在監聽。

方法一：使用 CheckNetIsolation 豁免指定 App

以下以 Microsoft Store 為例。請在受影響的 Windows 使用者工作階段中開啟「開始」功能表，搜尋 PowerShell，然後選擇「以系統管理員身分執行」。若輸入另一位管理員的憑證來取得更高權限，目前的使用者內容會改變；此時 Get-AppxPackage 的預設查詢結果可能不再對應受影響的使用者，因此要先確認查詢對象。

1. 查詢 App 套件系列名稱

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

新增豁免時要使用 PackageFamilyName，而不是顯示名稱，也不是包含版本與架構資訊的 PackageFullName。Microsoft Store 常見的套件系列名稱為 Microsoft.WindowsStore_8wekyb3d8bbwe，但仍應以目前電腦的查詢結果為準。

若要排查其他 App，可先列出目前使用者的 App 套件，再依 App 名稱篩選。App 介面顯示的名稱不一定與套件名稱相同，請勿只根據圖示文字推測套件系列名稱。

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

2. 新增豁免並確認結果

以下命令會從已安裝的 Microsoft Store 套件讀取名稱，避免手動輸入。若找不到套件，指令碼會停止，不會繼續執行缺少參數的命令。

$store = Get-AppxPackage -Name Microsoft.WindowsStore
if (-not $store) {
  throw "找不到目前使用者的 Microsoft.WindowsStore App 套件"
}
CheckNetIsolation.exe LoopbackExempt -a "-n=$($store.PackageFamilyName)"
CheckNetIsolation.exe LoopbackExempt -s
  • -a：為指定套件新增回環豁免。
  • -n=：依套件系列名稱指定 App。
  • -s：顯示目前的回環豁免清單。

執行後確認清單中是否出現目標 App 名稱或相應 SID。清單非空不代表剛新增的 App 已列在其中。若命令回報拒絕存取，請先確認終端機已取得系統管理員權限；若回報參數或套件名稱錯誤，請重新查詢套件系列名稱，不要改用完整套件名稱反覆嘗試。

3. 重新啟動 App 並查看連線

關閉目標 App 後重新開啟，再重做先前失敗的操作。有些 App 關閉視窗後仍會在背景執行，可在工作管理員確認目標處理程序已結束；必要時先儲存工作，再結束該 App 的處理程序。通常新增一項豁免不需要重新啟動整台電腦。

同時查看 Clash 連線紀錄中的目標網域、符合的規則、策略群組與實際使用的節點。若已出現連線但頁面仍無法使用，請改為檢查分流、DNS、服務的地區要求或登入狀態；繼續新增更多 App 豁免無法解決這些問題。

方法二：使用客戶端內建的 UWP 回環工具

部分 Windows 圖形介面客戶端會提供「UWP 回環」、「Loopback」或類似功能，本質上也是管理 Windows 的回環豁免清單。這是客戶端介面提供的功能，不是 Clash 設定中通用的 YAML 欄位，也不是每款 mihomo 客戶端都內建的工具。

舊版 Clash for Windows 0.20.x 常見的操作路徑為「Settings」→「System」→「UWP Loopback」→「Launch Helper」。這條舊版介面路徑僅供辨認既有安裝，不應作為選擇新客戶端的依據。其他客戶端請依目前版本的設定介面查找；若沒有此功能，直接使用上面的系統命令即可。

  1. 啟動回環工具，並依系統提示授予系統管理員權限。
  2. 在 App 清單中找到確實需要存取本機代理的目標套件。
  3. 勾選該 App 並儲存變更。若工具提供重新整理按鈕，安裝新 App 後請先重新整理清單。
  4. 執行 CheckNetIsolation.exe LoopbackExempt -s，再次確認系統中已儲存的清單。
  5. 重新啟動目標 App，確認連線是否進入核心。

撤銷回環豁免並保留排查紀錄

若不再使用本機系統代理，或只是為了確認原因而暫時新增豁免，可以單獨撤銷目標 App 的豁免。以下繼續以 Microsoft Store 為例，使用新增豁免時相同的套件系列名稱。

$store = Get-AppxPackage -Name Microsoft.WindowsStore
if (-not $store) {
  throw "找不到目前使用者的 Microsoft.WindowsStore App 套件"
}
CheckNetIsolation.exe LoopbackExempt -d "-n=$($store.PackageFamilyName)"
CheckNetIsolation.exe LoopbackExempt -s

-d 會刪除指定套件的豁免，之後請再次查看清單，確認該項已移除。不建議直接清空整份豁免清單，因為其他 App 或開發測試環境可能會用到既有項目。若目標 App 已解除安裝，請根據先前保存的套件系列名稱或清單中的 SID 找出舊項目，不要再從查無結果的 App 查詢中取得名稱。

  • 修改前記錄目標 App 的套件系列名稱，以及它是否已在豁免清單中。
  • 記下目前的代理位址、連接埠及客戶端啟用的設定名稱，以便區分「豁免變更」與「設定變更」。
  • 測試完成後保留必要項目；暫時放行的 App 請逐項撤銷豁免。

TUN 替代方案：接管流量，而非放寬回環限制

若 App 不讀取系統代理，回環豁免本身無法讓它使用 Clash。支援 TUN 的 mihomo 客戶端可透過虛擬網路介面與路由接收 IP 流量，讓部分原本直接連網的 App 也交由規則處理。這與「App 主動連線至本機 HTTP 代理」的路徑不同，因此在路由與 DNS 設定合適時，可免除對本機代理連接埠的依賴。

TUN 並非所有 UWP 網路問題的通用解法。若 App 仍讀取系統代理並嘗試連線至受限的回環位址，單獨啟用 TUN 未必能改變結果。為了排除變因，可先記錄原有設定，再關閉系統代理、僅使用 TUN 測試；前提是確認目前的客戶端確實已接管目標流量。

依序確認 TUN 設定

  1. 確認核心支援 TUN。mihomo 與舊版 Clash 核心的功能不同，不能只根據客戶端名稱判斷。
  2. 依客戶端要求安裝服務或授予系統管理員權限，並確認已成功建立虛擬網路介面。
  3. 確認已啟用自動路由，並檢查客戶端產生的最終設定，不要同時複製多段來源不明的 TUN 設定。
  4. 確認 DNS 要求是否依預期進入核心。DNS 劫持、系統 DNS 與 App 內建的加密 DNS 可能採用不同路徑。
  5. 暫時關閉其他 VPN 或網路接管軟體，減少預設路由衝突，再測試目標 App。

選擇方式很簡單：若 App 遵循系統代理，且問題集中在回環隔離，先為單一 App 新增豁免；若 App 繞過系統代理，或需要接收更多流量，再考慮 TUN。切換至 TUN 後仍須確認命中的規則；接管連線不代表所有連線都會經過代理節點。

常見結果與後續排查

新增豁免成功，但商店仍顯示無法連線，接下來該檢查什麼？

先確認目標套件確實列在豁免清單中，重新啟動 App，再查看核心是否出現連線。若有連線，請檢查是否符合 DIRECT、節點能否連上相關網域，以及系統日期與時間是否正確。商店服務也可能受帳號、服務狀態及地區限制影響，請依 App 錯誤碼繼續排查，不要重複執行新增命令。

需要使用 netsh winhttp import proxy source=ie 嗎？

這個命令會將使用者代理設定匯入 WinHTTP 代理設定，適用於另一類代理使用情境，無法解除 AppContainer 的回環隔離。請勿將它與 CheckNetIsolation 視為相同的修復方式。只有在確認目標元件使用 WinHTTP，且了解其對系統範圍的影響時，才應另外檢查這項設定。

為什麼更換 Clash 客戶端後還要檢查豁免？

豁免是針對 App 套件，儲存在 Windows 中，而不是訂閱檔案裡。更換客戶端通常不會改變目標 App 的豁免身分，但可能會改變本機監聽連接埠、系統代理位址與流量接入方式。App 更新後若套件系列名稱不變，通常仍可沿用原有項目；若重新封裝或更換發佈管道，則應重新查詢。

完整排查順序如下：確認核心正在執行且連接埠有監聽、確認系統代理指向正確位址、判斷目標 App 是否受到 AppContainer 回環隔離、為該 App 新增豁免，最後檢查連線規則與出口。每次只變更一個條件，才能分辨是 Windows 流量接入問題，還是訂閱、節點、DNS 或規則問題。

若要進一步了解設定層的差異，請參閱規則分流參考與核心說明；首次連線的通用操作請參閱代理連線教學。