Vazamento WebRTC: o que é, como testar e o que fazer quando aparece

WebRTC nasceu pra chamada de vídeo e áudio no browser, sem plugin. O efeito colateral pra quem opera várias contas de anúncio é simples: a página pode pedir caminhos de rede, e o browser entrega endereços que o proxy HTTP nunca viu. Você abre o Ads Manager, o HTTP sai por um residencial de São Paulo, e o WebRTC ainda aponta pra fibra do escritório em Belo Horizonte. Pra plataforma, isso não é detalhe. É dois lugares ao mesmo tempo.

Este texto não ensina a explorar nada. Ensina o time a ler o que um checker mostra, a não misturar furo de DNS com furo de WebRTC, e a ter um ritual antes de colar cookie ou logar BM. Se você ainda trata impressão digital como um número mágico, comece por lá. WebRTC é o sinal que mais denuncia “estou atrás de um proxy” quando o resto parece normal.

O que o WebRTC faz no dia a dia

Na prática, WebRTC é um conjunto de APIs do browser pra dois pontos trocarem mídia com baixa latência. Meet, Discord no Chrome, call de cliente, preview de câmera: tudo isso usa o mesmo motor. O browser precisa descobrir como chegar até a outra ponta. Essa descoberta não passa, por padrão, pelo mesmo cano do fetch que você configurou no proxy.

O time costuma achar que “se o IP do ipinfo está certo, a rede está certa”. Isso vale pro HTTP/HTTPS da página. Não vale automaticamente pro canal que o WebRTC monta. Uma analogia honesta: o proxy é o correio registrado da agência. O WebRTC, se ninguém mandar o contrário, ainda pode gritar o endereço da casa pelo interfone. Os dois no mesmo perfil é o cenário clássico de agência brasileira com residencial no antidetect e Wi-Fi do escritório no fundo.

Você não precisa decorar RFC. Precisa de uma frase operacional: o site pode ver um IP no cabeçalho da conexão web e outro nos candidatos de rede. Quando esses dois brigam, a conta não está protegida. Está anunciando o truque.

STUN, IP da placa e IP público

Pra achar um caminho, o browser pergunta a um servidor STUN: “como o mundo me vê?”. O STUN responde com o endereço público que observou. Ao mesmo tempo, o browser lista as interfaces locais — Ethernet, Wi-Fi, às vezes um VPN virtual, às vezes IPv6 da operadora. Esse pacote vira o que os checkers chamam de candidatos ICE: a lista de IPs que o perfil está disposto a confessar.

Três famílias importam na leitura. O candidato host é o IP local (192.168.x ou 10.x). Sozinho, não prova falha de proxy: quase todo notebook de escritório tem LAN. O candidato srflx (via STUN) é o IP público que o STUN enxergou. Se esse público é a Vivo Fibra da agência e o HTTP é um residencial de outro estado, você tem vazamento. O candidato relay (via TURN) aparece menos em anúncio; precisa ser o intermediário que você escolheu.

192.168.0.14 no checker não é crime. Quase todo Chrome de casa mostra isso. O crime operacional é o IP público do STUN ser o da operadora enquanto o HTTP está no proxy. Esconder só o host não resolve: anúncio e rede social ligam mais pro público real do que pro endereço da impressora no corredor. Na mesa, coluna A é o “seu IP” via HTTP; coluna B são os públicos do WebRTC. Se A é São Paulo residencial e B é o ASN da Claro da sala, o perfil não está pronto. Se A e B coincidem no mesmo proxy sticky, aí sim você passa pra fuso, idioma e qualidade de IP.

Por que anúncio e rede social ligam pra isso

Google Ads, Meta e redes sociais não odeiam WebRTC. Elas tentam responder se este login parece um dispositivo só, num lugar só, ou um conjunto de máscaras. IP é um dos sinais mais baratos dessa pergunta. Se o HTTP diz “residencial em Pinheiros” e o WebRTC diz “fibra empresarial em Savassi”, o grafo fica feio mesmo com cookie limpo.

Isso pesa mais em conta nova, em BM que já tomou restrição, e em várias identidades no mesmo escritório. Cinco gestores na mesma rede, cinco proxies diferentes no HTTP, e o mesmo IP real no STUN: pra plataforma, as contas nasceram no mesmo predinho. No Google Ads, MCC e contas de cliente no Chrome da agência já é risco; somar vazamento de WebRTC é pedir pro sistema achar que tudo é o mesmo operador.

