Windows 上 Microsoft Store 与 Clash Verge 共存：一次 UWP 回环权限排障

Microsoft Store 打不开，而浏览器和其他桌面应用都能正常联网。第一反应往往是重装商店、重置网络，甚至重装 Clash。

这些动作都太重了。本次故障里，Microsoft Store 安装包、Windows 服务和 Clash 核心都没有坏。真正的问题在数据路径的第一跳：Microsoft Store 运行在 AppContainer 中，缺少访问 Clash 本机代理端口的回环权限。

最终只需为 Microsoft Store 增加一条回环豁免，Clash Verge 的 TUN 模式和系统代理都可以继续保留。

TL;DR

• 现象：Clash Verge 同时开启 TUN 模式与系统代理后，Microsoft Store 初始化失败。
• 代理状态：系统代理为 127.0.0.1:7897，该端口由 verge-mihomo 正常监听。
• 排除项：Microsoft Store 包状态正常，相关 Windows 服务正常。
• 根因：Microsoft Store 不在 AppContainer/UWP 回环豁免列表中，无法访问监听在本机回环地址上的 Clash 代理。
• 修复：以管理员身份执行：

powershellCopy
CheckNetIsolation.exe LoopbackExempt -a -n=Microsoft.WindowsStore_8wekyb3d8bbwe

问题现场

故障发生时，Clash Verge 的两个入口同时开启：

• TUN 模式：开启
• Windows 系统代理：开启
• 系统代理地址：127.0.0.1:7897
• Clash 核心：verge-mihomo

Microsoft Store 显示：

Sorry about that. Something went wrong and Microsoft Store failed to initialize. Try refreshing or come back later.

关键特征是：普通桌面应用可以正常联网，只有 Microsoft Store 失败。这意味着“整机断网”和“Clash 核心没启动”都不是高优先级假设。

先把数据路径理清

开启系统代理后，Microsoft Store 的请求路径应该是：

textCopy
Microsoft Store (AppContainer)
        │
        │ 访问 127.0.0.1:7897
        ▼
Clash / verge-mihomo
        │
        ▼
Microsoft 服务

问题发生在第一条边，不是在 Clash 到公网的链路上。

Windows 会隔离 AppContainer 应用对本机回环地址的访问。普通 Win32 程序能连接 127.0.0.1:7897，不代表 Microsoft Store 也能连接。系统代理恰好把 Store 的流量引向本机代理，于是这个限制暴露出来。

Clash 的 Fake-IP 日志只能证明请求进入了 Clash 的 DNS/代理处理链路，不能单独证明 Fake-IP 就是根因。不要看到 198.18.0.0/15 就急着改 DNS 模式。

证据链：先排除损坏，再验证权限

1. 确认 Clash 端口确实在监听

在 PowerShell 中检查 7897：

powershellCopy
Get-NetTCPConnection -LocalPort 7897 -State Listen

本次排查中，端口由 verge-mihomo 正常监听。代理进程和入口端口没有问题。

2. 确认 Microsoft Store 包没有损坏迹象

powershellCopy
Get-AppxPackage -Name Microsoft.WindowsStore

包状态为 Ok。这条证据很重要：没有包损坏证据，就不要先执行卸载、重新注册之类的破坏性操作。

3. 确认相关服务正常

powershellCopy
Get-Service AppXSvc, BITS, InstallService, wuauserv

本次检查没有发现服务异常。因此，“商店包损坏”和“关键服务未启动”都被降为低优先级。

4. 检查回环豁免列表

powershellCopy
CheckNetIsolation.exe LoopbackExempt -s

列表中原本没有：

textCopy
microsoft.windowsstore_8wekyb3d8bbwe

到这里，证据已经闭环：Store 需要走 127.0.0.1:7897，代理端口正常，但 Store 没有访问本机回环地址的权限。

最小修复：只给 Microsoft Store 放行

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

powershellCopy
CheckNetIsolation.exe LoopbackExempt -a -n=Microsoft.WindowsStore_8wekyb3d8bbwe

然后验证：

powershellCopy
CheckNetIsolation.exe LoopbackExempt -s

输出中应出现：

textCopy
microsoft.windowsstore_8wekyb3d8bbwe

这条命令只为 Microsoft Store 增加回环豁免，不需要关闭 Clash TUN，也不需要关闭 Windows 系统代理。它比给所有应用放宽限制更可控。

如果以后不再使用本机代理，可以删除这条豁免：

powershellCopy
CheckNetIsolation.exe LoopbackExempt -d -n=Microsoft.WindowsStore_8wekyb3d8bbwe

清理旧状态

权限修复后，再清理故障期间留下的缓存状态。

1. 刷新 DNS 缓存

powershellCopy
ipconfig /flushdns

2. 重置 Microsoft Store 缓存

先完全关闭 Microsoft Store，再执行：

powershellCopy
wsreset.exe

wsreset.exe 会清理 Store 缓存并重新拉起应用。它负责清状态，不负责解决回环权限；顺序不要颠倒，否则可能只是短暂重启后继续失败。

0x80073D02 为什么不是主因

事件日志中还出现了 0x80073D02。它表示系统更新 Microsoft Store 时，应用仍在运行，相关资源被占用。

这是一个独立的附带问题：

• 回环限制解释“为什么 Store 访问本机代理失败”；
• 0x80073D02 解释“为什么 Store 自身更新暂时无法完成”。

正确处理方式是完全关闭 Microsoft Store，让更新完成后再启动。不能因为看到这个错误码，就直接推断 Store 安装包已经损坏。

修复后的状态

• Microsoft Store 包状态仍为 Ok
• Microsoft Store 可以正常启动和刷新
• UWP/AppContainer 回环豁免已添加
• Clash Verge TUN 模式保持开启
• Windows 系统代理保持为 127.0.0.1:7897
• verge-mihomo 核心继续运行

如果问题再次出现

按下面顺序处理，别上来就重装：

1. 完全关闭 Microsoft Store。
2. 确认 Clash Verge 与 verge-mihomo 正常运行。
3. 确认 127.0.0.1:7897 仍在监听。
4. 用 CheckNetIsolation.exe LoopbackExempt -s 检查 Store 豁免是否仍存在。
5. 执行 wsreset.exe，重新打开 Store。
6. 如果仍失败，再检查 Clash 连接日志中的微软域名规则命中与节点连通性。

Windows 大版本升级或系统重置后，值得重新检查豁免列表。普通 Clash 配置更新通常不会修改 Windows 的 AppContainer 回环权限。

复盘

这次最容易走偏的地方，是把“Store 打不开”直接等价为“Store 坏了”。真正有效的排障顺序应该是：

1. 画出请求路径；
2. 验证每个节点是否正常；
3. 找出断掉的那条边；
4. 只修这条边。

本次断点是 Microsoft Store → 127.0.0.1:7897。增加单应用回环豁免，问题结束。重装 Store、关闭 TUN、切换 DNS 模式都不是必要动作。