Podman 部署 AdGuardHome 出现 DNS 上游超时问题的排查与解决笔记

一、问题现象

在 Linux 系统使用 Podman 部署了 Clash 和 AdGuardHome 容器，系统 syslog 日志中频繁出现类似以下错误：

May 20 18:33:07 localhost adguardhome[5728]: 2026/05/20 10:33:07.310242 [error] dnsproxy: response received upstream_type=main addr=221.179.155.161:53 proto=udp status="exchanging with 221.179.155.161:53 over udp: read udp 10.88.2.8:46262->221.179.155.161:53: i/o timeout"

错误类型：AdGuardHome 向指定上游 DNS 服务器 221.179.155.161:53 发送查询请求超时。
影响：可能导致域名解析偶尔延迟或首次失败，服务整体可用但体验下降。

二、问题初步分析

1. 上游 DNS 来源

221.179.155.161 是光猫路由器上自动配置的运营商 DNS。
从宿主机 ping 该 IP 延迟低，但 DNS 解析服务与 ICMP 延迟无直接关系。

2. 可能原因

运营商对 DNS 查询频率（QPS）有限制：AdGuardHome 作为 DNS 代理，聚合了局域网内所有设备的查询，并发量高，容易触发运营商限流，导致 UDP 丢包和超时。
Podman 网络模式影响：
- 如果使用 rootless 容器的默认网络模式 slirp4netns，NAT 性能较差，高并发 DNS 请求下可能加剧超时。
- Podman 可能覆盖容器内 /etc/resolv.conf，引起 DNS 策略冲突。
上游服务器本身不稳定：部分运营商 DNS 对非网关直连的客户端（如本机 AdGuardHome）会策略性丢包。

三、排查步骤与发现

1. 测试运营商 DNS 可靠性

在宿主机上执行：

# 使用 dig 测试指定 DNS 服务器
dig @221.179.155.161 www.baidu.com

如果出现大量超时或丢包，说明该 DNS 确实不稳定。

2. 测试阿里公共 DNS（传统 UDP）

dig @223.5.5.5 dns.alidns.com

输出结果（关键部分）：

;; QUESTION SECTION:
;dns.alidns.com.            IN    A

;; ANSWER SECTION:
dns.alidns.com.        3406    IN    A    223.5.5.5
dns.alidns.com.        3406    IN    A    223.6.6.6

;; Query time: 7 msec
;; SERVER: 223.5.5.5#53(223.5.5.5)

结论：

网络到 223.5.5.5 的基础 UDP 53 端口通畅，阿里公共 DNS 服务可用。
说明宿主机网络出口没有运营商阻断问题。

3. 测试阿里 DoH 服务 `https://dns.alidns.com/dns-query`

错误尝试 1：直接浏览器打开

报错 400 / no 'dns' query parameter found。
原因：DoH 端点需要携带参数 ?dns=...，不是普通网页。

错误尝试 2：使用 curl 测试

curl -H 'accept: application/dns-json' 'https://dns.alidns.com/dns-query?name=www.baidu.com&type=A'
# 返回：no 'dns' query parameter found

根本原因：

系统 /etc/resolv.conf 中的 nameserver 指向了本地（可能是 127.0.0.1 即 AdGuardHome 自身）。
该 curl 请求在解析 dns.alidns.com 域名时，被转发到本地 AdGuardHome，而 AdGuardHome 无法正确响应此 DoH 测试请求，返回了错误提示。
并非阿里 DoH 服务不可用。

正确测试阿里 DoH 的方法

方法一：绕过本地 DNS，直接使用 IP 请求 DoH 服务

curl -H 'accept: application/dns-json' 'https://223.5.5.5/dns-query?name=www.baidu.com&type=A'

若返回正常 JSON（包含 "Answer" 段），则服务可用。

方法二：临时修改 hosts 文件

echo "223.5.5.5 dns.alidns.com" >> /etc/hosts
curl -H 'accept: application/dns-json' 'https://dns.alidns.com/dns-query?name=www.baidu.com&type=A'
# 测试后恢复 hosts

