Windows 上常見的一種代理故障是:瀏覽器與傳統桌面軟體都能正常透過 Clash 連線,從 Microsoft Store 安裝的某個應用程式卻持續顯示離線、登入失敗或無法重新整理內容。此時訂閱節點通常沒有問題,規則也不一定設定錯誤。真正的差異可能在於 UWP 應用程式採用的 AppContainer 網路隔離機制,以及 Clash 的本機代理監聽位於回圈位址這項特性。

Clash、Clash Meta 或 mihomo 圖形化用戶端啟用系統代理後,通常會讓 Windows 將 HTTP 與 HTTPS 請求交給本機監聽位址,例如 127.0.0.1:7890。傳統 Win32 應用程式可以連線至這個位址,但受 AppContainer 約束的商店應用程式可能無法存取本機回圈介面。結果是同一套系統代理設定對桌面程式有效,對特定 UWP 應用程式卻不起作用。

為什麼回圈限制只會影響部分 Windows 應用程式

回圈位址指向目前電腦本身。Clash 在本機啟動代理埠後,應用程式需要先連線至這個本機埠,代理核心再依據規則選擇 DIRECT、REJECT 或某個代理策略組。對應用程式而言,第一段連線並不是直接存取目標網站,而是連線至本機代理服務。

UWP 應用程式及部分採用 AppContainer 隔離的元件,具有獨立的網路能力邊界。Windows 預設限制這些容器存取本機回圈介面,目的是減少隔離應用程式與本機服務之間未經授權的通訊。系統代理雖然記錄了本機代理位址,但不會自動替每個 AppContainer 應用程式開放回圈存取。因此,設定介面顯示代理已啟用,也不代表所有商店應用程式都能連線至 Clash 的監聽埠。

常見症狀

  • Microsoft Store、計算機的線上功能、天氣類應用程式或其他商店應用程式顯示無法連線。
  • Chrome、Firefox、傳統桌面用戶端等 Win32 程式可以正常存取網路。
  • 問題應用程式執行重新整理操作時,Clash 記錄中沒有出現其存取目標網域的紀錄。
  • 關閉系統代理後,應用程式可能恢復直接連線;重新啟用代理後又再次失敗。
  • 同一個應用程式在另一台已設定回圈豁免的電腦上運作正常。

並非所有從 Microsoft Store 安裝的軟體都一定受此限制。有些商店軟體其實是打包後的傳統桌面程式,另一些應用程式則會使用不同的網路元件。排查時應以應用程式的套件身分、實際記錄與連線行為為依據,而不只是看安裝來源。

修改前先檢查 Clash 監聽與系統代理

回圈豁免只能解決 AppContainer 存取本機代理埠的權限問題。若 Clash 未執行、埠號不一致,或系統代理仍指向舊埠,加入豁免後仍然無法恢復連線。建議先依照以下順序完成基本檢查。

  1. 確認核心正在執行。開啟目前使用的 Clash 圖形化用戶端,檢查設定已載入,代理節點或策略組可以完成延遲測試。
  2. 確認系統代理已啟用。用戶端中的「系統代理」開關應處於開啟狀態。若使用手動設定,Windows 代理位址應與用戶端顯示的 HTTP 或 mixed-port 一致。
  3. 確認埠號沒有被其他程序佔用。用戶端反覆啟動失敗或記錄出現監聽錯誤時,應先關閉佔用程序或更換埠號。
  4. 查看連線記錄。用正常運作的桌面瀏覽器開啟網頁,確認 Clash 記錄產生連線紀錄;接著操作故障應用程式,比較是否出現新的請求。
  5. 暫時排除規則影響。如果故障應用程式的請求已出現在記錄中,問題更可能出在規則比對、策略組、DNS 或節點,而不是回圈限制。

可以在 PowerShell 中查看目前使用者的 Internet 代理設定。此命令只用於核對,不會修改設定:

Get-ItemProperty "HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings" |
  Select-Object ProxyEnable, ProxyServer, AutoConfigURL

ProxyEnable 處於啟用狀態,且 ProxyServer 指向本機位址時,表示手動系統代理已寫入。部分用戶端可能使用 PAC 指令碼,此時也應查看 AutoConfigURL。此外,Windows 的 WinHTTP 代理與目前使用者的 Internet 代理並非同一套設定,不應只根據 netsh winhttp show proxy 的結果判斷 Clash 系統代理是否生效。

