问题排查 预计阅读 10 分钟

Windows 商店应用不走代理:UWP 回环豁免设置与 CheckNetIsolation 用法

解释 UWP 应用默认禁止访问本机回环地址的原因,演示图形工具与命令行两种豁免方式,并说明如何撤销与验证效果。

先判断：是回环受限，还是应用没有使用代理

浏览器能够通过 Clash 客户端访问网络，但某个 Windows 商店应用一直加载，并不意味着订阅失效。若客户端把 HTTP 或混合代理入口监听在 127.0.0.1，而目标应用运行于受限制的 AppContainer 中，应用可能无法连接这个本机入口。此时，UWP 回环豁免是值得检查的一项设置。

不过，Microsoft Store 是应用分发渠道，不是运行模型。商店里的传统 Win32 软件、打包桌面应用和 UWP 应用，网络限制并不完全相同。只有确认涉及 AppContainer 的回环限制，豁免设置才有针对性；不能把“商店安装”直接等同于“必须添加豁免”。

观察到的现象优先检查
浏览器和目标应用都不能联网代理端口、配置是否加载、节点可用性及系统代理地址。
浏览器正常，单个容器应用失败应用是否使用系统代理，以及该应用的回环豁免。
客户端中出现目标连接，但命中 DIRECT规则顺序与代理组选择，而不是重复添加豁免。
启用 TUN 后仍失败流量是否被接管、DNS 与路由、应用服务端响应；不能只凭结果认定回环受限。

UWP、AppContainer 与 127.0.0.1 的关系

127.0.0.1 是 IPv4 回环地址，连接不会发往局域网中的其他机器。Clash 系列图形客户端通常在本机启动内核，再通过 HTTP、SOCKS 或混合端口接收应用请求。Windows 系统代理可以告诉遵循该设置的应用：把请求交给这个本地入口。

AppContainer 则是 Windows 的应用隔离机制。它按应用身份和能力约束资源访问，其中包括网络访问边界。即使代理服务运行在同一台电脑上，受限制的容器也不一定可以连接它。CheckNetIsolation.exe 提供的 LoopbackExempt 子命令用于管理这类回环例外。

与 TUN 模式的区别

  • 系统代理路径：应用先读取代理设置，再主动连接本机代理端口；回环限制可能发生在这一步。
  • TUN 路径：客户端通过虚拟网络接口和路由接管匹配的 IP 流量，通常不要求应用主动连接 HTTP 代理端口。
  • 适用边界：TUN 的实际效果还受路由、DNS、权限和应用行为影响。它不是“添加了所有回环豁免”的另一种名称。

排查时先保留一种明确的接管方式。例如先关闭 TUN，只测试系统代理与单个应用的回环访问。不要同时修改代理模式、DNS、规则和豁免，否则恢复联网后也难以确定是哪项设置起作用。

操作前：核对代理入口与测试基线

下面以 127.0.0.1:7890 为示例。7890 不是所有客户端的固定端口，应以当前客户端设置和实际生效的配置为准。mihomo 配置中的 mixed-port 同时提供 HTTP 与 SOCKS 服务；单独的 socks-port 则不能当作 Windows HTTP 系统代理入口填写。

  1. 在客户端设置中核对 HTTP 或混合端口，确认内核正在运行。
  2. Windows 11 打开「设置」→「网络和 Internet」→「代理」→「手动设置代理」→「使用代理服务器」，查看地址和端口。Windows 10 可在「设置」→「网络和 Internet」→「代理」中查看。
  3. 如果这些设置由客户端维护，应通过客户端开关调整，避免系统界面与客户端状态互相覆盖。
  4. 记录目标应用名称、失败操作和发生时间，便于稍后在连接列表或日志中对应。

可在 PowerShell 中先确认示例端口是否能够建立 TCP 连接，再显式指定代理发出一个 HTTPS 请求：

Test-NetConnection -ComputerName 127.0.0.1 -Port 7890
curl.exe --proxy http://127.0.0.1:7890 --head --max-time 15 https://www.microsoft.com/

TcpTestSucceeded : True 只说明端口可连接；HTTP 响应则可帮助判断代理链路是否建立。远端返回 403 等状态不等于代理端口失效。这里使用 curl.exe，是为了避免 Windows PowerShell 中 curl 别名带来的参数差异。

这两项检查由桌面进程发起，不能证明 UWP 应用已经获得回环权限。如果基线测试就失败，应先解决监听端口或上游连接问题，而不是继续调整容器权限。也不要为此开启“允许局域网”或把监听地址改成 0.0.0.0；扩大监听范围与添加回环豁免是两件事。

命令行方式：查询、添加与删除回环豁免

1. 记录现有列表，查找准确的包标识

在开始菜单搜索 PowerShell，选择「以管理员身份运行」。如果使用其他管理员账户的凭据提权，包查询可能对应另一个用户；应先在目标应用所属用户会话中查询包信息，再到提权窗口执行变更。

CheckNetIsolation.exe LoopbackExempt -s

Get-AppxPackage |
  Sort-Object Name |
  Select-Object Name, PackageFamilyName

-s 用于显示已有豁免。添加前保存输出或截图，便于判断某项设置原本是否存在。Get-AppxPackage 默认列出当前用户的包；按显示名称猜测包名容易出错，应从输出读取 PackageFamilyName。

