VPNSmith
self-host-vpnHOWTO

Fughe DNS in WireGuard: rilevare, diagnosticare, eliminare (2026)

WireGuard non blocca le fughe DNS di default. Guida pratica: come avvengono le fughe, strumenti di rilevamento, soluzioni per Linux/Windows/macOS/iOS/Android 2026.

Di Eric Gerard · Fondateur · VPNSmith — Spécialiste self-host VPN & VPS GDPR12 min letturaPhoto via Unsplash

Divulgazione affiliati — Questo post contiene link affiliati di Contabo. Se acquisti un VPS tramite questi link, guadagniamo una commissione senza costi aggiuntivi per te. Ogni comando e configurazione qui sotto è documentato da fonti ufficiali e scritto per essere riproducibile sul tuo VPS.

Questo è il difetto nascosto di WireGuard di cui nessuno avverte: configuri il tuo tunnel, tutto il tuo traffico IP passa attraverso Contabo, ti senti al sicuro — tranne che le tue query DNS continuano a raggiungere il tuo ISP, il router dell'hotel o il resolver della rete Wi-Fi aziendale. Una fuga DNS distrugge la garanzia di privacy di qualsiasi VPN: anche se i tuoi dati sono criptati, il tuo ISP sa che stai visitando github.com, tuo-banca.com o altro, perché risolve i nomi per te.

Il problema è strutturale in WireGuard. A differenza di OpenVPN, il protocollo non prende posizione sul DNS — è un tunnel IP puro. La direttiva DNS = ... nel tuo .conf è solo un suggerimento per wg-quick e varia a seconda del sistema operativo. Questa guida spiega perché, come rilevarlo e le soluzioni funzionanti per piattaforma — basate su un anno di debug di fughe reali sui nostri setup Contabo + WireGuard.

Come avviene realmente una fuga DNS

Tre meccanismi distinti producono una fuga DNS su un client WireGuard:

1. Il sistema operativo mantiene attivi i suoi resolver originali. Su Linux senza resolvectl, /etc/resolv.conf viene riscritto da NetworkManager, dhclient o systemd-resolved ad ogni evento (rinnovo DHCP, riattivazione, cambio rete). Il DNS che hai impostato tramite wg-quick viene sovrascritto. L'applicazione effettua una query → il sistema interroga il DNS originale → quel DNS vede le tue query al di fuori del tunnel.

2. Browser con DNS over HTTPS / DNS over TLS bypassano il sistema operativo. Firefox e Chrome hanno DoH abilitato di default in molte regioni. Quando il browser apre una connessione DoH a mozilla.cloudflare-dns.com, quella connessione transita attraverso il tunnel WireGuard (fin qui tutto bene), ma il browser bypassa completamente il resolver locale. Se un provider DoH mantiene i log, le tue query sono visibili lì, in modo diverso.

3. App che usano resolver hardcoded. Alcune app (Spotify, alcune app Microsoft, alcuni giochi) hanno hardcoded 8.8.8.8 o i loro server proprietari. Fanno una query UDP/53 direttamente a 8.8.8.8 — e se il tuo firewall non blocca ciò al di fuori del tunnel, la query esce.

La conclusione è brutale: una fuga DNS non è un bug di WireGuard, è uno stato strutturale dei sistemi operativi. Devi bloccare attivamente le cose per prevenirlo.

Rilevamento affidabile — gli strumenti giusti

Dimentica i test di fuga cosmetici per un minuto. Ecco i tre test che eseguiamo ogni volta che sospettiamo una fuga:

Test 1: dnsleaktest.com (esteso) + ipleak.net

Entrambi i siti fanno la stessa cosa: caricano una pagina che effettua query DNS a sottodomini unici generati casualmente, quindi guardano sul lato server quali resolver hanno richiesto quei sottodomini. Se vedi resolver nel tuo paese di origine (il tuo ISP, il tuo Wi-Fi aziendale), è una fuga. Se vedi solo resolver dalla regione del tuo VPS (Cloudflare DE, Hetzner DE), sei pulito.

Primo controllo più veloce: il nostro test di fuga IP & DNS — eseguito interamente nel tuo browser, nulla viene registrato. Poi verifica incrociata con dnsleaktest.com/extended-test | ipleak.net

