AdGuard Home Not Blocking Ads? DNS Fixes
Use the AdGuard Home query log to diagnose missing filtering, DNS bypass, IPv6, browser encrypted DNS, and client exceptions.
AdGuard Home not blocking ads? Start with its Query Log while reproducing the problem on one device. A missing request, an allowed request, and a blocked request with an advertisement still visible point to different fixes. Establish which situation you have before changing router settings or adding more blocklists.
Start with one device and one fresh lookup
Choose a laptop or desktop connected to your home network. Record its current DNS settings and the local address of your AdGuard Home server. Keep the administration page open, select Query Log, and remove any search or status filters that could hide your test. Confirm query logging is enabled for the test client. A quiet log alone does not prove DNS is bypassing the server.
Use a normal domain first, such as example.org, rather than judging success by whether a complicated news page looks different. Note the time, perform a lookup, and look for the corresponding entry. Check the requested domain, client address, result, and any matching rule. If your router forwards DNS, the client shown may be the router instead of the individual device.
The first objective is reliable evidence: this request reached this server at this time. The official AdGuard Home troubleshooting FAQ uses the default DNS server and Query Log as starting points, then checks filtering and exceptions. Keep those checks separate so a browser advertisement does not become your only diagnostic instrument.
Compare an explicit server query with the default resolver
Open a terminal and run nslookup example.org 192.168.1.10, replacing the example address with your AdGuard Home server's actual LAN address. This explicitly asks that server. A successful answer and matching log entry demonstrate that the device can reach AdGuard Home for this query. They do not demonstrate that the device normally chooses it.
Next run nslookup example.org without a server argument. Read the server address in the output and compare the log. If the explicit lookup works but the default lookup goes elsewhere, focus on the client's DNS configuration or the settings supplied by your router. Installing another blocklist cannot repair that routing decision.
A local loopback address or your router's address can represent a forwarding resolver. Trace its next destination before deciding it is wrong. Conversely, a successful command-line lookup does not prove your browser follows the same path: browser encrypted DNS and VPN software can introduce separate choices. Our guide to understanding DNS explains the difference between a device asking for an answer and the resolver obtaining it.
Write down three observations before continuing: which server the command selected, whether the query appeared in the log, and whether the response was allowed or blocked. This small record prevents a common troubleshooting loop where several settings change and nobody knows which change mattered. If the selected server is correct but the entry is absent, verify the log's time range and client exclusions before investigating network interception. Repeat the lookup once with a different ordinary domain to avoid confusing an old entry with the new request.
If direct queries fail, check the local service path
When an explicit query times out, first confirm that the server is running and that its LAN address has not changed. Loading the dashboard proves the web interface is accessible; DNS uses a different service and port. Check the configured listening interface, service logs, and whether another resolver already occupies port 53 on the host.
Allow DNS traffic from the intended local network through the host firewall. Ordinary DNS needs UDP and TCP port 53; checking only one transport leaves an incomplete setup. Guest Wi-Fi isolation, separate VLANs, or a container network can prevent clients from reaching the server even though a test performed on the server itself succeeds.
For containers, compare the published ports and bind addresses with the official AdGuard Home Docker documentation. Publishing a dashboard port does not publish DNS. Preserve the persistent configuration volumes when adjusting the container. Diagnose the specific missing path before recreating a working installation.
Keep this access restricted to your LAN or an authenticated private network. Opening port 53 to the internet is not a solution to local reachability. Do not add a WAN port-forward or disable the entire firewall to make a household device work; correct the local interface, subnet rule, or container mapping responsible.
Check router DHCP and every advertised DNS address
Once explicit queries work, inspect how devices receive their settings. Router WAN DNS and LAN DHCP DNS can be different controls. Changing the upstream resolver used by the router does not necessarily change the DNS servers it advertises to clients. Find the setting that governs your actual LAN, including a separate guest network if that is where the affected device connects.
Reserve a stable local address for AdGuard Home. Configure the intended clients to use it, then reconnect a test device or renew its lease and inspect the resulting settings. An old lease can preserve an earlier resolver address after the router configuration has changed. Keep a record of both the router change and what the client actually received.
Do not assume a second DNS address is used only after the first fails. Client selection varies, so an unfiltered public resolver in that field creates an available bypass. If you need redundant DNS with the same policy, both advertised resolvers must provide that policy. Otherwise, a working primary server can coexist with inconsistent blocking.
The official device configuration guide covers router and individual-device setup. Begin with one device if you are unsure about the router interface. Proving the intended settings there gives you a reference before changing DNS for everyone sharing the connection.
Inspect IPv6 instead of assuming IPv4 covers everything
A device can receive the correct IPv4 DNS address and still learn another resolver over IPv6. Inspect the active connection for both families. Depending on your router and clients, IPv6 resolver information may arrive through router advertisements or DHCPv6. Review the LAN IPv6 settings alongside the IPv4 DHCP settings rather than relying on a single screenshot.
When your network supports IPv6, ensure the advertised resolver path reaches the intended filtering server and that its IPv6 address remains usable. If the router advertises itself, inspect where it forwards queries. Repeat the explicit and default lookup comparison after changing the advertisement, and give the client an opportunity to refresh its network configuration.
Do not confuse an AAAA answer with an IPv6 DNS bypass. A query sent to AdGuard Home over IPv4 can legitimately return an IPv6 address for a website. The transport used to reach the resolver and the record returned are separate details. Turning off IPv6 everywhere may hide the symptom while leaving the actual configuration mistake unexplained.
Check browser encrypted DNS, private DNS, and VPNs
If terminal queries reach AdGuard Home but browsing produces no relevant entries, inspect the browser's secure DNS setting. A browser using an independent DNS-over-HTTPS provider can avoid the local resolver. Android Private DNS, device profiles, security applications, and VPN clients can also change where queries go. Look at the affected application and active network connection together.
For diagnosis, record the original choice and briefly switch one test browser to the system resolver. Reproduce the same page and inspect the log. Restore or deliberately reconfigure the setting afterward. Encryption itself is not the problem: the important question is which server receives the encrypted requests and whether that server applies your intended policy.
A DNS leak test can show the public resolvers involved in browser lookups. It usually cannot identify your private AdGuard Home address, and seeing its configured upstream provider can be expected. Correlate the test time with local query entries instead of treating a public resolver name as proof of failure. See our privacy settings guide for the broader distinction between individual application choices and network defaults.
Check the resolver, then verify the filtering
A browser DNS test shows outward-facing resolvers, not whether your local AdGuard Home filter handled a request. Compare the result with your Query Log before changing settings.
If requests arrive, inspect filtering and exceptions
An allowed query means you have moved beyond basic reachability. Confirm protection is active, domain filtering is enabled, and the intended DNS blocklists are enabled and have updated successfully. Pick the actual hostname from the query entry. A website's main domain and the separate hostname serving an advertisement may need different treatment.
Inspect allowlists, custom exceptions, and DNS rewrites before adding a new blocking rule. The log may identify why a request was allowed or which rule matched. Change the narrowest relevant setting and repeat the lookup. Avoid removing every exception at once: an older exception may exist because a required login, payment, or streaming feature depended on it.
Also inspect the affected client's settings. AdGuard Home supports individual policies, so global filtering can work while one client has an exception. The official client configuration reference describes client identities and per-client rules. Verify the identity currently shown in the log rather than assuming a remembered address still belongs to that device.
If several clients appear under the router's address, changing that client policy may affect all of them. Document that limitation before testing exceptions. A useful result is one explained query with a known policy, not a larger blocked percentage whose cause you cannot identify.
Understand upstream DNS and cache timing
The DNS server configured on your device is the first destination for its queries. The upstream server configured inside AdGuard Home answers requests that AdGuard Home forwards. Changing upstream providers does not redirect a device that never contacts AdGuard Home. Keep these two configuration layers distinct when comparing router, device, and dashboard settings.
The AdGuard Home configuration reference documents upstream and cache controls. Before adjusting them, decide whether the symptom is a timeout, an unexpected answer, or an absent query. Each calls for different evidence. A server restart is a blunt diagnostic tool when the query log already identifies a matching exception.
After a rule change, a device or application may retain a previously resolved address until its cache expires. Existing connections and already downloaded advertisements can also survive a page refresh. Repeat a direct lookup, compare the latest log result, and reopen the application when appropriate. Clear only the relevant cache or wait for the applicable TTL before concluding the new rule failed.
Recognize ads that DNS cannot separate from content
AdGuard Home makes decisions about domain lookups. When advertising and wanted content share a hostname, blocking that hostname can break both. YouTube advertisements and sponsored social content are therefore poor universal pass-or-fail tests for a DNS blocker. A visible advertisement does not automatically mean the client bypassed your resolver.
The official comparison with traditional ad blockers explains the limits of DNS filtering. A browser content blocker can work with page elements and requests at a different layer. DNS filtering also does not reliably remove empty spaces that a page reserves for advertisements.
Use the log to distinguish an uncovered advertising domain from content delivered through an allowed shared domain. Adding many overlapping lists cannot give DNS information about individual video segments or page elements. If the missing capability is content-level filtering, choose a compatible content blocker rather than repeatedly disrupting domains the website needs.
Verify the fix and keep a practical rollback
Repeat the same test on the original device, then on a second device using the same network. Confirm that expected requests arrive, ordinary sites resolve, and a hostname covered by an enabled rule is recorded as blocked. Check one service that matters to the household, such as work sign-in or video calling, before extending the change.
Keep the former router DNS values and a backup of the AdGuard Home configuration. If a change breaks resolution, restore the previous client or router settings, reconnect the test device, and investigate the failed step. Do not leave an accidental public fallback in place and assume every device is still filtered.
When connectivity is failing beyond DNS, follow the internet outage checks before blaming filtering. If an upstream network needs investigation, identify your ISP and record the symptoms precisely. Keep query logs private; they can reveal household browsing patterns. Share only redacted entries needed to explain a specific failure.
Frequently asked questions
Why does AdGuard Home work on one device but not another?
The devices may use different DNS servers, browser encrypted DNS settings, VPNs, IPv6 advertisements, or client policies. Compare a direct query to AdGuard Home with each device's default lookup, then inspect the matching Query Log entries.
Should I add a public secondary DNS server?
A public secondary resolver can bypass local filtering because clients do not universally treat it as emergency-only fallback. For consistent filtering, every advertised resolver must apply the intended policy.
Can AdGuard Home block every YouTube advertisement?
No. DNS filtering cannot reliably separate advertisements from wanted content when they share a hostname. Check that queries reach AdGuard Home, but do not use YouTube advertisements alone to judge whether DNS filtering works.
Primary sources
Standards, registries, and first-party references used to verify this guide:
- AdGuard Home troubleshooting FAQ (opens in a new tab) - AdGuard. Primary documentation supporting the troubleshooting workflow.
- official AdGuard Home Docker documentation (opens in a new tab) - AdGuard. Primary documentation supporting the troubleshooting workflow.
- official device configuration guide (opens in a new tab) - AdGuard. Primary documentation supporting the troubleshooting workflow.
- official client configuration reference (opens in a new tab) - AdGuard. Primary documentation supporting the troubleshooting workflow.
- AdGuard Home configuration reference (opens in a new tab) - AdGuard. Primary documentation supporting the troubleshooting workflow.
- comparison with traditional ad blockers (opens in a new tab) - AdGuard. Primary documentation supporting the troubleshooting workflow.
Did this article help?
IP Trackers is free with no sign-up. A small contribution helps keep the guides current and the tools running.
