加密 DNS 也需要先建立网络连接。如果解析服务使用域名，而解析这个域名又依赖尚未建立的代理，就会出现循环依赖。排查重点不是寻找“最快的 DNS”，而是画清第一次连接时，谁负责解析谁、谁能在没有其他服务帮助时先启动。
从一次冷启动开始思考
平时网络正常，可能只是因为缓存里保留着地址。设备重启或切换网络后，缓存失效，隐藏的依赖才显露出来。因而“刚才还可以”不能排除配置问题。对启动过程的验证应该包含一次没有现成连接可复用的状态，并在不会中断重要业务时进行。
假设客户端需要连接一个以域名表示的代理节点，节点域名由加密解析服务回答；但配置又要求这台解析服务必须经过该代理连接。两边都等待对方先完成，就无法启动。这个示例没有涉及特定机场，描述的是依赖关系本身。
类似问题也会出现在规则下载、订阅更新与节点启动之间。若客户端必须先下载规则才能决定解析服务出口，而规则下载又依赖规则才能路由，同样需要明确独立的启动路径。把所有连接都设为经过代理，不会自动解决这些先后关系。
引导解析只解决第一步
引导解析的任务是让客户端知道解析服务或代理服务器的初始地址。它并不代表后续所有业务查询都要使用同一个解析渠道，也不等于放弃加密。合理设计会把启动所需的少量查询与一般业务查询分别说明，避免把临时启动例外扩大到全部流量。
核验时的 mihomo 文档区分用于解析 DNS 服务域名的默认解析配置和节点域名解析配置。不同内核的字段名、默认行为及版本变化并不相同，应该从当前运行版本出发核对，不能直接套用网上另一套软件的片段。
使用固定地址也不是没有代价。服务地址可能调整，某些服务需要正确的主机名和证书验证，直接把 URL 中的域名换成地址可能导致验证失败。不能为了“连接成功”关闭证书校验；应采用服务与客户端正式支持的地址和身份配置方式。
画一张足够小的依赖图
拿一张纸写下四个对象：应用查询、解析服务、代理节点、基础网络。用箭头表示依赖，例如应用查询依赖解析服务，解析服务连接依赖基础网络。每条箭头旁边写出是解析依赖还是传输依赖，两者分开以后，环路通常会很明显。
再增加必要的配置下载对象，检查是否有任何闭环。一个可启动的方案至少应有一条从基础网络出发、无需依赖未就绪组件的路径。无需追求图表复杂，能够解释首次启动时第一个网络请求怎么发出就已经很有价值。
企业网络、酒店网络和校园网络还可能要求先完成接入认证。在认证完成前，加密解析服务不可达，不一定是客户端配置错误。先关闭接管进行合法的网络登录，再恢复原配置，记录这一前置条件，不要通过不断替换公共解析服务掩盖接入状态。
按错误阶段验证
若日志显示无法解析代理域名，先检查节点域名的解析路径；若已经得到地址但连接超时，检查路由与服务可达性；若连接建立后证书校验失败，检查系统时间、服务身份和证书链。把三个阶段混在一起，会让每次改动都难以验证。
对于解析服务本身，同样先看地址获取，再看传输，再看查询应答。连接被拒绝与查询返回不存在是不同结果，后者至少说明查询已得到响应。记录原始错误类别，不要把所有失败都写成“DNS 被污染”。
示例验证可以先保持业务规则不变，只把节点域名解析改成一条独立、已确认可达的路径，然后重新启动客户端。若恢复，说明启动依赖值得进一步检查；还需恢复原配置复现，才更有把握。对照过程中不要同时更换节点、浏览器和网络。
避免用缓存伪装稳定
如果每次手动访问某个页面之后客户端才恢复，应怀疑缓存或连接预热改变了条件。测试记录中加入冷启动与热启动两种状态，分别记载第一次查询用时、后续是否正常。不能只保留成功的第二次，把首次失败当作偶发忽略。
也要考虑故障后的恢复能力。主解析服务失效时，备用路径是否依赖同一节点、同一网络或相同域名？两个不同名称可能实际落在同一个故障点。备用设计的目标是减少共同依赖，而不是单纯增加地址数量。
最终可写出一份启动说明：基础网络就绪以后，节点域名由哪条路径解析，加密解析服务如何连接，业务查询再交给谁。说明中只记录服务名称与结构，不保存订阅凭证。每次升级后按照这一顺序做小范围验证。
如果查询路径已经正确，但测试页面显示不同解析出口，可继续阅读DNS 测试结果解释；若代理连接重新进入自身通道，则看TUN 环路预防。解决引导问题的终点，是重启后仍能按预期自动建立连接，而不需要依赖偶然留下的缓存。
参考资料
- RFC 8484：加密查询的协议定义，核验日期：2026-10-15。
- mihomo DNS 配置，核验日期：2026-10-15。