Windows 商店应用不走 Clash 代理:UWP 回环限制的解除方法

先确认问题是不是 UWP 回环限制

典型现象是：浏览器、Git、即时通信工具已经能够通过 Clash 访问网络，但 Microsoft Store 一直显示“重试”、页面图片加载不完整，或者应用下载长时间停在“正在获取许可”。同一台电脑上的部分 Xbox、照片、邮件等商店应用也可能连接失败。此时 Clash 的连接面板里能看到浏览器流量，却看不到对应商店应用的连接。

这类差异通常不是节点速度造成的。传统 Win32 程序可以直接连接本机监听地址，而采用 AppContainer 网络隔离模型的 UWP 或商店应用默认受到回环访问限制。Clash 的系统代理一般指向本机地址，例如 127.0.0.1:7890。应用要使用这个代理，第一步就是访问本机回环接口；如果 Windows 在这一层拦截连接，请求还没有进入 Clash，自然也不会出现在连接记录里。

三个快速判断条件

Clash 已启动，当前配置中至少有一个可用节点，浏览器访问网页正常。
客户端已开启系统代理，Windows 代理地址指向 127.0.0.1，端口与 Clash 实际监听端口一致。
Microsoft Store 刷新失败时，Clash 的“连接”或“日志”页面没有新增相应请求。

如果三项同时成立，可以继续处理 Loopback Exempt，也就是为指定应用添加本机回环访问豁免。它只改变该 AppContainer 是否允许连接本机地址，不会替代代理规则，也不会自动选择节点。最终流量仍由 Clash 当前的规则模式、策略组和 DNS 设置决定。

回环限制为什么会挡住本机 Clash 端口

Windows 商店应用通常运行在带有应用身份的隔离容器中。系统会按照应用包身份分配网络能力，并限制容器直接访问本机回环地址。设计目标是隔离应用与本机服务，避免应用随意探测运行在 127.0.0.1 上的端口。

Clash 的 HTTP、SOCKS 或 mixed-port 监听器恰好是本机服务。常见配置把混合端口设为 7890：

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

开启系统代理后，Windows 会把支持系统代理的请求交给 127.0.0.1:7890。普通桌面程序可以建立这条本机连接；受限制的 AppContainer 则可能在到达端口前被系统拒绝。因此，节点延迟即使只有 45 ms，Microsoft Store 仍可能无法加载，而 Clash 日志里也看不到一次完整的代理握手。

检查位置	正常结果	异常含义
浏览器联网	网页正常打开	Clash 基础链路仍有问题
本机监听端口	127.0.0.1:7890 正在监听	端口配置或客户端启动异常
Clash 连接面板	商店刷新时出现新连接	完全没有记录时优先检查回环限制
规则命中	请求进入指定策略组	进入 Clash 后失败应检查规则、DNS 或节点

回环豁免解决的是“应用能否连接本机代理”这一段。它不处理订阅失效、策略组选错、规则误判或远端节点超时。排查时把链路拆成“应用 → 本机 Clash 端口 → 代理规则 → 节点 → 目标服务”，可以避免反复更换节点却没有触及真正的阻断位置。

使用 Clash 客户端内置的 UWP Loopback 工具

部分 Windows 图形客户端提供 UWP Loopback 管理入口，底层仍是调用 Windows 的回环豁免机制。不同客户端和版本的菜单名称略有差异，常见路径包括“设置”→“系统设置”→“UWP Loopback”，或“常规”→“UWP 回环”→“启动工具”。旧版 Clash for Windows 常把入口放在 General 页面，按钮名称可能显示为 UWP Loopback。

图形界面操作步骤

先退出 Microsoft Store、Xbox 等需要处理的应用，避免旧连接继续占用。
打开 Clash 客户端，确认系统代理已开启，记下“设置”→“端口设置”中的 mixed-port 或 HTTP 端口。
进入“设置”→“系统设置”→“UWP Loopback”。如果客户端要求管理员权限，确认后继续。
等待工具枚举应用包，在列表中找到 Microsoft Store。其包身份通常包含 Microsoft.WindowsStore。
勾选 Microsoft Store；若 Xbox、照片或其他商店应用也存在同样问题，可按实际需要分别勾选。
点击“保存”“应用”或“Save Changes”，等待工具提示设置完成。
重新打开 Microsoft Store，进入任意应用详情页并刷新，再观察 Clash 的连接面板。

