v2rayN DNS 设置详解:境内外域名分开解析与防污染配置方案

先区分系统 DNS、内核 DNS 与远程解析

先在 v2rayN 中打开“设置”→“参数设置”，确认当前启用的核心类型、系统代理模式与 TUN 状态。DNS 分流是否生效，不只取决于填写了哪个服务器，还取决于域名请求有没有进入 Xray 内核。普通系统代理主要接管应用的 HTTP 或 SOCKS 流量，部分应用仍会直接调用操作系统 DNS；TUN 模式则能覆盖更多网络请求，但需要同时检查 DNS 劫持和路由规则。

系统 DNS 是网络适配器或操作系统当前使用的解析器。内核 DNS 是生成配置中顶层的 dns 对象，负责按域名规则选择解析服务器。远程解析表示查询经代理出站送到目标解析器，而不是单纯把服务器地址改成境外地址。若查询报文仍通过直连出口发送，填写远程服务器并不等于已经远程解析。

配置境内本地 DoH 与境外远程解析

先为境内域名准备一个低延迟的本地 DoH，再为其余域名准备一个需要经过代理访问的远程 DoH。分流依据应使用域名集合，而不是等解析完成后再按返回 IP 判断；前者能在发出查询前选定解析器，避免境外域名先向本地解析器暴露并取得异常结果。

1. 打开“设置”→“参数设置”，确认 Xray 核心处于启用状态，并记录本地 SOCKS 监听端口。常见默认值为 10808，实际值以当前参数页为准。
2. 进入 v2rayN 的 DNS 设置页面，选择与当前核心对应的配置区域。版本界面名称可能略有差异，修改后应查看生成的运行配置，而不是只看编辑框内容。
3. 把境内 DoH 服务器绑定到 geosite:cn 一类域名规则，并用 geoip:cn 约束预期返回地址。
4. 把远程 DoH 放在后续匹配位置，作为境外域名和未命中域名的解析器；同时确保该 DoH 域名或目标连接经过代理出站。
5. 保存配置并重启核心。先测试一个明确的境内域名，再测试一个境外域名，避免只凭单个站点下结论。

下面片段展示 Xray dns 对象的核心结构。它是结构示例，不应直接覆盖 v2rayN 自动生成的完整配置；实际使用时应通过客户端的自定义 DNS 区域合并，并保留已有的日志、入站、出站与路由部分。

{
  "dns": {
    "queryStrategy": "UseIP",
    "disableCache": false,
    "hosts": {
      "dns.local.example": "223.5.5.5"
    },
    "servers": [
      {
        "address": "https://dns.alidns.com/dns-query",
        "domains": [
          "geosite:cn"
        ],
        "expectIPs": [
          "geoip:cn"
        ],
        "skipFallback": true
      },
      {
        "address": "https://1.1.1.1/dns-query",
        "domains": [
          "geosite:geolocation-!cn"
        ]
      },
      "https://1.1.1.1/dns-query"
    ]
  }
}

queryStrategy 为 UseIP 时，核心可按可用网络请求 A 与 AAAA 结果；若本地网络没有稳定 IPv6，却强制使用 IPv6 查询策略，可能出现解析成功但连接超时。只使用 IPv4 的环境可根据当前核心支持情况选择对应策略，但不要把查询策略和路由出站混为一项。

让远程 DNS 查询确实经过代理出站

远程 DoH 本质上仍是一条 HTTPS 连接。若其目标地址被路由规则送往直连出站，查询就会从本地网络发出。处理方式是在路由设置中明确远程解析器域名的代理方向，同时避免把本地 DoH 也一并送入代理，保持境内查询的低延迟。

• 在“设置”→“路由设置”中检查自定义规则顺序，远程 DoH 域名的代理规则应位于宽泛直连规则之前。
• 本地 DoH 域名可按 geosite:cn 或明确域名设置为直连，连接端口通常为 443。
• 传统 DNS 若使用 UDP 53，需要确认 TUN 与防火墙没有让报文绕过内核；DoH 使用 HTTPS，更便于随普通 TCP 流量应用路由规则。
• 订阅节点中的服务器地址如果是域名，需要保留可用于建立首次连接的基础解析路径，否则会形成“必须先连代理才能解析节点、必须先解析节点才能连代理”的循环。

排查时打开 v2rayN 的日志窗口，把核心日志级别临时调整到可观察 DNS 与路由命中的级别。随后清理系统缓存，依次访问测试域名。关注的信息包括查询类型、命中的 DNS 服务器、路由出站标签、返回地址和超时原因。测试完成后可恢复较低日志级别，减少日常输出。

处理 hosts、fakeDNS 与缓存的优先级

hosts 用于在进入常规 DNS 查询前覆盖指定域名。适合固定内部服务地址、临时绕过失效解析或把一个域名映射到另一个域名。它不适合维护频繁变化的大型站点地址，因为固定 IP 可能绕过就近调度，也可能在服务端地址变化后导致连接失败。

fakeDNS 常用于 TUN 场景。它先向应用返回一个合成地址，常见地址池位于 198.18.0.0/15，内核随后根据合成地址找回原始域名并执行路由。这样可以保留域名信息，减少应用先在系统层完成真实解析后只交给内核一个 IP 的情况。是否启用应以当前 TUN 配置和核心支持为准。

缓存会保存解析结果直到 TTL 到期，从而减少重复查询和页面首开等待。修改 DNS 规则后若仍看到旧结果，可能不是新配置无效，而是系统缓存、应用缓存和内核缓存中的任意一层仍保存旧记录。应先重启核心，再清理操作系统 DNS 缓存，并完全关闭后重新启动用于测试的应用。

hosts 覆盖

在常规服务器查询前返回指定地址或别名。适合少量、明确、可维护的域名映射。

fakeDNS

向应用返回合成地址，并在内核中保留原域名映射。主要解决 TUN 流量中的域名识别问题。

DNS 缓存

按 TTL 复用已有结果。能降低延迟，但会让配置变更后的旧结果暂时继续出现。

{
  "dns": {
    "hosts": {
      "internal.example": "192.168.10.20",
      "alias.example": "target.example"
    },
    "disableCache": false,
    "disableFallback": false
  }
}

配置 hosts 后，应分别检查域名解析和实际连接。解析结果正确但网页打不开，可能是目标服务要求正确的 TLS 域名、反向代理入口或特定端口；hosts 只改变地址选择，不会改写证书校验、HTTP Host 或服务端监听配置。

按现象定位解析失败与规则未命中

先把问题拆成“没有发出查询”“查询走错出口”“返回结果不符合预期”和“解析正确但连接失败”四类。不要只用网页能否打开判断 DNS，因为 TLS 握手、路由规则、节点状态和目标服务也会产生相同表象。

命令行测试可以提供辅助证据，但 nslookup 默认询问系统 DNS，不一定经过 Xray 内核。它适合检查操作系统当前解析器，不适合单独证明远程 DoH 路径。验证内核分流时，应把命令结果、v2rayN 核心日志与网络出口观察结合起来。

1. 记录修改前的 DNS 设置、路由模式、核心类型和监听端口。
2. 每次只改一个变量，例如先调整解析器，再调整路由规则。
3. 重启核心并确认没有 JSON 解析错误、端口占用或 DNS 初始化失败。
4. 使用一个境内域名和一个境外域名分别测试，记录命中服务器与出站标签。
5. 最后恢复正常日志级别，并保存可工作的配置副本。