先确认问题是否来自 UWP 回环限制

典型现象是：Clash 已启动，浏览器能够正常访问，传统桌面程序也能使用代理，但 Microsoft Store、旧版邮件、照片、Xbox、部分商店安装应用仍然直连、加载超时或提示网络不可用。此时代理节点和订阅通常没有故障，差异出在 Windows 对 AppContainer 应用的网络隔离规则。

多数 Clash 图形客户端开启「系统代理」后，会把 Windows 代理服务器设置为本机地址，例如 HTTP 代理 127.0.0.1:7890，或者 mixed-port 对应的同一端口。普通 Win32 程序可以连接这个本机监听地址，受 AppContainer 隔离的 UWP 应用默认不能随意访问本机回环接口，因此请求无法送到 Clash 内核。

用四项检查缩小范围

  1. 在 Clash 客户端确认当前配置已经启用，并选择一个能够连接的策略。
  2. 打开「设置」或「常规」，确认「系统代理」处于开启状态。
  3. 在 Windows「设置」→「网络和 Internet」→「代理」中，确认代理地址为 127.0.0.1，端口与 Clash 当前监听端口一致。
  4. 分别测试桌面浏览器和目标商店应用。浏览器正常、目标应用失败，才符合回环隔离的常见特征。

端口不一定固定为 7890。采用 mihomo 内核的客户端可能使用 mixed-port: 7890，也可能由用户改为 7891、7897 或其他未占用端口。诊断时应以当前配置和客户端设置页显示的端口为准。

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

部分 Windows 图形客户端集成了回环豁免管理器。这种方式适合不熟悉包族名称和命令行的用户。工具本质上仍在修改 Windows 的 AppContainer 回环豁免列表，客户端退出后，已经写入系统的规则通常不会立即消失。

常见入口与操作顺序

不同客户端的菜单名称略有区别。经典 Clash for Windows 常见入口为「General」→「UWP Loopback」→「Launch Helper」；其他客户端可能放在「设置」→「系统设置」→「UWP 回环」或「网络工具」中。操作时按以下顺序执行：

  1. 先关闭正在测试的 UWP 应用，避免旧连接和缓存干扰结果。
  2. 以正常方式启动 Clash 客户端并载入有效配置。
  3. 进入 UWP Loopback 或回环豁免工具。如果 Windows 弹出权限确认，核对程序来源后允许本次管理操作。
  4. 在应用列表中找到目标程序，例如 Microsoft Store、Xbox 或指定的商店应用。
  5. 勾选目标程序，然后选择「Save Changes」「保存更改」或同等功能按钮。
  6. 返回客户端，确认系统代理仍然开启，再重新启动目标应用。

列表里找不到目标应用时

  • 先至少启动目标应用一次。部分包只有完成注册后才会出现在列表中。
  • 确认应用确实来自 Microsoft Store 或以 AppX、MSIX 包形式安装。普通 Win32 程序不需要 UWP 回环豁免。
  • 重启回环工具，使其重新读取已注册包。
  • 仍然无法识别时，改用后文的 PowerShell 与 CheckNetIsolation 方法。

某些新版应用虽然从 Microsoft Store 安装，内部仍可能运行普通桌面进程；另一些程序则同时包含桌面进程和 AppContainer 组件。因此「来自商店」不等于一定受回环限制，应结合实际进程和测试结果判断。

方法二：使用 CheckNetIsolation 精确添加豁免

CheckNetIsolation.exe 是 Windows 自带的网络隔离管理工具，可以列出、添加和删除 AppContainer 回环豁免。命令需要目标应用的 Package Family Name，简称 PFN。PFN 不是开始菜单显示名称，也不是安装目录名称。

第一步：查找应用的 Package Family Name

右键开始按钮，打开「终端管理员」或「Windows PowerShell 管理员」，先按应用名称筛选已安装包。以下示例查找名称中包含 Xbox 的包：

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

如果不知道包名，可以列出当前用户的全部 AppX 包，再在终端中搜索目标名称：

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

输出通常包含两列。需要复制的是 PackageFamilyName 的完整值，例如名称与发布者标识组合而成的一长串字符。不要复制 PackageFullName，后者通常还包含版本号、架构和资源标记。

第二步：添加回环豁免

把下面命令中的示例 PFN 替换为实际查询结果。参数 -a 表示添加，-n 后接包族名称：

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

命令执行成功后通常会返回完成提示。随后列出当前豁免项，确认目标包已经写入：

CheckNetIsolation LoopbackExempt -s

如果列表很长，可以先把结果输出到文本，再搜索包族名称：

CheckNetIsolation LoopbackExempt -s > "$env:TEMP\loopback-list.txt"
notepad "$env:TEMP\loopback-list.txt"

第三步：需要时删除豁免

应用不再需要连接本机代理，或者添加了错误的包族名称时，可用 -d 删除对应条目：

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

删除后再次运行 CheckNetIsolation LoopbackExempt -s，确认该项已经离开列表。修改豁免一般不需要重启 Windows，但应彻底退出并重新打开目标应用，让它建立新连接。

验证请求是否真正进入 Clash

