AdGuard Home auf dem Raspberry Pi mit Docker – Praxisanleitung

AdGuard Home auf dem Raspberry Pi: Warum ich es im Heimnetz einsetze

Die erste Version dieser Anleitung enthielt noch Raspberry-Pi-Preise aus dem Jahr 2021, eine Installation per curl | sh und – was ich heute als Erstes ändern würde – den Vorschlag, das AdGuard-Home-Webinterface über eine Portweiterleitung auf Port 3000 ins Internet zu stellen. Seitdem hat sich AdGuard Home weiterentwickelt, meine Nutzung ebenfalls, und auch die Preise sowie die Frage, welche Boards sich heute sinnvoll kaufen lassen, sehen anders aus. Statt den alten Text immer weiter zu flicken, war es sinnvoller, ihn neu aufzubauen.

Das Ziel ist gleich geblieben: Ich möchte einen zentralen Punkt im Heimnetz, der DNS für Smartphones, Rechner, Fernseher und andere Geräte filtert. Ohne auf jedem Gerät einen eigenen Adblocker zu installieren. Dazu kommen Safe Search, Sicherheitslisten, das Blockieren eines Teils der Telemetrie und vor allem das sehr hilfreiche Query Log, wenn eine App plötzlich nicht mehr funktioniert und ich wissen möchte, warum.

AdGuard Home ist genau so ein lokaler DNS-Server. In dieser Anleitung zeige ich meinen heutigen Aufbau: AdGuard Home auf dem Raspberry Pi mit Docker. Derselbe Server kann aber genauso auf einem normalen Linux-System, einem NAS oder einem anderen Docker-Host laufen. Ein Raspberry Pi ist weiterhin praktisch, weil er rund um die Uhr laufen kann und dafür keine großen Ressourcen braucht.

Was AdGuard Home kann – und was nicht

Hier entstehen schnell falsche Erwartungen: AdGuard Home filtert auf DNS-Ebene. Wenn eine App eine Domain aufrufen möchte, die auf einer Blockliste steht, kann der lokale DNS-Server diese Domain blockieren, bevor das Gerät überhaupt eine Verbindung dorthin aufbaut.

Das funktioniert gut bei vielen Werbenetzwerken, Trackern, Telemetrie-Domains, Phishing-Zielen und Teilen von Malware-Infrastruktur. Es ist aber kein Antivirus und ersetzt keinen Endpoint-Schutz. Es entfernt auch nicht jede Werbung. Wenn ein Dienst Werbung über dieselbe Domain wie seinen eigentlichen Inhalt ausliefert, würde eine DNS-Sperre auch den Dienst selbst treffen. Direkt eingebettete Werbung auf manchen Videoplattformen ist deshalb ein anderes Problem als klassische Werbetracker.

Das ist wichtig, wenn man Filterlisten auswählt. Mehr Regeln bedeuten nicht automatisch besseren Schutz. Manchmal bedeuten sie nur mehr Dinge, die später untersucht werden müssen.

Welche Hardware ist sinnvoll?

AdGuard Home braucht keinen leistungsstarken Rechner. Für eine kleine dedizierte Installation kann 1 GB RAM weiterhin ausreichen. Wenn ich heute allerdings Hardware nur für DNS kaufen würde, würde ich 2 GB nehmen. Nicht weil AdGuard selbst besonders schwergewichtig wäre, sondern weil mit der Zeit größere Filterlisten, Docker und Updates dazukommen können. In meiner aktuellen Konfiguration geht die Zahl der Regeln bereits in die Millionen, und in so einem Szenario möchte ich ein neues Gerät nicht unnötig knapp dimensionieren.

Affiliate-Hinweis: Einige der folgenden Hardware-Links sind Amazon-Partnerlinks. Als Amazon-Partner verdiene ich an qualifizierten Verkäufen. Für dich entstehen dadurch keine zusätzlichen Kosten. Ich verlinke nur Produkte, die zu dem beschriebenen Aufbau passen; ich behaupte nicht, jedes konkrete Modell persönlich getestet zu haben.

Am einfachsten: Raspberry Pi 4 2 GB als Komplettset

