AdGuard Home Raspberry Pi gives you network-wide ad blocking, encrypted DNS via DNS-over-HTTPS and DNS-over-TLS, and per-device parental controls running on a single Pi 4. Every device on your network benefits without installing browser extensions or apps on each one. AdGuard Home handles filtering at the DNS level, blocking domains before any content is fetched, and encrypts outgoing DNS queries so your ISP cannot log or redirect them. This guide covers installation with the correct arm64 binary, DoH and DoT upstream configuration, parental controls per device, SafeSearch enforcement, monitoring, and troubleshooting.
Last tested: Raspberry Pi OS Bookworm Lite 64-bit | May 3, 2026 | Raspberry Pi 4 Model B (2GB) | AdGuard Home 0.107.x | DoH upstream: Cloudflare 1.1.1.1
Key Takeaways
- Download the
arm64binary on Bookworm 64-bit, notarmv7. The armv7 build is 32-bit and does not use the Pi 4’s full instruction set. On Bookworm Lite 64-bit, the correct binary isAdGuardHome_linux_arm64.tar.gz. - DoH and DoT encrypt DNS queries between the Pi and the upstream resolver. They do not encrypt queries between your devices and the Pi. Those travel in plaintext on your LAN. This is acceptable for a home network but important to understand: encrypted DNS protects you from ISP surveillance and external interception, not from traffic analysis on your own network.
- Per-device parental controls require static IP assignments or MAC address bindings. If devices change IP frequently via DHCP, the rules follow the IP address rather than the device, and will apply to the wrong device after a lease renewal. Use DHCP reservations in your router or enable AdGuard Home’s built-in DHCP server.
AdGuard Home Raspberry Pi: How It Works
AdGuard Home acts as the DNS server for your entire network. Your router DHCP server advertises the Pi IP as the DNS resolver, so all devices send their DNS queries to AdGuard Home by default. AdGuard Home checks each query against its blocklists. If the domain matches, it returns a null response and the browser never fetches content from that domain. Allowed queries are forwarded to an upstream resolver using DoH or DoT, so the ISP sees encrypted HTTPS traffic rather than plaintext DNS requests.
Unlike Pi-hole with Unbound (which walks the DNS hierarchy from root servers), AdGuard Home forwards queries to a trusted upstream resolver over an encrypted connection. This is simpler to configure and still protects against ISP surveillance, but it means the upstream provider (Cloudflare, Quad9, NextDNS) does see your queries. For full recursive resolution with no upstream provider, see Unbound Raspberry Pi. For a direct comparison of the two approaches, see AdGuard Home vs Pi-hole on Raspberry Pi.
Installation
Flash Raspberry Pi OS Bookworm Lite 64-bit using Raspberry Pi Imager. After first boot:
sudo apt update && sudo apt full-upgrade -y
Set a static IP so the router always points DNS to the same address:
sudo nmcli connection modify "Wired connection 1" ipv4.method manual ipv4.addresses 192.168.1.53/24 ipv4.gateway 192.168.1.1 ipv4.dns 127.0.0.1
sudo nmcli connection up "Wired connection 1"
Download and install AdGuard Home. Use the arm64 binary on Bookworm 64-bit:
cd /opt
sudo wget https://github.com/AdguardTeam/AdGuardHome/releases/latest/download/AdGuardHome_linux_arm64.tar.gz
sudo tar -xvf AdGuardHome_linux_arm64.tar.gz
cd AdGuardHome
sudo ./AdGuardHome -s install
The -s install flag registers AdGuard Home as a systemd service that starts at boot. Navigate to http://<pi-ip>:3000 in a browser and the setup wizard loads.
Work through the wizard:
- Listening interface: select your wired interface (eth0)
- DNS port: 53 (default)
- Admin interface port: 3000 (change to 3001 or above if anything else uses 3000)
- Create an admin username and a strong password
Expected result: After completing the wizard, the AdGuard Home dashboard loads at http://<pi-ip>:3000. The Query Log tab shows DNS activity. If nothing appears, your devices are not yet using the Pi as their DNS server. Point your router DHCP server to the Pi static IP to push the new DNS setting to all devices.

