关于 TUN 模式环路问题（双核进程漏检 vs CDN 共享 IP 误伤）的解决思路探讨

[Obs-Mango]

为什么会出现 TUN 环路？（问题根源）

仔细复盘 #9974 的日志，这个死循环现象其实发生在 双核模式（即 sing-box 作为前置 TUN 服务 + Xray 作为代理主核心）：

1. sing-box.exe 接管系统 TUN 流量；
2. xray.exe 建立发往 VPS 的连接；
3. sing-box 尝试通过 Windows TCP 表查询该连接的进程归属，但由于 XHTTP / 测速连接频繁快速建连释放，sing-box 的 PID 查询未能及时匹配到 xray.exe，导致 process_path: ["xray.exe"] 规则未命中；
4. 这部分本该直连发往 VPS 的流量被当成普通流量，重新分发给了本地 127.0.0.1:10808（即回到 Xray SOCKS 入口），形成死循环。

---

为什么不能直接全局路由排除？

如 @DHR60 在 PR #10013 所指出的，route_exclude_address 修改的是操作系统的全局路由表。
如果节点使用了 Cloudflare CDN / Workers / 优选 IP，由于 Anycast IP 是全球共享的（Twitter、ChatGPT、Discord 等均在使用），全局排除会导致浏览器访问这些网站时全部被系统强行直连，进而导致连接被墙拦截。

---

几种解决思路与探讨

综合现代网络客户端的做法与 v2rayN 现有架构，整理了以下几种解决方案：

方案 1：双核模式下自动为 Xray 绑定物理网卡（bindInterface / IP_UNICAST_IF）

• 做法：当在双核模式下启动 Xray 时，v2rayN 自动将系统的物理网卡名称注入到 Xray 的配置（bindInterface 或 sendThrough）。
• 优势：
  • Xray 发出的 Socket 在 Windows 层面直接绑定物理网卡（IP_UNICAST_IF），从而在 Socket 层面跳过 sing-box 的 TUN 拦截；
  • 操作系统的全局路由表完全不修改，浏览器等其他软件的流量依然正常走 TUN 代理；
  • 对 Cloudflare / 优选 IP 100% 安全，彻底避免 CDN 误伤与死循环。

方案 2：纯 Xray 原生 TUN 模式（逐步替代双核前置）

• 做法：在 7.24.4+ 中，Xray 已自带原生 TUN（xray_tun），原生具备 autoOutboundsInterface: "auto"。对于 Xray 节点直接使用 Xray 单核心接管 TUN，不再拉起 sing-box 前置服务。
• 优势：单核心运行，消除了两个不同核心之间的进程归属识别竞争。

方案 3：开启 sing-box 前置的 WFP 内核过滤驱动（windows_protect）

• 做法：在前置 sing-box 配置中开启 WFP（Windows Filtering Platform）驱动模式。
• 优势：WFP 在内核层同步拦截数据包并识别 PID，process_path: ["xray.exe"] 永远不会因为建连太快而漏检。

方案 4：在 TUN 设置中增加独立开关（类似 Block AAAA）

• 做法：在「TUN 设置」中增加一个显式开关：[ ] 自动排除代理节点 IP（仅限独立 VPS），默认关闭。
• 优势：CDN 用户保持默认关闭，完全不受影响；独立 VPS 用户若遇断流可一键勾选，无需手动查 IP 和算 CIDR。

方案 5：保持现状纯手动

• 继续保持 route_exclude_address 由用户手动配置。

---

想听听二位从架构演进和维护角度看，哪种思路更合适？多谢！