為什麼 Chrome 正常，Microsoft Store 卻像「沒網路」？

許多人第一次遇到這個情境，會直覺懷疑機場節點壞了、或 Microsoft Store 下載慢 是微軟伺服器問題。可是在同一個工作階段裡，若以傳統 Win32 瀏覽器開網頁、下載檔案都正常，卻只有商店、Xbox、部分內建的 UWP（通用 Windows 平台）應用程式更新卡住，就很可能是流量根本沒照你想的管道離開本機。Clash 多數圖形用戶端預設把系統代理指到 127.0.0.1 加上 mixed-port（常見如 7890），而 UWP 程式在預設情況下，對「連到自己的電腦」有更嚴格的限制，導致即使你已在「設定 → 網路和網際網路 → Proxy」看到手動 Proxy 已啟用，商店行程仍無法穩定把流量交給本機的 Clash。

換句話說：你用 Chrome 測得的「會走代理」無法直接類推到 Xbox App。 前者通常遵循系統 Proxy 設定且不受 UWP 沙箱同一套回環規則束縛；後者除了要讀到系統層的 WinInet／WinHTTP Proxy，還要嘛通過回環豁免、要嘛乾脆不要用「指到本機」這條路，而改由 TUN 模式 在更底層承接封包。下面我們先把名詞對齊，避免把「開了 Clash」與「全域程式都已走代理」畫上等號。

系統代理與 TUN：各自動到誰？

系統代理（也有人說「系統 Proxy」）描述的是：Windows 把 HTTP／HTTPS 類請求交給哪一臺 Proxy 伺服器。多數 Clash 用戶端提供的「一鍵設定系統 Proxy」就是把這個欄位寫成你的本機 mixed-port。好處是與瀏覽器、許多尊重系統設定的桌面程式相容；壞處是對不依賴 WinInet 設定的程式無效，且如上一節所述，UWP 對連到本機位址還有額外隔離。

TUN 模式則是在網路堆疊更底層掛上一張虛擬介面，讓符合路由規則的流量先進入 Clash 再決定直連或轉發。理論上它能涵蓋更多「根本不讀系統 Proxy」的程式，包含不少遊戲與服務背景元件；代價是需要虛擬介面驅動、可能需要管理員權限，且要與公司 VPN、其他虛擬網卡和平共存。對 Xbox App 代理、Game Pass 下載這類混合了 UWP 與背景服務的案例，實務上有不少人選擇「系統代理 + 回環豁免」作為較輕量的第一步，若仍不理想再切到 TUN。

若你想先把 TUN 的行為、權限與典型坑一次讀完，可併讀站內 Clash TUN 模式詳解；若你才剛在 Windows 裝好圖形用戶端、還在對齊連接埠與開機啟動，建議搭配 Clash Verge Rev 的 Windows 教學 建立基礎設定再回頭處理商店。

步驟一：對齊 Clash mixed-port 與「系統代理」開關

在動任何 UWP 專用技巧前，請先確認三件事一致：核心實際監聽的 mixed-port、用戶端寫入系統的 Proxy 位址與埠號、以及你在 Windows 設定裡看到的數字。若曾經調過埠號卻忘了同步，表面上會變成「Chrome 仍沿用舊設定剛好可用、商店卻完全命不中」的錯覺。此時可直接參考 連接埠佔用與 mixed-port 一文，用 netstat 或 PowerShell 確認 LISTENING 的是哪個 PID、是不是你的 Clash 核心。

在圖形介面中，請開啟「系統代理」或同義選項（不同皮膚命名不一），確保它處於開啟狀態，並且顯示的位址與埠與設定檔一致。若你習慣手動在 Windows 設定裡填 Proxy，也要避免一邊用戶端自動寫入、另一邊你又改回舊值，造成雙重來源打架。

步驟二：在 Windows 設定中確認手動 Proxy

打開「設定」→「網路和網際網路」→「Proxy」，在「手動 Proxy 設定」區段確認已開啟，位址為 127.0.0.1（或你刻意指定的本機位址），連接埠為 mixed-port。若組織政策或協力廠商工具鎖定了 Proxy，這裡可能呈現灰色；那就要先還原可由使用者控制的狀態，否則後續豁免與分流都無從談起。

部分讀者會同時開啟「自動設定 Proxy」或 PAC，請注意它與手動欄位的優先順序，避免 PAC 把流量導到不存在的主機。排錯時可以暫時改回「只看手動 Proxy + Clash」的最小組合，確認 Store 能動之後再加回複雜邏輯。

步驟三：為 Store／Xbox 解除回環（loopback）隔離