Test 2: tcpdump lato server (il più affidabile)

Questo è il test realmente a prova di errore. Sul tuo VPS che ospita WireGuard:

tcpdump -i wg0 -n udp port 53

Lascialo in esecuzione. Sul tuo client (laptop, telefono) connesso al tunnel, digita curl https://example.com. Devi vedere una query DNS nel tcpdump su wg0. Se non vedi nulla, il tuo client ha risolto il DNS senza passare attraverso il tunnel = fuga.

Alternativa sul lato client stesso, ancora più pulita:

sudo tcpdump -i any -n udp port 53 and not net 10.66.0.0/16

Dove 10.66.0.0/16 è la tua subnet del tunnel WireGuard. Se appare qualcosa qui, è una fuga — traffico DNS che fluisce al di fuori del tunnel.

Test 3: stato resolvectl (solo Linux)

resolvectl status

Per ogni interfaccia, vedi i server DNS in uso. L'interfaccia wg0 dovrebbe elencare il tuo DNS del tunnel, e idealmente l'interfaccia eth0 non dovrebbe avere server DNS (o essere ignorata). Se eth0 mantiene attivi i resolver del tuo ISP, le applicazioni li useranno quando la risoluzione DNS fallisce su wg0 (comportamento di fallback).

Soluzioni funzionanti per piattaforma

Linux desktop — la soluzione più robusta

Raccomandazione: systemd-resolved + DNS per interfaccia + blocco nftables.

Nel tuo WireGuard .conf, il blocco [Interface]:

[Interface]
PrivateKey = ...
Address = 10.66.0.2/24
DNS = 10.66.0.1
PostUp = resolvectl dns %i 10.66.0.1; resolvectl domain %i '~.'
PreDown = resolvectl revert %i

Il dominio ~. dice a systemd-resolved "tutte le query DNS passano attraverso questa interfaccia". Il PreDown ripristina alla disconnessione.

Poi blocco firewall nftables — blocca qualsiasi traffico DNS NON diretto al tuo VPS:

nft add table inet vpn_lock
nft add chain inet vpn_lock output { type filter hook output priority 0 \; }
nft add rule inet vpn_lock output udp dport 53 ip daddr != 10.66.0.1 drop
nft add rule inet vpn_lock output tcp dport 53 ip daddr != 10.66.0.1 drop

Rendi persistente questo in /etc/nftables.conf per la sopravvivenza al riavvio. Questa regola elimina qualsiasi pacchetto UDP/TCP 53 non destinato al tuo resolver VPS. Brutale ma efficace — qualsiasi fuga è fisicamente bloccata.

Windows 10/11

Il client nativo WireGuard rispetta correttamente DNS = ... tramite il driver Wintun. Il problema: il DNS diviso non è ottimale di default, e DoH in Edge/Chrome può bypassare.

Passaggi:

  1. Nel tuo .conf, DNS = 10.66.0.1 (il tuo resolver VPS).
  2. Disabilita DoH nel browser: in Chrome chrome://settings/security → deseleziona "Usa DNS sicuro"; in Edge stessa impostazione.
  3. Indurimento firewall: Windows Defender Firewall con Sicurezza Avanzata → regola in uscita che blocca UDP/53 tranne che verso l'IP del tuo VPS. Il comando PowerShell:
New-NetFirewallRule -DisplayName "Block DNS Leak" `
  -Direction Outbound -Protocol UDP -LocalPort 53 `
  -RemoteAddress "!10.66.0.1" -Action Block

La sintassi ! iniziale significa "qualsiasi cosa tranne". Regola 10.66.0.1 all'IP del tuo resolver VPS.

macOS Sonoma/Sequoia

Il client WireGuard per macOS (App Store) rispetta correttamente il DNS. Ma la cache mDNSResponder e la vicinanza a .local possono introdurre sorprese.

Passaggi:

  1. Configurazione WireGuard: DNS = 10.66.0.1.
  2. Dopo la connessione, svuota la cache DNS: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder.
  3. Disabilita DoH nel browser (come su Windows).
  4. Verifica con scutil --dns che solo il tuo DNS del tunnel appaia nel blocco "resolver #1".

iOS — il client WireGuard è onesto