应用列表里可能同时出现显示名称相似的条目。判断时优先看包名或 Package Family Name，而不是只看图标。Microsoft Store 常见的包族名称是 Microsoft.WindowsStore_8wekyb3d8bbwe；Windows 应用安装器通常是 Microsoft.DesktopAppInstaller_8wekyb3d8bbwe。两者用途不同，需要处理哪个就放行哪个。

保存后通常不需要重启 Windows，但应完全关闭并重新打开目标应用。若 Microsoft Store 仍保留旧状态，可以在任务管理器结束对应进程，再启动一次。也可以按 Win + R，运行 wsreset.exe 清理商店缓存；该步骤用于处理缓存和界面状态，不负责添加回环豁免。

客户端没有入口时用命令行手动放行

Windows 自带的 CheckNetIsolation.exe 可以查看、添加和删除 AppContainer 回环豁免。手动操作的关键是取得准确的 Package Family Name，不能只把应用显示名称填进命令。

第一步：查询 Microsoft Store 包族名称

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

Get-AppxPackage Microsoft.WindowsStore |
  Select-Object Name, PackageFamilyName

常见输出如下，具体结果应以当前电脑为准：

Name              PackageFamilyName
----              -----------------
Microsoft.WindowsStore Microsoft.WindowsStore_8wekyb3d8bbwe

如果要查找名称中包含 Xbox 的应用，可以使用：

Get-AppxPackage *Xbox* |
  Select-Object Name, PackageFamilyName

第二步：添加回环豁免

确认包族名称后，在管理员终端中执行：

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

参数 -a 表示添加，-n 后面必须是完整的 Package Family Name。命令执行成功后，关闭 Microsoft Store，再重新打开测试。

第三步：检查当前豁免列表

CheckNetIsolation.exe LoopbackExempt -s

输出列表中应能找到刚才添加的包身份。若列表里没有目标项，可能是终端权限不足、包族名称拼写错误，或复制时带入了多余空格。重新从 PowerShell 查询结果复制一次，再执行添加命令。

需要撤销时删除豁免

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

-d 表示删除。修改后再次运行 LoopbackExempt -s，即可确认目标项是否已经移除。回环豁免按应用包身份保存；应用更新通常不会改变包族名称，但卸载后重新安装、系统迁移或应用包身份变化时，建议重新检查列表。

放行后如何确认 Microsoft Store 已经过 Clash

只看到商店页面恢复并不足以判断流量路径，因为页面内容可能来自缓存。更可靠的验证方式是同时观察应用行为、Clash 连接记录和规则命中结果。

验证一：观察连接面板

打开 Clash 客户端的“连接”页面，并清空现有筛选条件。
完全关闭 Microsoft Store，然后重新打开。
进入一个此前没有打开过的应用详情页，切换截图或点击“检查更新”。
查看连接面板是否出现新的 HTTPS 连接，目标域名可能属于 Microsoft 的商店、许可、内容分发或账户服务。

如果请求已经出现，说明 UWP 应用至少能够访问本机 Clash 端口。接下来要看该连接命中了哪个规则和策略组。若连接显示为 DIRECT，这是规则结果，不代表回环豁免失败；若希望特定域名经过代理，应检查当前规则集，而不是重复添加豁免。

验证二：检查端口与系统代理是否一致

在 PowerShell 中检查常用的 7890 端口：

Get-NetTCPConnection -LocalPort 7890 -State Listen

若没有结果，回到 Clash 的“设置”→“端口设置”，查看实际 mixed-port。部分配置使用 7897、1080 或其他端口。Windows 的“设置”→“网络和 Internet”→“代理”中，地址和端口必须与客户端当前监听值一致。端口冲突导致 Clash 改用其他值时，旧的系统代理设置也会造成商店连接失败。

验证三：进行可重复的商店操作

打开 Microsoft Store 的“库”页面，点击“获取更新”。
选择一个体积较小的应用，观察下载是否从“正在等待”进入实际进度。
在 Clash 日志中确认请求不再出现连续的连接超时或 DNS 错误。
切换策略组节点后重复刷新，确认新连接使用了当前选定策略。