Wenn du die Einzelteile nicht selbst zusammensuchen möchtest, ist ein Komplettset mit Raspberry Pi 4 2 GB der unkomplizierteste Einstieg. Beispiele sind zwei db-tronic-Varianten: rot-weißes 2-GB-/64-GB-Set und schwarzes 2-GB-/64-GB-Set. Beide enthalten Board, 15-W-Netzteil, Gehäuse, Kühlkörper, 64-GB-Karte und ein Micro-HDMI-Kabel.

Für einen headless betriebenen AdGuard-Server braucht man das HDMI-Kabel nicht; in einem Komplettset bleibt es einfach als Reserve. Wichtiger ist die Speicherkarte: Die mitgelieferte 64-GB-Karte wird nicht als High-Endurance-Modell beschrieben. Ich würde sie daher nicht mit einer Karte gleichsetzen, die ausdrücklich für dauerhaften Betrieb mit häufigen Schreibzugriffen ausgelegt ist.

Mein bevorzugter Aufbau für 24/7-Betrieb

Wenn du den Aufbau selbst zusammenstellen möchtest, ist für mich ein sinnvoller Startpunkt ein Raspberry Pi 4 Model B mit 2 GB, das offizielle USB-C-Netzteil 5,1 V / 3 A, ein passives Aluminiumgehäuse von Miuzei und eine SanDisk High Endurance 64 GB. Für einen DNS-Server, den das gesamte Netz nutzt, bevorzuge ich Ethernet statt WLAN. Falls du ein kurzes Patchkabel brauchst, ist ein Beispiel das PremiumCord Cat6a, 1,5 m.

Cat6a ist hier keine Voraussetzung. Der Raspberry Pi 4 hat Gigabit Ethernet, und ein ordentliches Cat5e-Kabel reicht ebenfalls aus. Ich nenne dieses konkrete Kabel, weil es kurz, geschirmt und aus Kupfer ist – nicht weil AdGuard Cat6a benötigen würde.

Orange Pi Zero3 als Alternative

AdGuard Home ist nicht an Raspberry Pi gebunden. Es kann genauso auf anderen kleinen ARM-Rechnern laufen. Eine Alternative ist der Orange Pi Zero3 mit 2 GB. Technisch eignet er sich sehr gut für diese Aufgabe. Ich gehe aber nicht davon aus, dass er automatisch günstiger ist als ein Raspberry Pi. Wenn beide Varianten am Kauftag ähnlich viel kosten, würde ich Einsteigern wegen des besser vorhersehbaren Ökosystems, der Dokumentation und der großen Zahl vorhandener Anleitungen eher den Raspberry Pi empfehlen.

Dazu passen beispielsweise ein passiver Aluminiumkühler/Gehäuse und ein USB-C-Netzteil 5 V / 3 A. Die 1,5-GB-Variante existiert und wäre vom Arbeitsspeicher her für einen typischen AdGuard-Betrieb grundsätzlich ausreichend. Aktuell gibt es aber bekannte Probleme rund um genau diese RAM-Konfiguration in Bootloadern/Systemen. Deshalb würde ich sie Einsteigern nicht als erste Wahl empfehlen.

Und was ist mit Preisen?

In der alten Fassung dieser Anleitung gab es eine Tabelle mit konkreten Preisen. Diesmal verzichte ich bewusst darauf. Elektronikpreise und Marketplace-Angebote ändern sich zu schnell, und bei Amazon-Partnerlinks möchte ich keine Beträge manuell in den Artikel schreiben, die wenige Wochen später bereits veraltet sein können. Den aktuellen Preis siehst du am zuverlässigsten direkt beim jeweiligen Produkt.

Dasselbe gilt für die Stromkosten. Statt einen festen Betrag für alle zu nennen, ist es ehrlicher, den eigenen Aufbau mit einem Energiekostenmessgerät zu messen und selbst zu rechnen: (W / 1000) × 24 × 365 × Preis pro kWh. Bei einem 24/7-Server ist dieser reale Messwert sinnvoller als die Nennleistung des Netzteils.

Raspberry Pi ohne Monitor vorbereiten

Für einen DNS-Server brauche ich weder Desktop noch Monitor oder Tastatur. Ich richte das System headless ein. Raspberry Pi empfiehlt dafür offiziell den Raspberry Pi Imager, weil man dort bereits vor dem ersten Start Hostname, Benutzerkonto, Netzwerk und SSH festlegen kann.

