V2Ray FakeDNS 工作原理:虚拟 IP 分配、流量嗅探配合与适用场景

FakeDNS 原理：用虚拟地址保留域名线索

普通 DNS 把域名解析成可连接的实际地址。FakeDNS 则为受处理的 A 或 AAAA 查询分配虚拟地址，并在本地保存“域名与虚拟地址”的对应关系。应用以为拿到了正常解析结果，随后向该地址建立连接；代理内核接住连接后查映射表，把目标恢复为原来的域名，再交给路由与出站处理。

这里的“恢复”是本地映射查找，不是向公共 DNS 发起 PTR 反向查询。比如应用查询 example.com，得到池内某个地址；内核看到应用连向这个地址，就能根据同一份映射表找回 example.com。具体分配到哪个地址由运行状态决定，不应把某个虚拟地址永久写进规则。

虚拟 IP 只是本机接管链路里的标记，不是网站服务器的实际地址。它不能拿到另一台设备上直接访问，也不能通过普通网关发送到公网后期待目标响应。即便最后选择直连出站，也要先正确恢复域名，再由相应解析与连接逻辑处理实际目标。

地址池与端口：先分清三个数字

198.18.0.0/15 覆盖 198.18.0.0 到 198.19.255.255，是为基准测试保留的地址段，不是普通私有局域网地址段。把它用作虚拟地址池，是借其不应作为正常公网目标的特点；但企业网络、实验环境或其他隧道也可能使用它，启用前仍要排查路由冲突。

poolSize 表示映射池容量，不是 DNS 缓存时间，也不是并发连接上限。本文的 4096 只是配置示例，不是所有设备都应采用的最佳值。容量不足、映射被淘汰而应用仍保留旧地址时，可能出现恢复失败；不能只清浏览器缓存而忽略内核映射与系统 DNS 缓存的生命周期。

• 地址池：决定哪些目的地址需要被识别为虚拟目标，不能与现有业务地址重叠。
• 映射容量：决定能保留多少映射条目；排查时观察实际行为，不凭数字判断速度。
• DNS 入口：传统 DNS 常用 UDP/TCP 53，但内核的内置 DNS 模块不等于自动在本机 53 端口监听。

FakeDNS、sniffing 与 TUN：三个环节各管一件事

TUN 负责接收被路由进虚拟网卡的 IP 流量，本身不保证所有连接都有域名。普通 sniffing 尝试从 HTTP Host、TLS 握手等受支持的协议信息中识别域名；FakeDNS 则依靠此前生成的映射恢复域名。二者都能补充域名信息，但信息来源不同，不能互相等同。

如果应用直接使用 IP、使用未被接管的加密 DNS，或复用了启用前的真实地址缓存，FakeDNS 就没有机会创建相应映射。此时看到连接仍按 IP 规则处理，并不能直接说明功能失效。反过来，只有 DNS 查询进了 FakeDNS，而目标连接绕过 TUN 或透明入站，也会导致应用拿着虚拟地址连接失败。

Xray 配置示例：分配地址与入站恢复要同时存在

下面展示 Xray 风格的字段关系，不是完整运行配置。V2Ray 是常用称呼，具体字段和行为仍以实际运行的内核为准。v2rayN 是客户端，v2rayNG 使用 Xray 内核，v2flyNG 使用 V2Fly 内核；不要仅因为界面名称相近，就跨内核复制同一份 JSON。

第一段是顶层配置片段：声明 IPv4 池，并让内置 DNS 使用 FakeDNS。它只展示最小关系，没有包含节点服务器域名解析、局域网域名例外、IPv6 与 DNS 流量入口，不应直接覆盖客户端生成的完整配置。

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

第二段属于接收虚拟目标连接的那个入站对象，用于查表恢复域名。这里仅保留 fakedns，方便看清必要关系；若要增加 HTTP、TLS 等嗅探类型，应先核对所用内核的支持情况。不要把这个对象作为顶层独立配置，也不要误加到一个完全接不到目标连接的入站上。

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

