Vazamentos de WebRTC e DNS: o que são e como evitar

Você configura um proxy no navegador, a página de verificação de IP mostra o endereço do proxy e tudo parece certo. Mas uma página aberta nesse mesmo navegador ainda consegue descobrir o seu IP real com poucas linhas de JavaScript. Há dois caminhos comuns para isso: WebRTC e consultas DNS. Os dois funcionam fora do tráfego HTTP que o proxy cobre, então podem não ser afetados pela configuração de proxy.

Neste artigo, explicamos o que é um vazamento de IP, o mecanismo pelo qual o WebRTC expõe o seu endereço real, de onde vêm os vazamentos de DNS e como testar os dois. Depois, vemos as configurações do Chrome e do Firefox que fecham o vazamento, por que a resolução DNS remota importa com SOCKS5 e outros sinais, além do IP, que revelam a sua localização. No final há uma checklist de uma página.

O que é vazamento de IP?#

Vazamento de IP é o seu endereço IP real ficar visível por uma parte do seu tráfego enquanto você usa proxy ou VPN. Vazamento não significa que o proxy não está funcionando. As requisições HTTP da página passam pelo proxy, e o site de destino vê o endereço do proxy nessas requisições. O problema é que o navegador também pode abrir outras conexões de rede além de HTTP.

A configuração de proxy de um navegador geralmente cobre só requisições HTTP e HTTPS. As outras conexões que um navegador faz são:

• WebRTC: conexões diretas por UDP para chamadas de vídeo, compartilhamento de tela e transferência de dados ponto a ponto.
• Consultas DNS: consultas que o sistema operacional ou o navegador envia a um servidor DNS para transformar nomes de domínio em endereços IP.
• Extensões do navegador e conexões internas de aplicativos: componentes que usam as próprias configurações de rede.

Se um site vê o seu endereço real por um desses canais, pode compará-lo com o endereço mostrado pelo proxy. Dois endereços de países diferentes mostram claramente que o visitante usa proxy. Explicamos como um proxy funciona em O que é um servidor proxy e como ele funciona?.

Como o WebRTC revela o seu IP real?#

O WebRTC foi projetado para que dois navegadores conversem diretamente sem passar por um servidor. Para isso, cada navegador precisa saber em quais endereços pode ser alcançado e informá-los ao outro lado. Esses endereços se chamam candidatos ICE, e o processo de descoberta é definido na RFC 8445.

Quando uma página inicia uma conexão WebRTC, acontece o seguinte:

1. A página cria um RTCPeerConnection. Ela não precisa pedir permissão ao usuário; câmera e microfone não são ligados. Basta pedir um canal de dados.
2. O navegador reúne candidatos locais. São os endereços das interfaces de rede do computador (candidatos host). Os navegadores atuais escondem o endereço local atrás de um nome aleatório xxxx.local em vez de mostrá-lo diretamente.
3. O navegador envia um pacote UDP a um servidor STUN. O servidor STUN informa de volta o endereço IP público e a porta de onde o pacote veio. Esse endereço é registrado como candidato srflx (server reflexive).
4. O pacote UDP não passa pelo proxy. Um proxy HTTP só transporta tráfego HTTP; o navegador envia o pacote STUN diretamente pela interface de rede. O servidor STUN vê o pacote vindo do seu IP público real.
5. Os candidatos são informados à página. O JavaScript lê a lista de candidatos pelo evento onicecandidate e pode enviar ao próprio servidor o IP público do candidato srflx.

O resultado: a página vê o endereço do proxy nas requisições HTTP e o seu endereço real pelo WebRTC.

Quais endereços os navegadores podem expor no WebRTC é definido na RFC 8828 em quatro modos: usar todas as interfaces, usar só a rota padrão e o endereço local associado, usar só o endereço público da rota padrão e forçar o UDP pelo proxy. As configurações do Chrome e do Firefox correspondem a esses modos.

O que é vazamento de DNS?#

Antes de se conectar a um site, o nome de domínio precisa ser transformado em endereço IP. O vazamento de DNS é quando essa consulta é feita pelo servidor DNS do seu provedor de internet ou da sua rede local em vez de passar pelo proxy.

