一、技术架构与工作原理

1.1 核心机制

AdGuard Home 本质上是一台递归 DNS 解析器 + 过滤引擎的融合体。其工作流程如下：

客户端发起 DNS 查询（标准 UDP/TCP 53 端口）。

AdGuard Home 接收查询后，依次经过以下过滤链：

• 自定义过滤规则（用户手动编写的精确规则）

• DNS 封锁清单（订阅的公共规则集）

• DNS 重写（域名到 IP 的静态映射）

• 浏览安全服务（在线 API 查询恶意域名哈希）

• 家长控制服务（在线 API 查询成人内容域名哈希）

• 强制安全搜索（重写搜索引擎域名以强制启用安全模式）

若域名未被任何规则拦截，则向上游 DNS 服务器发起递归查询。

返回结果前，根据设置进行 DNSSEC 验证、缓存、TTL 调整等操作。

1.2 与客户端广告拦截器的本质区别

结论：两者互补，DNS 层负责粗粒度拦截和隐私保护，浏览器插件负责细粒度元素隐藏和反反制。

二、部署架构设计

2.1 物理拓扑

在网络拓扑中，AdGuard Home 通常部署在以下位置之一：

[互联网] → [光猫] → [路由器 (DHCP)] → [AdGuard Home 服务器] → [局域网设备]
                          ↑                      ↑
                    分发 DNS 地址           运行过滤引擎

2.2 部署方案评估

2.3 高可用考量

DNS 是网络的核心依赖，AdGuard Home 若故障会导致全网断网。建议：

• 主备架构：部署两台 AdGuard Home，路由器 DHCP 下发主、备 DNS。

• 兜底 DNS：路由器 DHCP 的备用 DNS 填 119.29.29.29 等公共 DNS，保证 AdGuard Home 宕机时网络不中断。

• 健康检查监控：通过 cron 定时检测 AdGuard Home 进程和端口，异常时自动重启或告警。

三、上游 DNS 深度配置

3.1 并行请求与最快 IP 模式对比

AdGuard Home 支持两种上游查询策略：

推荐配置：

若上游列表中混合了普通 DNS 和 DoH/DoT，使用并行请求时，普通 DNS 因无握手延迟总是胜出，DoH/DoT 形同虚设。此时应采用以下策略之一：

• 方案 A：全部使用普通 DNS（UDP），最大化速度。

• 方案 B：全部使用 DoH/DoT，切换为最快 IP 地址模式，保障隐私。

• 方案 C：仅使用普通 DNS 作为上游，DoH/DoT 作为 AdGuard Home 对下游客户端提供的加密服务。

3.2 分流策略设计原理

DNS 分流的核心依据是 CDN 调度机制。国内主流 CDN（阿里云、腾讯云、百度云等）依赖客户端源 IP 来分配最优节点，而传递给权威 DNS 的源 IP 信息通过 EDNS Client Subnet (ECS) 字段承载。

客户端(192.168.1.100) → AdGuard Home → 上游 DNS (带 ECS: 你的公网IP段)
                                              ↓
                                    权威 DNS 根据 ECS 返回最近的 CDN 节点 IP

因此，分流规则需同时满足：

• 国内域名 → 支持 ECS 的国内上游（阿里 DNS、DNSPod）

• 海外域名 → 海外上游或不带 ECS（避免将国内 IP 段暴露给海外 CDN 导致被限速或返回无效节点）

3.3 推荐的完整上游配置及其原理

# ===== 优先级 1：腾讯云 DNSPod 专属解析 =====
# 使用纯 IPv4/IPv6 地址，零握手延迟，并行模式下总能最先响应
120.53.53.61
120.53.53.123
2402:4e00::0:1ada:bce5
2402:4e00:1::1ada:bce5

# ===== 优先级 2：阿里 DoH 分流（特定域名精确调度）=====
# 国内 CDN 密集域名，强制走阿里 DoH 确保 ECS 生效
[/cn/]https://dns.alidns.com/dns-query
[/qq.com/]https://dns.alidns.com/dns-query
[/bilibili.com/]https://dns.alidns.com/dns-query
# 解决 DoH 域名自身的解析循环依赖
[/dns.pub/]https://dns.alidns.com/dns-query

