Windows Microsoft Store 應用無法使用 Clash 代理？解除 UWP 回環限制的方法

先分清系統代理、應用程式沙箱與代理規則

瀏覽器能透過 Clash 連線，但某個 Microsoft Store 應用程式持續顯示連線失敗，可能與 UWP 的回環限制有關。常見情況是：用戶端已啟用系統代理，代理伺服器指向 127.0.0.1:7890，目標應用程式則在受限的 AppContainer 沙箱中執行。應用程式嘗試連線至本機代理時，請求尚未進入 Clash 核心，就已遭 Windows 網路隔離政策阻擋。

UWP 是 Universal Windows Platform，也就是通用 Windows 平台；AppContainer 則是 Windows 的應用程式隔離機制。回環位址指向目前這台電腦，例如 IPv4 的 127.0.0.1 和 IPv6 的 ::1。回環豁免可允許指定的應用程式容器存取本機網路服務，但不代表停用整個 Windows 防火牆。

從 Microsoft Store 安裝，不代表應用程式一定是 UWP。商店也會提供一般 Win32 桌面程式和封裝式桌面應用程式。應綜合應用程式封裝、執行方式及連線記錄判斷，不能把所有「商店應用程式無法連線」都歸因於回環限制。

三種機制各自解決什麼問題

• 系統代理：提供 HTTP 代理位址給會讀取 Windows 代理設定的應用程式，不會自動接管所有程式的 TCP、UDP 流量。
• 回環豁免：允許指定的應用程式容器連線至本機代理；應用程式仍須實際使用該代理設定。
• 規則模式：流量進入 Clash 或 mihomo 後，才會依照 rules 決定直連或代理；無法排除請求進入核心前遭沙箱阻擋的問題。

因此，瀏覽器能正常連線，只能證明其中一條代理路徑可用，不能據此確認目標應用程式也能連上相同的本機連接埠。反過來說，應用程式出現在用戶端連線清單中，也不代表流量一定經過遠端節點，還要查看套用的規則與最後的出口。

處理前先檢查：連接埠、系統代理與連線記錄

先確認用戶端目前使用的本機監聽連接埠。本文以 mixed-port: 7890 為例，表示 HTTP 與 SOCKS5 共用同一個連接埠；若實際設定是 7897，後續所有位址和檢查指令都應改用實際值。請勿把外部控制器連接埠當成代理連接埠，也不要為了讓本機應用程式連線就先啟用 allow-lan。

1. 在 Windows 11 開啟「設定」→「網路和網際網路」→「Proxy」，檢查「手動設定 Proxy」中的位址和連接埠。Windows 10 的路徑為「設定」→「網路和網際網路」→「Proxy」→「使用 Proxy 伺服器」。若使用 PAC 自動設定指令碼，請檢查指令碼回傳的代理位址，不要再額外套用手動代理。
2. 確認用戶端核心已啟動、選取的節點可用，並記下目前使用規則模式或全域模式。
3. 開啟用戶端的連線清單或記錄，再讓目標應用程式執行一次明確的網路操作，例如重新整理內容。請區分「沒有連線記錄」與「有連線但失敗」。
4. 暫時只保留一種流量接管方式。排查系統代理時，先記下並關閉已啟用的 TUN，避免無法判斷實際生效的是哪條路徑。

可在 PowerShell 中檢查連接埠是否正在監聽，並直接測試 HTTP 代理。以下第二個指令只會取得示範網站的回應標頭，用來確認連接埠及基本代理連線正常，不代表目標應用程式已取得回環存取權限。

Get-NetTCPConnection -State Listen -LocalPort 7890
curl.exe --proxy http://127.0.0.1:7890 --head https://example.com/

若連接埠沒有監聽，應先排除用戶端啟動或設定問題；若明確指定代理的請求也失敗，應先檢查節點、驗證資訊及規則。此時不要反覆新增應用程式豁免，因為豁免無法讓未監聽的連接埠開始運作。

方法一：使用 CheckNetIsolation 為單一應用程式新增豁免

