V2Ray DNS 泄漏怎么查:检测步骤与 dns 模块防泄漏写法

DNS 泄漏的判断：看解析路径，不只看地区

DNS 泄漏指本应沿预期代理路径处理的域名查询，实际交给了非预期的解析器。例如网页连接已经走代理，但应用先向路由器查询域名，路由器再转交本地运营商。网页出口地址改变，并不代表解析路径也随之改变。

浏览器的安全 DNS、操作系统的 DNS、V2Ray 内置 dns 可以同时存在。只有请求进入相应处理链，相关设置才会生效。系统代理通常只接管遵循代理设置的应用连接，不等于捕获所有 UDP 查询；在 JSON 中添加 dns.servers，也不会自动接管网卡的 DNS。

• 浏览器自行解析：启用安全 DNS 后，浏览器可能直接向自己指定的 DoH 服务查询，不使用系统解析器。
• 系统先行解析：应用先取得 IP，再把连接交给代理。此时内核收到的可能只有 IP，无法撤回已经发出的查询。
• 内核按需解析：路由 IP 匹配、部分出站连接或 DNS 入站转发可以触发内置解析，但不保证覆盖其他进程。

检测步骤：建立直连与代理两组对照

测试时固定浏览器、网络和检测服务。每轮记录网页出口 IP、解析器 IP、浏览器安全 DNS 状态、客户端路由模式。以下是操作方法，不是本站实测结果；不要把某一轮解析器数量当作通用合格线。

1. 记录基线

   暂时退出代理连接，运行一次浏览器 DNS 泄漏检测，记下解析器地址及运营方。共享办公网络或单位设备先确认是否允许修改网络设置。

2. 固定浏览器

   在浏览器「设置」内搜索「安全 DNS」，记录当前状态。排查时可临时关闭以隔离浏览器自带解析，完成后恢复原设置；不要同时修改系统 DNS。

3. 启用代理

   启动 v2rayN，在托盘菜单「系统代理」中选择「自动配置系统代理」，确认活动服务器及路由模式。重新打开检测页，发起新一轮测试。

4. 清理缓存

   Windows 终端运行 ipconfig /flushdns，随后完全退出并重开浏览器。此命令只清理系统缓存，不能代替清理浏览器自身缓存。

5. 逐项复测

   每轮只改一个变量：先浏览器解析，再内核 DNS，最后接管方式。至少重复两轮；若结果不稳定，保留时间和日志，避免把旧缓存误判为新配置生效。

命令行可以辅助判断请求入口。下面使用示例 SOCKS 端口 10808，实际端口以客户端为准。--socks5-hostname 把目标域名交给 SOCKS 代理；它能验证这条应用连接的域名交接方式，但不能证明全系统没有旁路 DNS。

curl.exe --proxy socks5h://127.0.0.1:10808 https://example.com/ --head
ipconfig /flushdns
Resolve-DnsName example.com -Type A

最后一条命令在 PowerShell 中运行，通常走系统 DNS 路径，不会因为设置了 HTTP 系统代理就自动交给 V2Ray。它与浏览器结果不同，恰好说明两者入口不同；不能直接据此判定内核配置失效。

端口与协议：区分本地代理、DNS 和 DoH

不要把网卡 DNS 直接改成 127.0.0.1，除非确实已有本地 DNS 服务监听对应端口。SOCKS 监听与 DNS 监听不是同一种协议：把查询发送到 10808 不会自动获得 DNS 应答。客户端也可能使用混合监听，仍需按当前生成配置判断。

dns.servers 写法：给解析流量明确的代理路由

下面是 V2Ray/Xray 风格的合并片段，用于演示远程 DoH 与 DNS 流量标签。前提是当前内核支持这些字段，且现有 outbounds 中已有名为 proxy 的可用代理出站。若实际标签不同，必须改成实际值。不要将该片段作为完整配置启动。

{
  "dns": {
    "tag": "dns-query",
    "servers": [
      "https://1.1.1.1/dns-query"
    ],
    "queryStrategy": "UseIPv4"
  },
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "inboundTag": ["dns-query"],
        "outboundTag": "proxy"
      }
    ]
  }
}

