Windows 11 上 UWP 与商店应用不走 Clash？用环回豁免核对系统代理与分流

先分清两类「不走代理」

第一类是根本没碰到 Clash 监听端口：系统代理对 Win32 程序生效，但 UWP 容器内的网络栈默认禁止访问 127.0.0.1 上的本机服务，于是你的 Clash 即便开着 系统代理，应用也连不上本地 mixed／HTTP 端口，表现就像「完全不走代理」。第二类是已经进 Clash，但被规则或 DNS 送走：连接日志里能看到进程或目标域名，但命中了直连、错误策略组，或解析路径与规则不一致。本文前半解决第一类；若环回已放行仍异常，再按后半段核对分流与解析。

为什么 UWP 与商店应用对「系统代理」特别挑剔

传统桌面程序常通过 WinINet／WinHTTP 读取用户级或计算机级的代理设置；而许多商店分发的应用跑在 AppContainer 里，出于安全模型，默认禁止向本机环回发起连接。Clash 类客户端在「仅系统代理」模式下，通常是在本机回环地址上监听端口，再把流量转发到上游节点——这与 UWP 的默认限制正好撞上。于是你会看到极端反差：Microsoft Store 里应用更新失败，而同一台机器上安装的 Win32 浏览器访问外网完全正常。理解这一点后，排错目标就从「换一个更快的节点」变成「让目标应用能够合法访问本机代理端口」，再配合规则精细化。

第一步：确认 Clash 的「系统代理」端口与开关

打开你正在使用的客户端（例如 Clash Verge 系列），确认系统代理已开启，并记下 HTTP／SOCKS 或 mixed 端口是否与 Windows 设置里一致。可在 Windows「设置 → 网络和 Internet → 代理」中查看手动代理地址是否为 127.0.0.1 加对应端口。若你刚重装或切换过内核，偶尔会出现 GUI 显示已开、系统设置未写入的情况，此时应先回到首次安装与系统代理排查那篇文章里的顺序，把「代理写入系统」这一步做实，再讨论 UWP。否则后面做再多 Loopback 豁免也是连错端口。

第二步：用连接日志判断流量有没有进 Clash

在复现问题的同时打开 Clash 的连接日志或实时连接面板。若点击商店下载、登录 Xbox 账号时完全没有新连接，优先怀疑环回隔离或应用未使用系统代理；若日志里已经出现相关域名，但延迟极高或握手失败，再转向节点质量、TLS 拦截、DNS 与分流顺序。不要把两类问题混在同一轮修改里，否则你会在「加规则」和「换节点」之间空转。对于需要进程级接管的场景，也可以对照TUN 模式深度解析考虑是否改用 TUN 统一接管，但 TUN 涉及驱动与路由优先级，仍建议先完成本机代理路径的确认。

第三步：CheckNetIsolation 与环回豁免（LoopbackExempt）

微软提供 CheckNetIsolation 工具用于诊断与配置网络隔离。要对某个应用包放行本机环回，需要它的程序包系列名（Package Family Name，PFN）。在管理员权限的 PowerShell 中，可用 Get-AppxPackage 查询，例如商店常用包名类似 Microsoft.WindowsStore 开头的一行，其 PackageFamilyName 字段即后续命令需要的值。放行示例（请把 PFN 换成你机器上查到的真实字符串）：

# Run in elevated PowerShell; replace PFN with your PackageFamilyName from Get-AppxPackage
CheckNetIsolation.exe LoopbackExempt -a -n="Microsoft.WindowsStore_8wekyb3d8bbwe"

-a 表示添加到豁免列表。若不确定 PFN，可先对具体应用执行 Get-AppxPackage *应用关键字* 缩小范围。对 Xbox、Game Bar、截图工具等系统组件，同理查到 PFN 后分别添加。可用 CheckNetIsolation.exe LoopbackExempt -c 清空列表（谨慎使用），或 -d 删除单条豁免。操作完成后完全退出并重启目标 UWP 应用再测，避免旧进程缓存网络栈状态。

批量放行与「全家桶式」豁免的取舍