一次下载成功只能说明当时链路可用。建议连续测试两次，并在关闭、重新打开 Microsoft Store 后再测一次。这样可以排除缓存、已建立连接和短时网络恢复带来的误判。

仍然无法连接时按固定顺序排查

添加回环豁免后，问题位置通常会从“应用无法访问本机端口”转移到 Clash 内部或上游网络。此时不要重复勾选同一个应用，应按下面顺序逐层确认。

1. 确认配置与端口正在生效

Clash 客户端状态应为运行中，配置文件已成功载入。
系统代理地址应是 127.0.0.1，端口与 mixed-port 或 HTTP 端口一致。
若配置中仅开启 SOCKS 端口，不应直接把该端口当作 Windows HTTP 系统代理使用。
修改 YAML 后先检查缩进，再在客户端中重新载入配置。

2. 检查规则模式和策略组

规则模式会逐条匹配目标域名。Microsoft Store 涉及账户、许可、应用元数据和内容分发等多个服务，不能只依据一个域名判断整体结果。连接面板显示请求后，重点查看 Rule、Chains 或策略组字段。若规则把部分服务送往不可用节点，商店可能表现为图片可见但下载失败。

临时诊断时可以把目标策略组切换到一个已确认可用、延迟约 50 至 150 ms 的节点，再重试商店更新。全局模式可用于短时对照，但测试结束后应恢复日常使用的规则模式，继续定位具体规则。

3. 检查 DNS

当连接已经进入 Clash，但日志出现域名解析失败、超时或返回异常地址时，应检查 DNS 配置。使用 mihomo 内核时，确认配置中的 dns.enable、监听地址、nameserver 和增强模式相互匹配。若开启 Fake-IP，还要保证系统流量确实由 Clash 接管，避免应用使用另一套 DNS 路径后产生解析与连接不一致。

4. 检查防火墙和安全策略

本机防火墙可能阻止 Clash 监听端口或限制应用容器网络。先确认 Clash 主程序和所用内核能够在当前网络配置文件中运行，再查看是否存在针对 127.0.0.1:7890 或对应进程的阻止规则。公司设备还可能通过组策略管理 Microsoft Store、代理和 AppContainer 网络能力，这种情况下本地修改可能被策略覆盖。

5. 区分系统代理与 TUN 模式

系统代理模式依赖应用主动读取 Windows 代理设置，因此 UWP 回环豁免与本机代理端口直接相关。TUN 模式则通过虚拟网络接口接管更多流量，对不遵循系统代理的程序更有效。启用 mihomo TUN 后，部分商店应用可能不再依赖传统的 127.0.0.1 HTTP 代理路径。

但 TUN 不是回环问题的通用替代步骤。它还涉及管理员权限、服务模式、路由、DNS 劫持和防火墙兼容性。如果当前只有 Microsoft Store 异常，而其他程序通过系统代理稳定工作，优先添加目标应用的 Loopback Exempt，改动范围更小。只有多类程序都不遵循系统代理，或确实需要接管 UDP 等流量时，再评估 TUN 模式。

常见误区与处理结论

开启系统代理等于自动解除 UWP 限制

系统代理只告诉应用代理服务器的位置。AppContainer 能否访问这个本机位置，由回环策略单独决定。两项必须分别确认。

端口写成 7890 就一定正确

7890 是常见默认值，不是固定要求。配置文件、客户端覆写设置或端口占用都可能改变实际监听值。应以当前客户端界面和监听结果为准。

放行 Microsoft Store 会同时覆盖所有商店应用

豁免按包族名称记录。Microsoft Store、应用安装器、Xbox 和其他应用通常拥有不同包身份，需要按实际故障分别查询和添加。

连接进入 Clash 就代表代理链路完整可用

连接出现只证明应用已到达本机代理。后续仍可能因规则命中、DNS、节点握手、远端服务限制或网络策略失败。继续查看日志中的错误阶段，才能判断下一步。

最终可按一个简化结论处理：普通桌面程序正常、商店应用没有任何 Clash 连接记录时，检查 UWP 回环豁免；连接记录已经出现但请求失败时，转查端口、规则、DNS 和节点；多个程序同时异常时，回到 Clash 基础链路和本机网络排查。按这个顺序操作，通常能把问题限定在一个明确层级。