VPNSmith
self-host-vpnHOWTO

Fugas de DNS no WireGuard: detetar, diagnosticar, eliminar (2026)

WireGuard não bloqueia fugas de DNS por defeito. Guia de produção: como ocorrem as fugas, ferramentas de deteção, correções para Linux/Windows/macOS/iOS/Android em 2026.

Por Eric Gerard · Fondateur · VPNSmith — Spécialiste self-host VPN & VPS GDPR12 min de leituraPhoto via Unsplash

Divulgação de afiliados — Este post contém links de afiliados da Contabo. Se adquirir um VPS através deles, ganhamos uma comissão sem custo adicional para si. Todos os comandos e configurações abaixo são documentados a partir de fontes oficiais e escritos para serem reproduzíveis no seu próprio VPS.

Este é o defeito oculto do WireGuard que ninguém avisa: configura o seu túnel, todo o tráfego IP passa pela Contabo, sente-se seguro — exceto que as suas consultas DNS ainda vão para o seu ISP, o router do hotel ou o resolvedor da rede Wi-Fi corporativa. Uma fuga de DNS destrói a garantia de privacidade de qualquer VPN: mesmo que os seus dados estejam encriptados, o seu ISP sabe que está a visitar github.com, seu-banco.com ou qualquer outra coisa, porque resolve os nomes para si.

O problema é estrutural no WireGuard. Ao contrário do OpenVPN, o protocolo não toma posição sobre DNS — é um túnel IP puro. A diretiva DNS = ... no seu .conf é apenas uma dica para o wg-quick e varia conforme o sistema operativo. Este guia desvenda porquê, como detetar e as correções funcionais por plataforma — com base num ano de depuração de fugas reais nas nossas próprias configurações Contabo + WireGuard.

Como realmente ocorre uma fuga de DNS

Três mecanismos distintos produzem uma fuga de DNS num cliente WireGuard:

1. O sistema operativo mantém os seus resolvedores originais ativos. No Linux sem resolvectl, o /etc/resolv.conf é reescrito pelo NetworkManager, dhclient ou systemd-resolved a cada evento (renovação DHCP, despertar, mudança de rede). O DNS que enviou via wg-quick é sobrescrito. A aplicação faz uma consulta → o sistema consulta o DNS original → esse DNS vê as suas consultas fora do túnel.

2. Navegadores com DNS sobre HTTPS / DNS sobre TLS contornam o sistema operativo. O Firefox e o Chrome vêm com DoH ativado por defeito em muitas regiões. Quando o navegador abre uma conexão DoH para mozilla.cloudflare-dns.com, essa conexão transita pelo túnel WireGuard (até aqui tudo bem), mas o navegador contorna completamente o resolvedor local. Se um fornecedor DoH mantiver registos, as suas consultas são visíveis lá, de uma forma diferente.

3. Aplicações que usam resolvedores codificados. Algumas aplicações (Spotify, certas aplicações da Microsoft, alguns jogos) codificam 8.8.8.8 ou os seus servidores proprietários. Fazem uma consulta UDP/53 diretamente para 8.8.8.8 — e se o seu firewall não bloquear isso fora do túnel, a consulta sai.

A conclusão é brutal: uma fuga de DNS não é um bug do WireGuard, é um estado estrutural dos sistemas operativos. Tem de bloquear ativamente para o evitar.

Deteção fiável — as ferramentas certas

Esqueça os testes de fuga cosméticos por um minuto. Aqui estão os três testes que fazemos sempre que suspeitamos de uma fuga:

Teste 1: dnsleaktest.com (extenso) + ipleak.net

Ambos os sites fazem a mesma coisa: carregam uma página que faz consultas DNS para subdomínios únicos gerados aleatoriamente, depois verificam no lado do servidor quais os resolvedores que solicitaram esses subdomínios. Se vir resolvedores no seu país de origem (o seu ISP, o seu Wi-Fi corporativo), é uma fuga. Se apenas vir resolvedores da região do seu VPS (Cloudflare DE, Hetzner DE), está limpo.

Primeira verificação mais rápida: o nosso próprio teste de fuga de IP e DNS — executa-se inteiramente no seu navegador, nada é registado. Depois, verifique com dnsleaktest.com/extended-test | ipleak.net

Teste 2: tcpdump no lado do servidor (o mais fiável)

Este é o teste realmente à prova de falhas. No seu VPS que hospeda o WireGuard:

tcpdump -i wg0 -n udp port 53

Deixe-o a correr. No seu cliente (portátil, telemóvel) conectado ao túnel, digite curl https://example.com. Deve ver uma consulta DNS no tcpdump em wg0. Se não vir nada, o seu cliente resolveu DNS sem passar pelo túnel = fuga.

Alternativa no próprio lado do cliente, ainda mais limpa:

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

Onde 10.66.0.0/16 é a sua sub-rede do túnel WireGuard. Se algo aparecer aqui, é uma fuga — tráfego DNS a fluir fora do túnel.

Teste 3: resolvectl status (apenas Linux)

resolvectl status

