FakeDNS 用虚拟地址保存域名线索，适合需要在 TUN 接管后继续按域名分流的场景。它不是加速开关，也不替代真实解析。本文按“返回地址、接管连接、恢复域名、选择出站”的顺序说明原理，再给出开启条件、配置核对项与回退步骤，适合已能正常连接、准备调整 DNS 和路由的用户。
FakeDNS 如何保存域名线索
普通 DNS 查询会把域名解析为目标服务器的地址。应用随后建立连接，系统网络层通常只看到目标 IP；如果多个域名共用同一个地址，仅凭这个 IP 很难判断应用原先访问的是哪个域名。FakeDNS 改变了回答方式：先分配一个虚拟 IP，并在本地记住它对应的域名。
例如，应用查询 example.com，FakeDNS 从地址池分配一个地址。应用向该地址发起连接后，代理内核根据映射表找回 example.com，再用域名参与路由判断。这个地址只是本机处理链中的标记，并不是网站服务器的新地址，更不能直接作为远端节点地址使用。
虚拟地址池与真实 DNS 的区别
在 Xray 的 FakeDNS 配置中，常见的 IPv4 地址池示例是 198.18.0.0/15。它覆盖 198.18.0.0 至 198.19.255.255，属于为网络基准测试保留的地址空间，不是可直接访问的公网目标。不要把它等同于家庭局域网的私有地址段。
地址池范围与映射容量不是一回事。网段中有多少地址，不代表当前内核一定保留同样多的映射。容量、回收策略以及重启后映射是否仍在，都要看具体实现；不要把某份示例中的容量值当成所有客户端的默认值。
- 虚拟回答：让应用先获得一个可被本地识别的目标标记，不要求立即取得网站的真实 IP。
- 真实解析：连接最终仍需到达实际服务。使用域名交给远端代理时，可由远端解析；直连时通常仍需在本地处理真实解析。
- 加密 DNS：解决 DNS 查询传输方式的问题，与是否返回虚拟 IP 是两个维度，不能相互替代。
TUN 模式如何配合域名分流
TUN 把符合路由条件的 IP 流量送进虚拟网卡，但并不天然保留应用查询过的域名。FakeDNS 的价值，是让内核有机会把目标虚拟 IP 还原为域名，再匹配域名规则。它尤其适合那些不使用系统 HTTP 代理、却能被 TUN 接管的应用。
TUN 配合虚拟地址
- DNS 回答
- 由支持映射的组件返回虚拟 IP
- 流量入口
- 虚拟网卡及其配套路由
- 域名来源
- 查询与连接之间的地址映射
- 核对重点
- 地址池流量是否回到同一处理链
TUN 负责接管，映射负责恢复域名，两项都正确才形成闭环。
系统代理传递域名
- DNS 回答
- 不一定需要虚拟地址
- 流量入口
- 应用使用的 HTTP 或 SOCKS 代理
- 域名来源
- 代理请求中携带的目标主机名
- 核对重点
- 应用是否把域名交给代理处理
应用已把域名交给代理时，FakeDNS 通常不是必须项。
恢复域名后，最终走哪条出站仍由路由规则决定。FakeDNS 不会自动把所有流量改为代理，也不会生成直连白名单。域名规则、IP 规则及其顺序仍可能改变匹配结果；按 IP 地理信息分流时，还需要确认规则判断所用的地址是不是经过真实解析的目标地址。
哪些场景适合开启 FakeDNS
先判断现有连接丢失了什么信息，再决定是否开启。一个实用标准是：应用的连接能够被接管，但内核日志只看到目标 IP，导致预期的域名规则无法命中；同时，应用的 DNS 查询也能纳入同一条处理链。满足这两个条件，才值得测试。
| 使用场景 | 建议 | 优先核对 |
|---|---|---|
| TUN 接管，主要依靠域名规则 | 可以测试开启 | DNS 查询和虚拟地址连接都被接管 |
| 浏览器正常使用系统代理 | 通常先保持现状 | 代理请求是否已经携带域名 |
| 办公 VPN 与内网域名并存 | 先规划排除项 | 企业 DNS、内网网段及路由优先级 |
| 应用需要保存或校验真实 IP | 倾向真实解析 | 虚拟地址是否改变应用判断 |
| 目标本身就是字面 IP | 不能靠映射补出域名 | 直接按 IP 规则处理连接 |
FakeDNS 可能减少“先等待真实解析、再决定如何转发”的依赖，但不能据此承诺下载速度或访问延迟改善。应用自行使用加密 DNS 时，查询也可能绕过本地映射服务；即使普通 DNS 请求已经被接管，该应用仍可能拿到真实 IP，而不是虚拟 IP。
开启前按四项检查处理链
在 v2rayN 桌面端，先从「设置」中确认当前 TUN、DNS 和路由选项；具体子菜单以所用版本界面为准。安卓端的 v2rayNG 使用 Xray 内核，但 VPN 授权成功仅说明应用可以建立流量入口，并不证明 FakeDNS 映射已经工作。两端都应先记录原设置，避免同时更改多个变量。
- 备份当前配置。保存 DNS 服务器、路由规则和所用内核信息。先验证关闭 FakeDNS 时节点可用，避免把原有连接故障误判为映射问题。
- 核对 DNS 入口。确认目标应用查询经过哪个解析器。传统 DNS 常用 UDP 或 TCP 的
53端口；浏览器内置的加密 DNS 不能只靠检查这个端口来判断。 - 核对地址池路由。如果使用
198.18.0.0/15，确认该网段没有被办公网络占用，也没有被规则提前排除到物理网卡。特殊网络可能实际使用这个范围，冲突时不能直接照用。 - 核对域名恢复。查看当前内核的入站、嗅探或映射设置，确认支持从虚拟 IP 找回域名。Xray 的
fakedns、ipPool、poolSize等字段各有作用，不能只添加地址池而忽略消费映射的入站配置。
嗅探与 FakeDNS 也不是同一件事。嗅探可能从 HTTP 主机名或 TLS 握手信息识别域名；映射则依赖之前记录的 DNS 查询。不同流量能提供的信息不同，不应假定所有加密连接都能靠嗅探找回域名。客户端自动生成配置时，手动修改生成文件还可能被下一次启动覆盖。
如何验证虚拟 IP 与规则命中
测试时只选一个普通域名和一个需要直连的内网目标。关闭旧连接，再重新查询和访问；不要仅凭一个已打开的网页判断效果，因为连接复用与 DNS 缓存可能继续沿用修改前的结果。
- 第一步，看查询结果。Windows 可运行
nslookup example.com。如果工具使用的解析路径确实经过 FakeDNS，回答应落在配置的地址池内；结果不同不一定表示功能失效，先检查工具是否绕过了应用实际使用的解析路径。 - 第二步，看内核日志。重新访问域名，检查日志能否关联到原始域名、匹配的规则和出站。日志级别不同，可见字段也不同；需要时短暂提高日志级别，完成后恢复。
- 第三步，看直连目标。测试内网域名和局域网服务，确认没有被错误代理。记录“域名、解析结果、匹配出站、是否成功”，一次只调整一项设置。
直连冲突与关闭后的恢复步骤
最常见的失败方式，是应用拿到了虚拟 IP，连接却走了不认识映射的路径。例如：某个进程被排除在 TUN 外，仍使用被接管的系统 DNS；或者企业 VPN 抢走了地址池网段。这类问题不是节点速度不足，反复更换节点通常没有帮助。
开启后只有一个直连应用打不开，怎么处理？
先检查该进程是否被排除在 TUN 外。若必须直连，应让它使用真实 DNS 回答，并确保对应连接也走直连路径。排除 DNS 与排除流量要配套，不能只排除进程，却继续给它发虚拟地址。
关掉 FakeDNS 后还是超时，为什么？
应用或系统可能仍缓存着旧虚拟 IP。恢复原 DNS 设置后重启受影响应用；Windows 可在命令提示符运行 ipconfig /flushdns 清理系统 DNS 缓存，再重新连接。浏览器自身的缓存和现有长连接还可能需要单独重建。
重启客户端后，一部分连接突然失败怎么办？
检查是否出现“应用保留旧 DNS 结果，内核映射表已经重建”的情况。先关闭旧连接、清理相关缓存并重新查询。部分实现可能持久化映射，是否支持要看当前后端，不能默认重启前后的映射完全一致。
看到虚拟 IP，是不是说明 DNS 一定没有外泄？
不是。它只能说明这一次查询获得了虚拟回答。其他应用、其他记录类型或浏览器自己的解析路径仍可能不同。分别检查系统解析器、应用加密 DNS 和 IPv6 的 AAAA 查询，再结合实际路由判断。
如果目标是稳定访问而不是验证映射机制，优先保留可解释、可回退的设置：系统代理已能正确传递域名时，不必额外引入 FakeDNS；确实需要 TUN 域名分流时，再逐项验证 DNS、映射、路由和出站。遇到无法归类的连接失败，可按连接故障排查步骤继续检查，而不是同时调整所有网络选项。