本文适合正在使用 v2rayNG、Xray 内核或 TUN 模式，并希望按域名稳定分流的用户。读完可以判断是否需要 FakeDNS，理解虚拟 IP 映射、嗅探与路由的关系，并能按日志和地址段逐项定位网页打不开、应用绕过规则或局域网冲突。
FakeDNS 解决什么问题
普通 DNS 模式下，应用先把域名解析成真实 IP，再向该 IP 建立连接。代理核心接管连接时，看到的目标可能只剩一个地址，例如 203.0.113.20:443。如果同一地址承载多个域名，或者服务端地址经常变化，仅按 IP 编写路由规则就容易出现误判。
FakeDNS 不负责提供真实公网地址。它接到应用的 DNS 查询后，从预设地址池分配一个虚拟 IP，并保存“域名与虚拟 IP”的临时映射。应用随后连接这个虚拟地址，TUN 入站截获连接，代理核心再从映射表取回原始域名。路由模块因此可以直接匹配 domain、domainSuffix 或规则集中记录的域名。
常见 IPv4 地址池是 198.18.0.0/15。该网段用于网络设备基准测试，不应出现在公网路由中，适合充当本机虚拟目标。一个 /15 网段包含 131072 个地址，但 Xray 配置通常会设置更小的映射池，例如 poolSize: 65535，避免创建没有实际用途的超大映射表。
上面的 1–3 毫秒是同一台安卓设备上连续查询未缓存域名时的本机应答范围，只表示 FakeDNS 返回虚拟地址的耗时，不代表网页完整加载速度。真实连接仍要经过节点握手、远端解析、TLS 建连和内容传输。
一次域名请求如何经过虚拟 IP 映射
完整链路可以拆成六步。第一步，应用向系统 DNS 发出 A 或 AAAA 查询。第二步，TUN 模式把 DNS 流量交给代理核心。第三步，FakeDNS 从地址池取出一个未占用地址并写入映射表。第四步，应用收到虚拟地址后发起 TCP 或 UDP 连接。第五步，入站根据目标地址反查域名。第六步，路由模块按域名决定直连、代理或阻断。
- 查询进入代理核心：DNS 请求必须被 TUN 或受控的本地 DNS 捕获。若应用自行连接外部 DNS，FakeDNS 不会获得这次查询。
- 建立临时映射：例如
news.example被分配为198.18.0.12，映射只在本地内存中生效。 - 应用连接虚拟地址：应用把
198.18.0.12当作普通目标地址，不需要理解 FakeDNS。 - 入站恢复域名：核心通过映射表得到
news.example，并把域名交给嗅探和路由模块。 - 路由规则命中：域名规则可在真实 DNS 查询发生前决定出站，减少“先解析、后判断”造成的信息丢失。
- 出站完成解析：直连出站通常在本地解析真实地址；支持域名目标的代理出站可以把域名交给远端处理，具体行为取决于出站协议与 DNS 配置。
| 处理阶段 | 核心看到的目标 | 可用匹配条件 | 常见问题 |
|---|---|---|---|
| DNS 查询前 | 原始域名 | DNS 服务器规则 | 应用绕过系统 DNS |
| 虚拟应答后 | 198.18.0.0/15 内地址 | FakeDNS 映射 | 地址池与局域网重叠 |
| TUN 入站 | 虚拟 IP 与端口 | 映射、TLS、HTTP、QUIC 嗅探 | 嗅探目标未包含 fakedns |
| 路由阶段 | 恢复后的域名 | 完整域名、后缀、规则集 | 高优先级规则提前命中 |
| 出站阶段 | 域名或真实 IP | 出站协议与 DNS 策略 | 本地和远端解析结果不同 |
结论:先确认 DNS 流量是否进入 TUN
FakeDNS 配置存在但查询仍由外部 DNS 直接处理时，虚拟地址池和域名映射都不会生效。排查顺序应从 DNS 捕获开始，而不是先改路由规则。
Xray 配置中的关键字段
Xray 配置通常包含三个相互配合的部分：顶层 fakedns 定义地址池，dns.servers 把查询交给 FakeDNS，入站的 sniffing.destOverride 允许核心从虚拟地址映射中恢复目标域名。只添加其中一个字段，不能组成完整链路。
下面是用于解释字段关系的最小示例。客户端生成配置时可能增加本地 DNS、规则集和多个入站。编辑前应先导出当前配置，并确认所用客户端允许自定义底层 JSON；订阅更新可能覆盖手动修改的节点参数。
{
"fakedns": [
{
"ipPool": "198.18.0.0/15",
"poolSize": 65535
}
],
"dns": {
"servers": [
"fakedns",
"1.1.1.1"
],
"queryStrategy": "UseIP"
},
"inbounds": [
{
"tag": "tun-in",
"protocol": "tun",
"settings": {
"stack": "system"
},
"sniffing": {
"enabled": true,
"destOverride": [
"http",
"tls",
"quic",
"fakedns"
],
"metadataOnly": false
}
}
],
"routing": {
"domainStrategy": "IPIfNonMatch"
}
}destOverride 中的 fakedns 用于读取映射；http、tls 和 quic 则用于从相应协议元数据补充域名。两种来源并不冲突。映射可直接给出查询过的域名，协议嗅探则能处理部分未经过 FakeDNS、但握手中仍携带主机名的连接。
TUN + FakeDNS
- 地址池
- 198.18.0.0/15
- 池容量
- 65535
- 嗅探目标
- fakedns、tls、http、quic
- 适用规则
- 域名后缀与规则集
适合需要接管整机流量并按域名分流的安卓设备。
系统代理 + 普通 DNS
- 本地 SOCKS
- 127.0.0.1:10808
- 目标来源
- 应用直接提交域名
- 地址池
- 不启用
- 适用流量
- 遵循系统代理的应用
应用已向 SOCKS 入站提交域名时，FakeDNS 的收益通常有限。
v2rayNG 使用 Xray 内核时，优先通过客户端界面管理 TUN 与本地 DNS。常见检查路径是「设置」→「VPN 设置」查看流量接管相关选项，再到「设置」→「路由设置」确认规则顺序。不同版本的开关名称可能调整，因此判断是否生效应以导出的运行配置和核心日志为准，而不是只看界面开关状态。
哪些场景适合开启 FakeDNS
FakeDNS 最适合 TUN 已接管整机流量、路由规则主要按域名编写的环境。安卓应用经常先自行解析域名，再把真实 IP 交给网络栈。TUN 只能看到目标 IP 时，域名规则的命中率依赖嗅探结果；加入 FakeDNS 后，DNS 查询与后续连接通过映射关联，路由判断会更直接。
- 大量域名分流：规则包含数千条域名后缀或规则集，需要在连接建立前明确目标域名。
- 共享地址服务：多个站点复用同一组服务地址，仅按 IP 无法稳定区分业务域名。
- 地址频繁变化：服务端通过动态调度返回不同地址，静态 IP 规则很快失效。
- 远端解析需求：代理出站需要保留域名，让节点所在网络完成最终解析。
- UDP 与 QUIC 流量：应用使用 UDP 443 时，可通过 FakeDNS 映射和 QUIC 嗅探补充目标信息。
如果只使用 v2rayN 的系统代理模式，浏览器通常会把目标域名直接提交给本地 SOCKS 或 HTTP 入站。此时核心已经拥有域名，启用 FakeDNS 不一定带来明显收益。是否需要开启，应根据入站类型和日志中显示的目标形式判断。
局域网包含特殊路由时也要谨慎。部分实验室、虚拟化平台或企业设备可能使用 198.18.0.0/15 做性能测试或内部模拟。如果系统路由表已经把这个网段指向真实接口，FakeDNS 地址会与现有网络重叠，表现为连接被发往局域网而没有进入 TUN。
| 使用场景 | 建议 | 判断依据 |
|---|---|---|
| v2rayNG 全局 TUN | 优先测试开启 | 整机应用流量均经虚拟网卡 |
| 按应用代理 | 结合目标应用测试 | 被排除应用的 DNS 不应强制映射 |
| v2rayN 系统代理 | 通常保持普通 DNS | 浏览器可直接提交域名 |
| 仅按 IP 分流 | 通常不必开启 | 规则本身不依赖域名 |
| 局域网使用 198.18/15 | 先更换地址池 | 避免虚拟地址与真实路由冲突 |
结论:系统代理先看入站目标，TUN 模式先看映射完整性
日志已经显示完整域名时，不要为了追求更低的 DNS 数字强行加入 FakeDNS；日志只显示共享服务 IP 且域名规则漏匹配时，再用虚拟映射补齐目标信息。
FakeDNS、嗅探与 TUN 如何配合
TUN 的职责是截获 IP 数据包，FakeDNS 的职责是保存域名与虚拟地址的关系，嗅探的职责是从 HTTP Host、TLS Server Name 或 QUIC 握手中提取域名。三者解决的问题不同。只有把它们按顺序连接起来，域名规则才能覆盖更多应用流量。
建议先建立最小可用链路，再逐项添加高级设置。一次修改地址池、DNS 服务器、路由规则和 MTU，会让故障来源难以区分。以下顺序适合 v2rayNG 的 Xray 内核配置，也适合检查由订阅生成的运行配置。
- 在「设置」→「VPN 设置」确认 TUN 或 VPN 接管已开启，并检查目标应用是否被分应用规则排除。
- 启动连接后查看核心日志，确认存在 TUN 入站，且没有地址冲突、权限失败或接口创建失败。
- 检查运行配置中的
fakedns地址池，并确认 DNS 服务器列表包含 FakeDNS 处理项。 - 确认入站嗅探已启用，
destOverride至少包含fakedns；需要识别网页流量时再保留http、tls和quic。 - 在「设置」→「路由设置」检查规则顺序。阻断规则、私有地址规则和直连规则如果排在前面，可能先于目标域名规则命中。
- 使用一个未访问过的测试域名发起连接，查看日志是否依次出现虚拟地址、恢复后的域名和最终出站标签。
MTU 问题与 FakeDNS 属于不同层级。若域名已经正确恢复，但页面只加载少量内容或大文件停住，应检查 TUN MTU。安卓设备可从 1500 调整到 1400 或 1380 做对照测试，每次只改一个值。若所有域名都无法建立连接，再返回 DNS 捕获和地址池路由继续排查。
Mux 也不会替代 FakeDNS。Mux 负责在一条底层连接中承载多个逻辑连接，主要影响连接复用；FakeDNS 负责保留目标域名。开启或关闭 Mux 不应改变虚拟地址映射是否建立，但可能改变连接数量和日志呈现方式。
常见故障与逐项排查
FakeDNS 故障通常表现为三类：应用收到虚拟 IP 后无法连接、域名规则没有命中、关闭客户端后短时间内仍访问失败。第一类优先检查 TUN 是否捕获虚拟网段，第二类检查映射和规则顺序，第三类通常与系统 DNS 缓存中残留的虚拟地址有关。
开启后所有网页都打不开?
先打开核心日志，确认 TUN 入站已成功创建。再检查系统路由表是否把 198.18.0.0/15 指向 TUN。若该网段被局域网占用，更换不冲突的专用地址池并重启连接。
日志只显示虚拟 IP，没有恢复域名?
检查入站的嗅探开关，并确认 destOverride 包含 fakedns。随后确认 DNS 查询与连接由同一个运行实例处理；分离的 DNS 进程无法共享内存映射。
域名已经恢复，路由规则仍不命中?
进入「设置」→「路由设置」检查从上到下的规则顺序。先临时停用范围过大的直连规则，再查看日志中的最终出站标签，确认规则使用的是完整域名、后缀还是规则集。
断开 v2rayNG 后网站短时间打不开?
系统可能仍缓存 198.18.0.0/15 内的虚拟地址。先关闭并重新打开目标应用；仍未恢复时切换一次网络连接，让系统重新发起 DNS 查询。
部分应用正常，另一些应用完全不走规则?
检查「设置」→「VPN 设置」中的分应用代理范围。被排除的应用不会经过 TUN，其 DNS 查询和后续连接也不会进入 FakeDNS 映射链路。
排查时不要只观察浏览器结果。核心日志至少要核对四个事实：DNS 查询是否进入客户端、是否分配虚拟地址、入站是否恢复域名、路由最终选择哪个出站。四项中缺少哪一步，就回到对应模块修改，而不是同时替换节点和协议。
还要区分“解析快”和“连接快”。FakeDNS 的本地应答可以在数毫秒内完成，但代理节点延迟、TCP 丢包、TLS 握手和服务端响应仍决定页面速度。若虚拟映射与路由均正确，速度问题应继续检查节点延迟、丢包率和传输参数。