TL;DR：Android Private DNS 和代理客户端内置 DNS 不要同时抢主导权。先关 Private DNS，确认客户端单独能解析；再反过来关客户端 DNS 的复杂规则。谁改动后问题消失，谁就是重点排查对象。
Android 的 Private DNS 本质上是系统级 DNS over TLS。代理客户端通常又会通过 VPNService 接管流量，并在内部做 DNS 解析、fake-ip、规则匹配或远程解析。两套逻辑叠在一起时，问题会变得很怪：浏览器正常，App 不正常；Wi-Fi 正常，移动网络不正常；同一个域名在不同 App 里结果不同。
先确认 Private DNS 状态
路径通常是：
设置 -> 网络和互联网 -> Private DNS / 私人 DNS不同厂商系统名字会略有不同。记录当前状态：
| 状态 | 含义 | 排障建议 |
|---|---|---|
| 关闭 | 系统不强制 DoT | 适合作为基线 |
| 自动 | 系统尝试使用运营商或网络提供的加密 DNS | 结果不够可控 |
| 指定主机名 | 固定 DoT 服务 | 最容易和客户端 DNS 策略冲突 |
第一轮排查建议先选「关闭」。不是说 Private DNS 不能用，而是要先把变量减到一个。
VPNService 接管后 DNS 怎么走
Android 代理客户端一般用 VPNService 建一个本地虚拟网卡。App 的流量进入这个虚拟网卡后，客户端再决定怎么转发。DNS 可能有三种路径：
- App 自己向系统 DNS 发请求。
- App 的 DNS 请求被 VPNService 捕获，交给客户端处理。
- App 内置 DoH/DoT，直接连自己的 DNS 服务。
第三种最烦。比如某些浏览器、社交 App 或安全软件有自己的加密 DNS 开关，它们不一定听系统 Private DNS，也不一定完全听代理客户端。
典型冲突表现
| 表现 | 可能原因 |
|---|---|
| 开客户端后部分 App 无法解析域名 | Private DNS 返回路径和客户端规则不一致 |
| 浏览器能打开，其他 App 失败 | 浏览器使用了自己的 DoH 或被分应用规则排除 |
| 只在移动网络失败 | 运营商网络对 DoT 或 UDP 处理不同 |
| fake-ip 模式下 App 连接到奇怪地址 | App 缓存了旧 fake-ip 或绕过了客户端 DNS |
| 关闭 Private DNS 后恢复 | 系统 DNS 和客户端 DNS 冲突 |
不要只看「能不能打开网页」。至少选两个 App、两个网络环境、两个域名做对比。
排查流程
按这个顺序做，不要跳：
- 关闭 Android Private DNS。
- 重启代理客户端的 VPN 开关。
- 清掉目标 App 的 DNS 缓存，简单做法是强行停止 App 后重开。
- 测试目标域名。
- 如果正常，再打开 Private DNS，填回原主机名。
- 再测同一组 App 和域名。
如果第 5 步后问题复现，冲突已经很明确。然后决定保留哪边：系统 Private DNS，还是客户端内置 DNS。
客户端内置 DNS 要看什么
不同客户端入口不同，但字段大同小异：
| 客户端 | 重点检查 |
|---|---|
| SFA / sing-box | dns.servers、rules、final、strategy |
| v2rayNG | remote DNS、domainStrategy、路由规则 |
| NekoBox | DNS 设置、绕行规则、分应用代理 |
| Hiddify | DNS mode、DoH/DoT、分应用 |
| Clash Meta for Android | fake-ip、nameserver、fallback、rule-provider |
如果你选择让客户端负责 DNS，就尽量关闭系统 Private DNS，并在客户端里写清楚 remote DNS 和 direct DNS。反过来，如果你只想用系统 Private DNS，就不要在客户端里叠复杂 fake-ip 和远程解析规则。
需要多客户端切换测试时，可以使用兼容 Clash / Singbox / V2Ray 的订阅分别导出格式，但 DNS 行为要在每个客户端里单独检查，不能只看订阅名称。
分应用代理会制造错觉
很多 Android 客户端支持「只代理选中的 App」或「排除选中的 App」。这会影响 DNS：
- 被纳入 VPN 的 App，DNS 可能由客户端处理。
- 被排除的 App，DNS 可能继续走系统 Private DNS。
- App 自带 DoH 时，两边设置都可能被它绕开。
所以同一个域名，在 A App 里正常、B App 里失败，不一定是线路问题。先看两个 App 是否在同一分应用策略里。
推荐的日常组合
普通使用建议二选一：
| 组合 | 适合谁 | 注意点 |
|---|---|---|
| 关闭 Private DNS，使用客户端 DNS | 需要规则分流、fake-ip、远程解析的人 | 客户端配置要写清楚 |
| 开 Private DNS，客户端少做 DNS 改写 | 只需要简单代理、不想调 DNS 的人 | 分流能力会弱一些 |
不要长期保持「系统指定 Private DNS + 客户端 fake-ip + App 自带 DoH 全开」。出问题时很难判断哪个 DNS 返回了结果。
结论
Android Private DNS 冲突的核心不是某个开关好坏，而是 DNS 决策入口太多。排障时先关系统 Private DNS，让客户端单独工作；再反向测试。最终保留一套主逻辑，另一套只做辅助。这样后续遇到解析失败，才有明确的日志和路径可查。