典型现象：为什么「只有浏览器」像开了代理
在 Windows 11 上，大多数图形版 Clash 客户端会同时做两件事：向系统写入 系统代理（常见为指向 127.0.0.1 某端口），并在本地打开 mixed、HTTP 或 SOCKS 监听端口。桌面版 Chromium 系浏览器会读取 WinINET 或系统代理表，于是网页立刻走代理；而 Microsoft Store、照片、邮件与许多自带组件属于 UWP 容器模型，默认遵守另一套安全策略：禁止访问本机回环地址，以免沙箱应用扫描你内网服务。结果是：浏览器能连上 127.0.0.1:7890，UWP 却连不上同一地址，看起来就像「Clash 对它们无效」。
另一类混淆来自「代理形态」本身：若你只开了系统代理而没有 TUN，那么不尊重系统代理表的程序仍会直连；UWP 的问题则更靠前——在它们尝试使用本机代理端口之前，就可能被回环策略挡住。排查时请先回答两个问题：目标应用是不是 UWP 或商店渠道包？Clash 的入站是否在本机回环地址上？两个都是「是」时，应优先怀疑 localhost 回环，而不是急着换节点。
网络隔离与 CheckNetIsolation：系统在拦什么
微软用 网络隔离（Network Isolation）把应用划分到不同「隔间」里，UWP 默认在隔间内不能向 127.0.0.1 或本机其他回环地址发起连接，除非你显式授予回环豁免（loopback exemption）。这与防火墙放行无关：即使入站规则全绿，UWP 仍可能碰不到你的代理监听端口。命令行工具 CheckNetIsolation 就是用来管理这类豁免的；它按应用的程序包系列名（Package Family Name，PFN）登记例外。
因此修复路径的第一步永远是：找出目标应用对应的 PFN。对商店应用，可在 PowerShell 里用应用包查询 cmdlet 列出已安装应用及其系列名，再把它交给 CheckNetIsolation LoopbackExempt 子命令。豁免一旦生效，该 UWP 即可像普通桌面程序一样访问本机代理端口，系统代理链路才有机会真正工作。
安全提示：回环豁免等于允许该应用访问你机器上的本地服务，请只对你信任的包名操作；测试结束后可用列表命令核对是否多开了不必要的条目。
实测步骤一：用 CheckNetIsolation 解除回环限制
以下步骤假设你以管理员身份打开 PowerShell 或 Windows 终端，且 Clash 正在本机端口提供 HTTP 或 mixed 代理。
- 列出候选 PFN：使用应用包查询命令，按显示名称或包名筛选 Microsoft Store、Xbox 等你关心的应用，记下
PackageFamilyName字段。名称相近时以系列名为准，避免加错隔间。 - 查看当前豁免列表：执行
CheckNetIsolation LoopbackExempt -s，确认是否曾经手工或第三方工具写入过记录，避免重复或冲突。 - 添加豁免：对目标 PFN 执行添加命令（需管理员权限）。成功后无需重启整个系统，通常退出并重开目标应用即可验证。
- 验证：保持 Clash 的系统代理开启，在商店应用内触发网络请求（如下载、登录），同时在 Clash 连接日志中观察是否出现对应域名或连接记录；若仍无流量，再继续下一节的 TUN 与规则核对。
- 回滚：若需移除单条豁免，可使用对应的删除子命令按 PFN 精确删除，避免「一刀切」影响其它应用。
不少开发者会用抓包工具自带的「一键豁免所有 UWP 回环」图形界面，本质仍是维护同一套列表。与手工命令相比，图形工具省事，但更难审计；生产环境或安全敏感机器上，更推荐保留你可解释的 PFN 级最小豁免集。
下面给出常用命令骨架（请把其中的 PFN 换成你在自己电脑上查到的值；商店应用升级后若系列名变化，需重新核对）。
# List Store-related packages (pick the correct PackageFamilyName)
Get-AppxPackage *WindowsStore* | Select-Object Name, PackageFamilyName
# Show current loopback exemptions (run from elevated cmd or PowerShell)
CheckNetIsolation.exe LoopbackExempt -s
# Add exemption for one PFN (example PFN — verify on your PC)
CheckNetIsolation.exe LoopbackExempt -a -n=Microsoft.WindowsStore_8wekyb3d8bbwe
# Remove one PFN from the exemption list when you need to roll back
CheckNetIsolation.exe LoopbackExempt -d -n=Microsoft.WindowsStore_8wekyb3d8bbwe实测步骤二：TUN 与系统代理如何配合 UWP
当你启用 TUN 模式时，流量往往在路由层被导向虚拟网卡，由内核侧进入 Clash，再按规则决定直连或出站。对许多 UWP 来说，这意味着它们不必再成功连接 127.0.0.1 上的代理端口，也能被纳入策略——这也是不少用户「一开 TUN，商店突然好了」的原因。但 TUN 会带来更高权限要求、驱动安装与路由/DNS 复杂度；若 TUN 未正确建立，又会出现整机断网，这与回环问题是不同维度。
实践上可遵循这条决策链：若你主要依赖系统代理且 UWP 需要访问本机代理端口，先做 CheckNetIsolation 回环豁免；若你希望终端、游戏与 UWP 在同一套路由下被透明接管，再开启 TUN，并关闭或简化系统代理写入以避免双轨干扰。更细的对照表、断网排查顺序见本站 《Clash TUN 模式在 Windows 11 与 macOS 上怎么开》，此处不再重复表格，只强调与 UWP 场景的衔接点。
若 TUN 已开而特定域名仍直连，请回到规则：是否命中了正确的策略组、GEOIP 与私有地址是否被误送代理、DNS 模式是否与 fake-ip 冲突。此类问题与「回环」无关，应配合 YAML 分流指南按日志中的域名逐条核对。
可打印排查清单：从现象到结论
把下面清单当作一次完整「桌面侧」体检，自上而下执行，通常能在十几分钟内定位主因。
| 步骤 | 检查项 | 若异常时的倾向结论 |
|---|---|---|
| 1 | 浏览器访问境外测试页是否正常 | 浏览器异常则先查订阅、端口与系统代理是否写入 |
| 2 | 问题应用是否为商店/UWP 包 | 是则优先查 localhost 回环豁免 |
| 3 | Clash 日志在操作应用时是否有连接记录 | 完全无记录且为 UWP 多半是回环或 TUN 未接管 |
| 4 | TUN 适配器是否成功创建、客户端是否管理员运行 | 适配器失败时先修 TUN，再谈规则 |
| 5 | 规则是否把微软服务误直连或误送错误策略组 | 调整 DOMAIN-SUFFIX 与策略顺序 |
完成清单后，把「已验证项」记在笔记里，下次换机或重装系统时可以照单恢复，比依赖模糊记忆要稳得多。
容易踩坑的边缘情况
某些应用同时提供桌面版与商店版，网络栈与更新渠道不同，PFN 也不相同；豁免与规则要对着你实际启动的这一份二进制做。公司设备上若存在 MDM 策略或第三方零信任客户端，也可能在路由层抢先于 Clash，表现为「日志里明明命中规则却仍直连」——此时要先确认只有一层默认路由接管者。
WinHTTP 代理与系统界面里看到的「代理」也不总是同一张表；少数维护工具或脚本只改了其中一类。桌面 Win32 程序与 UWP 对各表的尊重程度不同，遇到「同一个 exe 双版本表现不一致」时，不要惊讶，按上文分层排查即可。
写在最后
Windows 11 把安全边界往前推了一步，UWP 与商店应用在localhost 回环上的默认拒绝，是为了隔离沙箱；但对本地 Clash 用户来说，这就成了「浏览器一切正常、商店却像没开梯子」的经典错觉。把 CheckNetIsolation 回环豁免与 TUN 模式、系统代理各自解决的问题分开看，再配合规则与 DNS 自检，你就能稳定复现修复路径，而不是每次重装碰运气。
若你希望减少版本来源混乱、在单一入口获取各平台客户端，可先访问我们的下载中心选择适合自己系统的发行版，把精力留给策略与排错本身。
更多内容可继续浏览技术专栏中的 TUN、YAML 与订阅排查等文章，把「回环 → 代理形态 → 规则」串成一条完整链路。