1. 典型现象：为什么「只有 UWP 不对劲」
桌面版浏览器走系统代理或 TUN 虚拟网卡时，往往立刻见效；而微软商店、Xbox、部分预装 UWP 应用仍可能继续走「系统认为的直连路径」，或在访问本机回环地址（例如 127.0.0.1 上的本地代理端口）时被系统策略拦截。表现包括：商店无法加载页面、应用内图片与 API 请求超时、仅特定 UWP 异常而同一台电脑上的 exe 程序完全正常。
这类问题与「节点质量差」往往无关，更多出在 Windows 对 UWP 的网络沙箱以及你在 Clash 里写的 分流规则是否命中真实进程。下面先把 TUN 是否生效说清楚，再分别处理回环与进程名两条线。
2. 先确认：TUN 真在工作吗
在 mihomo（原 Clash Meta）内核下，TUN 模式会创建虚拟网卡并接管路由表中的相应流量。若此处未成功，所有应用的表现都会乱，而不仅是 UWP。建议先完成以下核对：客户端中 TUN 开关已开启、无「仅代理 TCP」之类过度收窄的选项误开、没有第二个同类软件同时抢占路由或网卡、必要时以管理员身份运行客户端一次以排除权限问题。
若桌面浏览器已通过代理访问目标站点，而连接日志里能看到对应会话，则说明内核与出站链路整体可用。此时再单独针对 UWP 排查，才有意义。若你尚未完成客户端安装与订阅导入，可先参考站内的 订阅导入教程，避免把「根本没连上节点」误判成 UWP 特例。
3. 回环隔离与 UWP：本地代理的隐形墙
Windows 对应用商店体系内的 UWP 应用默认启用 网络隔离：出于安全考虑，多数 UWP 默认 禁止访问本机回环地址。因此，当你的代理方案依赖「应用 → 连接本机某端口 → 再由 Clash 转发」时，UWP 可能在到达 Clash 之前就被系统拦下；这与你是否开启 TUN 并不矛盾——TUN 解决的是「出网路径」，而回环限制发生在「访问本机」这一层。
实务上，纯 TUN 全量接管且应用不依赖本机 HTTP 代理端口时，许多流量会直接进入虚拟网卡，回环问题可能不明显；但一旦涉及本机代理、抓包工具、或某些组件仍指向 127.0.0.1，就会与 Loopback 策略正面冲突。此时需要为对应包配置 Loopback Exemption（回环豁免），让该 UWP 被允许访问本机回环。
需要记住的一点
回环豁免解决的是「UWP 能不能连上本机」；Clash TUN 解决的是「出网流量走哪张网卡」。两者常一起出现，但职责不同，排查时建议分开验证。
4. 配置 Loopback 豁免的实用做法
Windows 自带 CheckNetIsolation.exe，可为指定应用包添加回环豁免。管理员身份的 PowerShell 或命令提示符中，可使用包族名称（Package Family Name）执行添加。包族名称可通过「设置 → 应用 → 已安装的应用」或 Get-AppxPackage 查询。以下示例展示常见写法（请将包名替换为你机器上的实际值）：
# Run as Administrator — add loopback exemption for Microsoft Store (example package family name) CheckNetIsolation LoopbackExempt -a -n="Microsoft.WindowsStore_8wekyb3d8bbwe"
查看当前豁免列表可使用 CheckNetIsolation LoopbackExempt -s。若你使用社区提供的「Loopback 豁免」图形工具，本质也是调用同一套机制；为可重复性与脚本化，建议掌握命令行方式。添加后重启对应 UWP 或整台电脑再试，避免旧进程缓存连接状态。
安全提示：回环豁免会扩大该应用访问本机的范围，仅对你信任的包操作，并在排查结束后按需评估是否保留。
5. PROCESS-NAME 规则：进程名写错等于没写
在 mihomo 规则中，PROCESS-NAME 按进程映像文件名匹配（如 chrome.exe），用于把特定程序的流量导向指定策略组。UWP 应用往往对应独立进程名，与桌面版同名软件可能不是同一个 exe；若你从网上复制规则却未核对本机任务管理器中的实际名称，规则会永远不命中。
建议用任务管理器「详细信息」或 Sysinternals 的 Process Explorer 查看目标应用对应的可执行文件名，再写入规则。示例（策略组名请与订阅中已有名称一致）：
rules: # Example: send traffic from a specific executable to proxy group - PROCESS-NAME,YourApp.exe,🔰 Proxy - PROCESS-NAME,WinStore.App.exe,🔰 Proxy
注意大小写与扩展名：规则里一般是纯文件名而非完整路径。若同一厂商提供 UWP 与 Win32 两个版本，请分别确认进程名，不要混用。配合连接日志（若客户端提供）可快速验证某条 PROCESS-NAME 是否被匹配。
6. 规则顺序与常见误区
Clash 系规则自上而下优先匹配：靠前的一条一旦命中，后面的规则不再生效。常见误区包括：把过于宽泛的 GEOIP,CN,DIRECT 或大的域名集合放在 PROCESS-NAME 之前，导致进程级规则永远走不到；或把 UWP 专用规则写在 MATCH 之后（无效）。建议将「强意图」的 PROCESS-NAME、DOMAIN 规则放在中段靠前，并在修改后用「连接面板 / 日志」观察实际命中的规则名。
另一个误区是混淆「系统代理」与「TUN」：仅开系统代理时，不尊重 WinINET 代理的 UWP 可能仍直连；切到 TUN 后行为会变化。讨论问题时应说明你当前是 TUN、系统代理还是混合，否则他人难以复现。若你从经典的 CFW 迁移指南换到新版图形客户端，也建议统一改为 TUN 或统一为端口代理，避免多层叠加却不自知。
7. 实测检查清单
相比在多个小工具之间来回切换，使用持续维护的 mihomo 内核与一款界面清晰的图形客户端，能把 TUN、规则覆写与日志查看集中在一处，排查 UWP 这类边界问题时效率会高很多。若你希望从下载到日常规则维护都更省心，可以优先选择社区活跃、与内核版本同步及时的发行版。