• dns.tag：为内置 DNS 发起的查询流量提供路由标识。这里用 inboundTag 匹配 dns-query，不是另建一个 SOCKS 入站。
• servers：示例使用 IP 形式的 DoH 地址，减少解析 DNS 服务自身域名的引导环节。服务可达性仍需在当前网络和代理路径下验证。
• queryStrategy：UseIPv4 将内置 DNS 查询限制为 IPv4，便于先排除 IPv6 路径差异；双栈环境确认配置后可评估 UseIP。
• 规则位置：将这条精确 DNS 规则放在宽泛直连规则之前，保留现有其他规则。若前面的规则已经匹配，后面的 DNS 代理规则不会补救。

DoH 加密的是客户端到解析服务的查询连接；它是否经代理，还取决于路由。部分内核支持名称带 +local 的本地处理模式，其路由行为与普通远程模式不同，不能为了“更快”直接替换本例。需要分流解析时，再增加域名限定的上游规则，并检查回退解析是否会使用非预期服务。

domainStrategy：路由解析与出站解析分别检查

domainStrategy 不是一个全局防泄漏开关。相同键名位于不同对象时，控制的是不同阶段。排错时必须连同 JSON 层级一起看，不能只搜索键名并批量替换。

AsIs 只约束路由阶段，不代表目标连接永远不解析。请求若最终进入直连出站，仍需获得目标地址；请求若以域名形式交给代理端，通常由远端继续处理。保留国内站点直连时，也应先定义这些站点的解析策略，而不是把所有本地 DNS 请求一律当成故障。

FakeDNS：地址映射不能代替流量接管

FakeDNS 返回的是保留地址池中的映射地址，而不是真实目标地址。内核保存域名与映射地址的关系；后续连接必须回到同一个处理链，再通过映射恢复域名。它适合具备 DNS 接管和连接回收能力的环境，不适合只复制一个字段就启用。

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

这是支持 FakeDNS 的 V2Ray/Xray 内核的概念片段，不包括 DNS 入站、转发和系统路由。需要恢复映射的既有入站，还应按内核能力合并以下嗅探设置；不要为此创建一个无法被实际流量命中的空入站。

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

• DNS 必须进入内核：仅在 JSON 中设置 "servers": ["fakedns"]，不会让 Windows 网卡自动向它查询。
• 映射连接必须回收：198.18.0.0/15 不是公网网站地址。若系统把它直接送向物理网关，常见结果就是网页超时。
• 路由需要一致：确认该地址池没有与现有网络规划冲突，且由当前接管链处理；不要把它加入直连绕过列表。
• 切换后清缓存：关闭 FakeDNS 或重启导致映射丢失后，旧缓存里的映射地址可能失效，应重新查询并建立连接。

v2rayN 可管理不同内核；TUN 模式的 DNS 接管也可能由另一套配置结构实现。先确认实际运行内核，再决定是否使用上述 V2Ray/Xray 写法。其他内核的 TUN DNS 页面不能直接粘贴这段 JSON。

v2rayN 设置位置与常见报错

桌面端先检查「设置」→「参数设置」中的本地监听端口，再打开「设置」→「DNS 设置」检查当前内核对应的 DNS 项；部分版本将 DNS 入口收在参数设置内，字段也会随内核变化。保存后重新启动服务，并在运行日志中确认实际内核和配置加载结果。客户端更新、订阅更新或切换配置后，都应再核对生成配置是否仍保留修改。

排查系统代理时使用托盘菜单「系统代理」；排查 DNS 接管时检查主界面的「TUN 模式」及其设置，两者不是同一个开关。TUN 可能需要提升权限，也可能与现有虚拟网卡冲突，修改前记录原状态。不要同时开启多套接管程序来比较结果。

安卓端也要区分内核：v2rayNG 使用 Xray，v2flyNG 使用 V2Fly。系统 VPN 接管、应用绕过列表与安卓「私人 DNS」都可能改变解析路径，桌面系统代理的结论不能直接套用。相同节点在两端结果不同，先比较入口与解析器，而不是直接判断节点有问题。

• 修复完成的依据：重复检测时，受测应用只出现预期解析器；日志中的 DNS 流量选择了预期出站。
• 保留分流的依据：直连域名与代理域名分别验证，既检查解析结果，也检查对应网页能否建立连接。
• 系统级验证：若目标是覆盖更多应用，需另外核查 UDP/TCP 53、浏览器加密 DNS 和 IPv6 路径，单个网页检测不能覆盖全部进程。
• 回退方式：保存修改前配置，每次只变更一个层级；异常时恢复该项、重启服务并清理缓存，避免在多个错误设置上继续叠加。