DNS 分流需要同时确定“谁解析域名”和“查询经哪条出站发送”。本文面向已经能连接节点、但遇到解析超时或域名分流异常的用户,使用 V2Ray 风格 JSON 说明字段关系、配置合并与验证步骤。示例是配置片段,不是可直接启动的完整客户端配置;使用 Xray 内核时,还要以当前内核支持的字段为准。
一、DNS 解析分流不等于连接分流
先给结论:把远程 DNS 填进客户端,并不代表所有应用都会使用它。浏览器可以自行启用加密 DNS,操作系统有自己的缓存,代理协议也可能把域名原样交给服务端解析。只有请求实际进入内置 DNS 模块,下面的 servers 规则才会参与处理。
这条链描述内置 DNS 被调用时的过程,不表示每条代理连接都会经过本地解析。客户端收到域名后,如果路由直接选中代理出站,通常可以把域名继续传向服务端;如果路由需要按 IP 判断,或直连出站需要一个目标地址,才可能触发本地解析。具体行为由路由策略和出站配置共同决定。
- 解析分流:决定某个域名交给哪台 DNS 服务器查询,配置重点在
dns.servers。 - 连接分流:决定业务连接使用直连还是代理,配置重点在
routing.rules。 - 查询分流:决定访问 DNS 服务器本身时走直连还是代理,也需要检查路由规则。
系统代理主要接管遵循代理设置的应用请求,不会自动接管整台设备的 DNS。TUN 可以扩大接管范围,但仍需配置 DNS 劫持、路由与排除项,不能仅凭开关状态判断查询是否进入内核。
二、servers、domains 与 queryStrategy 分别控制什么
servers 是候选解析器列表;对象里的 domains 指定优先交给该解析器的域名范围;queryStrategy 控制查询 IPv4、IPv6,还是两者都查询。它们不是同一层规则,不能用一个字段替代另一个字段。
| 字段 | 示例值 | 实际作用 |
|---|---|---|
servers | IP 地址或 DoH 地址 | 定义可用解析器及各自的匹配条件。 |
domains | geosite:cn | 匹配域名集合,优先尝试对应解析器。 |
queryStrategy | UseIP | 允许查询 A 与 AAAA 记录,不承诺两种地址都可连通。 |
queryStrategy | UseIPv4 | 仅查询 IPv4 地址,适合定位 IPv6 路径故障。 |
skipFallback | true | 将该解析器排除在未匹配域名的常规回退候选之外。 |
domains 不应理解为严格的访问白名单。解析失败后是否尝试其他服务器,还取决于回退相关设置。下文使用 skipFallback,避免本地解析器作为未匹配域名的常规兜底;它并不表示匹配它的域名失败后绝不会尝试其他解析器。
本地域名解析器
- 地址
223.5.5.5- 端口
- UDP 53
- 匹配范围
geosite:cn- 回退角色
skipFallback: true
用于本例中的中国大陆域名集合,不等于单位内网的专用 DNS。
默认远程解析器
- 地址
https://1.1.1.1/dns-query- 端口
- TCP 443
- 匹配范围
- 未匹配本地集合的域名
- 查询路径
- 显式指向已有代理出站
DoH 加密查询内容;能否连接取决于实际网络与代理出站。
geosite:cn 依赖运行目录中的域名规则数据,并非内核凭空识别地域。若启动日志提示规则文件缺失,应先修复资源文件。公司内部域名则应写成相应的 domain: 匹配,并交给公司内网解析器,不能发送到公共 DNS 后期待得到内网地址。
三、按域名分流的 DNS 配置片段
下面使用一个本地解析器和一个默认 DoH 解析器。配置意图是:中国大陆域名集合优先本地查询,其他域名使用远程查询。先备份配置,再将顶层 dns 对象合并到现有 JSON;已有同名对象时应编辑原对象,不要重复添加第二个 dns 键。
{
"dns": {
"queryStrategy": "UseIP",
"servers": [
{
"address": "223.5.5.5",
"port": 53,
"domains": [
"geosite:cn"
],
"skipFallback": true
},
"https://1.1.1.1/dns-query"
]
}
}
这里使用数字地址形式的 DoH 端点,避免先解析 DNS 服务器域名所带来的引导依赖。若改用域名形式的 DoH 地址,还要检查该域名由谁解析,以及解析请求会不会反过来依赖这个尚未连通的 DoH 服务。
- 确认内核:v2rayN 是客户端界面,不等同于 V2Ray 内核。先查看核心启动日志,确认当前运行的是 V2Ray 还是 Xray,再核对字段支持情况。
- 确认规则文件:启动时不能出现
geosite:cn加载失败;否则匹配前提已经不成立。 - 确认生成结果:使用界面生成配置时,重启客户端可能覆盖手工改动。应通过客户端支持的自定义配置入口保存,随后查看实际交给内核的配置。
- 确认地址族:保留
UseIP作为正常双栈起点;仅在定位 IPv6 故障时暂时改成UseIPv4,并记录对比结果。
该片段没有入站、代理服务器和出站定义,不能单独启动。Android 上的 v2rayNG 使用 Xray 内核,v2flyNG 使用 v2fly 内核;即使界面都出现“DNS”,字段覆盖关系与运行模式也应分别核对。
四、把 DNS 查询送到正确的出站
只有解析器地址,没有查询路径,仍然可能出现“远程 DNS 实际直连”的情况。标准 https:// DoH 请求可以经过内核路由;某些内核支持的 https+local:// 则采用本地访问语义,不能当作完全相同的地址写法替换。
{
"routing": {
"domainStrategy": "AsIs",
"rules": [
{
"type": "field",
"ip": [
"223.5.5.5/32"
],
"port": "53",
"outboundTag": "direct"
},
{
"type": "field",
"ip": [
"1.1.1.1/32"
],
"port": "443",
"outboundTag": "proxy"
}
]
}
}
这是另一段合并示意,假定现有出站标签确实叫 direct 和 proxy。标签只是配置中的引用名称,不是内核自动创建的对象。请将示例名称替换为实际标签,并把两条查询规则放在可能提前匹配它们的宽泛规则之前;不要用这两条规则覆盖原有的业务分流规则。
结论:先验证查询出站,再讨论解析器速度
日志里若发现 DoH 连接选中了直连出站,应先修正规则顺序与标签引用。替换更多 DNS 地址无法修复一条错误的查询路径。
AsIs 表示路由阶段不为了 IP 规则主动解析域名,并不表示业务连接永远不需要解析。若改成 IPIfNonMatch,未命中域名规则的请求可能先解析再匹配 IP;若使用 IPOnDemand,遇到需要 IP 的规则就可能触发解析。调整这些值之前,应先确认是否真的需要依赖 IP 规则。
还要检查代理服务器自身的域名解析。如果连接代理服务器必须先通过该代理查询 DoH,就会形成循环依赖。可使用明确的引导解析路径,或使用服务提供方确认的服务器地址;不要随意替换订阅中的服务器信息。
五、防 DNS 污染:加密查询、路径与缓存一起检查
DoH 可以保护客户端到解析器之间的查询传输,但不能保证解析结果一定符合预期。解析器的地域策略、网站的 CDN 调度、设备缓存和 IPv6 连通性,都可能造成“地址不同”或“解析成功但打不开”。单纯比较两个解析器返回的 IP 是否一致,不能直接判定污染。
- 先确定查询入口:浏览器自带安全 DNS 可能绕开操作系统解析。排查时暂时关闭该功能,完成对照后再决定是否启用。
- 再确定查询出口:查看核心日志中的 DNS 错误和连接出站,必要时在本机抓包检查是否仍有意外发出的 UDP 53 请求。
- 区分系统缓存:Windows 可运行
ipconfig /flushdns清理系统解析缓存,但该命令不会清空浏览器和内核各自维护的全部缓存。 - 保留单变量对照:同一目标、同一节点、同一运行模式下,只更换解析器或地址族中的一项,避免把代理线路变化误判为 DNS 改善。
本地解析器在本例中使用普通 UDP 查询,因此该部分没有加密保护。如果网络环境不适合明文查询,可以选择可达的本地加密解析器,并重新设计相应路由。不要只把地址改为 DoH,却遗漏它的连通性、证书验证和出站策略。
结论:解析成功与业务可达必须分开验证
能获得 A 或 AAAA 记录,只说明查询阶段有结果。下一步应核对业务连接实际使用的地址、出站和错误类型,再判断是解析异常、IPv6 路径问题还是代理连接失败。
六、解析异常的验证步骤与常见问答
建议先保存一份能连接的配置,再按“核心启动、查询发出、结果返回、业务连接”的顺序检查。临时提高日志详细程度后,只复现一个目标,避免大量并发请求淹没关键记录;完成排查后恢复日常日志等级,分享日志前移除订阅地址和连接凭据。
nslookup -type=A example.com 223.5.5.5
nslookup -type=AAAA example.com 223.5.5.5
ipconfig /flushdns
example.com 是用于说明的保留示例域名。前两条命令直接询问指定的普通 DNS,用于观察该查询路径是否可用;它们不会自动调用 V2Ray 内置 DNS,也不能证明 DoH 已经经代理发送。验证内核分流仍需使用真实应用请求,并结合内核日志和实际配置判断。
改了 DNS,浏览器怎么还是原来的结果?
先检查浏览器是否启用了独立安全 DNS,再清理系统缓存并重启浏览器。随后核对内核运行配置中是否包含新地址;仅修改一个未被加载的 JSON 文件不会影响当前连接。
普通查询正常,DoH 却一直超时?
先检查到 DoH 地址 TCP 443 的连接是否选中了预期出站,再确认节点本身可用、系统时间正确。若日志是证书错误,不要关闭证书验证,应检查时间、端点和网络干扰。
改成 UseIPv4 就能打开,说明什么?
这通常提示需要检查 IPv6 路径,而不是证明原来的 DNS 被污染。对照 A 与 AAAA 结果,检查设备默认路由、节点 IPv6 出站能力和目标连接错误,再决定是否长期限制地址族。
公司内网域名为什么在公共 DNS 查不到?
把公司域名后缀单独匹配到公司内网 DNS,并确认查询走内网直连。若相关地址被 TUN 接管,还应检查局域网路由和排除项;公共解析器通常没有该内部区域的数据。
订阅更新后设置消失,要重新改生成文件吗?
先核对自定义 DNS 设置属于客户端全局配置、配置模板还是单个配置项。将修改保存到客户端支持的持久化入口,再重启核心检查生成结果,不要反复编辑运行时临时文件。
最后的验收标准不是“填入了几台 DNS”,而是三件事同时成立:本地域名命中预期解析器,远程查询使用预期出站,业务连接能按原定路由完成。需要进一步核对界面入口和配置结构时,可阅读客户端配置教程与技术参考。