當系統 Proxy 已指向本機，而 UWP 仍無法下載時，下一步通常是回環豁免：讓特定的應用套件獲准連到 127.0.0.1。微軟提供 CheckNetIsolation 命令列工具，可自行針對套件解除隔離。實務上你需要目標程式的 Package Family Name（PFN）；在 PowerShell 中可用 Get-AppxPackage 查詢，例如針對 Microsoft Store 本體，常見的 PFN 形如 Microsoft.WindowsStore_8wekyb3d8bbwe，Xbox／遊戲列則可能落在 Microsoft.GamingApp_8wekyb3d8bbwe 或其它依版本而異的名稱，請一律以你機器上查到的為準。

以系統管理員身分開啟「命令提示字元」或 PowerShell，將下列指令中的 PFN 換成你查到的值（行尾參數為套件識別，非商店連結）：

CheckNetIsolation LoopbackExempt -a -n=Microsoft.WindowsStore_8wekyb3d8bbwe

-a 代表加入豁免清單。若你想確認目前清單，可使用 CheckNetIsolation LoopbackExempt -s。對 Xbox、Game Bar、相關更新代理程式，可視症狀重複為對應 PFN 各做一次。若覺得命令列繁瑣，市面上亦有圖形化「一次勾選多個 UWP」的輔助工具，原理仍是寫入同一份豁免政策；無論用哪種介面，都建議只放行你信任的官方套件，並在更新 Windows 大版本後若症狀復發，再檢查豁免是否仍有效。

若仍卡住：改以 TUN 承接，或檢查非 Proxy 因素

當回環與系統 Proxy 都已就緒，Microsoft Store 仍頻繁逾時，可以開始懷疑節點品質、DNS、規則分流、或微軟 CDN 本身。此時啟用 TUN、讓更多子程序別再依賴「是否尊重系統 Proxy」這件事，往往較省腦力。請依 TUN 教學 完成驅動與路由後，再在 Clash 日誌中觀察實際出口是否符合預期。

另外兩個常見「與代理無關」的干擾源值得一提：一是 傳遞最佳化（Delivery Optimization） 對等快取策略偶爾會讓進度條行為怪異，可在同一台機器上先關閉測試；二是第三方防火牆／流量監控攔截了虛擬網卡或本機連線。若你曾為 Clash 設定過排除路徑，記得在更新用戶端後路徑是否改變，可與 Defender 誤判還原 一文對照看。

與「區網共享」場景的差異

有些使用者會把行動熱點或區網代理當成另一條路：讓家裡其它裝置連到桌機上的 Clash。那種情境下，UWP 指向的是區網 IP 而非 127.0.0.1，回環限制的特性不同，設定重點會放在路由、防火牆與允許連入連接埠；這與本文聚焦的「本機系統 Proxy」是兩條支線。若你正好在作這類拓撲，請改讀 Clash 區網代理與 Wi‑Fi 共享，避免把兩種架構的參數混在一起。

排查清單（方便截圖備忘）

最後整理一份可按圖索驥的順序：(1) 用戶端確認 mixed-port 存活且系統代理開啟；(2) Windows 設定的手動 Proxy 與之一致；(3) 對 Microsoft Store、Xbox／Gaming 相關 PFN 做 loopback 豁免並重啟商店；(4) 再不行則啟 TUN、對照日誌與 DNS；(5) 仍異常時檢查傳遞最佳化、防火牆、節點本身。把這五層分開驗證，就不容易陷入「只有 Chrome 看得到世界」的無限迴圈。

小結

Clash Windows UWP 代理的本質，是在「桌面程式好用的本機 Proxy」與「沙箱化 UWP」之間補上一塊迴路豁免或改用更低階的轉發方式。搞懂系統代理與 TUN 模式的覆蓋範圍後，Microsoft Store 下載慢或 Xbox App 代理這類問題大多能收斂到少數可重現的設定缺口，而不是盲目換節點。相較於散落論壇的一次性指令，為自己的電腦保留一份「埠號、PFN 與豁免清單」備註，下次大版本更新後也能快速恢復環境。

當商店、遊戲服務與瀏覽器終於共用同一套路由邏輯，日常更新與下載就不會再卡在進度起始點。若你還在挑選 Windows 用戶端或想從本站取得一鍵安裝入口，歡迎先閱讀 說明文件 取得一致版本資訊；就安裝體驗而言，持續維護的圖形介面在穩定度與細部選項上通常優於東拼西湊的過期教學。→ 立即免費下載 Clash，開啟流暢上網新體驗