CheckNetIsolation.exe 是 Windows 內建的網路隔離管理工具。建議只為確實需要連線至本機代理的應用程式新增豁免，並先保存現有清單再進行修改。以下指令請在系統管理員 PowerShell 中執行；應用程式封裝查詢預設會針對目前登入的使用者，若使用另一個系統管理員帳戶提升權限，請留意查詢結果可能不是原使用者的應用程式。

第一步：查看現有豁免與應用程式封裝

CheckNetIsolation.exe LoopbackExempt -s

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

-s 用來顯示目前的豁免清單。PackageFamilyName 是封裝系列名稱，通常由封裝名稱與發行者識別碼組成；它不同於包含版本、架構等資訊的 PackageFullName。傳遞參數給 -n 時，請使用封裝系列名稱，不要直接複製應用程式顯示名稱。

第二步：精確選取封裝並新增豁免

以下以封裝名稱為 Microsoft.WindowsStore 的 Microsoft Store 本身為例。若發生問題的是其他應用程式，請先從上一步的清單確認其 Name，再替換查詢條件。應用程式是從商店下載，不代表只需為商店本身新增豁免。

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

if (@($pkg).Count -eq 1) {
    CheckNetIsolation.exe LoopbackExempt -a "-n=$($pkg.PackageFamilyName)"
} else {
    Write-Warning "找不到唯一的應用程式封裝，請先確認目前使用者與應用程式封裝名稱。"
}

CheckNetIsolation.exe LoopbackExempt -s

-a 代表新增，封裝系列名稱則緊接在 -n= 後方。指令回報成功後，請再次使用 -s 確認清單中有對應項目。接著完全關閉目標應用程式，包括仍在背景執行的處理程序，再重新啟動並觸發網路操作。僅將視窗最小化通常不夠。

第三步：必要時移除單一應用程式豁免

不再需要存取本機服務時，可使用相同的應用程式封裝變數刪除對應項目。以下指令會保留其他應用程式的設定；請勿為了移除單一應用程式的豁免而清空整份豁免清單。

$pkg = Get-AppxPackage -Name Microsoft.WindowsStore
if (@($pkg).Count -eq 1) {
    CheckNetIsolation.exe LoopbackExempt -d "-n=$($pkg.PackageFamilyName)"
}
CheckNetIsolation.exe LoopbackExempt -s

• 出現拒絕存取：確認 PowerShell 是以系統管理員身分啟動，並檢查裝置是否受組織政策管理。
• 查詢結果為空：確認封裝名稱拼寫、目前使用者及應用程式安裝狀態；該程式也可能是一般桌面應用程式，不適用這種查詢方式。
• 新增成功但仍無法連線：檢查應用程式是否使用系統代理，以及實際連線是否進入核心；不要把成功訊息當成網路已恢復。

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

部分 Windows 用戶端提供 UWP 回環豁免工具，介面名稱可能是「UWP 回環」、「Loopback」或「應用程式容器豁免」。各用戶端及版本的入口不盡相同，請以目前版本的設定頁面與說明為準；不要直接套用其他用戶端的選單路徑。

1. 在用戶端設定中尋找回環相關工具，並依提示授予系統管理員權限。若目前的用戶端沒有這項功能，使用前述系統指令即可。
2. 在清單中確認目標應用程式名稱與封裝識別碼，只勾選需要透過本機代理連線的應用程式，再執行儲存或套用。
3. 關閉並重新啟動目標應用程式，確認用戶端是否收到新的連線。
4. 必要時執行 CheckNetIsolation.exe LoopbackExempt -s，確認系統層級的豁免是否確實寫入。

這類工具通常只是將同一項系統設定包裝成圖形介面操作，不會自動提供節點、修復訂閱或變更規則。若工具只顯示處理程序名稱，沒有清楚列出目標應用程式封裝，請仔細核對，避免一併放行不相關的應用程式。

