本文目录
两个管理页面都显示运行中，家里的设备却时好时坏，这时反复换 DNS 端口往往难以判断原因。要看清一条查询先到哪个服务、再转给谁，并决定保留终端过滤统计还是优先让域名进入代理规则，之后才能检查停用服务时如何恢复解析。
AdGuard 与 OpenClash 的上游不能互相指回
OpenClash 和 AdGuard Home 都想处理 DNS，但职责不同：AdGuard Home 负责过滤、重写和查询记录，OpenClash 的内核 DNS 负责让域名解析与代理规则配合。两者可以共存，前提是一条查询只沿一个方向前进。
写下终端从 DHCP 得到的 DNS、路由器 53 端口由谁接收、AdGuard 的上游是谁、OpenClash 内核监听在哪个端口。只要查询最终又回到前一个服务，就会形成循环。
同一条查询应按选定方向转发。若另一个插件也会劫持 53 或转发 DNS，停掉其中一套冲突的劫持，并明确两个服务的先后顺序；dnsmasq 的上游应与这条路径一致。
根据你想保留的能力选路径
| 路径 | 查询方向 | 优点 | 取舍 |
|---|---|---|---|
| AdGuard 在前 | LAN DNS 入口 → AdGuard → OpenClash DNS → 外部上游 | AdGuard 更容易记录每台终端并先做过滤 | 必须关闭 OpenClash 对 LAN 53 的抢先劫持 |
| OpenClash 在前 | LAN / dnsmasq → OpenClash → AdGuard → 外部上游 | 域名先进入 OpenClash，Fake-IP 与规则路径更集中 | AdGuard 通常只看到来自路由器/内核的查询，难以区分每台终端 |
确认实际监听和转发，不要只看 LuCI 开关
先识别几个入口
| 入口 | 常见作用 | 不要混淆 |
|---|---|---|
| 路由器 TCP/UDP 53 | LAN 设备默认访问的 DNS 入口 | 同一个地址端口不能同时被 dnsmasq 与 AdGuard 独占 |
| AdGuard Home DNS 监听 | 接收查询、过滤并转给上游 | 3000 等 Web 管理端口不是 DNS 端口 |
| OpenClash 内核 DNS | 按模式解析并配合规则 | 常见内部监听为 127.0.0.1:7874，但应以运行页和日志为准 |
| 浏览器 DoH / Android 私人 DNS | 终端直接向外部解析 | 它可能绕过路由器上的两套服务 |
通过 SSH 登录 OpenWrt，查看 53、OpenClash 内部 DNS 端口以及你为 AdGuard 设置的端口分别由哪个进程监听。若 53 已被占用，另一个服务可能根本没有启动；若两个页面都显示运行，也可能靠防火墙重定向绕过了你以为的顺序。
ss -lntup | grep -E '(:53|:7874|:5335)'
uci show dhcp | grep -E 'server|port|noresolv'
logread | grep -Ei 'dnsmasq|AdGuardHome|OpenClash.*DNS' | tail -n 80先记下这些结果
- TCP 53 与 UDP 53 的监听进程
- AdGuard Home 的实际 DNS 监听地址和端口
- OpenClash 状态页显示的 DNS 监听端口
- dnsmasq 当前 server 指向
- 防火墙里是否存在 DNS redirect / hijack
- 修改前可恢复的 OpenWrt 与 AdGuard 配置备份
要保留 AdGuard 客户端统计，就让它先收到查询
这条路径可以写成“终端的 53 入口 → AdGuard Home → 127.0.0.1:7874 → OpenClash 外部上游”。在 OpenClash 的 DNS 设置里停用本地 DNS 劫持，避免防火墙把 LAN 的 53 查询提前截走。
在 AdGuard Home 的“设置 → DNS 设置 → 上游 DNS 服务器”里删除会产生分叉的其他上游，只保留当前 OpenClash 内核 DNS 监听地址。
127.0.0.1:7874 是 OpenClash 文档中的常见示例，不是可以盲抄的固定值。应从 OpenClash 状态、配置和 ss 输出确认实际端口。
AdGuard 使用 53、dnsmasq 移到其他端口，还是由 dnsmasq 转发到 AdGuard，取决于原来的 OpenWrt 集成。但经转发时，AdGuard 可能只看到转发者，不能保证每台终端的统计。同一条 LAN 查询也只能进入 AdGuard 一次。
改完后按查询顺序逐项确认
AdGuard 能启动
日志没有 bind: address already in use，TCP 与 UDP 监听都符合预期。
OpenClash DNS 在内部端口监听
本机能看到 7874 或实际端口由 Mihomo/OpenClash 占用。
关闭 OpenClash LAN DNS 劫持
重启后检查防火墙和启动日志，确认没有规则抢在 AdGuard 前面。
AdGuard 只转给 OpenClash
查询日志出现客户端地址，新的允许域名能得到响应。
更重视 Fake-IP 与规则一致性，就让 OpenClash 先接收查询
这条路径保留 OpenClash 的本地 DNS 劫持，并关闭 AdGuard Home 自己对 LAN 53 的重定向或劫持。让 AdGuard 只在一个不冲突的本机端口监听，例如 127.0.0.1:5335，再在 OpenClash“覆写设置 → DNS 设置”的自定义上游中填写这个实际地址。
AdGuard 的上游必须继续指向真正的外部 DNS，而不是 127.0.0.1:7874、路由器 LAN:53 或任何会重新进入 OpenClash 的地址。
OpenClash 接收终端查询，需要真实解析时再向 AdGuard 请求结果。Fake-IP 查询可能直接返回虚拟地址；通过代理的域名也可能由远端解析，不能保证 AdGuard 过滤全部域名。AdGuard 日志中的客户端往往只剩路由器本机。
LAN client
-> dnsmasq / OpenClash DNS hijack
-> OpenClash DNS
-> AdGuard Home 127.0.0.1:5335
-> external upstream DNS循环、端口占用与绕过过滤怎样区分？
日志反复出现同一域名，随后 SERVFAIL
常见原因：OpenClash 与 AdGuard 互相作为上游，形成查询循环
处理方法：按查询方向记录每个上游地址，删除把请求送回前一个服务的设置。
AdGuard 查询日志为空，但网页能打开
常见原因：查询可能被 OpenClash 或防火墙提前劫持 53，也可能由 Fake-IP、缓存或终端独立 DNS 处理
处理方法：若选择 AdGuard 在前，关闭冲突劫持并检查 NAT/nftables 规则顺序。
AdGuard 启动失败，提示 address already in use
常见原因：dnsmasq 或另一实例已占用相同地址与端口
处理方法：确定唯一的 53 监听者，再为内部转发选择不同本机端口。
电脑正常，手机偶尔绕过过滤
常见原因：IPv6 DNS、Android 私人 DNS 或浏览器 DoH 直接向外查询
处理方法：测试时统一关闭独立加密 DNS，并检查 DHCPv6/RDNSS 下发。
OpenClash 停止后全屋 DNS 失效
常见原因：唯一上游已指向停止监听的内核端口
处理方法：按修改前的记录恢复 dnsmasq 和 AdGuard 的上游，确认它们不再指向停用端口；从 LAN 终端查询未缓存域名，检查解析是否恢复。
缓存会遮住问题。调整服务顺序后重启相关服务，让测试终端清理 DNS 缓存或重新连接 Wi-Fi，再查询一个从未访问过的域名。反复打开已缓存的网站，只能证明旧答案还在。
验证过滤、分流与停用后的解析恢复
从一台测试电脑完成验收
确认终端 DNS
nslookup 输出的 Server 应是计划中的路由器或 AdGuard 地址，不是意外的公网 DNS。
查询允许域名
用未缓存域名测试，并确认查询是否实际转发到 AdGuard。需要真实解析时，AdGuard/OpenClash 应按选定方向处理；Fake-IP 答复本身不能证明两端都完成了查询。
查询过滤规则
在 AdGuard 临时添加一条测试规则，只验证实际经过它的查询是否符合过滤设置，再删除该规则；这不能证明所有代理域名都被过滤。
观察代理规则
访问需要代理的域名，OpenClash 连接记录应保留域名并命中预期策略。
分别重启服务
按实际启动顺序重启 AdGuard、dnsmasq 与 OpenClash，监听和上游方向不应变化。
执行回退
停用前记录并验证一套不依赖 OpenClash 的可达上游；停用后把 dnsmasq 和 AdGuard 的上游恢复到该设置，再从 LAN 终端查询未缓存域名。
nslookup example.com 192.168.1.1
nslookup www.iana.org 192.168.1.1确认 53 只有一个预期入口，AdGuard 能按选定顺序看到查询，OpenClash 能取得域名并执行规则，新域名查询不会循环超时。关闭任一组件后，也应能按预案恢复解析。只看两个页面显示“运行中”，不能确认这些结果。