安卓其实早就有系统级 DoH,只是被藏在一个 feature flag 后面

01

⭐ 但真正重要的不是这个发现本身，而是它揭示的一个现实：

⭐ 也就是说：对绝大多数用户，这条路是走不通的 —— 而正因为走不通，那个 workaround（自建一个 Cloudflare Worker 当 DoH 端点）才成为唯一解，也才值得单独成篇。

02

「安卓 Private DNS 这个功能最大的限制一直是：自定义主机名被锁定在 DNS-over-TLS 上。这意味着在封掉那个 TCP 端口的网络上 —— 比如大学 Wi-Fi、酒店、机场等等 —— 你的连接会彻底失败。」

⭐ 这个问题很多人遇到过但没想清楚原因：

⭐ 而 DoH（DNS over HTTPS）跑在 443 上 —— 那个端口几乎不可能被封。

03

⭐ 这是全文的技术核心，而它其实是一个相当优雅的机制设计。

「在翻安卓源码之后，我发现 OS 其实完整支持 Discovery of Designated Resolvers（RFC 9462 DDR）来自动把 Private DNS 升级成 HTTP/3 DNS-over-HTTPS！它就藏在那个 feature flag 后面。」

⭐ 我把 loophole 的 README 里的机制描述抄下来，因为它讲得最清楚（原文）：

「开了 flag 之后，安卓通过 DDR 自行发现 DoH 端点：它在连接前会查询一条名为 _dns.<hostname> 的特殊 SVCB DNS 记录，如果该记录通告了一个 DoH 路径，安卓就会跳过 853 端口，改走 DoH，通常跑在 HTTP/3 上。」

⭐ 换句话说，整个流程是：

⭐ 我认为这个设计的优雅之处在于：它把「如何知道 DoH 端点在哪」的问题，用 DNS 自己的扩展机制（SVCB/HTTPS 记录）来回答 —— 而不需要任何客户端额外配置。

04

⭐ 这一节是本文最实用的部分，因为原帖作者和 loophole 的 README 都强调了这一点。

⭐ 作者在原帖里也说了同样的话：

「我测了一堆，唯一发布 DDR 记录的公开服务是 Google、Cloudflare 和 Quad9。NextDNS 和 AdGuard，以及其它大多数流行服务商连记录都没有。🫠」

⭐ 而 loophole README 里有一句更精确的补充：

「在主要 DNS 服务中，Quad9 是唯一一个支持 DDR 且需要打开 flag 的。Google 和 Cloudflare 不需要它，因为它们是硬编码的。」

「DDR 对一个广告拦截型 DNS 服务商来说会很难实现。它也许能把连接升级到加密，但它怎么知道该分配哪个 profile？」

⭐ 我认为这是全文最重要的一条评论，因为它点出了这个机制的商业困境：

⭐ 这也解释了为什么 NextDNS 官方没有跟进 —— 它需要的是一个「用户专属的 DNS 记录」，而 DDR 的模型是「服务侧的公共记录」。

⭐ 而 Google 和 Cloudflare 能做，是因为它们提供的是「公共的、无状态的」DoH 端点 —— 对应到用户是谁不重要。

05

⭐ 而这正是 loophole 这个项目存在的意义 —— README 的「Why a gateway is needed」一节写得非常清楚：

「loophole 给安卓的 Private DNS 一个它能自己发现的 DoH 端点，这样系统级加密 DNS 在封 853 端口的网络上仍然可用。它是一个你部署到自己账号的 Cloudflare Worker，加上让发现机制能工作的安卓 flag 文档。不需要 VPN，不需要 root。」

⭐ 我认为这个设计非常巧，因为它把「服务商不支持 DDR」这个死结，绕开了：

「你的过滤服务自己不需要支持 DDR。」

⭐ 注意路径 ② 的存在 —— 这是最容易被忽略但最省事的一条：

⭐ 如果你不依赖广告拦截、只是想要「加密的系统 DNS」，那么直接用 Quad9 + 两条命令就够了，不需要 Worker、不需要域名、不需要 Cloudflare 账号。

⭐ 而 README 还给了调整说明：

「按你的服务器调整两件事：如果它不提供 HTTP/3，用 alpn="h2"（或 alpn="h2,h3" 如果两种都提供）；如果你的 DoH 路径不是 /dns-query，把你的路径放进 dohpath 里。如果你的端点跑在 443 以外的端口上，在参数里加 port=<数字>。」

