本文面向已经使用 v2rayN、v2rayNG 或 v2flyNG，并准备理解 TUN 接管与域名分流细节的用户。重点解释 FakeDNS 的映射表、保留地址池、域名还原、规则命中顺序和故障判断；读完可以分清“DNS 变快”和“连接变快”，并判断当前网络是否值得开启 FakeDNS。
FakeDNS 链路：先返回假 IP，再恢复原域名
普通 DNS 流程会先把域名发送给解析服务器，取得真实 A 或 AAAA 记录后，应用再连接返回的地址。这个过程至少包含一次 DNS 往返；如果系统 DNS 响应慢、解析请求走错出口，或者本地缓存没有命中，连接建立就会被解析阶段阻塞。
FakeDNS 改变的是本地解析路径。应用查询域名时，内核不必立即向公共 DNS 获取真实地址，而是从预设地址池中分配一个假 IP，同时记录“域名—假 IP”的对应关系。应用随后向假 IP 发起连接，TUN 入站捕获这条连接，核心根据映射表找回原域名，再按域名规则选择代理、直连或阻断出口。
常见的 IPv4 地址池是 198.18.0.0/15。这段地址用于网络设备基准测试，不属于公网可路由地址，因此适合在本机内部充当映射标记。假 IP 不是目标服务器地址，也不会作为最终目的地址直接发往代理节点；它的作用类似本地索引，真正的代理请求仍以还原后的域名为目标。
上面的延迟数据来自同一设备连续执行 100 次冷查询的示例：本地 FakeDNS 返回中位值约 1.2 毫秒，远端 DNS 往返中位值约 43 毫秒。它只说明首个解析响应可以更快，不代表网页总加载时间一定减少 41.8 毫秒；TLS 握手、节点往返、丢包和服务器响应仍然决定后续速度。
映射表、嗅探与出站之间如何配合
FakeDNS 能否工作，取决于三个环节是否同时成立：DNS 查询被核心接收，假地址连接被对应入站捕获，出站前能够用映射记录还原域名。只启用地址池但没有让 TUN 流量进入核心，会出现应用拿到 198.18.x.x 后无法连接的现象。
核心收到指向假 IP 的连接后，会检查目标是否属于 FakeDNS 地址池。如果映射表存在对应记录，例如 198.18.0.27 对应 example.net，目标就可以恢复为域名。随后，路由器按配置顺序检查域名规则、IP 规则、端口规则和入站标签，最终选择代理或直连出站。
TUN + FakeDNS 配置重点
- IPv4 地址池
- 198.18.0.0/15
- 常见池容量
- 65535
- 目标还原
- fakedns
- 路由依据
- 恢复后的域名
- 适用入口
- TUN 入站
地址池、DNS 返回与目标还原必须来自同一套核心配置。
普通系统代理配置重点
- HTTP 端口
- 10809
- SOCKS 端口
- 10808
- 目标来源
- 应用提交的域名
- DNS 接管
- 通常不完整
- 适用入口
- 显式代理应用
应用已经把域名交给代理时，FakeDNS 带来的收益通常有限。
这里容易混淆“协议嗅探”和“FakeDNS 还原”。HTTP、TLS 或 QUIC 嗅探尝试从流量内容中识别域名；FakeDNS 还原则直接读取先前建立的映射。两者可以共同存在，但映射还原不依赖每个连接都暴露可识别的主机名，因此对不便从负载中提取域名的连接更稳定。
{
"fakedns": [
{
"ipPool": "198.18.0.0/15",
"poolSize": 65535
}
],
"dns": {
"servers": [
"fakedns"
]
}
}这段配置只展示地址池与 DNS 服务器之间的概念关系，不能脱离入站、路由和出站单独使用。实际由客户端生成配置时，还要确认 TUN 入站已启用目标还原，并且本地网络没有把同一地址段用于实验设备或企业测试环境。
FakeDNS 对延迟与分流的实际影响
FakeDNS 最直接的收益是把“应用等待真实 DNS 响应”改成“应用立即取得本地假地址”。当远端 DNS 往返较高、首包容易超时或多个应用同时发起冷查询时，这个差异比较明显。已经命中系统缓存的域名则不会重复承担完整解析延迟，收益会缩小。
第二个收益是保留域名信息。应用在普通解析后只连接真实 IP，进入 TUN 的可能只剩目标地址；如果同一 IP 承载多个域名，单靠 IP 规则难以精确区分。FakeDNS 在连接阶段恢复原域名后，像 domain、domainSuffix、geosite 这类规则可以在出站选择前参与匹配。
| 观察项 | 普通远端 DNS | FakeDNS | 判断方法 |
|---|---|---|---|
| 首次返回地址 | 真实 A/AAAA 记录 | 保留段假 IP | 查看应用侧解析结果 |
| 域名信息 | 解析后可能只剩 IP | 由映射表恢复 | 查看路由命中日志 |
| 冷查询延迟 | 受 DNS 往返影响 | 通常为本地响应 | 连续测试并比较中位值 |
| 最终连接目标 | 真实 IP 或远端解析结果 | 还原后的域名 | 查看代理出站日志 |
第三个影响是解析出口更一致。若某域名应走代理，而系统却先通过本地网络查询 DNS，解析路径与流量路径就可能分离。FakeDNS 让本机先完成假地址分配，真实解析可以延后到代理出站一侧处理，从而减少本地 DNS 对代理域名解析结果的干扰。
结论：先确认瓶颈是否位于 DNS
若核心日志显示从查询到返回已低于 5 毫秒，而连接阶段仍耗时 300 毫秒以上，继续调整 FakeDNS 不会解决主要问题；应转向检查节点往返、丢包、TLS 握手和路由绕行。
FakeDNS 也会改变排障方式。看到 198.18.x.x 不应立即判断为解析错误，先检查该地址是否属于配置中的池、是否存在映射记录，以及连接有没有进入 TUN。只有应用收到假地址而核心无法恢复域名时，才说明链路中间断开。
与 TUN 模式和路由规则搭配
TUN 模式通过虚拟网卡接管不主动使用系统代理的进程流量，因此是 FakeDNS 最常见的配套入口。在 v2rayN 中，可以先进入「设置」→「参数设置」核对本地监听端口，再启用 TUN 模式；不同版本的 TUN 选项位置可能调整，最终应以状态栏显示和核心启动日志为准。
Android 端的 v2rayNG 使用 Xray 内核，v2flyNG 使用 v2fly 内核。启用设备级流量接管后，应检查客户端设置中的本地 DNS、域名策略和路由模式是否来自同一个配置方案。不要同时让另一项本地网络工具占用 VPN 接口，否则 DNS 查询可能绕过当前核心。
- 先验证 TUN 接管。关闭应用自身的 HTTP 或 SOCKS 代理设置，启动客户端后访问测试域名，确认连接仍出现在核心日志中。
- 再观察假地址。对一个未缓存域名执行查询，检查是否返回配置池中的
198.18.x.x地址。 - 确认域名还原。在路由日志中查找原始域名，而不是只看到假 IP；若仅记录假 IP，应检查目标还原配置。
- 验证规则命中。分别测试一个代理域名和一个直连域名，确认它们落到预期出站标签。
- 最后测试回退。关闭 FakeDNS 后恢复普通 DNS，确保配置失败时仍有明确可用的回退路径。
代理域名规则
- 匹配对象
- 还原后的域名
- 规则类型
- domainSuffix
- 预期出站
- proxy
- 验证位置
- 路由命中日志
域名规则应排在可能覆盖它的宽泛 IP 规则之前。
局域网与直连规则
- 保留目标
- 私有地址段
- 预期出站
- direct
- DNS 方式
- 本地或指定服务器
- 优先检查
- 地址池冲突
内部域名依赖局域网 DNS 时，不应被统一交给 FakeDNS 处理。
规则顺序尤其重要。假地址只是临时目标，如果一条宽泛的 IP 规则先匹配 198.18.0.0/15 并直接放行，连接可能在域名还原前被送到错误出口。更稳妥的做法是让 TUN 入站完成 FakeDNS 还原，再按域名规则分流，同时明确排除局域网和内部服务。
适合开启与不适合开启的场景
适合开启的典型环境是：TUN 已稳定接管、远端 DNS 往返较高、域名分流规则较多，并且应用流量经常只以 IP 形式进入核心。此时 FakeDNS 同时缩短冷查询等待，并让路由器重新获得原始域名，收益不只是单纯减少几十毫秒。
如果只使用浏览器显式连接本地 HTTP 或 SOCKS 端口，浏览器通常会把域名直接交给代理。核心已经拿到域名时，FakeDNS 对分流准确性的提升很小。此类配置优先保证 10808、10809 等监听端口没有冲突，并检查系统代理是否指向正确端口。
- 建议开启：TUN 接管全局流量，且核心日志中经常只能看到目标 IP。
- 建议开启：远端 DNS 冷查询长期超过 50 毫秒，首开应用存在明显等待。
- 谨慎开启：单位内部域名必须由局域网 DNS 解析，且存在分区域名结果。
- 谨慎开启：真实网络已经使用
198.18.0.0/15或自定义假地址池。 - 收益有限：应用已通过显式代理提交域名，本地 DNS 不是当前瓶颈。
查询结果变成 198.18.x.x，是不是 DNS 配错了？
先确认 FakeDNS 是否处于启用状态。启用后返回保留段地址属于预期行为；接着查看核心日志，确认连接进入 TUN 后能恢复成原域名并命中路由规则。
开启后网页反而打不开，先检查哪里？
先关闭 FakeDNS 验证普通 DNS 是否可用，再检查 TUN 入站、目标还原和地址池是否同时生效。若日志只出现假 IP 而没有域名，通常是映射没有被入站正确读取。
FakeDNS 能让所有连接都明显变快吗？
不能。它主要减少冷查询等待。若 DNS 本来只需 3 至 5 毫秒，而节点往返达到 180 毫秒，整体体验仍由节点链路决定，应先比较连接阶段和解析阶段的耗时。
局域网设备名称解析失败怎么处理？
把内部域名后缀交给局域网 DNS，并将私有地址段保持直连。若内部网络占用 FakeDNS 地址池，还要更换地址池或在该网络配置下关闭 FakeDNS。
订阅更新也需要经过 FakeDNS 吗？
订阅更新与节点流量是两条可独立处理的请求。先确认订阅地址能通过当前代理或直连策略访问，不要把订阅失败直接归因于 FakeDNS；应查看更新请求使用的出站和 DNS 记录。
按日志完成验证与故障定位
验证 FakeDNS 不应只看网页能否打开。完整检查需要覆盖 DNS 返回、TUN 捕获、域名恢复、规则命中和代理出站五个阶段。任一阶段缺失，都可能出现“偶尔能用”或“某些应用失效”的结果。
建议选取两个此前没有访问过的域名：一个应走代理，一个应直连。清理客户端内部 DNS 缓存后分别发起查询，记录返回地址与时间；然后立即建立连接，在日志中确认原域名、入站标签和出站标签。测试期间不要频繁切换节点，以免把节点差异误判成 DNS 差异。
- 记录客户端当前配置，确认本地 SOCKS 端口为
10808、HTTP 端口为10809，或记录实际自定义值。 - 启动 TUN 后检查核心日志，确认虚拟网卡创建成功，没有路由添加失败或接口占用提示。
- 查询测试域名，确认响应地址位于配置的 FakeDNS 池内，响应时间通常应低于远端 DNS 往返。
- 发起连接并搜索日志中的原域名，确认不是始终以
198.18.x.x作为最终目标。 - 检查代理域名命中
proxy，直连域名命中direct，避免被更靠前的宽泛规则覆盖。 - 连续测试 20 次，分别记录中位值和失败次数，不以单次最快结果作为结论。
结论：假地址可见，原域名也必须可追踪
应用侧看到保留段地址只能证明 FakeDNS 已返回结果；日志中能继续看到原域名、正确出站和成功连接，才表示“分配—捕获—还原—分流”整条链路闭合。
若测试失败，可按逆序回退：先暂时停用域名分流规则，确认基础代理出站可达；再关闭 FakeDNS，改用普通 DNS 检查解析；最后停用 TUN，使用显式系统代理验证本地监听端口。每次只改变一个变量，才能确定故障属于地址池、DNS、TUN、路由还是节点链路。
FakeDNS 的核心价值不是制造一个看似特殊的解析结果，而是让接管全局流量时仍能稳定保留域名维度。配置正确时，假地址只在本机短暂存在，路由判断使用恢复后的域名，代理出站继续按照 VMess、VLESS 和订阅节点的实际配置建立连接。是否开启，应由 DNS 延迟、TUN 接管方式、内部网络结构和分流需求共同决定。