O vazamento de DNS tem duas consequências:

• Os sites que você visita ficam visíveis a partir da rede local. O seu provedor de internet, a rede do trabalho ou alguém na mesma rede Wi-Fi pode ver quais nomes de domínio você consulta, mesmo com proxy.
• O site de destino pode entregar outro endereço de servidor. Sites que usam CDN retornam o servidor mais próximo com base na localização do servidor que faz a consulta DNS. Se a consulta sai de Türkiye enquanto a requisição sai por um proxy na Alemanha, você é mandado a um servidor distante e surge uma incoerência de localização.

Os vazamentos de DNS são mais comuns quando:

• Com proxy SOCKS5, o cliente resolve o nome de domínio sozinho e envia só um endereço IP ao proxy.
• O proxy está configurado só no navegador e os outros aplicativos usam o DNS do sistema.
• O software de VPN ou proxy não altera as configurações de DNS do sistema operacional.

Com proxies HTTP e HTTPS, o navegador envia o nome de domínio ao proxy na requisição CONNECT example.com:443, e quem resolve é o proxy. Isso torna os proxies HTTP menos arriscados quanto a vazamento de DNS no tráfego web do navegador. Explicamos como os dois protocolos diferem nesse ponto em SOCKS ou HTTP proxy.

Como testar vazamentos de WebRTC e DNS?#

Existem páginas de teste prontas, mas fazer o teste você mesmo uma vez ensina o que procurar.

Teste de WebRTC#

Com o proxy ligado, abra qualquer página no navegador, abra o console das ferramentas do desenvolvedor (F12) e rode este código:

const pc = new RTCPeerConnection({ iceServers: [{ urls: "stun:stun.l.google.com:19302" }] });
pc.createDataChannel("test");
pc.onicecandidate = (e) => {
  if (e.candidate) console.log(e.candidate.candidate);
};
await pc.setLocalDescription(await pc.createOffer());

Algumas linhas de candidatos vão aparecer no console. Procure a linha que contém typ srflx. Se o endereço IP dessa linha for:

• igual ao IP de saída do proxy, ou se não houver nenhuma linha srflx, não há vazamento de WebRTC.
• o seu endereço IP real, há vazamento de WebRTC.

Se você não sabe o seu endereço IP real, abra uma página de verificação de IP com o proxy desligado.

Teste de DNS#

O vazamento de DNS não pode ser medido só pelo navegador, porque apenas o dono do domínio consegue ver de qual servidor DNS veio uma consulta. Por isso as páginas de teste de vazamento de DNS fazem você resolver subdomínios gerados aleatoriamente e mostram quais servidores DNS fizeram essas consultas. Se o resultado mostrar os servidores DNS do seu próprio provedor de internet, as consultas não estão passando pelo proxy.

Na linha de comando, a saída detalhada do cURL mostra como um proxy SOCKS5 trata o DNS:

# Resolução local: o nome de domínio vira IP no seu computador
curl -v -x "socks5://user:pass@pr.proxynet.io:1080" https://httpbin.org/ip

# Resolução remota: o nome de domínio é enviado ao proxy, que faz a resolução
curl -v -x "socks5h://user:pass@pr.proxynet.io:1080" https://httpbin.org/ip

Na saída do primeiro comando, o cURL informa que resolveu o domínio antes de conectar e enviou um endereço IP ao proxy. No segundo, o próprio nome de domínio é enviado ao proxy. Todas as opções de proxy do cURL estão em Como usar proxy com cURL.

Como evitar vazamento de WebRTC no Chrome?#

O menu de configurações do Chrome não tem opção para desligar o WebRTC. Esse comportamento é alterado por política corporativa ou por extensões. O método da política não precisa de extensão e se baseia na documentação oficial do Google.

A política WebRtcIPHandling do Chrome Enterprise aceita estes valores:

O valor que fecha o vazamento quando você usa proxy é disable_non_proxied_udp. No Windows, você pode gravar essa política no registro pelo PowerShell aberto como administrador:

New-Item -Path "HKLM:\SOFTWARE\Policies\Google\Chrome" -Force | Out-Null
Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Google\Chrome" -Name "WebRtcIPHandling" -Value "disable_non_proxied_udp"