Im Raspberry Pi Imager wähle ich Raspberry Pi OS Lite (64-bit). Im August 2026 basiert Raspberry Pi OS 64-bit auf Debian 13 (Trixie), und Raspberry Pi 4 wird unterstützt. In den Image-Einstellungen vergebe ich einen Hostnamen, lege einen Benutzer mit Passwort an und aktiviere SSH. Wenn das Gerät per Ethernet angeschlossen wird – was ich für einen DNS-Server im Heimnetz bevorzuge – ist eine WLAN-Konfiguration nicht nötig.

Nach dem Schreiben der Karte kommt sie in den Raspberry Pi. Danach verbinde ich Ethernet und Strom. Nach dem ersten Start melde ich mich per SSH an, entweder über den im Imager vergebenen Hostnamen oder über die IP-Adresse aus dem Router:

ssh USER@HOSTNAME.local

Zuerst aktualisiere ich das System:

sudo apt update
sudo apt full-upgrade -y
sudo reboot

Nach dem Neustart melde ich mich erneut per SSH an.

Docker Engine und Compose

Ich verwende hier nicht mehr den alten Ansatz „Skript aus dem Internet laden und direkt in die Shell pipen“. Docker stellt für Debian ein offizielles APT-Repository bereit, und das ist auch für 64-bit Raspberry Pi OS auf Debian-Basis ein transparenterer Weg.

sudo apt update
sudo apt install -y ca-certificates curl

sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/debian/gpg \
  -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc

sudo tee /etc/apt/sources.list.d/docker.sources >/dev/null <<EOF
Types: deb
URIs: https://download.docker.com/linux/debian
Suites: $(. /etc/os-release && echo "$VERSION_CODENAME")
Components: stable
Architectures: $(dpkg --print-architecture)
Signed-By: /etc/apt/keyrings/docker.asc
EOF

sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io \
  docker-buildx-plugin docker-compose-plugin

Danach prüfe ich Docker und Compose:

sudo docker run --rm hello-world
sudo docker compose version

Man kann Docker später ohne sudo nutzbar machen. Für AdGuard Home ist das aber nicht erforderlich. In dieser Anleitung verwende ich die Befehle bewusst weiterhin mit sudo.

AdGuard Home mit Docker Compose installieren

Zuerst lege ich ein Arbeitsverzeichnis an:

mkdir -p ~/docker/adguard
cd ~/docker/adguard
mkdir -p adguard/conf adguard/work

Danach erstelle ich compose.yml:

services:
  adguard:
    image: adguard/adguardhome:latest
    container_name: adguard
    restart: unless-stopped

    ports:
      - "53:53/tcp"
      - "53:53/udp"

      # Web-Interface nach der Ersteinrichtung
      - "12280:80/tcp"

      # Nur für den Assistenten beim ersten Start
      - "3000:3000/tcp"

    volumes:
      - ./adguard/conf:/opt/adguardhome/conf
      - ./adguard/work:/opt/adguardhome/work

Start:

sudo docker compose up -d

Hinweis zu den Ports: Der Abschnitt ports: veröffentlicht die Ports auf den Interfaces des Hosts. In einem typischen Heimnetz hinter NAT ist das nicht dasselbe wie eine Portweiterleitung aus dem Internet. Trotzdem ist Docker allein keine Firewall. Wenn der Host mehrere Interfaces, eine öffentlich erreichbare IPv6-Adresse oder eine komplexere Segmentierung hat, sollte der Zugriff auf das Admin-Interface auf vertrauenswürdige Netze begrenzt und die Firewall beziehungsweise die Docker-DOCKER-USER-Regeln geprüft werden.

Die offizielle AdGuard-Home-Dokumentation verwendet 3000/TCP für die Ersteinrichtung, 80/TCP für die Weboberfläche sowie 53/TCP und 53/UDP für normales DNS. In meinem Beispiel veröffentliche ich bewusst weder DHCP noch DoT, DoQ, DNSCrypt oder einen eigenen DoH-Server, weil ich sie hier nicht brauche.

Wichtig: Port 3000 gehört nicht per Portweiterleitung vom Internet zum Raspberry Pi. Der Assistent und später auch die Administration sollen aus dem lokalen Netz erreichbar sein. Wenn du irgendwann von unterwegs administrieren musst, ist ein VPN oder ein korrekt abgesicherter Reverse Proxy die deutlich bessere Lösung.

Erster Start

