Vazamentos de WebRTC: como seu IP real escapa de um proxy e como testar e corrigir

Você configura um proxy, abre uma consulta de IP e ela mostra o IP do proxy. Missão cumprida? Nem sempre. Uma página ainda pode descobrir seu IP real pelo WebRTC, um recurso do navegador que, por projeto, ignora as configurações de proxy do navegador. Se você usa proxies residenciais para ver um site como um visitante local veria, um vazamento de WebRTC pode desfazer isso sem nenhum sinal visível.

Este guia explica como o vazamento funciona, como testá-lo em dois minutos e como fechá-lo no Chrome, no Firefox e em navegadores automatizados.

Como o vazamento acontece

O WebRTC permite que navegadores façam chamadas e enviem dados diretamente entre si. Para isso, cada navegador coleta “candidatos ICE”: endereços onde ele pode ser alcançado. Uma das etapas é perguntar a um servidor STUN, por UDP, “de que endereço público você me vê chegando?”. A resposta vai para um candidato que o JavaScript da página consegue ler.

O problema é o caminho que essa pergunta percorre. Um proxy HTTP típico transporta apenas suas requisições web, não UDP. Então a requisição STUN sai pela sua própria conexão, e a resposta é seu IP público real. A RFC 8828, o padrão da IETF sobre o tratamento de endereços no WebRTC, diz isso claramente: as verificações STUN podem contornar um proxy e revelar o IP público de um cliente se o acesso direto à internet for permitido. Ela também recomenda que o tráfego WebRTC não seja enviado por proxies por padrão, por causa da qualidade das chamadas.

Dois detalhes importam:

• Os endereços locais agora ficam quase sempre ocultos. Chrome e Firefox substituem seu endereço de rede privado por um nome .local aleatório na maioria das páginas. No Firefox, isso é a configuração media.peerconnection.ice.obfuscate_host_addresses, ativada por padrão. Seu IP público é o risco real.
• A página não precisa de permissão. Coletar candidatos não exige acesso à câmera nem ao microfone, então não há nenhum aviso.

Teste em dois minutos

Você não precisa de um site de teste de terceiros. Abra a página que importa para você, ou qualquer página, com o proxy ligado, abra o console do desenvolvedor (F12) e cole isto:

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

Olhe as linhas que contêm typ srflx. O endereço dessa linha é o IP público que o servidor STUN viu.

• Se ele coincidir com o seu IP de casa ou do escritório, o WebRTC está vazando.
• Se coincidir com o IP do proxy, ou se não houver nenhuma linha srflx, está tudo certo.
• Linhas com typ host e um nome .local são seu endereço local oculto, e são esperadas.

Depois compare com uma consulta de IP como o IP Info no mesmo navegador. Ela deve mostrar o IP e a localização do proxy. Se a consulta mostra o proxy mas a linha srflx mostra você, o proxy funciona e o WebRTC passa por fora dele.

Corrija no Chrome

Mais fácil: use uma extensão que cuide disso. A extensão de navegador da Shifter ativa por padrão a proteção contra vazamentos de WebRTC enquanto você está conectado. Por baixo dos panos, as extensões do Chrome controlam isso pela configuração de privacidade webRTCIPHandlingPolicy. Se outra extensão já controla o WebRTC, só uma das duas pode prevalecer, e a extensão da Shifter avisa quando sua proteção não está ativa. Remova ou desative a outra.

Computadores gerenciados: o Chrome tem uma política corporativa, WebRtcIPHandling, com quatro valores:

Valor	O que o WebRTC usa
default	Todas as interfaces de rede disponíveis
default_public_and_private_interfaces	A interface voltada ao público, endereços privados permitidos
default_public_interface_only	Apenas a interface voltada ao público, sem endereços privados
disable_non_proxied_udp	TCP pelo proxy; UDP somente se o proxy o suportar

Somente disable_non_proxied_udp impede o vazamento do IP público atrás de um proxy. Os dois valores de “interface pública” ainda consultam o servidor STUN pela sua própria conexão.

Corrija no Firefox

A extensão da Shifter também resolve isso no Firefox. Para fazer manualmente, abra about:config e defina:

• media.peerconnection.ice.proxy_only_if_behind_proxy como true: o WebRTC só usa o proxy quando há um configurado. Essa é a correção direcionada.
• media.peerconnection.ice.default_address_only como true: apenas a rota padrão é usada. Isso oculta endereços locais extras, mas sozinho não impede o vazamento do IP público.
• media.peerconnection.enabled como false: desativa o WebRTC por completo. É a opção mais drástica e quebra as chamadas nesse navegador.

Depois, rode o teste no console de novo: a linha srflx deve sumir ou mostrar o IP do proxy.

Corrija em navegadores automatizados

Playwright, Puppeteer e Selenium iniciam um navegador real, então vazam da mesma forma. Para o Chromium, inicie-o com:

--force-webrtc-ip-handling-policy=disable_non_proxied_udp

Para o Firefox, defina as mesmas preferências de about:config no perfil que seu framework inicia. Depois execute o teste de console acima a partir do seu script e verifique o resultado srflx como parte das suas verificações de configuração. Nosso guia sobre proxies residenciais no Selenium e no Playwright mostra onde essas opções entram.

O WebRTC não é o único vazamento

Feche as outras brechas relacionadas já que está aqui:

• DNS. As consultas de nome podem contornar o proxy e ser resolvidas pela sua própria rede. Nosso guia sobre como evitar vazamentos de DNS cobre socks5h e como verificar.
• IPv6. Se o caminho do seu proxy é apenas IPv4, um navegador que também tem IPv6 pode usá-lo em algumas requisições.
• Fuso horário e idioma. Eles não revelam seu IP, mas podem contradizer a localização do proxy.

Em resumo

Um vazamento de WebRTC acontece porque o navegador pergunta seu endereço a um servidor STUN por UDP, e a maioria dos proxies transporta apenas tráfego web. Teste com o trecho de console: se o endereço srflx é o seu, a página também consegue vê-lo. Ative a proteção contra vazamentos na extensão da Shifter, ou defina disable_non_proxied_udp no Chrome e proxy_only_if_behind_proxy no Firefox, e teste de novo.