2026-09-09 · 进阶原理 · 约 12 分钟

FakeDNS 工作原理详解：虚拟 IP 分配、适用场景与副作用

从 DNS 查询被拦截、返回虚拟 IP 讲起，说明 FakeDNS 如何配合域名分流与 TUN 模式工作，以及哪些场景不适合开启。

本文速览

FakeDNS 用本地分配的虚拟地址保留域名线索，不是公共 DNS，也不是新的代理协议。本文适合已经能正常连接、准备调整 TUN 与域名分流的用户：先看查询与连接如何闭环，再核对配置边界，最后按缓存、DNS 接管和局域网访问逐项排查。没有明确需求时，保留当前可用的真实地址解析方案即可。

FakeDNS 原理：虚拟地址是映射索引

普通 DNS 查询把域名解析成目标服务的真实地址。FakeDNS 则从本地地址池中选取一个地址，记录“域名与虚拟 IP”的映射，再把虚拟地址返回给应用。例如，应用查询 example.org 的 A 记录，可能获得 198.18.0.1。这个地址只是演示值，实际分配顺序由实现与运行状态决定。

域名查询 虚拟地址分配 连接接管 域名还原 规则出站

应用随后向这个虚拟 IP 建立连接。接管流量的组件读取目标地址，查回域名，将域名交给路由与出站处理。因此，FakeDNS 的关键不是“回答一个特殊 IP”，而是查询和后续连接必须经过能够共享或使用这份映射的处理链。

198.18.0.0/15 是用于基准测试的保留地址范围，覆盖 198.18.0.0 至 198.19.255.255；它不是普通公网服务地址。FakeDNS 常借用此范围，但不同实现可以使用不同地址池。如果虚拟地址绕过接管直接发给物理网络，通常无法到达原本的网站。

TUN 与域名分流：接管、还原、匹配缺一不可

TUN 在网络层接收 IP 数据包，刚接管一个连接时，常见信息只有目标 IP、端口与传输协议。如果应用已经完成域名解析，域名可能不再直接出现在数据包里。FakeDNS 把“这个地址原来对应哪个域名”提前保存在映射中，为域名规则提供线索。

  1. 接管 DNS：应用的查询需要进入预期的 DNS 处理链。传统 DNS 常使用 UDP 53，也可能使用 TCP 53；只处理其中一种不能代表所有查询都已接管。
  2. 接管连接：发往虚拟地址池的 TCP 或 UDP 流量必须进入相应的 TUN、路由与内核处理链，不能被排除规则提前放行。
  3. 恢复域名：接收连接的组件必须能使用映射。Xray 的相关配置涉及 FakeDNS 与入站嗅探；仅在 DNS 列表中加入一个名称并不足以完成闭环。
  4. 执行规则：还原域名后再按域名规则、IP 规则和兜底规则决定出站。VMess、VLESS 等协议负责后续代理传输，不负责生成这份映射。

浏览器通过系统 HTTP 代理访问 HTTPS 网站时，可以在 CONNECT 请求中携带目标主机名；SOCKS5 也能使用域名地址类型。这类链路可能已经把域名交给代理，不一定需要再引入 FakeDNS。相反，应用若先在本地解析并只提交 IP，就需要另行判断域名信息如何获取。

判断：先确认域名是否已经到达路由层

如果当前系统代理链路已经能按域名命中规则，先保留现状。只有 TUN 接管后域名信息不足、并且 DNS 与连接都能进入同一套处理链时，再评估 FakeDNS。

配置核对：地址池与还原入口必须配套

v2rayN 是桌面客户端，v2rayNG 使用 Xray 内核，v2flyNG 使用 V2Fly 内核。客户端界面、所选内核和 TUN 接入组件是不同层级，不能仅凭客户端名称判断配置字段是否可用。下列键值用于解释 Xray 的配置关系，不代表三款客户端都提供同名开关，也不能直接作为完整配置导入。

虚拟地址分配端

配置对象
fakedns
地址池示例
198.18.0.0/15
容量示例
poolSize: 65535
DNS 服务项
fakedns

容量是示例参数，不是节点数或并发承诺；定义地址池还需要让相应查询实际使用它。

连接还原端

入站配置
sniffing
启用字段
enabled: true
还原类型
destOverride: ["fakedns"]
接管范围
应用到虚拟地址池的连接

应核对实际承接流量的入站，而不是给一个没有流量经过的入站添加字段。

下面是 Xray 原生 JSON 的分配端片段，只展示地址池和内置 DNS 的关联。它缺少入站、出站、路由和接管配置，不能替换客户端生成的完整文件。客户端若用另一组件处理 TUN 与 DNS，应以该组件的配置结构为准，不要混用字段。

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

