Windows UWP 應用程式無法連線代理伺服器：解除回環限制與驗證步驟

先確認是否為 UWP 回環問題

不要看到「商店打不開」就直接修改回環豁免。Microsoft Store、郵件、部分媒體應用程式與其他商店應用程式無法連線，可能是系統代理伺服器未啟用、Clash 核心未執行、規則錯誤、DNS 失敗、帳戶服務異常或 Windows 服務狀態異常所致。回環限制只解釋一種特定現象：應用程式需要透過本機代理伺服器連線，但 AppContainer 阻止其存取這個本機監聽位址。

最具代表性的故障組合是：傳統桌面瀏覽器可以透過 Clash 正常存取；Clash 的系統代理伺服器開關已啟用；目標 UWP 應用程式直接顯示無網路、持續載入或連線失敗；關閉系統代理伺服器後，該應用程式可能恢復直連，也可能因網路環境而繼續失敗。此時應先記錄目前模式、代理連接埠與應用程式名稱，再進行針對性處理。

建議依照以下順序建立基準狀態

1. 確認 Clash 用戶端顯示核心正在執行，而不只是介面程序處於開啟狀態。
2. 使用一般桌面瀏覽器存取可用網站，確認系統代理伺服器連線至少對 Win32 應用程式有效。
3. 在 Clash 連線記錄中搜尋目標網域，觀察啟動 UWP 應用程式時是否產生新的連線。
4. 記錄用戶端設定中的 HTTP 連接埠或混合連接埠，並確認系統代理伺服器實際指向相同連接埠。
5. 完全結束目標應用程式後重新開啟，避免背景程序繼續重用修改前的連線。

如果啟動目標應用程式時，Clash 連線清單完全沒有相關請求，而瀏覽器請求可以正常出現，回環限制就是優先檢查項目。反之，如果請求已進入 Clash，並明確顯示規則命中、DNS 錯誤或節點連線失敗，表示流量已越過 AppContainer 抵達本機代理伺服器，問題應轉向規則、DNS 或上游節點。

為什麼系統代理伺服器正常，UWP 應用程式仍然失敗

Clash 或 mihomo 在 Windows 上執行時，通常會監聽本機連接埠。例如混合連接埠可能監聽於 127.0.0.1:7890，同時接受 HTTP 與 SOCKS 協定；某些用戶端也會分別設定 HTTP 與 SOCKS 連接埠。啟用系統代理伺服器後，Windows 會將代理伺服器位址寫入目前使用者的網路設定，使用該設定的應用程式接著會把請求傳送至本機 Clash 連接埠。

對一般桌面程式而言，存取 127.0.0.1 是常見的本機通訊。UWP 應用程式及部分封裝應用程式則可能在 AppContainer 沙盒中執行。AppContainer 對網路能力與本機回環存取設有限制，目的是避免隔離應用程式任意連線同一台裝置上的其他服務。結果是：應用程式雖然讀取到系統代理伺服器位址，卻無法連線該位址，網路請求在抵達 Clash 核心前就已失敗。

回環豁免並不是把應用程式本身改成「強制代理伺服器」，它只允許指定的 AppContainer 存取本機回環介面。應用程式是否讀取系統代理伺服器、是否繞過代理伺服器、是否使用 UDP 或 QUIC，仍由應用程式實作與 Windows 網路堆疊決定。因此，加入豁免後仍需透過連線記錄驗證流量路徑，不能只看應用程式介面是否短暫恢復。

解除目標應用程式的回環限制

部分 Clash Windows 用戶端會提供「UWP 回環」、「Loopback」或「解除回環限制」入口。此入口通常會呼叫 Windows 的回環豁免機制，並顯示已安裝的 AppContainer 應用程式清單。優先只選擇確實需要透過本機代理伺服器連線的應用程式，例如發生問題的 Microsoft Store 或特定商店應用程式；未確認範圍前，不建議一次勾選所有項目。

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

1. 以正常方式啟動 Clash 用戶端，並確認核心已成功載入設定。
2. 開啟設定、一般設定或服務工具區域，尋找名稱包含 UWP、Loopback 或「回環」的入口。
3. 在應用程式清單中找到目標程式。清單可能顯示應用程式名稱、套件名稱或套件系列名稱，請注意區分相似項目。
4. 勾選目標程式並儲存，讓 Windows 為對應套件加入回環豁免。
5. 關閉目標應用程式的所有視窗，並在工作管理員中確認其背景程序已結束，然後重新啟動應用程式。

