先確認問題是否源自 UWP 回環限制

典型情況是：Clash 已啟動，瀏覽器可以正常存取網站，傳統桌面程式也能使用代理，但 Microsoft Store、舊版郵件、相片、Xbox，以及部分從商店安裝的應用程式仍會直接連線、載入逾時或顯示網路無法使用。此時代理節點和訂閱通常沒有問題，差異在於 Windows 對 AppContainer 應用程式的網路隔離規則。

多數 Clash 圖形客戶端開啟「系統代理」後，會將 Windows 代理伺服器設定為本機位址，例如 HTTP 代理 127.0.0.1:7890，或 mixed-port 對應的相同連接埠。一般 Win32 程式可以連線至這個本機監聽位址，但受 AppContainer 隔離的 UWP 應用程式預設無法任意存取本機回環介面，因此請求無法送達 Clash 核心。

用四項檢查縮小範圍

  1. 在 Clash 客戶端確認目前設定已啟用，並選擇可正常連線的策略。
  2. 開啟「設定」或「一般」，確認「系統代理」已開啟。
  3. 在 Windows「設定」→「網路和網際網路」→「代理」中，確認代理位址為 127.0.0.1，連接埠與 Clash 目前監聽的連接埠一致。
  4. 分別測試桌面瀏覽器和目標商店應用程式。瀏覽器正常、目標應用程式失敗，才符合回環隔離的常見特徵。

連接埠不一定固定為 7890。採用 mihomo 核心的客戶端可能使用 mixed-port: 7890，也可能由使用者改為 7891、7897 或其他未被占用的連接埠。診斷時應以目前設定和客戶端設定頁顯示的連接埠為準。

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

部分 Windows 圖形客戶端整合了回環豁免管理器。這種方式適合不熟悉套件族名稱和命令列的使用者。工具本質上仍是在修改 Windows 的 AppContainer 回環豁免清單；客戶端退出後，已寫入系統的規則通常不會立即消失。

常見入口與操作順序

不同客戶端的選單名稱略有差異。經典版 Clash for Windows 常見入口為「General」→「UWP Loopback」→「Launch Helper」；其他客戶端可能放在「設定」→「系統設定」→「UWP 回環」或「網路工具」中。操作時請依照以下順序執行：

  1. 先關閉正在測試的 UWP 應用程式，避免舊連線和快取干擾結果。
  2. 以正常方式啟動 Clash 客戶端，並載入有效設定。
  3. 進入 UWP Loopback 或回環豁免工具。如果 Windows 跳出權限確認，請核對程式來源後允許這次管理操作。
  4. 在應用程式清單中找到目標程式，例如 Microsoft Store、Xbox 或指定的商店應用程式。
  5. 勾選目標程式，然後選擇「Save Changes」、「儲存變更」或具有相同功能的按鈕。
  6. 返回客戶端，確認系統代理仍然開啟，再重新啟動目標應用程式。

清單中找不到目標應用程式時

  • 請先至少啟動目標應用程式一次。部分套件完成註冊後才會出現在清單中。
  • 確認應用程式確實來自 Microsoft Store，或是以 AppX、MSIX 套件形式安裝。一般 Win32 程式不需要 UWP 回環豁免。
  • 重新啟動回環工具，讓它重新讀取已註冊的套件。
  • 仍然無法識別時，請改用後文的 PowerShell 與 CheckNetIsolation 方法。

某些新版應用程式雖然從 Microsoft Store 安裝，內部仍可能執行一般桌面程序；另一些程式則同時包含桌面程序和 AppContainer 元件。因此「來自商店」不代表一定受到回環限制，應結合實際程序和測試結果判斷。

方法二：使用 CheckNetIsolation 精確新增豁免

CheckNetIsolation.exe 是 Windows 內建的網路隔離管理工具，可以列出、新增和刪除 AppContainer 回環豁免。指令需要目標應用程式的 Package Family Name，簡稱 PFN。PFN 不是開始功能表顯示的名稱，也不是安裝目錄名稱。

第一步：查找應用程式的 Package Family Name

以滑鼠右鍵按一下開始按鈕，開啟「終端機系統管理員」或「Windows PowerShell 系統管理員」，先依應用程式名稱篩選已安裝套件。以下範例會查找名稱中包含 Xbox 的套件：

Get-AppxPackage *Xbox* | Select-Object Name, PackageFamilyName

如果不知道套件名稱，可以列出目前使用者的所有 AppX 套件，再在終端機中搜尋目標名稱：

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

輸出通常包含兩欄。需要複製的是 PackageFamilyName 的完整值，例如由名稱與發行者識別碼組合而成的一長串字元。不要複製 PackageFullName，後者通常還包含版本號碼、架構和資源標記。

第二步：新增回環豁免

將以下指令中的範例 PFN 替換為實際查詢結果。參數 -a 表示新增，-n 後面接套件族名稱：

CheckNetIsolation LoopbackExempt -a -n="目標應用程式的PackageFamilyName"

指令執行成功後通常會顯示完成提示。接著列出目前的豁免項目，確認目標套件已寫入：

CheckNetIsolation LoopbackExempt -s

如果清單很長，可以先將結果輸出至文字檔，再搜尋套件族名稱：

CheckNetIsolation LoopbackExempt -s > "$env:TEMP\loopback-list.txt"
notepad "$env:TEMP\loopback-list.txt"

第三步：必要時刪除豁免

應用程式不再需要連線至本機代理，或是新增了錯誤的套件族名稱時，可以使用 -d 刪除對應項目：

CheckNetIsolation LoopbackExempt -d -n="目標應用程式的PackageFamilyName"

