V2Ray FakeDNS 是什么:工作原理、开启方式与适用场景

解释 FakeDNS 用虚拟地址池换取域名信息的机制,对比普通 DNS 解析流程,说明它在 TUN 模式与透明代理下的优势和需要避开的情况。

本文速览

FakeDNS 的作用是保存域名与虚拟地址之间的映射,让只看到目标 IP 的透明代理重新获得域名。它适合 DNS 查询与后续连接都由同一代理链路接管的场景,不是换一个 DNS 地址就能生效的加速选项。下文先解释数据流,再给出 Xray 配置片段、v2rayN 检查路径,以及断网后的回退方法。

FakeDNS 是什么:先返回虚拟 IP,再还原域名

普通 DNS 查询回答的是“这个域名对应哪些真实地址”。FakeDNS 回答的是“用这个虚拟地址代表刚才查询的域名”。例如,应用查询 example.com,FakeDNS 从自己的地址池分配一个地址,并保存对应关系。应用随后连接这个地址,代理入口查回域名,再按域名规则选择直连或代理出站。

应用查询域名 分配虚拟地址 连接进入代理 映射还原域名 规则选择出站

关键不在“虚拟”两个字,而在完整闭环:回答 DNS 的映射表,必须能被处理后续连接的组件访问。如果 DNS 请求进入一个进程,连接却交给另一个没有共享映射的进程,后者只会看到无法用于公网访问的目标地址。即使两个程序都叫代理,也不能假定它们自动共享映射。

普通 DNS 与 FakeDNS 的区别

普通 DNS 也可以配合域名分流。应用使用 HTTP 代理或把域名交给 SOCKS 代理时,代理本来就可能知道域名;这时增加 FakeDNS 未必有收益。它更有价值的情况,是 TUN 或透明代理截获了一个以 IP 为目标的连接,而路由规则仍需要原始域名。

比较项普通 DNSFakeDNS
返回结果上游解析得到的真实地址从本地地址池分配的虚拟地址
域名保留方式依赖代理协议、嗅探或额外记录依赖域名与虚拟地址映射表
后续连接可以按真实 IP 发起连接必须先被接管并还原目标
真实解析时机通常在应用连接前按出站方式在后续阶段完成
停用后的缓存缓存地址在有效期内通常仍可连接残留虚拟地址可能让连接失败

FakeDNS 也不等于加密 DNS。DoH、DoT 解决的是 DNS 查询传输方式;FakeDNS 解决的是域名信息如何跟随后续连接。把查询交给 FakeDNS 后,直连目标仍可能需要真实解析,代理服务器的域名也要能被正常解析。不能据此认定所有 DNS 请求都已消失,或所有流量都经过代理。

地址池与端口:三个容易混淆的数字

131072
/15 网段包含的 IPv4 地址数量
65535
本文示例的 poolSize 配置值
53
常规 DNS 服务使用的端口号

198.18.0.0/15 覆盖 198.18.0.0 到 198.19.255.255,包含 131072 个地址;这不代表映射表一定同时保存这么多条记录。示例中的 poolSize 是映射池容量设置,不能把地址范围、映射容量和 DNS 缓存有效期当成同一个概念。

端口同样需要分清。系统向 DNS 服务发起查询,常见目标是 UDP 或 TCP 的 53 端口;代理软件内部的 DNS 接收端口可以另行配置。HTTP、SOCKS 的本地监听端口不是 DNS 端口,把系统 DNS 指向一个 HTTP 代理监听地址,不会自动产生 FakeDNS。

开启前先确认:谁接管 DNS,谁处理连接

v2rayN 是客户端界面,Xray 是可能被调用的代理内核。界面中的 TUN 功能还可能由独立组件承担,不能仅凭节点使用 VLESS 或 VMess,就判断 TUN 的 DNS 一定由 Xray 处理。协议描述的是节点连接方式,不决定本机 DNS 接管架构。

系统代理场景

接管对象
遵循系统代理设置的应用
域名来源
代理请求可能直接携带域名
DNS 范围
不保证接管系统全部查询
建议起点
先使用常规 DNS 与域名路由

只为浏览器代理访问时,不必先引入虚拟地址池。

TUN 或透明代理场景

接管对象
进入虚拟网卡或转发入口的数据包
域名来源
FakeDNS 映射或其他嗅探结果
DNS 范围
需要明确配置查询接管路径
必要条件
虚拟地址连接可回到对应映射表

先确认组件实现,再选择它支持的 FakeDNS 配置格式。

  1. 在 v2rayN 的「设置」→「参数设置」中核对当前核心相关设置,并查看启动日志实际启动的进程。版本之间分组名称可能调整,以当前界面和日志为准。
  2. 若界面提供「设置」→「DNS 设置」,先确认它修改的是哪个核心的配置,不要把同名 DNS 选项视为全局总开关。
  3. 记录当前系统代理状态、TUN 状态和 DNS 配置,再修改一项。保留原配置副本,便于直接回退。
  4. 若使用 v2rayNG 或 v2flyNG,同样先确认实际内核与配置支持情况;不要把桌面客户端的菜单路径照搬到安卓端。

Xray 配置示例:生成映射与还原目标缺一不可

