V2Ray DNS 泄漏怎么检测:远程 DNS、FakeDNS 与 TUN 组合的防泄漏配置实操

本文速览

适合已经导入订阅、能够访问网站，却发现 DNS 检测结果异常的用户。先区分正常直连解析与意外绕行，再用系统查询、内核日志和网卡抓包交叉验证；随后配置远程 DNS 与直连 DNS 的分工，最后检查 TUN 接管范围及 FakeDNS 的域名还原链路。示例配置是内核片段，不是可直接替换客户端配置的完整文件。

1. DNS 泄漏是什么：解析出口与访问出口不一致

DNS 负责把域名转换为 IP 地址。代理连接已经建立，不代表此前的域名查询也经过代理。例如，应用先向家庭路由器查询目标 IP，再把连接交给本地代理端口，网页看起来通过了代理，但本地解析器仍可能知道访问过的域名。判断是否泄漏，要看查询是否违背预先设定的分流策略，而不是看到本地解析器就立即判错。

应用查询域名解析规则匹配选择查询出口返回目标地址连接规则匹配

如果国内网站按策略直连，使用直连 DNS 通常是合理的；如果某个域名应当通过代理访问，其查询却发往本地网络的解析器，才是本篇要堵住的绕行。VMess、VLESS 负责代理传输，并不会自动接管系统里所有 DNS 请求。订阅提供节点配置，也不等于提供完整的本机 DNS 策略。

工作方式	容易遗漏的解析路径	检查重点
系统代理	不读取系统代理的程序仍使用系统 DNS	应用是否先在本地解析、是否使用自己的 DNS
SOCKS 代理	应用只提交 IP，没有把域名交给代理	应用是否开启代理端解析域名
TUN 接管	排除路由、IPv6 或自带加密 DNS 绕行	虚拟网卡、DNS 劫持与出口规则是否同时生效

2. DNS 泄漏怎么检测：建立基线，再检查真实网卡

浏览器检测页面显示的是它观察到的递归解析器出口，不一定是客户端直接连接的服务器。公共 DNS 可能使用不同地区的出口；页面显示的城市也可能来自过时的地址库。因此，不要把“解析器城市与节点城市不同”当作唯一证据。需要同时确认查询走哪张网卡，以及是否符合当前规则。

传统 DNS 的 UDP/TCP 端口

443

DoH 常用 HTTPS 端口

853

DoT 常用 TLS 端口

保存基线。关闭 TUN 和系统代理，记录系统 DNS 地址、浏览器安全 DNS 状态及检测页面列出的解析器。测试期间不访问敏感站点。
固定变量。开启同一个节点与同一套路由，再测试同一个页面。不要一边切节点，一边更改浏览器 DNS，否则无法定位是哪项设置改变了结果。
清理缓存。Windows 在终端执行 ipconfig /flushdns，关闭并重新打开浏览器。内核自带的 DNS 缓存通常还需要通过重启内核清除。
检查系统查询。运行下面的命令，记录默认解析器和查询结果。该结果用于观察系统解析路径，不代表浏览器一定使用相同路径。
检查物理网卡。在抓包工具中选择正在联网的以太网或无线网卡，观察目标查询是否直接发往本地解析器；虚拟网卡里出现 DNS 包，本身不代表它已经离开设备。

ipconfig /all
ipconfig /flushdns
nslookup example.com

# 抓包显示过滤器：检查传统 DNS 与常见 DoT 连接
udp.port == 53 || tcp.port == 53 || tcp.port == 853

example.com 是用于演示查询方法的示例域名，不是泄漏检测服务。正式复测应选择一个按你的规则明确走代理的域名。浏览器自带 DoH 使用 HTTPS，不能只靠端口 53 的过滤器识别；需要结合其安全 DNS 配置、连接目的地址和客户端路由日志判断。

结论：用“目标域名是否绕行”判断，不用解析器数量判断

先挑选一个明确走代理的测试域名。如果物理网卡上仍出现向本地解析器发送的该域名明文查询，就沿系统 DNS、应用 DNS 和 TUN 排除规则逐项排查；出现多个公共解析器出口，则先核对它们是否来自同一个服务。

3. v2rayN 远程 DNS 与直连 DNS：配置解析器，也配置出口

在 v2rayN 中先进入「设置」→「参数设置」，确认当前内核与监听配置；再打开「设置」→「DNS 设置」核对对应内核的 DNS 配置。不同版本的入口位置和字段名称可能不同，应以当前界面及生成的配置为准。尤其要区分普通代理使用的内核与 TUN 使用的内核，不要把一份 DNS JSON 填进另一个内核的配置区。

