Architecture & DNS/IPv6 routing behavior in Xray TUN mode (7.23.4 vs 7.24.4+)

[Obs-Mango]

大家好，近期社区中关于 Xray TUN 模式在 7.23.4 升级到 7.24.4+ 后的网络行为出现了一些讨论（例如 #9878、#9921、#9930 等）。我们梳理了 7.23.4 与 7.24.4+ 在 Xray TUN 上的实现细节，希望发起一个讨论，向作者和各位贡献者请教原本的设计初衷，并探讨如何让 Xray TUN 兼顾各种网络环境（IPv4 节点、双栈环境、Reality/ECH 兼容等）。

---

1. 架构对比 (Implementation Differences)

配置项 (Setting)	7.23.4 (旧版)	7.24.4+ (新版)	现象与影响 (Observed Impact)
TUN 网卡 DNS 地址 (tunInbound.settings.dns)	["172.18.0.1"] (虚拟网关)	["1.1.1.1", "8.8.8.8"]	指向公网 DNS 时，Windows 不直接走 Xray 内置 DNS 模块，容易受到系统多宿主 DNS 或上游公共 DNS 解析策略的影响。
Xray DNS 解析策略 (queryStrategy)	缺失（未配置）	缺失（未配置，默认 UseIP）	sing-box 端通过 rule.strategy 映射了 Strategy4Proxy（如 prefer_ipv4 / ipv4_only）；而 Xray 端未配置 queryStrategy，向上游请求时始终返回 AAAA 记录。
嗅探域名路由 (sniffing.routeOnly)	false (随入站设置)	true (硬编码)	true 保护了 Reality、ECH 和伪装 SNI 服务；但当目标域名解析出 IPv6 地址，而代理节点为纯 IPv4 时，连接由于无法回退域名而超时。
IPv6 默认路由 (autoSystemRoutingTable)	仅当开启 IPv6 时添加 ::/0	0.0.0.0/0 与 ::/0 处理	当本地具备 IPv6 但代理节点仅为 IPv4 时，双栈解析与路由选择可能导致部分服务（如 Google / YouTube）无法连接。

---

2. 问题与瓶颈分析 (Analysis of Issues Reported)

