---

现象:普通应用能代理,商店应用连不上

在 Windows 上开启 Clash 或 mihomo 内核的系统代理、甚至开了 TUN 模式之后,大多数桌面应用(浏览器、命令行工具、传统 exe 程序)都能正常走代理规则出站。但一部分从 Microsoft Store 安装的应用——比如某些邮件客户端、部分浏览器的商店版、跨平台聊天工具的 UWP 封装版——却表现出典型的"代理对它不生效"症状:直连能上的网站它能上,需要走代理才能访问的地址一律超时或提示网络错误,哪怕系统代理设置里已经正确填入了本地端口。

这类问题的排查很容易走偏。很多人第一反应是怀疑订阅节点失效、内核崩溃或者规则写错,反复重启客户端、重新导入订阅,结果毫无效果。原因很简单:问题根本不在代理服务这一侧,而在 Windows 系统对 UWP(Universal Windows Platform)应用的网络访问做了一层独立于普通进程的隔离限制,这层限制默认会切断 UWP 应用与 127.0.0.1 / localhost 的回环通信,而绝大多数本地代理客户端(包括 Clash 系内核)恰好是通过监听本机回环地址对外提供 HTTP/SOCKS5 代理端口的。

原理:UWP 沙箱与回环通信隔离

要理解这个限制,得先知道 UWP 应用的运行方式与传统 Win32 程序完全不同。UWP 应用运行在一个被称为 AppContainer 的沙箱环境里,微软为每个 UWP 应用分配一个独立的安全标识符(SID),并通过网络隔离(Network Isolation)机制严格控制它能访问哪些网络资源。这套机制的设计初衷是安全:防止商店应用未经声明就随意访问局域网或者本机其他进程开放的端口,降低横向渗透与信息泄露的风险。

网络隔离策略里有一条关键规则:UWP 应用默认禁止访问运行在同一台机器上、以回环地址(loopback,即 127.0.0.1 或 ::1)方式监听的服务,除非该服务本身也是打包成 UWP 应用运行的。这就解释了为什么问题只出现在商店应用上——传统桌面程序不受 AppContainer 约束,可以随意连接本机任意端口;而 UWP 应用即便系统代理设置全局生效,它发出的每一次连接请求在到达网络层之前就会先在这层隔离检查中被拒绝,连接对象是 127.0.0.1:7890 这类本地代理端口时表现得尤为明显。

值得注意的是,这个限制与代理软件本身是否开启"允许局域网连接"或者监听地址填 0.0.0.0 还是 127.0.0.1 关系不大——即便代理监听在所有网卡上,UWP 应用发起的回环请求依然会被系统级的隔离策略拦下,这是操作系统层面的行为,客户端配置文件里没有任何选项能绕开它。

先确认:是不是回环限制在作怪

动手解除限制之前,建议先做两步简单验证,避免误判:

1. 确认受影响的是不是商店应用。右键点击开始菜单里的应用图标,如果"卸载"之外还能看到"高级选项"这一项,通常说明它是 UWP 应用;传统 Win32 程序一般直接是卸载入口。也可以在设置的"应用和功能"列表里查看来源标注。
2. 确认代理服务本身工作正常。用浏览器或命令行工具手动测试同一个代理端口是否可用,比如用 curl 指定代理访问一个需要代理才能打开的地址,如果这类传统程序都能正常出站,基本可以排除代理配置或节点本身的问题,问题指向就集中在 UWP 网络隔离上。

两步都对上号,基本可以确定就是回环限制导致的连接失败,接下来只需要为这个具体的 UWP 应用单独打开回环豁免。

路径一:CheckNetIsolation 命令行解除

Windows 系统自带一个命令行工具 CheckNetIsolation.exe,专门用于管理 AppContainer 的网络隔离白名单,这是官方提供的标准解决方式,不需要安装任何额外软件。

第一步:找到应用的 Package Family Name

以管理员身份打开 PowerShell,执行以下命令列出当前系统安装的所有 UWP 应用及其包名:

Get-AppxPackage | Select-Object Name, PackageFamilyName

在返回列表里找到目标应用对应的条目,记下它的 PackageFamilyName 字段,格式类似 12345Publisher.AppName_abcdefghijk1m,这一串字符是后续命令必须的精确标识,不能用应用的显示名称代替。

第二步:添加回环豁免

关闭 PowerShell,改用管理员权限打开命令提示符(cmd),执行:

CheckNetIsolation.exe LoopbackExempt -a -n="12345Publisher.AppName_abcdefghijk1m"

