---

現象:普通應用能代理,商店應用連不上

在 Windows 上開啟 Clash 或 mihomo 核心的系統代理、甚至開了 TUN 模式之後,大多數桌面應用(瀏覽器、命令列工具、傳統 exe 程式)都能正常走代理規則出站。但一部分從 Microsoft Store 安裝的應用——比如某些郵件客戶端、部分瀏覽器的商店版、跨平台聊天工具的 UWP 封裝版——卻表現出典型的「代理對它不生效」症狀:直連能上的網站它能上,需要走代理才能存取的位址一律逾時或提示網路錯誤,即使系統代理設定裡已經正確填入了本機連接埠。

這類問題的排查很容易走偏。很多人第一反應是懷疑訂閱節點失效、核心崩潰或者規則寫錯,反覆重啟客戶端、重新匯入訂閱,結果毫無效果。原因很簡單:問題根本不在代理服務這一側,而在 Windows 系統對 UWP(Universal Windows Platform)應用的網路存取做了一層獨立於一般行程的隔離限制,這層限制預設會切斷 UWP 應用與 127.0.0.1 / localhost 的回環通訊,而絕大多數本機代理客戶端(包括 Clash 系核心)恰好是透過監聽本機回環位址對外提供 HTTP/SOCKS5 代理連接埠的。

原理:UWP 沙箱與回環通訊隔離

要理解這個限制,得先知道 UWP 應用的運作方式與傳統 Win32 程式完全不同。UWP 應用運行在一個被稱為 AppContainer 的沙箱環境裡,微軟為每個 UWP 應用分配一個獨立的安全識別碼(SID),並透過網路隔離(Network Isolation)機制嚴格控制它能存取哪些網路資源。這套機制的設計初衷是安全:防止商店應用未經聲明就隨意存取區域網路或者本機其他行程開放的連接埠,降低橫向滲透與資訊洩露的風險。

網路隔離策略裡有一條關鍵規則:UWP 應用預設禁止存取運行在同一台機器上、以回環位址(loopback,即 127.0.0.1 或 ::1)方式監聽的服務,除非該服務本身也是打包成 UWP 應用運行的。這就解釋了為什麼問題只出現在商店應用上——傳統桌面程式不受 AppContainer 約束,可以隨意連接本機任意連接埠;而 UWP 應用即便系統代理設定全域生效,它發出的每一次連線請求在到達網路層之前就會先在這層隔離檢查中被拒絕,連接對象是 127.0.0.1:7890 這類本機代理連接埠時表現得尤為明顯。

值得注意的是,這個限制與代理軟體本身是否開啟「允許區域網路連線」或者監聽位址填 0.0.0.0 還是 127.0.0.1 關係不大——即便代理監聽在所有網卡上,UWP 應用發起的回環請求依然會被系統級的隔離策略攔下,這是作業系統層面的行為,客戶端設定檔裡沒有任何選項能繞開它。

先確認:是不是回環限制在作怪

動手解除限制之前,建議先做兩步簡單驗證,避免誤判:

1. 確認受影響的是不是商店應用。右鍵點擊開始功能表裡的應用圖示,如果「解除安裝」之外還能看到「進階選項」這一項,通常說明它是 UWP 應用;傳統 Win32 程式一般直接是解除安裝入口。也可以在設定的「應用程式和功能」清單裡查看來源標註。
2. 確認代理服務本身工作正常。用瀏覽器或命令列工具手動測試同一個代理連接埠是否可用,比如用 curl 指定代理存取一個需要代理才能開啟的位址,如果這類傳統程式都能正常出站,基本可以排除代理設定或節點本身的問題,問題指向就集中在 UWP 網路隔離上。

兩步都對上號,基本可以確定就是回環限制導致的連線失敗,接下來只需要為這個具體的 UWP 應用單獨開啟回環豁免。

路徑一:CheckNetIsolation 命令列解除

Windows 系統自帶一個命令列工具 CheckNetIsolation.exe,專門用於管理 AppContainer 的網路隔離白名單,這是官方提供的標準解決方式,不需要安裝任何額外軟體。

第一步:找到應用的 Package Family Name

以系統管理員身份開啟 PowerShell,執行以下命令列出當前系統安裝的所有 UWP 應用及其套件名稱:

Get-AppxPackage | Select-Object Name, PackageFamilyName

在返回清單裡找到目標應用對應的條目,記下它的 PackageFamilyName 欄位,格式類似 12345Publisher.AppName_abcdefghijk1m,這一串字元是後續命令必須的精確標識,不能用應用的顯示名稱代替。

第二步:新增回環豁免

關閉 PowerShell,改用系統管理員權限開啟命令提示字元(cmd),執行:

