FakeDNS 返回的是供本地代理识别域名的地址，不是目标服务器的真实地址。本文适合正在配置 v2rayN TUN 模式、遇到虚拟 IP 或 DNS 异常的读者：先拆开查询、映射和出站三个环节，再判断是否适合启用，最后按可复现的顺序排查缓存、分流与地址冲突。
FakeDNS 是什么：用一个地址保存域名线索
普通 DNS 查询会把域名解析成目标服务的真实 IP，应用随后向这个地址建立连接。FakeDNS 则从预设地址池分配一个虚拟 IP，把“域名与虚拟 IP”的对应关系保存在本地，再把虚拟 IP 返回给应用。这个地址像一张取件凭证，只有掌握映射表的处理组件才能还原它代表的域名。
例如，应用查询 example.com，FakeDNS 可以返回池内的 198.18.0.10。应用连接该地址的 443 端口，接管组件查表恢复 example.com，再交给路由与出站处理。地址仅为流程示例，不代表这个域名固定对应此地址，也不是可直接访问的公网服务。
这里的关键不是“生成了一个假地址”，而是返回地址的组件与接收后续连接的组件能共享或衔接映射状态。只让 DNS 返回虚拟地址，却把连接交给普通网关，连接通常会失败。FakeDNS 也不承担流量加密，VMess、VLESS 等代理协议与它处在不同环节。
虚拟 IP 池：地址数量不等于缓存条目数
在 V2Ray/Xray 的 FakeDNS 配置语境中，常见 IPv4 地址池是 198.18.0.0/15。这个范围用于网络设备基准测试，并非普通公网目标地址。下面的三个数字分别描述地址范围、映射容量示例与常见 DNS 服务端口，不是性能测试成绩。
ipPool 决定可分配地址范围，poolSize 决定映射池容量，两者不是一回事。大量域名、长时间运行或映射淘汰可能让旧地址与当前映射失去对应；具体回收策略取决于实现。应用自身还可能保留旧 DNS 结果，因此重启内核后，原来缓存的虚拟地址不一定还能被正确识别。
判断：先查地址冲突，再考虑扩大映射池
如果企业 VPN 或实验网络已经使用 198.18.0.0/15，先检查实际路由和地址池冲突。增加 poolSize 不能修复重叠路由，也不能恢复重启前丢失的映射。
TUN 模式为什么常与 FakeDNS 一起使用
TUN 在网络层接收 IP 数据包，看到的起点往往是目标地址，而不是应用最初输入的域名。真实 IP 可能被多个域名共用，仅凭 IP 难以稳定恢复原始域名。FakeDNS 把域名保留在映射表里，让后续连接更容易按域名分流。
不过，TUN 和 FakeDNS 不是绑定开关。TUN 可以搭配真实 DNS 解析工作；FakeDNS 也可以用于其他具备透明接管能力的链路。TLS 或 HTTP 嗅探有时能提供域名线索，但并不覆盖所有协议和加密场景，不能直接视为映射表的等价替代。
- 更适合：需要接管不读取系统代理的应用，同时希望保留域名规则匹配能力。
- 先确认：应用的 DNS 查询确实进入配置的 DNS 处理链，返回虚拟地址后的连接也进入同一套接管路径。
- 不必强开：浏览器已经通过显式代理传递域名，且系统代理能够满足使用需求时，先保持现有配置。
- 不能补救：应用直接连接写死的真实 IP，没有域名查询过程，FakeDNS 无法凭空还原域名。
配置怎么读：DNS 分配与连接还原要配套
下面两张卡片用于辨认 Xray 风格配置中的关联字段，不是完整可运行配置，也不应直接粘贴到客户端的任意输入框。客户端自动生成的配置可能覆盖手工修改；如果 TUN 使用另一套 DNS 实现，其字段名与行为也可能不同。
DNS 分配侧
- 顶层配置
fakedns数组- 地址池
ipPool: 198.18.0.0/15- 映射容量
poolSize: 65535- DNS 服务项
dns.servers中使用fakedns
分配侧需要真正处理应用查询；只定义池而没有接入 DNS 请求链，不会自动接管系统解析。
入站还原侧
- 入站嗅探
sniffing.enabled: true- 恢复类型
destOverride: ["fakedns"]- 目标处理
- 恢复域名后交给路由与出站
- 验证依据
- 入站目标、域名与出站日志
还原侧必须能访问对应映射；不要把虚拟地址未经恢复就交给普通直连出站。
在 v2rayN 中，可以先从「设置」→「参数设置」核对当前基础配置，再检查当前版本提供的 DNS 与 TUN 设置入口；不同版本的选项位置和名称会变化。重点是确认谁监听 DNS、谁生成虚拟地址、谁接收连接，而不是机械寻找一个同名复选框。
v2rayNG 使用 Xray 内核，v2flyNG 使用 V2Fly 内核，但桌面配置与安卓应用设置不能按字段位置直接互抄。应以客户端实际暴露的选项、所带内核版本及运行日志为准。订阅通常提供节点参数，也不等于已经替用户设置好整机 DNS 接管。
减少一次解析，具体减少了哪一步
FakeDNS 可以省掉应用连接前、在本地等待真实目标 IP 的那次查询。但它并没有让整个访问过程永远不再需要 DNS。若代理出站把域名交给远端，远端仍可能解析；若命中直连规则，本地出站通常仍需要真实 IP 才能建立连接。
| 访问路径 | 应用收到的结果 | 后续解析位置 | 注意事项 |
|---|---|---|---|
| 普通 DNS 后直连 | 真实 IP | 通常已在连接前完成 | 应用直接使用解析结果 |
| FakeDNS 后代理 | 虚拟 IP | 可能交由代理服务端完成 | 取决于出站是否传递域名 |
| FakeDNS 后直连 | 虚拟 IP | 通常仍需本地真实解析 | 注意避免再次返回虚拟地址形成循环 |
| 应用自带加密 DNS | 由应用解析链决定 | 可能绕开本地 FakeDNS | 仅接管 53 端口通常不足 |
域名规则与 IP 规则也要分开看。恢复域名后，域名规则可以直接匹配；IP 地理分类仍可能需要真实地址，实际是否触发解析取决于路由策略。不能把 198.18.0.10 当成目标服务器所在地的证据，更不能因为启用 FakeDNS 就假定所有 DNS 都经过代理。
判断：用出站日志验证分流，不用虚拟 IP 判断地域
选择一项应直连的服务和一项应代理的服务，分别建立新连接，核对实际命中的出站。若只有地址池内 IP、看不到预期域名或出站，先修复还原链路，再调整域名规则。
兼容问题：从缓存、绕行与特殊网络排查
最典型的故障不是“所有网站都慢”，而是开启后少数应用失效、重启内核后旧连接异常，或者企业内网突然不可达。排查时一次只改变一个条件，保留可回退的基线，避免同时修改节点、DNS 和路由后无法判断原因。
为什么查询结果变成 198.18 开头，网页却能打开？
如果当前配置确实使用这个地址池，这是预期结果。确认日志能恢复域名并选择正确出站即可；不要把该地址填入节点服务器地址，也不要发送给其他设备当真实目标使用。
重启客户端后，有的应用突然连不上了？
先完全退出受影响应用再重开，让它重新查询 DNS。若仍复用旧地址，再清理系统解析缓存。Windows 可执行 ipconfig /flushdns；采用 systemd-resolved 的 Linux 可执行 resolvectl flush-caches。这些命令不会清空每个应用自己的缓存。
浏览器正常，游戏或局域网发现却失败了？
先关闭 FakeDNS 保留其余配置复测。部分应用依赖真实 IP 判断网络范围，局域网发现还可能依赖广播或多播。为本地域名和内部网络设计真实解析与直连例外，并验证这些例外没有被 TUN 再次错误接管。
开启后还是看到应用直接查询外部 DNS？
检查浏览器的「安全 DNS」或应用内的加密 DNS 设置，并核对 IPv6 查询路径。诊断时暂时改用系统解析后复测；不要仅凭 53 端口已被接管，就认定加密 DNS 也进入 FakeDNS。
另一个常见误区是用 ping 测虚拟 IP，再按丢包率判断节点质量。这个地址代表映射，不是真实服务器；ICMP 的处理方式也可能与 TCP、UDP 不同。应测试目标应用的实际连接，并把 DNS 耗时、连接耗时与下载吞吐分别记录。
启用与回退：用同一组请求做对照
是否使用 FakeDNS，最终要看它能否让当前接管链路更完整，而不是配置项越多越好。建议先记录客户端版本、当前节点、TUN 状态、DNS 处理组件和地址池，再用下面的步骤建立可重复的对照。
- 建立基线：关闭 FakeDNS，保持同一节点和同一网络，分别访问一个代理目标、一个直连目标与一个局域网服务，记录成功或失败。
- 只开启映射链路：确认 DNS 分配与入站恢复配套启用，不同时更换节点或改写整套路由。
- 重新建立连接：退出测试应用后重新打开，必要时清理系统 DNS 缓存，避免旧真实地址与新虚拟地址混测。
- 核对三类证据：查询是否返回池内地址，连接是否恢复到原始域名，最终出站是否符合分流预期。启用 IPv6 时，还需单独检查 AAAA 查询与 IPv6 连接。
- 验证回退：关闭 FakeDNS，恢复原 DNS 设置并重启受影响应用。回退后仍异常，就继续检查 TUN 路由、系统代理或节点连通性，不把所有问题都归到 DNS。