家里的常规 IPv4 DNS 查询通常先到 RouterOS，再转给 AdGuard Home（AGH），由 AGH 查 DoH 上游、返回真实地址。DoH 就是通过 HTTPS 发 DNS 查询。
直接查 mihomo 的 1053 端口是另一条路径，会用到 Fake-IP 和排除规则。10月16日与21日的AGH修改都没有合并这两条路径。
本文保留 10 月 15–16 日的排查过程。10 月 21 日已进一步改为国内名单分流、其余走可信海外 DoH，重复的 Google/TMDB 等专属上游规则已删除；页面手工规则、后备解析与自动恢复见后续维护记录。
截图是 10 月 16 日的汇总界面，和下面的突发查询测试不是同一批数据。
内网查询卡住约两秒
AGH 原来限制为 20 QPS，也就是每秒 20 次查询，按 IPv4 /24 共享一个限速桶。RouterOS 转过来的请求也受这个桶限制。超过限速的 UDP 查询被静默丢弃，RouterOS 等约两秒后再发一次。
测试用了不重复的内网重写子域，共 36 项，速率为 40 QPS。这样查的是本地重写，不经过公网和 DoH 上游。
| 配置 | 查询响应时间 | 重试情况 |
|---|---|---|
| 调整前：20 QPS | 前 20 项约 0.6–1.9 ms，后 16 项约 1996–2011 ms | 后 16 项约两秒后重发 |
| 调整后：200 QPS | 全部 36 项为 0.59–1.03 ms | 36/36 回复，未见该两秒重试 |
抓包里能看到，那 16 项第一次发出后没有收到回复，约两秒后重发才成功。低速查询原本就快，缓存也没有明显容量压力。
我把限速从 20 改到 200 QPS，保留原来的分桶方式和限速保护。再跑同样的突发查询，36 项都快速返回了。
200 QPS是针对当时家里的查询负载选的值，10月21日只读复核仍保持。表里的毫秒级耗时来自内网重写，境外域名冷查询仍要等上游回复。
10月16日：先为异常域名指定上游
另外查到的问题是 DNS 答案。原默认并行组里，两路阿里上游更快返回了 Google、YouTube 的可疑地址；其他上游返回的地址归属正常，但不一定最先到。并行查询可以采用先到的成功响应。
当时给Google、YouTube和相关资源域单独配了Cloudflare、Quad9、Google DoH组，再清理AGH和RouterOS的旧缓存，其余域名暂时继续用原默认组。这个默认组已经在10月21日的分流改造中替换，不能作为现在的配置示例。
同日回查TMDB，API域的A答案也有异常，又把 themoviedb.org 和 tmdb.org 加到同一专属组，没有固定网站IP。域名指定上游的语法见AGH官方配置说明。
TMDB 当时仍能通过 HTTPS 访问。mihomo 按嗅探到的域名和业务规则选路，绕过了坏地址，所以只打开网页没有暴露这个问题。
10月16日的查询和访问验证
TMDB 改后返回了核对过归属的 CloudFront 地址，随后 60 项低速 DNS 查询全部回复。冷查询仍约百毫秒，热缓存才是毫秒级。
HTTPS 检查中，无密钥访问 TMDB API 返回 401，图片根路径返回 404，网站返回 200，TLS 校验都通过。我没有登录 Emby 做完整刮削，应用里那一步还没测。
当时还在独立测试实例中测过专属上游全部失败，结果为SERVFAIL，没有退回默认组。这个实例未包含10月21日新增的可信海外后备和后端watchdog，不能用它描述现在的整条故障处理链。AGH真实地址查询和mihomo的Fake-IP路径当时分别检查，行为保持。
10月21日后的配置
| 项目 | 现在的处理 |
|---|---|
| 默认解析 | 主AGH转给同容器回环5353：国内后缀名单用国内DoH，其余用Cloudflare / Quad9 / Google DoH |
| 原逐域名规则 | Google、Telegram、TMDB、OpenAI六条重复海外规则已删除；设备更新/DDNS等九条国内例外保留 |
| 页面维护 | 手工域名上游由主AGH原生保存，优先于默认分流；周更只更新后端，不覆盖页面规则 |
| 后端异常 | 主AGH配置可信海外后备；连接异常/超时后接管，持续SERVFAIL由watchdog重启或隔离后端 |
| 缓存与日志 | 保留最低TTL600秒，过期最大年龄1小时；查询日志7天轮转，磁盘历史最长可能近14天 |
新方案已另测真实后端卡死、UDP/TCP后备和恢复。完整过程见第七篇。这次修复的是后端分流的故障链，主AGH、容器或PVE整机失效仍没有跨主机接管。