刪除後再次執行 CheckNetIsolation LoopbackExempt -s，確認該項目已從清單中移除。修改豁免通常不需要重新啟動 Windows，但應完全退出並重新開啟目標應用程式，讓它建立新的連線。

驗證請求是否確實進入 Clash

應用程式恢復網路連線不代表請求一定經過目前的代理。驗證時應同時觀察應用程式表現、Clash 連線記錄和系統代理狀態，避免將快取內容誤判為修復成功。

驗證一：查看 Clash 連線記錄

  1. 在客戶端進入「連線」、「Connections」或具有相同功能的頁面。
  2. 清除現有記錄，或記住目前時間。
  3. 完全關閉目標 UWP 應用程式，再重新開啟並觸發一次網路請求。
  4. 檢查是否出現與該應用程式存取網域相對應的新連線。
  5. 查看連線命中的規則、策略組和最終節點，確認結果符合設定預期。

如果連線頁出現目標網域，表示請求已抵達 Clash 核心。若連線存在但仍無法開啟，應繼續檢查規則命中、DNS 解析和節點連通性，而不是反覆新增回環豁免。

驗證二：比較系統代理開關

讓目標應用程式保持完全退出狀態，開啟 Clash 系統代理後測試一次，再關閉系統代理測試一次。如果開啟時出現連線記錄、關閉時消失，且應用程式的網路行為同步改變，表示連線關係相當明確。測試完成後恢復原本的代理設定。

驗證三：檢查本機監聽連接埠

在 PowerShell 中確認 Clash 是否監聽預期的連接埠。假設 mixed-port 為 7890，可以執行：

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

正常結果應顯示連接埠處於 Listen 狀態。若沒有結果，表示核心未監聽該連接埠，或客戶端使用了其他連接埠。此時即使回環豁免正確，UWP 應用程式也無法連線至代理。

新增豁免後仍然無效的排查順序

1. 系統代理連接埠與 Clash 監聽連接埠不一致

這是最常見的後續問題。例如設定寫著 mixed-port: 7897，Windows 代理仍指向 127.0.0.1:7890。應在客戶端「設定」→「參數設定」中確認混合連接埠，再到 Windows「設定」→「網路和網際網路」→「代理」核對位址與連接埠。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

allow-lan 控制區域網路裝置是否能夠連線至 Clash 監聽的連接埠，並不是解決本機 UWP 回環限制的開關。僅為處理本機應用程式而將它改為 true，通常沒有必要。

2. 目標應用程式使用了不同的套件

同一產品可能存在正式版、測試版、遊戲服務元件和獨立登入元件。為主程式新增豁免後，實際發起請求的可能是另一個 AppX 套件。重新執行 Get-AppxPackage，依產品名稱檢查相關套件，並結合 Clash 記錄逐項驗證。

3. 應用程式程序沒有完全退出

按一下視窗關閉按鈕後，應用程式可能仍在背景執行。可以在「工作管理員」→「處理程序」中結束對應工作，等待 5 秒後重新啟動。必要時登出目前的 Windows 使用者工作階段，讓 AppContainer 網路狀態重新建立。

4. 規則將請求直接連線

回環修復只負責讓請求抵達 Clash，不會改變規則結果。如果連線頁顯示 DIRECT，表示網域或 IP 命中了直連規則。應檢查設定中的網域規則、規則集順序和最終匹配項，不要將回環問題與代理規則問題混為一談。

5. DNS 或 TUN 模式造成第二層問題

開啟 TUN 模式後，部分客戶端會接管更多系統流量，但 UWP 應用程式的實際行為仍取決於客戶端實作、Windows 網路堆疊與目前設定。若系統代理模式已恢復正常，再切換至 TUN 進行比較。不要同時修改回環、DNS、TUN 和規則，否則很難判斷是哪項變更生效。

回環豁免、系統代理與 TUN 的關係

這三個概念位於不同層次。系統代理會告訴支援代理設定的程式，將 HTTP 或 HTTPS 請求交給本機連接埠；回環豁免允許受隔離的 AppContainer 存取這個本機連接埠；TUN 模式則透過虛擬網路介面接管更廣泛的 IP 流量。

  • 系統代理：適合瀏覽器和遵循 Windows 代理設定的應用程式，常見目標為 127.0.0.1:7890。
  • UWP 回環豁免：解決 AppContainer 無法存取本機代理監聽位址的問題，不負責選擇節點或修改規則。
  • TUN 模式：適合不讀取系統代理的程式和更複雜的流量接管情境，通常需要驅動程式、服務或系統管理員權限支援。

如果只有一兩個 UWP 應用程式無法使用已開啟的系統代理，請優先新增精確的回環豁免，改動範圍較清楚。如果大量不支援系統代理的程式都需要接管，再評估 TUN 模式。切換模式前應保留目前可用的設定，記錄 mixed-port、DNS 與規則模式，以便恢復。

處理結果檢查表

  • Clash 核心已啟動，設定檔沒有載入錯誤。
  • 目前節點可用，桌面瀏覽器能透過相同設定存取網路。
  • Windows 系統代理位址與 mixed-port 完全一致。
  • 目標 UWP 應用程式對應的 Package Family Name 已加入回環豁免。
  • 應用程式已完全退出並重新啟動，不再重用舊連線。
  • Clash 連線頁可以看到目標應用程式觸發的網域請求。
  • 連線命中的規則和策略符合預期，沒有被錯誤分配至 DIRECT。
  • 測試結束後，只保留實際需要的回環豁免項目。

完成以上檢查後，可以明確區分三類故障：應用程式無法連線至本機代理、請求已進入 Clash 但規則選擇錯誤，以及節點或 DNS 本身不可用。依照連線路徑逐段驗證，比反覆切換節點或重新安裝客戶端更容易找出原因。