Teste de fuga WebRTC
A executar o teste de fuga...
IPv4 (HTTP) A verificar...
IPv6 (HTTP) A verificar...
Candidatos ICE recolhidos
Nenhum candidato ICE foi recolhido.
Localização aproximada
A localizar a sua rede…

O marcador mostra o centro aproximado da área servida pelo seu operador , não a sua casa, rua ou dispositivo. Um desvio de dezenas de quilómetros é normal.

Como travar uma fuga de WebRTC
Chrome / Edge — instale uma extensão que bloqueie WebRTC (por exemplo «WebRTC Leak Prevent») ou use um cliente VPN que bloqueie explicitamente o tráfego WebRTC — o Chrome moderno já não inclui um interruptor próprio para isto.
Firefox — abra about:config, procure media.peerconnection.enabled e defina como false para desativar totalmente o WebRTC.
Safari — O WebRTC não pode ser desativado globalmente; retire o acesso à câmara/microfone por site em Safari > Definições > Sites, ou confie numa VPN que bloqueie o WebRTC ao nível da rede.
Brave — abra o painel Shields e coloque o limitador de rede WebRTC no modo mais restrito («Proxied») para evitar fugas de IP local.
Sobre o teste de fuga WebRTC

O WebRTC é uma tecnologia do navegador criada para videochamadas em tempo real e transferência de ficheiros ponto a ponto. Para ligar dois computadores diretamente, precisa de descobrir todos os endereços de rede por onde cada lado pode ser contactado, por isso pergunta a um servidor STUN público «que IP tem esta ligação vista de fora?» e recolhe a resposta como um candidato ICE. Essa troca de candidatos acontece normalmente de forma invisível entre dois pares numa chamada — mas qualquer site também a pode desencadear em silêncio em segundo plano, ler os candidatos e extrair os seus endereços.

Isto torna-se um problema de privacidade sobretudo para quem usa VPN. Uma VPN reencaminha o seu tráfego HTTP normal pelo túnel, por isso os sites veem o IP da VPN em vez do seu. O WebRTC, porém, fala com o servidor STUN pela sua própria ligação e, em algumas configurações, essa ligação contorna completamente o túnel da VPN — revelando o seu IP real mesmo quando a barra de endereço sugere que está «protegido». Os navegadores modernos também tentam esconder o seu endereço de rede local substituindo-o por um nome mDNS aleatório e de uso único terminado em .local em vez de um IP como 192.168.1.5; essa substituição é uma melhoria genuína de privacidade, não um sinal de avaria.

Esta ferramenta executa exatamente o mesmo processo de recolha ICE que uma página maliciosa poderia executar, usando dois servidores STUN independentes por fiabilidade, e compara cada candidato público recolhido com o seu endereço IP HTTP real. Se coincidirem, o WebRTC não acrescenta qualquer exposição além do que todos os sites já veem. Se diferirem enquanto acredita estar numa VPN, essa discrepância é a fuga — e as soluções acima explicam como a fechar no seu navegador específico.

Este teste só revela o que o seu próprio navegador expõe através da recolha ICE do WebRTC; não deteta fugas que ocorram ao nível do sistema operativo ou do router.

Teste de vazamento WebRTC: sua VPN está revelando seu IP real?

Este teste de vazamento WebRTC executa exatamente a mesma rotina de conexão ponto a ponto que um script de rastreamento utilizaria e verifica se algum dos endereços coletados corresponde ao IP que sua VPN deveria ocultar. Ele inicia uma conexão RTCPeerConnection com um canal de dados vazio — sem ligar câmera, sem microfone e sem pedir autorizações —, consulta dois servidores STUN públicos para descobrir como sua conexão é enxergada externamente e compara o resultado com o IP das suas requisições HTTPS normais.

Como interpretar os candidatos ICE apresentados

O WebRTC precisa mapear todos os caminhos de rede pelos quais outro dispositivo poderia se comunicar com você, gerando uma lista de candidatos ICE. Esta página exibe essa relação bruta acompanhada do tipo e protocolo de transporte, finalizando a coleta após cinco segundos.

Acima aparecem seus endereços IPv4 e IPv6 usuais detectados via HTTP — os mesmos valores fornecidos pela ferramenta qual é o meu endereço IP. Eles servem de referência básica; o veredito decorre do confronto direto entre essas informações.

host, srflx e relay: o significado de cada etiqueta

  • Local (host): endereço da sua própria placa de rede: um IP local como 192.168.1.14 ou um identificador aleatório .local.
  • Público (via STUN): o candidato srflx, que representa o endereço público registrado pelo servidor STUN. É o dado vital ao navegar conectado a uma VPN.
  • Relay (TURN): pacote transmitido por um servidor intermediário; este teste emprega apenas STUN, portanto uma linha relay é incomum.