方法三：使用支持 DoH 的专用工具（如 dog）

dog @https://dns.alidns.com/dns-query www.baidu.com A

四、解决方案

1. 更换上游 DNS 服务器（核心措施）

在 AdGuardHome 管理界面 设置 → DNS 设置 中，将上游 DNS 服务器更换为稳定可靠的公共 DNS，并启用并行请求模式。

推荐配置：

类型	地址
阿里 DoH	`https://dns.alidns.com/dns-query`
DNSPod DoH	`https://doh.pub/dns-query`
阿里 UDP	`223.5.5.5` , `223.6.6.6`
DNSPod UDP	`119.29.29.29`

并行请求：AdGuardHome 同时向所有上游发起请求，只要一个返回即成功，大幅减少单点超时报错。

2. 调整 Podman 网络模式（备选）

如果更换上游后问题依旧，考虑修改容器网络模式为 host：

podman run -d --name adguardhome --network host \
  -v ./adguard/work:/opt/adguardhome/work \
  -v ./adguard/conf:/opt/adguardhome/conf \
  docker.io/adguard/adguardhome:latest

使用 host 模式后，管理界面访问地址为 http://宿主机IP:3000。
该模式可彻底避免容器网络虚拟化带来的性能开销。

五、知识点总结

概念	说明
ICMP 延迟 ≠ DNS 服务质量	`ping` 低延迟不代表 DNS 解析稳定，需关注策略限制和并发能力。
运营商 DNS 可能限制 QPS	家庭宽带线路常有隐形限流，高并发 DNS 代理（如 AdGuardHome）容易触发。
DoH (DNS over HTTPS)	使用 HTTPS 协议加密 DNS 查询，地址格式为 `https://域名/dns-query`，不能直接在浏览器中当网页打开。
测试 DoH 的正确方法	使用 `curl` 搭配 JSON 接口参数，或使用专用 DNS 测试工具，注意绕过本地 DNS 解析器干扰。
Podman rootless 网络特性	默认 `slirp4netns` 模式 NAT 性能有限，DNS 高负载场景可考虑 `host` 网络模式。

六、后续建议

应用配置后观察日志：更换上游并启用并行请求，监控 i/o timeout 日志是否消失或显著减少。
如果仍有少量超时：
- 检查是否个别上游服务器仍不稳定。
- 确认容器网络模式是否需要调整。
- 考虑增加更多上游 DNS 并保持并行请求。
避免混淆测试场景：当需要测试外部 DNS 服务时，注意绕过本地运行的 DNS 代理（如临时修改 /etc/resolv.conf 或使用 --noproxy 参数）。

tls://dns.pub (DNS over TLS, DoT) 和 https://doh.pub/dns-query (DNS over HTTPS, DoH) 是两种不同的DNS加密协议，它们的核心区别在于传输方式和端口。

你把它们配置在AdGuardHome里，最终效果都是加密DNS查询、防止被篡改和窃听，这点是一样的。就好比你要寄一封重要的信，一个用了结实的牛皮纸信封（DoT），另一个则把信藏在了普通快递纸箱里（DoH），都能保护信件内容，但方式和外观不同。

下面是具体的区别，我整理成了一个表格，方便你对比查看：

特性	`tls://dns.pub` (DNS over TLS)	`https://doh.pub/dns-query` (DNS over HTTPS)
全称	DNS over TLS	DNS over HTTPS
标准端口	853	443 (跟HTTPS网页流量相同)
工作层级	传输层 (第4层)，在系统层面建立加密隧道	应用层 (第7层)，将DNS请求伪装成HTTPS流量
连接方式	建立持久加密连接，能保持连接以加速后续查询	每次查询通常是独立的HTTPS请求，开销相对大一点点
流量特征	非常明显：可以被网络设备轻易识别出“有人在用DoT”，但因为加密所以看不到内容	难以分辨：混在普通的HTTPS网页访问数据里，网络设备难以进行针对性识别和封锁
配置场景	适合整个操作系统层面、对所有应用生效的全局配置	适合浏览器等单个应用的配置，也常作为备用方案