Instagram e Facebook olham dispositivo, IP, comportamento e grafo de pessoas. WebRTC vazando não causa shadowban sozinho. Ajuda a amarrar contas que o time jura que estão isoladas. Nenhuma plataforma publica um PDF dizendo “banimos por candidato ICE”. Você precisa da disciplina: um perfil, um caminho de saída, um lugar plausível. O resto da impressão digital só faz sentido depois disso.

O proxy que passa no HTTP e falha no WebRTC

O caso mais comum na agência não é “esqueci o proxy”. É o contrário: o proxy está ligado, o ipinfo no HTTP mostra o país certo, o gestor sorri, e o WebRTC ainda lista o IP da operadora. Muita stack trata o proxy como HTTP(S) e WebSocket. STUN e o caminho de mídia não entram nesse contrato a menos que o browser (ou o perfil) force.

Proxy HTTP e SOCKS5 não são a mesma coisa pra esse furo. HTTP CONNECT cobre o que a página pede via TLS. WebRTC pode simplesmente não perguntar ao proxy. Extensão de proxy no Chrome vanilla “funciona” em qualquer site, e o checker continua mostrando a fibra de casa. No antidetect, o mesmo filme se o perfil só encaminha HTTP. Tem ainda o fornecedor que vende residencial sticky: o HTTP sai por um ASN residencial, mas o STUN continua saindo pela placa local.

Antes de culpar o vendor, feche o básico. O proxy está no perfil certo, não no Chrome do host? A senha não expirou no meio do teste? O time não ligou VPN de consumidor por cima? VPN por cima de proxy cria um terceiro IP que ninguém documentou. Teste o perfil só com o proxy da operação. Um cano de cada vez.

Como testar sem virar engenheiro

O teste que o time precisa é conceitualmente o de um checker tipo BrowserLeaks: uma página que mostra o IP da conexão web e, à parte, os candidatos que o WebRTC reuniu. Você não precisa do site da moda nem colar script. Precisa de um procedimento repetível no perfil vazio, antes do login da conta quente. Score, canvas e teatro ficam pra como ler testes de fingerprint.

Abra o perfil com o proxy já aplicado. Confirme que você não está logado em Google, Meta nem no e-mail da BM. Acesse o checker. Anote o IP HTTP. Anote todos os IPs públicos do bloco WebRTC, IPv4 e IPv6. Anote o país que o checker chuta pra cada um — o chute de geo é falho, mas serve de bandeira quando um é Brasil-SP e o outro é o bloco da operadora do bairro.

A regra é dura. Se existe IP público no WebRTC que não é o do proxy (nem um IPv6 do mesmo provedor), o perfil vazou. Se só aparece host de LAN e o público WebRTC coincide com o HTTP do proxy, passou nesse recorte. Se o checker não mostra candidato nenhum, não celebre: pode ser bloqueio, checker falhando ou WebRTC desligado. Confirme com um reload. Faça o teste duas vezes. Se a primeira leitura limpa e a segunda suja, vale a suja. Vazamento intermitente existe: proxy que cai, IPv6 que aparece tarde.

Checklist mínimo pro print:

• IP HTTP do proxy (IPv4) e IPv6 HTTP, se houver
• IPs públicos WebRTC (v4 e v6); hosts locais só como contexto
• País e fuso que o time espera pra aquele cliente
• Data, nome do perfil, nome do proxy, quem testou

IPv6: o endereço que ninguém configurou no proxy

No Brasil, fibra de casa e de escritório frequentemente chega com IPv6 nativo. Vivo, Claro, TIM e boa parte dos regionais entregam os dois mundos. O proxy que a agência comprou, muitas vezes, só fala IPv4. O HTTP mostra um IPv4 residencial lindo, e o WebRTC lista um IPv6 da operadora do escritório. Quem olha só a linha de IPv4 assina o perfil. Quem olha o bloco inteiro vê o furo.

IPv6 não é o mesmo IP em outro formato. É outro endereço, outro caminho, muitas vezes sem NAT na frente. Pra correlação, às vezes é pior que o IPv4 real, porque o prefixo da rede tem mais cara de assinante. Tratar IPv6 como detalhe de nerd é o erro que sobrevive em checklist de 2019.

Na prática: o checker precisa mostrar IPv6; se a página só imprime v4, você testou metade. O proxy precisa ser explícito — cobre IPv6 ou o perfil impede o browser de anunciá-lo? O host conta: desligar IPv6 só no Windows e testar no Mac da mesma mesa não é o mesmo ambiente. Se o HTTP já mostra um IPv6 do proxy, documente e siga. Se o HTTP é só v4 e o WebRTC entrega v6 da operadora local, não avance. Não desligue IPv6 no adapter e logue a BM pra ver se cola. Ajuste, teste de novo, aí sim login.

