本文目錄
兩個管理頁面都顯示執行中，家裡的裝置卻時好時壞，這時反覆更換 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 能取得網域並執行規則，新網域查詢不會循環逾時。關閉任一元件後，也應能按事先準備的方案恢復解析。只看兩個頁面顯示「執行中」，不能確認這些結果。