🎯 应该选哪个？

对于你在AdGuardHome里配置来说，这两个都是很好的加密方案，主要就看你的需求和网络环境：

选 tls://dns.pub (DoT)，如果你：
- 追求最佳性能：DoT维持持久连接的特性，在大量DNS查询时延迟通常比DoH稍低。
- 网络环境简单：你不用担心运营商或网络防火墙针对DoT协议的封锁。
- 做全局加密：希望整个系统的所有DNS流量都受到保护。
选 https://doh.pub/dns-query (DoH)，如果你：
- 网络限制严格：担心网络会封锁非标准的853端口。DoH使用和上网一样的443端口，更隐蔽，更难被阻断。
- 希望应用兼容性好：在一些严格的网络环境下，DoH的穿透性更强。

AdGuardHome 配置优化笔记（针对 1核1G 香橙派）

一、上游 DNS 配置优化

当前推荐的上游列表（加密为主，兼顾速度与隐私）

https://dns.alidns.com/dns-query   # 阿里 DoH，国内快
tls://dns.pub                      # DNSPod DoT，国内快
https://doh.pub/dns-query          # DNSPod DoH，备选
tls://1.1.1.1                      # Cloudflare DoT，国外备用（可选）

关键优化点

移除纯文本 DNS：去掉 223.5.5.5 等非加密上游，让所有查询都走加密信道（DoH/DoT），提升隐私保护。
并行请求模式：务必开启。AdGuardHome 会同时向所有上游发起查询，采用最先返回的有效结果。
- 开启后，上游列表的前后顺序完全无关，不再影响解析结果。
适度原则：上游 DNS 数量保持在 2~4 个即可，过多会增加不必要的并发流量。

二、TTL 相关配置优化

TTL（Time To Live）决定 DNS 记录在客户端的缓存时间。合理设置可减少查询频率，降低 CPU 负载。

1. 覆盖最小/最大 TTL 值

配置项	推荐值	说明
覆盖最小 TTL	`0`	设为 0 表示不覆盖，完全遵循上游 DNS 返回的原始 TTL。
覆盖最大 TTL	`0`	同上。

原因：

专业公共 DNS（如阿里、DNSPod）为不同域名设置的 TTL 已经非常合理（稳定网站 TTL 长，CDN 域名 TTL 短）。
强行覆盖可能导致缓存膨胀（短 TTL 变长）或解析不及时（长 TTL 变短），对 1核1G 设备弊大于利。
设为 0 是最省心、最科学的做法。

2. 屏蔽的 TTL 应答（Blocked TTL）

配置项	推荐值	说明
屏蔽的 TTL	`600` 秒（10分钟）	专门针对被广告/追踪规则拦截的域名。

设置方法：

此选项不在 Web 界面中，需修改配置文件 AdGuardHome.yaml：
```
filtering:
  blocked_response_ttl: 600
```
修改后重启 AdGuardHome 容器生效。

原因：

1核 CPU 处理每个 DNS 请求都有开销。被屏蔽的域名无需频繁重复查询。
600 秒是一个平衡值：既能有效压制重复查询，又不会因 TTL 过长而影响规则修正（误杀后恢复较慢）。

三、DNS 缓存大小优化

配置项	推荐值	说明
DNS 缓存大小	`4 MB`（默认）或 `2 MB`	1GB 内存有限，缓存不宜过大。

详细建议：

保持默认 4 MB：可存储约 6~8 万条域名记录，对家庭网络完全足够。
内存优先：如果内存经常吃紧（用 free -h 观察），可手动设为 2097152 字节（2 MB）。
不要关闭缓存：关闭会丧失本地加速能力，显著增加上游查询压力。

设置位置：AdGuardHome → 设置 → DNS 设置 → DNS 缓存 → 大小（字节）