1. IPv4 代理节点与 IPv6 AAAA 记录冲突 ([Bug]: 7.23.4升级到7.24.4后XRay TUN模式下有些网站打不开 #9878):

   • 很多用户的家庭宽带自带 IPv6，但所使用的 VPS 节点仅有 IPv4 出口。
   • 当 Windows 在 TUN 模式下发起 DNS 查询时，上游返回了 Google / YouTube 的 AAAA 记录。
   • 因为开启了 routeOnly: true，Xray 保留了目标 IPv6 地址并转发给纯 IPv4 代理节点，导致握手直接超时（关闭 TUN 的 IPv6 后恢复正常）。
   • 对比 sing-box: sing-box 在 DNS 规则中设置了 strategy = "prefer_ipv4" 或 Happy Eyeballs 回退，因此不会出现此超时。

2. Xray DNS 模块与 Strategy4Proxy UI 选项的联动:

   • 目前 GUI 的“DNS 设置”中提供了 Strategy4Proxy（如 UseIPv4、UseIP 等）。
   • 在 sing-box 模式下该选项已正确下发给内核；但在 Xray 模式下，Xray 的 dns.queryStrategy 和 dns.servers[].queryStrategy 似乎未被完整填充。

---

3. 希望探讨的问题 (Questions for Maintainers & Contributors)

1. TUN DNS 地址绑定:
   将 tunInbound.settings.dns 统一绑定到本地网关 172.18.0.1，使所有端口 53 流量统一进入 Xray 内置 DNS 引擎处理，是否符合预期规划？
2. queryStrategy 的默认策略:
   在 Xray TUN 模式下，让 Xray DNS 的 queryStrategy 默认遵循 GUI 的 Strategy4Proxy（或在未指定时对代理域名默认过滤 IPv4 AAAA 记录），是否是最佳的通用解决方案？
3. routeOnly 与域名传递的权衡:
   如何在保证 Reality/ECH 等高级协议安全（需要 routeOnly: true）的前提下，让 IPv4-only 节点能够平滑处理双栈环境？

非常感谢 @2dust、@DHR60 以及所有贡献者的付出！期待大家的宝贵意见和建议。

[DHR60]

是否可以当禁用 IPv6，在路由规则中预置一个高优先级的 ipv6 block，同时 dns queryStrategy 设置为 UseIPv4？

[Obs-Mango]

同意您的方案，我们在测试分支中已经实现了：当 TUN 启用且用户未自定义 queryStrategy 时，
Xray DNS 自动使用 UseIPv4。从 DNS 层面彻底阻止 AAAA 记录返回。

您说的 TCP 终结问题非常关键——正因为 Xray TUN 入站会先完成 SYN-ACK，
后续 IPv6 不可达时只能 RST，浏览器等应用的 Happy Eyeballs 回退已经失效了。
所以路由层 block IPv6 是治标不治本，DNS 层过滤才是根本方案。

关于 DNS 泄露，我们测试了一种不依赖 WFP 的轻量方案：
TUN 启动时自动设置 HKLM 注册表 DisableSmartNameResolution = 1（禁用 SMHNR），
同时将 xray_tun 的 Interface Metric 设为 1（最高优先级），TUN 停止时自动恢复。
虽然不如 WFP 那么严密，但对大多数用户场景已经有效。

[DHR60]

Xray DNS 自动使用 UseIPv4

不应该自动，应该给选项，且默认关闭

TUN 启动时自动设置 HKLM 注册表 DisableSmartNameResolution = 1

xray 社区那边测试了，效果不佳

[DHR60]

所以路由层 block IPv6 是治标不治本，DNS 层过滤才是根本方案。

DNS 层过滤覆盖场景更少，解决不了预置 ipv6 和 DoH

[Obs-Mango]

感谢反馈！

关于 UseIPv4：
同意不应该强制。我们的实现是：当用户在 GUI「DNS 设置」中配置了 Strategy4Proxy 时，
Xray DNS 的 queryStrategy 会直接使用用户选择的值（UseIPv4 / UseIP / UseIPv6）。
仅当用户未配置 Strategy4Proxy 时，TUN 模式才默认回退到 UseIPv4。

这样双栈用户可以在 GUI 中手动选择 UseIP 来保留 IPv6，
而大多数使用纯 IPv4 节点的用户不需要额外配置就能正常工作。
您觉得这个逻辑是否合理？还是应该在未配置时也默认 UseIP？

关于 SMHNR 注册表：
了解，感谢告知 Xray 社区的测试结论。我们会把 SMHNR 方案作为可选项而非默认行为。

DNS 层过滤覆盖场景更少，解决不了预置 ipv6 和 DoH

确实，DNS 层过滤无法覆盖以下场景：

1. 应用内置 DoH（如 Chrome 安全 DNS）
2. 应用硬编码 IPv6 地址（如 [2607:f8b0::1]）

这些场景下只有路由层 block IPv6 或 WFP 才能拦截。

不过对于绝大多数用户的常规浏览场景，应用使用系统 DNS 解析器，
DNS 层 queryStrategy 过滤是有效的。
两种方案结合使用（DNS 层 UseIPv4 + 路由层 IPv6 block）应该能覆盖更多场景。

[DHR60]

和 Strategy4xxx 不太合适，它的功能是指定传递域名还是传递 IP ，与 queryStrategy 无关，后者更倾向于 block 语义

如果要加可以考虑在高级设置中添加一个 Switch

[DHR60]

直接关闭 tun 的 ipv6 是否有效？

[Obs-Mango]

关闭 tun ipv6 时，ping/tcping ipv6 能否触发终结前 unreachable。这个行为未知，也应该测下

补充一下实际测试的详细底层数据（Windows 11 环境，TUN IPv6 关闭）：

1. ICMP ping 测试：
   执行 ping -6 2606:4700:4700::1111
   结果：Windows 内核在 0ms 内直接返回 PING: transmit failed. General failure.，底层协议栈直接拒绝，未发出任何物理报文。

2. TCP 端口与原生 Socket 测试：
   使用原生 InterNetworkV6 TCP Socket 直接 Connect 目标 IPv6 的 443 端口：
   结果：耗时约 180ms，Windows 直接抛出底层错误：
   WSAENETUNREACH (10051): A socket operation was attempted to an unreachable network [2606:4700:4700::1111]:443

测试结论：
在未分配 TUN IPv6 路由且本地为 IPv4 的环境下，Windows 会在 ~180ms 内迅速触发 Network Unreachable（10051），不会发生慢速的 TCP SYN 握手挂起，浏览器的 Happy Eyeballs 可以快速完成回退。
但在本地物理宽带有原生 IPv6 路由的环境下，关闭 TUN IPv6 会导致 IPv6 报文直接走物理网卡路由流出（绕过代理）。因此在 DNS 层面配合 queryStrategy: "UseIPv4" 依然是确保 IPv4 代理节点完全走通的最稳妥方案。

更正一下之前测试数据的适用范围：

我们的测试环境是纯 IPv4 宽带，无法验证双栈场景。如果您有双栈环境，欢迎补充实测数据

---

另外，关于防止物理网卡 DNS 泄露，我们测试验证了一种基于 Windows Defender 防火墙的轻量方案：
Windows 防火墙底层本身就是基于 WFP 构建的。我们在 TUN 启动时通过原生防火墙，仅针对物理网卡（interfacetype=wireless 和 interfacetype=lan）添加出站 UDP/TCP 53 端口的 Block 规则，而虚拟网卡（xray_tun）保持放行，TUN 停止时自动清理。

实测效果：

1. 彻底阻断了 SMHNR 向物理网卡发出的明文 53 端口 DNS 请求（达到了等同于直接写 WFP 规则的拦截效果）。
2. 完全不需要引入底层 C++ 驱动或复杂的 P/Invoke / COM 代码，非常轻量、稳定且安全。
3. 配合 TUN 的 DNS 拦截，实现了真正的零泄露。

[DHR60]

经我实测，不认为有效

queryStrategy: "UseIPv4" 可以作为单独选项 “Block AAAA” 存在

[Obs-Mango]

经我实测，不认为有效

queryStrategy: "UseIPv4" 可以作为单独选项 “Block AAAA” 存在

感谢测试与反馈！

1. 关于 queryStrategy 的设计考量（自动默认 vs 独立开关）：
   最初我们倾向于自动/无开关的方案，主要是希望能对齐 sing-box 的使用体验：sing-box 在 TUN 模式下内部默认就具备了类似 prefer_ipv4 / Happy Eyeballs 的平滑机制，普通用户无需专门找开关配置即可开箱即用。
   考虑到社区中绝大多数用户的代理节点依然是纯 IPv4 出口（未配置 IPv6 节点），在未特殊配置时默认优先 IPv4 能直接避免绝大多数用户的网站超时问题。

   不过我也很想向您请教：从整体架构和用户体验角度来看，您认为做成显式的「Block AAAA」开关相比自动默认更好的主要考量是什么呢？（例如是否主要为了避免影响有原生 IPv6 节点需求的用户？）非常期待听听您的看法。

2. 关于防火墙规则实测：
   请教一下您实测中发现防火墙规则无效的具体场景是怎样的呢？（例如是遇到应用内置 DoH / 443 端口绕过、本地 Localhost 解析器，还是有特定虚拟网卡类型未被 wireless/lan 覆盖？）我们很希望能了解具体的测试条件和失效现象，以便深入评估。

[DHR60]

ok，假定一个统一场景和前提，不知道能否接受

1. Tun 入站的始终是 IP 目标而不是域名目标，不存在所谓 Happy Eyeballs
2. 对外 DNS 不存在 prefer，prefer 始终是对内选项。应用发起请求是先发起多个不同 QTYPE DNS 请求，而目前内核均不存在跨请求对比整合功能，因此只有转发和 Block 两种结果
3. 所以不存在“默认优先 IPv4”，要做只能做成“完全阻止 IPv6 查询”，而这不适合作为默认和隐式选项

对于防火墙先前说了，不做考虑

我的实测结果是 Windows 下在关闭 tun ipv6，开始确实会报 unreachable，十分钟左右后变为等待直到超时，并且不会进核心，不认为应该在 GUI 解决。
而在 linux 下则是始终等待直到超时，并且不会进核心。

[DHR60]

所以开启 tun ipv6 随后 block ipv6 又是另外一个问题，但是上面已经得出结论这种方案有问题，不会触发部分回退