V2Ray FakeDNS 是什么:虚假 IP 映射原理与开启时机

FakeDNS 是什么：返回映射地址，而非网站真实 IP

普通 DNS 查询通常把域名换成服务器的真实地址；FakeDNS 则先分配一个仅供当前代理链路识别的地址。例如，应用查询 example.com，FakeDNS 可以返回池中的 198.18.0.1，同时在内存中记录这两者的对应关系。这个地址不是该网站的服务器，也不应该直接交给公网路由访问。

应用随后向合成地址建立连接。代理接收到连接后，从映射表找回原域名，再按域名规则决定直连还是代理。最终如何取得真实 IP，取决于出站类型与解析策略：可能由本地直连出站解析，也可能把域名交给远端代理处理。FakeDNS 本身并没有消除最终访问真实服务器的需求。

常见示例使用 198.18.0.0/15，即从 198.18.0.0 到 198.19.255.255 的特殊用途地址空间。它原本用于网络设备基准测试，不是可任意访问的公网网站地址，也不是日常局域网常用的私有地址段。把它用于合成地址池前，仍要确认企业网络或实验网络没有实际使用这一段。

FakeDNS、嗅探与 TUN：三个环节分别做什么

三者常在同一配置界面出现，但负责的任务不同。FakeDNS 管地址和域名的对应关系；TUN 通过虚拟网络接口把匹配的 IP 流量送入客户端；嗅探或入站目标恢复逻辑把连接中的信息转成可用于路由、出站的目标。只开启其中一个选项，不能保证整条链路成立。

HTTP Host、TLS SNI 嗅探与 FakeDNS 映射恢复也不能完全画等号。前两者尝试从协议数据中识别域名，受协议、加密方式和应用行为影响；FakeDNS 恢复主要依赖先前保存的映射。应用直接访问一个真实 IP、绕过客户端自行解析，或仍使用上次运行留下的合成 IP 时，都可能没有可用映射。

开启时机：域名规则有需求，再检查接管条件

适合考虑 FakeDNS 的情况，是透明代理收到的主要是 IP 连接，而路由规则又需要原始域名。它可以减少“先解析出真实 IP，再猜这个 IP 属于哪个域名”的不确定性，也能让部分请求不必等待本地取得真实解析结果就进入后续处理。但它不承诺下载更快，更不会改变节点带宽或线路拥塞。

• 可以尝试：已经稳定运行 TUN，希望按域名分流，并且客户端能同时处理 DNS 查询、合成地址路由和目标恢复。
• 通常不必增加：仅使用系统代理，应用已经通过 HTTP CONNECT 或支持域名目标的 SOCKS 请求把域名交给代理，现有规则也能正确匹配。
• 优先保持真实解析：企业内网、局域网设备发现、依赖真实 IP 做访问控制的软件，以及需要直接查看解析结果的网络诊断场景。
• 暂缓开启：设备同时运行另一套 VPN 或透明代理，尚未确认谁管理 DNS、默认路由以及合成地址段。

浏览器内置的安全 DNS、应用自带 DoH 等也需要纳入检查。传统 UDP 53 查询被接管，并不代表 HTTPS 内的 DNS 请求也会交给 FakeDNS。仅按端口封堵 443 会破坏普通网页访问，不能作为通用处理方法；应检查应用的 DNS 选项，明确由应用解析还是由客户端统一处理。

配置字段：地址池、DNS 与入站恢复必须配套

v2rayN 是桌面客户端；v2rayNG 是使用 Xray 内核的安卓客户端；v2flyNG 使用 v2fly 内核。界面负责生成或加载核心配置，但三款客户端的菜单、可用开关和生成结果并不相同。不要把某个客户端的界面截图当作所有版本的通用路径，应以当前实际运行内核接受的配置及日志为准。

下面是用于理解字段关系的 JSON 片段，展示常见 V2Ray 风格的 IPv4 FakeDNS 配置。它省略了入站、出站、路由和真实 DNS，不是可以直接覆盖客户端的完整配置。Xray 与 v2fly 的具体版本可能存在行为或字段差异，保存前应检查当前内核支持情况。

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

对于承担合成地址连接恢复的入站，常见的嗅探片段如下。这里的 fakedns 是目标恢复类型，不表示同时启用了所有 HTTP、TLS 嗅探功能。不要为追求“选项齐全”而把其他版本的类型名称一并复制进去。

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

开启后的验证：按 DNS、映射、路由三层检查

验证目标不是“开关显示已启用”，而是同一次访问从域名查询到最终出站都有合理结果。建议先记录当前代理模式、DNS 设置和内核类型，每次只改变一组设置。订阅中的服务器地址、端口与用户标识不属于 FakeDNS 的地址池参数，不需要为了测试而改动。

1. 建立基线。关闭 FakeDNS 时，确认同一网络下目标网站能够访问，记录使用的是系统代理还是 TUN，并保留一份原配置。
2. 确认查询路径。启用后，使用一个重新发起解析的域名访问，检查 DNS 日志是否进入预期处理流程；若配置要求该查询使用 FakeDNS，回答应落在配置的池内。
3. 确认连接回流。查看连接或核心日志，确认对合成地址的连接进入代理，并在可观察的日志阶段恢复出域名。不同日志级别展示的信息可能不同，不能只凭一行 IP 日志断定失败。
4. 确认分流结果。分别测试一个预期直连和一个预期代理的域名，核对实际出站。只测网页能否打开，无法证明规则命中正确。
5. 补测兼容性。检查局域网服务、应用内登录和后台联网；若启用了 IPv6，还要检查 AAAA 查询，避免只验证 A 记录就认为所有流量均已接管。

Windows 上可以用 ipconfig /flushdns 清理系统 DNS 缓存；浏览器或其他应用可能还保有自己的缓存及连接，需要退出后重新打开。安卓上可先停止客户端连接，再关闭并重开测试应用。不要为了获取新结果反复同时切换网络、节点、协议和 DNS，那会让对照失去意义。

常见问题：延迟、解析结果与重启后失效

关闭与恢复：同时撤销 DNS 分配和流量接管

关闭时要避免一种中间状态：DNS 仍向应用返回合成地址，但负责恢复的入站或 TUN 已停止工作。更稳妥的方式是暂停测试应用，恢复此前配套的 DNS 与代理设置，再重启连接并清理旧缓存。若客户端提供一体化的 FakeDNS 模式，优先通过同一入口回退，而不是只手动删除一行核心配置。

• 恢复 DNS：确认新查询返回预期真实解析结果，且系统没有残留不可达的本地 DNS 地址。
• 恢复路由：确认不再需要的合成地址池路由、虚拟接口和接管规则已由客户端正常撤销。
• 恢复应用：关闭旧连接、重新解析域名，再检查网页、内网服务与后台联网。
• 保留排查线索：记录异常出现在哪一步，以及是否只影响某个应用；分享日志前删去订阅地址、用户标识等敏感信息。

FakeDNS 的价值在于把域名信息带回透明代理的路由判断。对于已经稳定工作的系统代理，保持简单通常更容易维护；对于确实需要域名分流的 TUN 场景，重点则是确认查询、映射、入站和出站彼此配套。更多基础设置可参照完整手册中的 DNS 设置，先把普通解析路径确认清楚，再增加合成地址这一层。