Para cada interface, vê os servidores DNS em uso. A interface wg0 deve listar o seu DNS do túnel, e idealmente a interface eth0 não deve ter servidores DNS (ou ser ignorada). Se eth0 mantiver os resolvedores do seu ISP ativos, as aplicações irão usá-los quando a resolução DNS falhar em wg0 (comportamento de fallback).

Correções funcionais por plataforma

Linux desktop — a solução mais robusta

Recomendação: systemd-resolved + DNS por interface + bloqueio nftables.

No seu WireGuard .conf, o bloco [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

O domínio ~. diz ao systemd-resolved "todas as consultas DNS passam por esta interface". O PreDown reverte na desconexão.

Depois, bloqueio de firewall nftables — bloqueie qualquer tráfego DNS que NÃO vá para o seu 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

Persista isto em /etc/nftables.conf para sobrevivência ao reiniciar. Esta regra elimina qualquer pacote UDP/TCP 53 não destinado ao resolvedor do seu VPS. Brutal mas eficaz — qualquer fuga é fisicamente bloqueada.

Windows 10/11

O cliente nativo WireGuard respeita DNS = ... corretamente através do driver Wintun. O problema: o DNS dividido não é ótimo por defeito, e o DoH no Edge/Chrome pode contornar.

Passos:

  1. No seu .conf, DNS = 10.66.0.1 (o seu resolvedor VPS).
  2. Desative o DoH do navegador: no Chrome chrome://settings/security → desmarque "Usar DNS seguro"; no Edge a mesma configuração.
  3. Endurecimento do firewall: Windows Defender Firewall com Segurança Avançada → regra de saída bloqueando UDP/53 exceto para o IP do seu VPS. O comando PowerShell:
New-NetFirewallRule -DisplayName "Block DNS Leak" `
  -Direction Outbound -Protocol UDP -LocalPort 53 `
  -RemoteAddress "!10.66.0.1" -Action Block

A sintaxe ! significa "qualquer coisa exceto". Ajuste 10.66.0.1 para o IP do seu resolvedor VPS.

macOS Sonoma/Sequoia

O cliente WireGuard para macOS (App Store) respeita o DNS corretamente. Mas a cache mDNSResponder e a proximidade com .local podem introduzir surpresas.

Passos:

  1. Configuração WireGuard: DNS = 10.66.0.1.
  2. Após conectar, limpe a cache DNS: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder.
  3. Desative o DoH do navegador (igual ao Windows).
  4. Verifique com scutil --dns que apenas o seu DNS do túnel aparece no bloco "resolver #1".

iOS — o cliente WireGuard é honesto

O cliente oficial WireGuard para iOS respeita DNS = ... de forma limpa. Normalmente não precisa de fazer mais nada. No entanto, tenha atenção:

  • O Safari pode usar o iCloud Private Relay se ativo, o que adiciona uma camada extra (Cloudflare/Akamai) — não é uma fuga, mas altera o encaminhamento.
  • Aplicações que usam portas não padrão (alguns VoIP) podem contornar — raro, mas existe.

Teste na vida real: ative o túnel, vá a dnsleaktest.com no Safari, deve ver apenas resolvedores da região do seu VPS.

Android — o caso mais complicado

O cliente oficial WireGuard para Android lida com DNS parcialmente. O problema clássico: o Android getprop net.dns1 mantém o DNS original ativo, e algumas aplicações Android consultam diretamente essa propriedade, contornando o túnel.

Mitigações por ordem de preferência:

  1. NetGuard ou AFWall+ em conjunto com WireGuard: NetGuard cria uma VPN local que bloqueia todo o tráfego DNS no seu túnel. Gratuito, open-source no F-Droid.
  2. DNS Privado Android (configurações → Rede → DNS Privado) com um servidor DoT em que confia: dns.adguard.com ou o seu próprio servidor com Unbound + suporte DoT. O DoT funciona mesmo sem VPN, por isso é uma camada base de proteção.
  3. AdGuard Home ou NextDNS como fornecedor de DNS Privado: mesma configuração, mas controla totalmente o resolvedor.

Veredicto honesto: WireGuard Android + DNS Privado apontando para o seu próprio VPS é uma das configurações mais robustas disponíveis. Configurado desta forma, mantém de forma fiável a resolução DNS dentro do túnel no móvel.

Configuração sólida do lado do VPS — Unbound na Contabo

Código fonte num editor de terminal
Código fonte num editor de terminal

A outra metade da equação é quem responde ao DNS no seu VPS. Por defeito, se o seu cliente WireGuard aponta para 10.66.0.1, esse é o seu VPS — e o próprio VPS precisa de um resolvedor real. Duas opções viáveis:

Opção A: Unbound (purista, totalmente recursivo)

O Unbound consulta diretamente as raízes DNS. Zero registos de terceiros. A configuração de privacidade mais limpa. Instale num VPS Contabo S (Debian 12):

apt install unbound unbound-anchor

Configuração mínima em /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

Reinicie: systemctl restart unbound. Teste a partir de um cliente: dig @10.66.0.1 example.com — deve obter uma resposta com ANSWER SECTION.

Opção B: AdGuard Home (filtragem + UI)

Se quiser bloqueio de anúncios/rastreadores a nível de DNS, o AdGuard Home é a escolha fácil. UI web, listas de filtros (EasyList, EasyPrivacy, OISD, …), estatísticas por cliente. Instale:

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

Configuração web na porta 3000 → defina a escuta em 10.66.0.1:53. Upstream: deixe a pilha DoT/DoH padrão (ou encadeie para Unbound em 127.0.0.1 para modo purista completo).

Executamos AdGuard Home → Unbound na nossa própria Contabo. Melhor dos dois mundos: filtragem + zero registos.

Configurar qualquer uma das opções leva 15 minutos num VPS Contabo S recém-provisionado a €4.99/mês (configuração completa: tutorial passo a passo Contabo). O custo total mantém-se em €60/ano para um VPS que lida com WireGuard + o seu resolvedor DNS de uma só vez.

Reforço contra fugas de DNS do lado do VPS

Três ajustes adicionais no lado do hub WireGuard que tornam as fugas de DNS muito mais difíceis:

1. Forçar DNS do túnel via iptables/nftables. No VPS, intercepte qualquer tráfego UDP/53 originário da sub-rede WireGuard e redirecione-o para o seu resolvedor local:

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

Mesmo que um cliente tente consultar 8.8.8.8 diretamente, o VPS intercepta e responde via Unbound. Brutal mas à prova de falhas.

2. Bloquear fuga IPv6 do lado do servidor. Se o seu VPS não desativar o IPv6 na interface wg0, alguns clientes irão vazar DNS sobre IPv6 fora do túnel. Ou desative completamente o IPv6 no VPS (net.ipv6.conf.all.disable_ipv6=1 em /etc/sysctl.conf), ou envie uma rota IPv6 ::/0 através de wg0 nas AllowedIPs do cliente.

3. Monitorização de saída de DNS incomum. Configure um cron diário no VPS que audita os registos Unbound para consultas de IPs externos (não 10.66.0.0/24). Se chegarem consultas de fora, o seu túnel está a vazar ou aberto. Veja o nosso monitorização de VPS WireGuard com Prometheus + Grafana para uma configuração pronta para o dashboard.

Falsos positivos comuns — não entre em pânico

Duas situações parecem fugas mas não são:

1. iCloud Private Relay (macOS/iOS). Se tiver o Private Relay ativo, as consultas DNS são duplamente retransmitidas através da Apple + Cloudflare/Akamai. dnsleaktest.com às vezes mostra "Cloudflare US" em vez do seu DNS do túnel — isso é comportamento esperado, não uma fuga. Desative o Private Relay se quiser ver apenas o seu DNS do túnel.

2. DoH do navegador (Firefox, Chrome). Com o DoH ativo, o seu navegador contorna o resolvedor do sistema operativo e consulta um servidor DoH (cloudflare-dns.com por defeito no Firefox). Tecnicamente não é uma fuga — a conexão passa pelo túnel WireGuard — mas significa que um terceiro (Cloudflare) vê as suas consultas. Desative o DoH do navegador se quiser que todas as consultas passem pelo resolvedor do seu VPS.

Veredicto final — a checklist de 5 minutos à prova de fugas

Por ordem de prioridade, o que implementar para eliminar fugas de DNS num WireGuard auto-hospedado:

  1. DNS = 10.66.0.1 no seu .conf + PostUp = resolvectl dns %i 10.66.0.1; resolvectl domain %i '~.' no Linux.
  2. Firewall nftables/iptables que bloqueia UDP/TCP 53 fora do túnel no cliente.
  3. Resolvedor do lado do VPS: Unbound ou AdGuard Home em 10.66.0.1.
  4. DNAT do lado do VPS para UDP/53 de wg0 para 10.66.0.1.
  5. Desative o DoH do navegador (ou aceite que a Cloudflare vê as suas consultas).
  6. Verifique com tcpdump -i any -n udp port 53 no cliente — o objetivo é zero tráfego fora de wg0.

Uma configuração limpa do WireGuard na Contabo com esta stack: sem fugas de DNS uma vez que esteja corretamente bloqueada. Sem magia — o protocolo é sólido, os sistemas operativos são complicados, e o bloqueio é estrutural, não opcional.

Indo mais além

Fontes e referências:

Publicado em 2026-06-05. Testes e correções validados em Debian 12, Ubuntu 24.04, Windows 11 23H2, macOS Sonoma 14.5, iOS 17.5, Android 14 — com um VPS Contabo S Nuremberg a executar WireGuard 1.0.20210914 + AdGuard Home + Unbound. O comportamento pode diferir em outras distribuições ou versões de sistemas operativos — sempre verifique a sua própria configuração com tcpdump antes de considerá-la à prova de fugas.

Lembrete: WireGuard e a auto-hospedagem de resolvedores DNS são perfeitamente legais na UE, EUA, Canadá e na maioria dos países democráticos. A VPNSmith publica este conteúdo para fins educacionais.

★ Datacenter GDPR em Nuremberg · ✓ IPv4 dedicado incluído · 200+ Mbps garantidos

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

Leia a seguir