海灵总结

海灵提示：Microsoft Store 关闭代理正常、开启 Clash 或 Mihomo 后初始化失败，并不一定是分流规则未生效。本文记录如何根据 0x80072EFD、TransportException 和本机代理地址定位 Windows AppContainer 回环隔离，并通过回环豁免、图形工具或纯 TUN 模式解决问题。

微软商店开启 Clash 后初始化失败：不是规则失效，而是 UWP 回环权限

最近遇到一个看起来很像“代理规则没生效”的问题：

Microsoft Store 在关闭代理时可以正常打开；
开启 Clash Party 和系统代理后，商店提示“初始化失败”；
Mihomo 中已经把微软域名和商店进程设置为 DIRECT，但问题依旧存在。

最后确认，问题不在分流规则，而在 Windows 的 AppContainer 回环隔离。

现象为什么容易误导

系统代理指向本机的 Mihomo，例如：

127.0.0.1:7890

微软商店发起请求时，正常路径应该是：

Microsoft Store
    → 127.0.0.1:7890
    → Mihomo 匹配规则
    → DIRECT
    → 微软服务器

这里的 DIRECT 不是让微软商店绕过本机代理，而是告诉 Mihomo：收到请求后，出口直接连接目标服务器。

Microsoft Store 属于 Windows AppContainer 应用。系统代理开启后，如果它没有访问本机回环地址的权限，请求就会停在第一步。流量尚未进入 Mihomo，后面的 DIRECT 规则自然没有机会执行。

这也是为什么“规则明明存在”，商店却仍然失败。

如何确认是这个问题

在事件查看器中打开：

应用程序和服务日志
→ Microsoft
→ Windows
→ Store
→ Operational

如果看到以下特征，基本可以确定与本机代理或回环权限有关：

0x80072EFD
WinStore.Network.TransportException
127.0.0.1:7890

还可以检查两个关键事实：

Mihomo 的 7890 端口确实正在监听；
普通浏览器或 PowerShell 通过该代理可以访问微软商店接口，但 Microsoft Store 自己不行。

这说明代理服务正常，失败点位于 Store 应用访问本机代理的过程。

解决方法一：添加回环豁免

以管理员身份打开 Windows PowerShell 或终端，执行：

CheckNetIsolation LoopbackExempt -a "-n=microsoft.windowsstore_8wekyb3d8bbwe"
CheckNetIsolation LoopbackExempt -a "-n=microsoft.storepurchaseapp_8wekyb3d8bbwe"
CheckNetIsolation LoopbackExempt -a "-n=microsoft.desktopappinstaller_8wekyb3d8bbwe"

检查是否写入成功：

CheckNetIsolation LoopbackExempt -s

结果中应该出现：

microsoft.windowsstore_8wekyb3d8bbwe
microsoft.storepurchaseapp_8wekyb3d8bbwe
microsoft.desktopappinstaller_8wekyb3d8bbwe

包标识应使用上述精确的小写形式。完成后，彻底关闭并重新打开 Microsoft Store。

解决方法二：使用图形界面

Windows 设置目前没有管理 AppContainer 回环权限的图形入口。

不想使用命令行，可以安装并以管理员身份运行 Fiddler Classic：

打开 Tools；
进入 Win8 Loopback Exemptions；
勾选 Microsoft Store、Store Purchase App 和 App Installer；
点击 Save Changes；
重新启动 Microsoft Store。

有些 Clash 客户端也提供 UWP Loopback、UWP 回环 或 解除 UWP 回环限制 功能，本质上做的是同一件事。

解决方法三：只使用 TUN

如果客户端没有 UWP 回环管理功能，可以尝试：

开启 TUN 模式；
关闭系统代理；
保持 Mihomo 为 Rule 模式。

这样 Microsoft Store 不再显式连接 127.0.0.1:7890，流量由 TUN 接管，通常可以避开 AppContainer 的本机代理限制。

需要注意：修改网络接管方式后，应重新检查局域网、远程桌面、云电脑和游戏流量，避免影响原有连接。

分流规则仍然需要保留

解决回环权限只负责让 Microsoft Store 的请求进入 Mihomo，并不决定流量最终走代理还是直连。

如果希望微软商店走国内直连，仍应保留类似规则：

rules:
  - PROCESS-NAME,WinStore.App.exe,DIRECT
  - PROCESS-NAME,StoreDesktopExtension.exe,DIRECT
  - PROCESS-NAME,AppInstaller.exe,DIRECT
  - DOMAIN-SUFFIX,microsoft.com,DIRECT
  - DOMAIN-SUFFIX,microsoftstore.com,DIRECT
  - DOMAIN-SUFFIX,apps.microsoft.com,DIRECT
  - DOMAIN-SUFFIX,windowsupdate.com,DIRECT

规则顺序也很重要：微软直连规则应放在通用境外代理规则和 MATCH 之前。

修复后的验证

本次排查使用相同条件进行前后对比：

修复前：代理开启后，35 秒内产生 11 条 0x80072EFD 网络错误；
修复后：相同时间内相关网络错误为 0；
Microsoft Store 建立了到 127.0.0.1:7890 的连接；
商店首页、应用和游戏内容正常显示；
系统代理和 Mihomo 均保持开启。

这说明请求已经能够进入 Mihomo，原有微软直连规则也终于有机会执行。

安全与恢复

回环豁免允许指定 AppContainer 访问本机服务。建议只为确实需要的微软商店相关包开启，不要给所有 UWP 应用批量放行。

需要恢复默认状态时，执行：

CheckNetIsolation LoopbackExempt -d "-n=microsoft.windowsstore_8wekyb3d8bbwe"
CheckNetIsolation LoopbackExempt -d "-n=microsoft.storepurchaseapp_8wekyb3d8bbwe"
CheckNetIsolation LoopbackExempt -d "-n=microsoft.desktopappinstaller_8wekyb3d8bbwe"

总结

当 Microsoft Store 出现“关闭代理正常、开启代理失败”时，不要只盯着域名和 DIRECT 规则。

先判断请求是否真正进入了 Mihomo：

规则存在 ≠ 应用能够连接本机代理

如果事件日志同时出现 0x80072EFD、TransportException 和本机代理地址，应优先检查 AppContainer 回环权限。放行回环后，再由 Mihomo 的规则决定微软流量走国内直连还是代理。