代理 DNS 与分流：远程解析、Fake-IP 和泄漏怎么判断

“节点延迟正常，域名却打不开”常发生在解析链路和访问链路不一致时。DNS 负责把域名变成可连接的地址，代理规则再决定连接去哪里；有的规则还需要先拿到解析结果。要解决这类问题，先确定失败发生在哪一步，再改相应设置。

开始前保存当前配置，并记下客户端与内核版本、当前模式、本地代理端口、一个失败域名和一个正常域名。整个过程中固定同一节点，每次只改一项。

一次访问里，可能有三次不同的解析

解析对象	为什么要查	常见处理位置
代理节点域名	客户端要先找到入口服务器	系统 DNS 或内核专用的节点域名解析器
DNS 服务域名	使用域名形式的 DoH/DoT 前，要先找到解析服务器	引导解析器，即 bootstrap DNS
目标网站域名	决定目标地址，或辅助规则匹配	应用、内核 DNS、代理服务端等

这三类查询不能混成一条。“先通过代理访问 DNS，代理节点又必须由同一个 DNS 解析”会形成循环：还没连上节点就要求使用节点。mihomo 的 proxy-server-nameserver、引导 DNS 以及其他内核的相应机制，就是为区分这些依赖准备的。具体字段必须按所用内核版本核对，不能直接把 mihomo YAML 粘贴进 sing-box JSON。

本地解析、远程解析与加密 DNS 的区别

• 本地解析：应用或本机内核取得目标 IP，再发起连接。查询可能走系统、局域网或单独配置的解析器。
• 代理端解析：应用把域名交给代理端，而不是先取得 IP。若该代理端就是本机客户端，之后仍由本机内核决定解析方式；只有继续把域名交给远端出站，才可能由远端解析。
• DoH/DoT：给 DNS 查询本身加密。它们不自动规定走直连还是代理，也不会让解析服务商看不到所查询的域名。
• Fake-IP：内核先返回虚拟 IP 并保存域名映射，后续连接再结合规则处理。虚拟 IP 不是目标网站的公网地址。

因此，socks5h 的“代理端解析”与“查询一定从境外出口发出”不是同一个承诺。你还必须看本地代理内核使用了什么 DNS 和出站。

第一步：确认请求确实进入代理

打开客户端连接记录，访问失败域名，查看是否出现目标域名或目标连接，以及命中的规则和出站。没有记录时，先处理 系统代理与流量接管，此时换 DNS 未必触及问题。

浏览器的“安全 DNS”、Android 私人 DNS、应用自带 DoH 可能使用自己的解析通道。普通端口 53 的 DNS 接管无法自动理解所有加密 DNS 请求；它们的连接是否被 TUN 接管，又是另一个路由问题。诊断时可以临时停用其中一项，对照后恢复原设置，避免把多套解析结果混在一起。

第二步：做同一域名的解析对照

系统查询可以先用以下命令；example.com 是可替换的公开测试域名：

nslookup example.com

记录服务器、返回地址或超时。这个结果只说明该命令的解析路径，不能代表浏览器或代理内核也在用它。

内核若已经启用独立 DNS 监听，还可直接向它的实际地址、端口查询，并与系统结果分别记录；具体命令见 DNS 故障排查中的监听验证。这一步验证的是内核能否回答查询，查询经哪个出站发送仍需查内核配置和日志。

若客户端提供 SOCKS5 或 mixed 端口，可以对照下面两次请求。把 7890 换成客户端实际监听的端口；Windows PowerShell 使用 curl.exe，防止命中同名别名。

curl -q --noproxy localhost --proxy socks5://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com
curl -q --noproxy localhost --proxy socks5h://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com

第一条让 curl 本地解析目标，第二条把域名交给 SOCKS 代理端。--noproxy localhost 覆盖环境中的绕过列表，以上测试目标是公开网站，不是 localhost。两者均使用相同节点和 URL，并保留 HTTPS 证书验证。若目标不接受 HEAD 请求，去掉 -I 重新对照，不要把 HTTP 方法错误误判为 DNS 故障。

对照结果	可以得出的线索	仍需确认
本地解析失败，交域名给代理端成功	应用本地解析路径可能有问题	内核的解析器、规则及日志是否符合预期
两条都无法连到 127.0.0.1	本地端口未监听或填错	内核状态、端口、是否提供 SOCKS5
两条都报代理连接或认证失败	可能尚未到目标解析阶段	先排查节点与认证
两条都收到 HTTP 响应	这一目标的基本解析与访问成立	浏览器专有设置、缓存、IPv6 或其他失败域名

不要直接把网站 IP 粘到 HTTPS 地址栏作最终判断：证书名、SNI、虚拟主机和 CDN 选择都可能变化，得到的不是同一次访问。

第三步：检查 DNS 与规则是否一致

1. 看目标查询发给谁。 在内核 DNS 日志或配置中确认目标域名的解析器与策略。代理域名和本地域名可以按设计使用不同解析器。
2. 看查询连接走哪里。 “配置了境外 DNS 地址”不代表查询经代理。mihomo 可通过 DNS 指定代理或相关路由选项处理，但需要同时解决节点域名的引导解析。
3. 看是否存在映射脱节。 Fake-IP 模式下，DNS 返回虚拟 IP 后，连接应回到保存该映射的内核。多个代理同时运行、切换配置后沿用旧缓存，都可能造成失配。
4. 核对 A 与 AAAA 路径。 IPv4 正常而 IPv6 失败时，要比较两类地址的接管和出站。仅收到 AAAA 记录并不能证明泄漏；只在故障定位需要时暂时作 IPv4 对照。
5. 应用改动后重试。 重载当前配置，关闭旧连接，必要时清理受影响的 DNS 缓存，再验证同一域名。保留正常域名作为对照。

若是公司内网、打印机或 .lan 域名，只能由局域网 DNS 回答时，应保留对应的直连解析策略；把所有查询一律交给公共解析器，反而会破坏这些功能。

怎样判断 DNS 泄漏

先写下预期，例如“代理域名的 DNS 查询应经选定节点访问指定解析器；局域网域名由本地解析”。只有违背这个预期的查询，才有明确的泄漏含义。

第三方 DNS 检查页可以提供解析器线索，但其显示位置可能来自 IP 数据库、任播节点或转发解析器。它无法覆盖其他应用、历史缓存、所有 IPv6 流量，也无法单独证明查询经过哪条隧道。应结合内核日志、受控域名查询与开启/关闭特定设置的对照；需要更强证据时，在自己控制的网络接口上观察实际查询流量。

不要公开包含完整订阅地址、节点认证或私人浏览域名的日志。提交排障信息时保留时间、错误类型、查询路径和脱敏目标即可。

验收与恢复

修复完成后，失败域名应连续可访问，连接记录应显示预期规则，内网域名也应仍可用；退出客户端后，系统应恢复正常直连解析。若新设置让更多网站失败，恢复备份配置和临时更改的浏览器 DNS 设置，重新从“请求是否进入内核”开始检查。

已有明确 DNS 报错时，继续阅读 代理 DNS 解析失败排查；需要理解系统代理、规则、全局和 TUN 的关系时，进入 代理模式详解。