Feche o Chrome completamente, abra de novo e digite chrome://policy na barra de endereços para confirmar que a política foi carregada. Depois repita o teste de WebRTC acima.

Essa configuração tem um custo: ferramentas de chamada de vídeo e compartilhamento de tela baseadas no navegador não conseguem usar UDP, então podem ficar lentas ou nem funcionar. Se você faz trabalho com proxy e chamadas de vídeo no mesmo computador, é mais prático usar um perfil de navegador separado, ou um navegador separado, para cada coisa. De onde o Chrome lê a configuração de proxy está explicado em Configuração de proxy no Windows e no Chrome.

Como evitar vazamento de WebRTC no Firefox?#

O Firefox oferece essas configurações na página about:config. Digite about:config na barra de endereços, aceite o aviso e procure as configurações abaixo.

A primeira configuração busca fechar o vazamento durante o uso do proxy sem quebrar totalmente as ferramentas de chamada. Definir media.peerconnection.enabled como false é a correção mais definitiva, mas desativa todos os recursos de chamada de vídeo e compartilhamento de tela do navegador.

Para o DNS no Firefox, marque também "Usar proxy DNS ao utilizar SOCKS v5" na tela de configurações de proxy. No about:config, essa opção é network.proxy.socks_remote_dns. A configuração completa de proxy no Firefox está em Configuração de proxy no Firefox; para gerenciar proxy por perfil, veja o nosso guia do SwitchyOmega.

Por que o DNS remoto importa com SOCKS5?#

O protocolo SOCKS5 permite ao cliente informar o destino ao proxy de duas formas: como endereço IP ou como nome de domínio. Se o cliente envia um endereço IP, é porque resolveu o nome de domínio sozinho, o que significa que a consulta DNS saiu pela sua própria rede.

Em bibliotecas e ferramentas, esse comportamento tem nomes diferentes:

• cURL: socks5:// resolve localmente, socks5h:// remotamente.
• Python Requests e HTTPX: o esquema socks5h:// no endereço do proxy.
• Firefox: a opção "Usar proxy DNS ao utilizar SOCKS v5".
• Chrome: envia o nome de domínio ao proxy com SOCKS5.
• Ferramentas de roteamento como o Proxifier: uma opção do tipo "Resolver nomes de host pelo proxy".

O segundo benefício da resolução remota é a coerência de localização: quando o proxy resolve o DNS, as CDNs retornam um servidor próximo da localização do proxy. Para os detalhes técnicos do SOCKS5, veja O que são proxies SOCKS5?. Configurações que também cobrem o tráfego de aplicativos usam planos Proxies SOCKS5.

Sinais além dos vazamentos que revelam a sua localização#

Depois de fechar os vazamentos de IP e DNS, uma página ainda pode reunir pistas sobre a sua localização a partir do que sabe do próprio navegador. Não são vazamentos de rede, mas, quando contradizem a localização do proxy, têm o mesmo efeito.

• Fuso horário. O JavaScript lê o fuso horário do sistema com Intl.DateTimeFormat().resolvedOptions().timeZone. Um IP saindo na Alemanha com fuso Europe/Istanbul é uma contradição.
• Preferências de idioma. navigator.languages e o cabeçalho Accept-Language mostram a ordem de idiomas do navegador.
• Permissão de localização. Se você deu permissão de localização a um site no navegador, a API de geolocalização pode retornar a sua localização real com base nas redes Wi-Fi próximas.
• Cookies e sessões. Um cookie de sessão de uma visita sem proxy também é enviado na visita com proxy e liga as duas visitas.
• Impressão digital do navegador. Resolução de tela, fontes e informações da placa de vídeo identificam o navegador independentemente do IP. Os detalhes estão em Browser fingerprinting.

Se você precisa trabalhar com mais de uma identidade, há configurações que mantêm coerentes entre si o proxy, o fuso horário e o idioma de cada perfil; explicamos em O que é um navegador antidetect?.

Casos de uso#

