Vazamento de IP WebRTC: por que trocar o proxy ainda te "entrega"?

O velho Zhou, que vende na Amazon, gastou quase mil reais em um proxy residencial, e tudo parecia normal no cliente. Até que um dia ele deu uma olhada em um site de detecção de IP e encontrou dois IPs na página ao mesmo tempo: um nos EUA, um na China. O dos EUA era o proxy que ele comprou; o da China era a banda larga da própria casa dele.

Na época ele não deu importância. Só quando a terceira loja foi congelada por "associação" é que ele se lembrou daquela página estranha.

Isso não é um caso isolado. Quando ajudo clientes a resolver problemas de conta, descobri que na maioria dos casos de "troquei o proxy e mesmo assim fui banido", o problema não é a qualidade do proxy, mas um backdoor do próprio navegador — o WebRTC. Este artigo explica tudo: como ele contorna o proxy, o que acontece quando vaza, como se verificar e como fechar a brecha.

WebRTC é uma "escada de incêndio" no navegador que o proxy não controla

Imagine o proxy como o porteiro do condomínio e o WebRTC como a escada de incêndio — o porteiro controla o portão principal, mas não controla a porta escondida na escada de incêndio que leva direto à sua casa.

No nível técnico, os dois caminhos fazem trabalhos completamente diferentes:

• O proxy assume a "estrada principal" das requisições web, ou seja, o tráfego HTTP/HTTPS. Você acha que "todo o tráfego passa pelo proxy", mas na verdade só a parte de navegação web passa.
• O WebRTC usa o mecanismo interno de comunicação em tempo real do navegador, usando os protocolos STUN/ICE (baseados em UDP) para perguntar diretamente a um servidor externo "qual é o meu endereço público". Esse processo acontece dentro do kernel do navegador, que a ferramenta de proxy nem consegue ver, muito menos bloquear.

Essa é a verdade por trás do "dois IPs ao mesmo tempo" do velho Zhou: as requisições web passaram pelo proxy dos EUA, enquanto o WebRTC reportava silenciosamente o endereço da banda larga de casa.

Quais cenários têm mais chance de cair na armadilha? Recursos de comunicação em tempo real, como chamadas de vídeo, apps de voz e colaboração online, são os piores; plataformas de e-commerce e redes sociais parecem não acionar no uso diário, mas fazem sondagens silenciosas em momentos críticos como login e pagamento — impossível se proteger de tudo.

Como um único IP vazado derruba um lote inteiro de contas?

O caso do velho Zhou é a melhor ilustração:

• A associação fica comprovada. Quando a primeira loja fez login, a plataforma viu o IP doméstico dele pelo WebRTC; quando a segunda loja fez login, viu o mesmo IP doméstico de novo. Duas lojas "sem relação" estavam ligadas à mesma linha de internet — a palavra "associação" foi escrita no arquivo de risco assim.
• Depois vem o processamento em lote. Uma vez estabelecida a associação, quando uma conta dá problema, outras lojas, contas de anúncio e contas de pagamento do mesmo dono são todas implicadas — cai um, cai um monte.
• O pior é que não tem como limpar. O que vaza não é só o IP, mas também a localização geográfica real e as informações da operadora. Uma vez que esses dados entram no arquivo de risco, trocar de ambiente ou de proxy dificilmente apaga.

Muitos vendedores tratam "trocar o proxy" como uma solução mágica, ignorando exatamente isto: o proxy pode trocar a "identidade de rede", mas não pode trocar o "endereço real" que o navegador reporta por conta própria.

Autoverificação de 2 minutos: seu IP real está "exposto"?

Sem desmontar o navegador, sem instalar software — abra qualquer site de detecção de IP (ipleak.net, BrowserScan servem) e veja claramente em três passos:

1. Primeiro teste o "estado exposto". Abra a página de detecção na sua rede doméstica e anote o IP exibido — essa é a sua "carta real".
2. Depois teste com o proxy ligado. Ative o proxy e atualize a mesma página.
3. Compare a coluna WebRTC. Se o IP da sua rede doméstica aparecer nessa coluna, o backdoor está aberto; se mostrar o IP do proxy ou ficar em branco, a proteção está funcionando.

