Windows UWP 应用无法连接代理：回环限制解除与验证步骤

先确认是不是 UWP 回环问题

不要看到“商店打不开”就直接修改回环豁免。Microsoft Store、邮件、部分媒体应用和其他商店应用无法连接，可能来自系统代理未开启、Clash 内核未运行、规则错误、DNS 失败、账户服务异常或 Windows 服务状态异常。回环限制只解释一种特定现象：应用需要通过本机代理连接，但 AppContainer 阻止了它访问这个本机监听地址。

最有代表性的故障组合是：传统桌面浏览器可以通过 Clash 正常访问；Clash 的系统代理开关已经启用；目标 UWP 应用直接提示无网络、持续加载或连接失败；关闭系统代理后，该应用可能恢复直连，也可能因网络环境而继续失败。此时应先记录当前模式、代理端口和应用名称，再做定向处理。

建议按以下顺序建立基线

1. 确认 Clash 客户端显示内核正在运行，而不是只有界面进程处于打开状态。
2. 用普通桌面浏览器访问一个可用站点，确认系统代理链路至少对 Win32 应用有效。
3. 在 Clash 连接记录中搜索目标域名，观察启动 UWP 应用时是否产生新连接。
4. 记录客户端设置中的 HTTP 端口或混合端口，并确认系统代理实际指向同一个端口。
5. 完全退出目标应用后重新打开，避免后台进程继续复用修改前的连接。

如果启动目标应用时，Clash 连接列表完全没有相关请求，而浏览器请求可以正常出现，回环限制就是优先检查项。反过来，如果请求已经进入 Clash，并明确显示规则命中、DNS 错误或节点连接失败，那么流量已经越过 AppContainer 到本地代理，问题应转向规则、DNS 或上游节点。

为什么系统代理正常，UWP 应用仍然失败

Clash 或 mihomo 在 Windows 上运行时，通常会监听本机端口。例如混合端口可能监听在 127.0.0.1:7890，同时接受 HTTP 和 SOCKS 协议；某些客户端也会分别设置 HTTP 与 SOCKS 端口。开启系统代理后，Windows 会把代理地址写入当前用户的网络设置，使用该设置的应用随后把请求发送到本机 Clash 端口。

对普通桌面程序而言，访问 127.0.0.1 是常规本机通信。UWP 应用及部分打包应用则可能运行在 AppContainer 沙箱中。AppContainer 对网络能力和本机回环访问设置了边界，目的是避免隔离应用任意连接同一台设备上的其他服务。结果是：应用虽然读到了系统代理地址，却无法连接该地址，网络请求还没到 Clash 内核就已经失败。

回环豁免并不是把应用本身改成“强制代理”，它只允许指定 AppContainer 访问本机回环接口。应用是否读取系统代理、是否绕过代理、是否使用 UDP 或 QUIC，仍由应用实现和 Windows 网络栈决定。因此，添加豁免后还需要通过连接记录验证流量路径，不能只看应用界面是否短暂恢复。

解除目标应用的回环限制

部分 Clash Windows 客户端会提供“UWP 回环”“Loopback”或“解除回环限制”入口。该入口通常调用 Windows 的回环豁免机制，并显示已安装的 AppContainer 应用列表。优先只选择确实需要通过本地代理联网的应用，例如出现问题的 Microsoft Store 或具体商店应用，不建议在没有确认范围时一次勾选全部项目。

方法一：使用客户端内置的 UWP 回环工具

1. 以正常方式启动 Clash 客户端，并确认内核已成功加载配置。
2. 打开设置、通用设置或服务工具区域，寻找名称包含 UWP、Loopback 或“回环”的入口。
3. 在应用列表中找到目标程序。列表可能显示应用名称、包名称或包族名称，注意区分相似条目。
4. 勾选目标程序并保存，使 Windows 为对应包添加回环豁免。
5. 关闭目标应用的全部窗口，并在任务管理器中确认其后台进程已经结束，然后重新启动应用。

不同客户端的菜单位置并不统一，有些现代客户端没有集成图形化回环工具。没有入口不代表 mihomo 内核缺少代理能力，因为回环限制属于 Windows AppContainer 策略，不是 Clash 规则引擎中的选项。这种情况下可以使用 Windows 自带命令检查和修改。

方法二：使用 PowerShell 查找包族名称

先打开 PowerShell，按应用显示名称或包名称查找对应的 PackageFamilyName。下面的命令列出当前用户安装的应用包及包族名称：

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

如果列表较长，可以按关键词筛选。例如查找名称中包含 Store 的应用：

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

找到准确的包族名称后，在终端中执行回环豁免添加命令。应把示例值替换为查询到的真实 PackageFamilyName：

CheckNetIsolation.exe LoopbackExempt -a -n="目标应用的PackageFamilyName"

命令中的 -a 表示添加，-n 后面必须是包族名称，而不是开始菜单显示名称，也不是安装目录名称。名称输入错误时，命令可能失败，或者修改了非预期包。执行前应从 PowerShell 输出中复制完整值。

查看和撤销已有豁免

要查看当前回环豁免列表，可以执行：

CheckNetIsolation.exe LoopbackExempt -s

如果测试结束后不再需要某项豁免，可使用删除命令恢复该应用的默认限制：

CheckNetIsolation.exe LoopbackExempt -d -n="目标应用的PackageFamilyName"

从本机端口到规则命中的完整验证

添加豁免只是修改权限，验证时要逐层确认。建议暂时保持 Clash 在规则模式运行，因为规则模式能在连接记录中显示域名、目标地址、命中规则和策略组，比全局模式更适合判断请求是否按预期分流。

第一步：核对监听端口

