---
title: "Vazamentos de WebRTC e DNS: o que são e como evitar"
description: "Mesmo com proxy ligado, o navegador pode revelar o seu IP real por WebRTC ou DNS. Explicamos por que os vazamentos acontecem, como testar e como corrigir."
url: https://proxynet.io/pt-br/blog/webrtc-dns-leak
date: 2026-09-13
author: "Acar Diveroli"
category: "Proxy 101, Tutoriais"
lang: pt-BR
---

# 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.

> **Nota: Resposta rápida**
>
> O vazamento de WebRTC acontece quando o WebRTC, usado pelo navegador em chamadas de vídeo, contorna o proxy, chega a um servidor STUN por UDP e informa à página o seu IP público real. O vazamento de DNS acontece quando as consultas de nomes de domínio saem pela sua própria rede em vez de passar pelo proxy. Para WebRTC, use a política `WebRtcIPHandling` no Chrome e as configurações `media.peerconnection` no Firefox; para DNS, ative a resolução remota (`socks5h`) com SOCKS5.

## 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?](/pt-br/blog/what-is-a-proxy-server).

## 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](https://www.rfc-editor.org/rfc/rfc8445).

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](https://www.rfc-editor.org/rfc/rfc8828) 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. Explicamos como funciona a resolução de nomes e como ver ou mudar o servidor DNS que o seu dispositivo usa em [O que é DNS e como mudar o seu servidor DNS?](/pt-br/blog/what-is-dns).

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](/pt-br/blog/socks-vs-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:

```javascript
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:

```bash
# 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](/pt-br/blog/curl-proxy).

## 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](https://chromeenterprise.google/policies/web-rtc-ip-handling/) aceita estes valores:

| Valor | Comportamento | Equivalente na RFC 8828 |
|---|---|---|
| `default` | Todas as interfaces de rede são usadas | Modo 1 |
| `default_public_and_private_interfaces` | Endereço público e local da rota padrão | Modo 2 |
| `default_public_interface_only` | Só o endereço público da rota padrão | Modo 3 |
| `disable_non_proxied_udp` | UDP que não passa por proxy é desativado; o WebRTC recorre a TCP pelo proxy | Modo 4 |

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:

```powershell
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](/pt-br/blog/windows-chrome-proxy-settings).

## 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.

| Configuração | Valor | Efeito |
|---|---|---|
| `media.peerconnection.ice.proxy_only_if_behind_proxy` | `true` | Com proxy configurado, o WebRTC só se conecta pelo proxy |
| `media.peerconnection.ice.default_address_only` | `true` | Só o endereço da rota padrão é usado |
| `media.peerconnection.ice.no_host` | `true` | Candidatos locais (host) não são enviados |
| `media.peerconnection.enabled` | `false` | O WebRTC é desligado completamente |

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 **"Proxy DNS ao usar 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](/pt-br/blog/firefox); para gerenciar proxy por perfil, veja o nosso guia do [SwitchyOmega](/pt-br/blog/switchy-omega).

## 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 "Proxy DNS ao usar 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?](/pt-br/blog/socks5-proxy-101). Configurações que também cobrem o tráfego de aplicativos usam planos [Proxies SOCKS5](https://proxynet.io/pt-br/socks5-proxy).

## 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. Os sites que restringem conteúdo por país leem esses mesmos sinais; como eles decidem onde você está explicamos em [O que é bloqueio geográfico e como os sites localizam você?](/pt-br/blog/what-is-geo-blocking).

- **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](/pt-br/blog/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?](/pt-br/blog/what-is-antidetect-browser).

## 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](https://proxynet.io/pt-br/residential-proxy), 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](https://proxynet.io/pt-br/mobile-proxy).
- **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

| Verificação | Como | Resultado esperado |
|---|---|---|
| Endereço de saída HTTP | Página de verificação de IP | O endereço do proxy |
| Candidatos WebRTC | Teste de `RTCPeerConnection` no console | Sem `srflx`, ou com o endereço do proxy |
| Política do Chrome | `chrome://policy` | `WebRtcIPHandling: disable_non_proxied_udp` |
| WebRTC no Firefox | `about:config` | `proxy_only_if_behind_proxy: true` |
| DNS com SOCKS5 | Esquema no endereço do proxy | `socks5h://` ou opção de DNS remoto ligada |
| Servidores DNS | Teste de vazamento de DNS | Os servidores do seu próprio provedor não aparecem |
| Fuso horário e idioma | Configurações do navegador e do sistema operacional | Coerentes com a localização do proxy |
| Cookies | Perfil separado ou sessão limpa | Nenhum cookie de sessão de fora do proxy |

## 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](/pt-br/blog/iphone-proxy); 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](/pt-br/proxy).