識別 UWP 應用程式的套件系列名稱

CheckNetIsolation 使用的是 Package Family Name,也就是套件系列名稱,而不是開始功能表顯示的中文名稱,也不是包含完整版本號的 Package Full Name。選錯欄位時,命令可能無法套用至目標應用程式。

使用 PowerShell 查詢

以 Windows 計算機為例,可以開啟 PowerShell 並執行:

Get-AppxPackage -Name "*WindowsCalculator*" |
  Select-Object Name, PackageFamilyName

輸出中的 PackageFamilyName 類似 Microsoft.WindowsCalculator_8wekyb3d8bbwe。不同應用程式的值各不相同,應以本機查詢結果為準。若不清楚套件名稱,可以列出目前使用者安裝的應用程式並依名稱排序:

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

應用程式數量較多時,可以用名稱片段縮小範圍。例如查找 Microsoft Store:

Get-AppxPackage -Name "*WindowsStore*" |
  Select-Object Name, PackageFamilyName

避免混淆兩種套件識別碼

欄位 用途 識別特徵
PackageFamilyName 用於回圈豁免 通常由套件名稱與發行者識別碼組成,不含版本與架構
PackageFullName 識別某個已安裝版本 通常包含版本號、CPU 架構與資源資訊
Name PowerShell 查詢與套件識別 比開始功能表顯示名稱穩定,但不能直接取代套件系列名稱

如果電腦上有多個 Windows 使用者,應在實際執行應用程式的帳戶中查詢。某些套件只安裝給特定使用者,從系統管理員帳戶查到的應用程式集合不一定與日常使用的帳戶完全相同。

使用 CheckNetIsolation 新增回圈豁免

確認目標應用程式與 Clash 的基本連線正常後,可以使用 Windows 內建的 CheckNetIsolation.exe 管理 AppContainer 回圈豁免。建議先關閉目標應用程式,再以系統管理員身分開啟 PowerShell 或 Windows 終端機。

為單一應用程式新增權限

以下 PowerShell 命令會先取得計算機套件,再將本機實際查到的套件系列名稱傳給系統工具:

$pkg = Get-AppxPackage -Name "*WindowsCalculator*"
CheckNetIsolation.exe LoopbackExempt -a -n="$($pkg.PackageFamilyName)"

若查詢回傳多個套件,不應直接批次執行。先查看每個項目的 NamePackageFamilyName,確認目標後再新增。也可以將已核對的套件系列名稱直接寫入命令:

CheckNetIsolation.exe LoopbackExempt -a -n="Microsoft.WindowsCalculator_8wekyb3d8bbwe"

命令中的 -a 代表新增,-n 後方是套件系列名稱。執行完成後,完全退出目標應用程式再重新開啟。只關閉視窗有時不足以終止背景程序,可以在工作管理員中確認應用程式已停止。

查看目前的豁免清單

CheckNetIsolation.exe LoopbackExempt -s

清單可協助確認豁免是否已寫入,也能找出過去遺留的設定。輸出格式可能較接近系統識別碼,不一定與開始功能表名稱一致,因此仍應搭配 PowerShell 查詢結果核對。

授權後驗證代理、規則與 DNS

成功新增回圈權限只代表應用程式可以嘗試連線至本機代理,並不表示後續代理鏈路一定正確。驗證時應從應用程式、Clash 記錄、規則比對與目標服務四個層面逐步確認。

  1. 重新啟動目標應用程式。再次執行登入、重新整理或載入內容的操作,觀察錯誤提示是否改變。
  2. 檢查 Clash 記錄。如果開始出現目標網域或連線紀錄,表示應用程式已能連線至本機代理埠。
  3. 查看命中的規則。確認請求進入預期的策略組,而不是被 REJECT、錯誤的網域規則或不適用的直連規則攔截。
  4. 切換可用策略。在策略組中選擇已確認可連線的節點,避免將節點故障與回圈權限問題混為一談。
  5. 檢查 DNS。若記錄顯示網域解析失敗,應檢查 Clash DNS 設定、系統 DNS、Fake IP 相容性,以及應用程式是否使用特殊解析方式。

如果連線紀錄已經出現,但應用程式仍顯示失敗,可以暫時切換至規則較簡單的設定進行比對。測試目的不是長期繞過分流,而是確認問題位於規則層還是應用程式層。測試結束後應恢復原有設定,並針對實際網域調整規則。

