Windows 商店應用不走 Clash 代理?UWP 迴環限制解除步驟

為什麼瀏覽器能連代理,商店應用卻不行

不少用戶第一次遇到這個問題,都是同一個場景:桌面版瀏覽器、傳統 exe 軟體走代理毫無問題,延遲測速正常,規則也匹配得上,但換成從微軟商店安裝的應用——不管是聊天工具、閱讀器還是某些遊戲用戶端——一律顯示網路異常,像是代理完全沒生效。排查一輪發現系統代理設定沒錯,Clash 用戶端也在正常執行,問題就出在應用本身的運行方式上。

微軟商店裡的應用絕大多數是 UWP(Universal Windows Platform)架構,和傳統 Win32 桌面程式是兩套完全不同的運作機制。UWP 應用執行在一個叫 AppContainer 的沙盒環境裡,權限比傳統程式小得多,網路存取要靠系統預先宣告好的「能力」(Capability)才會放行,而不是像 Win32 程式那樣預設擁有整機網路權限。這套沙盒設計本意是提升安全性,但副作用是它預設禁止應用連接本機迴環位址(127.0.0.1 或 localhost)。

這一點直接卡住了 Clash 的工作方式。Clash 用戶端在本機開一個監聽埠(常見的是 7890 系統代理埠),系統層的代理設定本質上就是讓各個程式把網路請求轉發到 127.0.0.1:7890 這個迴環位址上。Win32 程式天生可以存取迴環位址,所以瀏覽器、聊天軟體都能順利轉發。UWP 應用因為沙盒隔離,存取迴環位址這條路直接被系統擋住,請求根本發不出去,應用只能報網路錯誤或者乾脆走上原始直連——如果直連本身被封鎖,表現就是「完全連不上」;如果直連能通但目標服務對地區有限制,表現就是「內容載入不出來但看起來沒報錯」。

判斷依據同一台裝置上,Win32 版瀏覽器測速正常、商店版應用異常,基本可以確定是迴環限制導致,而不是訂閱或規則的問題。

用系統內建工具 CheckNetIsolation 解除限制

微軟為這個問題留了官方解法:命令列工具 CheckNetIsolation,Windows 10/11 都內建,不用額外安裝。它可以幫單個 UWP 應用開一個「迴環豁免」(LoopbackExempt),相當於告訴系統沙盒:這個應用允許存取本機迴環位址。

按 Win 鍵搜尋「命令提示字元」,右鍵選擇「以系統管理員身分執行」,必須是系統管理員權限,否則命令會靜默失敗。
輸入以下命令,列出目前所有已安裝的 UWP 應用及其套件名稱,找到出問題的應用對應的 PackageFamilyName:
```
CheckNetIsolation LoopbackExempt -s
```
確認套件名稱後,執行豁免命令,把 套件名稱 換成上一步查到的完整字串:
```
CheckNetIsolation LoopbackExempt -a -n="套件名稱"
```
命令執行後沒有報錯即代表成功,不需要重新開機,但建議把該 UWP 應用完全關閉後重新開啟,讓新的網路權限生效。

如果一時找不到具體套件名稱,也可以用一條命令直接給所有已安裝的 UWP 應用批次開啟迴環豁免,適合排查階段快速驗證是不是這個原因:

CheckNetIsolation LoopbackExempt -a -p=*

確認問題解決後,建議再用下面的命令把範圍收窄回單個應用,避免長期給全部商店應用開這個口子:

CheckNetIsolation LoopbackExempt -c
CheckNetIsolation LoopbackExempt -a -n="目標應用套件名稱"

命令	作用
`-s`	列出目前所有迴環豁免記錄與已安裝套件名稱
`-a -n="套件名稱"`	為指定應用新增迴環豁免
`-d -n="套件名稱"`	移除指定應用的迴環豁免
`-c`	清空全部已新增的豁免記錄

用戶端內建入口:TUN 模式繞開系統代理層