Il client ufficiale WireGuard per iOS rispetta DNS = ... in modo pulito. Di solito non devi fare altro. Attenzione però:

  • Safari può utilizzare iCloud Private Relay se attivo, il che aggiunge un ulteriore livello (Cloudflare/Akamai) — non è una fuga, ma cambia il routing.
  • App che utilizzano porte non standard (alcuni VoIP) possono bypassare — raro ma esiste.

Test reale: abilita il tunnel, vai su dnsleaktest.com su Safari, dovresti vedere solo resolver dalla regione del tuo VPS.

Android — il caso più complesso

Il client ufficiale WireGuard per Android gestisce il DNS parzialmente. Il problema classico: Android getprop net.dns1 mantiene attivo il DNS originale, e alcune app Android interrogano direttamente quella proprietà, bypassando il tunnel.

Mitigazioni in ordine di preferenza:

  1. NetGuard o AFWall+ in combinazione con WireGuard: NetGuard crea una VPN locale che blocca tutto il traffico DNS sul tuo tunnel. Gratuito, open-source su F-Droid.
  2. DNS privato Android (impostazioni → Rete → DNS privato) con un server DoT di cui ti fidi: dns.adguard.com o il tuo server con supporto Unbound + DoT. DoT funziona anche senza VPN, quindi è un livello base di protezione.
  3. AdGuard Home o NextDNS come provider DNS privato: stessa configurazione, ma controlli completamente il resolver.

Verdetto onesto: WireGuard per Android + DNS privato puntato al tuo VPS è una delle configurazioni più robuste disponibili. Configurato in questo modo, mantiene affidabilmente la risoluzione DNS all'interno del tunnel su mobile.

Configurazione solida lato VPS — Unbound su Contabo

Codice sorgente in un editor di terminale
Codice sorgente in un editor di terminale

L'altra metà dell'equazione è chi risponde al DNS sul tuo VPS. Di default, se il tuo client WireGuard punta a 10.66.0.1, quello è il tuo VPS — e il VPS stesso ha bisogno di un resolver reale. Due opzioni valide:

Opzione A: Unbound (purista, completamente ricorsivo)

Unbound interroga direttamente le radici DNS. Zero log di terze parti. La configurazione di privacy più pulita. Installa su un VPS Contabo S (Debian 12):

apt install unbound unbound-anchor

Configurazione minima in /etc/unbound/unbound.conf.d/vpn.conf:

server:
  interface: 10.66.0.1
  access-control: 10.66.0.0/24 allow
  hide-identity: yes
  hide-version: yes
  qname-minimisation: yes
  use-caps-for-id: yes
  prefetch: yes
  cache-min-ttl: 300
  cache-max-ttl: 86400
  num-threads: 2
  msg-cache-size: 50m
  rrset-cache-size: 100m

Riavvia: systemctl restart unbound. Testa da un client: dig @10.66.0.1 example.com — dovresti ottenere una risposta con ANSWER SECTION.

Opzione B: AdGuard Home (filtraggio + UI)

Se vuoi bloccare annunci/tracker a livello DNS, AdGuard Home è la scelta facile. Interfaccia web, liste di filtri (EasyList, EasyPrivacy, OISD, …), statistiche per client. Installa:

curl -s -S -L https://raw.githubusercontent.com/AdguardTeam/AdGuardHome/master/scripts/install.sh | sh -s -- -v

Configurazione web sulla porta 3000 → imposta l'ascolto su 10.66.0.1:53. Upstream: lascia lo stack DoT/DoH di default (o collegalo a Unbound su 127.0.0.1 per la modalità purista completa).

Noi eseguiamo AdGuard Home → Unbound sul nostro Contabo. Il meglio di entrambi i mondi: filtraggio + zero log.

Configurare una delle due opzioni richiede 15 minuti su un VPS Contabo S a €4.99/mese appena fornito (configurazione completa: tutorial passo-passo Contabo). Il costo totale rimane €60/anno per un VPS che gestisce WireGuard + il tuo resolver DNS in un colpo solo.

Rafforzamento delle fughe DNS lato VPS

Tre ulteriori modifiche sul lato hub WireGuard che rendono le fughe DNS molto più difficili:

