浏览器正常、商店应用失败：先判断回环限制
Windows 开启 Clash 系统代理后，浏览器可以访问目标网站，Microsoft Store 或某个 UWP 应用却提示网络不可用，这类差异可能来自 AppContainer 的网络隔离。系统代理通常指向本机地址，例如 127.0.0.1:7890；受隔离的应用访问这个地址时，可能在连接到 Clash 内核之前就被 Windows 拦住。
但“从商店安装”不等于“运行在 UWP 沙盒中”。Microsoft Store 同样分发普通桌面程序，MSIX 也可以包装完整信任的桌面应用。只有先确认目标应用的运行方式，回环豁免才有明确意义。应用忽略系统代理、代理端口填错、登录服务故障，也可能产生相似表现。
三项现象一起检查
- 普通桌面浏览器能访问同一服务：至少说明当前节点与基本代理链路有机会正常工作，但浏览器若装有独立代理扩展，不能据此判断系统代理已生效。
- 目标应用操作时没有对应连接记录：打开 Clash 的连接或日志界面，再刷新应用。没有记录可能表示连接被提前拦截，也可能表示应用根本未使用系统代理。
- 系统代理地址指向本机：检查地址是不是
127.0.0.1、localhost或回环 IPv6 地址::1，端口是否与内核实际监听一致。
UWP 沙盒与 127.0.0.1 的连接关系
回环地址代表当前计算机自身，不代表外网节点。常见连接路径是“应用 → 本机 HTTP 代理端口 → Clash 或 mihomo 内核 → 规则选择的出口”。系统代理设置只是告诉遵循该设置的应用去哪里连接，并不会取消应用自身受到的网络隔离。
UWP 应用通常运行在 AppContainer 中。Windows 默认限制这类应用访问本机回环服务，以维护应用与本地服务之间的隔离边界。即使代理服务已经启动，应用也可能无法建立到 127.0.0.1:7890 的连接。CheckNetIsolation LoopbackExempt 可以为指定应用包配置回环豁免，让它能够访问本机服务。
| 操作 | 实际作用 | 仍需检查 |
|---|---|---|
| 开启系统代理 | 提供本机代理地址与端口 | 应用是否读取系统代理 |
| 添加回环豁免 | 允许指定 AppContainer 访问回环服务 | 代理监听、节点与分流规则 |
| 修改代理规则 | 决定已进入内核的连接走哪个出口 | 连接是否先到达内核 |
| 启用 TUN | 通过虚拟网络接口接入 IP 流量 | 路由、DNS、权限与应用网络行为 |
因此，添加豁免并不等于把应用强制切换到代理出口。连接进入内核以后，仍可能匹配 DIRECT，也可能被 REJECT 拒绝。回环限制与规则分流属于不同层次，排查时应先解决接入，再检查出口。
操作前检查系统代理与监听端口
- 保持 Clash 客户端和内核运行，确认已启用包含有效节点的配置。
- 在 Windows 11 打开「设置」→「网络和 Internet」→「代理」→「手动设置代理」→「使用代理服务器」的「设置」。Windows 10 对应入口也是「设置」→「网络和 Internet」→「代理」，但开关布局不同。
- 检查客户端开启系统代理后写入的地址和端口。若使用本机代理，地址通常为
127.0.0.1，端口应与当前 HTTP 或混合端口一致。 - 在 PowerShell 中检查该端口能否建立 TCP 连接，再进行应用豁免。
Test-NetConnection -ComputerName 127.0.0.1 -Port 7890
netstat -ano | findstr ":7890"TcpTestSucceeded : True 表示当前 PowerShell 进程能连接到这个端口，不表示 UWP 已获准访问，也不表示代理出口已经可用。netstat 的结果应出现对应的 LISTENING 监听记录；若只有其他连接状态，不能把它当成内核已经监听的证明。
方法一：用 CheckNetIsolation 添加指定应用豁免
以下使用 Microsoft Store 作为具体例子。先在受影响的 Windows 用户会话中打开「开始」，搜索 PowerShell，选择「以管理员身份运行」。若通过输入另一位管理员的凭据提权，当前用户上下文会改变，Get-AppxPackage 的默认查询结果可能不再对应受影响用户，需要先确认查询对象。
1. 查找应用包族名称
Get-AppxPackage -Name Microsoft.WindowsStore |
Select-Object Name, PackageFamilyName, PackageFullName添加豁免使用的是 PackageFamilyName，不是显示名称，也不是含版本与架构的 PackageFullName。微软商店常见包族名称为 Microsoft.WindowsStore_8wekyb3d8bbwe，仍应以当前机器的查询结果为准。
如果排查其他应用，可以先列出当前用户的应用包，再用应用名称筛选。应用界面名称与包名称不一定一致，不要仅凭图标文字推断包族名称。
Get-AppxPackage |
Sort-Object Name |
Select-Object Name, PackageFamilyName2. 添加豁免并查看结果
下面的命令从已安装的微软商店包读取名称，避免手动拼写。若找不到包，脚本会停止，而不是继续执行空参数命令。
$store = Get-AppxPackage -Name Microsoft.WindowsStore
if (-not $store) {
throw "当前用户未找到 Microsoft.WindowsStore 应用包"
}
CheckNetIsolation.exe LoopbackExempt -a "-n=$($store.PackageFamilyName)"
CheckNetIsolation.exe LoopbackExempt -s-a：为指定包添加回环豁免。-n=：按包族名称指定应用。-s：显示当前回环豁免列表。
运行后检查列表是否出现目标应用的名称或对应 SID。单纯看到列表非空，不代表刚才添加的应用已经在其中。命令若报告拒绝访问，先确认终端已经提权；若报告参数或包名称错误，重新查询包族名称，不要改用完整包名反复尝试。
3. 重新启动应用并观察连接
关闭目标应用后重新打开，再执行刚才失败的操作。部分应用关闭窗口后仍保留后台进程，可在任务管理器确认目标进程已退出，必要时保存工作后结束该应用进程。通常无需为了添加一条豁免而重启整台电脑。
同时查看 Clash 连接记录中的目标域名、命中规则、策略组和实际节点。若连接已经出现但页面依旧失败，应转向检查分流、DNS、服务地区要求或登录状态；继续添加更多应用豁免不会解决这些问题。
方法二：使用客户端内置的 UWP 回环工具
部分 Windows 图形客户端会提供“UWP 回环”“Loopback”或类似入口，本质上也是维护 Windows 的回环豁免列表。该功能属于客户端界面层，不是 Clash 配置里的通用 YAML 字段，也不是所有 mihomo 客户端都会附带的工具。
历史版 Clash for Windows 0.20.x 的常见入口是「Settings」→「System」→「UWP Loopback」→「Launch Helper」。这一旧版界面路径只用于帮助识别已有安装，不作为选择新客户端的依据。其他客户端应按当前版本的设置界面查找；没有入口时，直接使用上面的系统命令即可。
- 启动回环工具，并按系统提示授予管理员权限。
- 在应用列表中找到真正需要访问本机代理的目标包。
- 勾选该应用并保存更改。若工具提供刷新按钮，安装新应用后先刷新列表。
- 运行
CheckNetIsolation.exe LoopbackExempt -s，交叉确认保存后的系统列表。 - 重启目标应用，检查连接是否进入内核。
撤销回环豁免与保留排查记录
不再使用本机系统代理，或者只是为了验证原因而临时添加豁免时，可以单独撤销目标应用。下面继续沿用微软商店示例，与添加时使用同一个包族名称。
$store = Get-AppxPackage -Name Microsoft.WindowsStore
if (-not $store) {
throw "当前用户未找到 Microsoft.WindowsStore 应用包"
}
CheckNetIsolation.exe LoopbackExempt -d "-n=$($store.PackageFamilyName)"
CheckNetIsolation.exe LoopbackExempt -s-d 删除指定包的豁免，之后再次查看列表确认该项已移除。不建议直接清空整份豁免列表，因为其他应用或开发调试环境可能依赖已有条目。若目标应用已经卸载，需依据之前保存的包族名称或列表中的 SID 定位旧条目，而不是从无结果的应用查询中继续取值。
- 修改前记录目标应用包族名称，以及它是否已经处于豁免列表中。
- 记录当前代理地址、端口与客户端启用的配置名称，便于区分“豁免变化”和“配置变化”。
- 测试完成后保留必要条目；临时放开的应用按项撤销。
TUN 模式替代思路：接管流量而非放开回环
如果应用不读取系统代理，回环豁免本身并不能让它使用 Clash。支持 TUN 的 mihomo 客户端可以通过虚拟网络接口与路由接入 IP 流量，使部分原本直接联网的应用也进入规则处理。这条路径与“应用主动连接本机 HTTP 代理”不同，因此在合适的路由与 DNS 配置下，可绕开对本机代理端口的依赖。
TUN 不是所有 UWP 网络问题的统一解法。如果应用仍然读取系统代理并尝试连接受限的回环地址，单独打开 TUN 未必改变结果。为了隔离变量，可以在记录原设置后关闭系统代理，仅使用 TUN 测试；前提是确认当前客户端确实已接管目标流量。
按顺序验证 TUN
- 检查内核是否支持 TUN。mihomo 与旧 Clash 内核的能力不同，不能仅依据客户端名称判断。
- 按客户端要求安装服务或授予管理员权限，确认虚拟网络接口成功创建。
- 确认自动路由已启用，并检查客户端生成的最终配置，而不是同时复制多段来源不明的 TUN 配置。
- 检查 DNS 请求是否按预期进入内核。DNS 劫持、系统 DNS 和应用自带的加密 DNS可能走不同路径。
- 暂时退出其他 VPN 或网络接管软件，减少默认路由竞争，再测试目标应用。
选择方式可以很直接：应用遵循系统代理、问题集中在回环隔离时，先做单应用豁免；应用绕过系统代理或需要更广的流量接入时，再考虑 TUN。切换到 TUN 后仍须检查规则命中，接管连接不等于所有连接都走代理节点。
常见结果与下一步排查
添加成功，商店仍提示无法连接，下一步检查什么？
先确认目标包确实在豁免列表中，重启应用，再查看内核是否出现连接。有连接时检查是否命中 DIRECT、节点能否访问相关域名，以及系统日期与时间是否准确。商店还可能涉及账号、服务状态和地区限制，应根据应用错误码继续定位，而不是重复执行添加命令。
是否需要使用 netsh winhttp import proxy source=ie？
这条命令把用户代理设置导入 WinHTTP 的代理配置，涉及另一套代理使用场景，不会解除 AppContainer 的回环隔离。不要把它与 CheckNetIsolation 当成同一种修复方式。只有明确目标组件使用 WinHTTP，并理解系统范围影响时，才单独排查该设置。
为什么换了 Clash 客户端后还需要检查豁免？
豁免针对应用包，保存于 Windows，而非某个订阅文件。换客户端通常不会改变目标应用的豁免身份，但可能改变本机监听端口、系统代理地址与接入方式。应用升级后若包族名称保持一致，通常仍可沿用原条目；重新打包或更换发行渠道后应重新查询。
完整排查顺序是：确认内核运行与端口监听，确认系统代理指向正确地址，识别目标应用是否受到 AppContainer 回环隔离，按应用添加豁免，最后查看连接规则与出口。每次只改变一个变量，才能区分 Windows 接入问题与订阅、节点、DNS 或规则问题。