Microsoft Store 与 UWP 不走 Clash？回环豁免与 TUN 修复步骤
在 Windows 上，很多人会遇到一种「割裂」：Edge 或 Chrome 已经跟着 Clash 的系统代理正常翻墙，但 Microsoft Store 下载卡住、UWP 应用更新失败，或部分沙箱化程序仍像直连。这往往不是订阅坏了，而是 Windows 对应用容器的网络隔离——尤其是 loopback（回环） 限制——让 UWP 栈无法像传统 Win32 那样「老实」使用本机代理监听地址。本文按真实搜索意图，先讲清成因，再给出可复制的 CheckNetIsolation 回环豁免步骤；若仍不稳，再收敛到 TUN 模式 与规则、DNS 的协同，让你少在论坛里反复试错。
典型现象：为什么「系统代理开了」商店仍像没走 Clash
当你使用 Clash 图形客户端常见的系统代理（或 PAC）方案时，系统会把 HTTP(S) 代理信息下发给愿意读取系统代理设置的应用。桌面浏览器、许多 Win32 程序会遵守；但 UWP 运行在 AppContainer 沙箱中，默认禁止连接本机回环地址上的服务——而本地代理端口（例如 127.0.0.1:7890）恰恰就在回环上。
结果是：应用要么忽略代理直接出站（看起来像「直连」），要么在尝试走本机代理时被 loopback 策略挡住，表现为长时间转圈、错误码模糊、仅部分页面能开。Microsoft Store、Xbox 相关组件、部分从商店分发的应用更新通道，都属于高频踩坑对象。它与「规则写错」不同：你即使在 Clash 里把微软域名都标成代理，只要流量没有进入 Clash 的捕获路径，规则也不会生效。
- 浏览器正常、商店异常：优先怀疑 UWP 回环隔离，而不是节点质量。
- Win32 工具正常、沙箱应用异常：同一台机器上两类应用网络栈不同。
- 已开 TUN 仍异常：再查 DNS、fake-ip、规则优先级，参见下文「与规则、DNS 协同」。
排错前基线：先确认 Clash 与系统代理本身可用
在动 CheckNetIsolation 或 TUN 之前，先用最小步骤确认「代理链路」没有低级错误：客户端已导入订阅、当前模式为 Rule 或你期望的模式、系统代理开关确实由 Clash 接管。若你尚未完成 Windows 侧安装与模式切换，请先按 《Clash for Windows 完整安装与配置教程》 走通，再回来看 UWP 专项。
若浏览器访问海外站点已稳定，而商店仍失败，再继续本文；若浏览器也不稳定，应先处理订阅、规则或 《DNS 泄漏与 fake-ip 排查》，避免把两个问题缠在一起。
心智模型
把问题拆成两层：流量有没有进 Clash（捕获点），以及进 Clash 后规则怎么判。UWP 的 loopback 限制主要卡在「进不进」这一层。
方案一：CheckNetIsolation 回环豁免（针对 UWP / 商店包族）
Windows 提供 CheckNetIsolation 工具，允许你为指定应用的程序包族名称（Package Family Name）添加 LoopbackExempt，使其可以访问本机回环上的代理或服务。对 Microsoft Store 与相关系统组件，这是社区里最常用、改动面相对可控的办法之一。
步骤 A：用 PowerShell 查到 Package Family Name
以管理员身份打开 PowerShell，查询商店相关包（示例过滤关键字，按你机器上实际输出为准）：
# Run PowerShell as Administrator
Get-AppxPackage *WindowsStore* | Select-Object Name, PackageFamilyName
Get-AppxPackage *Xbox* | Select-Object Name, PackageFamilyName
记下你需要豁免的包对应的 PackageFamilyName。不同系统版本与组件组合，名称可能略有差异，请以本机查询结果为准，不要机械照抄旧帖。
步骤 B：添加 loopback 豁免
将下面命令中的 <PackageFamilyName> 换成上一步输出的完整字符串（仍需管理员权限）：
# Administrator CMD or PowerShell — replace placeholder
CheckNetIsolation LoopbackExempt -a -n="<PackageFamilyName>"
添加成功后，完全退出 Microsoft Store（可在任务管理器结束相关进程），重新打开并尝试下载或登录。若你只豁免了商店主包，但更新仍由其它相关包发起，可根据事件查看器或经验再补充相邻包的族名。
如需查看当前豁免列表，可使用 CheckNetIsolation LoopbackExempt -s。若误加过多，可用 -d 删除指定项（同样带 -n="..."）。部分第三方网络调试工具也提供图形化 loopback 开关——本质仍是同一类系统能力，择一即可，避免重复操作。
安全与合规
回环豁免会扩大应用访问本机监听端口的能力。请只对你信任的包族操作，并在排查结束后保留最小豁免集合。请遵守当地法律、微软服务条款与工作场所 IT 策略。
方案二：启用 Clash TUN——当系统代理链路与 UWP 仍不对齐
若你已做 loopback 豁免，但部分 UWP 仍不走期望路径，或你希望统一捕获点、减少「谁读系统代理、谁不读」的差异，可以在确认客户端与内核支持的前提下启用 TUN 模式。TUN 在更靠近系统的层面对流量进行导流，使更多程序——包括不完全遵守系统代理的应用——进入 Clash 的转发逻辑，再由 规则 决定直连或代理。
各 Clash 衍生图形客户端对 TUN 的开关位置不同，但共性要求包括：通常需要管理员权限或完成驱动／Wintun 安装；首次启用若出现「整机上不了网」，应立刻回退 TUN，先恢复系统代理可用，再逐项核对 DNS 与规则。Windows 上与 WSL、虚拟机、其它虚拟网卡并存时，偶发冲突；可对比 《WSL2 走 Clash 的镜像网络与端口转发》 中的拓扑意识，避免多栈抢路由。
| 路径 | 适用 | 权衡 |
|---|---|---|
| 系统代理 + loopback 豁免 | 主要问题集中在商店／少数 UWP | 改动面小；需维护包族豁免列表 |
| TUN + Rule | 希望全局一致捕获、减少漏网进程 | 权限与驱动成本更高；要会看日志排冲突 |
与规则、DNS、fake-ip 的协同（避免「进了 Clash 仍失败」）
当捕获点已经正确（豁免后系统代理可用，或 TUN 已生效），若 Microsoft 相关域名仍访问异常，才进入「规则与 DNS」层面：商店与更新 CDN 主机名多、边缘节点会变，远程规则集需要定期更新；若你使用 fake-ip，要确保解析行为与策略一致，避免「解析到了 fake-ip，但某条路径没匹配预期策略组」的错位。
建议一次只改一个变量：先固定节点与策略组，再动 DNS；或先对照连接日志里的进程／目标／命中规则，再决定是加域名规则还是调整 GEOIP／MATCH 顺序。更系统的 DNS 与 fake-ip 说明见 《Clash 显示已连接却无法上网》 专题。
WinGet、终端与「不是 UWP」的坑
有些用户会把 winget、PowerShell 里的下载失败全部归类为「商店问题」。实际上 winget 默认多在 Win32 控制台进程里跑，往往走系统代理或环境变量路径，与 UWP loopback 不是同一类故障。若你遇到的是 Git、npm、curl 在终端里超时，应优先参考 《GitHub 与 npm 终端代理》，用 HTTP_PROXY／HTTPS_PROXY 或 Git 的 proxy 配置对齐，而不是盲目堆 loopback 豁免。
Clash 退出后网络异常？
若你在调试 TUN 或反复切换系统代理后，出现「退出 Clash 仍无法上网」，多半是系统代理或 PAC 残留。请按 《Clash 退出后恢复系统代理》 在 Windows 设置里恢复「不使用代理」，再重启网卡或系统服务观察。
常见问题
豁免加了仍无效
核对是否豁免了实际发起连接的包族；商店界面与后台下载可能对应不同组件。结合客户端连接日志与系统版本，必要时临时启用 TUN 对比行为。
开 TUN 后整机断网
先关闭 TUN，确认基础网络恢复；检查是否与其它 VPN、公司安全软件、虚拟交换机冲突；DNS 是否被劫持到不可达地址。
公司域策略或 MDM
企业设备可能禁止 loopback 豁免或限制虚拟适配器。此类环境请先联系 IT，不要强行绕过合规策略。
实操检查清单
- 浏览器已验证 Clash 系统代理／规则工作正常。
- 用
Get-AppxPackage取得准确的PackageFamilyName。 - 管理员执行
CheckNetIsolation LoopbackExempt -a -n="..."，重启商店再测。 - 若仍异常，评估 TUN：权限、驱动、与 WSL／其它 VPN 的冲突。
- 捕获点确认后，再查规则、DNS、fake-ip 与日志三要素。
从顺手的客户端开始
把 UWP 问题拆成「捕获点」与「策略」两步后，维护成本会明显下降。无论你偏好系统代理还是 TUN，Clash 系列客户端都强调可读规则与透明日志，适合长期自用排错。