用 Claude/GPT 需要配 DoH 吗？DNS 泄露与分流方案对比
为了让账号更稳，不少人把本地 DNS 全量换成 DoH，结果国内站点解析到海外 CDN、访问变慢；而代理工具默认的并行 fallback 依然会把查询暴露给国内 DNS。文章拆解 DNS 泄露、ECS 与分流原理，对比四种做法的适用场景，并给出一份可逐项核对的配置清单。
为了让 Claude、GPT 这类服务用得稳一点，很多人先从 DNS 下手：把系统或代理的解析全部换成 DoH，认为这样能避开「DNS 泄露」，从而降低被封号或模型变「降智」的概率。真按这个思路配完，最先出问题的往往不是账号，而是国内网站——音乐、视频类站点被解析到海外 CDN，打开慢、拖动卡，整体上网体验跟着下降。
这条链路里其实混了三件事：DNS 查询被谁看到（隐私）、域名解析到哪个 CDN 节点（性能）、平台如何判断账号风险（风控）。三者相关但不等价，拆开看，配置思路会清楚很多。
DNS 泄露到底指什么
简单说，就是本该由代理解析的域名，实际由本地运营商或本地公共 DNS 解析了。查询内容、你的真实出口网段因此暴露给这些解析器。常见的检测站点大多基于同一逻辑：看你用的是哪家解析器、出口在哪个地区、与代理出口是否一致。
与访问速度直接相关的是 ECS（EDNS Client Subnet）。递归解析器会把客户端网段一并带给权威服务器，权威服务器据此返回就近节点。国内公共 DNS 一般会带 ECS，国内站点因此能拿到本地 CDN；不少海外 DoH 不带 ECS（或只带解析器自己的网段），权威服务器就可能把请求当成海外来源，返回海外节点，于是出现「能打开但很慢」。
并行 fallback 为什么防不住泄露
代理工具常见的默认写法是两组 DNS 并行：一组国内，一组海外 DoH，谁先返回、谁没被污染就用谁。这套设计的初衷是抗污染——某个域名被投毒时用另一组结果兜底——而不是隐私保护。
问题也在这里：只要做过并行查询，国内 DNS 就已经收到过一次请求并留下记录，无论最终采信哪一组。想靠它隐藏「访问了哪些域名」，逻辑上不成立。所以会有这样的疑问：既然并行必然产生国内查询，这套 fallback 对账号安全的意义是什么？比较中肯的回答是几乎没有，它解决的是解析可用性，不是泄露。
平台真的会拿 DNS 判断账号吗
一种看法是，服务方不太可能专门构造随机子域名去探测用户的解析路径，更常见的信号是语言、时区、IP 归属、支付方式与账号行为模式。这个判断无法验证，但方向上合理：DNS 只是众多信号之一，而且是很弱的一个。
另一种看法强调，就算与封号无关，DNS 泄露本身也是隐私问题——访问过哪些域名、频率如何，都留在了本地解析器那里。这个说法成立，且与平台是否检测无关。
至于「降智」是否与 DNS 有关，目前没有可靠证据。把它当成确定性的因果，容易在错误的方向上反复折腾配置，反而忽略真正影响体验的因素。
四种做法与取舍
| 做法 | 原理 | 优点 | 代价 |
|---|---|---|---|
| 全量 DoH | 所有查询都走海外 DoH | 本地解析器看不到查询 | 无 ECS，国内站点调度变差，延迟上升 |
| 并行 fallback | 国内外 DNS 同时查，择优采用 | 配置简单、抗污染 | 泄露依旧，解析结果不稳定 |
| 域名分流 | 名单内的国内域名走本地 DNS，其余交由代理解析 | 隐私与速度兼顾 | 名单可能滞后，小众域名会误判 |
| 按注册信息判断 | 查 RDAP/whois、权威 NS 归属决定用哪组解析 | 准确率高，规则维护量小 | 首次解析慢，需要脚本或支持规则求值的内核 |
几点补充：
- 域名分流是多数人的性价比之选。geosite 一类名单对主流站点覆盖足够，时效性问题主要出现在冷门域名上。
- 按注册信息判断更准，但要自己写点东西（RDAP 查询、IP 归属库），或使用支持规则求值的代理内核，适合经常访问小众站点、追求确定性的人。
- 无论选哪种，「海外域名在本地直连海外 DoH」都不算好方案：延迟高、稳定性差。更稳的做法是让代理侧去解析海外域名。
一份可执行的检查清单
- 关掉并行 fallback，改成「按域名决定解析路径」。
- 国内域名走本地或国内 DoH，并保留 ECS；海外域名交给代理侧远程解析。
- 排查系统层绕过：
systemd-resolved、NetworkManager、浏览器自带的「安全 DNS」都可能绕开代理配置，需要逐项确认。 - 用查询命令验证，端口按实际监听填写：
dig @127.0.0.1 -p 53 +short music.163.com # 期望：国内 CDN 节点
dig @127.0.0.1 -p 53 +short api.anthropic.com # 期望：海外解析结果
- 打开自建 DNS 或代理的查询日志，确认海外域名的解析请求没有落到国内解析器上。
- 配置结构大致如下（键名以所用内核的文档为准）：
dns:
enable: true
# 不要同时启用两组 DNS 的并行查询
nameserver-policy:
"geosite:cn": ["https://国内-doh/dns-query"]
# 其余域名由代理侧解析，而不是本地直连海外 DoH
账号层面更值得投入的地方
- 遵守平台使用条款，在支持的地区使用；不共享、不买卖账号，这类做法带来的封禁与支付纠纷风险，远大于调整 DNS 带来的收益。
- 保持出口稳定。频繁切换节点、IP 跳变、反复断线重连，比 DNS 更容易被判定为异常。
- 长任务不要依赖本地机器。跑 Claude Code 这类需要长时间在线的任务时，本地休眠、网络切换、断电都会中断会话。若本地环境不稳定，可以把任务放到一台长期在线的远程机器上，例如整机置于新加坡机房的独享 Mac mini，按月租用、远程连接，网络环境相对固定，适合挂着跑。这是可选项，不是必需。
小结
- DoH 不是防封号手段，它解决的是「查询别被本地看到」的隐私问题。
- 默认的并行 fallback 抗污染有效、防泄露无效，还会让国内站点的解析结果变得不确定。
- 想兼顾速度与隐私：按域名分流，国内域名用带 ECS 的国内 DNS，海外域名交给代理解析。
- 判断配置是否到位看两点：国内站点解析到国内 CDN；海外域名的查询不出现在国内解析器日志里。
- 平台风控的具体规则不会公开，任何「这样配就不会封」的说法都值得怀疑；地区支持与条款以官方最新说明为准。