# ===== 优先级 3：微软/游戏/海外 CDN 专用 =====
[/microsoft.com/]https://dns.alidns.com/dns-query
[/steamcommunity.com/]https://dns.alidns.com/dns-query
[/cloudfront.net/]https://dns.alidns.com/dns-query
[/akamaihd.net/]https://dns.alidns.com/dns-query

# ===== 优先级 4：最终兜底 =====
# 使用 DoH + IP 双重保障（IP 放在最后，并行模式下优先命中）
https://dns.alidns.com/dns-query
223.5.5.5
2400:3200::1

关键设计要点：

• Bootstrap DNS 必须独立配置，仅使用纯 IP 的公共 DNS（223.5.5.5、119.29.29.29），专用于解析 DoH/DoT 服务器的域名。切勿将 DoH 地址自身加入 Bootstrap，否则形成循环依赖。

• DNSPod 的 DoH 地址（https://doh-xxx.doh.pub/dns-query）若要保留，必须为 dns.pub 后缀添加分流规则，指向阿里或 DNSPod 自身。否则 DNS 解析 doh-xxx.doh.pub 域名时可能被其他分流规则错误地送往无法解析该内部域名的上游，导致超时。

• 上游列表中普通 DNS 始终比 DoH 快 5-50ms（缺少 TLS 握手），因此将 DNSPod 的 IP 地址置于最前，确保正常查询优先采用最快的通道。

3.4 上游 DNS 健康检查

AdGuard Home 内置上游健康检查机制，定期对所有上游发起测试查询。若某上游连续失败，会自动降权，待恢复后重新加入。建议：

• 至少配置 3 个不同网络路径的上游（防止单点故障）

• 观察仪表盘 → 上游服务器响应时间，定期淘汰高延迟节点

四、DNS 设置页高级选项详解

4.1 EDNS 客户端子网 (ECS)

技术原理：传统 DNS 查询中，递归解析器只暴露自身 IP 给权威 DNS。ECS 扩展允许递归解析器传递客户端的 IP 段（/24 或 /32 前缀）给权威 DNS，CDN 据此返回地理最优的节点 IP。

配置影响：

• 开启：视频网站、直播平台、下载站等 CDN 调度准确，加载速度显著提升。

• 关闭：CDN 可能分配远离用户实际位置的节点，部分地区网速变慢。

隐私权衡：开启后，权威 DNS 可获知用户所在城市级位置信息（/24 段），等同于普通 DNS 查询的固有隐私暴露（ISP 本就知晓）。对于家庭用户，该隐私泄漏可接受。

推荐：✅ 开启。配合支持 ECS 的上游（阿里 DNS、DNSPod 均支持）。

4.2 DNSSEC

技术原理：通过数字签名链（从根区 DNSKEY 到域名的 RRSIG 记录）逐级验证 DNS 数据的完整性和真实性，防止缓存投毒（Kaminsky 攻击）和中间人篡改。

配置影响：

• 开启：对支持 DNSSEC 的域名进行强制验证，验证失败则拒绝返回结果，安全但极少数配置错误的域名可能无法访问。

• 关闭：接受所有 DNS 响应，无额外验证。

兼容性：主流顶级域（.com、.cn、.org 等）均已支持 DNSSEC，失败率极低。

推荐：✅ 开启。

4.3 DNS 缓存配置

缓存大小：AdGuard Home 默认缓存约 4 MB（约 4000 条记录）。对于家庭网络（10-30 台设备），保守估计每日产生 5-10 万次查询，缓存命中率可达 60-80%。

将缓存提升至 16-32 MB（约 16000-32000 条记录），可使常用域名的查询响应时间降至 1ms 以内（本地内存查询），极大降低上游负载和公网延迟。

优化公式：