Nach dem Start des Containers öffne ich im Browser:

http://SERVER-IP:3000

Im Assistenten setze ich das Webinterface auf Port 80 und DNS auf Port 53. Außerdem lege ich ein separates Administratorkonto an. Nach Abschluss des Assistenten ist die Oberfläche über den in Compose definierten Host-Port erreichbar, in diesem Beispiel also:

http://SERVER-IP:12280

Wenn alles funktioniert, entferne ich aus compose.yml die temporäre Zeile:

- "3000:3000/tcp"

und lasse den Container neu erstellen:

sudo docker compose up -d

Das wirkt nebensächlich, ist aber später hilfreich: In der Compose-Datei bleiben nur die Ports stehen, die tatsächlich gebraucht werden. Monate später muss ich dann nicht mehr rätseln, warum irgendwann 853, 784 oder 3000 veröffentlicht wurden.

AdGuard zuerst eine feste Adresse im LAN geben

Ein DNS-Server sollte nach einem Router-Neustart nicht plötzlich eine andere Adresse bekommen. Am einfachsten ist eine DHCP-Reservierung im Router für die Ethernet-Schnittstelle des Raspberry Pi, zum Beispiel 192.168.1.10. Ich bevorzuge eine Reservierung im DHCP-Server gegenüber einer statischen Netzwerkkonfiguration direkt auf dem Host, weil die Adressverwaltung so an einer Stelle bleibt.

Nach dem Speichern prüfst du im Router oder mit ip addr, ob das Gerät wirklich die erwartete Adresse erhalten hat. Erst diese Adresse sollte später als DNS an die Clients verteilt werden.

AdGuard Home als DNS im Heimnetz verteilen

Am bequemsten ist es, die Adresse des AdGuard-Hosts über Router oder DHCP als DNS an die Clients zu verteilen. Dann nutzen Smartphones, Laptops, Fernseher und die meisten anderen Geräte automatisch diesen Resolver.

Trage neben AdGuard nicht noch einen öffentlichen Resolver wie 1.1.1.1 oder 8.8.8.8 als „Backup-DNS“ ein, wenn du konsequente Filterung möchtest. Ein Client muss den zweiten Eintrag nicht ausschließlich als Notfall-Resolver behandeln und kann einen Teil seiner Anfragen an AdGuard vorbei schicken. Wenn du echte Redundanz brauchst, ist ein zweiter lokaler Resolver die sauberere Lösung.

Wenn im LAN IPv6 aktiv ist, prüfe zusätzlich, welchen DNS-Server der Router über IPv6 verteilt. Eine saubere IPv4-Konfiguration hilft wenig, wenn Geräte parallel einen externen IPv6-Resolver vom Router oder Provider erhalten und diesen bevorzugen.

Port 53 leite ich nicht vom WAN ins LAN weiter. Dieser DNS-Server ist für mein lokales Netz gedacht, nicht als öffentlicher Resolver im Internet.

Nach der Änderung mache ich einen einfachen Test von einem beliebigen Client, damit ich nicht raten muss, ob die DNS-Anfragen wirklich bei AdGuard Home ankommen:

dig @ADGUARD-IP example.com +stats

Wenn die Anfrage im Query Log auftaucht, funktioniert der Pfad Client → AdGuard Home.

Upstream DNS: zwei verschlüsselte Resolver statt einer langen Liste

Eine Zeit lang hatte ich mehrere unterschiedliche Upstreams konfiguriert. Auf dem Papier sah das gut aus, aber im Modus Load-balancing fielen mir gelegentlich deutlich längere Antworten auf. Deshalb habe ich die Konfiguration schließlich auf zwei DoH-Resolver reduziert und Parallel requests aktiviert.

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

Bei Parallel requests sendet AdGuard eine Anfrage, sofern sie nicht bereits im lokalen Cache liegt, an beide konfigurierten Upstreams und verwendet die erste Antwort. Das kann die Latenz verbessern, hat aber einen klaren Datenschutzpreis: Beide Resolver sehen diese Anfrage. Mit acht Upstreams wäre dieser Kompromiss für mich nicht mehr sinnvoll; mit zwei ist er bewusst und leicht nachvollziehbar.

