本文目錄
OpenClash 和 AdGuard Home 一起開就斷網，先畫清 DNS 路徑
OpenClash 和 AdGuard Home 都想處理 DNS，但職責不同：AdGuard Home 負責過濾、重寫和查詢記錄，OpenClash 的核心 DNS 負責讓網域解析與代理規則配合。兩者可以共存，前提是一條查詢只沿一個方向前進。
出現「國內能開、部分網域超時」「AdGuard 查詢日誌為空」「OpenClash 開啟後全屋 SERVFAIL」時，不要急著更換上游。
寫下終端從 DHCP 得到的 DNS、路由器 53 連接埠由誰接收、AdGuard 的上游是誰、OpenClash 核心監聽在哪個連接埠。只要查詢最終又回到前一個服務，就會形成循環。
先識別幾個入口
| 入口 | 常見作用 | 不要混淆 |
|---|---|---|
| 路由器 TCP/UDP 53 | LAN 裝置預設存取的 DNS 入口 | 同一個位址連接埠不能同時被 dnsmasq 與 AdGuard 獨佔 |
| AdGuard Home DNS 監聽 | 接收查詢、過濾並轉給上游 | 3000 等 Web 管理連接埠不是 DNS 連接埠 |
| OpenClash 核心 DNS | 按模式解析並配合規則 | 常見內部監聽為 127.0.0.1:7874，但應以執行頁和日誌為準 |
| 瀏覽器 DoH / Android 私人 DNS | 終端直接向外部解析 | 它可能繞過路由器上的兩套服務 |
確認實際監聽和轉發，不要只看 LuCI 開關
透過 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 設定備份
兩種接法都能工作，但只能選一個方向
OpenClash 官方 DNS 說明給出的原則很直接：它應成為 dnsmasq 的唯一上游；如果另一個外掛程式也會劫持 53 或轉發 DNS，就停掉其中一套劫持，並明確兩個服務的先後順序。
實際使用中，可以把 AdGuard 放在 OpenClash 前面，也可以讓 OpenClash 接收查詢後再呼叫 AdGuard。
根據你想保留的能力選路徑
| 路徑 | 查詢方向 | 優點 | 取捨 |
|---|---|---|---|
| AdGuard 在前 | LAN DNS 入口 → AdGuard → OpenClash DNS → 外部上游 | AdGuard 更容易記錄每台終端並先做過濾 | 必須關閉 OpenClash 對 LAN 53 的搶先劫持 |
| OpenClash 在前 | LAN / dnsmasq → OpenClash → AdGuard → 外部上游 | 網域先進入 OpenClash，Fake-IP 與規則路徑更集中 | 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 整合。無論採用哪種方式，LAN 的 53 最終只能進入 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 請求實際上游結果。AdGuard 日誌中的用戶端往往只剩路由器本機，這是這種接法的正常代價。
LAN client
-> dnsmasq / OpenClash DNS hijack
-> OpenClash DNS
-> AdGuard Home 127.0.0.1:5335
-> external upstream DNS三個常見問題看起來都像「DNS 很慢」，處理方法卻不同
日誌反覆出現同一網域，隨後 SERVFAIL
常見原因：OpenClash 與 AdGuard 互相作為上游，形成查詢循環
處理方法：沿上游位址逐個畫箭頭，刪掉回到前一層的那一項。
AdGuard 查詢日誌為空，但網頁能開啟
常見原因：OpenClash 或防火牆在 AdGuard 前劫持了 53
處理方法：若選擇 AdGuard 在前，關閉衝突劫持並檢查 NAT/nftables 規則順序。
AdGuard 啟動失敗，提示 address already in use
常見原因：dnsmasq 或另一實例已佔用相同位址與連接埠
處理方法：確定唯一的 53 監聽者，再為內部轉發選擇不同本機連接埠。
電腦正常，手機偶爾繞過過濾
常見原因：IPv6 DNS、Android 私人 DNS 或瀏覽器 DoH 直接向外查詢
處理方法：測試時統一關閉獨立加密 DNS，並檢查 DHCPv6/RDNSS 傳送。
OpenClash 停止後全屋 DNS 失效
常見原因：唯一上游已指向停止監聽的核心連接埠
處理方法：準備一鍵還原到可達的外部 DNS，或讓停用指令碼同步恢復 dnsmasq 上游。
快取會遮住問題。調整服務順序後重啟相關服務，讓測試終端清理 DNS 快取或重新連線 Wi-Fi，再查詢一個從未存取過的網域。反覆開啟已快取的網站，只能證明舊答案還在。
最後同時驗證過濾、分流和停機還原
從一台測試電腦完成驗收
確認終端 DNS
nslookup 輸出的 Server 應是計劃中的路由器或 AdGuard 位址，不是意外的公用網路 DNS。
查詢允許網域
使用一個未快取網域，回應時間正常且 AdGuard/OpenClash 日誌按選定順序出現。
查詢過濾規則
在 AdGuard 臨時新增一條測試規則，確認回傳符合過濾設定，再刪除該規則。
觀察代理規則
存取需要代理的網域，OpenClash 連線記錄應保留網域並命中預期策略。
分別重啟服務
按實際啟動順序重啟 AdGuard、dnsmasq 與 OpenClash，監聽和上遊方向不應變化。
執行還原
停用 OpenClash 時，按預案把 DNS 恢復到可達上游，LAN 裝置仍能解析普通網域。
nslookup example.com 192.168.1.1
nslookup www.iana.org 192.168.1.1驗收透過的結果應很具體：53 只有一個預期入口，AdGuard 能按選定拓撲看到查詢，OpenClash 能拿到網域並執行規則，新網域沒有循環超時，關閉任一元件時也有明確還原。做到這些，比把兩個頁面都調成「執行中」更重要。