1. Forza il DNS del tunnel tramite iptables/nftables. Sul VPS, intercetta qualsiasi traffico UDP/53 proveniente dalla subnet WireGuard e reindirizzalo al tuo resolver locale:

nft add rule ip nat prerouting iif wg0 udp dport 53 dnat to 10.66.0.1

Anche se un client tenta di interrogare direttamente 8.8.8.8, il VPS intercetta e risponde tramite Unbound. Brutale ma a prova di errore.

2. Blocca la fuga IPv6 lato server. Se il tuo VPS non disabilita IPv6 sull'interfaccia wg0, alcuni client perderanno DNS su IPv6 al di fuori del tunnel. Disabilita completamente IPv6 sul VPS (net.ipv6.conf.all.disable_ipv6=1 in /etc/sysctl.conf), o spingi una rotta IPv6 ::/0 attraverso wg0 nelle AllowedIPs del client.

3. Monitoraggio in uscita di DNS insoliti. Imposta un cron giornaliero sul VPS che controlla i log di Unbound per query da IP esterni (non 10.66.0.0/24). Se arrivano query dall'esterno, il tuo tunnel è permeabile o aperto. Vedi il nostro monitoraggio VPS WireGuard con Prometheus + Grafana per una configurazione pronta per il dashboard.

Falsi positivi comuni — non farti prendere dal panico

Due situazioni sembrano fughe ma non lo sono:

1. iCloud Private Relay (macOS/iOS). Se hai Private Relay attivo, le query DNS sono dual-relay tramite Apple + Cloudflare/Akamai. dnsleaktest.com a volte mostra "Cloudflare US" invece del tuo DNS del tunnel — è un comportamento previsto, non una fuga. Disabilita Private Relay se vuoi vedere solo il tuo DNS del tunnel.

2. Browser DoH (Firefox, Chrome). Con DoH attivo, il tuo browser bypassa il resolver del sistema operativo e interroga un server DoH (cloudflare-dns.com di default in Firefox). Tecnicamente non è una fuga — la connessione passa attraverso il tunnel WireGuard — ma significa che una terza parte (Cloudflare) vede le tue query. Disabilita DoH nel browser se vuoi che tutte le query passino attraverso il tuo resolver VPS.

Verdetto finale — la checklist anti-fuga in 5 minuti

In ordine di priorità, cosa mettere in atto per eliminare le fughe DNS su un WireGuard autogestito:

  1. DNS = 10.66.0.1 nel tuo .conf + PostUp = resolvectl dns %i 10.66.0.1; resolvectl domain %i '~.' su Linux.
  2. Firewall nftables/iptables che blocca UDP/TCP 53 al di fuori del tunnel sul client.
  3. Resolver lato VPS: Unbound o AdGuard Home su 10.66.0.1.
  4. DNAT lato VPS per UDP/53 da wg0 a 10.66.0.1.
  5. Disabilita DoH nel browser (o accetta che Cloudflare veda le tue query).
  6. Verifica con tcpdump -i any -n udp port 53 sul client — l'obiettivo è zero traffico al di fuori di wg0.

Una configurazione WireGuard pulita su Contabo con questo stack: nessuna fuga DNS una volta bloccata correttamente. Nessuna magia — il protocollo è solido, i sistemi operativi sono complessi, e il blocco è strutturale, non opzionale.

Approfondimenti

Fonti e riferimenti:

Pubblicato il 2026-06-05. Test e correzioni validati su Debian 12, Ubuntu 24.04, Windows 11 23H2, macOS Sonoma 14.5, iOS 17.5, Android 14 — con un VPS Contabo S Norimberga che esegue WireGuard 1.0.20210914 + AdGuard Home + Unbound. Il comportamento può variare su altre distro o versioni OS — verifica sempre la tua configurazione con tcpdump prima di considerarla a prova di fuga.

Promemoria: WireGuard e l'autogestione dei resolver DNS sono perfettamente legali nell'UE, negli Stati Uniti, in Canada e nella maggior parte dei paesi democratici. VPNSmith pubblica questo contenuto a scopo educativo.

★ Datacenter GDPR di Norimberga · ✓ IPv4 dedicato incluso · 200+ Mbps garantiti

Self-host your VPN on your own VPS → ContaboFull root access · public IPv4 · pick your region→
Articoli correlati

Leggi dopo