不同用戶端的選單位置並不一致，有些新式用戶端沒有整合圖形化回環工具。沒有入口不代表 mihomo 核心缺少代理伺服器功能，因為回環限制屬於 Windows AppContainer 原則，而不是 Clash 規則引擎中的選項。在這種情況下，可以使用 Windows 內建命令進行檢查與修改。

方法二：使用 PowerShell 查找套件系列名稱

先開啟 PowerShell，依應用程式顯示名稱或套件名稱查找對應的 PackageFamilyName。以下命令會列出目前使用者安裝的應用程式套件及套件系列名稱：

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

如果清單很長，可以依關鍵字篩選。例如查找名稱包含 Store 的應用程式：

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

找到正確的套件系列名稱後，在終端機中執行加入回環豁免的命令。請將範例值替換為查詢到的實際 PackageFamilyName：

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

命令中的 -a 表示加入，-n 後面必須是套件系列名稱，而不是開始功能表顯示的名稱，也不是安裝目錄名稱。名稱輸入錯誤時，命令可能失敗，或修改到非預期的套件。執行前應從 PowerShell 輸出複製完整值。

檢視與撤銷現有豁免

若要檢視目前的回環豁免清單，可以執行：

CheckNetIsolation.exe LoopbackExempt -s

測試結束後若不再需要某項豁免，可使用刪除命令恢復該應用程式的預設限制：

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

從本機連接埠到規則命中的完整驗證

加入豁免只是修改權限，驗證時仍需逐層確認。建議暫時讓 Clash 以規則模式執行，因為規則模式能在連線記錄中顯示網域、目標位址、命中規則與策略群組，比全域模式更適合判斷請求是否依預期分流。

第一步：核對監聽連接埠

在 Clash 用戶端中查看目前的混合連接埠或 HTTP 連接埠，再檢查 Windows 系統代理伺服器。兩者的連接埠必須一致。例如用戶端監聽 127.0.0.1:7890，但系統代理伺服器仍殘留為 127.0.0.1:7897，所有讀取系統代理伺服器的應用程式都會連線到錯誤位置。切換不同 Clash 用戶端後，這類連接埠殘留尤其常見。

還要確認設定中的監聽位址沒有被改成只適用於其他介面的值。僅供本機應用程式使用時，監聽回環位址通常已足夠；區域網路共用涉及 allow-lan、監聽位址與防火牆，是另一條設定路徑，不應為了修復單機 UWP 應用程式而直接開放區域網路存取。

第二步：重新啟動目標應用程式

不少 UWP 應用程式關閉視窗後仍會保留背景工作。修改回環豁免後，應從工作管理員結束對應程序，或登出目前的 Windows 使用者再重新登入。若應用程式仍重用舊連線，可能誤判為「設定已加入但沒有生效」。

第三步：觀察 Clash 連線與記錄

重新開啟應用程式並觸發一次明確的網路操作，例如重新整理頁面、檢查更新或載入帳戶資訊。接著查看 Clash 的連線清單：

• 出現目標網域且資料傳輸成功，表示回環、本機連接埠與代理伺服器入口已連通。
• 出現網域但規則命中錯誤，應調整規則順序、規則集引用或策略群組選擇。
• 出現連線但節點交握失敗，應測試策略群組中的其他可用節點。
• 完全沒有請求，應繼續確認應用程式是否使用系統代理伺服器、豁免對象是否選取正確，以及應用程式是否使用不受該代理伺服器入口處理的協定。

第四步：進行一組開關對照測試

維持其他條件不變，分別測試「系統代理伺服器開啟」與「系統代理伺服器關閉」。如果開啟時應用程式失敗、關閉後直連正常，而且 Clash 中始終沒有該應用程式的請求，通常仍是本機代理伺服器入口或回環權限問題。如果兩種狀態都失敗，則應檢查應用程式服務、Windows 網路、帳戶狀態與 DNS，而不是繼續重複加入豁免。

解除回環後仍無法連線的排查順序

如果目標應用程式已出現在豁免清單中，但仍無法正常連線網路，應從代理伺服器入口繼續向後檢查。以下問題與回環限制的表現相近，卻需要不同的處理方式。