O que indica cada veredito

  • Vazamento detectado: um candidato público STUN difere do seu IP HTTP; sob VPN, indica que o pacote contornou o túnel seguro.
  • Sem vazamento: ambos os endereços coincidem perfeitamente.
  • IP local exposto: foi apresentado um IP de rede interna em vez de um nome ofuscado por mDNS.
  • Protegido: seu endereço de rede local foi resguardado sob um host .local aleatório.
  • Sem IP público / WebRTC bloqueado: o STUN ficou inacessível ou o WebRTC está desativado no navegador.

Por que o WebRTC pode expor um IP que sua VPN esconde

O WebRTC foi desenvolvido para viabilizar chamadas de voz, conferências de vídeo e troca de arquivos diretamente entre navegadores. Para conectar dois computadores protegidos por roteadores independentes é indispensável superar o NAT, o que exige responder a uma pergunta externa: de qual endereço esta conexão se origina? Um servidor STUN responde a isso, e qualquer site pode iniciar esse processo em segundo plano por JavaScript.

O problema surge quando você pretende ocultar seu endereço verdadeiro. Uma VPN conduz o tráfego HTTP convencional pelo túnel seguro, mas o WebRTC dispara pacotes UDP próprios para servidores STUN que, em conexões com tunelamento dividido, seguem a rota comum do provedor. Extensões de VPN em navegadores são o exemplo clássico: elas atuam como proxy para requisições web, mas não intermedeiam o tráfego UDP do sistema — gerando discrepâncias em relação a uma verificação de VPN feita em HTTP.

Um nome de host .local aleatório não indica vazamento

Se um candidato do tipo host exibir um registro como 7b3f9c21-4d0a-48e7.local em vez de 192.168.1.14, o sistema está funcionando corretamente. Trata-se da ofuscação mDNS: o navegador gera um nome DNS multicast de uso temporário para a interface local e o transmite no lugar do IP da LAN. Chrome, Edge, Brave, Firefox e Safari realizam isso por padrão — o uBlock Origin removeu sua opção de WebRTC na v1.38 porque os próprios navegadores incorporaram essa camada nativa. Vale lembrar: isso protege apenas seu IP de rede local (não evita vazamento da VPN pública) e qualquer página autorizada a usar microfone ou câmera obterá o IP local autêntico.

Como corrigir vazamentos de WebRTC no Chrome e no Edge

Nenhum dos dois navegadores possui um botão comum de desligamento, e as seções chrome://flags ou edge://flags não desativam mais o WebRTC. Três soluções são eficientes na prática:

  • Utilize um aplicativo VPN completo instalado no sistema em vez de uma extensão de navegador. Se todos os pacotes UDP passarem pelo túnel seguro, o STUN registrará exclusivamente o endereço do servidor VPN.
  • Configure a política de manuseio de IP via extensão. Ferramentas como WebRTC Leak Prevent alteram chrome.privacy.network.webRTCIPHandlingPolicy para default_public_interface_only ou disable_non_proxied_udp, impedindo a revelação local.
  • Aplique políticas no sistema operacional. No Windows, defina a chave WebRtcIPHandling no Chrome ou WebRtcLocalhostIpHandling em SOFTWARE\Policies\Microsoft\Edge com AllowPublicInterfaceOnly ou DisableNonProxiedUdp. Requer reiniciar o navegador; confira em edge://policy.

Como desativar totalmente o WebRTC no Firefox

O Firefox é o único navegador desktop popular que possui um controle direto de desativação. Digite about:config na barra de endereços, confirme o aviso, localize media.peerconnection.enabled e dê um duplo clique para alterar para false. O WebRTC será suspenso para todos os sites sem necessidade de reinicialização, e nosso teste o apontará como bloqueado.

Trata-se de uma medida drástica: ferramentas como Google Meet, Microsoft Teams, Discord e Zoom não conseguirão conectar chamadas pelo navegador até que você reverta o ajuste. Para continuar realizando chamadas, mantenha o item como true e marque media.peerconnection.ice.default_address_only como true — assim o Firefox usará unicamente a rota padrão (o túnel da VPN).

Como configurar o Brave contra vazamentos WebRTC

O Brave disponibiliza abertamente as configurações que o Chrome esconde. Acesse brave://settings/privacy e procure por WebRTC IP handling policy. Duas opções se destacam com VPN ou proxy:

  • Default: pode varrer todas as interfaces e expor endereços locais.
  • Default Public and Private Interfaces: utiliza a rota padrão, mas continua exibindo o IP privado.
  • Default Public Interface Only: apenas rota padrão sem endereços locais; as chamadas continuam ativas. É a melhor configuração para o dia a dia.
  • Disable Non-Proxied UDP: força tráfego TCP pelo proxy caso ele não tenha suporte a UDP. É a opção mais rigorosa (usada pelo Brave em janelas Tor), embora possa impedir chamadas P2P.

Particularidades no Safari, iPhone e Android

Em plataformas móveis e no mecanismo WebKit, as recomendações convencionais para computadores não se sustentam.

