V2Ray DNS 泄漏检测与防泄漏设置:v2rayN 远程 DNS 与 FakeDNS 实操

DNS 泄漏是什么：网页出口与解析出口分开看

DNS 负责把域名转换成 IP 地址。网页连接走了代理，不代表查询域名的请求也走了代理。如果原本希望交给代理处理的域名，被应用提前提交给本地网络的解析器，本地网络仍可能获知这些查询。这才是需要修复的路径偏差。

v2rayN 是桌面客户端，具体解析行为取决于当前内核、入站方式与生成的配置。VMess、VLESS 等协议名称不能直接说明 DNS 是否泄漏；仅更换协议，通常不会修正浏览器自行解析或路由顺序错误。

这条流程是排查模型，并非所有请求都严格按同一顺序执行。应用可能先在本机解析；内核也可能为了匹配 IP 规则而先解析。排查时要问两个问题：谁发起查询，以及查询通过哪个出站发送。

• 远程 DNS：承担需要经代理解析的域名查询。服务器位于外地，不等于请求自动通过代理发送。
• 直连 DNS：承担明确允许直连的域名查询，目标是与本地访问路径匹配。
• 浏览器安全 DNS：浏览器自己的加密解析通道，可能绕开系统 DNS 设置，但是否绕开代理还要看它的连接路径。
• 节点地址解析：连接代理服务器之前可能就要完成，不能让它依赖尚未建立的同一条代理连接。

DNS 泄漏检测：先记录基线，再比较代理结果

打开 DNSLeakTest 一类检测页面，运行标准检测或扩展检测，记录解析器的地址、运营网络与地区。检测页通常看到的是最终递归解析器的出口，不一定是电脑直接连接的 DNS 地址；地区数据库也可能有偏差，因此不能只凭“国家不同”下结论。

1. 准备基线：关闭代理和 TUN，重启浏览器，访问一个不涉及敏感信息的 DNS 检测页面。记录此时的公网出口和解析器运营网络。
2. 启用普通代理：启动已确认可用的节点，在 v2rayN 托盘菜单选择「系统代理」→「自动配置系统代理」。不同版本措辞可能略有差异，以实际界面为准。
3. 重复同一测试：先确认网页公网出口已改变，再运行 DNS 检测。尽量保持浏览器、节点、测试页面不变。
4. 隔离浏览器设置：记录当前“安全 DNS”设置，临时关闭后再测一次。不要同时改节点和路由，否则无法确认是哪项操作产生效果。
5. 补测其他应用：浏览器测试通过后，再检查目标应用。系统代理不是全系统流量接管，某个浏览器通过测试不能代表所有程序。

端口与命令验证：区分本机解析和代理解析

先在「设置」→「参数设置」中查看当前本地监听端口与入站类型。下面使用 10808 演示 SOCKS 入站；这不是对所有版本默认值的断言。只有确认该端口支持 SOCKS 后，才使用对应命令。

Windows 可在 PowerShell 中运行以下命令。第一条只验证本地端口是否能建立 TCP 连接；后两条才用于比较域名在哪里解析。使用 curl.exe 可避免部分环境把 curl 当作其他命令的别名。

Test-NetConnection 127.0.0.1 -Port 10808

curl.exe --socks5 127.0.0.1:10808 --connect-timeout 10 -I https://example.com

curl.exe --socks5-hostname 127.0.0.1:10808 --connect-timeout 10 -I https://example.com

• --socks5：由 curl 在本机解析目标域名，再把目标 IP 交给 SOCKS 代理。
• --socks5-hostname：把域名交给 SOCKS 代理，由后续代理链路处理解析；这不单独证明最终使用了哪台 DNS 服务器。
• 只有后一条成功时，优先检查本机解析是否受阻；两条都失败时，先排查节点、监听端口和出站连接。
• nslookup example.com 通常查询系统配置的 DNS，不会因为开启系统 HTTP 代理就自动走 v2rayN。不能单凭它的输出否定浏览器测试结果。

v2rayN 远程 DNS 与直连 DNS：地址和出站一起设置

修改前先备份客户端配置，记录当前节点、路由模式和 DNS 设置。进入「设置」→「DNS设置」查看当前内核对应的选项；若版本将 DNS 放在参数设置页，按实际页面中的 DNS 分组操作。不同内核的配置结构不通用，不要把一段 JSON 同时粘贴到所有内核中。