有些應用程式會同時存取身分驗證、內容分發、遙測或憑證狀態服務。只允許主網域不一定足夠。此時應根據記錄識別完整的請求集合,避免僅憑名稱猜測網域。對於需要直連的 Windows 服務,可以建立明確的 DIRECT 規則;需要代理的內容網域則應放入相應策略組。

系統代理與 TUN 模式的差異

系統代理依賴應用程式主動讀取 Windows 代理設定,並連線至 Clash 提供的本機 HTTP 或混合埠。UWP 回圈限制正是在這個連線階段產生影響。TUN 模式則透過虛擬網路介面接管更廣泛的流量,不遵循系統代理的部分應用程式也可能因此受到涵蓋。

但 TUN 並不是回圈問題的通用替代方案。啟用 TUN 還涉及系統管理員權限、虛擬網卡、路由、DNS 劫持、防火牆與其他 VPN 軟體的相容性。若需求只是讓少數 UWP 應用程式使用現有系統代理,新增精確的回圈豁免通常更容易驗證。若大量應用程式不讀取系統代理,且已了解路由與 DNS 設定,再考慮使用 mihomo 核心支援的 TUN 模式會更合適。

仍然無法連線時的分層排查

Clash 記錄完全沒有請求

先再次執行豁免清單命令,確認目標套件已存在。接著檢查應用程式是否屬於另一個套件、更新後是否更換了套件身分,以及目前執行的使用者是否與查詢套件資訊的使用者一致。也應確認系統代理位址確實是回圈位址,並核對應用程式是否略過系統代理。

記錄出現請求但連線逾時

這通常表示回圈階段已經通過。接下來檢查節點連通性、策略組選項、目標埠號與網路環境。可以用桌面瀏覽器存取同一項服務作為對照,但要注意瀏覽器與應用程式存取的網域集合可能不同。

記錄顯示 DIRECT 後失敗

檢查規則順序。Clash 會依照設定中的順序進行比對,較寬泛的直連規則可能先於目標規則命中。調整時應保持規則意義清楚,並確保清單末端存在合理的最終處理策略,例如由 MATCH 對應策略組。

啟用 TUN 後仍然無效

檢查 TUN 是否確實啟動、路由表是否被其他 VPN 或安全軟體改寫,以及 DNS 請求是否進入預期的解析鏈路。不要同時啟用多個會建立虛擬網卡的工具。若關閉其他網路工具後恢復正常,問題更可能是路由優先順序或驅動程式衝突。

Microsoft Store 可以瀏覽但無法下載

商店頁面載入與應用程式套件下載可能經過不同服務。此時除了查看 Clash 規則,也要確認 Windows Update、背景智慧型傳送服務與相關系統服務的狀態。回圈豁免只影響容器存取本機,不負責修復遭停用的系統服務、帳戶授權或商店快取。

撤銷回圈豁免與還原設定

當應用程式不再需要透過 Clash、已經解除安裝,或排查證明問題與回圈無關時,可以撤銷相應豁免。刪除命令中的 -d 代表移除:

$pkg = Get-AppxPackage -Name "*WindowsCalculator*"
CheckNetIsolation.exe LoopbackExempt -d -n="$($pkg.PackageFamilyName)"

也可以使用已核對的套件系列名稱:

CheckNetIsolation.exe LoopbackExempt -d -n="Microsoft.WindowsCalculator_8wekyb3d8bbwe"

撤銷後再次執行 CheckNetIsolation.exe LoopbackExempt -s,確認目標項目已從清單移除。然後重新啟動應用程式並驗證其網路行為。如果排查期間曾修改系統代理、Clash 埠號、DNS、規則模式或 TUN 開關,也應逐項還原,而不是只刪除回圈豁免。

建議保留的排查紀錄

  • 目標應用程式的名稱與 Package Family Name。
  • Clash 使用的核心、監聽埠與代理模式。
  • 新增豁免前後的記錄差異。
  • 請求命中的規則與策略組。
  • 是否啟用 TUN、其他 VPN 或網路過濾軟體。
  • 最終解決步驟與撤銷命令。

這類紀錄有助於區分「應用程式無法存取本機代理」與「代理已收到請求但後續連線失敗」。前者應重點檢查 AppContainer 與回圈權限,後者則應檢查規則、DNS、節點與目標服務。依照連線鏈路分層判斷,通常比反覆重新安裝用戶端或更換訂閱更快找出原因。