命令列方式對單個應用精確有效,但如果家裡同時裝了多個商店應用都受影響,一個個手動豁免比較繁瑣。更省心的做法是讓 Clash 用戶端切換到 TUN 模式(部分用戶端裡標註為「虛擬網卡模式」或「增強模式」)。

TUN 模式的原理和系統代理設定完全不同:系統代理是讓程式把請求轉發到本機迴環埠,依賴的是每個應用自己「願意」配合系統代理設定;TUN 模式則是在系統裡建立一張虛擬網卡,由用戶端在網路層攔截並接管所有出站流量,不管發起請求的程式是 Win32 還是 UWP,只要走的是標準 TCP/IP 協定堆疊,都會被這張虛擬網卡截住轉發,不再依賴迴環位址這條路徑,自然也就繞開了 UWP 沙盒對迴環存取的限制。

開啟方式因用戶端介面而略有差異,大致步驟一致:

開啟用戶端設定頁,找到「網路模式」或「連接方式」選項。
將模式從「系統代理」切換為「TUN」或「虛擬網卡」。
首次開啟通常需要額外授權:安裝一次虛擬網卡驅動,並允許用戶端以系統管理員權限執行,系統會彈出一次驅動安裝確認框。
切換成功後系統代理設定可以保持預設狀態,不用手動再設定,商店應用和一般桌面程式會走同一條轉發路徑。

注意 TUN 模式對系統權限要求更高,少數安全軟體會把虛擬網卡驅動的安裝動作標記為敏感操作,出現攔截提示時選擇允許即可,這是驅動安裝的正常行為,不代表異常。

兩種方法怎麼選,常見報錯怎麼查

如果只是個別一兩個商店應用異常,其他一切正常,優先用 CheckNetIsolation 精確豁免,改動範圍小、不影響其他網路設定。如果家裡商店應用普遍受影響,或本身就打算長期用一套更穩的轉發方式,直接切到 TUN 模式一次性解決更省心,後續新裝的商店應用也不用逐一再處理。

處理過程中如果依舊不通,按下面順序排查:

確認命令提示字元是否以系統管理員身分執行,非管理員權限下 CheckNetIsolation 命令會回傳成功提示但實際不生效,這是最容易被忽略的一步。
用 -s 參數重新查看豁免清單,確認目標套件名稱確實出現在清單裡,而不是拼字錯誤導致豁免了一個不存在的套件。
確認 Clash 用戶端的監聽埠和系統代理設定裡的埠一致,迴環限制解除只是打通了存取路徑,埠設錯依然連不上。
切換 TUN 模式後如果仍無變化,檢查用戶端是否提示虛擬網卡驅動安裝失敗,可嘗試重新啟動用戶端或重新開機後再開一次。
部分商店應用有自己獨立的網路設定項(常見於部分閱讀、下載類應用),需要在應用內部單獨關閉「僅使用直連」之類的選項。

驗證代理是否真正生效

解除限制之後,不要只看應用能不能開啟內容,這樣容易出現「看起來通了但走的還是直連」的誤判。用下面三種方式交叉驗證更可靠:

IP 歸屬地對比:在瀏覽器裡開啟一個 IP 查詢頁面,記錄直連時顯示的地區,再在商店應用內觸發一次網路請求(比如刷新一個受地區限制的頁面),對比行為差異是否符合代理節點所在地區的預期。
用戶端連接記錄:開啟 Clash 用戶端的日誌或連接面板,操作商店應用的同時觀察是否新增了對應的連接記錄,能看到具體網域和使用的代理節點,是最直接的證據。
刻意切換節點復測:把代理節點切換到另一個地區,重複同一個操作,如果商店應用裡的內容表現隨之變化,說明流量確實經過了代理而不是走直連命中快取。

三種方法裡,用戶端連接記錄最能說明問題,因為它不依賴商店應用本身的介面反饋,直接從流量轉發層確認請求是否被接管。如果記錄裡完全沒有出現該應用的連接記錄,說明迴環限制或 TUN 模式設定沒有真正生效,需要回到上面的排查順序重新走一遍。