AdGuard Home: network-wide ad and tracking blocker

Ads and trackers are blocked most effectively not in the browser, but in DNS – there, where every device asks which IP belongs to a domain. AdGuard Home is a self-hosted DNS server that simply lets requests to known ad, tracking and malicious domains run into the void. One server, all devices – phone, TV, laptop – without a single app on the client.

What are we building?

By the end, AdGuard Home v0.107.78 runs as a DNS server on your VPS. It answers DNS requests, filters out ads/trackers/malware based on block lists, and shows you live in a web interface what was blocked. Concretely:

• a DNS filter with over 150,000 rules (default block list), extensible with any lists,
• a web interface with statistics and a query log, secured behind your reverse proxy,
• the DNS service reachable exclusively via your WireGuard tunnel – not open on the internet.

The last point is decisive and the reason this tutorial requires WireGuard: an open DNS resolver on the internet is abused within hours for DNS amplification attacks. So we bind the DNS port to the VPN interface, and only your own devices talk to it via the tunnel.

Prerequisites

• A server with Docker and a running Traefik reverse proxy (for the web interface under its own domain with TLS).
• A set-up WireGuard VPN with the server interface wg0 at 10.8.0.1. Your devices later reach the DNS server through it.
• Basic understanding of DNS (domain → IP) helps but isn’t a must.

AdGuard Home is extremely frugal – it gets by with a few tens of MB of RAM. The smallest plan is plenty, especially since it probably runs alongside other services at your place anyway.

Step by step

Step 1: Is port 53 free?

AdGuard Home needs port 53 – the DNS port. On some systems systemd-resolved already occupies it. Check that:

ss -tulpn | grep ":53 "

On the netcup Debian 13 image used here, the port was free (no systemd-resolved active), so the output was empty. If you instead get a line with systemd-resolve, you have to disable its stub listener – otherwise AdGuard won’t start (“address already in use”):

sudo mkdir -p /etc/systemd/resolved.conf.d
echo -e "[Resolve]\nDNSStubListener=no" | sudo tee /etc/systemd/resolved.conf.d/adguard.conf
sudo systemctl restart systemd-resolved

Step 2: Create the Docker Compose

Create the project folder:

mkdir -p /opt/adguardhome/work /opt/adguardhome/conf && cd /opt/adguardhome

Create the compose.yaml:

services:
  adguardhome:
    image: adguard/adguardhome:v0.107.78
    container_name: adguardhome
    restart: unless-stopped
    volumes:
      - ./work:/opt/adguardhome/work
      - ./conf:/opt/adguardhome/conf
    ports:
      - "10.8.0.1:53:53/tcp"
      - "10.8.0.1:53:53/udp"
    networks:
      - proxy
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.adguard.rule=Host(`YOUR_DOMAIN`)"
      - "traefik.http.routers.adguard.entrypoints=websecure"
      - "traefik.http.routers.adguard.tls.certresolver=le"
      - "traefik.http.services.adguard.loadbalancer.server.port=3000"

networks:
  proxy:
    external: true

The most important things:

• ports: "10.8.0.1:53:53" – the DNS port is bound only to the WireGuard address, not to 0.0.0.0. This makes the resolver reachable exclusively via the VPN tunnel and never open on the internet. This one line is the difference between “secure” and “abused for attacks”.
• The web interface runs on container port 3000 and is published under YOUR_DOMAIN with TLS via the four Traefik labels. Replace YOUR_DOMAIN with your real domain.
• Both volumes (work, conf) make the configuration and statistics persistent.

Start the container:

docker compose up -d

Check that it’s running:

docker compose ps

You should see Up and that port 53 is bound to 10.8.0.1.

Step 3: The initial setup

Open your domain in the browser – you land in the setup wizard. At the bottom right you can set the language.

Click through the five steps. Two settings are important:

• Admin web interface: as the port you must enter 3000 (All interfaces, port 3000) – because that’s exactly where Traefik forwards. The suggestion is often port 80; if you don’t change it, the interface is no longer reachable via Traefik after the setup.
• DNS server: port 53 (All interfaces). The restriction to the VPN interface is already handled by the port binding from the Compose – inside the container, AdGuard may listen on all interfaces.

Then you create a username and a strong password for the login. Done – you’re redirected to the login.

Step 4: The dashboard

After logging in you see the overview: number of requests, how many of them were blocked, the most frequently requested and the most frequently blocked domains.

At first everything is at zero – it fills up as soon as the first device uses AdGuard as its DNS (step 6).

Step 5: Manage block lists

Under Filters → DNS blocklists you see the active block lists. By default the AdGuard DNS filter is active – for us with 159,173 rules.

Via Add blocklist you can include more curated lists (AdGuard brings a catalog, e.g. AdAway or OISD). Less is often more: one or two good lists block most, without legitimate sites constantly breaking. With Check for updates you update the rules manually; AdGuard otherwise keeps them current automatically (see “Maintenance”).

Step 6: Switch devices to AdGuard

For your devices to use the filter, they have to use AdGuard as their DNS server. Via the WireGuard tunnel this works most elegantly centrally in the client configuration: enter the server’s tunnel address as DNS in the [Interface] section of your WireGuard clients:

[Interface]
# ... your existing lines ...
DNS = 10.8.0.1

As soon as the tunnel is up, the device sends all DNS requests to AdGuard – whether on Wi-Fi on the go or on the mobile network. No intervention at the router needed, and the protection works on the go too.

Step 7: Does it really work?

Check the resolver directly on the server via the VPN address. A normal domain must resolve:

dig @10.8.0.1 +short example.com

172.66.147.243

A known tracking domain must be blocked – AdGuard then answers with 0.0.0.0:

dig @10.8.0.1 +short doubleclick.net

0.0.0.0

As a counter-check that the resolver does not listen openly, you query it via the loopback address – that must fail:

dig @127.0.0.1 +time=2 +tries=1 example.com

;; communications error to 127.0.0.1#53: connection refused

Exactly as it should be: reachable via 10.8.0.1 (the tunnel), rejected on all other addresses. A look at the query log in the web interface shows the same requests live – blocked entries are marked red and name the list that took effect:

When things go wrong

Maintenance & backups

Block-list updates. AdGuard updates the lists automatically (default: every 24 hours). You don’t have to do anything here; a manual Check for updates is possible any time if needed.

Backups. The entire configuration is in /opt/adguardhome/conf/AdGuardHome.yaml – admin login, DNS settings, lists, exceptions. You back up this file (plus the work folder with the statistics) regularly, e.g. via Restic. This way a server migration is done in minutes: bring up the container, restore conf, done.

Updates. You fetch new versions like with any Compose stack. Pin the tag deliberately (not latest) so updates happen in a controlled way:

cd /opt/adguardhome
docker compose pull && docker compose up -d

Privacy. The query log stores which device requested which domain – that’s gold for troubleshooting, but also sensitive. Under Settings → General settings you can shorten the retention period of the log or disable logging entirely. Especially when other people share your DNS, a short retention is fair.