推荐缓存大小(MB) = 日均查询次数 × 平均缓存时长(秒) / 86400(秒/天) × 每条记录大小(MB)

假设日均 10 万次，平均 TTL 3600 秒，每条约 200 字节：

缓存 = 100000 × 3600 / 86400 × 0.0002 ≈ 0.83 MB

加之域名数量远超 TTL 轮转量，实战中 16-32 MB 足够有余。

推荐：✅ 设置为 16-32 MB（取决于服务器可用内存，树莓派 4B 可设 16 MB）。

4.4 覆盖 TTL 值与缓存优化

AdGuard Home 允许用户强制设置一个自定义的最小/最大 TTL 值，覆盖域名的原始 TTL。

风险：

• 设置最小 TTL 过短（如 60 秒）：大量请求提前过期，上游查询量激增，总体延迟反而上升。

• 设置最大 TTL 过长（如 86400 秒）：CDN 节点变更后客户端长时间无法感知，导致访问失败或走错节点。

推荐：❌ 不勾选。保持由权威 DNS 控制 TTL，AdGuard Home 在 TTL 过期后自动刷新。

4.5 速率限制

限制每个客户端每秒的最大查询数（QPS），防止以下场景：

• 某设备感染恶意软件后进行 DNS DDoS

• 应用 Bug 导致的后台无限重试（如前述蜻蜓 FM 案例）

• IoT 设备固件缺陷

默认值 20 QPS 对家庭网络非常充足。正常网页浏览触发数十个 DNS 查询，20 QPS 意味着每秒可同时加载约 50-100 个网页，远超实际需求。

推荐：✅ 保持默认 20，不轻易调低至 10 以下。

4.6 针对特定平台的防护选项

阻止访问 iCloud 专用代理：

Apple 的 iCloud 专用代理（Private Relay）将所有 Safari 流量通过 Apple 中继服务器发送，DNS 查询绕过本地网络设置。

开启后，AdGuard Home 会阻塞 mask.icloud.com、mask-h2.icloud.com 等关键域名，强制设备回退到本地 DNS。

推荐：有大量 Apple 设备的家庭开启。

阻止 Firefox Canary 域名：

Firefox 会定期查询 use-application-dns.net 这个 Canary 域名，若返回 NXDOMAIN，则认为网络不支持 DoH，使用系统 DNS；若返回 A 记录，则启用内置 DoH 绕过本地 DNS。

开启后，AdGuard Home 强制返回 NXDOMAIN，确保 Firefox 遵守本地 DNS 设置。

推荐：有 Firefox 用户的网络开启。

4.7 DNS 访问控制

位于 DNS 设置页最下方，用于限制允许查询的来源 IP。

最佳实践：

• 选择 允许模式 (Allowlist)

• 在“允许的客户端”中添加内网 IP 段：

192.168.1.0/24

拒绝所有其他 IP，防止外网恶意用户或僵尸网络利用你的 AdGuard Home 发起 DNS 放大攻击。

五、浏览安全与家长控制模块

5.1 浏览安全服务

采用与 Google Safe Browsing 兼容的 API，通过发送域名 SHA256 哈希的前缀进行比对，不泄露完整域名。AdGuard 使用 family.adguard-dns.com 作为后端服务。

性能影响：每次 DNS 查询前先检查哈希缓存，首次查询增加约 50-100ms 延迟。高频域名会被缓存，后续检查为本地操作。

国内使用障碍：family.adguard-dns.com 服务器在海外，直连可能超时。若需使用，必须确保 AdGuard Home 主机具有稳定的海外访问能力。

替代方案：若网络条件不允许，可关闭此服务，依赖 DNS 封锁清单中的恶意域名列表实现本地静态防护。

5.2 家长控制服务

同样通过 family.adguard-dns.com 检查成人内容域名哈希，开启后全局生效。

细粒度控制：若仅需对特定设备（如孩子 iPad）启用家长控制，不应在此全局开启，而应在“客户端设置”中为对应设备单独配置。

5.3 强制安全搜索

