FakeDNS 是什么:V2Ray 虚拟 DNS 工作原理与开启时机

FakeDNS 是什么：用虚拟地址关联域名

普通 DNS 查询会把域名转换为可连接的真实地址。FakeDNS 则从指定地址池取出一个虚拟 IP 返回给应用，并记录“域名与虚拟 IP”的对应关系。应用仍然按照正常流程发起连接，但这个地址不是网站服务器的实际地址，必须由本地代理接回处理。

例如，应用查询 example.com，本地 FakeDNS 可以分配 198.18.0.1。应用连接该地址的 443 端口时，代理查询映射表，把目标恢复成 example.com:443，再进行域名规则匹配与出站选择。这个地址仅为流程示例，不代表某次查询一定会分配相同地址。

它解决的是“连接到达代理时只剩 IP，域名信息已经丢失”的问题。它不负责提供节点，不替代 VMess、VLESS 或 Trojan，也不改变 REALITY 的握手配置。订阅负责提供连接参数，FakeDNS 负责保留本地连接与域名之间的关联，两者所在层次不同。

域名还原与普通嗅探有什么不同

普通协议嗅探会分析连接中的应用层信息，例如 HTTP Host 或 TLS ClientHello 中可见的服务器名称。FakeDNS 还原则依赖先前保存的映射，不需要等应用主动在载荷中暴露域名。两种方式可以配合，但不能把“开启 HTTP/TLS 嗅探”直接等同于“已经完成 FakeDNS 配置”。

• 映射还原：根据目标虚拟 IP 查找域名。前提是分配地址与接收连接的一侧共享有效映射。
• 协议嗅探：从连接内容提取域名。对于没有可识别域名信息的流量，不能保证得到结果。
• 域名路由：拿到域名后匹配规则。恢复了域名，不代表规则一定命中，还要检查规则顺序与目标出站。
• 实际连接：代理出站可能把域名交给远端解析；直连出站通常仍需要获取真实地址，具体取决于内核与出站设置。

这也解释了为什么开启 FakeDNS 不等于彻底取消真实 DNS：应用端可能省去一次等待真实解析的过程，但最终建立直连、解析节点服务器域名等环节仍可能需要真实 DNS。远程代理链路中，目标域名也可能由远端继续解析。

FakeDNS 与 TUN：需要接通的两个入口

TUN 提供虚拟网络接口，用来接收符合路由条件的 IP 流量；FakeDNS 提供虚拟 DNS 应答与映射。两者经常同时出现，是因为 TUN 能把发往虚拟地址的连接重新送回代理，但 TUN 本身不保证所有 DNS 都已接管，也不保证使用某一种 FakeDNS 实现。

在 v2rayN 中，TUN 路径与常规代理路径可能使用不同的配置生成方式或处理模块。不要把某个内核的 fakedns JSON 直接粘贴到另一套 TUN 配置格式中。应先确认当前选中的内核、正在使用的配置与日志，再判断 DNS 是由哪一层处理。

1. 先关闭 TUN，用原有系统代理验证节点能否正常连接，排除订阅和服务端故障。
2. 打开 v2rayN 的「设置」→「参数设置」，检查当前版本提供的内核与相关配置项；具体分页名称随版本变化，以实际界面为准。
3. 启用 TUN 后检查系统路由，确认虚拟地址段会进入接管路径，而不是发往物理网关。
4. 同时检查 DNS 接管与应用自身的加密 DNS 设置，避免只接住业务连接却没有建立域名映射。

V2Ray / Xray 配置：分配与还原必须成对

下列是支持对应字段的 V2Ray / Xray 内核配置片段，用来说明字段关系，不是完整的 v2rayN 导入配置。它没有入站监听、节点出站和完整路由规则。图形客户端通常会生成这些内容，修改生成文件也可能在下次保存时被覆盖。

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

dns.servers 中的 fakedns 表示使用虚拟 DNS 应答；顶层 fakedns 定义地址池与容量。本例中的 4096 是示例容量，不是所有内核的默认值，也不是性能指标。还需要把实际 DNS 查询送入这个 DNS 模块，仅添加字段不会自动接管系统查询。

对于接收虚拟 IP 连接的入站，还需要启用对应的恢复机制。下面的 sniffing 对象应合并到相关入站对象内，不是另一个顶层配置。实际字段支持情况应以所用内核为准。

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

• enabled 开启该入站的嗅探处理；destOverride 中的 fakedns 指定按虚拟地址映射恢复目标。
• 本示例使用 routeOnly: false，让恢复结果可以用于目标替换，而不只用于路由匹配。不要在未理解出站行为时改成仅路由模式。
• 若选择代理出站，应确认恢复后的域名被交给代理链路；若选择直连，应提供能得到真实地址的解析路径，避免再次返回虚拟地址形成循环。
• geosite: 规则匹配域名分类，geoip: 规则匹配地址分类。虚拟 IP 不代表目标服务器的地理位置，不能依靠它进行真实目标的 IP 归属分流。

什么时候开启：按连接方式做选择

如果应用本来就通过 HTTP 代理或携带域名的 SOCKS 请求连接，代理已经可能拿到域名，FakeDNS 的额外收益通常有限。它更适合透明接管后只能看到目标 IP、又需要稳定使用域名规则的情况。

198.18.0.0/15 属于用于网络基准测试的特殊用途地址段，不是网站公网地址，也不等同于常见私有网段。如果本地实验网络或企业环境已经使用它，应先排查路由冲突。使用其他地址池同样需要确认内核支持与路由规划，不能随意选一个公网地址段替代。

如何验证：不要只看 DNS 查询结果

验证需要覆盖完整链路。仅看到 198.18 或 198.19 开头的地址，只能说明某次查询得到了虚拟应答，不能证明后续连接已经恢复域名或正确分流。反过来，某个工具返回真实地址，也可能是它绕过了预期 DNS 入口。

1. 记录基线。保存原配置，选择一个原本可访问的域名，同时记录当前节点和分流模式；不要一边测试一边更换协议。
2. 触发新查询。启用配置后重新启动测试应用。Windows 可执行 ipconfig /flushdns 清除系统 DNS 缓存，但浏览器自己的 DNS 与连接缓存仍可能需要另行清理。
3. 观察 DNS 入口。可用 nslookup example.com 辅助检查系统解析路径，但该工具不一定复现浏览器的加密 DNS 行为，不能单独作为验收依据。
4. 观察连接日志。检查虚拟目标是否被还原为原始域名，以及最终命中的出站。临时增加日志详细程度后，应在测试结束时恢复，避免长期记录访问域名。
5. 交叉测试。分别验证代理站点、直连站点、内网域名和 IPv6 场景。只测试一个网页，容易遗漏直连解析循环或 AAAA 查询绕行。

常见问题与回退步骤

回退时按“恢复 DNS 设置、恢复原路由、重启接管服务、清理应用缓存”的顺序操作。保留一份可正常使用的基线配置，比同时调整 FakeDNS、IPv6、嗅探和路由策略更容易定位问题。重新启用时每次只改变一个环节，才能分清故障来自查询绕行、映射失效还是出站规则。