表中地址用于说明配置关系，不是必须采用的服务列表。远程 DNS 选择 DoH 时，HTTPS 加密只能保护传输内容；如果 DoH 请求直连，本地网络仍能看到你连接了解析服务。若目标是让解析流量也离开本地出口，就要同时核对路由。

1. 先确定范围：排查期间可临时使用客户端提供的全局代理路由模式，减少分流变量。测试完成后恢复日常路由，不要把临时模式误当成最终配置。
2. 设置远程解析：填写当前内核支持的 DNS 地址格式。普通 DoH 与某些内核的本地直连解析模式不是一回事，不能只看到 HTTPS 就认定它经代理。
3. 检查规则顺序：如果存在“境外 IP 直连”或覆盖解析器地址的直连规则，先确认它是否抢先命中。通常规则自上而下匹配，后面的代理规则无法覆盖已经命中的直连规则。
4. 处理节点引导解析：节点使用域名时，为它保留独立、可达的解析方式。不要让节点域名只能通过该节点才能解析。
5. 保存并重启内核：确认日志没有配置错误，再重新做同一组测试。若路由恢复分流后问题重新出现，重点检查域名规则和解析器出站规则。

FakeDNS 与 TUN：解决 IP 入站后的域名识别

FakeDNS 不会为域名直接返回真实服务器地址，而是分配一个合成 IP，并保存域名与合成地址的映射。后续连接到这个地址时，内核才能还原域名并继续处理。它解决的是域名信息传递问题，不是一个独立的加密 DNS 服务，也不能替代代理出站规则。

Xray 常见 FakeDNS IPv4 地址池为 198.18.0.0/15，但应以当前生成配置为准。这个范围用于基准测试，不是真实网站的公网地址。只有请求与后续连接都被同一套支持 FakeDNS 的链路接住，映射才有意义。

1. 先验证基础代理：在未启用 FakeDNS 的情况下完成前面的远程 DNS 测试。不要在节点仍无法连接时同时开启多项高级设置。
2. 确认实现支持：检查当前 TUN 实现及内核是否支持对应的 FakeDNS 或 fake-ip 模式。名称相近不代表配置通用，普通 SOCKS 场景也不必为了检测而强行开启。
3. 启用 DNS 接管：按当前客户端提供的 TUN 与 DNS 接管选项操作。仅启用虚拟网卡，不代表所有 DNS 查询都已交给内核。
4. 核对域名恢复：检查生成配置是否具备 FakeDNS 映射识别能力，必要时核对 FakeDNS 嗅探相关设置。不要把只在普通嗅探中打开 HTTP、TLS 识别当成完整配置。
5. 清缓存后复测：重启受测应用，并按需执行下面的系统缓存清理命令。浏览器可能另有缓存，需要一并重启。

ipconfig /flushdns

浏览器自带 DoH、应用内置 DNS 和 IPv6 是常见遗漏点。只接管 UDP 53 不能自动处理所有 HTTPS 解析请求；如果 IPv6 路由没有纳入接管，应用也可能通过另一条网络路径访问。应按实际支持情况配置 IPv6，或在隔离测试中临时关闭对应网卡的 IPv6 后比较结果，不能把临时关闭当成通用修复。

DNS 设置后打不开网页：按日志定位失败层级

先看日志中的目标地址、使用的出站与失败时间，再看错误关键字。以下是常见错误片段，不代表每次都会出现完整相同的句子。临时提高日志详细程度可以帮助定位，但分享日志前应遮去订阅地址、节点凭据和个人访问域名。

修改后只有部分网站失败，优先排查分流规则和 IPv6；所有网站立即失败，优先检查 DNS 地址格式、节点引导解析以及 TUN 路由。若连客户端都无法正常加载配置，应先回退本次修改，而不是继续叠加规则。

• 回退顺序：恢复 DNS 备份，关闭新增的 FakeDNS 或 TUN 设置，重启内核，再清理缓存。
• 保留证据：记录失败发生在普通代理还是 TUN 模式，以及使用了哪个解析器。
• 控制变量：每轮只改 DNS 地址、出站规则、浏览器安全 DNS 中的一项。

常见问题：检测结果与防泄漏设置怎么判断