对以下搜索引擎强制启用安全搜索模式：

• Google（www.google.com → forcesafesearch.google.com）

• YouTube（www.youtube.com → restrictmoderate.youtube.com）

• Bing（www.bing.com → strict.bing.com）

• DuckDuckGo（duckduckgo.com → safe.duckduckgo.com）

• 其他：Ecosia、Yandex、Pixabay

实现原理：AdGuard Home 在解析这些域名时自动重写到官方安全搜索专用域名，由搜索引擎自身过滤结果，无需依赖第三方规则。

六、加密层配置

6.1 加密协议全景

6.2 证书管理

AdGuard Home 支持两种证书导入方式：

• 文件路径：提供证书和私钥的绝对路径（适合反向代理或提前获取的证书）

• 粘贴内容：将 PEM 格式的证书和私钥内容直接粘贴到输入框（适合自动化脚本）

自动化证书更新：若使用 Let's Encrypt 证书，90 天过期。建议：

• 使用 certbot 或 acme.sh 自动续期脚本

• 将 AdGuard Home 的证书路径指向续期后的符号链接位置

• 配合 cron 定时重载 AdGuard Home 配置

6.3 加密部署的负载考量

开启 TLS 加密后，每个 DNS 查询增加约 4-8ms 的握手和加解密开销（TLS 1.3 1-RTT）。对于家庭网络，此代价可接受。但如果 AdGuard Home 运行在资源极度受限的硬件（如第一代树莓派），大量并发查询可能导致 CPU 负荷升高，此时应优先使用普通 DNS 为上游，仅对外部客户端提供加密端口服务。

七、过滤器系统详解

7.1 过滤规则引擎

AdGuard Home 使用自研的 aghost 过滤引擎，支持两种主流语法：

Adblock 风格：

||example.org^          # 拦截 example.org 及其所有子域名
@@||example.org^        # 放行（白名单）
||example.org^$third-party  # 仅拦截第三方请求
||example.org^$client='192.168.1.100'  # 仅对特定客户端生效

Hosts 风格：

0.0.0.0 example.org    # 将 example.org 解析到 0.0.0.0（黑洞）
127.0.0.1 example.org  # 解析到 127.0.0.1

7.2 推荐规则集与策略

“精而不多”原则：

• 规则集越多，内存占用越大，查询遍历时间越长。

• 不同规则集之间存在大量重复，重复规则消耗额外资源却无增益。

推荐组合（约 5-8 万条有效规则）：

AdGuard DNS filter + OISD Full + EasyList China + CJX's Annoyance List

7.3 自定义规则编写精要

场景 1：仅拦截特定设备的特定域名

|api.open.qingting.fm^$client='192.168.1.225'

场景 2：放行被全局误杀的域名

@@||cdn.example.com^

场景 3：将某个域名精准解析至特定 IP（绕过分流）

# 在“DNS 重写”页面中配置，而非过滤规则
example.com → 1.2.3.4

场景 4：正则表达式过滤

/^ad[0-9]+\.example\.com$/   # 拦截 ad1.example.com, ad2.example.com 等

7.4 过滤检查工具使用与异常诊断

“检查过滤”功能可模拟完整的过滤链，包括本地规则、在线服务。若出现以下错误：

Error: couldn't apply filtering: huazhuhui.fun:
safe browsing: getting hashes;
requesting https://family.adguard-dns.com:443/dns-query:
net/http: request canceled while waiting for connection
(Client.Timeout exceeded while awaiting headers)

诊断与修复：

• 确认错误源于在线服务（safe browsing/parental control）而非本地规则。

• 进入 设置 → 常规设置，分别测试关闭/开启“浏览安全”与“家长控制”后过滤检查是否恢复。

• 若恢复，说明网络环境无法稳定连通 family.adguard-dns.com。

最终方案：

• 不需要在线服务 → 永久关闭，完全依赖本地规则。

• 需要在线服务 → 配置 AdGuard Home 所在主机的代理或上游 VPN，使流量能稳定到达海外服务器。

