FakeDNS 是什么:虚假 IP 映射原理、适用场景与 v2rayN 开启时机

FakeDNS 原理：先保留域名，再决定连接出口

虚假 IP 映射：普通 DNS 通常为域名返回可连接的真实地址；FakeDNS 则从指定地址池中分配一个地址，并在本地记录“域名与虚假 IP”的对应关系。这个地址不是目标网站的公网入口，而是供后续连接识别域名的索引。应用收到结果后仍照常连接，代理处理链再通过映射找到原始域名。

连接闭环：只有 DNS 请求和后续连接经过相互配套的处理链，虚假地址才有意义。如果 DNS 已返回假 IP，但 TUN 没有接管该地址池，应用就可能把连接交给普通网络，最终超时。反过来，若应用通过独立的加密 DNS 得到真实 IP，FakeDNS 中也不会凭空出现这次查询的域名映射。

出口解析：恢复域名并不代表整个连接不再需要真实 DNS。后续是否解析、在哪里解析，取决于出站类型、域名处理策略和服务端行为。直连通常仍需获得可连接地址；支持传递域名的代理出站可以把域名交给远端处理。FakeDNS 解决的是本地识别与分流，不是替代整个互联网的名称解析。

地址池与端口：看到假 IP 不等于 DNS 出错

数值识别：Xray 的 FakeDNS 常见配置使用 198.18.0.0/15 地址池，该范围原本保留用于网络基准测试，不是普通公网网站地址。下面列出的是地址和协议事实，不是速度测试结果，也不是要求所有环境照搬的默认设置。

地址范围：198.18.0.0/15 覆盖 198.18.0.0 至 198.19.255.255。地址块总量不等于内核一定会保存同样数量的映射，实际容量还受池配置与实现限制。企业实验网络如果已经使用这个范围，需要先处理路由冲突，不能把“保留地址”理解为“本机一定没有使用”。

• 正常表现：域名查询返回池内地址，应用可访问，连接日志能关联域名与预期出站。
• 异常表现：查询返回池内地址，但连接没有进入接管链，或日志只剩假 IP 且持续超时。
• 检查边界：仅监听或转发 UDP 53 不代表覆盖所有查询；传统 DNS 还可能使用 TCP，应用也可能使用加密 DNS。

v2rayN 开启时机：先区分系统代理与 TUN

系统代理场景：遵循系统代理设置的应用，通常会把目标域名交给本地 HTTP 或 SOCKS 代理，不过是否本地解析仍取决于应用和协议用法。如果日志已经能看到域名、路由也符合预期，启用 FakeDNS 往往没有必要。FakeDNS 不是 VMess、VLESS 节点能否连接的前置条件，也不能修复订阅失效或 TLS 参数错误。

内核边界：v2rayN 是桌面客户端，界面选中的节点内核与 TUN 实际使用的处理组件不一定相同。不能因为节点由 Xray 连接，就把 Xray 的 FakeDNS 字段直接粘进所有 TUN 配置。先查看当前配置和启动日志，确认 DNS、TUN 与路由分别由谁处理，再使用对应内核支持的设置。

安卓边界：v2rayNG 使用 Xray 内核，v2flyNG 使用 v2fly 内核；两者的界面选项、配置生成方式和字段支持不能按桌面截图推定。即使名称相近，也应分别检查当前版本提供的 DNS 与流量接管选项。跨平台迁移时保留分流目标，不直接复制未经核对的底层配置。

配置顺序：地址池、DNS 应答与域名恢复缺一不可

最小片段：下面仅展示 Xray 顶层 fakedns 地址池配置，便于理解字段，不是可以独立运行的完整配置。poolSize 的 65535 是此示例选择的映射容量，不代表地址块总数，也不是所有机器的推荐值。由 v2rayN 自动生成的文件可能在重启后重写，修改前应确认自定义配置的入口和保存方式。

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