⭐ 而 alpn="h3" 这点值得单独说：它指的是 QUIC（HTTP/3 over UDP/443）。这正是 DoH 相对 DoT 的另一个优势 —— QUIC 在丢包环境下通常比 TCP 表现更好，而且首次连接不需要额外往返。

⭐ 这是最漂亮的部分 —— 整个功能只需要两个 flag：

「必需的最后一步：打开飞行模式，等几秒，然后关掉。安卓只在重连之后才应用这个改动。不做这一步，设置就不会生效。」

⭐ 而评论区有人实测了这个流程，并补充了更完整的命令集（u/Masterflitzer 在 Galaxy S23 Plus / Android 17 / OneUI 9.0 上验证）：

⭐ 他的实测结论：

「一开始不工作，但跑了这些命令并重启手机之后它终于работа了」

「我用的是 Cloudflare 帮助站的测试域名 one.one.one.one 和 cloudflare-dns.com 来测试，因为只有后者在安卓的硬编码白名单里 —— 在做这个之前前者显示 dot（DoT）而后者显示 doh，现在跑完这些命令并重启手机后两个都显示 doh，所以说明它生效了。」

⭐ 「dot vs doh」这个显示差异是个很好的验证方法 —— 因为系统设置界面会直接告诉你当前 Private DNS 是走的 DoT 还是 DoH。

06

⭐ 这一节是本文我最想强调的部分，因为 README 自己把它放在 FAQ 的前几条，而且它是设计上无法避免的。

「网关的 /dns-query 端点按设计是开放的。DDR 要求安卓在无需认证的情况下访问它，所以任何找到你网关 URL 的人都可以通过它发查询，而你的上游 profile 会看到他们的流量。除非你接受这一点，否则不要公开你的网关域名。」

⭐ 我想解释一下这个代价的准确形态，因为容易被误解：

⭐ 而 README 明确说了 PIN 锁不住它：

「为什么 DNS 端点是开放的？不能拿 PIN 锁住吗？不能。DDR 要求安卓在无需认证的情况下访问端点，所以端点无法被锁。PIN 只保护 dashboard。」

⭐ 这一点值得反复强调 —— 因为很多人在自建 DoH 时会本能地加上鉴权，然后发现 DDR 发现失败。不是配置错了，是 DDR 的模型就是「无认证发现」。

⭐ 所以 README 的建议是：「除非你接受这一点，否则不要公开你的网关域名。」

⭐ 而这在实践中意味着：你的 Worker 域名（如果是 xxx.workers.dev）或者你自己域名下的那个主机名，本质上是一个「公开的秘密」。谁拿到它就能借用你的 DNS 配置。

⭐ 现实影响评估：这和「公开的 DNS over HTTPS 端点」是同一类东西 —— 而 Cloudflare/Google 的公共 DoH 端点本来就是公开的。真正的风险不是「别人能用你的 DoH」，而是「别人能用你的 NextDNS profile，从而让你的规则集被别人的查询触发，或者消耗你的配额。

「需要 root 吗？不需要。loophole 通过 Shizuku 或 ADB 管理系统设置。」

「会耗电或后台运行吗？不会。设置完成后手机上没有任何东西在运行。Private DNS 是一个系统设置，不是一个 app，也不是 VPN，所以没有后台服务，也没有电量开销。」

⭐ 而原帖作者补充了他做这个项目的直接动机：

「这意味着像 RethinkDNS 那样吃电的后台 VPN app 不再必要了（我一直很讨厌那种后台 VPN，所以这对我来说意义重大😅）。」

⭐ 我认为这一点值得展开，因为「用 VPN app 做 DoH」和「用系统级 Private DNS 做 DoH」的差别，比表面看起来大：

07

⭐ 我把 README 和评论区的细节汇总成一份清单：

⭐ 注意作者自己修正过一次：

「这个设置自己搞需要 ~~Android 15+~~（编辑：我说错了，16+）」

「Shizuku：在手机上安装 Shizuku，通过无线调试配对，然后装 aShell You 并允许它访问 Shizuku。在那里逐条运行下面的命令。」

「ADB：从电脑装 Android Platform Tools，开启开发者选项和 USB 调试，USB 连接，跑 adb devices 确认手机出现。」

⭐ 所以手机本地也能做，不需要电脑 —— 这对很多用户是关键。

「如果这些设置一直重置，这会禁用整机的 DeviceConfig 同步。只在需要时使用：」

```

adb shell device_config set_sync_disabled_for_tests persistent

```

「恢复：adb shell device_config set_sync_disabled_for_tests none」