Ich verwende hier Quad9 dns10, also die Variante ohne zusätzliches Threat Filtering durch Quad9. Seit Juni 2026 validiert Quad9 auch auf diesen Endpoints DNSSEC. „Ohne Threat Blocking“ bedeutet daher heute nicht mehr „ohne DNSSEC“. Das eigentliche Blockieren möchte ich an einer Stelle halten – lokal in AdGuard Home – statt später herausfinden zu müssen, ob eine Domain durch meine Filter, Quad9 oder eine weitere Ebene blockiert wurde.

Bootstrap DNS kann einfach bleiben, zum Beispiel:

9.9.9.10
1.1.1.1

Blocklisten: breit aufgestellt, aber mit Plan

Bei Blocklisten ist Übertreibung besonders einfach. Mein Netz besteht nicht nur aus ein paar Browsern. Es gibt Apple-Geräte, Smart-TVs, internationale Dienste und Apps, die teilweise sehr gesprächig sind. Deshalb bevorzuge ich ein etwas breiteres Profil als das absolute Minimum.

Gleichzeitig habe ich gemerkt, wie schnell mehrere Listen praktisch dasselbe tun. Ich habe Überschneidungen reduziert und nur Ebenen mit klarer Aufgabe behalten. Ein sinnvoller Ausgangspunkt sieht so aus:

• HaGeZi Pro++ als breite Hauptliste für Werbung, Tracker und Telemetrie;
• HaGeZi Threat Intelligence Feeds als separate Bedrohungsebene;
• Dandelion Sprout’s Anti-Malware List als zusätzliche Sicherheitsliste;
• Smart-TV Blocklist, wenn Fernseher im Netz sind und du einen Teil ihrer Werbe- und Telemetrieziele einschränken möchtest;
• optionale Hersteller- oder regionale Listen nur dann, wenn du dafür einen konkreten Grund hast.

Ich würde meine komplette Liste nicht blind kopieren. Aggressive Filter, ganze verdächtige TLDs oder das Blockieren von VPN-/Proxy-Infrastruktur können in einem Netz sinnvoll und in einem anderen extrem störend sein. Entscheidend ist, dass du weißt, warum eine bestimmte Liste aktiviert ist.

Safe Search und weitere Einstellungen, die für mich sinnvoll sind

Safe Search ist bei mir global für die verfügbaren Suchmaschinen und YouTube aktiviert. Ich sehe das nicht als „Kinderschutz mit einem Haken erledigt“, aber als zusätzliche sinnvolle Ebene in einem Familiennetz.

AdGuard Browsing Security bleibt ebenfalls aktiv. Die globale Parental-Control-Funktion nutze ich dagegen nicht. Wenn ich irgendwann strengere Regeln für ein bestimmtes Gerät brauche, würde ich diese lieber pro Client setzen, statt das Verhalten des gesamten Netzes zu verändern.

Nach meinem Audit habe ich außerdem eingestellt:

• Filter-Updates einmal täglich;
• Query Log für 7 Tage statt 90;
• Statistiken für 30 Tage statt nur 24 Stunden;
• DNS-Cache mit 16 MiB;
• Optimistic caching aktiviert;
• DNSSEC aktiviert;
• EDNS Client Subnet deaktiviert.

Im Query Log anonymisiere ich die Client-Adressen nicht, weil ich bei Problemen und Regeln pro Client sehen möchte, welches Gerät eine Anfrage gestellt hat. Für veröffentlichte Screenshots gilt natürlich etwas anderes – dort müssen private Adressen anonymisiert werden.

Wenn du lesbarere Logs oder andere Regeln für einzelne Geräte möchtest, sind Persistent clients nützlich. Du kannst einem Gerät einen Namen geben und später zum Beispiel Safe Search, Logging oder andere Regeln separat steuern. Für normales DNS-Blocking ist das nicht erforderlich, deshalb würde ich eine erste Installation damit nicht unnötig komplizieren.

Blocked Services: vollständige Liste der verfügbaren Dienste

AdGuard Home kann komplette Dienste global oder nur für einen bestimmten Client sperren. In diesem Setup lasse ich globales Blocked Services ausgeschaltet — ich möchte keine Dienste nur deshalb sperren, weil es dafür einen Schalter gibt. Wenn ich eine solche Regel wirklich für ein bestimmtes Gerät brauche, beginne ich mit einem einzelnen persistent client statt mit einer Richtlinie für das gesamte Netz.

