FakeDNS 是什么:虚假 DNS 原理、与 TUN 模式配合及适用场景

FakeDNS 原理：用临时地址保留域名

FakeDNS 返回的是本地映射地址，不是网站服务器的真实地址。普通 DNS 查询会把域名转换为真实 IP；FakeDNS 则从预设地址池分配一个地址，并记录“域名与临时地址”的对应关系。应用仍按正常流程连接这个地址，代理接管后再根据映射恢复域名，交给后续路由和出站处理。

Xray 常见的 IPv4 地址池示例是 198.18.0.0/15，范围从 198.18.0.0 到 198.19.255.255。这是用于基准测试的保留地址范围，不是公网服务器地址，也不是常见的家庭局域网私有地址段。应用拿到这样的结果，在正确配置的 FakeDNS 链路中属于正常现象。

这套机制的关键是“地址可以还原成域名”。如果应用连接假地址时绕过了代理，或者接管连接的内核没有那份映射表，假地址就无法用于正常访问。仅在 DNS 设置中填入一个地址池，却没有配置连接接管与还原环节，通常只会把能够访问的网站变成连接超时。

FakeDNS 与 TUN：接管流量不等于接管 DNS

TUN 负责把网络包送入代理处理，FakeDNS 负责让域名信息在这个过程中可恢复。两者经常搭配，但不是同一个功能。开启 TUN 后，应用的连接可能已被接管，DNS 查询却仍发送到路由器、企业 DNS，或者浏览器自己的加密解析服务；此时得到的仍是真实地址，FakeDNS 映射并未建立。

域名还原与流量嗅探也要区分。HTTP Host、TLS 中的服务器名称等信息可以帮助识别部分连接，但并非每种连接都能提供可读取的域名。FakeDNS 依靠之前的查询映射恢复域名，不必完全依赖应用层内容；不过应用直接使用 IP、没有经过该 DNS 入口时，它也无法凭空补出原始域名。

Xray 配置：地址池与入站还原分开检查

Xray 的 FakeDNS 需要地址池配置与实际 DNS 使用方式配合。下面是用于讲解的顶层配置片段，不是可直接运行的完整客户端配置。它只展示 IPv4 假地址池和内置 DNS 的服务器选择；完整配置还需要入站、路由和出站，且必须让应用查询确实进入这个 DNS 模块。

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

poolSize 表示映射池容量，不是 DNS 监听端口，也不是网络速度参数。示例中的 65535 不代表网站能够获得 65535 条并发连接。只有 FakeDNS 的 DNS 配置也不能承担所有真实解析需求：需要真实 IP 的直连目标、代理服务器域名以及特殊内网域名，都应有明确的真实解析路径，防止连接引导阶段也拿到无法直接使用的假地址。

对支持该机制的 Xray 入站，sniffing.destOverride 中的 fakedns 用于查找映射并恢复目标。不要把这组字段直接粘到其他内核的配置中，也不要只修改一个不接收 TUN 流量的入站。若客户端自动生成配置，手改临时文件还可能在下一次启动时被覆盖，应优先使用客户端提供的配置入口。

适用场景：域名分流优先，内网解析保留例外

FakeDNS 更适合“流量被透明接管，但需要按域名选择出站”的场景。例如某些应用不使用系统 HTTP 代理，开启 TUN 后只能看到连接目标 IP；通过 FakeDNS 保留映射，可以让路由重新获得域名条件。它改善的是识别链路，不会改变订阅节点质量，也不会把 VMess 自动转换成 VLESS。

局域网打印机、企业内部服务和依赖本地发现的应用不宜一律交给 FakeDNS。多播发现与普通单播 DNS 也不是同一套机制。应先保留这些服务原有的解析路径，再逐步扩大接管范围；如果把内部域名分给公共解析器，即使关闭 FakeDNS，也可能仍然无法访问。

验证与排障：先看解析，再看目标与出站

验证 FakeDNS 不应只看网页是否能打开。网页可能通过已有连接、缓存或浏览器独立 DNS 正常访问，无法证明新配置生效。建议只改一个设置，记录改动前后的 DNS 结果、连接目标和出站标签；以下顺序不依赖特定客户端版本，也不把某个菜单名称当成所有版本的统一入口。

1. 确认实际内核。在 v2rayN 的内核选择或运行日志中核对启动对象；记录当前客户端与内核版本。配置报“未知字段”时先检查字段所属内核，而不是反复切换订阅节点。
2. 检查 DNS 入口。普通 DNS 常使用 UDP 或 TCP 的 53 端口，但内置 DNS 模块不等于已经在系统上监听该端口。核对客户端的 DNS 接管配置和系统 DNS 地址，不要直接假设 127.0.0.1:53 可用。
3. 清理旧缓存。关闭测试应用后清理系统缓存，再重新启动应用；浏览器可能另有 DNS 缓存与安全 DNS 设置，需要分别核对。
4. 验证地址与还原。查询结果应符合所配置的地址池，连接日志则应能显示恢复后的域名或相应处理记录。仅看到 198.18.x.x 不能证明出站成功。
5. 核对真实解析和路由。检查直连目标与代理服务器域名是否能得到真实地址，再确认域名规则命中的出站。排障完成后恢复常规日志级别，避免长期保存大量连接信息。

Windows 可用以下命令清理系统 DNS 缓存，并查看各网络接口配置的 DNS 服务器。第二条需要在 PowerShell 中运行。它们用于定位入口，不会自动修改客户端规则，也无法清理应用内部的全部缓存。

ipconfig /flushdns

Get-DnsClientServerAddress -AddressFamily IPv4

如果测试工具返回真实地址，先确认它查询的是哪个 DNS 服务器，再判断 FakeDNS 是否失败；如果返回假地址但连接超时，重点检查地址池流量是否进入正确入站，以及映射是否仍然有效。重启内核后，应用可能继续使用旧假地址，而新内核已经没有对应映射，这时重启应用并清理缓存比反复更换节点更有针对性。

• 有 AAAA 结果但 IPv4 映射正常：检查 IPv6 接管与 DNS 策略，不能仅凭 IPv4 成功断言所有连接都已进入代理。
• 企业网络出现异常：检查是否已有网络设备使用 198.18.0.0/15，避免地址池与现有路由冲突。
• 怀疑 DNS 泄漏：单独检查传统 DNS、加密 DNS 和 IPv6 路径；假地址本身不能证明所有查询都没有外发。

常见问题：开关、延迟与关闭后的恢复

最终判断以完整连接链路为准：应用获得了什么地址，哪个入站接管连接，能否恢复域名，规则选择了哪个出站。需要进一步调整路由与代理模式时，可阅读完整手册；初次配置客户端则先按使用指南建立可用基线，再增加 FakeDNS。