Aqui está um ponto cego em que a maioria cai: as páginas de detecção costumam mostrar várias colunas ao mesmo tempo (IP, DNS, WebRTC), e muita gente só olha a coluna "IP", a mais chamativa — ao ver que virou EUA, já fica tranquila — enquanto as colunas DNS e WebRTC, que escondem as minas terrestres, ninguém olha.

Qual é a forma certa de fechar esse backdoor?

Primeiro, por que três tentativas "óbvias" não funcionam:

• Instalar extensão de bloqueio: a maioria das extensões de bloqueio de WebRTC cobre só parte dos caminhos de acionamento e continua vazando em cenários novos.
• Comprar proxy ou VPN mais caro: o proxy age na camada de rede, não alcança o kernel do navegador — comprar um mais caro não resolve (isso foi tratado no artigo Navegador de impressão digital vs VPN).
• Desativar o WebRTC por completo: fecha mesmo, mas chamadas de vídeo e reuniões online quebram — é cortar o nariz para contrariar o rosto.

A solução de verdade é tratar na camada do kernel do navegador: o navegador de impressão digital modifica diretamente o comportamento das APIs relacionadas ao WebRTC, para que os scripts da página não consigam obter seu endereço real. Tomando o MasBrowser como exemplo: ao criar um ambiente, selecione "desabilitado" para WebRTC nas configurações de impressão digital, e o navegador não vai mais sondar as interfaces de rede locais pelo WebRTC. A configuração completa de ambiente independente e isolamento de impressão digital pode ser vista na página de gerenciamento de segurança multi-contas do MasBrowser.

Depois de configurar, volte à página de detecção e confira. Confirme que seu IP real não aparece mais na coluna WebRTC — só então esse backdoor está realmente fechado.

Perguntas frequentes

Vazamento WebRTC e vazamento DNS são a mesma coisa?

Não. O vazamento de DNS acontece quando o proxy trata as consultas DNS de forma incompleta e as requisições passam pela operadora local; o vazamento de WebRTC acontece quando o recurso nativo do navegador contorna o proxy e reporta o IP diretamente. Os dois expõem o ambiente de rede real, mas os caminhos são diferentes, e as páginas de detecção mostram separadamente.

Com um proxy residencial, o WebRTC ainda vaza?

Sim. O vazamento não tem relação com o tipo de proxy — enquanto o recurso WebRTC do navegador não for tratado corretamente, seja proxy residencial ou de datacenter, ele consegue contornar o túnel e reportar o IP real. O ponto é fechar o WebRTC, não comprar um proxy mais caro.

Se eu definir WebRTC como "desabilitado", afeta o uso normal?

Basicamente não. A grande maioria dos aplicativos web (e-commerce, redes sociais, trabalho) não usa WebRTC; só chamadas de vídeo, reuniões online e transferências P2P são afetadas, e nesses cenários basta criar um ambiente separado sem desabilitar o WebRTC.

Se a página de detecção está toda verde, estou totalmente seguro?

Significa que essa camada de proteção está em dia. Mas a segurança multi-contas é um "combo": o WebRTC é só um elo da camada de rede — é preciso combinar com isolamento de impressão digital, vínculo de proxy e consistência de comportamento. Um ponto verde não significa segurança geral.

Conclusão

Se você trocou o proxy e ainda foi banido, na maioria das vezes não é culpa do proxy, mas da "escada de incêndio" do navegador que ficou aberta — ela contorna o proxy e reporta seu endereço real diretamente para a plataforma.

A boa notícia é que a solução não é complicada: trate o WebRTC na camada do kernel do navegador e rode uma verificação depois de configurar para confirmar. O plano gratuito já inclui 2 slots de ambiente — baixe o MasBrowser, crie um ambiente, defina WebRTC como "desabilitado" e teste se seu IP real ainda aparece. Esse passo vale para todas as contas.