If your private DNS setup isn’t behaving the way you expect, this guide on how to fix AdGuard Home errors covers the fixes for DNS leaks, upstream timeouts, broken TLS certificates, blocked ports, and confusing split-DNS setups.

The goal isn’t just to get AdGuard Home running; it’s to prove your private DNS is actually private.

Why Encrypted DNS Setups Break

AdGuard Home only protects your privacy if every device actually sends its DNS queries through it. Many setups look correct in the dashboard but silently leak queries around it, which is the core problem this guide to fix AdGuard Home errors is built to solve.

The most common cause is a mismatch between what you configured and what your devices are actually doing:

• The browser uses its own encrypted DNS
• Router falling back to a secondary server
• Bootstrap address that can’t reach your upstream provider.

Each of these breaks trust in the setup, even though AdGuard Home itself looks healthy.

For the initial setup, the AdGuard Home private DNS Server Setup guide covers the full deployment process.

Confirm Devices Are Actually Using AdGuard Home

Before touching any settings to fix AdGuard Home errors, you must check whether your device is even sending queries to AdGuard Home. This is the first step to fix AdGuard Home errors, because most “it’s not working” reports turn out to be a device talking to a different resolver entirely.

Run a lookup and check the server line:

nslookup example.org

Look at the Server: line in the output, it should show your AdGuard Home IP, not your router’s default or your ISP’s resolver.

Then, confirm the query appears in AdGuard Home. Open the dashboard and go to Query Log. If your test lookup doesn’t show up there, AdGuard Home isn’t actually receiving it, even if the nslookup result looked fine.

Finally, check the DHCP settings. If your router gives out its own DNS as a backup, some devices will use that instead of AdGuard Home. Log in to your router, go to DHCP settings, set the primary DNS to your AdGuard Home IP, and remove any secondary DNS entry.

Now you can follow the steps below to fix AdGuard Home errors:

Fix DNS Leaks from Bypassing Clients

DNS leaks happen when part of your traffic skips AdGuard Home and goes straight to another resolver, usually without any error message at all. This is one of the trickiest parts of any effort to fix AdGuard Home errors because the leak is invisible unless you test for it directly.

1. Test with a real leak checker

Visit a site like DNS Leak Test and run the extended test. If it shows your ISP’s resolver alongside AdGuard Home, something on your network is bypassing it.

2. Disable DNS-over-HTTPS in browsers

Modern browsers ship their own encrypted DNS that ignores your network’s resolver entirely:

• Chrome: chrome://settings/security → turn off “Use secure DNS“
• Firefox: about:preferences#privacy → turn off “DNS over HTTPS“
• Edge: edge://settings/privacy → turn off “Use secure DNS“

3. Block DoH providers at the network level

By doing this, leaks can’t happen even if a browser re-enables it later. In AdGuard Home, go to Filters > Custom filtering rules and add:

||dns.google^
||cloudflare-dns.com^
||doh.opendns.com^
||dns.quad9.net^
||mozilla.cloudflare-dns.com^

4. Recheck for VPN or router conflicts

If a VPN client is set to use its own DNS while AdGuard Home also tries to intercept it, both servers may appear in a leak test. Point your VPN’s DNS field directly at your AdGuard Home IP rather than leaving it blank or pointing at a public resolver.

Fix Upstream DNS Failures and Timeouts

If AdGuard Home receives queries but can’t resolve them, the problem lies with your upstream servers, not the client side. This step matters a lot to fix AdGuard Home errors related to slow or failed page loads.

1. Check your upstream list

In the dashboard, go to Settings > DNS settings > Upstream DNS servers and confirm the list isn’t empty.

2. Add reliable upstream servers

If the list is missing or has bad entries, add reliable upstream servers:

https://dns.cloudflare.com/dns-query
https://dns.google/dns-query
https://dns.quad9.net/dns-query

3. Test connectivity from inside the container

Use the command below to test the connectivity:

docker exec adguardhome nslookup google.com 1.1.1.1

A working response returns an IP address. If it times out, the container itself may lack internet access. Confirm with a basic ping:

docker exec adguardhome ping -c 3 1.1.1.1

4. Fix the bootstrap DNS if upstream servers use hostnames

DNS-over-HTTPS and DNS-over-TLS upstreams need a working bootstrap resolver to find their own IP address first. In Settings > DNS settings > Bootstrap DNS servers, use plain IPs like 1.1.1.1 and 9.9.9.9 instead of another hostname-based server, which can create a circular failure.

Fix HTTPS Certificate Errors