⭐ 这一点很重要 —— 因为 DeviceConfig 的设置是从 Google 服务端同步的，如果你只改了本地，OTA 更新或同步可能把它冲掉。而「禁用同步」这个开关是官方提供的、专门给这类场景用的测试接口。

⭐ 两个都应返回 1。而更直观的验证是：看系统设置里 Private DNS 的状态显示 —— 如果显示 doh 而不是 dot，说明 DDR 生效了。

「不用自定义域名能用吗？部分能。基础 DoH 和 dashboard 在 workers.dev 地址上能用，但安卓的主机名发现需要自定义域名和它的 SVCB 记录。没有域名，Private DNS 无法发现网关。」

⭐ 也就是说：Worker 本身可以挂在 workers.dev 上，但 SVCB 记录必须在你自己的域名下 —— 因为 _dns.<hostname> 这条记录需要一个你能控制的 zone。

08

⭐ 我认为这个帖子的价值在于它揭示了一个被忽视的、一直在那里的能力：

⭐ 因为能从中受益的服务商，几乎只有 Google、Cloudflare（不需要开）和 Quad9（需要开）。而 2026 年的主流 DNS 服务商（NextDNS、AdGuard、Control D…）全都不发布 DDR 记录 —— 对它们来说，DDR 在商业上不成立。

⭐ 所以这个 flag 大概率会永远关着 —— 除非有人解决评论区提出的那个问题：

「它怎么知道该分配哪个 profile？」

⭐ 我认为这是本文最值得记住的一层因果：

⭐ 原帖作者的原话：

「在翻安卓源码之后，我发现 OS 其实完整支持 RFC 9462 DDR……」

⭐ 而他做这件事的路径是：遇到一个「封 853 就完全不能用」的实际痛点 → 去翻源码 → 发现有一个被藏起来的能力 → 验证它 → 写出来 → 顺手做成开源工具。

⭐ 三条：

⭐ 而值得加一句：原帖评论区里有人提到 FortiGate 用户在防火墙上直接屏蔽 DoH（「yeah. im blocking DoH within the firewall. nice try, maybe next time 😄 Fortigate FTW」）—— 企业网络管理员对 DoH 的封锁，本身就是这个方案在企业环境里的最大障碍。

09

23

KEY FACTS

这个帖子的价值在于它揭示了一个被忽视的、一直在那里的能力：安卓完整实现了 RFC 9462，代码就在树里，只差一个开关。而这个开关之所以没打开，很可能就是因为「开了也没用」—— 因为能从中受益的服务商几乎只有 Google、Cloudflare（不需要开）和 Quad9（需要开）。而 2026 年的主流 DNS 服务商全都不发布 DDR 记录，对它们来说 DDR 在商业上根本不成立。评论区那条最尖锐的评论把根因说透了：DDR 的 SVCB 记录是按域名的、全域共享的，而 profile 是按用户的、每个用户私有的。你没法在 dns.nextdns.io 的公共 DNS 记录里告诉全世界「这个用户要用 profile abc123」。所以这个 flag 大概率会永远关着 —— 除非有人解决那个问题：让用户拥有专属的 DNS 记录。而正因为原生路走不通，workaround 才成为唯一解，也才值得单独成篇。于是形成了一个有点讽刺的格局：系统里有能力，但商业上没人用；用户有需求，但系统能力用不上；最后是两个人自己搭桥。而这个案例本身也是「源码阅读 + 实验能产出真实价值」的一个好例子：作者的路径是遇到一个实际痛点，去翻源码，发现一个被藏起来的能力，验证它，写出来，顺手做成开源工具。这比任何隐私技巧文章都更有价值，因为它给出了一个可复用的方法论，而不是一个配方。最后必须提醒三个边界：第一，不要公开你的网关域名 —— DoH 端点按 DDR 的要求无法鉴权，知道 URL 的人就能借用你的 profile。第二，这个方案对「已经用后台 VPN app 做 DoH」的用户收益最大 —— 省电，而且只接管 DNS 不接管全部流量。第三，它只保护「谁看到你的 DNS 查询」，不保护「你访问了什么」。而在企业环境里，还有一道更硬的墙：已经有防火墙管理员直接在规则里封掉了 DoH。

本文同步发布于 freelamp.com 与 B站「LeisureLinux」

我是 FreeLAMP.com，专注开源安全工具与工程实践，持续分享安全入门与前沿技术的观察。

如果今天这篇有收获，欢迎点赞、在看、转发三连，我们下篇见。