Safari no macOS

Versões recentes do Safari não contam com um interruptor global duradouro. Opções no menu Desenvolvedor redefinem-se ao fechar o navegador. Como o Safari protege os IPs locais atrás de mDNS até que se conceda acesso à câmera ou ao microfone, a estratégia recomendada é gerenciar permissões em Safari > Ajustes > Sites e utilizar uma VPN para todo o sistema operacional.

iPhone e iPad

Todo navegador no iOS opera obrigatoriamente sobre o WebKit. Chrome ou Firefox no iPhone não dispõem de about:config, sinalizadores ou extensões; bloqueadores de conteúdo não interceptam WebRTC. Para coibir vazamentos no iOS, instale um perfil de VPN em Ajustes > VPN que encapsule o tráfego UDP e repita este teste no Safari.

Android

O Chrome para Android não possui flags de WebRTC nem aceita extensões. O Brave para Android conta com a mesma lista de políticas de IP em suas opções de privacidade. No Firefox para Android, about:config só funciona nas edições Beta e Nightly. De modo abrangente, ative nas configurações do Android a VPN sempre ativa combinada com Bloquear conexões sem VPN.

Limitações desta ferramenta de diagnóstico

Esta página analisa apenas aquilo que seu navegador entrega aos scripts executados neste domínio. Ela não tem como rastrear vazamentos na camada do sistema operacional — tais como roteamentos defeituosos do sistema ou rotas IPv6 não contempladas pela sua VPN —, tampouco examina vazamentos de DNS. Se um firewall bloquear o STUN, a indicação será „Sem IP público“, o que simplesmente significa ausência de resposta. Além disso, o IP é apenas um entre inúmeros atributos: dimensões de tela, fontes tipográficas e cabeçalhos detalhados em Qual é o meu navegador continuam aptos a individualizar seu aparelho mesmo com uma VPN em operação.

Perguntas frequentes (FAQ)

O WebRTC pode vazar meu IP real mesmo conectado a uma VPN?

Sim, isso acontece frequentemente. O WebRTC envia seus próprios pacotes UDP diretamente aos servidores STUN. Em cenários de túnel dividido ou com extensões de navegador simples, esses pacotes viajam fora do túnel pela sua conexão comum. O servidor STUN identifica seu IP real de provedor, permitindo que sites o leiam por JavaScript. Um aplicativo VPN completo de sistema fecha essa brecha.

Existe algum modo de desligar o WebRTC por completo no Edge?

Não pelos menus convencionais: o Edge não oferece um botão direto e a antiga opção em about:flags foi eliminada. No Windows, você pode definir a política WebRtcLocalhostIpHandling como AllowPublicInterfaceOnly ou DisableNonProxiedUdp no Registro sob SOFTWARE\Policies\Microsoft\Edge. Isso requer reiniciar o navegador; valide em edge://policy.

Onde posso desativar o WebRTC e o PeerConnection no Firefox?

Em about:config: procure por media.peerconnection.enabled e dê duplo clique para definir como false. O WebRTC será desativado em todas as páginas imediatamente, mas chamadas de vídeo deixarão de funcionar. Para mantê-las ativas, conserve essa opção como true e mude media.peerconnection.ice.default_address_only para true.

Como desativar o WebRTC permanentemente no Safari?

Nas versões atuais do Safari isso não é viável de modo permanente. A opção experimental de anos atrás foi descontinuada e os ajustes do menu Desenvolvedor duram apenas a sessão atual. Como o Safari oculta IPs locais atrás de mDNS, a conduta mais eficiente é restringir permissões em Safari > Ajustes > Sites e empregar uma VPN em todo o sistema operacional.

Quais as melhores configurações no Brave contra vazamentos WebRTC?

Acesse brave://settings/privacy e selecione „Disable Non-Proxied UDP“ na diretiva de manuseio de IP do WebRTC ao utilizar VPN ou proxy. Assim o WebRTC usará TCP pelo proxy e o STUN nunca verá seu IP legítimo. A opção „Default Public Interface Only“ é a alternativa prática indicada para não inviabilizar chamadas de voz.

Qual política de IP do WebRTC devo selecionar?

„Default Public Interface Only“ atende perfeitamente à maioria dos usuários: esconde adaptadores locais, preserva a operação de pacotes UDP e mantém as chamadas ativas sem falhas. Escolha „Disable Non-Proxied UDP“ apenas caso deseje proteção máxima sob proxy ou VPN. As opções padrão permanecem revelando dados das interfaces locais.

Por que meu endereço IP privado é exposto pelo WebRTC?

Nos navegadores modernos isso não ocorre mais abertamente. Chrome, Edge, Brave, Firefox e Safari substituem a identificação direta da rede LAN por um nome mDNS provisório com terminação .local. As páginas web captam apenas esse nome em vez de valores como 192.168.1.14. Caso veja um IP privado explícito, esse escudo está inoperante e deve ser revisto.