四、其他性能相关选项

配置项	推荐设置	理由
乐观缓存	开启	当上游响应慢时，直接返回已过期但尚未刷新的缓存，避免网络“卡住”。对低 CPU 设备提升流畅度帮助很大。
并行请求	开启	同时查询所有上游，取最快结果。虽然会增加瞬时 CPU 负载，但相比串行查询的几十秒延迟，利远大于弊。

设置位置：AdGuardHome → 设置 → DNS 设置 → 勾选对应选项。

五、针对 1核1G 香橙派的最终配置清单

配置项	推荐值	备注
上游 DNS	2~4 个加密 DNS（DoH/DoT）	并行请求模式下顺序无影响
并行请求	开启	必要
乐观缓存	开启	必要
DNS 缓存大小	4 MB（或 2 MB）	默认即可
覆盖最小 TTL	0（不覆盖）	信任上游
覆盖最大 TTL	0（不覆盖）	信任上游
屏蔽 TTL	600 秒	需修改 yaml 文件

六、一句话总结

信任上游的 TTL，只干预被屏蔽域名的缓存时间；保持缓存精简，开启并行和乐观缓存；用加密 DNS 替代明文查询。

这套配置能让 AdGuardHome 在 1核1G 的香橙派上运行得既省资源又足够流畅。

AdGuardHome配置DNS上游

Podman 部署 AdGuardHome 出现 DNS 上游超时问题的排查与解决笔记

一、问题现象

二、问题初步分析

1. 上游 DNS 来源

2. 可能原因

三、排查步骤与发现

1. 测试运营商 DNS 可靠性

2. 测试阿里公共 DNS（传统 UDP）

3. 测试阿里 DoH 服务 `https://dns.alidns.com/dns-query`

错误尝试 1：直接浏览器打开

错误尝试 2：使用 curl 测试

正确测试阿里 DoH 的方法

四、解决方案

1. 更换上游 DNS 服务器（核心措施）

2. 调整 Podman 网络模式（备选）

五、知识点总结

六、后续建议

🎯 应该选哪个？

AdGuardHome 配置优化笔记（针对 1核1G 香橙派）

一、上游 DNS 配置优化

当前推荐的上游列表（加密为主，兼顾速度与隐私）

关键优化点

二、TTL 相关配置优化

1. 覆盖最小/最大 TTL 值

2. 屏蔽的 TTL 应答（Blocked TTL）

三、DNS 缓存大小优化

四、其他性能相关选项

五、针对 1核1G 香橙派的最终配置清单

六、一句话总结

添加新评论

分类

AdGuardHome配置DNS上游

Podman 部署 AdGuardHome 出现 DNS 上游超时问题的排查与解决笔记

一、问题现象

二、问题初步分析

1. 上游 DNS 来源

2. 可能原因

三、排查步骤与发现

1. 测试运营商 DNS 可靠性

2. 测试阿里公共 DNS（传统 UDP）

3. 测试阿里 DoH 服务 https://dns.alidns.com/dns-query

错误尝试 1：直接浏览器打开

错误尝试 2：使用 curl 测试

正确测试阿里 DoH 的方法

四、解决方案

1. 更换上游 DNS 服务器（核心措施）

2. 调整 Podman 网络模式（备选）

五、知识点总结

六、后续建议

🎯 应该选哪个？

AdGuardHome 配置优化笔记（针对 1核1G 香橙派）

一、上游 DNS 配置优化

当前推荐的上游列表（加密为主，兼顾速度与隐私）

关键优化点

二、TTL 相关配置优化

1. 覆盖最小/最大 TTL 值

2. 屏蔽的 TTL 应答（Blocked TTL）

三、DNS 缓存大小优化

四、其他性能相关选项

五、针对 1核1G 香橙派的最终配置清单

六、一句话总结

添加新评论

分类

3. 测试阿里 DoH 服务 `https://dns.alidns.com/dns-query`