CheckNetIsolation.exe LoopbackExempt -a -n="12345Publisher.AppName_abcdefghijk1m"

命令執行後沒有報錯即代表新增成功,不會有額外的成功提示彈窗。這條命令的效果是把指定應用加入回環豁免名單,允許它此後正常存取本機 127.0.0.1 上監聽的服務,包括代理客戶端開放的 HTTP/SOCKS5 連接埠。

查看與撤銷

如果要確認目前已經豁免的應用清單,執行:

CheckNetIsolation.exe LoopbackExempt -s

如果後續需要撤銷某個應用的豁免(比如排查其他問題時想恢復預設隔離狀態),把參數 -a 換成 -d 即可:

CheckNetIsolation.exe LoopbackExempt -d -n="12345Publisher.AppName_abcdefghijk1m"

需要提醒的是,這個豁免名單不會跨裝置同步,也不會在應用解除安裝重裝後自動保留,重裝後需要重新執行一次新增命令。

路徑二:圖形化工具操作

如果不習慣打命令、擔心套件名稱抄錯,也可以用圖形介面工具完成同樣的操作。微軟社群裡流傳較廣的 EnableLoopback 是一個開源小工具,本質上是給 CheckNetIsolation.exe 套了一層介面,不涉及底層機制的更改,操作邏輯與命令列完全一致:

1. 以系統管理員身份執行該工具,程式啟動後會自動讀取目前系統已安裝的全部 UWP 應用清單,並標註出各自目前的回環豁免狀態。
2. 在清單裡勾選需要解除限制的應用(可以多選,批量處理多個受影響的商店應用),點擊「Modify」套用變更。
3. 工具執行的操作與手動打命令完全等效,勾選即新增豁免,取消勾選即撤銷豁免,無需記憶或複製套件名稱。

對於需要頻繁調整豁免狀態、或者一次性要處理多個應用的場景,圖形工具比反覆打命令列更省事;但如果只是臨時解決單個應用的問題,直接用命令列往往更快,不需要額外下載安裝第三方工具。

解除後如何驗證生效

完成豁免設定後,建議按以下順序驗證,不要只憑「應用開啟變快了」這種主觀感覺判斷:

• 完全關閉再重新開啟應用。UWP 應用的網路會話通常在啟動時就已建立,豁免設定在應用執行期間往往不會立即熱生效,必須完整退出行程後重新啟動才會按新的隔離策略走。
• 存取一個明確需要代理才能開啟的位址。避免用應用首頁這種可能有本機快取的內容來判斷,選擇一個必須連網即時載入、且明確處於代理規則分流範圍內的功能來測試。
• 回頭檢查代理客戶端的連線記錄或活動連線面板。如果客戶端介面能看到該應用發起的連線記錄,說明流量確實已經進入代理鏈路;如果記錄裡完全沒有出現相關記錄,說明豁免沒有生效,需要回頭確認套件名稱是否抄錯、命令是否以系統管理員權限執行。

另外提一點容易被忽略的細節:部分 UWP 應用即便解除了回環隔離,仍然可能因為自身的「網路功能聲明」(Capability)裡沒有聲明專用網路存取權限而受限,這種情況一般出現在企業定制發佈的應用上,一般商店應用較少遇到,如果解除隔離後依然無效,可以在應用清單權限裡進一步確認。

規避回環限制的其他思路

如果不想逐個應用去解除隔離,或者受影響的應用數量較多、頻繁變動,還有兩條思路可以從根源上繞開這個限制:

切換到 TUN 模式

如前文提到的,回環限制針對的是應用主動連接本機代理連接埠這種存取方式。如果客戶端支援 TUN 模式,啟用後會在系統裡建立一個虛擬網卡,所有行程(包括受隔離約束的 UWP 應用)的流量都會在網卡層被統一接管轉發,不再依賴應用自己去連接 127.0.0.1 上的代理連接埠,自然也就不受回環隔離策略影響。對於經常遇到商店應用連線問題的使用者,直接切到 TUN 模式往往比逐個加白名單更省心。

調整監聽位址與防火牆規則配合系統代理

部分場景下也可以考慮把系統代理的作用範圍調整為覆蓋更底層的網路設定,但這類調整通常伴隨其他相容性代價,不如前兩條路徑直接,一般不作為首選方案,僅在 TUN 模式與逐應用豁免都不適用的特殊環境下再考慮。

---

回環限制是 Windows 系統層面的安全設計,不是代理客戶端的缺陷,理解這一點能省去大量無意義的排查時間。遇到「只有商店應用連不上代理」這種特徵明顯的問題,直接按套件名稱走 CheckNetIsolation 命令或圖形工具解除豁免,通常幾分鐘內就能解決;如果應用數量多或者不想維護白名單,切換到 TUN 模式是更省心的長期方案。