适合已经能通过 v2rayN 或 v2rayNG 连接节点、准备调整 DNS 分流的用户。先分清系统解析、内核解析与代理服务器解析,再用两组上游和明确的出站规则搭建可验证的配置。示例以 Xray JSON 为操作基准,配置片段需要合并到现有配置,不是可以直接启动的完整节点文件。
一、内置 DNS 在哪里参与连接
“配置了 DNS,为什么浏览器还是查询系统服务器?”通常不是服务器地址填错,而是请求根本没有进入内核 DNS。V2Ray、Xray 的内置 DNS 是一个供内核调用的解析模块,不会因为出现了 dns 字段,就自动接管整台设备的所有 UDP 53 请求。
应用把域名交给 SOCKS 代理时,内核可能直接把域名交给远端服务器,最终由远端解析。应用如果先用系统 DNS 得到 IP,再把 IP 交给代理,内核收到的则已经不是原始域名。这两条路径都不能简单等同于“客户端内置 DNS 已生效”。
- 路由需要 IP:
routing.domainStrategy设置为IPIfNonMatch时,域名规则未匹配后,路由可以调用内置 DNS,再尝试 IP 规则。 - 直连出站需要 IP:Xray 的
freedom出站使用UseIPv4等解析策略时,会通过内置 DNS 获得连接地址。 - 设备发出普通 DNS 包:需要另行配置接收、转发或捕获链路;仅写上游服务器并不能完成这件事。
- 浏览器启用安全 DNS:浏览器可能自行发送 HTTPS 查询。请求即使经过代理,也未必使用这里配置的内置解析上游。
二、先确定上游、端口和内核边界
本文把境内域名交给 223.5.5.5,其他域名交给 https://1.1.1.1/dns-query,并让后一条查询经过现有代理出站。IP 形式的 DoH 地址可以减少“为了连接解析服务器,先解析解析服务器域名”的引导依赖;仍然要保留正常的 TLS 证书验证。
境内域名上游
- 服务器
223.5.5.5- 传输
- 普通 DNS,UDP 53
- 匹配范围
geosite:cn- 查询出站
direct
适合需要本地网络视角的解析;这条普通 DNS 链路本身不加密。
其他域名上游
- 服务器
https://1.1.1.1/dns-query- 传输
- DoH,TCP 443
- 匹配范围
- 未命中专用上游的域名
- 查询出站
proxy
依赖代理节点先能连接;代理不可用时,不应悄悄退回普通本地解析。
v2rayN 是桌面客户端,不等于固定使用某一种内核。v2rayNG 使用 Xray,v2flyNG 使用 V2Fly;同名字段的可用范围和默认行为需要按实际内核确认。尤其是 DNS 回退字段、特殊地址前缀和出站解析策略,不要把一份 Xray 配置原样套到所有内核上。
- 备份当前能连接的配置,记录客户端版本和启动日志中的内核版本。
- 确认运行配置中已有代理出站,并记下它的实际
tag。下面统一使用proxy,不是要求修改协议名称。 - 确认
geosite.dat可读取且包含cn分类。缺失数据文件会导致规则加载失败,不是上游超时。 - 操作期间只改一层:先改 DNS,再改路由,最后验证系统与浏览器是否仍有独立解析。
三、按域名分配解析上游,收紧失败回退
下面是顶层 dns 字段片段。境内服务器带有域名匹配列表,只负责对应域名;DoH 服务器不带域名列表,作为其他域名的常规上游。这里先使用 IPv4,目的是把 IPv6 可达性这个变量从第一次排查中移出去,而不是要求长期关闭 IPv6。
{
"dns": {
"queryStrategy": "UseIPv4",
"disableFallback": true,
"servers": [
{
"address": "223.5.5.5",
"port": 53,
"domains": [
"geosite:cn"
],
"skipFallback": true
},
{
"address": "https://1.1.1.1/dns-query"
}
]
}
}
domains是解析服务器的匹配条件,不是完整的流量路由规则。域名交给某个 DNS,不代表网页连接也会自动使用相同出站。skipFallback: true表示这台服务器不参加未匹配查询的回退,避免境内上游顺便接到其他域名的查询。disableFallback: true用于禁止匹配上游失败后的回退阶段。没有命中专用域名列表的查询,仍由默认上游处理;它不等于“所有查询都禁止使用默认服务器”。queryStrategy: "UseIPv4"限制本次解析策略,不能替代系统层面的 IPv6 路由管理。
这份配置刻意没有加入 localhost 或系统 DNS 作为备用项。否则代理 DoH 不可达时,查询可能重新落回原本想绕开的解析路径。若启动日志提示未知字段,应先核对内核文档和版本,不要直接删掉回退限制后就认为问题已经解决。
四、让 DoH 查询走代理,让直连确实使用内置 DNS
只写 DoH 地址,还不能说明查询经过了节点。普通 https:// 形式的 DoH 请求可参与内核路由;下面通过目标 IP 和端口把它送到 proxy。不要随手改成 https+local://:后者的本地查询语义不同,不能继续套用这里的路由判断。
将以下规则合并到现有路由中。DNS 上游规则放在宽泛的直连、IP 分类和最终兜底规则之前;proxy 必须替换成实际代理出站标签,direct 必须对应已有的直连出站。这个示例没有按目标 IP 做境内分流,因此选择 AsIs,避免为了路由额外解析每个陌生域名。
{
"routing": {
"domainStrategy": "AsIs",
"rules": [
{
"type": "field",
"ip": [
"1.1.1.1"
],
"port": "443",
"network": "tcp",
"outboundTag": "proxy"
},
{
"type": "field",
"ip": [
"223.5.5.5"
],
"port": "53",
"network": "udp",
"outboundTag": "direct"
},
{
"type": "field",
"domain": [
"geosite:cn"
],
"outboundTag": "direct"
},
{
"type": "field",
"network": "tcp,udp",
"outboundTag": "proxy"
}
]
}
}
这段规则是最小逻辑示例,不应覆盖原有的局域网绕过、节点地址直连等必要规则。尤其是节点使用域名时,连接节点本身所需的引导解析不能反过来依赖“已经连上的代理”,否则会形成启动循环。可以保留客户端原有的节点解析方案,单独核对它使用的上游。
还要检查直连出站。下面展示的是需要合并或替换的那个 freedom 出站对象,不是让你额外创建第二个同名出站。设置后,境内域名交给直连出站时,会通过内置 DNS 获取 IPv4 地址。
{
"tag": "direct",
"protocol": "freedom",
"settings": {
"domainStrategy": "UseIPv4"
}
}
判断:先证明查询链路,再增加 IP 分流
先让域名规则、两组上游和两个出站对应起来。确实需要按目标 IP 判断时,再引入 IPIfNonMatch 与相应 IP 规则;不要为了“更完整”同时改动解析策略、IPv6 和路由兜底。
五、在 v2rayN 与 v2rayNG 中落地配置
图形界面的 DNS 页面不一定接受完整 Xray JSON。有的字段只接收服务器地址,有的页面区分基础设置和高级配置。先判断输入框期待的是地址、DNS 对象还是完整配置,再粘贴对应内容。直接编辑客户端临时生成的运行文件,通常会在切换节点或重启后被覆盖。
- 桌面端先看入口:在 v2rayN 中打开「设置」→「DNS 设置」,核对当前内核对应的 DNS 项;再到「设置」→「路由设置」检查规则顺序。不同版本若使用设置页签,应以页面实际字段说明为准。
- 复杂规则使用自定义配置:需要同时控制
dns、routing和outbounds时,在 v2rayN 的「服务器」→「添加自定义配置服务器」中导入合并后的完整配置。已有节点的认证、传输和 TLS 参数继续保留。 - 安卓端核对运行方式:在 v2rayNG 的「设置」中检查 VPN 模式及 DNS 相关选项。若导入完整自定义配置,确认实际运行的是该配置,而不是仅把它保存在列表中。
- 不要混用配置格式:v2rayNG 的原始自定义配置需要符合 Xray 结构;v2flyNG 则按 V2Fly 的字段支持处理。订阅链接、单个节点分享链接和完整 JSON 是三种不同输入。
- 保存后重启连接:查看启动日志是否有 JSON 解析错误、未知标签或数据文件读取错误。启动失败时先恢复备份,不要连续切换多个开关掩盖错误。
六、验证分流解析与防污染是否生效
验证要同时回答三个问题:谁收到了查询、查询经过哪个出站、应用最后连接了哪个地址。仅用 nslookup 看见一个可用 IP,不能证明内核 DNS 生效;它默认测试的是系统解析链路,恰好可以作为对照组。
| 验证项目 | 具体操作 | 判读重点 |
|---|---|---|
| 系统解析基线 | 执行 nslookup www.example.com | 记录系统解析器,不把输出当作内核上游证明。 |
| 境内域名路径 | 访问一个确认属于当前 geosite:cn 的域名。 | 日志或抓包中核对 223.5.5.5:53 的查询与直连出站。 |
| 其他域名路径 | 访问未命中境内集合的域名,并确认这次操作确实触发了内核解析。 | 检查到 1.1.1.1:443 的连接是否命中代理;域名直接交给远端时,本地没有查询也可能正常。 |
| 失败回退 | 临时让代理不可用,再触发一条需要代理 DoH 的全新查询。 | 应出现明确失败,而不是把该查询转交境内普通上游。 |
| 应用独立解析 | 分别检查浏览器安全 DNS、系统加密 DNS及被排除应用。 | 区分应用自身的 HTTPS 查询与内核 DoH,逐项记录覆盖范围。 |
测试前清理相关缓存。Windows 可以运行下面的命令清理系统 DNS 缓存,再重启内核以清理内核进程内缓存;浏览器也可能维护自己的缓存。不要连续刷新同一个已缓存域名,然后根据“没有新查询”判断配置失效。
ipconfig /flushdns
nslookup www.example.com
需要定位时,可短时间把顶层 log.loglevel 调整为 debug,结合连接日志观察。不同内核版本输出的 DNS 细节不同,不应只搜索某一句固定文字。测试结束后恢复 warning 或原先级别,并避免公开包含访问域名、服务器地址和认证信息的完整日志。
- DoH 一直超时:先核对代理节点可用性、
proxy标签及规则顺序,再检查服务地址是否可达。 - 出现证书错误:检查设备时间和 TLS 验证环境,不要把关闭证书验证当成 DNS 修复办法。
- 境内网站解析成功却访问慢:检查是否拿到了不合适的 CDN 地址,以及网页流量是否也命中了直连。
- 测试页面显示境外解析器:结合预期判断;代理 DoH 本来就可能显示境外递归服务器,地理位置本身不是泄漏结论。
七、常见配置疑问
用了 DoH,为什么还是打不开某个网站?
DoH 只解决解析传输中的一部分问题。继续检查返回 IP、目标端口、节点连通性、路由命中和 TLS 握手。如果域名由代理服务器解析,还需要检查服务器侧 DNS;客户端这份配置未必参与了那次解析。
VMess、VLESS 或 REALITY 会改变这套 DNS 分流规则吗?
它们影响代理连接的协议或安全设置,不会自动替你选择 DNS 上游。只要实际代理出站标签仍然正确,查询分流的基本思路不变。节点地址是域名时的启动解析仍需单独处理。
是否应该马上启用 FakeDNS?
先不必。FakeDNS 返回的是供内核映射使用的合成地址,需要 DNS 捕获与后续连接都回到同一条处理链。只打开一个开关却没有完整接管路径,可能让应用拿到无法直接连接的地址。先验证真实 IP 解析与出站规则,再考虑引入它。
本地解析与远端解析必须选一种吗?
不必。境内直连业务可以由客户端按指定上游解析,其他业务可以把域名交给代理服务器解析。关键是明确每条路径的责任边界,不要把客户端内置 DNS 的设置误认为对远端服务器也自动生效。