域名解析失败并不是单一状态。权威服务器确认名称不存在，与解析器暂时超时或不可用，在应用层可能看起来相似；如果以相同方式缓存，短暂故障就可能被延长。加入代理后还要回答另一个问题：解析发生在本机、代理节点，还是上游解析器？
本指南提供一套可重复的恢复测试。其研究依据之一是 curl 于 2026 年 9 月 2 日发布的 8.22.0 版本说明，其中明确提到仅对权威回答产生的否定解析结果进行缓存。该方法同样适用于其他维护 DNS 或连接状态的 HTTP、SOCKS 客户端。
先定义四类结果
为每次请求明确分类：
- 获得正向解析结果并尝试连接；
- 获得符合解析策略的权威否定回答；
- 发生临时解析失败、超时或解析器不可用；
- 临时故障解除后成功恢复。
不要把所有解析错误都写成“DNS 挂了”。应记录结果类别、执行解析的组件、是否命中缓存，以及客户端是否真正开始网络连接。
确认解析责任边界
逐项记录各路径由谁解析：
- 本地解析的直连请求；
- 携带源站主机名的 HTTP 代理请求；
- 使用目标主机名的 HTTP CONNECT 隧道；
- 将主机名交给代理的 SOCKS 请求；
- 将本地已解析地址交给代理的请求。
具体行为取决于客户端和代理模式，必须用受控日志验证，不能根据出口 IP 猜测。远程解析和本地解析往往使用完全不同的缓存。
如需排除响应缓存干扰，可参考代理响应缓存隔离测试；需要提交问题时，可使用代理支持升级证据包指南。
构建受控测试环境
使用组织自有的域名与解析环境，准备：
- 指向已知地址的稳定主机名；
- 明确返回权威否定回答的不存在主机名；
- 可在测试解析器中临时延迟或失败的主机名；
- 将临时主机名恢复为有效地址的步骤；
- 一条直连路径和所有获准测试的代理路径。
目标端点只返回很小且确定的无害响应。保持请求方法、请求头、代理会话、目标和超时策略不变，每次只改变解析条件或路由。
采集必要证据
为每个案例分配编号并记录：
- 时间戳和单调计时耗时；
- 客户端与解析器版本；
- 直连、HTTP 代理、CONNECT 或 SOCKS 路径；
- 本地解析或代理侧解析；
- 测试主机名和案例类别；
- 解析结果类别，以及缓存命中或重新查询证据；
- 连接开始时间、结果和目标类别；
- 不含凭据的代理会话类别；
- 重试次数和退避间隔。
禁止记录代理密码、API Token、Cookie、客户域名或完整生产数据。测试环境不应包含个人或机密信息。
建立基线
从干净的客户端和解析状态开始：
- 直连解析稳定主机名并确认连接成功。
- 通过每种代理模式重复，确认解析发生位置。
- 在有限时间窗内两次查询权威不存在主机名。
- 确认结果按既定解析策略保持为否定回答。
- 在测试解析器健康时查询临时主机名并确认成功。
这一步既验证测试环境，也能发现错误路由、旧地址或掩盖 DNS 查询的连接复用。
注入临时故障并验证恢复
只让受控解析路径临时不可用或延迟，不要干扰公共基础设施。
- 使用新连接请求临时主机名。
- 确认结果被标记为临时失败，而非权威否定。
- 恢复解析器及有效记录。
- 按应用正常的有限退避策略重试。
- 要求客户端重新查询，并在无需重启无关组件的情况下连接成功。
- 分别使用相同代理会话和新会话重复。
- 分别覆盖本地解析和代理侧解析模式。
验收标准很清楚：临时失败不能形成持久负缓存，从而在解析器恢复后继续阻断请求。权威否定回答只能按预期的客户端和解析器策略缓存。
将 DNS 缓存与连接复用分开
连接池可能让请求不经过新查询便成功；陈旧连接也可能在 DNS 已恢复后继续失败。至少执行三个变体：
- 保留 DNS 缓存，但强制建立新连接；
- 清除 DNS 状态，但保留正常连接池；
- 启动既无 DNS 状态也无连接状态的新进程。
比较结果，不要因为一次重试成功就认定发生了重新解析。连接池键应隔离目标、代理路由、TLS 信任配置和认证会话等安全边界。
控制重试放大
只执行少量固定次数的重试，采用带抖动的指数退避，并限制并发。解析器短暂故障不应触发快速更换代理或大量重复请求。
记录恢复时间、每个逻辑请求的查询次数、成功连接数和重试放大倍数。如果换出口后测试才“成功”，应回到稳定路径找到真正持有缓存的组件；更换出口不是 DNS 缓存修复方法。
验收清单
- [ ] 已确认每种代理模式的解析责任方。
- [ ] 正向、权威否定和临时失败被分别分类。
- [ ] 测试仅使用自有名称和受控解析器。
- [ ] 稳定正向对照在所有获准路径成功。
- [ ] 权威否定案例符合预期缓存策略。
- [ ] 临时失败仅按有限退避策略重试。
- [ ] 恢复后出现新查询并成功连接。
- [ ] DNS 缓存和连接复用被独立测试。
- [ ] 未用代理轮换掩盖结果。
- [ ] 日志不包含凭据和生产数据。
常见问题
所有 DNS 否定结果都适合缓存吗？
不适合。关键在于结果是否是符合当前解析策略的权威否定回答，还是临时故障。把临时错误当作持久不存在会延迟恢复。
SOCKS 代理一定负责解析主机名吗？
不一定。有的模式把主机名交给代理，有的模式把客户端已解析的地址发给代理。应检查配置并用受控测试确认。
为什么恢复后的请求成功，却没有新的 DNS 查询？
它可能复用了已有连接。强制新建连接，并将 DNS 状态单独测试后再下结论。
故障期间是否应该清空所有缓存？
不应自动这样做。先判断陈旧状态属于应用、操作系统、解析器、代理还是连接池。大范围清缓存会掩盖问题边界并增加负载。
来源与合规说明
内部研究依据：curl 项目于 2026 年 9 月 2 日发布的 curl 8.22.0 发布公告与变更记录。外部资料 URL 仅保存在内部运营记录中，公开文章不含外部链接。
只测试自己拥有或明确获准评估的域名、解析器、代理路径与端点，并遵守服务商限制、隐私要求、robots 规则和组织变更流程。
