Allow switching legacy process name tun protect

[DHR60]

允许切换为旧版，基于进程名的 TUN 保护

[2dust]

先把这个合并了，发个版本

[feng-jianwei]

@DHR60 @2dust 旧版Tun和新版Tun有什么不同，现在最新版本默认情况下旧版Tun保护不开启。使用的时候在wsl中无法和github ssh秘钥交换，勾选保护后恢复。是否需要默认兼容，旧版本Tun保护默认勾选呢

[Caesar-Victory]

以下是基于官方 Issue #8977 和 xray-core 仓库的完整技术分析。

---

一、为什么要做这个变更——TUN 保护的本质问题

TUN 模式的流量回环死锁

TUN 模式的工作原理是：在操作系统网络栈层创建一个虚拟网卡，用路由规则把所有出站流量劫持进来，再由代理 core 决策走代理还是直连。

这里有一个必须解决的结构性矛盾：代理 core 自身也需要向外发送流量（连接远程服务器），但 TUN 把所有流量都劫持了，core 的出站流量也会被自己的 TUN 入口再次捕获，形成死锁回环。

xray 发包 → TUN 虚拟网卡截获 → 交给 xray → xray 再发包 → ∞

这不是 bug，而是 TUN 全局透明代理的固有设计挑战，所有实现都必须解决它。

---

旧方案：进程嗅探（Process Sniffing）

v7.19 之前的解决方案是让 sing-box 在 TUN 入口处识别发包进程的名称，如果发包方是 xray.exe / sing-box.exe 等 core 进程，则直接放行走直连，不进入 TUN 处理循环。

这个方案在 Windows 上可行，但有两个根本性缺陷：

在 macOS 上无法实现进程嗅探，同时部分 Linux 发行版对 UDP 流量无法正确嗅探进程，导致 xray XHTTP/3 和 Hysteria2 协议出现问题。

具体来说：

• macOS：内核不向非特权进程暴露 socket-to-process 的映射关系，进程嗅探从系统层面就不可行。
• Linux UDP：/proc/net/udp 在高并发或某些内核版本下存在竞态，UDP 数据报的进程归属无法可靠获取。XHTTP/3 和 Hysteria2 都是 UDP 协议（QUIC），因此直接受害。

---

新方案：Shadowsocks 中继隔离

v7.19 改为一个更可靠的架构：

所有应用流量
    ↓
[sing-box TUN 入口]
    ↓
[sing-box 内置 SS 中继服务，随机端口，本地监听]
    ↓（加密的 SS 流量，sing-box 路由识别为"已处理流量"直接放行）
[xray core 接收，处理出站]
    ↓
远程服务器

保护机制的关键：sing-box 的路由规则可以精确识别"目标是本地 SS 中继端口"的流量，并将其标记为直连放行——这不依赖任何进程嗅探，只是普通的端口/地址匹配路由规则，在所有平台上都完全可靠。

xray core 连接到这个本地 SS 中继时，流量目标是 127.0.0.1:随机端口，sing-box 路由直接放行，不会再次进入 TUN，回环死锁被彻底切断。

---

二、为什么明知性能下降仍要保留旧版选项

这是一个经典的可靠性 vs 兼容性权衡，有具体的工程原因：

新架构引入了额外复杂度：多了一个 sing-box 进程 + SS 中继，流量路径变成 TUN → SS加密 → xray → 服务器，本地多了两次序列化/反序列化和一次 loopback 转发。性能退化是可预见的副作用。

新架构在部分 Windows 系统上触发了 loopback 问题：正是你遇到的情况——sing-box 的 TUN 在某些网络配置下，127.0.0.1 的 loopback 流量被严格路由规则误拦截，导致 xray 连不上本地 SS 中继端口，整个链路断裂。

旧版方案使用进程嗅探实现 TUN 保护，在 Windows 上本来是工作的，新方案是为了修复跨平台问题而引入的，Windows 用户因此成了"被连带"的一方。保留旧版选项，是为了让 Windows 用户在新架构存在兼容性问题时有退路，而不是强迫所有人接受一个在自己平台上反而更差的方案。

---

三、何时移除「旧版 Tun 保护」

官方的明确答复是：目前他们能力有限，欢迎 PR 实现 xray core 的 TUN 模式，或者等待 xray 官方实现 TUN mode auto-route。

而这件事在 2026 年 1 月已经有了实质进展：

xray-core v26.1.23 已经正式加入了 Windows 和 Linux（含 Android）的 TUN inbound 支持。

这意味着终态架构的方向已经清晰：未来 v2rayN 可以直接使用 xray 原生 TUN，完全不需要借助 sing-box 做前置，也不存在进程嗅探或 SS 中继的问题，整个"两核心链式"架构会变得多余。

但目前 v2rayN 尚未集成 xray 原生 TUN（需要 GUI 层适配路由规则生成逻辑），所以「旧版 Tun 保护」的移除时间点取决于：v2rayN 团队何时完成对 xray native TUN 的集成并稳定下来。在此之前，这个选项不会消失。也正因如此，有人戏称 xray 的 TUN 支持要等到 2029 年——虽是玩笑，但也侧面说明这件事拖了相当长时间，社区对此已有不少积怨。

---

总结

	旧方案（≤7.18）	新方案（7.19+）	终态（xray native TUN）
回环保护方式	进程嗅探	SS中继端口路由放行	xray内置auto-route
macOS支持	❌	✅	待定
Linux UDP	❌（XHTTP/3、Hy2失效）	✅	✅
Windows loopback	✅	⚠️（部分系统有问题）	✅
性能	较好	有额外开销	最优