下面是面向支持这些字段的 Xray 核心的配置片段,不是可单独运行的完整节点配置。使用前应核对本机核心版本的配置说明。客户端自动生成的文件可能在保存设置或切换节点时被覆盖,因此应通过客户端支持的自定义配置入口修改,而不是反复编辑临时文件。

第一部分:定义地址池并选择 FakeDNS

{
  "fakedns": [
    {
      "ipPool": "198.18.0.0/15",
      "poolSize": 65535
    }
  ],
  "dns": {
    "servers": [
      "fakedns"
    ]
  }
}

顶层 fakedns 定义映射池,dns.servers 中的 "fakedns" 选择内部 FakeDNS 服务。这个最小片段只说明字段关系,并未提供节点服务器域名、局域网域名和直连目标所需的真实解析方案。生产配置需要按用途安排普通解析器,避免把所有解析需求都交给虚拟地址池。

第二部分:让接收连接的入口还原域名

{
  "sniffing": {
    "enabled": true,
    "destOverride": [
      "fakedns"
    ]
  }
}

第二段应合并到实际接收目标连接的 inbound 对象中,不是新增一个顶层字段。destOverride 中的 "fakedns" 用于从 FakeDNS 映射恢复目标域名。不要只在接收 DNS 查询的入口设置它,却遗漏接收网页或应用连接的入口。

如何验证 FakeDNS 生效,而不是只看到一个虚拟地址

完整验证需要同时观察 DNS 答案、连接接管和最终访问结果。只看到 198.18.x.x,最多说明某一次查询拿到了虚拟地址,并不能证明浏览器连接成功,也不能证明域名分流使用了预期规则。

  1. 清除旧状态。关闭测试浏览器,应用配置并重启相关核心。Windows 可在终端执行下方命令清除系统 DNS 缓存;应用自身缓存仍可能需要单独清理。
  2. 查询测试域名。执行 nslookup example.com,记录返回地址和所显示的 DNS 服务器。若使用 IPv4 FakeDNS,检查 A 记录是否位于配置的地址池内。
  3. 验证应用路径。重新打开浏览器访问同一域名。浏览器的安全 DNS 可能绕过系统查询路径,应暂时关闭该功能进行对照,而不是认定命令行结果代表所有应用。
  4. 检查路由结果。在核心访问日志中核对目标域名与出站标记。日志格式依版本变化,应关注是否恢复到预期域名,而不只看“连接成功”字样。
  5. 检查直连与代理。各选一个已有规则覆盖的目标测试,确认域名命中后进入对应出站。不要用虚拟 IP 的归属地判断目标应当直连还是代理。
ipconfig /flushdns
nslookup example.com

如果 nslookup 返回真实 IP,原因可能是查询没有进入 FakeDNS,也可能是该域名按设计使用普通解析器。若返回虚拟 IP 但网页打不开,应优先检查虚拟网段路由和映射还原,不要先更换订阅或批量修改节点参数。

常见问题:虚拟地址、浏览器绕过与关闭后断网

查到了 198.18 开头的地址,为什么还是打不开?

先确认这个地址属于当前配置的地址池,再检查 TUN 路由是否接管它。然后查看接收连接的入口是否能读取同一份映射。只有 DNS 回答生效、连接却绕过代理,是最典型的半配置状态。

命令行查询正常,浏览器为什么还是走另一条路?

检查浏览器设置中的「安全 DNS」或「使用安全 DNS」选项,暂时关闭后重启浏览器对照。浏览器可能自行发起加密查询,也可能复用旧连接;清理系统缓存并不等于清掉浏览器内部状态。

关闭 TUN 后,为什么一些网站突然打不开了?

应用可能仍缓存虚拟 IP,但负责还原它的链路已经退出。恢复原系统 DNS 和路由,执行 ipconfig /flushdns,再重启受影响应用。若仍未恢复,检查虚拟网卡路由是否残留。

开启 FakeDNS 能降低游戏延迟吗?

它主要改变域名与连接的关联方式,不改变节点距离或链路拥塞。需要真实 IP 探测、内置网络诊断或自行校验地址的应用,反而可能与虚拟答案不兼容。应先使用普通 DNS 测试,再针对单个应用决定是否排除。

重启核心后,之前打开的网站为什么短暂失效?

不要假定映射表会跨重启保留。应用缓存的虚拟地址可能已找不到对应域名,也可能与新映射不一致。关闭旧连接、刷新 DNS 缓存并重新发起查询,比连续切换节点更有针对性。

适用场景与回退顺序

当透明代理需要稳定获得域名、DNS 与连接都由可协作的组件处理,并且愿意维护例外规则时,FakeDNS 才是合适的工具。它不是订阅节点的附加能力,也不要求服务端节点采用某一种协议;主要配置发生在本机接管与路由阶段。

需要回退时,先恢复原有 DNS 配置与接管规则,确保新查询得到正常结果;再退出相关 TUN 或透明代理链路,并清理系统及应用缓存。最后分别验证域名解析与普通访问。不要只删除地址池配置却继续向应用返回旧的虚拟答案,也不要只关闭代理进程而保留虚拟网段路由。

下载v2rayN按平台选择安装包