1. 记录基线：保存当前 DNS、路由和 TUN 设置，选定一个常用网站与一个局域网服务作为前后对照对象。
2. 确认 DNS 入口：检查系统与应用的查询是否进入预期处理链。仅在配置里定义地址池，不会自动让所有系统查询使用 FakeDNS。
3. 连接 FakeDNS 应答：在适用的 Xray 配置中，还需要让相应 DNS 查询使用内置的 fakedns 服务；具体查询规则应与直连、代理需求对应。
4. 确认域名恢复：使用 Xray 对应入站时，核对嗅探设置里的 enabled 与 destOverride，其中 fakedns 项用于从映射恢复域名。其他接管组件应使用自身的等效机制。
5. 逐项验证：检查普通浏览、局域网访问与目标应用。先确认恢复后的域名与出站，再决定是否扩大到日常使用。

IPv6 配套：只有 IPv4 池不代表 IPv6 已得到相同处理。应用可能优先查询 AAAA 记录，再使用 IPv6 连接；若这条路径没有对应路由与 DNS 策略，就可能表现为不同应用行为不一致。应分别验证 A、AAAA 查询及其连接路径，而不是把一次 IPv4 成功当作全部通过。

适用场景与兼容取舍：域名规则优先，真实 IP 需求单独处理

规则收益：TUN 接收到的通常是目标 IP，单靠 IP 很难稳定表达一个网站的业务归属。一个域名可能对应多个地址，一个地址也可能承载多个域名。FakeDNS 通过保留查询时的名称，让域名规则更容易获得匹配依据；但其覆盖范围受实际 DNS 查询路径限制，不是对所有连接都能恢复域名。

兼容原因：部分应用会检查解析地址是否属于预期网段，或把 DNS 结果交给另一个进程、设备使用。假地址离开原来的映射环境后通常没有可用意义。因此，不应把 FakeDNS 应答共享给没有配套接管能力的其他设备，也不应把它返回的地址当成服务器真实 IP 写进长期配置。

故障定位与回退：按查询、映射、连接顺序排查

排查入口：开启后出现“网页能开、某个应用不能用”，先保留出错时段的本地日志，观察异常应用是否使用独立 DNS、固定 IP 或不同的网络路径。不要同时更换节点、路由规则与 DNS，否则即使恢复也难以判断是哪一项起作用。

1. 查询不到假地址：确认测试域名确实命中 FakeDNS 查询规则；真实地址可能是排除策略的预期结果，也可能来自应用自带 DNS 或旧缓存。
2. 拿到假地址却超时：检查 TUN 是否运行、地址池路由是否进入正确接口，以及是否存在其他虚拟网卡或企业路由冲突。
3. 日志只显示假地址：检查对应入站的域名恢复配置，并排除重启后映射已丢失、应用却仍保留旧 DNS 缓存的情况。
4. 域名正确但走错出口：检查规则从前到后的匹配顺序，以及进程、端口、IP 规则是否抢先命中；这时问题已不只是 DNS。
5. 浏览器与应用表现不同：分别检查加密 DNS、应用代理设置和缓存，不用浏览器的一次成功代表其他进程。

Windows 缓存：回退到真实 DNS 前，先恢复 DNS 应答与接管设置，再清理系统缓存并重启目标应用。下面命令只清理 Windows DNS 客户端缓存，不会清空浏览器内置缓存，也不会修改节点。长时间运行的应用可能保留自己的连接池，需要完全退出后重新打开。

ipconfig /flushdns

回退验证：确认新查询不再返回原来的假地址、局域网服务可访问、系统代理或 TUN 处于计划状态。若关闭接管后仍有应用尝试连接旧假 IP，应继续清理应用缓存，而不是把该地址加入直连规则；直连无法把虚假索引变成真实服务器。

常见问题：FakeDNS、嗅探与隐私的边界

最终判断：系统代理下域名分流已正常时，FakeDNS 不必作为例行开关；TUN 下确有域名信息缺口，且能够同时控制 DNS 与连接路径时，才值得启用。配置完成后，以域名恢复、路由命中和应用兼容三个结果共同验收。