在 Clash 客户端中查看当前混合端口或 HTTP 端口，再检查 Windows 系统代理。两边端口必须一致。例如客户端监听 127.0.0.1:7890，系统代理却残留为 127.0.0.1:7897，所有读取系统代理的应用都会连接错误位置。切换过不同 Clash 客户端时，这类端口残留尤其常见。

还要确认配置中的监听地址没有被改成仅适用于其他接口的值。只供本机应用使用时，监听回环地址通常足够；局域网共享涉及 allow-lan、监听地址和防火墙，是另一条配置路径，不应为了修复单机 UWP 应用而直接开放局域网访问。

第二步：重新启动目标应用

不少 UWP 应用关闭窗口后仍保留后台任务。修改回环豁免后，应从任务管理器结束对应进程，或者注销当前 Windows 用户再登录。若应用仍复用旧连接，会造成“设置已经添加但没有生效”的误判。

第三步：观察 Clash 连接和日志

重新打开应用并触发一次明确的联网操作，例如刷新页面、检查更新或加载账户信息。随后查看 Clash 的连接列表：

• 出现目标域名并成功传输数据，说明回环、本机端口和代理入口已经连通。
• 出现域名但规则命中错误，应调整规则顺序、规则集引用或策略组选择。
• 出现连接但节点握手失败，应测试策略组中的其他可用节点。
• 完全没有请求，应继续确认应用是否使用系统代理、豁免对象是否选对，以及应用是否走了不受该代理入口处理的协议。

第四步：做一组开关对照

保持其他条件不变，分别测试“系统代理开启”和“系统代理关闭”。如果开启时应用失败、关闭后直连正常，而且 Clash 中始终没有该应用请求，通常仍是本机代理入口或回环权限问题。如果两种状态都失败，则应检查应用服务、Windows 网络、账户状态和 DNS，而不是继续重复添加豁免。

解除回环后仍无法连接的排查顺序

如果目标应用已经出现在豁免列表中，但仍不能正常联网，应从代理入口继续向后检查。以下问题与回环限制表现接近，却需要不同处理。

系统代理地址或端口残留

Windows 系统代理可能保留上一个客户端的端口，尤其是在客户端异常退出、切换便携版和安装版，或多个代理工具交替使用之后。先关闭其他代理软件，再让当前 Clash 客户端重新设置一次系统代理。不要只根据客户端按钮状态判断，应核对 Windows 中实际保存的代理地址。

应用没有使用系统代理

并非所有应用都遵循当前用户的系统代理设置。有些程序自行实现网络栈，有些连接使用 UDP 或 QUIC，有些后台组件通过不同服务进程发起请求。此时即使回环豁免正确，HTTP 系统代理也未必能接管全部流量。可以测试 mihomo 的 TUN 模式，但启用前应确认客户端具有所需权限、虚拟网卡组件可用，并了解 DNS 接管和路由变化。

TUN 模式从网络层接管流量，与“让应用主动连接 127.0.0.1 系统代理”不是同一机制。它常用于不读取系统代理的应用，但并不保证修复所有 UWP 问题。若 TUN 开启后依旧没有请求，应检查路由排除、接口冲突、安全软件策略和应用自身服务状态。

规则把必要请求分配到错误策略

Microsoft Store 等应用可能同时访问内容分发、账户、证书和更新服务。只看到主域名成功并不代表全部依赖请求都正常。检查连接记录中失败或反复重试的域名，确认规则从上到下的匹配顺序。Clash 命中一条规则后不会继续检查后续规则，因此过于宽泛的前置规则可能覆盖后面的精确规则。

排查阶段可临时切换到一个已确认可用的策略组做对照，但不建议直接长期使用全局代理掩盖规则问题。确定具体域名和失败原因后，再把修正写入规则配置，并保留最终兜底规则。

DNS 解析与代理连接分属不同阶段

日志若显示域名解析失败、返回异常地址或持续超时，应检查当前配置的 dns 段、解析服务器可达性和 Clash DNS 监听状态。使用 fake-ip 时，还要确认应用是否对虚拟地址或特定域名存在兼容性要求。不要因为症状发生在 UWP 应用中，就跳过 DNS 层检查。

端口冲突与内核未成功加载

客户端界面可以打开，不等于代理端口已经监听。配置语法错误、端口被占用或内核启动失败时，系统代理仍可能指向一个没有服务的地址。查看客户端日志中的配置加载结果和监听错误，必要时更换未被占用的端口，并同步更新系统代理。

企业策略或受管设备限制

公司设备、学校设备和启用了集中管理策略的 Windows 环境，可能通过组策略、防火墙或终端防护限制 AppContainer、本地代理和网络接口。命令返回成功也不代表策略不会随后覆盖设置。此类环境应先确认设备管理要求，不要持续修改被集中控制的配置。

恢复测试清单

完成修改后，可以按下面的清单做最后确认。每一项都能对应一个明确层级，便于以后复现和回退。

• Clash 或 mihomo 内核启动成功，当前配置没有解析错误。
• 本机 HTTP 或混合端口处于监听状态，端口未被其他程序占用。
• Windows 系统代理地址与当前客户端端口一致。
• 目标 UWP 应用对应的包族名称已加入回环豁免列表。
• 修改后已完全结束并重新启动目标应用。
• Clash 连接记录中可以看到应用产生的域名或目标地址。
• 请求命中了预期规则和策略组，上游节点能够正常建立连接。
• DNS 查询没有持续超时，解析结果符合当前配置模式。
• 测试完成后撤销不再需要的临时改动，并记录最终有效设置。

判断修复成功的标准不只是“页面能打开”，而是目标请求稳定进入 Clash、命中预期规则并完成传输。通过这种分层验证，可以区分 AppContainer 权限、本机代理端口、规则、DNS 和节点问题，避免在同一个设置上反复操作。