Configuring DoH and DoT Upstream Servers
In the AdGuard Home dashboard, go to Settings > DNS Settings. Under Upstream DNS servers, replace the defaults with DoH or DoT addresses. AdGuard Home identifies the protocol by the URL prefix: https:// for DoH, tls:// for DoT, and plain IP for unencrypted DNS.
Reliable encrypted upstream options:
# Cloudflare DoH (recommended, fast, privacy policy available)
https://dns.cloudflare.com/dns-query
# Quad9 DoH (blocks malicious domains, privacy-focused)
https://dns.quad9.net/dns-query
# CleanBrowsing Family Filter DoT (blocks adult content at upstream level)
tls://family-filter-dns.cleanbrowsing.org
# NextDNS DoH (per-account filtering, requires free account)
https://dns.nextdns.io/your-nextdns-id
Enter one or more servers on separate lines. AdGuard Home queries all listed upstreams in parallel and uses the fastest response. Under Bootstrap DNS servers, enter 9.9.9.9. This plain DNS address is used only to resolve the DoH/DoT server hostnames themselves before encrypted DNS is established.
Save the settings, then test encrypted DNS is working:
# From the Pi, check which upstream is responding
dig @127.0.0.1 google.com
# From a browser on any network device
# Visit: https://1.1.1.1/help
# Look for: Using DNS over HTTPS (DoH): Yes
Expected result: The AdGuard Home dashboard under Settings > DNS Settings shows the upstream servers with green status indicators. The 1.1.1.1/help page confirms DoH is active when Cloudflare is the upstream.
Adding blocklists
Go to Filters > DNS blocklists > Add blocklist. Well-maintained lists:
- AdGuard DNS Filter: default, broad ad and tracker coverage
- EasyList: widely used ad blocking list
- Steven Black’s Hosts (Unified): ads, malware, fake news, and adult content
- OISD Big: comprehensive, low false positive rate
Do not stack 20 or more lists without testing. Overlapping lists slow query processing and increase false positives. Start with two or three and add more if gaps appear.
Parental Controls and Per-Device Rules
Adding clients
Go to Settings > Client Settings > Add client. Identify the device by MAC address (more reliable) or IP address. Name it clearly (for example, “Childs iPad” or “Living Room TV”). Each client can have its own blocklists, filtering level, and access schedule independent of every other device.
Parental controls per device
On each client’s settings page, enable parental controls to block adult content categories. Enable Safe Search enforcement to force Google, Bing, YouTube, and DuckDuckGo to return filtered results. Enable YouTube restricted mode specifically to hide adult-rated content on YouTube without blocking the domain entirely.
Apply additional blocklists only to specific clients. For example, add a social media blocklist to a child’s device without affecting other devices.
SafeSearch DNS rewrite
AdGuard Home’s built-in Safe Search feature (enabled per-client in the parental settings) automatically rewrites DNS for major search engines and YouTube to enforce their respective safe modes. Enabling it at the client level is simpler and more reliable than adding manual DNS rewrite rules, which can break with search engine infrastructure changes.
Scheduling access
Under a client’s settings, enable the schedule option to restrict internet access to specific hours. Example: block all DNS resolution for a specific device from 21:00 to 07:00. When a device’s schedule blocks it, AdGuard returns NXDOMAIN for all queries, preventing any domain from resolving. This works across all apps, not just browsers.
Monitoring and Maintenance
Query log
The Query Log tab shows every DNS request with timestamp, client, domain, response status (allowed, blocked, rewritten), and upstream used. Filter by client to see one device’s activity, or filter by status to see only blocked queries. Click any blocked domain to whitelist it immediately without leaving the log view.
Top blocked domains and clients
The Statistics tab shows which domains generate the most queries and which clients are most active. This is useful for identifying devices with excessive DNS activity (which may indicate malware or a misconfigured app) and for finding false positives that need whitelisting.
Updating blocklists and AdGuard Home
# Update blocklists manually (or enable auto-update per list in Filters settings)
# In the dashboard: Filters > DNS blocklists > Update now
# Update AdGuard Home binary
sudo /opt/AdGuardHome/AdGuardHome -s stop
cd /opt
sudo wget -q https://github.com/AdguardTeam/AdGuardHome/releases/latest/download/AdGuardHome_linux_arm64.tar.gz
sudo tar -xf AdGuardHome_linux_arm64.tar.gz --overwrite
sudo /opt/AdGuardHome/AdGuardHome -s start
Backing up configuration
AdGuard Home stores all configuration in /opt/AdGuardHome/AdGuardHome.yaml and filter lists in /opt/AdGuardHome/data/. Back up both:
sudo tar -czf ~/adguard-backup-$(date +%Y%m%d).tar.gz /opt/AdGuardHome/AdGuardHome.yaml /opt/AdGuardHome/data/
The configuration file contains admin credentials, client settings, blocklist URLs, and DNS upstream configuration. Restoring it to a fresh AdGuard Home install recovers all settings without manual reconfiguration.
Troubleshooting
DNS not resolving for network devices
# Test AdGuard Home is listening on port 53
sudo ss -tlnp | grep :53
# Test resolution directly from another device on the network
dig @192.168.1.53 google.com
# Check AdGuard Home service status
sudo systemctl status AdGuardHome
If dig from another device fails but dig @127.0.0.1 google.com on the Pi succeeds, the router is not distributing the Pi’s IP as the DNS server. Check the DHCP DNS setting on the router and confirm the Pi’s static IP matches what is configured there.
Upstream DoH/DoT failing
# Test upstream DoH from the Pi
curl -sI https://dns.cloudflare.com/dns-query
# Check AdGuard Home upstream status
# Dashboard: Settings > DNS Settings > Test upstreams (button at bottom)
AdGuard Home has a built-in “Test upstreams” button in DNS settings that checks each configured server and reports latency and reachability. If all upstreams fail, the bootstrap DNS setting may be wrong. Confirm the bootstrap address (9.9.9.9) is reachable with ping 9.9.9.9.
False positives blocking legitimate sites
# Find the blocked domain in the query log
# Dashboard: Query Log > filter by blocked status
# Whitelist a domain
# Click the domain in the Query Log > Unblock > Whitelist
# Or manually: Filters > Custom filtering rules > add:
@@||example.com^
The @@||domain.com^ syntax in custom filtering rules is an allowlist exception that overrides all blocklists. Use it for domains your blocklists incorrectly flag. The Query Log identifies which filter list matched the blocked domain, which helps diagnose whether one specific list is over-aggressive.
Mobile devices bypassing filters via cellular
DNS filtering only applies to devices using your home network. A phone on LTE uses the carrier’s DNS and bypasses AdGuard Home entirely. Mitigation options: install a VPN on the device that routes traffic through the home network, or use a device management profile (iOS) or Google Family Link (Android) to enforce restrictions at the device level alongside the network-level DNS filtering.
Port 53 conflict with systemd-resolved
# Check if systemd-resolved is using port 53
sudo ss -tlnp | grep :53
# If systemd-resolved is on port 53, disable its DNS stub listener
sudo sed -i 's/#DNSStubListener=yes/DNSStubListener=no/' /etc/systemd/resolved.conf
sudo systemctl restart systemd-resolved
FAQ
Does AdGuard Home replace a VPN?
No. AdGuard Home encrypts DNS queries but does not encrypt the rest of your traffic. A VPN encrypts all traffic between your device and the VPN endpoint. The two serve different purposes. You can combine them: route VPN client traffic through the home network so remote devices still use AdGuard Home for DNS filtering. See Tailscale Raspberry Pi for a straightforward setup that routes remote devices’ DNS through the home Pi.
Should I use DoH or DoT?
Both encrypt DNS queries. DoH runs on port 443 and blends with HTTPS traffic, making it harder for ISPs to block. DoT runs on port 853 and is easier to identify and block at the network level. For a home setup where ISP blocking is not a concern, either works well. DoH is more widely supported by upstream providers and is the safer default choice.
Can I run AdGuard Home alongside other services on the Pi?
Yes. AdGuard Home uses port 53 (DNS), port 3000 (web UI), and optionally port 853 (DoT server) and 443 (DoH server) if you configure it as a DoH/DoT server for clients. Other services on different ports do not conflict. A Pi 4 with 2GB RAM runs AdGuard Home and several other containers without measurable performance impact on DNS query latency.
How does this compare to Pi-hole?
Pi-hole is the older, more established tool with a larger community blocklist ecosystem. AdGuard Home is newer, includes built-in DoH/DoT support without additional software, and has per-device parental controls and scheduling built into the UI. Pi-hole requires Unbound or a separate DoH proxy to match AdGuard Home’s encryption features. For a new installation primarily focused on ad blocking and parental controls, AdGuard Home is simpler. For a setup requiring full recursive DNS without any upstream provider, Pi-hole with Unbound is the better choice. See AdGuard Home vs Pi-hole on Raspberry Pi for the full comparison.
Does DNS-level parental control block everything?
No. DNS filtering blocks domains before content is fetched, which stops most ad-supported and explicitly listed content. It does not inspect HTTPS traffic, cannot block content served from non-blocked domains (a social media post embedded on a news site, for example), and cannot prevent access on cellular networks. DNS filtering is one layer of a layered approach. Device-level controls (Screen Time on iOS, Digital Wellbeing on Android) complement it for mobile devices.
References
- https://github.com/AdguardTeam/AdGuardHome
- https://adguard-dns.io/kb/adguard-home/getting-started/
- https://adguard-dns.io/kb/adguard-home/faq/
- https://github.com/StevenBlack/hosts
About the Author
Chuck Wilson has been programming and building with computers since the Tandy 1000 era. His professional background includes CAD drafting, manufacturing line programming, and custom computer design. He runs PidiyLab in retirement, documenting Raspberry Pi and homelab projects that he actually deploys and maintains on real hardware. Every article on this site reflects hands-on testing on specific hardware and OS versions, not theoretical walkthroughs.
Last tested hardware: Raspberry Pi 4 Model B (2GB). Last tested OS: Raspberry Pi OS Bookworm Lite 64-bit. AdGuard Home 0.107.x, Cloudflare DoH upstream.