适用场景与副作用：不是所有应用都适合虚拟 IP

FakeDNS 可以减少部分连接在本地获取真实地址的需求，并帮助域名规则识别已经变成 IP 连接的请求。但它不会自动缩短远端解析时间，也不会修复节点不可用、TLS 参数错误或路由规则顺序错误。是否有收益，应看域名识别和应用兼容性，而不是只看 DNS 回答是否变快。

场景主要影响处理建议
TUN 下按域名分流映射可为 IP 连接补回域名验证 DNS、虚拟网段与还原入口的完整链路
局域网服务与内部域名名称发现、内网解析可能被错误接管为内部域名和网段保留真实解析及直连路径
企业网络使用相同网段虚拟池可能与现有路由冲突检查路由表，按实现能力更换池或关闭该功能
应用检查解析结果程序可能拒绝保留地址或缓存虚拟地址对该应用采用真实地址解析，重新测试登录与连接
应用使用加密 DNS查询可能绕过常规 53 端口接管检查应用 DNS 设置，不把加密连接误当普通 DNS 强行重定向

直接连接 IP 字面量的程序没有先查询域名，FakeDNS 无法凭空补出域名。局域网的组播名称发现也不等于普通单播 DNS；只调整 53 端口规则，不一定能解决打印、文件共享或内部服务发现问题。

取舍：内部服务优先保持真实解析

如果工作网络依赖内部 DNS，先把内部域名、DNS 服务器和相关网段的解析及连接路径核对清楚。出现登录或服务发现异常时，先回退 FakeDNS，不要用扩大代理范围来掩盖问题。

验证流程：分开检查 DNS、映射和出站

验证时使用同一个测试域名，固定节点与路由规则，一次只改变一个开关。看到虚拟地址只能证明某次查询获得了虚拟回答；看到网站打开也不能证明所有应用都经过相同链路。应把解析结果、接管日志和规则命中一起检查。

  1. 建立基线：关闭 FakeDNS，记录测试域名能否访问、当前 DNS 结果和出站规则。保留可恢复的设置，不修改订阅中的服务器地址。
  2. 验证查询：启用后查询同一域名，核对 A 记录是否位于实际配置的虚拟地址池。若仍为真实 IP，先查缓存、应用自带 DNS 和 DNS 路由，不急着修改地址池。
  3. 验证还原：发起新连接，检查日志是否能关联到原域名及预期出站。若只看到虚拟 IP 被直接连接，应优先检查还原入口与网段路由。
  4. 验证兼容性：分别测试网页、内部服务和一个非浏览器应用。对 UDP 应用也要单独测试，网页的 TCP 连接成功不能替代 UDP 验证。

Windows 可先查看系统当前使用的解析结果，切换方案后再清理系统 DNS 缓存。下面两条命令分别用于查询和清理；它们不是性能测试，也不提供固定的预期地址。

nslookup example.org
ipconfig /flushdns

系统缓存清理不等于清除了浏览器或应用内部缓存。关闭 FakeDNS 或重启映射组件后，应用可能仍持有旧虚拟地址；若映射已经消失，这些旧连接会失败。回退时应停止相关应用、清理系统缓存，再重开应用验证。

常见问题：开启后异常从哪里查

解析到 198.18 开头，是否说明 DNS 出错了？

先看实际地址池。启用 FakeDNS 且配置使用 198.18.0.0/15 时，这可能是正常回答。继续发起连接并查看域名还原和出站日志；如果功能已关闭却仍返回这类地址，清理系统与应用缓存，并检查是否还有其他 DNS 接管组件运行。

为什么开启后浏览器能用，其他应用却断网？

分别检查应用是否使用独立 DNS、是否被排除在 TUN 之外，以及是否拒绝保留地址。先让异常应用回到真实地址解析方案，重启应用复测。不要只凭浏览器成功就扩大所有应用的接管范围。

开启 FakeDNS 就不用配置远端 DNS 了吗？

不是。虚拟分配端只解决本地映射；直连出站或远端代理建立实际连接时，仍可能需要解析域名。检查负责最终解析的组件与 DNS 出站，避免代理服务器域名的解析依赖尚未建立的代理连接。

关掉后还是打不开网页，应该重装客户端吗？

先恢复原 DNS 与接管设置，执行 ipconfig /flushdns，再退出并重开浏览器。随后核对系统代理是否仍指向已停止的本地服务。Android 端先停止并重启客户端 VPN 连接及相关应用，再复测；通常应先排除旧缓存和残留接管状态。

最终判断标准是连接链路可解释、域名规则能命中、日常应用能稳定使用。FakeDNS 只是 DNS 与流量接管之间的一种配合方式；订阅导入、节点选择、系统代理和 TUN 仍然需要分别核对。

v2rayN下载