FakeDNS 虚拟 DNS 映射原理详解:什么场景该开、什么场景别碰

FakeDNS 解决的不是“解析更准”，而是域名身份丢失

应用访问一个域名时，通常先向 DNS 请求真实地址，再连接返回的 IP。进入代理核心的连接如果只剩目标 IP，域名信息就可能已经丢失。此时，按 geosite、完整域名或域名后缀编写的路由规则无法直接匹配，只能依赖目标 IP、协议嗅探结果或其他补充信息。

FakeDNS 的作用，是在 DNS 阶段先返回一个临时的虚拟地址，并在核心内部保存“域名—虚拟地址”的对应关系。应用随后连接该虚拟地址时，核心可以反向找回原始域名，再按域名规则决定直连、代理或阻断。它本质上是一张短期映射表，不是公共 DNS 服务，也不会把虚拟地址发布到互联网。

Xray 常见的 FakeDNS 地址池会使用专门保留的 IPv4 网段，例如 198.18.0.0/15。该地址段不会成为目标站点的真实地址。它只在本机或受控网络栈内充当索引。具体地址池、容量和处理方式由核心配置及客户端版本决定，不应把某一个默认值当成所有环境都固定不变的参数。

一次请求怎样经过虚拟地址映射

以 v2rayN 的 TUN 模式为例，浏览器准备访问 docs.example.net。启用 FakeDNS 且 DNS 流量已被 TUN 接管后，完整链路大致分为六步：

1. 应用向系统发起 docs.example.net 的 DNS 查询。
2. TUN 网络栈捕获查询，并把它交给核心配置中的 DNS 处理链。
3. FakeDNS 从地址池分配一个虚拟 IP，同时记录该 IP 对应的原始域名。
4. 应用收到虚拟 IP，随后像连接普通地址一样发起 TCP 或 UDP 流量。
5. TUN 再次捕获该连接。核心查询映射表，恢复出 docs.example.net。
6. 路由模块按域名规则选择出站；真正需要的目标解析由相应出站链路继续完成。

应用查询域名
    ↓
TUN 捕获 DNS
    ↓
FakeDNS 返回虚拟 IP，并保存映射
    ↓
应用连接虚拟 IP
    ↓
核心恢复原始域名
    ↓
域名路由匹配 → 选择直连或代理出站

这里所说的“减少一次 DNS 往返”，指应用在建立连接之前不必等待公共上游返回真实 IP。FakeDNS 可以在本地立即给出映射结果。但这不代表整个访问过程完全不再解析域名。代理出站可能把域名交给远端解析，直连出站也可能根据配置调用指定 DNS。被省掉的是前置阶段的一次真实地址查询，不是所有链路上的域名解析。

映射存在生命周期。缓存过期、核心重启、配置重载或地址池条目被回收后，旧虚拟地址可能失去对应关系。因此，不应把 FakeDNS 返回值保存为长期业务数据，也不适合将它复制到其他设备使用。

FakeDNS 与嗅探、真实 DNS 的分工

域名嗅探和 FakeDNS 经常同时出现，但两者获取域名的时机不同。嗅探是在连接已经进入核心后，从协议数据中尝试提取目标名称，例如 HTTP 请求中的 Host，或 TLS 握手中的服务器名称。FakeDNS 则更早介入，在应用查询 DNS 时建立确定的映射。

嗅探依赖流量中存在可识别字段。协议行为变化、加密握手形式变化、应用直接连接 IP，或者首包不包含可用域名时，嗅探结果可能为空。FakeDNS 不需要从业务载荷猜测域名，只要 DNS 查询和后续连接都经过同一套受控网络栈，就能沿映射表恢复名称。

真实 DNS 仍然负责找到最终可连接的目标地址。FakeDNS 只是把“应用先解析、再连接真实 IP”的顺序，改成“应用取得虚拟 IP、核心恢复域名、出站阶段再解析”。这一变化让解析位置可以跟随路由结果：代理域名可由代理链路处理，直连域名可交给本地选定的 DNS，从而减少解析结果与实际出站位置不一致的问题。

TUN 模式下适合启用的场景

