FakeDNS 适合已经能正常连接、但需要改善域名识别与 DNS 路径的 v2rayNG 用户。先弄清虚拟地址如何还原，再检查 Android VPN 接管、域名路由与应用自带 DNS；最后按单变量步骤开启并验证。它不能修复失效节点，也不能保证所有应用的 DNS 查询都经过代理。
FakeDNS 原理：用虚拟地址保留域名线索
普通 DNS 查询会把域名换成服务器的真实 IP，应用随后连接这个 IP。进入透明接管路径后，代理内核有时只能看到目标 IP，不再知道应用最初查询了哪个域名。依赖域名的路由规则就可能无法命中，只能继续尝试嗅探、匹配 IP，或者落到默认出站。
FakeDNS 则维护一张“域名与虚拟 IP”的映射表。应用询问域名时，它先分配一个池内地址；应用连接该地址时，内核查回域名，再按路由选择直连或代理。这个地址不是网站服务器，也不应被直接送到公网。
Xray 的 FakeDNS 常见 IPv4 池使用 198.18.0.0/15，范围为 198.18.0.0 至 198.19.255.255。该网段原本保留用于网络设备基准测试，并非可访问网站的公网地址，也不是通常所说的家庭局域网私有网段。看到这一范围的 DNS 回答，本身不代表解析被污染。
DNS 泄漏与解析延迟：能改善什么，不能保证什么
FakeDNS 对被接管的查询可以本地生成回答，不必在这一阶段向外部 DNS 请求真实 IP。这既减少了本地 DNS 直接得知目标域名的机会，也省去了应用等待这次外部查询的时间。不过，网站连接最终仍要找到真实服务器；解析可能在代理服务端进行，也可能在直连出站需要时进行。
| 流量路径 | FakeDNS 的作用 | 仍需检查 |
|---|---|---|
| 进入内核的普通 DNS 查询 | 本地返回虚拟地址，保留域名映射 | UDP/TCP 53 查询是否确实进入处理链 |
| 以域名交给代理出站 | 可把还原后的域名交给后续连接流程 | 服务端解析策略与 DNS 出口 |
| 按规则选择直连 | 先恢复域名，方便匹配规则 | 直连侧如何解析真实地址 |
| 应用自带加密 DNS | 未必能处理其中的域名查询 | 应用内 DoH 与安全 DNS 设置 |
| 应用直接访问固定 IP | 没有对应查询，无法凭空补出域名 | IP 规则与默认出站 |
“DNS 泄漏”要结合预期判断：如果规则本来允许部分域名直连，那么这些域名在直连侧解析，不一定属于配置故障。真正需要核对的是：原本要求经代理处理的域名，是否仍被发给了本地网络的解析器。只看检测网页显示了哪家解析服务，不能证明整台设备的所有应用都走同一条路径。
结论：先验证 DNS 路径，再比较打开速度
保持同一节点与路由规则，分别测试开关前后的目标应用。只有查询进入 FakeDNS、后续连接也能正确还原，才有比较首开等待时间的意义；不要把更快拿到虚拟地址等同于网站整体加载更快。
v2rayNG 开启前：核对 VPN、DNS 与域名还原
Android 上的 v2rayNG 通常通过系统 VPN 服务获得虚拟网络接口，再把流量交给内核处理。这与桌面环境常说的 TUN 接管属于相近思路，但界面并不一定存在一个单独叫“TUN 模式”的开关。应先确认 VPN 已启动、目标应用未被排除，再调整 FakeDNS，不能直接套用 v2rayN 的桌面菜单。
客户端入口核对
- 功能入口
- 侧栏「设置」→「启用 FakeDNS」
- 相关选项
- 「启用本地 DNS」与 DNS 配置项
- 接管范围
- 检查「分应用代理」中的选择
- 生效动作
- 停止连接后重新启动 VPN
不同版本的名称与分组可能调整；以已安装版本为准，不把名称相近的开关当成同一功能。
内核链路核对
- DNS 回答
- 查询被送到 FakeDNS 处理
- 地址池
- 常见 IPv4 范围为 198.18.0.0/15
- 域名还原
- 检查与 fakedns 对应的嗅探配置
- 路由依据
- 还原域名后匹配域名规则
自动生成配置通常由客户端配套处理；自定义配置不能只添加一个地址池就视为完成。
先记录「设置」中的 DNS、流量嗅探以及路由选项，再开启「启用 FakeDNS」。若当前版本提示相关依赖，应按提示一起配置；不要为了“保险”同时开启所有 DNS 选项。自定义配置可能不采用界面自动生成的字段，必须确认实际运行配置，而不是只看界面开关。
- 普通配置：优先使用客户端提供的 FakeDNS 配套设置，不手工拼接另一份不明来源的 DNS 配置。
- 自定义配置：检查 DNS 是否使用
fakedns，以及相应入站的sniffing、destOverride是否包含所需的 FakeDNS 还原处理。 - 分应用代理：测试应用必须在 VPN 接管范围内；调整后重新建立 VPN，再关闭并重开应用。
- 系统 DNS：在 Android「设置」中搜索「私人 DNS」，记录原状态。若使用自定义加密 DNS，先核对它与 VPN 的实际关系，不预设 UDP 53 规则能接管所有查询。
域名分流与 IP 分流：规则顺序需要一起检查
FakeDNS 的直接收益之一是恢复域名，让域名规则有可用的匹配对象。例如，内核还原出目标域名后，可以先尝试指定域名规则，再处理其他规则。但它不负责替用户决定哪些网站应该直连，也不会自动补齐缺失的规则资源。
路由通常按配置顺序匹配。若自定义规则把整个虚拟地址池提前判为直连，而且此时目标尚未正确还原，流量可能被送到无法访问的地址。另一个常见误区是把“IP 属于哪个地区”当成“域名属于哪个类别”：虚拟 IP 只是本地映射标记，不能拿它做真实服务器的地理判断。
- 先确认域名恢复。通过可用的日志或运行配置，检查入站是否能将 FakeDNS 地址还原；不要先给
198.18.0.0/15添加直连规则。 - 再检查域名规则。确认指定域名、域名集合与默认出站的顺序符合预期，尤其注意过早匹配的宽泛规则。
- 最后检查 IP 判断。若启用
IPIfNonMatch或IPOnDemand等域名解析策略，路由阶段仍可能触发真实解析；这不是 FakeDNS 自动失效的证据。 - 单独测试局域网。打印机、路由器管理页与内部域名可能依赖本地 DNS。保留明确的局域网访问规则，并检查 VPN 路由是否覆盖到相关地址。
开启与回退：用同一应用做单变量验证
适合尝试 FakeDNS 的情况，是节点连接已经正常，但透明接管后域名规则经常无法命中，或被接管的普通 DNS 查询等待明显。若现有解析与分流都稳定，开启它不一定带来可见收益。遇到服务器拒绝连接、TLS 握手失败或订阅更新失败时，应先处理对应问题，FakeDNS 不是这些故障的通用修复项。
- 建立基线。关闭 FakeDNS，保持节点、路由和网络不变，确认浏览器、目标应用与一个局域网服务的表现。记录是否能打开、是否走预期出站，而不是只记“快”或“慢”。
- 仅改变 FakeDNS 相关设置。在「设置」启用功能及客户端提示的必要依赖，停止并重新启动 VPN。此时不同时更换节点、DNS 服务或路由模式。
- 清除旧连接影响。彻底退出测试应用后重新打开。若应用沿用 DNS 缓存，可先强行停止再测试；浏览器还需检查自身「安全 DNS」设置。
- 检查两端表现。普通 DNS 测试可能看到池内地址；随后实际访问必须成功。只有前者成功而连接失败，重点检查映射还原、VPN 接管和旧缓存。
- 异常时完整回退。恢复原有开关，重启 VPN，再重新打开应用。若仍持有旧虚拟地址，等待应用缓存失效或重启设备，不要通过长期固定虚拟 IP 规避问题。
结论：能还原、能分流、能回退，才保留开启
若启用后只有部分应用失效，先定位该应用的加密 DNS、分应用代理和缓存，而不是继续叠加全局规则。若无法确认实际配置链路，恢复原设置，比同时修改多个 DNS 与嗅探选项更容易排查。
FakeDNS 常见问题：地址异常、应用失效与切换网络
解析出来是 198.18 开头，是不是节点有问题？
先查看「设置」→「启用 FakeDNS」是否开启。若地址属于配置的池内范围，这是预期的虚拟回答；接着实际打开目标站点。只有连接无法还原时，才继续检查 VPN 接管、嗅探配置和应用旧缓存，不凭地址外观判断节点失效。
浏览器正常，另一个应用却一直转圈怎么办？
到「分应用代理」核对该应用是否被接管，再检查应用内是否有独立的安全 DNS。保持节点不变，关闭 FakeDNS、重启 VPN，并强行停止该应用后重试。若只有开启时失败，重点排查该应用是否绕过了虚拟地址的回程路径。
开启后 DNS 检测仍看到本地解析服务，算泄漏吗？
先核对被测域名的出站：它可能按规则直连，也可能由应用自己的加密 DNS 解析。用预期走代理的域名重新测试，并检查浏览器「安全 DNS」与系统「私人 DNS」。检测结果应与路由目标一起判断，不能仅凭解析服务名称下结论。
从无线网络切到移动网络后打不开，要重新导入订阅吗？
先停止并重新启动 VPN，再关闭并重开应用，以排除旧连接和映射缓存不一致。订阅负责节点参数，不负责刷新应用 DNS 缓存；只有节点本身也无法连接时，才转向网络连通性与节点参数排查。
v2flyNG 能照抄 v2rayNG 的配置吗？
不能只凭功能名称照抄。v2rayNG 使用 Xray 内核，v2flyNG 使用 V2Fly 内核；即便两者都提供相关能力，字段支持、默认值和界面生成逻辑也可能不同。应以当前客户端与内核支持为准，迁移时分别核对 DNS、入站与路由配置。