• 节点服务器如果使用域名，必须有能取得实际地址的解析路径，不能把虚拟地址当成连接节点的最终地址。
• 路由恢复域名后，geosite: 规则才有相应匹配依据；geoip: 面向 IP，不能拿虚拟地址当目标网站归属地。
• 只配 IPv4 池不代表已经覆盖 AAAA 查询与 IPv6 连接；双栈网络需要单独验证。

适用场景：透明接管有收益，普通系统代理先保持简单

HTTP 代理和支持远端解析的 SOCKS 请求可以直接把域名交给代理，此时再引入 FakeDNS，未必能解决新的问题。透明接管只收到 IP 包，更容易丢失域名上下文，才是它常见的使用位置。选择开关前，先判断流量缺的到底是域名信息，还是节点连接、出站解析或路由顺序。

FakeDNS 不等于 DNS 加密，也不保证所有 DNS 都经过代理。它只是改变了应用侧收到的解析结果；后续真实解析在哪一端进行、使用什么传输方式，仍由出站与 DNS 策略决定。VMess 或 VLESS 等节点协议不会单独决定 FakeDNS 能否工作，也不需要为此重新导入一份订阅。

验证步骤：从解析结果追到最终出站

1. 保留基线。先在普通代理模式下确认同一节点可以访问目标，备份当前配置。暂时不要同时调整订阅、路由规则库和 DNS。
2. 检查接管入口。启用选定的 TUN 或透明接管方案，确认应用的 DNS 查询与后续连接都进入预期链路。Windows 可在「设置」→「网络和 Internet」中核对当前网络接口，但不要把物理网卡 DNS 的显示值当作接管成功的充分证据。
3. 清除旧缓存。关闭测试应用；Windows 可在命令提示符运行 ipconfig /flushdns 清理系统缓存，再重新打开应用。浏览器自己的缓存和加密 DNS 设置仍需单独检查。
4. 观察实际查询。通过应用请求触发解析，配合 DNS 日志确认返回地址是否属于配置池。nslookup example.com 可作辅助，但它的查询路径可能与浏览器不同，不能凭一次结果判断所有应用。
5. 核对恢复与分流。在可用日志中寻找原始虚拟目标、恢复后的域名、命中的规则及出站标签。日志详细程度因内核和客户端而异，必要时临时提高级别，测试结束后恢复。
6. 验证例外。分别测试内网站点、IPv6 目标和直连规则。只验证一个代理网站能打开，不足以证明整套 DNS 策略正确。

测试数据要能回答一个具体问题：DNS 返回了什么、连接去了哪里、哪条规则命中。单独运行 ping 不适合判断网页代理是否可用，因为虚拟地址不必响应 ICMP，而网页使用的是另一条连接路径。也不要把获得虚拟地址的速度写成网站访问延迟，两者不是同一个指标。

常见故障：虚拟地址残留、内网异常与分流失效

如果问题只在内核重启后出现，还要考虑映射状态与应用缓存不同步：应用保存了旧虚拟地址，新进程却没有相应条目。此时重启应用并重新解析，比反复切换节点更有针对性。若扩大池容量后仍反复发生，也要回头检查是否存在多个 DNS 处理组件，不能无限增加容量代替排障。

回退顺序：恢复 DNS，再清缓存和验证普通代理

判断功能不适合当前网络时，按原配置回退即可。关键是同时撤销虚拟地址分配与依赖它的接管关系，避免保留一半链路。客户端更新可能改变配置生成方式，回退应以此前保存的配置为依据，而不是猜测哪个开关曾经打开。

• 恢复原先的 DNS 服务器、域名例外和客户端接管设置。
• 确认物理网络接口与系统路由中没有遗留的虚拟池接管规则。
• 退出应用、清理 DNS 缓存，再按普通系统代理方式测试同一目标。
• 记录失败发生在查询、映射恢复还是出站连接阶段，下一次只调整对应环节。

记住这一条就够用：FakeDNS 的价值是给需要域名的分流链路补信息。已经能稳定传递域名的场景，不必为了多开一个选项增加复杂度；透明接管确实缺少域名时，再把地址池、查询入口、入站恢复和出站解析逐项接完整。更多字段关系可结合配置参考中的 DNS 设置检查，基础连接问题先看连接排查说明。