按域名做精细路由

当规则主要依赖 geosite、域名后缀或完整域名时，FakeDNS 最有价值。应用即使原本只会把真实 IP 交给网络栈，核心仍可通过虚拟地址映射找回域名。对“指定站点走代理、常用本地域名直连、其余按默认规则处理”这一类配置，域名身份越稳定，匹配结果越容易解释。

希望解析位置跟随出站

同一个域名在不同网络位置可能返回不同地址。先由本地 DNS 解析，再把真实 IP 交给代理链路，可能造成解析位置与连接位置分离。FakeDNS 让应用先拿到虚拟地址，等核心确定出站后再处理真实解析。对于需要由代理侧完成域名解析的连接，这种顺序通常更合理。

接管不支持单独设置代理的程序

TUN 模式可以承接没有 HTTP 或 SOCKS 代理选项的程序。此时，FakeDNS 与 TUN 配合，可让这些程序的普通系统 DNS 查询和后续连接进入同一处理路径。只要程序遵循系统网络栈并且流量确实被接管，域名规则就能获得较完整的匹配条件。

减少协议嗅探的单点依赖

嗅探仍可作为辅助信息，但不必独自承担域名恢复任务。对于连接建立较快、首包特征不稳定或使用 UDP 传输的应用，预先建立的 FakeDNS 映射通常更直接。需要注意，FakeDNS 并不会让所有 UDP 协议自动兼容；它只负责目标映射，协议本身是否能经当前出站传输仍取决于节点、核心和路由配置。

这些场景应关闭或绕过 FakeDNS

局域网名称和分流 DNS 依赖真实结果

企业内网、家庭设备名、路由器管理域名和分区域 DNS，常常依赖局域网解析器返回私有地址。若这些查询被 FakeDNS 提前替换，应用可能无法取得服务发现所需的真实记录。处理方式通常是让内网域名、私有地址段及指定 DNS 服务器直连，并从 FakeDNS 规则中排除。若排除关系难以确认，关闭 FakeDNS 后先验证内网访问更稳妥。

应用会读取或校验 DNS 返回内容

部分诊断工具、网络管理程序、域名解析测试程序和业务客户端，不只是拿到地址后建立连接，还会展示、保存、比较或校验 DNS 应答。它们需要看到 A、AAAA 或其他记录的真实内容。虚拟地址会改变这类程序观察到的数据，因此不适合参与相关查询。

连接没有经过同一套 TUN 映射链

FakeDNS 的前提是“查询时写入映射，连接时读取映射”。如果 DNS 查询被捕获，但后续连接绕开 TUN，应用会尝试把虚拟地址直接发往普通网络；反过来，如果连接进入 TUN，而 DNS 查询由其他设备或独立加密解析通道完成，核心也可能得不到映射。两段路径不一致时，应先统一接管范围，无法统一则关闭 FakeDNS。

需要把解析结果交给其他设备

虚拟地址只在生成它的映射实例中有效。把该地址写入配置文件、发送给局域网其他主机、用于端口探测，或者在核心重启后继续复用，都可能得到失败结果。旁路由部署尤其要确认 DNS 应答与后续连接是否始终回到同一实例。若客户端可能改走其他网关，返回真实地址更容易保持行为一致。

排障阶段需要观察原始解析链

当问题集中在上游 DNS、分流 DNS、域名污染、缓存或 IPv4 与 IPv6 选择时，FakeDNS 会增加一层转换。此时可以暂时关闭它，直接观察查询发往哪个服务器、返回哪些记录、连接选择哪个地址。确认真实解析链正常后，再重新启用映射并比较差异。

在 v2rayN 中启用前的检查顺序

v2rayN 不同版本对 TUN、DNS 和核心配置的入口组织可能调整，选项名称也可能随内核能力变化。与其照抄某一张旧界面截图，不如按数据路径检查。下面这组顺序适用于大多数配置：