DNS leak e WebRTC não são o mesmo furo

DNS leak responde: pra quem o browser pergunta o IP de ads.google.com? Se a query sai pro DNS da operadora do escritório, do Google público da máquina host ou do firewall corporativo, a rede real participa mesmo com HTTP no proxy. WebRTC responde outra pergunta: quais endereços este browser oferece pra montar um caminho de mídia? São furos vizinhos. Não são o mesmo buraco.

Dá pra estar certo num e errado no outro. Proxy com DNS remoto bem forçado e WebRTC vazando o IP real. Ou WebRTC alinhado ao proxy e DNS ainda batendo no 8.8.8.8 da máquina. O time que testa só um dos dois constrói falsa segurança. Ordem curta: IP HTTP, WebRTC, DNS, depois fuso e idioma. Fuso e idioma não vazam IP; denunciam história mal contada quando o IP é de Lisboa e o Windows está em America/Sao_Paulo.

Na leitura, não misture os blocos. DNS lista resolvedores. WebRTC lista candidatos. Um resolvedor da Cloudflare não prova WebRTC limpo. WebRTC limpo não prova que o escritório não está resolvendo nome. Quando o DNS vaza e o WebRTC não, o conserto é no túnel de DNS, não em bloquear STUN. Quando o WebRTC vaza e o DNS não, o conserto é no tratamento de WebRTC do perfil — não em trocar o resolvedor.

Ritual: testar, printar, congelar o perfil

O teste não vale se depois o estagiário instala uma extensão “pra bloquear WebRTC”, o gestor liga a VPN do notebook, e alguém muda o proxy no dia seguinte sem repetir o checker. Perfil de anúncio precisa de aceite, como aceite de criativo: uma foto do estado, uma data, e a regra de não mexer sem novo teste.

Crie o perfil. Aplique o proxy sticky do cliente. Não cole sessão ainda. Rode o checker. Se HTTP, WebRTC e DNS alinharem com o país combinado, tire um print da tela inteira — não um recorte do IP HTTP. Salve no diretório do cliente, com nome de perfil e data. Só então congele: sem extensão nova, sem trocar de máquina host, sem “só um toggle”. Aí cole a sessão ou faça o login.

Congelar não é superstição. Canvas, fonte e GPU já são barulhentos demais pra somar um terceiro IP no meio da semana. O print existe pro próximo gestor não discutir memória. Se a agência opera dezenas de contas, isso entra no pacote de organizar dezenas de contas: nome de perfil, proxy, print, responsável. Repita o ritual quando mudar rede — fornecedor, país, máquina, VPN no host. Não repita porque o criativo foi recusado. Recusa de política não é vazamento de STUN. Misturar as filas é como trocar o navegador porque a BM caiu sem olhar pagamento.

O que fazer quando vaza

Primeiro: não logue a conta quente. Não “só pra ver o Ads Manager”. Relogar no IP real, ou num mix HTTP-proxy + STUN-real, ensina o grafo exatamente o que você não queria ensinar. Feche o perfil. Trate como ambiente contaminado pra aquela identidade.

Segundo: separe causa. O proxy caiu? Religue e teste de novo no perfil ainda vazio. O WebRTC lista o IP da operadora com o proxy de pé? Aí não é reputação de ASN — é caminho. Trocar o residencial por outro residencial do mesmo vendor, no mesmo modo, costuma repetir o furo. Mude o tratamento de WebRTC no perfil ou o tipo de túnel. Se o HTTP já estava num IP ruim, leia sticky e reputação no texto de qualidade de IP. São consertos diferentes.

Terceiro: IPv6 e VPN de consumidor. Desligue a VPN do notebook host e teste o perfil isolado. Se o v6 da operadora persiste, o perfil precisa deixar de anunciar IPv6 ou o proxy precisa carregar IPv6 de verdade. Só então perfil consertado (ou novo), print novo, freeze, login. Se a conta já tinha sido aberta no vazamento, assuma correlação. Isolar daqui pra frente reduz dano futuro; não apaga o que a plataforma já viu.

O que não adianta: extensão de “WebRTC Leak Prevent” no mesmo processo; VPN de consumidor por cima do proxy; desligar WebRTC no perfil que precisa de Meet; randomizar candidato a cada refresh; relogar a BM pra validar. Isole perfil de call e perfil de anúncio. Teste no vazio. Print. Congele. Essa ordem é o trabalho. O resto é teatro.