FakeDNS 的作用是保存域名与虚拟地址之间的映射,让只看到目标 IP 的透明代理重新获得域名。它适合 DNS 查询与后续连接都由同一代理链路接管的场景,不是换一个 DNS 地址就能生效的加速选项。下文先解释数据流,再给出 Xray 配置片段、v2rayN 检查路径,以及断网后的回退方法。
FakeDNS 是什么:先返回虚拟 IP,再还原域名
普通 DNS 查询回答的是“这个域名对应哪些真实地址”。FakeDNS 回答的是“用这个虚拟地址代表刚才查询的域名”。例如,应用查询 example.com,FakeDNS 从自己的地址池分配一个地址,并保存对应关系。应用随后连接这个地址,代理入口查回域名,再按域名规则选择直连或代理出站。
关键不在“虚拟”两个字,而在完整闭环:回答 DNS 的映射表,必须能被处理后续连接的组件访问。如果 DNS 请求进入一个进程,连接却交给另一个没有共享映射的进程,后者只会看到无法用于公网访问的目标地址。即使两个程序都叫代理,也不能假定它们自动共享映射。
普通 DNS 与 FakeDNS 的区别
普通 DNS 也可以配合域名分流。应用使用 HTTP 代理或把域名交给 SOCKS 代理时,代理本来就可能知道域名;这时增加 FakeDNS 未必有收益。它更有价值的情况,是 TUN 或透明代理截获了一个以 IP 为目标的连接,而路由规则仍需要原始域名。
| 比较项 | 普通 DNS | FakeDNS |
|---|---|---|
| 返回结果 | 上游解析得到的真实地址 | 从本地地址池分配的虚拟地址 |
| 域名保留方式 | 依赖代理协议、嗅探或额外记录 | 依赖域名与虚拟地址映射表 |
| 后续连接 | 可以按真实 IP 发起连接 | 必须先被接管并还原目标 |
| 真实解析时机 | 通常在应用连接前 | 按出站方式在后续阶段完成 |
| 停用后的缓存 | 缓存地址在有效期内通常仍可连接 | 残留虚拟地址可能让连接失败 |
FakeDNS 也不等于加密 DNS。DoH、DoT 解决的是 DNS 查询传输方式;FakeDNS 解决的是域名信息如何跟随后续连接。把查询交给 FakeDNS 后,直连目标仍可能需要真实解析,代理服务器的域名也要能被正常解析。不能据此认定所有 DNS 请求都已消失,或所有流量都经过代理。
地址池与端口:三个容易混淆的数字
198.18.0.0/15 覆盖 198.18.0.0 到 198.19.255.255,包含 131072 个地址;这不代表映射表一定同时保存这么多条记录。示例中的 poolSize 是映射池容量设置,不能把地址范围、映射容量和 DNS 缓存有效期当成同一个概念。
端口同样需要分清。系统向 DNS 服务发起查询,常见目标是 UDP 或 TCP 的 53 端口;代理软件内部的 DNS 接收端口可以另行配置。HTTP、SOCKS 的本地监听端口不是 DNS 端口,把系统 DNS 指向一个 HTTP 代理监听地址,不会自动产生 FakeDNS。
- 地址池范围应避开现有 VPN、企业网络和实验网络正在使用的网段。
- 改变地址池后,应同步检查 TUN 路由或透明转发规则是否覆盖新范围。
- 映射池较大不代表网页更快;先确保查询与连接能走完同一条链路。
开启前先确认:谁接管 DNS,谁处理连接
v2rayN 是客户端界面,Xray 是可能被调用的代理内核。界面中的 TUN 功能还可能由独立组件承担,不能仅凭节点使用 VLESS 或 VMess,就判断 TUN 的 DNS 一定由 Xray 处理。协议描述的是节点连接方式,不决定本机 DNS 接管架构。
系统代理场景
- 接管对象
- 遵循系统代理设置的应用
- 域名来源
- 代理请求可能直接携带域名
- DNS 范围
- 不保证接管系统全部查询
- 建议起点
- 先使用常规 DNS 与域名路由
只为浏览器代理访问时,不必先引入虚拟地址池。
TUN 或透明代理场景
- 接管对象
- 进入虚拟网卡或转发入口的数据包
- 域名来源
- FakeDNS 映射或其他嗅探结果
- DNS 范围
- 需要明确配置查询接管路径
- 必要条件
- 虚拟地址连接可回到对应映射表
先确认组件实现,再选择它支持的 FakeDNS 配置格式。
- 在 v2rayN 的「设置」→「参数设置」中核对当前核心相关设置,并查看启动日志实际启动的进程。版本之间分组名称可能调整,以当前界面和日志为准。
- 若界面提供「设置」→「DNS 设置」,先确认它修改的是哪个核心的配置,不要把同名 DNS 选项视为全局总开关。
- 记录当前系统代理状态、TUN 状态和 DNS 配置,再修改一项。保留原配置副本,便于直接回退。
- 若使用 v2rayNG 或 v2flyNG,同样先确认实际内核与配置支持情况;不要把桌面客户端的菜单路径照搬到安卓端。
Xray 配置示例:生成映射与还原目标缺一不可
下面是面向支持这些字段的 Xray 核心的配置片段,不是可单独运行的完整节点配置。使用前应核对本机核心版本的配置说明。客户端自动生成的文件可能在保存设置或切换节点时被覆盖,因此应通过客户端支持的自定义配置入口修改,而不是反复编辑临时文件。
第一部分:定义地址池并选择 FakeDNS
{
"fakedns": [
{
"ipPool": "198.18.0.0/15",
"poolSize": 65535
}
],
"dns": {
"servers": [
"fakedns"
]
}
}
顶层 fakedns 定义映射池,dns.servers 中的 "fakedns" 选择内部 FakeDNS 服务。这个最小片段只说明字段关系,并未提供节点服务器域名、局域网域名和直连目标所需的真实解析方案。生产配置需要按用途安排普通解析器,避免把所有解析需求都交给虚拟地址池。
第二部分:让接收连接的入口还原域名
{
"sniffing": {
"enabled": true,
"destOverride": [
"fakedns"
]
}
}
第二段应合并到实际接收目标连接的 inbound 对象中,不是新增一个顶层字段。destOverride 中的 "fakedns" 用于从 FakeDNS 映射恢复目标域名。不要只在接收 DNS 查询的入口设置它,却遗漏接收网页或应用连接的入口。
- 先保证节点服务器地址可解析,避免“连接代理前必须先通过代理解析”的循环依赖。
- 不要对虚拟地址连接仅做域名规则匹配却保留虚拟目标直连;出站前必须完成有效的目标还原。
- 若有 IPv6 查询,应单独设计 AAAA 记录与 IPv6 流量策略;只配置 IPv4 地址池不能证明 IPv6 已被接管。
如何验证 FakeDNS 生效,而不是只看到一个虚拟地址
完整验证需要同时观察 DNS 答案、连接接管和最终访问结果。只看到 198.18.x.x,最多说明某一次查询拿到了虚拟地址,并不能证明浏览器连接成功,也不能证明域名分流使用了预期规则。
- 清除旧状态。关闭测试浏览器,应用配置并重启相关核心。Windows 可在终端执行下方命令清除系统 DNS 缓存;应用自身缓存仍可能需要单独清理。
- 查询测试域名。执行
nslookup example.com,记录返回地址和所显示的 DNS 服务器。若使用 IPv4 FakeDNS,检查 A 记录是否位于配置的地址池内。 - 验证应用路径。重新打开浏览器访问同一域名。浏览器的安全 DNS 可能绕过系统查询路径,应暂时关闭该功能进行对照,而不是认定命令行结果代表所有应用。
- 检查路由结果。在核心访问日志中核对目标域名与出站标记。日志格式依版本变化,应关注是否恢复到预期域名,而不只看“连接成功”字样。
- 检查直连与代理。各选一个已有规则覆盖的目标测试,确认域名命中后进入对应出站。不要用虚拟 IP 的归属地判断目标应当直连还是代理。
ipconfig /flushdns
nslookup example.com
如果 nslookup 返回真实 IP,原因可能是查询没有进入 FakeDNS,也可能是该域名按设计使用普通解析器。若返回虚拟 IP 但网页打不开,应优先检查虚拟网段路由和映射还原,不要先更换订阅或批量修改节点参数。
常见问题:虚拟地址、浏览器绕过与关闭后断网
查到了 198.18 开头的地址,为什么还是打不开?
先确认这个地址属于当前配置的地址池,再检查 TUN 路由是否接管它。然后查看接收连接的入口是否能读取同一份映射。只有 DNS 回答生效、连接却绕过代理,是最典型的半配置状态。
命令行查询正常,浏览器为什么还是走另一条路?
检查浏览器设置中的「安全 DNS」或「使用安全 DNS」选项,暂时关闭后重启浏览器对照。浏览器可能自行发起加密查询,也可能复用旧连接;清理系统缓存并不等于清掉浏览器内部状态。
关闭 TUN 后,为什么一些网站突然打不开了?
应用可能仍缓存虚拟 IP,但负责还原它的链路已经退出。恢复原系统 DNS 和路由,执行 ipconfig /flushdns,再重启受影响应用。若仍未恢复,检查虚拟网卡路由是否残留。
开启 FakeDNS 能降低游戏延迟吗?
它主要改变域名与连接的关联方式,不改变节点距离或链路拥塞。需要真实 IP 探测、内置网络诊断或自行校验地址的应用,反而可能与虚拟答案不兼容。应先使用普通 DNS 测试,再针对单个应用决定是否排除。
重启核心后,之前打开的网站为什么短暂失效?
不要假定映射表会跨重启保留。应用缓存的虚拟地址可能已找不到对应域名,也可能与新映射不一致。关闭旧连接、刷新 DNS 缓存并重新发起查询,比连续切换节点更有针对性。
适用场景与回退顺序
当透明代理需要稳定获得域名、DNS 与连接都由可协作的组件处理,并且愿意维护例外规则时,FakeDNS 才是合适的工具。它不是订阅节点的附加能力,也不要求服务端节点采用某一种协议;主要配置发生在本机接管与路由阶段。
- 适合:TUN 场景下需要按域名分流,又无法仅靠应用代理请求保留域名;或透明代理已经有明确的 DNS 接管与目标恢复流程。
- 优先保持普通解析:只使用浏览器系统代理、依赖局域网名称发现、需要真实地址诊断,或已有企业网络策略管理 DNS。
- 应先做兼容性测试:游戏、实时通信、虚拟机与多层 VPN 叠加环境。检查虚拟网段冲突,也要检查 UDP 和 IPv6 是否遵循同一接管策略。
需要回退时,先恢复原有 DNS 配置与接管规则,确保新查询得到正常结果;再退出相关 TUN 或透明代理链路,并清理系统及应用缓存。最后分别验证域名解析与普通访问。不要只删除地址池配置却继续向应用返回旧的虚拟答案,也不要只关闭代理进程而保留虚拟网段路由。