Certificate errors usually show up when AdGuard Home’s encryption settings and your reverse proxy disagree about who’s handling TLS. Getting this right matters to fix AdGuard Home errors that block encrypted DNS-over-HTTPS clients specifically.

First, you must decide where TLS terminates. If a reverse proxy like Caddy or Nginx already handles HTTPS in front of AdGuard Home, don’t also enforce TLS inside AdGuard Home itself.

Then, allow unencrypted DoH behind the proxy. In AdGuardHome.yaml, set:

allow_unencrypted_doh: true

This tells AdGuard Home it’s fine to answer DoH requests without its own TLS layer, since the proxy is already encrypting the connection to clients.

Next, pass real client IPs through the proxy. Set trusted_proxies in AdGuardHome.yaml to your proxy’s IP address, otherwise every request will look like it comes from the proxy itself, breaking per-client filtering.

Restart and re-check the certificate chain:

docker compose restart adguardhome
openssl s_client -connect yourdomain.com:443 -servername yourdomain.com

Look for “Verify return code: 0 (ok)” in the output, anything else usually means the certificate chain is incomplete, or the domain doesn’t match what’s configured.

Fix Blocked Ports and Address Already in Use

Port 53 conflicts are one of the most common installation-stage errors, and they resurface any time you move AdGuard Home to a new server.

Check what’s using port 53:

sudo ss -tulnp | grep :53

Free the port if systemd-resolved is holding it:

sudo mkdir -p /etc/systemd/resolved.conf.d
echo -e "[Resolve]\nDNSStubListener=no" | sudo tee /etc/systemd/resolved.conf.d/adguardhome.conf
sudo systemctl restart systemd-resolved
sudo ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf

Confirm Docker port bindings if you’re running in a container:

docker port adguardhome

You should see 53/tcp, 53/udp, and your web UI port is mapped to 0.0.0.0. If port 53 is missing, add it to your docker-compose.yml ports section.

Check firewall rules on the host:

sudo ufw allow 53/tcp
sudo ufw allow 53/udp
sudo ufw allow 3000/tcp

Fix Split-DNS and Local Domain Confusion

Split-DNS setups, where some domains resolve locally, and everything else goes upstream, usually break silently when local domain rules and upstream rules overlap. Sorting this out is part of any complete effort to fix AdGuard Home errors on a home or office network with local services.

First, check DNS rewrites. Go to Filters > DNS rewrites and confirm there’s no leftover rule pointing a real domain to the wrong internal IP.

Then, separate local and public domains cleanly. Use a private suffix like .home.arpa or .lan for internal devices and rely on your upstream servers for everything else, rather than mixing both in one zone.

Verify with a targeted lookup:

nslookup myserver.home.arpa your-adguard-ip
nslookup example.com your-adguard-ip

The first should return your internal IP, and the second should return a public IP from your upstream provider. If both return the wrong result, the rewrite rules or upstream conditional forwarding need review.

If you’re also running DNS-over-HTTPS on a router like MikroTik alongside AdGuard Home, the MikroTik DNS-over-HTTPS setup guide covers how to keep both layers from conflicting.

Fix AdGuard Home Errors | Privacy Validation Checklist

Run through this list after any change to confirm your setup is actually private, not just running:

• The query log shows every test lookup you make.
• DNS Leak Test shows only your intended upstream, no ISP resolver.
• Browser secure DNS settings are off on all client devices.
• Upstream servers respond correctly from inside the container.
• Bootstrap DNS uses plain IPs, not hostnames.
• Certificate check with openssl returns a valid chain.
• DHCP hands out only the AdGuard Home IP, no secondary resolver.

A private DNS server that leaks or times out under normal use isn’t doing its job, no matter how good the dashboard looks. Every fix in this guide to fix AdGuard Home errors, leak testing, upstream checks, certificate alignment, port conflicts, and split-DNS rules, works together as one system, not separate patches.

If your VPS can’t keep up with all the DNS queries and TLS handshakes, it’s time for an upgrade. Moving to a stronger PerLod Linux VPS gives your resolver enough power to handle encrypted DNS smoothly, without timing out.

Conclusion

Most AdGuard Home problems depend on five things: devices not actually using it, leaks from browser DoH, bad upstream or bootstrap servers, mismatched TLS settings, and blocked ports. Work through the checklist above after every change, and you’ll know for certain whether your private DNS is actually private, not just running.

We hope you enjoy this guide to fix AdGuard Home errors.

For deeper detail on AdGuard Home’s official troubleshooting steps and known limitations, you can check the AdGuard Home knowledge base.

FAQs