Vollständige Liste anzeigen: 139 Dienste in 12 Kategorien

Dies ist ein Snapshot des aktuellen AdGuard-Home-Interfaces vom 25.08.2026. Die Liste kann sich mit späteren AdGuard-Home-Versionen ändern. Die Namen der einzelnen Dienste bleiben unverändert, damit sie dem Interface entsprechen.

• Künstliche Intelligenz: ChatGPT, Claude, Copilot, DeepSeek, Google Gemini, Grok, Manus, Meta AI, Perplexity
• Content Delivery Networks (CDN): Cloudflare
• Dating-Dienste: Grindr, Plenty of Fish, Tinder, Wizz
• Glücksspiel und Wetten: Betano, Betfair, Betway, Blaze, FDJ United
• Gaming: Activision Blizzard, Battle.net, Blizzard Entertainment, Electronic Arts, Epic Games, GOG, IO Interactive, League of Legends, Minecraft, Nintendo, Origin, PlayStation, Riot Games, Roblox, Rockstar Games, Shell Shockers, Steam, Ubisoft, Valorant, Wargaming, Warner Bros. Games, Xbox Live
• Webhosting / Datei-Dienste: Box, Dropbox, Flickr, Imgur
• Messaging-Dienste: KakaoTalk, Kik, MAX, Microsoft Teams, Olvid, Signal, Skype, Slack, Telegram (Web), Viber, WeChat, WhatsApp
• Datenschutz-Tools: iCloud Private Relay, Privacy, Proton
• Shopping: AliExpress, Amazon, CoolApk, eBay, Lazada, Mercado Libre, Shein, Shopee, Temu, Xiaohongshu
• Soziale Netzwerke: 4chan, 500px, 9GAG, Amino, Bluesky, Clubhouse, Discord, Douban, Facebook, Instagram, KOOK, LINE, LinkedIn, Mail.ru, Mastodon, Odysee, OK.ru, OnlyFans, Pinterest, Reddit, Snapchat, TikTok, Tumblr, X (formerly Twitter), VK.com, Zhihu
• Softwareentwicklung: Nvidia, Google Play Store
• Streaming-Dienste: Amazon Streaming, Apple Streaming, Bigo Live, Bilibili, Canais Globo, Claro, Crunchyroll, Dailymotion, Deezer, DirecTV Go, Discovery+, Disney+, ESPN, FIFA, Globoplay, HBO Max, Hulu, iHeartRadio, iQIYI, Lionsgate+, Looke, Nebula, Netflix, Paramount Plus, Peacock TV, Plex, Pluto TV, QQ, Rakuten Viki, Samsung TV Plus, SoundCloud, Spotify, Spotify Video, Tidal, Twitch, Vimeo, Vivo Play, Voot, Weibo, YouTube, YY

Custom filtering rules: hier kann eine Ausnahme schnell zu breit werden

Das war eine der praktischsten Lektionen beim Aufräumen meiner Konfiguration.

Ich wollte prüfen, ob googleads.g.doubleclick.net blockiert wird. Die Anfrage ging normal durch, obwohl sie mit meinen aktiven Listen eigentlich hätte geblockt werden sollen. Der Grund lag weder an HaGeZi noch an den Upstreams. Einige Monate zuvor hatte ich selbst Ausnahmen eingetragen:

@@||googleads.g.doubleclick.net^
@@||doubleclick.net^

Besonders die zweite Regel war sehr breit, weil die Ausnahme für doubleclick.net auch dessen Subdomains umfasst. Ich habe beide Zeilen auskommentiert, statt sie zu löschen, damit ich bei Problemen einen einfachen Rollback habe. Danach lieferte derselbe Test:

googleads.g.doubleclick.net.  10  IN  A  0.0.0.0

Die Filter hatten also die ganze Zeit funktioniert. Meine eigene Allowlist hatte sie umgangen.

Seitdem beginne ich bei Filterproblemen mit dem Query Log und meinen eigenen Ausnahmen. Eine Blockliste kann perfekt sein, aber eine alte @@-Regel kann das Ergebnis für einen ganzen Domain-Baum verändern.

Umgekehrt lösche ich nicht automatisch jede Ausnahme. Einige sind aus konkreten Gründen entstanden – zum Beispiel wegen Problemen mit Apple-Diensten oder VPNs. Wenn ein Dienst dank einer bewusst gesetzten Ausnahme zuverlässig funktioniert, ist mir ein dokumentierter Kompromiss lieber als eine „perfekt saubere“ Konfiguration, die wichtige Anwendungen kaputtmacht.