命令执行后没有报错即代表添加成功,不会有额外的成功提示弹窗。这条命令的效果是把指定应用加入回环豁免名单,允许它此后正常访问本机 127.0.0.1 上监听的服务,包括代理客户端开放的 HTTP/SOCKS5 端口。

查看与撤销

如果要确认当前已经豁免的应用列表,执行:

CheckNetIsolation.exe LoopbackExempt -s

如果后续需要撤销某个应用的豁免(比如排查其他问题时想恢复默认隔离状态),把参数 -a 换成 -d 即可:

CheckNetIsolation.exe LoopbackExempt -d -n="12345Publisher.AppName_abcdefghijk1m"

需要提醒的是,这个豁免名单不会跨设备同步,也不会在应用卸载重装后自动保留,重装后需要重新执行一次添加命令。

路径二:图形化工具操作

如果不习惯敲命令、担心包名抄错,也可以用图形界面工具完成同样的操作。微软社区里流传较广的 EnableLoopback 是一个开源小工具,本质上是给 CheckNetIsolation.exe 套了一层界面,不涉及底层机制的更改,操作逻辑与命令行完全一致:

1. 以管理员身份运行该工具,程序启动后会自动读取当前系统已安装的全部 UWP 应用列表,并标注出各自当前的回环豁免状态。
2. 在列表里勾选需要解除限制的应用(可以多选,批量处理多个受影响的商店应用),点击"Modify"应用改动。
3. 工具执行的操作与手动敲命令完全等效,勾选即添加豁免,取消勾选即撤销豁免,无需记忆或复制包名。

对于需要频繁调整豁免状态、或者一次性要处理多个应用的场景,图形工具比反复敲命令行更省事;但如果只是临时解决单个应用的问题,直接用命令行往往更快,不需要额外下载安装第三方工具。

解除后如何验证生效

完成豁免设置后,建议按以下顺序验证,不要只凭"应用打开变快了"这种主观感觉判断:

• 完全关闭再重新打开应用。UWP 应用的网络会话通常在启动时就已建立,豁免设置在应用运行期间往往不会立即热生效,必须完整退出进程后重新启动才会按新的隔离策略走。
• 访问一个明确需要代理才能打开的地址。避免用应用首页这种可能有本地缓存的内容来判断,选择一个必须联网实时加载、且明确处于代理规则分流范围内的功能来测试。
• 回头检查代理客户端的连接日志或活动连接面板。如果客户端界面能看到该应用发起的连接记录,说明流量确实已经进入代理链路;如果日志里完全没有出现相关记录,说明豁免没有生效,需要回头确认包名是否抄错、命令是否以管理员权限执行。

另外提一点容易被忽略的细节:部分 UWP 应用即便解除了回环隔离,仍然可能因为自身的"网络功能声明"(Capability)里没有声明专用网络访问权限而受限,这种情况一般出现在企业定制分发的应用上,普通商店应用较少遇到,如果解除隔离后依然无效,可以在应用清单权限里进一步确认。

规避回环限制的其他思路

如果不想逐个应用去解除隔离,或者受影响的应用数量较多、频繁变动,还有两条思路可以从根源上绕开这个限制:

切换到 TUN 模式

如前文提到的,回环限制针对的是应用主动连接本机代理端口这种访问方式。如果客户端支持 TUN 模式,启用后会在系统里建立一个虚拟网卡,所有进程(包括受隔离约束的 UWP 应用)的流量都会在网卡层被统一接管转发,不再依赖应用自己去连接 127.0.0.1 上的代理端口,自然也就不受回环隔离策略影响。对于经常遇到商店应用连接问题的用户,直接切到 TUN 模式往往比逐个加白名单更省心。

调整监听地址与防火墙规则配合系统代理

部分场景下也可以考虑把系统代理的作用范围调整为覆盖更底层的网络配置,但这类调整通常伴随其他兼容性代价,不如前两条路径直接,一般不作为首选方案,仅在 TUN 模式与逐应用豁免都不适用的特殊环境下再考虑。

---

回环限制是 Windows 系统层面的安全设计,不是代理客户端的缺陷,理解这一点能省去大量无意义的排查时间。遇到"只有商店应用连不上代理"这种特征明显的问题,直接按包名走 CheckNetIsolation 命令或图形工具解除豁免,通常几分钟内就能解决;如果应用数量多或者不想维护白名单,切换到 TUN 模式是更省心的长期方案。