远程 DNS 用于需要代理访问的域名，直连 DNS 用于明确直连的域名。配置远程解析器只是第一步：若连接解析器的请求仍走直连，即便采用加密查询，也没有达到“解析随代理出口走”的目标。DoH 保护的是到解析器这段连接，不会自动替你选择代理出站。

先解决引导解析。节点服务器如果使用域名，需要在代理连接建立前得到可用 IP。为节点域名单独安排可达的引导解析路径，避免“连接代理才能解析节点、解析节点才能连接代理”的循环。
限制直连解析范围。只将明确直连的域名分配给直连解析器，不要把它作为所有查询失败后的无限制兜底。
检查规则顺序。解析器的出口规则应放在可能提前命中的宽泛直连规则之前；路由通常按顺序匹配，先命中的规则决定去向。

Xray DNS 片段：直连域名独立匹配，其余使用远程查询

下面以 Xray 配置格式演示。需要已有 geosite.dat 支持 geosite:cn 分类；若缺少规则数据，应先修复数据文件或改用自己的明确域名列表。示例地址仅用于说明分工，其可达性需要在当前网络验证。disableFallbackIfMatch 限制已匹配域名组失败后转向其他解析器，但不能约束浏览器或应用自行发起的查询。

{
  "dns": {
    "queryStrategy": "UseIP",
    "disableFallbackIfMatch": true,
    "servers": [
      {
        "address": "223.5.5.5",
        "domains": ["geosite:cn"],
        "skipFallback": true
      },
      {
        "address": "https://1.1.1.1/dns-query"
      }
    ]
  }
}

还要把以下规则合并到现有 routing.rules 中，而不是替换整份路由。这里假定配置中确实存在名为 proxy 和 direct 的出站；客户端生成的标签若不同，必须使用真实标签。示例按解析器 IP 选择出口，会影响发往这些 IP 的其他连接，正式配置应结合现有规则评估。

{
  "routing": {
    "rules": [
      {
        "type": "field",
        "ip": ["1.1.1.1/32"],
        "outboundTag": "proxy"
      },
      {
        "type": "field",
        "ip": ["223.5.5.5/32"],
        "outboundTag": "direct"
      }
    ]
  }
}

4. TUN 模式防泄漏：接管流量之后，还要处理 DNS 与 IPv6

TUN 把系统流量引入虚拟网卡，适合处理不读取系统代理的应用。但它不是一个“所有请求必走代理”的开关：最终走直连还是代理，仍由路由决定。DNS 是否被拦截并送入受控解析流程，也取决于 TUN 配置。先保存现有参数，再在 v2rayN 主界面开启「启用 TUN」，按系统要求授予权限，并查看启动日志。

确认虚拟网卡建立。如果内核启动失败，先处理权限、驱动或配置错误，不要继续调整 DNS 来掩盖启动故障。
确认 DNS 接管。检查 TUN 配置是否包含适用的 DNS 劫持或重定向规则，再用系统查询与抓包验证。只修改网卡 DNS 地址，不足以控制应用硬编码的解析器。
核对路由排除。局域网访问可按需求直连，但要确认排除范围没有顺带放走需要代理的 DNS 请求。远程解析器地址也不能被宽泛的直连规则提前命中。
同时检查 IPv6。IPv4 已进入 TUN，不代表 IPv6 也已接管。检查 IPv6 默认路由及 DNS 服务器；不需要 IPv6 时，可在明确影响范围后暂时关闭它做对照，而不是把关闭 IPv6 当成通用修复。
验证重连与休眠恢复。切换无线网络、恢复休眠后再次查询。网卡 DNS、系统路由和虚拟网卡状态可能已经变化。

v2rayN 的 TUN 实现可能使用 sing-box 内核，其 DNS 与 FakeIP 配置结构不同于 Xray 的 FakeDNS；应通过对应设置或对应内核格式配置。v2rayNG 使用 Xray，v2flyNG 使用 V2Fly，但安卓 VPN 接管、应用排除和 DNS 行为仍受客户端配置影响。桌面 JSON 不能直接当作安卓界面参数照填。

结论：优先验证接管范围，再增加解析功能

先证明目标应用的 IPv4、IPv6 和 DNS 查询都进入预期处理链，再考虑 FakeDNS。若只有浏览器正常而其他程序仍绕行，重点检查应用排除、硬编码解析器与代理端解析选项，而不是反复更换节点。

5. FakeDNS 怎么配：假地址必须在同一链路还原成域名

FakeDNS 不直接返回网站的真实 IP，而是返回地址池中的映射地址。应用随后连接这个地址时，内核通过映射恢复原始域名，再执行域名路由与代理连接。它能减少提前获取真实 IP 的需求，但不是加密 DNS，也不能单独保证没有泄漏。节点域名引导解析、直连目标和不受控的应用 DNS 仍需要另外处理。