So teste ich, ob das Blocking wirklich funktioniert

Für einen Test verwende ich nicht irgendeine echte Werbedomain. Sie könnte gerade nicht auf der aktiven Liste stehen oder eine eigene Ausnahme haben. Zuverlässiger ist es, vorübergehend eine neutrale Regel einzutragen:

||ads.example.com^

und den eigenen AdGuard-Server direkt abzufragen:

dig @ADGUARD-IP ads.example.com +stats

Beim Standard-Blocking für einen A-Record solltest du 0.0.0.0 sehen. Danach kann die Testregel wieder entfernt werden.

Zusätzlich teste ich eine normale Domain:

dig @ADGUARD-IP example.com +stats

In meinem Test funktionierten normale DNS-Anfragen und das Blocking nach der Umstellung der Upstreams korrekt. Einige lokale Antworten wurden von dig mit 0 ms gemeldet. Das passt zu einer sehr schnellen lokalen oder gecachten Antwort, beweist allein aber noch nicht, woher die Antwort genau kam.

Wenn im Query Log alle Geräte wie ein einziger Client aussehen

Docker kann die ursprüngliche Client-IP hinter der Adresse der Bridge verstecken. Wenn im Query Log statt Laptop, Smartphone und Fernseher ständig zum Beispiel die Adresse des Docker-Gateways erscheint, ist das kein Blocking-Problem, sondern ein Problem der Sichtbarkeit der Quell-IP.

Die offizielle AdGuard-Home-Dokumentation empfiehlt unter Linux Host Networking, wenn die ursprünglichen Client-Adressen erhalten bleiben sollen. Ich würde den Netzwerkmodus einer funktionierenden Installation aber nicht nur deshalb ändern, weil es in der Dokumentation steht. Bei host networking nutzt der Container das Hostnetz direkt, deshalb sind die ports:-Mappings nicht nötig, und ein bereits von einem anderen Dienst belegter Port 53 wird sofort zum klaren Konflikt.

Wenn deine bestehende Konfiguration die Clients korrekt zeigt, lass sie so.

Was tun, wenn Port 53 bereits belegt ist?

Das ist unter Linux ein häufiger Fall. Bevor du wahllos Dienste abschaltest, prüfe, welcher Prozess tatsächlich lauscht:

sudo ss -lntup | grep ':53'

Auf manchen Distributionen kann systemd-resolved den Port belegen. AdGuard dokumentiert dafür ein eigenes Vorgehen. Solche Änderungen sollte man bewusst durchführen, weil ein Eingriff in den lokalen Resolver den DNS-Betrieb des gesamten Hosts beeinflusst.

Updates: Warum ich im Beispiel latest verwende

In meiner Compose-Datei steht:

image: adguard/adguardhome:latest

Der Grund ist einfach: Dieser Artikel wird nicht bei jedem AdGuard-Home-Release angepasst. Die offizielle Docker-Dokumentation beschreibt das Standard-Image als aktuelle stabile Version. So startet jemand, der diese Anleitung in einem halben Jahr liest, nicht automatisch mit einer Versionsnummer, die nur am Veröffentlichungstag aktuell war.

Wenn du Updates vollständig kontrollieren möchtest, pinne einen konkreten Tag statt latest. Aktuelle stabile Releases findest du auf der offiziellen AdGuard-Home-Releases-Seite. Achte darauf, ein stabiles Release und nicht eine als Pre-Release markierte Beta-Version zu wählen.

Dass ein neues Image verfügbar ist, aktualisiert einen laufenden Container nicht automatisch. Ich führe Updates bewusst aus:

sudo docker compose pull
sudo docker compose up -d

Vor größeren Änderungen sichere ich die Verzeichnisse conf und work und behalte die vorherige compose.yml. Das reicht für einen schnellen Rollback vieler Konfigurationsänderungen. Bei Image-Updates notiere ich mir zusätzlich die vorher verwendete Version beziehungsweise den Tag, wenn mir ein einfacher Rückweg wichtig ist.

Installation ohne Docker