系統代理伺服器位址或連接埠殘留

Windows 系統代理伺服器可能保留上一個用戶端的連接埠，尤其是在用戶端異常結束、切換免安裝版與安裝版，或交替使用多個代理工具之後。先關閉其他代理軟體，再讓目前的 Clash 用戶端重新設定一次系統代理伺服器。不要只根據用戶端按鈕狀態判斷，應核對 Windows 中實際儲存的代理伺服器位址。

應用程式沒有使用系統代理伺服器

並非所有應用程式都遵循目前使用者的系統代理伺服器設定。有些程式自行實作網路堆疊，有些連線使用 UDP 或 QUIC，有些背景元件則透過不同的服務程序發起請求。此時即使回環豁免正確，HTTP 系統代理伺服器也未必能接管所有流量。可以測試 mihomo 的 TUN 模式，但啟用前應確認用戶端具備所需權限、虛擬網卡元件可用，並了解 DNS 接管與路由變更。

TUN 模式會從網路層接管流量，與「讓應用程式主動連線 127.0.0.1 系統代理伺服器」並非相同機制。它常用於不讀取系統代理伺服器的應用程式，但不保證能修復所有 UWP 問題。若啟用 TUN 後仍然沒有請求，應檢查路由排除、介面衝突、安全軟體原則與應用程式本身的服務狀態。

規則將必要請求分配到錯誤的策略

Microsoft Store 等應用程式可能同時存取內容傳遞、帳戶、憑證與更新服務。只看到主網域成功，不代表所有相依請求都正常。檢查連線記錄中失敗或反覆重試的網域，確認規則由上至下的比對順序。Clash 命中一條規則後不會繼續檢查後續規則，因此過於寬泛的前置規則可能覆蓋後面的精確規則。

排查期間可以暫時切換到已確認可用的策略群組進行對照，但不建議長期直接使用全域代理伺服器來掩蓋規則問題。確認具體網域與失敗原因後，再將修正內容寫入規則設定，並保留最終的兜底規則。

DNS 解析與代理伺服器連線屬於不同階段

如果記錄顯示網域解析失敗、回傳異常位址或持續逾時，應檢查目前設定中的 dns 區段、解析伺服器可達性與 Clash DNS 監聽狀態。使用 fake-ip 時，還要確認應用程式是否對虛擬位址或特定網域有相容性要求。不要因為症狀出現在 UWP 應用程式中，就跳過 DNS 層的檢查。

連接埠衝突與核心未成功載入

用戶端介面可以開啟，不代表代理伺服器連接埠已在監聽。設定語法錯誤、連接埠被佔用或核心啟動失敗時，系統代理伺服器仍可能指向沒有服務的位址。查看用戶端記錄中的設定載入結果與監聽錯誤，必要時更換未被佔用的連接埠，並同步更新系統代理伺服器。

企業原則或受管理裝置限制

公司裝置、學校裝置與啟用集中管理原則的 Windows 環境，可能透過群組原則、防火牆或端點防護限制 AppContainer、本機代理伺服器與網路介面。命令回傳成功也不代表原則不會隨後覆寫設定。此類環境應先確認裝置管理要求，不要持續修改受集中控制的設定。

恢復測試清單

完成修改後，可以依照以下清單進行最後確認。每個項目都能對應明確的層級，方便日後重現與復原。

• Clash 或 mihomo 核心啟動成功，目前設定沒有解析錯誤。
• 本機 HTTP 或混合連接埠處於監聽狀態，連接埠未被其他程式佔用。
• Windows 系統代理伺服器位址與目前用戶端連接埠一致。
• 目標 UWP 應用程式對應的套件系列名稱已加入回環豁免清單。
• 修改後已完全結束並重新啟動目標應用程式。
• 在 Clash 連線記錄中可以看到應用程式產生的網域或目標位址。
• 請求命中預期規則與策略群組，上游節點能正常建立連線。
• DNS 查詢沒有持續逾時，解析結果符合目前的設定模式。
• 測試完成後撤銷不再需要的臨時變更，並記錄最終有效設定。

判斷修復成功的標準不只是「頁面能開啟」，而是目標請求穩定進入 Clash、命中預期規則並完成傳輸。透過這種分層驗證，可以區分 AppContainer 權限、本機代理伺服器連接埠、規則、DNS 與節點問題，避免反覆操作同一項設定。