FakeDNS 是什么：Xray 虚拟 IP 解析原理、适用场景与开启注意事项

FakeDNS 的原理：返回地址，不先查询真实 IP

普通 DNS 解析会向上游查询域名的 A 或 AAAA 记录，取得真实地址后再建立连接。FakeDNS 则在本地维护一张“域名与虚拟 IP”的映射表：应用查询域名时，先从指定地址池分配一个地址并返回。这个地址不是网站服务器，不能脱离映射表直接使用。

假设应用查询 example.com，本地返回池内的某个 198.18.x.x 地址。应用随后连接这个地址，流量必须回到能够读取同一映射表的处理链路。Xray 才能恢复原来的域名，匹配域名规则，并把请求交给相应出站。若连接绕过接管链路，系统只会尝试连接一个并不承载该网站的虚拟地址。

这解释了它为什么常与 TUN 配合：虚拟网卡可以接住应用发往这些地址的 IP 流量。但 TUN 只是接管入口，不自动保证 DNS 查询也进入 FakeDNS，更不保证不同内核之间共享映射。DNS 查询与后续连接必须形成闭环。

地址池与映射容量：三个数字怎么理解

Xray 的 FakeDNS 配置可以指定 ipPool 与 poolSize。下面以 IPv4 教学片段为例，数字描述配置含义，不代表所有客户端都采用相同默认值。地址池与映射容量是两件事，不能因为网段足够大，就假定映射永远不会被回收。

198.18.0.0/15 属于保留的网络基准测试地址范围，不是公网网站地址，也不是普通家庭局域网的私有网段。如果企业测试网络或其他隧道已经使用这一范围，仍可能发生路由冲突。开启前应检查本机路由，而不是把“保留地址”理解成绝不冲突。

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

这是 Xray 配置的局部结构，不是完整客户端配置。它没有提供入站、出站、DNS 接管与路由规则，也没有为直连目标安排真实解析。不能把它当作可直接连接的文件。映射是运行时状态，内核重启后不能假定旧地址仍对应原域名。

FakeDNS、真实 DNS 与域名嗅探的区别

FakeDNS 不等于加密 DNS，也不等于 HTTP 或 TLS 嗅探。前者建立映射，后者从连接内容提取可能的域名。Xray 的 FakeDNS 还原依靠映射表，并不要求每条连接都能从应用层读到主机名。即便如此，若应用直接访问一个真实 IP，且没有发生对应的域名查询，FakeDNS 也无法凭空知道其域名。

对需要代理的域名，FakeDNS 可以省掉客户端先等待真实 IP 的环节；代理出站若按域名交给远端处理，解析可在后续链路完成。但访问直连网站时，仍需要真实地址。解析成本可能只是换了位置，不是从整个连接中消失。网页加载还受节点延迟、丢包、服务器响应与资源数量影响，不能据此承诺固定提速比例。

• 适合：应用主要发起 IP 连接，TUN 已稳定接管，希望域名规则获得更完整的匹配依据。
• 不必优先开启：浏览器已通过代理协议传递域名，现有系统代理工作正常，暂时没有域名丢失问题。
• 需要谨慎：企业内网、局域网设备发现、依赖真实解析结果的软件，以及与其他虚拟网卡同时运行的环境。
• 不能替代：正确的订阅参数、可用的节点、准确的系统时间和服务端支持。

v2rayN 开启前：先核对内核与 DNS 入口

v2rayN 是客户端界面，Xray 是可被调用的内核。不能看到界面里有“TUN”就推断该模式一定读取 Xray 的 fakedns 字段。部分运行模式由不同的配置生成路径负责，实际字段和接管方式可能不同。先看启动日志记录的内核名称、版本和配置加载结果，再决定是否使用本文的 Xray 字段。

1. 保留基线：备份当前配置；先关闭 TUN，用原有系统代理验证同一节点能访问目标网页。记录已有 DNS、路由模式和本地端口。
2. 检查设置：从 v2rayN「设置」→「参数设置」核对内核与入站相关配置，再检查「设置」→「DNS 设置」中的现有内容。不同版本菜单名称可能有差别，以实际界面为准。
3. 核对生成结果：确认运行配置是否包含预期的 fakedns、DNS 服务器列表和入站 sniffing 字段。不要只依据一个开关的选中状态判断生效。
4. 检查接管范围：DNS 查询要进入预期的本地处理链路，虚拟网段连接也要被接管。注意浏览器安全 DNS、应用内置 DoH 和 IPv6 查询是否绕开该链路。
5. 单项验证：保存后按客户端要求重启内核，先验证一个代理目标、一个直连目标，再测试局域网服务。一次只更改一类设置。

尤其要留意 routeOnly：只把恢复出的域名用于规则匹配，与将其作为连接目标，是不同处理方式。若后续出站仍拿着虚拟 IP 发起连接，就可能超时。应按照当前内核的配置说明与完整出站设计核对，不要孤立复制某个布尔值。

怎么验证：解析结果与连接日志要一起看

只看到一个 198.18.x.x 地址，最多证明该次查询拿到了虚拟结果，不能证明代理出站成功。反过来，网页能打开也可能只是浏览器绕过了系统 DNS。验证要同时观察“查询从哪里走”和“连接最后发给谁”。

1. 关闭浏览器中已有的测试标签页；在 Windows 终端运行 ipconfig /flushdns，再退出并重新打开浏览器，避免旧缓存影响观察。
2. 运行下面的查询，检查系统当前使用的解析链路是否返回池内地址。不要在查询中指定外部 DNS，否则测试的就不是原有系统路径。
3. 访问同一个域名，查看内核日志中的目标域名与出站标签。必要时临时提高日志级别，验证后恢复，避免长期记录过多访问信息。
4. 再检查一个应当直连的目标，确认它没有把虚拟 IP 当作最终服务器地址；同时验证本地路由器和内网服务是否仍可访问。

ipconfig /flushdns
nslookup example.com
route print

nslookup 适合观察常规 DNS 查询，不代表浏览器内置 DoH 的实际行为。route print 用来检查虚拟网段的路由归属；没有单独列出该网段，也不能立即认定接管失败，因为某些 TUN 配置使用更大范围的路由。应结合接口、跃点和客户端日志判断。

常见问题：缓存、IPv6 与关闭后的恢复

FakeDNS 的价值是让域名信息在特定接管链路中保留下来。它不会改变 VMess、VLESS 的认证参数，也不会修复失效订阅或不可达节点。基础连接已经稳定、有明确域名分流需求、能够验证并回退配置时，再考虑开启；只是浏览器偶发卡顿，应先按常见问题中的系统代理、DNS 与路由步骤缩小范围。