Docker ist der Hauptweg in dieser Anleitung, aber nicht zwingend. AdGuard Home stellt fertige Archive für unterstützte Systeme bereit. Bei einer nativen Installation lädst du das passende Paket für deine Architektur von der offiziellen Releases-Seite herunter, entpackst es und registrierst das Programm als Dienst.

Nach dem Wechsel in das entpackte Verzeichnis AdGuardHome lautet der offizielle Installationsbefehl:

sudo ./AdGuardHome -s install

Den Dienststatus kannst du später prüfen mit:

sudo ./AdGuardHome -s status

Beim ersten Start lauscht AdGuard Home auf Port 3000 und führt durch denselben Einrichtungsassistenten. Aktuelle stabile Archive findest du auf der offiziellen Releases-Seite, die vollständige Installation beschreibt die Getting-started-Dokumentation.

Ich verwende in dieser Anleitung keinen Befehl nach dem Muster curl ... | sh als Standardweg. Ein konkretes Release herunterzuladen und eine klar sichtbare Binärdatei auszuführen ist leichter zu prüfen und später reproduzierbarer.

Grenzen, die man vorher kennen sollte

Erstens ersetzt DNS-Level-Blocking keinen Adblocker im Browser. Es ist besonders praktisch für Geräte, auf denen man keine Erweiterung installieren kann – etwa Fernseher, bestimmte mobile Apps oder IoT-Geräte – löst aber nicht jede Art von Werbung.

Zweitens müssen nicht alle Geräte den vom Router verteilten DNS verwenden. Eine App kann eigenes DoH nutzen, ein Gerät kann über ein VPN arbeiten, und Apple Private Relay verändert ebenfalls den normalen DNS-Pfad. Wenn du die Nutzung eines lokalen Resolvers wirklich erzwingen möchtest, reicht AdGuard allein nicht. Dafür brauchst du zusätzlich passende Firewall-Regeln. Ich mache das in dieser Anleitung bewusst nicht, weil ich ein funktionierendes Netz nicht nur für ein „perfekt dichtes“ Diagramm unnötig komplizieren möchte.

Drittens können aggressive Listen Dienste kaputtmachen. Genau dann ist für mich nicht die nächste Million Regeln die größte Stärke von AdGuard Home, sondern das Query Log. Dort sehe ich Domain, Client und Blockierungsgrund und kann das konkrete Problem beheben, statt pauschal einen großen Teil der Filterung abzuschalten.

Wie sich dieser Aufbau im Alltag bewährt hat

Die Installation von AdGuard Home ist einfach. Mehr Zeit hat es gekostet, eine Konfiguration zu finden, die nicht ständig nachjustiert werden muss: Upstreams auf zwei reduzieren, auf DoH umstellen, Blocklisten aufräumen, die Query-Log-Aufbewahrung verkürzen und alte Ausnahmen kontrollieren.

Das beste Beispiel ist DoubleClick. Zunächst sah es so aus, als würden meine Filter nicht funktionieren. Erst die Kontrolle der eigenen Regeln zeigte, dass ich mir das Problem früher selbst mit der breiten Ausnahme @@||doubleclick.net^ eingebaut hatte. Nach dem Deaktivieren kam dieselbe Domain als 0.0.0.0 zurück. Solche Fälle sind für mich wertvoller als die nächste Liste mit „10 besten Filtern“, weil sie genau zeigen, wo man suchen sollte, wenn sich etwas anders verhält als erwartet.

Wenn ich AdGuard Home heute neu aufsetzen würde, wäre die Reihenfolge genau diese: kleiner Rechner mit Ethernet, Raspberry Pi OS Lite, Docker, minimale Portfreigaben, ein oder zwei verschlüsselte Upstreams, ein sinnvoller Satz Filterlisten und erst danach zusätzliche Ausnahmen. Ich würde nicht mit mehreren Millionen Regeln anfangen. Zuerst muss DNS stabil funktionieren; danach kann man die Filterung passend zum eigenen Netz verschärfen.

Dokumentation

• AdGuard Home – Docker
• AdGuard Home – Getting started
• AdGuard Home – Clients
• AdGuard Home – Releases
• Raspberry Pi – Getting started / Raspberry Pi Imager
• Docker Engine – Installation auf Debian
• Quad9 – verfügbare Resolver und DoH-Adressen
• Cloudflare 1.1.1.1 – DNS over HTTPS
• HaGeZi DNS Blocklists