症状复盘：为什么 Chrome 能上，商店却一直转圈
很多 Windows 用户装好 Clash 后，第一个直觉是「我已经开了代理」。这时用 Chromium 系浏览器访问外站往往没问题，但打开 Microsoft Store、Xbox 应用或部分自带的 UWP/WinRT 程序，下载与更新仍然慢、进度条不动，甚至直接报错。先把预期摆对：浏览器走代理，只能说明浏览器进程按你配置的方式（扩展、手动指定 SOCKS5/HTTP、或读取系统代理）找到了 Clash 的入站口；它不能自动推出「所有 Win32/UWP 程序都会同样走 Clash」。
Microsoft Store、Xbox、Game Pass 相关组件，很大比例走的是 Windows 的网络栈与 CDN，对「系统代理」与「本机回环」的依赖路径和 Chrome 并不完全一致。再加上部分地区 DNS、传输优化与多线程分片，表现就会像「只有商店坏了」。下文先把系统代理与TUN两条路线区分清楚，再按顺序做可在家里复现的排查。
先选路线：系统代理和 TUN 分别解决什么问题
系统代理（System Proxy）依赖 Windows「Internet 设置」里下发的 HTTP 代理地址（常见为 Clash 的 mixed-port 或单独 HTTP 端口）。尊重这一设置的程序会通过 WinINet/WinHTTP 把流量送到你填写的 127.0.0.1:端口。Chrome、Edge 在「使用系统代理」时通常就属于这一类；不少 Win32 桌面软件也同样遵循。它的优点是改动面小、排障直观；缺点是并非所有运行时都会读系统代理，有些自建协议栈或沙盒里的 UWP 会出现「设置了但没用」的断层。
TUN / 虚拟网卡模式则在更底层把符合条件的数据包导入 Clash（视实现与路由表而定），对「不关心系统代理」的程序更友好。代价是需要虚拟网卡与路由权限、规则与 DNS 要一并想清楚，否则容易出现全表流量都被拉进隧道、或分流与 fake-ip 互相打架。若你已准备用 TUN 统一接管，可对照本站 Clash TUN 模式详解 先把模式开关、DNS 与例外路由理顺，再回到商店场景验证下载。
实战建议：若你只想让 Store/Xbox 尽量跟浏览器一致，优先把「Clash 写入系统代理」做对，并确认 mixed-port 未被其它软件占用（可参考 7890 / mixed-port 占用排查）；若仍卡住，再考虑 TUN 作为升级方案，而不是一上来两条线同时开、却说不清哪一条在生效。
第一步：在 Clash / Verge 里打开「系统代理」并核对端口
以常见的 Clash Verge Rev 为例：安装与管理员权限若仍有问题，可先过一遍 Clash Verge Rev Windows 安装教程。在能正常启动内核后，找到「系统代理」「Set System Proxy」或同级选项，确保其为开启状态，且内核监听端口与「Internet 属性 → 连接 → 局域网设置」里看到的地址一致。
打开「设置 → 网络和 Internet → 代理」，你应该能看到「使用代理服务器」已打开，地址一般为 127.0.0.1，端口为 YAML 里的 mixed-port（或你手动改成的新端口）。若这里仍是关闭，说明 Clash 没有成功写入系统代理：常见原因包括客户端未以足够权限运行、与其他「自动代理」工具互相覆盖、或你手动改过 LAN 设置后被系统策略锁回。先让这一屏与 Clash 状态对齐，再测商店，比盲目加规则更有效。
若你同时使用 PAC 文件或企业策略下发的固定代理，注意后写入者覆盖前者。临时排障可以关闭其它网络加速器、游戏加速器里的「系统代理」类选项，只保留 Clash，确认没有第二份软件在抢 WinINet。
第二步：UWP 的「回环隔离」与 localhost 代理
这是 Windows 上最容易被忽视的一点：默认情况下，许多 UWP 应用不能访问本机回环地址，而系统代理往往正是把流量发到 127.0.0.1。结果就是：Win32 浏览器能连上 Clash，Store 却像「代理断了」。微软提供了按程序包族名称（package family name）豁免的通道，常见做法是用 PowerShell / checknetisolation 把指定应用加入 loopback 例外。
操作前请确认你从可信渠道安装应用，并理解这是在放宽本机网络隔离边界。不要随意对未知包名批量放行。你可以在「开始」菜单里对 Microsoft Store、Xbox 应用图标使用「应用设置」查看其高级信息，或在 PowerShell 中用 Get-AppxPackage 列出包名与 Family Name，再按官方文档给出的 LoopbackExempt 流程添加。放行后重启应用，再观察下载进度是否开始走动。
若你希望长期少踩坑，也可以评估 TUN：流量不依赖「UWP → 127.0.0.1」这条路径时，loopback 限制带来的困扰会小很多，但请回到上一节，把 DNS 与分流一起规划好。
第三步：规则与 DNS——商店域名有没有被误杀或半直连
即使系统代理已生效，错误的规则顺序仍会让微软 CDN 命中直连或错误出口，表现为「连接有，但就是没有吞吐」。典型做法是：为 microsoft.com、xbox.com、windows.com、常见 Azure/下载域名所在的下载与认证路径单独观察，避免被过宽的 GEOIP 或「局域网/国内」一类规则提前截胡。
配合 Clash 的连接日志，看商店请求实际命中的策略组与远端 SNIs；若你使用 fake-ip，还要确认解析链没有让应用拿到无法路由的地址。更细的命中思路请看 连接日志与规则命中排查。与「只有商店慢、浏览器正常」相比，若是全局都慢，则应回到节点质量、加密协议与服务商侧限速，而不是只盯 UWP。
第四步：Xbox 应用与 Microsoft Store 的额外检查
Xbox 应用、Game Pass 与商店的后台组件可能在不同时间段访问不同主机名；若你只固定了其中一小撮域名规则，更新游戏时仍可能走到默认组。可尝试：在 Clash 里临时切到明确的单一出口（避免 url-test 频繁跳节点），关闭可能影响连接的「节能代理」类软件，再在系统设置里暂停后恢复传递优化（Delivery Optimization）相关选项，排除 P2P 与防火墙策略拉扯带宽。
企业网络或校园网若对微软更新有缓存或阻断，也会出现「只有商店异常」。此时可对比同一台机器换手机热点：若热点下正常，侧重点是上游网络策略而非 Clash。本地亦可执行一次商店的重置或疑难解答向导——但请记住：重置应用不会替代代理路径修复，只是排除应用自身损坏。
什么时候该升级到 TUN
如果你已经确认：系统代理写入正确、loopback 已按需豁免、规则没有把微软域名送进死胡同，但仍有大量 UWP 或系统组件不走 HTTP 代理，那么 TUN 往往是下一档方案。请阅读 TUN 专文 完成虚拟网卡权限、路由与 DNS 的完整配置，再与本文第一节对照，避免系统代理与 TUN 双重改写路由表却不自知。
TUN 打开后，务必用连接日志确认确实是 Clash 接住了商店的连接，而不是又落到「直连但 DNS 污染」的假通路。若你与 WSL2、Docker 共存，宿主机代理与端口规划也要一致，可参考 Docker 走宿主机 Clash HTTP 代理 与站内 WSL 相关篇，减少「一环改端口、另一环仍写死旧端口」的隐性坑。
收尾清单
把下面几项按顺序勾一遍：① Clash 是否成功打开系统代理，Windows 代理页是否显示正确 127.0.0.1 端口；② mixed-port 是否冲突；③ UWP 是否需要 loopback 豁免；④ 微软相关域名规则与 DNS 是否合理；⑤ Xbox/传递优化与第三方加速器是否干扰；⑥ 若仍失败，再评估 TUN 并对照专文配置。绝大多数「Microsoft Store 下载慢、Xbox App 不走 Clash」都能在系统代理与隔离策略这两层找到原因。
相比把问题笼统归因为「微软抽风」，分清系统代理 / TUN / UWP 隔离三条线，能少重装很多次系统。把 Clash 在 Windows 上的入口、规则与日志读顺以后，商店与游戏更新会容易预测得多。
若你尚未安装客户端或希望从可信入口获取安装包，可从本站 Clash 客户端下载页 下载后再按上文步骤验证 Microsoft Store 与 Xbox；开源仓库适合核对协议与更新记录，日常安装与版本选择建议仍以本站下载页为主。→ 立即免费下载 Clash，开启流畅上网新体验