On this page
Both management pages may say the services are running while devices at home still work intermittently. Repeatedly changing DNS ports makes the cause hard to identify. Follow where a query arrives first and where it is forwarded, choose between per-device filtering statistics and sending domains to proxy rules first, then check how resolution recovers when a service is disabled.
AdGuard and OpenClash Must Not Point Upstream to Each Other
OpenClash and AdGuard Home both want to process DNS, but have different roles. AdGuard Home handles filtering, rewrites, and query logs; the OpenClash core's DNS aligns name resolution with proxy rules. They can coexist as long as each query moves in only one direction.
Write down the DNS received by clients through DHCP, which service accepts router port 53, AdGuard's upstream, and the port where the OpenClash core listens. If a query eventually returns to an earlier service, it forms a loop.
Each query should follow the chosen direction. If another plugin also intercepts 53 or forwards DNS, disable one conflicting interception setup and establish the order of the two services. The upstream used by dnsmasq must match that path.
Choose a path based on the capabilities you want to keep
| Path | Query direction | Advantages | Tradeoff |
|---|---|---|---|
| AdGuard first | LAN DNS entry → AdGuard → OpenClash DNS → external upstream | AdGuard can more easily log each client and filter first | You must disable OpenClash's early interception of LAN 53 |
| OpenClash first | LAN / dnsmasq → OpenClash → AdGuard → external upstream | Domains enter OpenClash first, centralizing Fake-IP and rule handling | AdGuard usually sees only queries from the router/core, making individual devices hard to distinguish |
Confirm actual listeners and forwarding; do not rely only on LuCI toggles
Identify these entry points first
| Entry point | Common role | Do not confuse it with |
|---|---|---|
| Router TCP/UDP 53 | Default DNS endpoint used by LAN devices | dnsmasq and AdGuard cannot both exclusively bind the same address and port |
| AdGuard Home DNS listener | Receives queries, filters them, and forwards them upstream | Web administration ports such as 3000 are not DNS ports |
| OpenClash core DNS | Resolves according to the mode and coordinates with rules | A common internal listener is 127.0.0.1:7874, but verify it on the runtime page and in logs |
| Browser DoH / Android Private DNS | The client resolves directly through an external service | It may bypass both services on the router |
Connect to OpenWrt over SSH and identify which processes listen on 53, the internal OpenClash DNS port, and the port configured for AdGuard. If 53 is already occupied, the other service may never have started. Even if both pages say they are running, a firewall redirect may bypass the order you expected.
ss -lntup | grep -E '(:53|:7874|:5335)'
uci show dhcp | grep -E 'server|port|noresolv'
logread | grep -Ei 'dnsmasq|AdGuardHome|OpenClash.*DNS' | tail -n 80Record these results first
- Processes listening on TCP 53 and UDP 53
- Actual AdGuard Home DNS listening address and port
- DNS listening port shown on the OpenClash status page
- Current dnsmasq server target
- Whether the firewall contains a DNS redirect / hijack
- Recoverable backups of OpenWrt and AdGuard configuration before editing
If AdGuard client statistics matter, let it receive queries first
This path can be written as “client 53 entry → AdGuard Home → 127.0.0.1:7874 → OpenClash external upstream.” Disable local DNS interception in OpenClash DNS settings so the firewall does not capture LAN 53 queries too early.
Under “Settings → DNS Settings → Upstream DNS Servers” in AdGuard Home, remove other upstreams that create branches and keep only the current OpenClash core DNS listening address.
127.0.0.1:7874 is a common example in OpenClash documentation, not a fixed value to copy blindly. Confirm the actual port from OpenClash status, configuration, and ss output.
Whether AdGuard uses 53 and dnsmasq moves to another port, or dnsmasq forwards to AdGuard, depends on the existing OpenWrt integration. Forwarding may leave AdGuard seeing only the forwarder, so per-device statistics are not guaranteed. Each LAN query must also pass through AdGuard only once.
After editing, verify each step in query order
AdGuard starts
Logs contain no bind: address already in use, and both TCP and UDP listeners match expectations.
OpenClash DNS listens on an internal port
The local system shows 7874 or the actual port owned by Mihomo/OpenClash.
Disable OpenClash LAN DNS interception
After restarting, inspect the firewall and startup log to confirm that no rule runs ahead of AdGuard.
AdGuard forwards only to OpenClash
The query log shows client addresses, and a new allowed domain receives a response.
If Fake-IP and rule consistency matter more, let OpenClash receive queries first
This path keeps OpenClash local DNS interception and disables AdGuard Home's own redirect or interception of LAN 53. Let AdGuard listen on one nonconflicting local port, such as 127.0.0.1:5335, then enter that actual address under custom upstreams in OpenClash “Override Settings → DNS Settings.”
AdGuard's upstream must continue to point to a real external DNS service—not 127.0.0.1:7874, router LAN:53, or any address that reenters OpenClash.
OpenClash receives device queries and asks AdGuard for results when real resolution is needed. A Fake-IP query may return a virtual address directly, and a proxied domain may be resolved remotely, so AdGuard is not guaranteed to filter every domain. AdGuard logs will often show only the router as the client.
LAN client
-> dnsmasq / OpenClash DNS hijack
-> OpenClash DNS
-> AdGuard Home 127.0.0.1:5335
-> external upstream DNSHow to Distinguish Loops, Port Conflicts, and Filter Bypasses
The log repeatedly shows the same domain, followed by SERVFAIL
Common cause:OpenClash and AdGuard are each configured as the other's upstream, creating a query loop
Resolution:Follow the direction of the queries and record each upstream address, then remove the setting that sends requests back to the previous service.
The AdGuard query log is empty, but websites open
Common cause:Queries may be intercepted on 53 by OpenClash or the firewall before reaching AdGuard, or handled by Fake-IP, a cache, or a separate DNS service on the device
Resolution:If you choose AdGuard first, disable the conflicting interception and inspect NAT/nftables rule order.
AdGuard fails to start with address already in use
Common cause:dnsmasq or another instance already owns the same address and port
Resolution:Choose a single listener for 53, then use a different local port for internal forwarding.
Computers work, but phones occasionally bypass filtering
Common cause:IPv6 DNS, Android Private DNS, or browser DoH resolves externally
Resolution:For testing, disable independent encrypted DNS everywhere and inspect DHCPv6/RDNSS advertisements.
Household DNS fails when OpenClash stops
Common cause:The only upstream points to a core port that is no longer listening
Resolution:Restore the upstream settings for dnsmasq and AdGuard from your pre-change record, ensuring they no longer point to a stopped listener. Query an uncached domain from a LAN device to check that resolution has recovered.
Cache hides problems. After changing service order, restart the relevant services, clear DNS cache on the test client or reconnect its Wi-Fi, then query a domain never visited before. Repeatedly opening a cached website proves only that an old answer remains.
Verify Filtering, Routing, and Resolution Recovery After Shutdown
Complete acceptance from one test computer
Confirm the client's DNS
The Server in nslookup output should be the intended router or AdGuard address, not an unexpected public DNS server.
Query an allowed domain
Test an uncached domain and check whether the query actually reaches AdGuard. When real resolution is needed, AdGuard/OpenClash should process it in the chosen direction; a Fake-IP reply alone does not prove that both handled the query.
Query a filtering rule
Temporarily add a test rule in AdGuard, verify the filtering result only for queries that actually pass through it, then delete the rule. This does not prove that every proxied domain is filtered.
Observe proxy rules
Visit a domain that requires proxying; OpenClash connection records should retain the domain and match the expected policy.
Restart services separately
Restart AdGuard, dnsmasq, and OpenClash in the actual startup order; listeners and upstream direction should remain unchanged.
Execute rollback
Before disabling OpenClash, record and test reachable upstream servers that do not depend on it. After disabling it, restore those upstream settings in dnsmasq and AdGuard, then query an uncached domain from a LAN device.
nslookup example.com 192.168.1.1
nslookup www.iana.org 192.168.1.1Confirm that there is only one intended entry point on port 53, queries reach AdGuard in the configured forwarding order, OpenClash obtains domains and applies rules, and new domain queries do not time out in a loop. After either component is stopped, resolution should also be recoverable using the prepared plan. Seeing both pages show “running” does not establish these results.