WebRTC leaks: como seu navegador entrega seu IP real

Você conecta na sua VPN. A status bar diz que você está protegido. Carrega um site. O site silenciosamente pede pro seu navegador o endereço IP real — não o da VPN, o que seu provedor de fato atribuiu. O navegador entrega. Você não vê prompt, não vê aviso, e a VPN está fazendo exatamente o que prometeu.

Isso é WebRTC leak. O culpado é o navegador, não a VPN. E funciona em todo navegador moderno até você desabilitar.

O que é WebRTC

WebRTC (Web Real-Time Communication) é um browser API que provê voz e vídeo no navegador. Google Meet, canais de voz do Discord, huddles do Slack, Whereby, a parte in-browser do Zoom — todos usam WebRTC. Também usam transferências de arquivo diretas, screen sharing e botões de "clique pra ligar" em páginas de suporte.

Pra conexões peer-to-peer funcionarem, o navegador precisa saber seu IP público. É assim que o outro lado te alcança. WebRTC resolve isso via STUN server: o navegador pergunta pra um STUN server público "de qual endereço eu vim?". O STUN server responde com o IP que vê. O navegador cacha e entrega pra qualquer página que pergunte via WebRTC API.

A arquitetura fazia sentido em 2011, quando WebRTC foi projetado. Peer-to-peer latency-sensitive era o caso de uso. Privacidade contra sites arbitrários não estava no documento de design.

Por que VPN não conserta isso

VPN tunela seu tráfego de rede. A troca STUN do WebRTC opera em cima disso, mas a resposta que o navegador cacha é seu IP real, não o do túnel, em dois casos:

Caso 1: STUN foi consultado antes da VPN conectar. O navegador aprendeu seu IP real no startup ou numa rede anterior. Cachou. A página pede endereços IP do WebRTC e pega o valor real cachado.

Caso 2: VPN não tunela UDP pro STUN server. Em algumas configurações VPN existem edge-cases de roteamento. O pacote STUN escapa do túnel.

Mesmo com VPN devidamente tunelada, o cache STUN a nível de navegador é superfície de ataque. Páginas não precisam consultar STUN elas mesmas; só pedem ao WebRTC os endereços IP que o navegador já sabe.

Exposed vs leaking

Terminologia importa porque a reação é diferente.

Exposed. Você não está em VPN, visita uma página, a página vê seu IP real. É comportamento esperado. Não é leak, é a internet funcionando como projetada.

Leak (vazamento). Você ESTÁ em VPN, a página deveria ver só o IP da VPN, mas o WebRTC ainda entrega seu IP real. Isso é leak. A privacidade que você achou que tinha está quebrada.

O teste de WebRTC leak do Fexyn mostra em qual caso você está. Com VPN conectada, o IP público que aparecer deve ser o IP do servidor Fexyn. Se for seu IP de casa — você está vazando.

O que o atacante vê do leak

Mesma coisa que sem VPN:

Seu IP público real
Geolocalização aproximada (geralmente cidade, às vezes bairro pra provedores residenciais)
Seu provedor
Um identificador persistente que pode ser correlacionado entre visitas e entre sites

Pior que sem VPN: o leak dá a eles tanto seu IP real quanto o IP da VPN. Podem correlacionar entre sessões, construir perfil que te segue independente da VPN estar de pé ou não, e usar o próprio IP da VPN como fingerprint.

Pra modelos de ameaça onde geolocalização importa — jornalistas, ativistas, qualquer um se escondendo de stalker, qualquer um usando VPN pra evitar tracking específico de jurisdição — um WebRTC leak silenciosamente anula a proteção.

Fixes por navegador

A cura vive no navegador, não na VPN. Cada navegador trata WebRTC diferente.

Firefox — desabilitar completo

Opção mais limpa. Firefox permite desabilitar WebRTC inteiramente:

Abra uma nova aba e vá pra about:config. Aceite o aviso.
Procure media.peerconnection.enabled.
Coloque em false.
Reinicie Firefox.

Custo: chamadas de vídeo em qualquer aplicação baseada em navegador param de funcionar. Slack huddles, Google Meet, Discord voice no navegador — mortos até você ligar de volta. Pra maioria dos usuários focados em privacidade, isso é aceitável; chamadas são feitas no app desktop.

Brave — toggle embutido

Brave vem com setting orientado a privacidade:

Abra brave://settings.
Procure "WebRTC".
Coloque "WebRTC IP Handling Policy" em Disable non-proxied UDP.

Esse é o setting mais forte que não quebra WebRTC inteiramente. Chamadas funcionam; tráfego STUN é restringido pelo caminho de proxy. Pra usuários Brave em VPN — o setting certo.

Chrome e Edge — precisa extension

Nem Chrome nem Edge têm WebRTC toggle embutido na UI de settings. Precisa extension. Instale uma de:

uBlock Origin com filtro "Prevent WebRTC from leaking local IP addresses" habilitado. uBlock Origin é o ad-blocker certo de qualquer jeito; isso é bonus grátis.
WebRTC Network Limiter (publicado pela própria Google). Single-purpose, restringe WebRTC ao caminho de proxy.

Evite extensions aleatórias de "WebRTC fix" com uma estrela na Chrome Web Store. A categoria atrai extensions de baixa qualidade e às vezes maliciosas. Fique com uBlock Origin ou o do Google.

Safari

Safari implementa WebRTC mas não expõe toggle. Se está no Safari e WebRTC leaks te preocupam — migre pra Brave (Webkit-based, tem toggle) ou Firefox (Gecko-based, desabilitar completo).

Como o Fexyn lida com isso

O Fexyn não tenta monkey-patch seu navegador. Comportamento WebRTC do navegador é nível de navegador, e fora do que VPN pode ou deve sobrescrever.

O que o Fexyn faz:

Tunela todo tráfego UDP, incluindo STUN, quando o protocolo permite. WireGuard tunela tudo por padrão. Configurações VLESS Reality e OpenVPN tunelam UDP pelo mesmo caminho.
Recomenda settings específicos de navegador na página de suporte.
Provê uma ferramenta de checagem, pra você verificar combinação específica de navegador/setting.

A combinação — STUN tunelado por VPN mais WebRTC desabilitado ou restringido no lado do navegador — fecha o leak.

Re-teste depois do fix

Depois de mudar settings de navegador, reinicie o navegador e rode o teste de novo em fexyn.com/tools/webrtc-leak-test. O IP público que aparecer deve bater com o servidor Fexyn. O IP local deve estar vazio ou mostrar só o endereço do adaptador do túnel VPN.

Se ainda vê seu IP público real, a mudança não foi aplicada. Cheque que:

O navegador foi de fato reiniciado (fechar abas não basta; saia do app)
Pra Brave o setting é "Disable non-proxied UDP", não "Disable non-proxied UDP and force proxy"
Pra Chrome/Edge a extension está habilitada, não só instalada

O que WebRTC leak não é

WebRTC leaks são especificamente sobre exposição de IP via browser API. Não:

Afetam aplicações não-navegador. Um app desktop nativo em VPN não tem esse problema.
Afetam apps mobile que têm seu próprio networking. Apps iOS/Android que não embedam webview geralmente não expõem o IP da VPN via WebRTC.
Indicam que o próprio túnel VPN está quebrado. O túnel está bem; o navegador está voluntariamente entregando informação acima do nível do túnel.

Leitura relacionada

Experimente o Fexyn grátis por 7 dias. O túnel faz a parte dele; fixes de navegador são setting de uma vez.