前一篇 DNS 排查处理了两秒重试和 Google、YouTube、TMDB 的异常答案。当时先给几个域名指定海外 DoH，其他域名仍使用原来的默认上游。
10 月 21 日继续检查 Telegram、X 等常用服务，又遇到了同类解析问题。单独增加规则能修好已知域名，但以后访问的新域名还会落到原默认组。这次把默认策略改成了国内名单走国内 DoH，其余走可信海外 DoH，再补上手工维护和故障恢复。
本文记录 2026 年 10 月 21 日已实施并验证的配置，AGH 版本为 v0.107.79，时间均为北京时间。家庭地址、管理入口和真实业务域名已省略；示例域名仅说明语法。原有代理出口选择保持。
国内名单和海外默认组
名单使用 felixonmars/dnsmasq-china-list 的国内加速域名数据，本次生成了 109,785 个国内后缀。数量是当天的快照，以后会随更新变化。
| 匹配情况 | 使用的上游 |
|---|---|
| 页面中明确指定的域名规则 | 按手工规则选择，保留设备更新、DDNS 等国内例外 |
| 命中国内后缀名单 | 阿里 / DNSPod DoH |
| 其余域名，包括未知域名 | Cloudflare / Quad9 / Google DoH |
Google、Telegram、TMDB、OpenAI 等原来单独配置的六条海外 DNS 规则就可以删掉了。它们共覆盖 21 个后缀，现在继承海外默认组。设备更新和 DDNS 等九条国内例外继续保留。
这份名单决定用谁解析域名，不负责决定连接从哪个代理节点出去。RouterOS 的 IPv4 分流、mihomo 的业务选路，以及独立的 Fake-IP DNS 路径都没有随之改动；常规 AGH 查询仍返回真实地址。
它也不是第五篇中的RouterOS CNIP地址名单：CNIP存的是IPv4/CIDR，按日更新用于选路；这里存的是域名后缀，按周更新用于选择DNS上游。IPv6公网服务目标列表则是另一套入站放行条件。
页面保留手工规则，后端维护自动名单
最初把所有规则合并成一个上游文件，主 AGH 通过 upstream_dns_file 使用它。这样便于生成名单，却让页面上的手工编辑难以和活动文件保持一致。
最终改为同一容器内运行两个 AGH 核心：
- 主 AGH 负责客户端查询、过滤、内网重写、缓存和日志。它的
upstream_dns_file为空，手工上游规则由原生页面保存。 - 分流后端只监听回环
127.0.0.1:5353，按国内名单选择上游；管理口也只在回环监听。它不再做过滤、缓存、查询日志或统计。
主 AGH 的默认上游是 127.0.0.1:5353。明确写在页面里的域名上游先被匹配，不必再进入自动名单后端。
在“DNS 设置 → 上游 DNS 服务器”中保留默认入口，新增规则可以这样写。下面两条是语法示例，没有作为真实业务规则部署：
127.0.0.1:5353
# example.cn 及其子域名使用国内 DoH
[/example.cn/]https://dns.alidns.com/dns-query https://doh.pub/dns-query
# example.com 及其子域名使用可信海外 DoH
[/example.com/]https://1.1.1.1/dns-query https://dns.google/dns-query域名上游的语法和更具体后缀优先关系，见 AGH 官方配置说明。页面保存后由原生配置重载生效，终端和 RouterOS 已经缓存的结果仍有自己的 TTL。
自动任务每周日 04:20 后随机延迟最多 15 分钟更新后端。下载后检查格式、大小、域名哨兵和集合变更幅度，再校验候选配置、替换并重载。任一步失败就保留旧名单，任务失败后 15 分钟重试。
这个任务不写主 AGH 配置。实际从页面增加测试规则后，运行一次名单更新并重载后端，主配置逐字节保持一致，测试规则仍有效；从页面删除后，查询也恢复了原来的结果。
分流后端卡死时的接管
两个核心仍在同一容器、同一 PVE 上。增加后端之后，首先需要处理的是：5353 这个进程停止响应，会不会把主 DNS 一起拖住。
主 AGH 配置了 Cloudflare、Quad9、Google DoH 作为后备，上游超时设为 2 秒。正常情况下使用原分流；连接失败或超时才尝试后备。应急时，原本通过国内名单解析的默认查询也会用海外 DNS。
在这个版本里，完全卡死的上游会先被尝试两次。生产验证只暂停了分流后端，新的 UDP/TCP 查询分别在约 4.37、4.44 秒得到后备应答，因此不能把“2 秒超时”理解成两秒内一定完成接管。
还测到了一个限制：正常 NXDOMAIN 不应被改写，而 SERVFAIL 在此版本里不会自动触发原生后备。 持续返回失败的后端，需要额外的健康检查来隔离。
PVE 上的 watchdog 每轮结束后等 15 秒，再直接探测后端：百度的 A/UDP、Google 的 A/UDP 和 A/TCP，要求得到有效公共地址。
连续三轮失败后先重启后端，重启操作五分钟内最多一次；仍失败就停止故障后端，让主服务把它视为不可用上游，转用可信后备。应急期间每 120 秒启动一个临时回环候选，用当前名单做两轮 UDP/TCP 查询，都通过后才恢复正式后端并复查。
更新和维修共用维护锁，避免一边换名单、一边恢复服务。计划停机还有维护标记，防止 watchdog 把主动停止的后端重新拉起。主服务与后端的 OpenRC 崩溃监督也保留，后端只是主服务的启动排序软依赖，后端失败不会成为主 DNS 启动的硬条件。
这些保护主要覆盖分流后端。主 AGH 卡死、容器或 PVE 整机停机，仍没有另一台独立主机来接管；全部出口不可用时，后备 DoH 也帮不上忙。
缓存保留额度考虑，缩短过期记录留存
这次没有把最低 TTL 改成零。原来的 600 秒是为了减少重复解析，也考虑了所用阿里云 DoH 的额度。
最终缓存保留 128 MiB，最低 TTL 600 秒、最高 3600 秒，乐观缓存继续开启。只把过期缓存最大年龄从 12 小时缩到 1 小时，过期应答 TTL 保持 30 秒。
最低 TTL 会把较短的权威 TTL 延长到 600 秒，这意味着地址变化可能更晚被看到。这次保留的是家庭现有取舍，并不适合所有业务。过期记录最多留一小时，也不表示每小时才刷新一次；正常 TTL 周期和后台刷新仍照常工作。
旧查询日志约 976 万条，系统抽样约 12.82 万条，缓存命中比例约 68%–70%。这个结果支持继续保留当前缓存策略，但不能换算成阿里云账户实际计费或剩余额度。
查询日志最终选择 7 天轮转。当前版本保留活动文件和上一份日志，稳定运行后磁盘历史最长可能接近 14 天，并非每条记录满七天就立即删除。运行日志另外按大小管理：每小时检查，超过 20 MiB 轮转，保留五份压缩文件。
确认旧历史没有继续保留价值后，清理了五份旧查询、运行日志及其归档，共约 1.43 GiB。配置回退备份继续保留。
正常采集接口被 PCDN 关键词误拦
整理查询记录时，还发现一个媒体采集接口反复失败。回到应用容器核对配置和日志，确认两个启用的源确实在请求它，同容器的 Node 查询也复现了 EAI_AGAIN。
它的 CNAME 中恰好包含连续的 pcdn 字符，被已有通配规则命中。域名包含这几个字符，并不能证明它在跑 PCDN。这次只对确认的接口主机做精确过滤放行，没有放行整个 CDN。
放行后 A 查询恢复，AAAA 却仍然失败。继续使用带 DO 的查询对比，Quad9 返回 SERVFAIL，Cloudflare 和 Google 返回 NOERROR；单独清理缓存也没解决。最终只给这个接口增加 Cloudflare / Google 上游例外，DNSSEC 保持开启。
下面用示例域名展示两种规则所在的位置：
# 自定义过滤规则：只放行完整主机名
@@|api.example.com|$important
# 上游 DNS：为这个域名后缀选择解析服务
[/api.example.com/]https://1.1.1.1/dns-query https://dns.google/dns-query过滤放行和选择 DNS 上游解决的是不同环节。这里有实际验证过的单域名兼容问题，因此保留例外；之前那六条规则只是重复海外默认组，已经删除。
修复后，AGH、RouterOS 的 A/AAAA 均为 NOERROR。AAAA 只有 CNAME、没有 IPv6 地址也是有效的无 AAAA 应答，Node 随后使用 IPv4。原应用容器的 HTTP/HTTPS 列表请求都返回 200，JSON 有效并含 20 条数据；原来明确要拦的 QQ、B站 PCDN 目标仍返回拦截答案。没有验证整片播放或多天稳定性。
本次验证到的范围
| 项目 | 实际验证 |
|---|---|
| 自动名单与页面规则 | 国内、海外、未知域名及手工优先；真实周更不覆盖页面规则 |
| 后端故障 | 同版本隔离测试、生产短暂挂起后端、UDP/TCP后备及自动恢复 |
| 常用服务 | 多个实施阶段检查 Google、Telegram、X、YouTube、百度及家庭入口的 HTTPS/TLS |
| 过滤兼容 | 收窄 QQ、B站整域放行中的冲突，11 个明确拦截目标恢复；普通图片/视频 CDN 和设备例外解析正常 |
| STUN | 取消通用关键词拦截，保留平台专用项；没有进行真实通话测试 |
| 最终日志设置 | 只把查询日志周期改回7天，主/后端进程未重启；百度UDP、Google UDP/TCP正常 |
Homepage 的功率卡片另外修正了失效实体引用，监控里的 Lucky URL 也改回有效入口。这两项分别通过接口和页面复查；状态页过去的失败条和在线率保留，不会因为当前成功就消失。
应用登录、完整播放、长期节点稳定性和跨主机 DNS 接管，都不在这次已完成的验证范围里。