当应用先解析域名、再只拿 IP 建立连接时，FakeDNS 可以暂存域名与虚拟 IP 的对应关系，让进入代理核心的连接重新带上域名。下文按查询、映射、嗅探、路由的顺序拆解，并给出 v2rayN 中检查 TUN、DNS 与嗅探的办法；如果只用普通系统代理，也能据此判断是否需要开启。
FakeDNS 解决的是哪段域名丢失
按域名分流的前提是：路由判断时仍然知道目标域名。浏览器通过 HTTP 代理发起请求时，代理通常能直接取得域名；但在 TUN 模式下，应用可能先用系统 DNS 把域名解析为真实 IP，随后向这个 IP 发起连接。TUN 捕获到的是目标 IP，原始域名不一定随连接一同到达核心。此时，即使路由中写了域名规则，也可能只能按 IP 规则继续判断。
FakeDNS 的做法不是替远端网站找出真实地址，而是把一次 DNS 查询变成临时编号：核心向应用返回一个虚拟 IP，并记下“这个虚拟 IP 对应哪个域名”。应用照常连接该地址；连接被核心接收后，再用映射找回域名。后续由路由与出站决定如何处理，不应把 FakeDNS 理解成代理协议或新的服务器节点。
关键条件是两段流量都要进入同一套处理链：DNS 查询进入 FakeDNS，使用返回地址发起的连接也进入能够读取映射的核心。如果查询走了系统外部 DNS，或者连接绕过了 TUN，单独打开一个 FakeDNS 选项不会补回域名。应用若一开始就连接写死的 IP，也不存在可供 FakeDNS 保存的域名。
虚拟 IP 怎样分配，又怎样还原域名
一个常见的 IPv4 虚拟地址池是 198.18.0.0/15。该网段用于网络设备基准测试，不是访问网站时应直接使用的公网目的地址。FakeDNS 从配置的地址池中取出地址，返回给提出查询的应用，并在核心内部保存对应关系。地址池范围、可分配数量和缓存状态都与具体配置及核心实现有关，不能把某个虚拟 IP 当成永久不变的域名标识。
这里的“嗅探”不只指从 TLS 握手或 HTTP 请求里读取域名。支持 FakeDNS 的核心还可以依据先前建立的虚拟 IP 映射，把连接目标还原成域名；HTTP Host、TLS SNI 等常规嗅探方式则是其他可能的域名来源。应用使用的协议、是否加密、是否携带域名信息，都会影响常规嗅探，但不会改变“先收到 FakeDNS 答复、再命中映射”这条链路的基本要求。
判断重点：看连接是否命中映射
日志里只看到 DNS 返回虚拟 IP，还不能证明分流成功。继续检查后续连接是否被同一核心接收，以及路由记录中的目标能否还原为域名；若停在虚拟 IP，就先查 TUN 捕获范围与嗅探设置。
核心重启、映射被清理或应用长期缓存旧的 DNS 答复后，应用可能继续连接一个已经找不到对应域名的虚拟 IP。遇到“刚切换配置就打不开，稍后又恢复”的情况，先让应用重新发起 DNS 查询；必要时关闭并重开该应用，而不是立即修改服务器地址。
在 v2rayN 的 TUN 场景中检查哪些设置
先在 v2rayN 的「设置」→「参数设置」确认当前使用的核心与 TUN 相关选项，再检查 DNS 和流量嗅探配置。不同版本的分组名称及开关位置可能调整，操作时以当前界面字段为准。FakeDNS、DNS 接管、TUN 捕获和嗅探需要配合：只勾选其中一项，不能推断整条链路已经生效。
DNS 查询路径
- 检查入口
- 「设置」→「参数设置」
- 核对项目
- 当前核心、TUN 与 DNS 选项
- 预期现象
- 应用查询由配置中的 DNS 处理
- 异常线索
- 仍收到真实公网 IP
先确定查询进了核心，再检查返回地址是否属于配置的虚拟地址池。
连接与路由路径
- 检查入口
- v2rayN 核心日志与路由设置
- 核对项目
- 嗅探启用、域名规则、出站
- 预期现象
- 连接按还原后的域名匹配规则
- 异常线索
- 日志中仅剩虚拟 IP
路由结果还取决于规则顺序；FakeDNS 负责找回域名，不负责决定走哪条出站。
验证时选一个已明确写进域名分流规则的测试域名，先记录未开启相关功能时的路由结果，再逐项检查 DNS 答复、连接捕获和规则命中。不要只用“网页能打开”作为标准：直连与代理出站都可能打开同一页面。也不要拿内网设备名测试公网域名规则，二者通常走不同的解析路径。
订阅提供的是服务器连接信息，不等于本机 DNS 与 TUN 配置。换一条 VMess 或 VLESS 节点后，FakeDNS 的查询路径仍要在本机核对；节点可用也不能证明域名已经按预期分流。需要定位问题时，保持同一节点不变，逐次只改一个本地设置，日志才容易比较。
哪些流量适合开启，哪些要保留真实解析
FakeDNS 特别适合“应用先解析、TUN 后接管连接”的场景：应用最终只向一个 IP 建连，但路由规则又需要原始域名。它也能减少应用提前取得真实解析结果后，域名信息在进入核心前丢失的机会。不过，它不是所有 DNS 问题的统一解法；上游解析、路由规则和应用自己的 DNS 行为仍需分别检查。
| 流量类型 | 优先检查 | 使用建议 |
|---|---|---|
| TUN 内的公网域名访问 | DNS 查询和连接是否都进入核心 | 需要域名分流时，可测试 FakeDNS 映射 |
| 局域网设备与内部域名 | 本地 DNS、局域网直连规则 | 优先保留真实地址，避免影响内网访问 |
| 直接访问数字 IP | IP 路由规则 | FakeDNS 没有原始域名可还原 |
| 应用自行使用加密 DNS | 应用的解析是否绕过本机 DNS 路径 | 先确认查询入口，不要仅凭系统 DNS 设置判断 |
局域网打印机、路由器管理页和企业内部服务尤其要谨慎。它们可能依赖本地 DNS 返回实际内网地址；如果查询被改成虚拟地址，而后续连接又没有按预期进入核心，访问会直接失败。处理办法是先给这些域名或目标网段安排明确的本地解析与直连路径，再测试公网域名的 FakeDNS，而不是把所有查询一股脑交给虚拟地址池。
结论：按入口决定是否开启
主要使用普通系统代理，且域名规则已经正确命中时，不必为了“多一个 DNS 功能”改变现有解析路径。只有确认 TUN 场景出现域名丢失，再对相应流量测试 FakeDNS，并为本地资源保留独立处理方式。
还有一类情况是应用自行发送加密 DNS 查询，或把请求交给另一个网络组件处理。这时 v2rayN 未必能看到普通 DNS 查询；即使后续连接被 TUN 捕获，也未必有虚拟地址映射可查。排查顺序应从“应用实际把查询发到哪里”开始，而不是先推断 FakeDNS 分配失败。
开启后无法访问：按现象逐项排查
先把故障分为三类：没有虚拟 IP、拿到了虚拟 IP 但连不上、连接成功却没有命中预期域名规则。它们分别对应 DNS 入口、连接捕获与映射、路由匹配。保留一次测试的查询结果和同一时段的核心日志，能避免把不同请求的现象拼在一起判断。
开了 FakeDNS，查到的还是网站真实 IP？
先在「设置」→「参数设置」核对当前核心及 TUN、DNS 选项，再确认发起查询的应用是否使用这条 DNS 路径。查询没有进入 FakeDNS 时，调整嗅探规则不会改变 DNS 答复。
查到 198.18 网段地址，网页却一直转圈？
检查后续 TCP 或 UDP 连接是否被 TUN 捕获，并在核心日志中查找对应请求。如果连接绕开核心，虚拟 IP 无法像真实网站地址那样直接访问；若刚重启过核心，再让应用重新查询一次。
公网网站正常，局域网设备打不开？
检查本地 DNS 与局域网直连设置，让内部域名及内网地址使用真实解析结果。修改后重新查询设备域名，确认返回的是实际内网地址，而不是虚拟地址池中的地址。
域名已经还原，为什么仍走错出站？
到路由设置核对规则内容与优先顺序，确认该域名是否先命中另一条规则。FakeDNS 只补回判断所需的域名；最终出站仍由路由配置决定。
如果问题只发生在某个应用，拿浏览器与该应用对照测试：两者是否使用相同的 DNS 入口，是否都经过 TUN，是否连接相同的域名。不要因为浏览器正常就认定所有应用都会产生相同的查询。若问题只在切换配置后短暂出现，则优先考虑应用缓存了旧虚拟 IP，重新发起查询后再观察。
最后再看节点与协议层。v2rayN 中的 VMess、VLESS 服务器能否连通，与 FakeDNS 映射是否成立是两件事：日志若已经显示域名规则命中、出站也已选定，但请求仍超时，才继续排查节点连接。按 DNS、嗅探、路由、出站的顺序逐层缩小范围，比同时修改订阅、路由和 DNS 更容易找到真正的故障点。