• Uma equipe que verifica anúncios e conteúdo em países diferentes: um vazamento de WebRTC pode fazer o site classificar você na localização errada. Junto com um Proxies residenciais, que sai por linhas de usuários reais, as configurações do navegador também precisam ser corrigidas.
• Um desenvolvedor que testa tráfego com cara de celular: um IP de operadora móvel aparecendo no WebRTC junto com o endereço real de uma rede de desktop gera incoerência. A mesma verificação vale ao usar um Proxies móveis.
• Um usuário que roteia um aplicativo de desktop por proxy: as consultas DNS do aplicativo podem passar pelo DNS do sistema; a resolução remota precisa estar ligada na ferramenta de roteamento.
• Uma equipe que usa automação de navegador: navegadores de automação também suportam WebRTC. A mesma política ou uma configuração de inicialização equivalente deve ser usada ao iniciar o Chrome.

Erros comuns#

• Considerar suficiente o resultado da página de verificação de IP. Essas páginas só mostram o endereço da requisição HTTP; WebRTC e DNS precisam ser testados separadamente.
• Mudar a configuração sem reiniciar o navegador. As políticas do Chrome só carregam depois que o navegador é fechado e aberto de novo por completo.
• Usar VPN e proxy juntos e interpretar mal o endereço vazado. Com a VPN ligada, o endereço da VPN aparece no teste de WebRTC; não é o seu endereço real, mas também não bate com o do proxy.
• Deixar o esquema socks5:// como padrão. A maioria dos exemplos de bibliotecas usa o esquema que resolve localmente.
• Desligar o WebRTC por completo e estranhar que as ferramentas de chamada não funcionem. proxy_only_if_behind_proxy ou um perfil separado alcançam o mesmo com menos efeitos colaterais.
• Esquecer o fuso horário e o idioma. Mesmo com os vazamentos de rede fechados, esses sinais revelam a incoerência de localização.

Checklist#

Perguntas frequentes#

Vazamentos de WebRTC só afetam quem usa proxy?#

Podem afetar quem usa VPN também, mas, como a maioria das VPNs funciona no nível do sistema operacional e também leva o tráfego UDP pelo túnel, os vazamentos são menos comuns. O proxy só cobre o tráfego HTTP do navegador, então o risco é maior.

Desligar o WebRTC quebra sites?#

Chamadas de vídeo, chat de voz, compartilhamento de tela e alguns serviços de transferência de arquivos baseados no navegador param de funcionar ou ficam lentos. A grande maioria dos sites comuns não é afetada.

O meu endereço IP local (192.168...) continua vazando?#

As versões atuais do Chrome e do Firefox escondem por padrão os endereços locais atrás de nomes aleatórios terminados em .local. O risco real é o IP público obtido via STUN.

Pode haver vazamento de DNS com proxy HTTP?#

Geralmente não no tráfego web do navegador, porque o nome de domínio é enviado ao proxy na requisição CONNECT. Mas outros aplicativos e componentes do sistema operacional sem proxy configurado continuam fazendo as próprias consultas DNS.

Há vazamento de WebRTC em dispositivos móveis?#

Pode haver. Navegadores móveis também suportam WebRTC, e um proxy de Wi-Fi configurado no celular só cobre o tráfego HTTP. Explicamos a configuração de proxy no iPhone em Configuração de proxy no iPhone; você pode fazer o mesmo teste de WebRTC em um navegador móvel.

Fechei o vazamento, mas o site ainda sabe que uso proxy. Por quê?#

O próprio endereço IP pode pertencer a um data center, o fuso horário e o idioma podem contradizer a localização do proxy ou a impressão digital do navegador pode bater com a sua visita anterior. O vazamento de rede é só um desses sinais.

Em resumo#

O proxy transporta o tráfego HTTP do navegador; as conexões UDP do WebRTC e algumas consultas DNS podem ficar fora desse alcance. Feche os vazamentos de WebRTC com a política WebRtcIPHandling no Chrome e as configurações media.peerconnection no Firefox. Para vazamentos de DNS, use resolução remota com SOCKS5 e confirme os resultados com o teste no console. Depois, garanta que fuso horário, idioma e cookies estejam coerentes com a localização do proxy. Planos para tráfego de navegador e de aplicativos estão nos nossos serviços de proxy.