为什么「开了 Clash」UWP 仍可能不走代理
在 Windows 上，Clash 类客户端通常通过修改系统代理（指向 127.0.0.1 上的 HTTP/HTTPS 端口）或TUN 虚拟网卡来接管流量。传统 Win32 程序若尊重系统代理设置，往往可以随之走本地代理；但 UWP（通用 Windows 平台）应用运行在应用容器内，默认禁止访问本机环回地址（Loopback isolation），除非为对应包显式授予豁免。结果是：即便系统代理已指向 127.0.0.1，UWP 仍可能无法与本地代理进程通信，表现就像「完全没开代理」。
另一类情况是：应用不使用系统代理，而是自带网络栈或走 WinHTTP 代理（与「设置 → 网络和 Internet → 代理」不一定一致）。因此排查时要先确认问题属于 Loopback 限制、代理模式覆盖不足，还是 DNS/规则层面，避免一上来只反复切换节点。若你尚未完成 Windows 端基础安装，可先对照 Windows 下 Clash Verge Rev 完整安装与配置教程 把订阅与系统代理或 TUN 开稳。
典型现象：如何与「普通软件不走代理」区分
若只有 Edge、Chrome 等浏览器正常，而 Microsoft Store 下载慢、Xbox 应用登录异常、部分内置应用更新卡住，同时你已确认同一台电脑上 Clash 日志中有其他程序的连接记录，则 UWP 相关限制的可能性较高。若所有程序都不走代理，优先检查 Clash 是否开启系统代理、端口是否冲突、是否被安全软件拦截，而不是先折腾 Loopback。
另有一种混淆来自 localhost：某些 UWP 会访问 127.0.0.1 或本机服务；在 Loopback 未豁免时，这些连接会失败，错误信息与「代理无关」的网络错误相似。此时在事件查看器或应用内往往看不到明确提示，需要结合下文豁免与对比测试判断。
术语：Loopback 豁免（Loopback exemption）指允许特定 UWP 包访问本机回环接口；与「是否使用系统代理」是两个层面——豁免解决「能否连上本机代理」，系统代理与 TUN 决定「流量如何出境」。
1先验证：Clash 在系统层是否已生效
打开 Windows「设置 → 网络和 Internet → 代理」，查看「使用代理服务器」是否为开，且地址与端口与 Clash 客户端显示一致（常见为 127.0.0.1 加混合端口或 HTTP 端口，具体以你使用的 Clash Verge Rev 界面为准）。若此处未开启或端口错误，UWP 与 Win32 都会异常，应先回到客户端确认系统代理开关与端口未被占用。
在管理员命令提示符或 PowerShell 中执行 netsh winhttp show proxy，查看 WinHTTP 是否为系统代理同步。部分服务或组件依赖 WinHTTP；若长期与预期不符，可在确认需求后使用 netsh winhttp import proxy source=ie 从 IE/系统设置导入（操作前建议了解该命令的影响范围）。这一步用于排除「仅当前用户会话有代理、系统组件仍直连」的差异。
2针对 UWP：Loopback 豁免操作思路
对需要访问本机代理端口的 UWP，需将对应应用包加入 Loopback 豁免列表。Windows 自带 CheckNetIsolation 工具（位于 System32 目录）。基本思路是：查出目标应用的包族名称（Package Family Name），再执行添加豁免命令。包名可在「设置 → 应用 → 已安装的应用」中点击应用详情查看，或通过 PowerShell 枚举已安装应用列表获得。
管理员权限打开 PowerShell 后，可使用如下形式（将示例包名替换为你的目标 UWP 的真实 Package Family Name）：
CheckNetIsolation LoopbackExempt -a -n="YourApp_xxxxxxxxx"
添加后可用 CheckNetIsolation LoopbackExempt -s 查看当前豁免列表。若你希望撤销某条，可使用 -d 与相同 -n 参数删除。注意：系统更新或应用重装后包名可能变化，需重新核对。对 Microsoft Store 本体、Xbox、特定游戏插件等，应分别添加对应包，而不是只添加「Clash」相关项——豁免的是需要连本机的 UWP，不是代理软件本身。
安全提示：放宽 Loopback 会扩大 UWP 访问本机的范围，仅在可信环境按需添加；不要随意对未知来源包全盘豁免。
3替代路径：TUN 模式与「非本机代理」场景
若你希望减少对本机环回的依赖，可在硬件与策略允许的前提下启用 TUN 模式，由虚拟网卡在更底层接管流量，使更多程序无需显式指向 127.0.0.1。这在命令行工具、部分忽略系统代理的应用上往往更有效；UWP 是否全部遵循 TUN 仍取决于系统路由与规则，但实践中常作为与系统代理并列的选项。详细开启步骤见 Clash Verge Rev TUN 模式完整开启教程；若同时存在 DNS 泄漏或解析异常，可配合 Meta 内核 DNS 防泄漏指南 调整。
另一种思路是使用局域网内其他设备作为 HTTP 代理入口（例如在路由器或另一台 PC 上跑代理），UWP 连接的是非环回地址时，可能不再受 Loopback 限制——但部署成本更高，一般作为进阶方案。对家庭用户，优先顺序仍是：系统代理 + Loopback 豁免，再考虑 TUN。
规则与分流：排除「命中直连」误判
当 UWP 已能连接本地代理，但仍访问特定域名失败时，可能是规则将目标设为直连，或 DNS 解析走了意外路径。此时应在 Clash 日志中观察该应用对应连接的目标域名与策略命中情况，检查是否被 GEOIP、自定义直连列表或进程级规则影响。与 Loopback 无关的典型特征是：日志显示连接已建立且经代理，但页面仍异常——这更偏向 DNS、SNI 或远端封锁问题。
建议保持订阅与规则集为较新版本，并避免在同一台机器上多开多套代理软件争抢路由或虚拟网卡。若近期安装过其他 VPN 或「网络加速」类驱动，可暂时退出后复测 UWP 行为。
可打印的排查清单（建议按顺序执行）
- 确认 Clash 客户端中系统代理已开启，且 Windows 设置中代理地址、端口与客户端一致。
- 用浏览器或非 UWP 工具确认代理工作正常，缩小问题范围到 UWP。
- 对目标 UWP 执行 Loopback 豁免，重启应用后复测。
- 检查
netsh winhttp show proxy是否与预期一致（按需处理）。 - 需要更底层接管时尝试 TUN，并阅读 TUN 与防火墙相关提示。
- 仍异常时检查规则命中与 DNS，必要时调整规则或 DNS 模式。
小结
Windows 上「Clash 已开但 UWP 仍像直连」的常见根因，是 UWP 对 localhost 的默认隔离与系统代理/TUN 覆盖范围两类因素叠加。先把系统代理与端口核对清楚，再对具体 UWP 做 Loopback 豁免，最后才上升到 TUN 与规则/DNS 层，可以显著减少无效尝试。相比在论坛零散搜命令，按顺序排查也更容易定位是「连不上本机代理」还是「代理之后仍走错出口」。
若你希望在一套客户端里同时管理好订阅、策略组与多种代理模式，基于 Meta（Mihomo）内核的 Clash Verge Rev 在 2026 年仍是 Windows 桌面上较省心的选择之一；从安装到系统代理的完整路径可参考上文链接的 Windows 教程。