1. 确认 TUN 已实际运行。 先观察普通应用流量是否进入核心，避免在接管尚未成功时叠加 DNS 变量。
2. 确认 DNS 查询进入 TUN。 系统中残留的独立 DNS 工具、浏览器自带解析设置或其他网络服务，可能让查询绕过映射链。
3. 检查私有网络排除项。 局域网域名、网关地址、打印设备和内部服务应按实际环境决定直连或排除。
4. 简化路由规则。 初次测试只保留明确的直连、代理和默认规则，避免多个规则集同时影响判断。
5. 再启用 FakeDNS。 重载配置后重新发起查询，不要用应用缓存中的旧地址判断结果。
6. 查看日志中的域名与出站。 重点确认核心是否恢复出原始域名，以及该域名最终匹配到哪一条路由。

如果 v2rayN 使用订阅节点，FakeDNS 与节点协议不是同一个层级。VMess、VLESS 等节点参数决定代理出站如何连接服务器；FakeDNS 位于本地 DNS 与路由处理环节。节点能连接，不代表 FakeDNS 配置一定正确；FakeDNS 映射正常，也不能修复服务器地址、端口、安全层或传输参数错误。

同理，Android 上的 v2rayNG 使用 Xray 内核时，也要区分本地 VPN 接管、DNS 设置与节点协议。v2flyNG 使用 v2fly 内核，具体可用能力应以内核和客户端当前实现为准。不要把某个桌面配置字段原样搬到另一内核，再假设行为完全一致。

常见故障如何定位

启用后所有域名都打不开

先检查 DNS 查询是否进入 FakeDNS，再检查虚拟地址对应的连接是否被 TUN 捕获。若系统路由把保留地址段送往普通网卡，映射就无法在核心内部闭环。还应查看地址池是否与本地已有网络、虚拟机网络或其他隧道配置冲突。

网页可访问，但局域网设备失联

这通常不是节点故障，而是内网名称或私有地址被纳入了错误的处理范围。检查局域网域名是否应交给本地 DNS，私有网段是否直连，以及本地服务发现流量是否需要保持在物理网络中。先为明确的内网范围建立排除，再测试设备名与直接 IP 访问的差异。

日志里只有虚拟 IP，没有原始域名

这说明连接阶段没有成功读取映射。可能原因包括查询与连接走了不同核心实例、映射已过期、应用复用了旧缓存，或某段流量绕开 TUN。关闭应用后清理系统 DNS 缓存，重载核心，再进行一次全新的查询与连接，通常比反复刷新同一页面更容易得到有效日志。

规则命中与预期相反

确认规则顺序。路由通常按配置顺序匹配，较宽泛的 IP、端口或域名规则如果排在前面，可能提前接管连接。还要区分 FakeDNS 恢复出的域名、嗅探得到的域名和最终解析出的 IP。排障时一次只保留一种主要判断条件，定位后再恢复组合规则。

运行一段时间后偶发失败

观察失败是否发生在休眠恢复、网络切换、核心重载或长时间保持连接之后。这些事件可能让应用缓存的虚拟地址与当前映射表不同步。关闭并重新打开应用、刷新 DNS 缓存、重建 TUN，能够帮助确认问题是否来自陈旧映射。如果频繁出现，还应检查地址池容量及是否存在大量短期域名查询。

最终选择：按流量路径决定，不按开关名称决定

FakeDNS 适合的条件很明确：DNS 查询与后续连接由同一 TUN 链路接管，路由需要稳定获得域名，而且最终解析可以放到出站阶段完成。在这种结构中，它能减少应用连接前的一次真实 DNS 等待，并让 geosite、域名后缀和完整域名规则获得更可靠的输入。

应关闭或绕过的条件同样明确：程序必须读取真实 DNS 记录，局域网依赖分流解析，虚拟地址会被传给其他设备，或者查询与连接无法保证进入同一映射实例。FakeDNS 不是默认越多越好的加速项，而是一种改变解析顺序的路由工具。

实际配置时，先让 TUN、真实 DNS 和基础路由独立工作，再加入 FakeDNS。每次只改变一个环节，并用日志确认“查询、映射、连接、路由、出站”五个阶段。这样即使出现问题，也能判断故障是在 DNS 接管、映射恢复还是规则匹配，而不是把所有异常归到节点质量上。