查询目标域名分配映射地址应用发起连接内核还原域名匹配代理规则

以下为支持该功能的 Xray 内核示意片段。198.18.0.0/15 是常用于此类映射的基准测试地址范围，不是网站真实地址；使用前检查它是否与局域网、其他 VPN 或现有路由冲突。poolSize 表示映射池容量，不表示网速或并发连接能力。

{
  "fakedns": [
    {
      "ipPool": "198.18.0.0/15",
      "poolSize": 65535
    }
  ],
  "dns": {
    "servers": ["fakedns"]
  }
}

接收后续连接的相关入站还需具备 FakeDNS 域名还原能力，例如为该入站配置下面的嗅探字段。应合并到已有入站对象中，不能作为独立入站使用。这只是“生成映射与还原映射”的演示，还没有包含 DNS 流量接入、节点引导解析及直连域名的例外规则。

{
  "sniffing": {
    "enabled": true,
    "destOverride": ["fakedns"],
    "metadataOnly": true
  }
}

地址池必须被接管。应用拿到映射地址后，连接不能从物理网卡直接发出；否则它会尝试访问一个并不存在的公网目标。
映射与连接要能对应。不能让一个独立实例生成映射，再把连接交给没有该映射信息的另一个实例。
直连流量还需真实解析。恢复出域名后，直连出站可能仍需查询真实 IP，这一步也要按直连 DNS 策略执行。
重启后清缓存。内核重启可能丢失旧映射，而应用仍缓存旧地址。清理系统与应用缓存，再重新查询，避免把过期映射误认为节点故障。

6. 常见 DNS 报错：先确定失败在哪一层

下面列出日志中可能出现的错误片段。完整前缀和措辞会随内核版本变化，单条错误只能帮助定位方向。复测时一次只改一项，并记录错误来自节点连接、远程解析器连接，还是目标网站连接。

报错:`failed to lookup ip for domain`

原因与解法:域名查询没有得到可用地址——先确认失败域名是节点地址还是访问目标，再检查对应 DNS 的可达性、域名匹配规则及 IPv4/IPv6 查询策略。

报错:`context deadline exceeded`

原因与解法:操作在期限内没有完成，并非 DNS 独有错误——结合相邻日志确认是否发生在 DNS 查询，随后检查解析器出口、连接超时和引导解析循环。

报错:`network is unreachable`

原因与解法:当前网络没有通向目的地址的可用路径——核对错误中的 IP 地址族、TUN 路由和出站接口，特别检查只有 IPv6 查询结果而网络没有 IPv6 路径的情况。

报错:`no such host`

原因与解法:所调用的解析路径未能解析主机名——核对域名拼写、系统解析器和节点引导路径，不要仅凭这段文字认定远程 DNS 被阻断。

7. 复测问答：浏览器正常，不代表整机正常

检测页面还显示本地解析器，一定泄漏了吗？

不一定。先确认该次测试域名是否按规则直连，并核对浏览器安全 DNS 设置。若它明确应该走代理，再在物理网卡上查找对应明文查询；计划内的国内域名直连解析不应算作同一种故障。

开启 DoH 后，为什么解析出口还是本地网络？

DoH 只改变查询传输方式。检查远程解析器的 HTTPS 连接是否命中代理出站，是否被浏览器自行建立，以及是否使用了绕过内核路由的查询方式。先修正出口，再重新测试。

启用 TUN 后，订阅更新反而失败了怎么办？

检查订阅地址和节点地址的引导解析。临时恢复之前可用的 DNS 与路由，确认更新能完成，再逐项启用新设置；不要让订阅更新依赖一个尚未建立、又需要同一解析路径才能建立的代理连接。

FakeDNS 开了以后，部分软件一直超时？

先重启内核并执行 ipconfig /flushdns，然后重启目标软件。检查它连接的映射地址是否进入具备还原能力的入站；若仍不兼容，将该应用或域名改为真实解析，再验证其解析出口。

怎样确认修复后不会在换网络时失效？

分别在当前网络、切换网络后和休眠恢复后复测。每次记录系统 DNS、TUN 状态、一个代理域名及一个直连域名的结果，同时检查 IPv6；单次浏览器测试只能证明当时那条请求链路。

最终验收应形成闭环：代理域名使用受控解析路径，远程解析器连接命中预期出站，直连域名按策略解析，节点地址能够独立完成引导，TUN 与 IPv6 接管范围清楚。需要核对基础配置时，可查看订阅导入指南、DNS 配置文档和TUN 模式说明。