FakeDNS 是什么:工作原理、开启方式与适用场景

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

普通 DNS 查询会把域名转换成真实服务器地址。FakeDNS 则为查询的域名分配一个虚拟 IP，并在本地维护“域名—虚拟 IP”的映射。例如，应用查询 example.com 后可能获得地址池中的一个地址；应用随后连接这个地址，代理内核再依据映射找回原始域名。这个地址不是网站的真实服务器，不能直接交给公网连接。

这条流程有两个必要前提：DNS 查询确实由维护映射的组件处理，后续连接也能回到识别该映射的处理链。只满足前者，应用拿到了虚拟地址却无法连接；只满足后者，查询返回的是真实 IP，FakeDNS 就没有对应的映射可用。

域名恢复后，代理可以依据域名规则选择直连或代理。直连通常仍需获得可连接的真实地址；代理出站能否把域名交给远端解析，则取决于出站协议与配置。FakeDNS 改变的是本地解析与识别过程，不替代最终连接目标的解析，也不改变 VMess、VLESS 的协议参数。

FakeDNS、TUN 与流量嗅探分别负责什么

TUN 是流量入口，FakeDNS 是地址映射机制，嗅探是目标识别机制，三者不是同一个开关。TUN 接收到的通常是 IP 数据包；如果应用已在其他地方完成解析，包里未必保留域名，因此需要额外的域名识别路径。

FakeDNS 恢复域名主要依赖自己的映射，不要求应用一定发送可读的 HTTP 主机头或 TLS 主机名。但应用自带加密 DNS、固定 IP 连接或独立解析缓存，仍可能绕过这条映射路径。不能把“已启用嗅探”理解成所有连接都会命中域名规则。

开启之前：核对内核与 DNS 接管边界

v2rayN 是桌面客户端，具体配置能力取决于当前内核与运行模式；v2rayNG 面向 Android，使用 Xray 内核；v2flyNG 面向 Android，使用 V2Fly 内核。不能仅凭客户端名称认定配置字段相同。尤其是 TUN 流量入口与节点代理内核可能由不同组件承担，Xray 的 FakeDNS 字段不能直接套用到另一组件的配置中。

IPv4 与 IPv6 要分别核对。只配置 IPv4 虚拟池，而应用仍能取得真实 IPv6 地址时，连接可能沿另一条路径发起；这不一定是故障，却会使分流行为与预期不同。不要为了让测试结果整齐就盲目关闭系统 IPv6，应先确认客户端是否支持配套的 IPv6 接管。

Xray 配置示例：地址池、DNS 与入口恢复

下面是用于说明字段关系的 Xray JSON 片段，不是完整的 TUN 配置。它展示顶层 fakedns 地址池、DNS 的 fakedns 服务器，以及 SOCKS 入口的域名恢复设置。合并前需要确认当前 Xray 版本支持这些字段，并与现有 dns、inbounds 配置逐项合并，不能覆盖原有入口与出站。

{
  "fakedns": [
    {
      "ipPool": "198.18.0.0/15",
      "poolSize": 65535
    }
  ],
  "dns": {
    "servers": [
      "fakedns"
    ]
  },
  "inbounds": [
    {
      "tag": "local-socks",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "udp": true
      },
      "sniffing": {
        "enabled": true,
        "destOverride": [
          "fakedns"
        ]
      }
    }
  ]
}

• poolSize: 65535 是映射池容量设置，不是节点数量，也不代表速度。长时间运行时，映射生命周期与应用缓存是否协调更重要。
• 127.0.0.1:10808 是本例的 SOCKS 入口，不是 DNS 监听端口。把系统 DNS 填成这个地址与端口，并不会自动形成 DNS 服务。
• dns.servers 在此仅展示 FakeDNS。真实部署还需按内核支持的规则组织真实解析，不能让需要真实 IP 的查询全部落入虚拟池。
• destOverride 中的 fakedns 用于从映射恢复目标域名；它本身既不会创建 TUN 网卡，也不会把系统 DNS 引入内核。

客户端自动生成配置时，直接编辑临时生成文件可能在重启或切换节点后失效。应使用当前版本提供的自定义配置入口，或在支持范围内调整 DNS 与入口设置。需要理解规则字段时，可先查看配置大全，不要把不同内核的示例拼在同一份配置里。

验证步骤：从 DNS 应答追到路由结果

建议每次只改一类设置，先保留可恢复的配置，再按下面顺序测试。验证目标是整条链路闭合，不是只看到一个虚拟 IP。单独执行一次延迟测试，也不能说明域名分流正确。

1. 记录基线。选定一个用于测试的域名，记录当前 DNS 应答、连接是否成功以及路由命中的出站。不要在测试中同时更换节点、订阅与规则集。
2. 清理旧缓存。Windows 可在 PowerShell 执行 Clear-DnsClientCache，随后重启测试应用。系统命令不会清理所有浏览器内部缓存，也不会清理代理内核自己的映射。
3. 检查应答地址。若查询确实经过所设的 IPv4 虚拟池，应答应落入 198.18.0.0/15。如果仍返回真实地址，先查 DNS 去向，不要立刻改路由。
4. 发起实际连接。观察客户端日志中目标是否能恢复为预期域名，并检查命中的规则或出站。日志字段随内核而异，不保证每个日志级别都显示映射细节。
5. 分别测试直连与代理。两类目标都应能完成连接。若只有直连失败，重点检查真实 DNS 解析与直连出站；若虚拟地址全部超时，先检查连接回收路径。
6. 验证退出行为。关闭该模式后再次清理系统与应用缓存，确认新的查询不再沿用旧虚拟地址；否则退出后的失败容易被误判为网络故障。

适用场景与应暂缓开启的情况

FakeDNS 更适合需要透明接管、依赖域名规则、又能统一管理 DNS 的环境。它可以减少对协议嗅探结果的依赖，但也引入了对映射状态和缓存一致性的要求。是否启用，应由当前问题决定。

• 适合评估：TUN 接管后日志经常只显示 IP，域名规则难以命中，而且能够控制系统与应用的解析路径。
• 可以维持现状：浏览器通过明确的代理配置提交域名，现有域名分流已经稳定，没有透明接管需求。
• 应先排查：企业内网使用分离 DNS、内部域名或与虚拟池冲突的路由，需要先划分内部查询与公网查询。
• 应谨慎测试：应用把 DNS 结果长期保存在磁盘、跨进程传递 IP，或者在代理退出后继续使用旧连接。
• 不应据此期待改善：节点不可达、服务器认证参数错误、传输路径拥塞。这些问题不由域名映射机制解决。

局域网打印机、网络存储与内部业务域名通常应保留符合本地网络要求的解析方式。把全部查询统一替换成虚拟地址，可能破坏依赖真实地址的发现、访问控制或诊断流程。先做局部验证，再扩大范围，比一次性开启所有相关选项更容易定位问题。

FakeDNS 常见问题与处理顺序

实际配置可以遵循一个顺序：先让普通代理与真实 DNS 正常工作，再验证 TUN 接管，最后引入 FakeDNS。每一步保留日志与可恢复设置，才能区分是解析、路由还是出站连接出了问题。