Home Infrastructure · Active

Raspberry Pi + AdGuard Home

A rebuildable guide for deploying network-wide DNS filtering and ad blocking with a Raspberry Pi 4B, Raspberry Pi OS Lite, AdGuard Home, fast upstream DNS, and practical allow/block rules for ChatGPT, Claude, Fandom, Google Home, Alexa, and Roku.

DNS rules View Markdown notes

Setup used

Hardware

Raspberry Pi 4B connected to the router. Ethernet is preferred to avoid dual-interface confusion.

Raspberry Pi OS Lite flashed with Raspberry Pi Imager, with SSH enabled during imaging.

Network

Netgear Nighthawk router with AdGuard Home running as the DNS filtering service and optional DHCP server.

Quick setup

Flash Raspberry Pi OS Lite using Raspberry Pi Imager.
Enable SSH and configure login credentials during imaging.
Boot the Pi and connect it by Ethernet.
Update Raspberry Pi OS.
Find the Pi IP address and reserve it outside the DHCP pool.
Install AdGuard Home and open the web UI.
Configure fast upstream DNS before moving DHCP.
Add stable blocklists first; add device-specific rules gradually.
Only move DHCP to AdGuard after confirming router = gateway and Pi = DNS.

Core commands

Update the Pi

sudo apt update
sudo apt upgrade -y
sudo reboot

Find the Pi IP address

hostname -I
ip route
ip addr

Install AdGuard Home

wget https://static.adtidy.org/adguardhome/release/AdGuardHome_linux_arm64.tar.gz
tar xvf AdGuardHome_linux_arm64.tar.gz
cd AdGuardHome
sudo ./AdGuardHome -s install

Check installed version

sudo /opt/AdGuardHome/AdGuardHome --version
sudo systemctl status AdGuardHome

DNS flow

Ideal client visibility

Client → AdGuard → Upstream DNS

AdGuard can show individual device traffic.

Common Nighthawk behavior

Client → Router → AdGuard

AdGuard may only show the router IP. Filtering can still work.

Fast upstream DNS

Use a small, known-good upstream set first. Add complexity only after DNS latency and client behavior look stable.

Balanced speed

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

Use Cloudflare and Google DoH as the baseline. Enable parallel requests if speed matters more than minimizing duplicate upstream queries.

Security leaning

https://dns.quad9.net/dns-query
https://dns11.quad9.net/dns-query

Use Quad9 when malware and phishing blocking matter more than raw resolver speed.

Bootstrap / fallback

1.1.1.1
1.0.0.1
8.8.8.8
8.8.4.4
9.9.9.9

DNS blocklists and local rules

Start with stable lists. Add device-specific tracker blocks only after the basic network is fast and reliable.

Starting blocklists

AdGuard DNS filter
OISD Big: https://big.oisd.nl

Optional after stable

HaGeZi Multi PRO:
https://cdn.jsdelivr.net/gh/hagezi/dns-blocklists@latest/adblock/pro.txt

HaGeZi TIF Mini:
https://cdn.jsdelivr.net/gh/hagezi/dns-blocklists@latest/adblock/tif.mini.txt

DNS blocking cannot remove every first-party or app-native ad. Use DNS blocking for network-wide tracker reduction, then pair it with a browser content blocker for cosmetic cleanup on ad-heavy sites.

Allow ChatGPT and Claude

Add these if ChatGPT, Codex, Claude, Claude Code, uploads, login, or streaming responses break.

ChatGPT / OpenAI

@@||chatgpt.com^
@@||openai.com^
@@||auth.openai.com^
@@||oaistatic.com^
@@||oaiusercontent.com^
@@||oaistatsig.com^
@@||openaimerge.com^
@@||workos.com^
@@||workoscdn.com^
@@||challenges.cloudflare.com^

Claude / Anthropic

@@||claude.ai^
@@||claude.com^
@@||anthropic.com^
@@||api.anthropic.com^
@@||platform.claude.com^
@@||statsig.anthropic.com^

Fandom, casting, Alexa, and Roku

Fandom helper rules

@@||wikia.nocookie.net^
||jwplayer.com^$domain=fandom.com
||doubleclick.net^
||googlesyndication.com^
||googleadservices.com^
||pubmatic.com^
||criteo.com^
||taboola.com^
||scorecardresearch.com^
||quantserve.com^

Do not block all of Fandom or Wikia. If pages render badly, allow static Wikia assets.

Casting fallback allowlist

@@||google.com^
@@||gstatic.com^
@@||googleapis.com^
@@||googlevideo.com^
@@||youtube.com^
@@||ytimg.com^
@@||clients3.google.com^
@@||connectivitycheck.gstatic.com^

If casting breaks, check same Wi-Fi/subnet and client isolation before assuming DNS is the only cause.

Smart-device tracker blocks to test carefully

||app-measurement.com^
||firebase-settings.crashlytics.com^
||firebaselogging-pa.googleapis.com^
||device-metrics-us.amazon.com^
||device-metrics-us-2.amazon.com^
||metrics.amazon.com^
||fls-na.amazon.com^
||data.amazon.com^
||logs.roku.com^
||scribe.logs.roku.com^
||ads.roku.com^
||p.ads.roku.com^

For Roku and Alexa, prefer client-specific test rules first so one device can be rolled back without disabling filtering across the network.

DHCP warning

Do not disable router DHCP until AdGuard has a static IP and AdGuard DHCP is configured. If router DHCP is disabled too early, devices may lose IP addresses and the AdGuard interface may become unreachable.

Reserve the Pi IP first.
Confirm AdGuard is reachable.
Configure AdGuard DHCP if needed.
Confirm gateway is router IP and DNS is Pi IP.
Only then disable router DHCP.

Troubleshooting

AdGuard only shows the router

Likely cause: router DNS proxying. Test by manually setting one client DNS server to the Pi IP.

Slow DNS / slow internet

Check average processing time in the AdGuard dashboard.
Use Cloudflare + Google DoH as a baseline.
Enable parallel requests only after confirming no DNS loop.
Disable newly added aggressive lists if latency starts immediately after adding them.
Check whether IPv6 DNS is bypassing AdGuard.

AdGuard UI will not load

sudo systemctl status AdGuardHome
sudo systemctl restart AdGuardHome
sudo journalctl -u AdGuardHome -f

Lessons learned

Use Ethernet if possible.
Reserve the Pi IP before changing DNS settings.
Router = gateway; Pi = DNS.
Test one device before changing the whole network.
Expect Netgear DNS proxy behavior.
Do not disable router DHCP until AdGuard DHCP is ready.
DNS filtering and client visibility are related but separate problems.
Allow only the smallest domain needed when fixing false positives.