社区中偶见一次性豁免大量 UWP 的脚本，短期能省事，但从攻击面看，等于放宽了一批应用对本机服务的访问边界。更稳妥的做法是：只为确实需要走本机代理且你信任其厂商的包添加豁免；其余保持默认隔离。若你同时运行公司 VPN、其他「加速器」或抓包工具，也要避免它们与 Clash 争抢同一环回端口或重复改写系统代理，否则日志里会出现间歇性「有时进有时不进」的假阳性。

第四步：若日志已出现连接，核对分流与规则顺序

当 Microsoft Store 或 Xbox 相关流量已经进入 Clash，却仍提示区域不可用或下载失败，需要区分「平台业务限制」与「网络路径问题」。网络路径侧请检查：相关域名是否被过宽的 GEOIP,CN,DIRECT 提前命中；是否存在应走代理的 CDN 域名被误直连；以及 MATCH 兜底是否把未知流量送到了错误策略组。具体写法可参考自定义规则教程：让指定 App 走指定节点，记住更精确的 DOMAIN 规则应排在过宽规则之前，并结合连接日志增量维护，而不是一次导入巨型规则集。

第五步：DNS、fake-ip 与「看起来像没代理」的错觉

部分商店接口在 DNS 阶段就会因污染或错误解析落到不可达地址，表现为秒失败，容易误判为「没走 Clash」。建议在问题窗口内固定使用 Clash 内置 DNS 或你明确理解的 DoH 配置，避免系统 DNS、路由器 DNS 与 Clash DNS 混用导致解析与规则脱节。若启用 fake-ip，要同时理解哪些规则需要 no-resolve、以及客户端是否会缓存旧解析结果。整体思路与Docker Desktop 与 Win11 宿主机代理、DNS 对齐一文里强调的「同一时刻只保留一条清晰的解析路径」是一致的，只是本文面向的是 UWP 侧环回与系统代理。

TUN 模式是否是「银弹」

TUN 通过虚拟网卡把流量导入 Clash，往往能绕过「应用不读系统代理」或部分沙箱限制，但并非没有代价：驱动签名、路由优先级、与公司 VPN 冲突、以及游戏反作弊对虚拟网卡的敏感等，都是需要纳入评估的变量。若你仅在少数 UWP 上遇到麻烦，优先用 Loopback 豁免通常更轻量；若整机多类应用都存在接管困难，再阅读TUN 模式权衡是否切换。切忌在未读日志的情况下同时打开系统代理与多个 TUN 类软件，否则排错会指数级变难。

与 WSL、Docker 场景的边界

WSL2 与 Windows 共用 Clash讨论的是虚拟网卡与 localhost 转发；Docker Desktop讨论的是引擎独立网络栈。UWP 环回问题与上述场景机制不同，但日志驱动的排查方法相同：先看连接是否进入 Clash，再分层处理。把三类笔记分开保存，日后遇到「只有某一个容器／子系统不正常」时能快速定位，而不是每次都从零重装客户端。

推荐排查顺序（检查表）

1. 确认 Clash 已运行，系统代理端口与 Windows 设置一致。
2. 复现问题时观察连接日志：无连接则优先 Loopback 豁免。
3. 用 Get-AppxPackage 取得 PFN，CheckNetIsolation.exe LoopbackExempt -a -n="..." 添加后重启应用。
4. 若日志已有连接，检查分流命中顺序、GEOIP 与兜底策略。
5. 对齐 DNS 与 fake-ip 行为，一次只改一类变量。
6. 仍复杂时再评估 TUN 或排除多代理冲突。

常见问题

小结

Windows 11 上 UWP 与 Microsoft Store 类应用「看起来不走 Clash」，很多时候是环回隔离挡住了对本机代理端口的访问，而不是订阅失效。用 CheckNetIsolation 做 Loopback 豁免后，再按连接日志核对系统代理、分流与 DNS，就能把大部分「只有商店不正常」的案例收敛到可复现的几步操作里。与仅讨论安装或局域网放行的文章相比，本文补齐了桌面代理在 WinRT 应用上的最后一块常见盲区。

相比在论坛帖子里碎片化试错，使用维护积极的客户端、从本站下载页获取安装包并配合使用教程建立固定排错顺序，长期成本更低。规则型代理在可观测性与分流精度上仍具优势；当你需要让系统组件与商店应用稳定走出口时，先把环回豁免与系统代理对齐，再谈节点与规则细节，会少踩很多冤枉路。→ 立即免费下载 Clash，开启流畅上网新体验。