八、仪表盘监控与性能分析

8.1 关键指标解读

8.2 案例：86% 拦截率的根因分析

现象：

• 客户端 192.168.1.225 在 24 小时内发起 78,079 次查询，占全网 83.7%

• 域名 api.open.qingting.fm 被拦截 77,262 次，占全部拦截的 95.94%

• 广告过滤规则生效，但应用不断重试

诊断流程：

• 进入 查询日志，按客户端 IP 192.168.1.225 过滤。

• 确认所有 api.open.qingting.fm 请求均被拦截，应用在失败后进行无退避循环重试。

• 到路由器 DHCP 列表反查该 IP 的设备名称和 MAC 地址。

解决方案：

• 方案 A（精确放行）：为该域名添加自定义放行规则，仅对该客户端生效：

@@||api.open.qingting.fm^$client='192.168.1.225'

• 方案 B（粒度隔离）：在“客户端设置”中为 192.168.1.225 创建持久客户端，配置专属的放行规则或关闭过滤。

• 方案 C（日志降噪）：在“常规设置”的“被忽略的域名”中添加 api.open.qingting.fm，排除日志污染（但后台重试依然存在，治标不治本）。

• 方案 D（源头治理）：若该应用不再需要，从设备上卸载。

后续监控：检查仪表盘，确认拦截率回归 20-30% 正常区间。

九、客户端管理策略

9.1 持久客户端与运行时客户端

运行时客户端：由 AdGuard Home 通过 rDNS、ARP、mDNS、hosts 文件自动识别并展示，设备离线后自动消失。不可配置固定策略。

持久客户端：手动创建的固定记录，通过 IP、MAC、CIDR 范围匹配设备。设备离线后配置依然保留，再次上线即生效。支持独立过滤规则、阻止服务、标签分组。

9.2 差异化过滤场景设计

实施方法：在 设置 → 客户端设置 中为每一类设备创建持久客户端，匹配对应 IP 段或 MAC 地址，勾选专属配置。

十、日志与统计管理

10.1 数据隐私合规

根据 GDPR 和《个人信息保护法》的隐私设计原则，DNS 查询日志属于网络行为数据。建议：

• 开启“匿名化客户端 IP”，仅保留部分 IP 段，无法精确追溯个人。

• 保留时间设置为最短可行值（7 天以内），排查问题够用即可。

• 在“被忽略的域名”中加入频繁请求但无价值分析的域名，减少日志体积。

10.2 日志保留策略设定

日志写入频繁时，若 SD 卡或闪存设备运行 AdGuard Home（如树莓派），长期大量写入会加速存储介质损耗。建议将日志目录映射到外置机械硬盘或 tmpfs 内存盘。

十一、故障排查速查表

十二、持续优化与维护

12.1 定期审查清单

• 月度：检查仪表盘各指标趋势，淘汰响应慢的上游服务器。

• 季度：审查订阅规则集，去掉长期无人使用的规则，减少引擎负担。

• 半年度：更新 AdGuard Home 版本（自动更新开启或关注 GitHub Releases）。

• 年度：审查证书有效期（Let's Encrypt 自动续期是否正常）、日志占用空间、硬件资源使用率。

12.2 进阶扩展

• 与 Home Assistant 集成：通过 AdGuard Home 的 API 将实时拦截数据展示在智能家居面板。

• 自定义 Prometheus 指标导出：通过第三方工具采集 AdGuard 统计数据，接入 Grafana，构建可视化监控大盘。

• 结合 Surge / Quantumult X：在移动端通过策略路由将 DNS 查询定向至家庭的 AdGuard Home DoH/DoT/DoQ 端口，实现户外漫游时的持续保护。

• 递归模式：在充分信任的上游环境下，可将 AdGuard Home 配置为递归解析器，直接从根 DNS 进行迭代查询，最大程度减少外部依赖，并提升解析的纯净度。

附录 A：推荐上游 DNS 汇总

表格

附录 B：常用规则集地址

表格