Pi-hole o AdGuard Home con Docker: bloccare pubblicità e tracker su tutta la rete

Un blocco della pubblicità che funziona su smart TV, console, smartphone e su ogni browser di casa, senza installare nulla sui dispositivi: è quello che fanno Pi-hole e AdGuard Home. Entrambi si mettono al posto del DNS del router e rispondono “non esiste” quando un dispositivo chiede l’indirizzo di un dominio pubblicitario o di tracciamento. In questa guida li installiamo con Docker Compose, spieghiamo come farli usare a tutta la rete anche con i router degli operatori italiani e come verificare che funzionino davvero, compresi i loro limiti.

Versioni di riferimento: procedura verificata sulla documentazione ufficiale al 4 novembre 2026, con Pi-hole v6 (immagine pihole/pihole, tag 2026.10.1) e AdGuard Home 0.107.80 (immagine adguard/adguardhome; la 1.0 è in beta).

Pi-hole o AdGuard Home: le differenze che contano

In sintesi: AdGuard Home è più completo “di serie”, soprattutto per il DNS cifrato; Pi-hole ha una comunità enorme e una documentazione molto concreta sui router. Per bloccare la pubblicità si equivalgono, perché la qualità dipende soprattutto dalle liste.

Prima di iniziare: liberare la porta 53 su Ubuntu

Ubuntu (dalla 17.10) e Fedora (dalla 33) usano systemd-resolved, che occupa la porta 53 con un resolver locale e impedisce a Pi-hole o AdGuard Home di avviarsi. Controllate:

sudo ss -tulpn | grep ':53 '

Se compare systemd-resolve, disattivate il resolver locale con la procedura della documentazione Pi-hole (serve sudo):

sudo sh -c 'mkdir -p /etc/systemd/resolved.conf.d && printf "[Resolve]nDNSStubListener=non" | tee /etc/systemd/resolved.conf.d/no-stub.conf'
sudo sh -c 'rm -f /etc/resolv.conf && ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf'
sudo systemctl restart systemd-resolved

Il secondo comando fa puntare /etc/resolv.conf al file aggiornato automaticamente da systemd, altrimenti il server stesso resterebbe senza risoluzione dei nomi. La documentazione di AdGuard Home propone una variante equivalente che aggiunge anche DNS=127.0.0.1, così l’host usa il filtro per sé.

Opzione A: Pi-hole v6 con Docker Compose

Create una cartella (ad esempio /opt/pihole) e il file compose.yaml, ricavato dall’esempio ufficiale:

services:
  pihole:
    container_name: pihole
    image: pihole/pihole:latest
    ports:
      - "53:53/tcp"
      - "53:53/udp"
      - "8080:80/tcp"
      - "8443:443/tcp"
    environment:
      TZ: 'Europe/Rome'
      FTLCONF_webserver_api_password: 'PASSWORD_LUNGA'
      FTLCONF_dns_listeningMode: 'ALL'
    volumes:
      - './etc-pihole:/etc/pihole'
    restart: unless-stopped

Rispetto all’esempio ufficiale abbiamo spostato l’interfaccia web sulle porte 8080 e 8443 dell’host, per non scontrarci con un eventuale reverse proxy (è la soluzione indicata dalla documentazione in caso di conflitto). FTLCONF_dns_listeningMode: 'ALL' è necessario con la rete bridge predefinita di Docker. Non abbiamo aggiunto cap_add: NET_ADMIN, che serve solo se Pi-hole fa anche da server DHCP.

cd /opt/pihole
sudo docker compose up -d

Se omettete la password, Pi-hole ne assegna una casuale, che di norma compare nel log del primo avvio (sudo docker logs pihole). Per cambiarla in seguito: sudo docker exec -it pihole pihole setpassword.

Per aggiornare le liste a mano: sudo docker exec pihole pihole -g. Per aggiornare Pi-hole non si usa pihole -up dentro il container ma si scarica la nuova immagine: sudo docker compose pull e poi sudo docker compose up -d.

Opzione B: AdGuard Home con Docker Compose

La documentazione di AdGuard fornisce un comando docker run; questo è l’equivalente in Compose con le sole porte che servono in casa (DNS, interfaccia e procedura iniziale):

services:
  adguardhome:
    container_name: adguardhome
    image: adguard/adguardhome
    restart: unless-stopped
    ports:
      - "53:53/tcp"
      - "53:53/udp"
      - "3000:3000/tcp"
      - "8081:80/tcp"
    volumes:
      - ./work:/opt/adguardhome/work
      - ./conf:/opt/adguardhome/conf

Le altre porte dell’esempio ufficiale servono solo per funzioni specifiche: 67 e 68 per il DHCP, 443 e 853 per offrire DoH, DoT e DNS-over-QUIC ai dispositivi, 5443 per DNSCrypt, 6060 per il debug.

cd /opt/adguardhome
sudo docker compose up -d

Aprite http://IP_SERVER:3000/ per la procedura guidata: create l’utente amministratore e scegliete la porta dell’interfaccia: se indicate la 80 del container, la troverete sulla 8081 dell’host come previsto dal compose; se ne scegliete un’altra, aggiornate la mappatura delle porte e riavviate. Poi nelle impostazioni DNS (Settings > DNS settings) indicate gli upstream cifrati, ad esempio https://dns.quad9.net/dns-query o tls://dns.quad9.net: la sintassi con prefisso https://, tls:// o quic:// è quella documentata.

Le liste: poche e buone

