V2Ray FakeDNS 原理详解:虚拟 IP 映射机制与适用场景

FakeDNS 与真实 DNS 解析的区别

普通 DNS 的 A、AAAA 查询分别用于获取 IPv4、IPv6 地址。应用拿到结果后，通常直接向这个地址建立连接。到了透明代理入口，原始连接可能只剩“目标 IP + 目标端口”，而域名规则需要的却是应用最初查询的名称。FakeDNS 改变了前半段：不急着返回真实服务器地址，而是分配一个仅在受控链路内有意义的虚拟 IP。

例如，应用查询 www.example.com，FakeDNS 分配 198.18.0.2 并保存两者的对应关系。应用随后连接 198.18.0.2:443，接管连接的内核查到映射，便可以把目标恢复为 www.example.com:443。这里的地址是机制示例，不是可直接访问的测试节点，也不是任何客户端固定分配的首个地址。

虚拟 IP 映射的完整链路

这条链路的关键不是“DNS 返回了什么”，而是返回结果和后续连接能否重新汇合。回答 DNS 的映射表，与处理目标连接的内核，必须共享对应状态，或由支持此机制的集成组件衔接。若由一个实例生成虚拟地址，却把连接交给另一个没有映射的实例，后者看到的只是无法直接访问的特殊用途地址。

1. 查询进入受控 DNS：应用的 A 或 AAAA 请求需要进入配置好的解析路径。仅接管传统 DNS 的 UDP 53 端口，并不等于覆盖应用自带的加密 DNS。
2. 写入映射表：FakeDNS 为域名分配虚拟地址。地址池容量有限，实现可能在容量压力下回收旧映射；地址分配次序不应被当作稳定接口。
3. 接管虚拟地址连接：TUN 或透明代理规则将连接送入支持还原的入口。FakeDNS 本身既不创建 TUN 网卡，也不自动安装完整的系统路由。
4. 查表并恢复目标：内核从虚拟 IP 找回域名，供域名规则与后续出站使用。具体是否改写连接目标，还受入口嗅探等设置影响。
5. 完成实际访问：选择代理出站时，支持域名目标的协议可将域名交给远端处理；选择直连时，通常仍要通过真实 DNS 获得可连接的地址。

因此，FakeDNS 不是“不再需要 DNS”，而是推迟真实解析，并保留域名关联。它也不代替 VMess、VLESS 等代理协议，不修改节点认证资料，更不能修复服务端不可达、传输路径错误或 TLS 配置不匹配。

配置字段：地址池、DNS 与入口还原

“V2Ray FakeDNS”常被用来统称这类机制，但 V2Ray 与 Xray 的具体配置能力、字段和客户端接入方式需要分别核对。下面按支持这些字段的 Xray-core JSON 配置说明，展示显式填写的示例值，不宣称它们是所有版本的默认值。v2rayN、v2rayNG 与 v2flyNG 的界面和生成配置方式不同，不能跨内核照抄。

以下是根对象中的 DNS 与地址池片段，不是可独立运行的完整配置。它没有定义监听入口、出站与系统路由，而且只展示 IPv4 池；不能据此认定 AAAA 查询也会按相同方式处理。实际部署需要结合当前内核文档配置 IPv6 行为和真实 DNS 回退路径。

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

接收虚拟地址连接的对应入站，还需要配置还原机制。下面仅展示该入站内部的 sniffing 字段；它不会自动补齐其他入站参数。routeOnly 的通常含义是将嗅探结果只用于路由而不改写目标，本例显式设为 false，避免把尚未恢复的虚拟目标继续交给出站。

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

适用场景与不适用场景

FakeDNS 最有价值的场景，是已经采用 TUN 或透明代理、又需要按域名分流的环境。透明入口从网络层接收连接，不一定能从连接本身得到域名；映射表让域名规则不必完全依赖 HTTP Host 或 TLS 握手信息。它也适用于希望把真实解析留到代理出口侧处理的配置，但是否实现这一目标仍取决于出站、路由与真实 DNS 的组合。

显式代理和透明代理要分开判断：支持域名目标的 SOCKS 请求或 HTTP CONNECT 请求，可以直接携带域名，不一定需要 FakeDNS；而应用先在本地解析、再向代理提交 IP 时，域名仍可能丢失。是否需要启用，应以实际请求形式为准，而不是看到“系统代理”四个字就作判断。

常见副作用：缓存、内网与解析旁路

FakeDNS 引入了一张有生命周期的本地映射表，应用和系统却可能继续缓存旧的 DNS 答案。内核重启后，如果原映射已经消失，应用仍拿旧虚拟 IP 发起连接，就会出现“刚打开能用，切换模式后打不开”的现象。此时不停更换节点通常无效，因为故障发生在出站选择之前。

• 模式切换后失联：关闭 FakeDNS 或退出 TUN 后，缓存中的虚拟地址仍可能被使用。应先恢复一致的接管模式，再清理缓存并重启相关应用。
• 局域网服务异常：内部域名可能需要由办公 DNS 返回内部地址。应让这些域名进入明确的真实解析与直连路径，而不是把所有查询无差别送入虚拟池。
• 应用自行解析：应用内置 DoH、DoT 或自带解析结果时，传统 DNS 接管可能根本看不到查询。此时没有虚拟映射属于预期现象，不代表地址池失效。
• IPv4 与 IPv6 不一致：A 查询走虚拟池、AAAA 查询走另一条路径时，同一应用可能表现不稳定。应分别检查两类记录、IPv6 路由与相应池配置。
• 诊断工具结果变化：解析工具显示 198.18 网段不等于域名真实指向那里。对虚拟 IP 做连通性测试，也不能直接反映远端网站的存活状态。

FakeDNS 也不天然等于“没有 DNS 泄漏”。本地直连出站仍可能触发真实解析，应用也可能绕开受控 DNS。若要检查解析路径，应分别观察查询去了哪里、连接从哪个出站发出，而不是仅凭一次解析返回了虚拟地址就下结论。

按顺序排查虚拟 IP 连接失败

建议先固定一个域名、一个应用和一个节点，记录切换前后的现象。下面以 www.example.com 为查询示例；命令用于观察本机当前解析路径，不保证查询一定进入 FakeDNS。Windows、macOS 与 Linux 的解析工具也可能和浏览器采用不同的解析路径。

nslookup -type=A www.example.com
nslookup -type=AAAA www.example.com

1. 先看解析是否进入虚拟池：若 A 结果是配置池内的地址，说明该次查询拿到了虚拟结果；若仍是真实 IP，检查查询是否绕过受控 DNS，以及目标域名是否命中了真实解析例外。
2. 再看连接是否进入内核：应用建立连接时查看访问日志。如果解析返回虚拟地址，但内核没有对应连接记录，优先检查 TUN 路由与入口接管，不要先改节点的 VMess 或 VLESS 参数。
3. 检查映射能否还原：日志里若始终只有虚拟 IP，核对接收连接的入站是否启用了匹配的还原设置，以及是否发生过内核重启、地址池更换或多实例切换。日志展示格式随版本而异，不能只凭单行内容断言失败。
4. 最后检查路由与出站：能够还原域名但仍失败时，再确认域名规则命中的出站。直连需要可用的真实解析路径；代理出站则继续检查节点连通、服务端解析与传输配置。

Windows 可用下面的命令清理系统 DNS 缓存，但它不会清理所有应用内缓存。清理前应先确认当前接管模式正确，否则应用只会再次拿到无法使用的结果。浏览器或长驻后台程序仍有异常时，需要关闭相关进程后再试。

ipconfig /flushdns