应用恢复联网并不等于请求一定经过了当前代理。验证时应同时观察应用表现、Clash 连接记录和系统代理状态，避免把缓存内容误判为修复成功。

验证一：查看 Clash 连接记录

  1. 在客户端进入「连接」「Connections」或同等页面。
  2. 清空现有记录，或者记住当前时间。
  3. 彻底关闭目标 UWP 应用，再重新打开并触发一次网络请求。
  4. 检查是否出现与该应用访问域名对应的新连接。
  5. 查看连接命中的规则、策略组和最终节点，确认结果符合配置预期。

如果连接页出现目标域名，说明请求已经到达 Clash 内核。若连接存在但仍打不开，应继续检查规则命中、DNS 解析和节点连通性，而不是反复添加回环豁免。

验证二：对比系统代理开关

保持目标应用处于完全退出状态，开启 Clash 系统代理后测试一次，再关闭系统代理测试一次。如果开启时连接记录出现、关闭时消失，且应用网络行为同步变化，说明链路关系比较明确。测试完成后恢复原来的代理设置。

验证三：检查本机监听端口

在 PowerShell 中确认 Clash 是否监听预期端口。假设 mixed-port 为 7890，可执行：

Get-NetTCPConnection -State Listen -LocalPort 7890 |
  Select-Object LocalAddress, LocalPort, OwningProcess

正常结果应显示端口处于 Listen 状态。若没有结果，说明内核未监听该端口，或者客户端使用了其他端口。此时即使回环豁免正确，UWP 应用也无法连接代理。

添加豁免后仍然无效的排查顺序

1. 系统代理端口与 Clash 监听端口不一致

这是最常见的后续问题。比如配置写着 mixed-port: 7897，Windows 代理仍指向 127.0.0.1:7890。应在客户端「设置」→「参数设置」中确认混合端口，再到 Windows「设置」→「网络和 Internet」→「代理」核对地址与端口。

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

allow-lan 控制局域网设备是否能够连接 Clash 监听端口，并不是解决本机 UWP 回环限制的开关。仅为处理本机应用而把它改为 true，通常没有必要。

2. 目标应用使用了不同的包

同一产品可能存在正式版、测试版、游戏服务组件和独立登录组件。给主程序添加豁免后，实际发起请求的可能是另一个 AppX 包。重新执行 Get-AppxPackage，按产品名称检查相关包，并结合 Clash 日志逐项验证。

3. 应用进程没有彻底退出

点击窗口关闭按钮后，应用可能仍在后台驻留。可在「任务管理器」→「进程」中结束对应任务，等待 5 秒后重新启动。必要时注销当前 Windows 用户会话，使 AppContainer 网络状态重新建立。

4. 规则把请求直接连接

回环修复只负责让请求抵达 Clash，不会改变规则结果。如果连接页显示 DIRECT，说明域名或 IP 命中了直连规则。应检查配置中的域名规则、规则集顺序和最终匹配项，不应把回环问题与代理规则问题混在一起。

5. DNS 或 TUN 模式造成第二层问题

开启 TUN 模式后，部分客户端会接管更多系统流量，但 UWP 应用的实际行为仍取决于客户端实现、Windows 网络栈与当前配置。若系统代理模式已经恢复正常，再切换 TUN 进行对比。不要同时修改回环、DNS、TUN 和规则，否则很难确定是哪项改动生效。

回环豁免、系统代理与 TUN 的关系

这三个概念位于不同层次。系统代理告诉支持代理设置的程序把 HTTP 或 HTTPS 请求交给本机端口；回环豁免允许受隔离的 AppContainer 访问这个本机端口；TUN 模式则通过虚拟网络接口接管更广范围的 IP 流量。

  • 系统代理：适合浏览器和遵循 Windows 代理设置的应用，常见目标为 127.0.0.1:7890。
  • UWP 回环豁免：解决 AppContainer 无法访问本机代理监听地址的问题，不负责选择节点或修改规则。
  • TUN 模式：适合不读取系统代理的程序和更复杂的流量接管场景，通常需要驱动、服务或管理员权限支持。

如果只是一两个 UWP 应用无法使用已开启的系统代理，优先添加精确回环豁免，改动范围更清晰。如果大量不支持系统代理的程序都需要接管，再评估 TUN 模式。切换模式前应保留当前可用配置，记录 mixed-port、DNS 与规则模式，便于恢复。

处理结果检查表

  • Clash 内核已启动，配置文件没有加载错误。
  • 当前节点可用，桌面浏览器能够通过相同配置访问网络。
  • Windows 系统代理地址和 mixed-port 完全一致。
  • 目标 UWP 应用对应的 Package Family Name 已加入回环豁免。
  • 应用已彻底退出并重新启动，不再复用旧连接。
  • Clash 连接页能够看到目标应用触发的域名请求。
  • 连接命中的规则和策略符合预期，没有被错误分配到 DIRECT。
  • 测试结束后，仅保留实际需要的回环豁免项。

完成以上检查后，可以明确区分三类故障：应用无法连接本机代理、请求已经进入 Clash 但规则选择错误、节点或 DNS 本身不可用。按链路逐段验证，比反复切换节点或重装客户端更容易定位原因。