Più liste non significa più protezione, ma più siti rotti. Il registro ufficiale di AdGuard propone 66 liste, comprese AdGuard DNS filter, OISD e le HaGeZi in varie intensità; contiene liste regionali per diversi paesi, ma nessuna dedicata all’Italia. Nella pratica le grandi liste internazionali coprono già i circuiti pubblicitari usati dai siti italiani. Il nostro consiglio è partire con una lista generalista (AdGuard DNS filter o HaGeZi Normal) e aggiungerne una sola più aggressiva se serve, controllando per una settimana il registro dei blocchi. Le stesse URL si possono usare in Pi-hole, nella sezione delle liste.

Far usare il filtro a tutta la rete

Il metodo corretto è far distribuire dal DHCP del router l’IP del vostro server come DNS. Con il Fritz!Box la documentazione Pi-hole indica, in modalità avanzata, il campo “Local DNS server” in Home Network / Network / Network Settings / IP Addresses / IPv4 Configuration (nell’interfaccia italiana: Rete domestica, Rete, Impostazioni di rete). In alternativa si può impostare il filtro come DNS del Fritz!Box stesso, in Internet / Account Information / DNS server: in quel caso non impostate il Fritz!Box come upstream del filtro, o creerete un ciclo infinito. I dispositivi vedono la modifica solo al rinnovo del lease DHCP: il modo più rapido è scollegarli e ricollegarli alla rete.

Il problema italiano è che diversi router forniti dagli operatori non permettono di cambiare il DNS distribuito via DHCP. Le soluzioni, dalla più pulita alla più laboriosa:

1. Usare il DHCP di Pi-hole o AdGuard Home e disattivare quello del router: richiede NET_ADMIN e, per AdGuard Home, la rete host. Prima di spegnere il DHCP del router, assicuratevi che il server abbia un IP statico configurato su se stesso.
2. Impostare il DNS a mano sui dispositivi principali (PC, smart TV, console): la nostra guida https://hardwarfare.it/guide/tutorial/cambiare-dns-pc-smartphone-router-cloudflare/ mostra dove farlo.
3. Mettere un vostro router dietro quello dell’operatore, se lo usate già per il Wi-Fi: vedi https://hardwarfare.it/guide/tutorial/accedere-router-configurare-wifi-tim-vodafone-fritzbox/.

Due dettagli che rovinano il risultato: un DNS IPv6 distribuito dal router, che i dispositivi possono usare scavalcando il filtro (la documentazione Pi-hole dedica una sezione al Fritz!Box con IPv6), e i browser con DNS-over-HTTPS attivo, che ignorano il DNS di rete. Nel secondo caso disattivate la funzione nelle impostazioni del browser o lasciatela puntare al vostro AdGuard Home.

Cosa non può bloccare

Il filtro DNS blocca per nome di dominio. Se la pubblicità arriva dallo stesso dominio dei contenuti, come accade con gli annunci dentro i video di YouTube o nelle app di molti social, bloccarla significherebbe bloccare anche il servizio. Lo stesso vale per i banner serviti direttamente dal sito che state visitando. Per questi casi resta necessario un blocco nel browser; il filtro di rete, però, protegge anche i dispositivi dove un’estensione non si può installare, come smart TV e console.

Se qualcosa va storto

• Il container non parte con un errore sull’indirizzo già in uso per la porta 53 (“address already in use”): systemd-resolved o un altro DNS è ancora attivo. Ripetete il controllo con ss.
• Il server stesso non risolve più i nomi: avete disattivato il resolver locale ma /etc/resolv.conf punta ancora a 127.0.0.53. Rifate il collegamento simbolico indicato sopra.
• Un sito o un’app smette di funzionare: cercate nel registro delle query il dominio bloccato in quel momento e aggiungetelo alla allowlist. Con Pi-hole potete anche interrogarlo da terminale: sudo docker exec pihole pihole -q NOME_DOMINIO mostra in quale lista compare.
• Le statistiche mostrano un solo client: è la rete bridge di Docker oppure il router che inoltra le richieste a nome di tutti. Con il Fritz!Box, la distribuzione via DHCP (e non come DNS del router) mostra i singoli dispositivi.
• Nessun blocco nonostante tutto: controllate da un dispositivo con nslookup doubleclick.net quale server DNS sta rispondendo. Se non è il vostro, la configurazione del router o del dispositivo non è stata applicata.

Come tornare indietro

Rimettete sul router i DNS annotati all’inizio (o riattivate il suo DHCP, se lo avevate spento), poi fermate il container con sudo docker compose down nella sua cartella. Per riattivare systemd-resolved su Ubuntu cancellate il file /etc/systemd/resolved.conf.d/no-stub.conf, ricreate il collegamento con sudo ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf e riavviate il servizio con sudo systemctl restart systemd-resolved.

La nostra lettura

Un filtro DNS di rete è uno degli interventi con il miglior rapporto tra fatica e risultato in una casa con molti dispositivi: mezz’ora di lavoro e la smart TV smette di parlare con decine di server di tracciamento. Scegliete AdGuard Home se volete il DNS cifrato senza componenti aggiuntivi, Pi-hole se vi serve una documentazione più ricca sui router; in entrambi i casi la parte delicata non è l’installazione, ma il router dell’operatore. E tenete a portata di mano i vecchi DNS: il giorno in cui il server si spegnerà, vi serviranno.

Articolo redatto con il supporto di strumenti di intelligenza artificiale e verificato dalla redazione. Come usiamo l'AI · Come lavoriamo