例如查询 Microsoft Store 自身的包身份，可以执行：

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

常见结果中的包系列名称为 Microsoft.WindowsStore_8wekyb3d8bbwe。它与包含版本号、架构等信息的 PackageFullName 不同；下方 -n 参数应使用包系列名称。若查询没有输出，先确认应用是否安装在当前账户下，不要把显示名称直接拼进命令。

2. 仅为目标应用添加豁免

下面的示例针对 Microsoft Store 本身，不会顺带给商店下载的其他应用授权。只有实际查询结果与示例一致时才直接执行；其他应用需要使用各自查到的包系列名称。

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

执行后核对列表中是否出现对应身份，并查看命令是否返回错误。若提示拒绝访问，先检查终端是否已提权；若提示名称或参数问题，重新核对包身份和英文半角引号。成功加入列表之后，彻底关闭目标应用再重开，避免复用原先失败的连接。

3. 撤销本次添加

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

-d 删除指定应用的豁免。只撤销本次新增的项目：如果它在操作前就已经存在，不应为了测试而直接删除。不要运行批量授权所有包的脚本，也不要用清空全部列表来代替定向撤销，已有开发工具或其他应用可能依赖其中的条目。

图形方式：用回环列表勾选目标应用

Windows「设置」没有通用的 UWP 回环豁免复选框。如果电脑已经安装 Fiddler Classic，可以使用其 WinConfig 工具栏入口打开回环豁免工具；部分界面也可从「Tools」→「Win8 Loopback Exemptions」进入。虽然入口保留 Win8 字样，管理的仍是 Windows AppContainer 回环设置。

  1. 先完成前面的代理端口核对，并记录当前系统代理值。
  2. 打开 Fiddler Classic，将「File」→「Capture Traffic」取消勾选，避免抓包代理接管当前测试流量。
  3. 打开 WinConfig，按提示批准管理员权限，等待应用容器列表加载。
  4. 只勾选需要排查的目标应用，点击「Save Changes」保存，不使用「Exempt All」批量授权。
  5. 关闭工具与 Fiddler Classic，重新确认系统代理仍指向 Clash 客户端的实际端口，再启动目标应用测试。

撤销时重新进入 WinConfig，取消本次新增的勾选并保存即可。图形工具与命令行管理的是同类系统设置，可用 CheckNetIsolation.exe LoopbackExempt -s 交叉核对。没有安装该工具的电脑，直接使用系统自带命令即可，不必为这一步额外部署抓包环境。

如何验证：应用请求、规则命中与撤销对照

豁免列表出现应用名称，只证明配置已写入，不代表目标功能一定恢复。验证应围绕同一个失败操作进行，例如刷新商店页面或加载应用内的在线内容，并同时观察客户端连接记录。

  1. 固定测试条件：保持相同订阅、代理组和规则模式，关闭抓包工具，记录测试时间。
  2. 重启目标应用：必要时在任务管理器中结束对应进程，再重新打开。仅关闭窗口可能留下后台进程。
  3. 查看连接：在客户端的「连接」或「日志」界面核对目标域名、目标地址、命中规则和出站策略；界面名称以具体客户端为准。
  4. 检查业务结果：区分“请求已进入代理”与“登录或下载成功”。服务端地区限制、账户状态和证书错误仍需单独处理。
  5. 必要时做撤销对照：仅对本次新增项执行删除，再重复操作；测试后按实际需要恢复。

有些连接由系统服务或辅助进程发起，不能只按进程名称筛选。应用也可能先从缓存显示页面，因此单次“打开成功”证据较弱。把时间、目标域名和规则命中合起来看，比只观察窗口能否显示内容更可靠。

如果连接已进入 mihomo，却命中了 DIRECT，回环阶段通常已经不是当前阻断点。此时应检查规则按顺序匹配的结果、规则集是否更新、代理组是否选择了预期策略。规则模式不等于所有流量都通过代理，添加豁免也不会改变这一点。

仍然无效时的排查顺序

列表有豁免，但客户端看不到连接

先确认豁免对应的确实是发起网络请求的包，而不是相似名称的启动器。再检查应用是否遵循 Windows 系统代理、是否有独立代理选项，以及是否已经重启。对不使用系统代理的应用，回环豁免不能凭空创建一条代理路径，可在保留原配置的前提下单独测试 TUN 接管。

客户端能看到连接，但业务仍失败

先检查命中策略和连接错误，再区分 DNS 解析失败、上游超时、TLS 错误与 HTTP 错误响应。应用下载可能涉及多个域名，首页成功不代表内容分发地址也走相同策略。应针对实际失败连接调整，不要直接把所有域名改成同一种出站。

应用更新或重新安装后再次失败

普通版本更新通常不会改变包系列名称，但更换发行渠道、安装预览版或迁移 Windows 账户后，实际包身份可能不同。重新运行包查询和 -s，以当前环境为准。企业设备若由策略管理，应联系管理员确认限制，不要通过关闭防火墙来替代定向授权。

完整的判断链应是：本机代理可用 → 应用确实使用该入口 → 必要的回环权限已放行 → 连接命中预期规则 → 业务请求成功。按这个顺序验证，才能把 Windows 容器限制、客户端设置和远端服务问题分开处理。

下载Clash