優先採用逐一授權。若選取所有應用程式，能存取本機服務的範圍就會擴大，日後也更難追查問題。應用程式解除安裝後重新安裝，或封裝識別資訊變更時，請重新確認清單，不要假設舊記錄仍然適用。

方法三：使用 mihomo TUN 接管應用程式流量

如果目標程式不會讀取系統代理設定，即使新增回環豁免，也不會強迫它使用 127.0.0.1:7890。此時可評估 TUN 模式：透過虛擬網路介面與路由，將原本直接傳往遠端的流量交由 mihomo 處理，再依規則決定出口。mihomo 是在 Clash Meta 基礎上持續發展的核心；用戶端是否支援 TUN，仍取決於其整合的核心與系統服務。

在 Windows 啟用 TUN 通常需要系統管理員權限，或由用戶端預先安裝並啟動的服務。建議先使用用戶端提供的開關完成設定，確認是否成功建立介面、設定路由並啟動 DNS 處理。若不了解現有設定，請勿直接以整份設定檔取代訂閱內容。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

這是 mihomo 的 TUN 設定片段，並非可直接執行的完整設定。auto-route 用來設定路由，auto-detect-interface 用來自動識別出口介面；dns-hijack 會將符合條件的一般 DNS 請求交由核心 DNS 模組處理，還需要搭配有效的 dns 設定。此處的 any:53 不代表接管所有 DoH 或 DoT 加密 DNS。

測試 TUN 時，避免再次遇到原本的回環限制

如果應用程式仍會讀取系統代理並主動連線至本機回環位址，啟用 TUN 不代表一定能繞過遭沙箱阻擋的連線。測試 TUN 時，可先記下原本的系統代理設定，再暫時關閉系統代理，讓應用程式嘗試直接連線遠端並交由 TUN 接管；接著將應用程式完全關閉後重新啟動，查看實際連線情況。確實需要明確連線至本機代理的應用程式，仍可能需要回環豁免。

• 先確認一般網頁與目標應用程式都能連線，再檢查各自套用的規則，避免雖有連線卻意外走直連。
• 若同時執行其他 VPN、虛擬網卡或企業安全軟體，請檢查預設路由與介面是否衝突，不要一次啟用多種全域流量接管方案。
• 若發生網域名稱解析失敗，請另外排查 DNS；啟用 TUN 不會自動確保所有 DNS 上游都能連線。
• 測試完成後，請還原預計使用的系統代理設定，並檢查新路由是否影響區域網路、印表機或企業內網。

三種處理方式的適用範圍

若只有一個應用程式發生問題，請優先確認封裝識別資訊並測試單項豁免，影響範圍較小。若有多個不遵循系統代理的程式都需要接管，再評估 TUN。企業裝置也應遵守裝置管理政策，不應以關閉防火牆或移除安全政策取代問題排查。

新增豁免後仍無法連線：排查順序

1. 先確認核心是否收到請求：若沒有記錄，請檢查應用程式的代理使用方式、是否重新啟動、封裝識別資訊及 TUN 路由。請注意，記錄篩選條件可能會隱藏部分項目。
2. 再檢查套用的規則：若連線顯示 DIRECT，表示目前規則選擇直連；應確認目標網域及規則順序，而非繼續新增豁免。
3. 接著檢查出口與通訊協定：登入、圖片與媒體內容可能使用不同網域；部分功能也會使用 UDP。瀏覽器能開啟首頁，不代表應用程式所需的所有服務都能連線。
4. 最後確認是帳戶還是網路問題：登入權杖過期、系統時間錯誤、服務區域限制及伺服器故障，都可能造成連線失敗。請勿因此匯入來源不明的憑證或停用憑證驗證。

每次只修改一項設定，並記錄修改前後的狀態：本機連接埠、系統代理、豁免清單、TUN 開關及套用的規則。判斷問題是否解決，應以目標應用程式功能正常且連線路徑符合預期為準，而不只是指令執行成功。若要重新整理設定檔匯入與規則模式，可參閱入門指南；若要挑選支援所需接管方式的用戶端，請依平台查看下載頁面。