MyIPScan

WebRTC · verificação no navegador

Teste de WebRTC: verifique se o seu navegador vaza o seu IP

Para abrir chamadas e videochamadas, o navegador publica os próprios endereços. Este teste mostra quais são públicos, quais são locais e quais ficam mascarados, e se algum escapa da sua VPN.

Ferramenta funcional

Teste de WebRTC funcional

Verifica candidatos WebRTC públicos, locais, mascarados ou indisponíveis no navegador atual.

Status Não verificado Sinais pendentes
Metodologia

Status inicial: não verificado. Rode o teste para ver candidatos WebRTC públicos, locais, mascarados ou indisponíveis.

Não verificado

Rode o teste para gerar um resumo de exposição. O relatório seguro não exporta o IP completo, a cidade exata, o user-agent completo, os candidatos WebRTC nem impressões digitais brutas.

O que verifica

A ferramenta funcional analisa os candidatos WebRTC que o navegador permite ver nesta sessão.

O que não prova

Não prova anonimato nem confirma que todos os riscos de WebRTC estejam ausentes. O resultado depende do navegador, das permissões, das extensões, da VPN e da rede.

Resposta rápida

O WebRTC está vazando o meu endereço IP?

Se este teste mostrar um candidato público que bate com a sua operadora e não com o seu servidor de VPN, o navegador está expondo o seu endereço real pelo WebRTC. Se aparecerem apenas endereços locais do tipo 192.168.x.x ou candidatos mascarados, esse é o comportamento normal dos navegadores modernos e não revela quem você é. É um sinal limitado: descreve esta sessão, não o computador inteiro.

O que é um vazamento de WebRTC e por que ele acontece

O WebRTC permite que um navegador abra uma chamada ou uma transferência direta com outro navegador, sem servidor intermediário. Para isso, as duas pontas precisam dizer uma à outra onde se encontrar: o navegador reúne os endereços pelos quais poderia receber tráfego — o da rede local, o que o roteador vê, o que a internet vê — e os publica como candidatos ICE.

Aí está o detalhe incômodo: essa lista é montada pelo próprio navegador e não segue o mesmo caminho de uma requisição web comum. Qualquer página pode pedi-la com algumas linhas de JavaScript e sem instalar complementos, tanto no Chrome quanto no Firefox, no Edge ou no Safari.

Há vazamento quando, entre esses candidatos, aparece o seu endereço público real enquanto você esperava que o tráfego saísse por outra rota, normalmente a de uma VPN. O termo é usado em excesso: um candidato local ou mascarado não vaza nada. O que importa é se aparece um endereço público alheio ao túnel. Abra antes a página qual é o meu endereço IP para ter um ponto de comparação.

Como ler o resultado do teste

A ferramenta separa os candidatos em quatro linhas — públicos, locais ou privados, mascarados e suporte — e os resume em um único status. Esse status aparece no cartão como um rótulo curto colorido, acompanhada de uma frase que explica o que foi observado. Os quatro rótulos possíveis são os que você vê abaixo. Não são veredictos: descrevem o que o navegador deixou ver nesta sessão.

  • Visível Apareceu pelo menos um candidato público, com um endereço IPv4 ou IPv6 alcançável pela internet. Compare com a rota que você esperava: se não for a do servidor da VPN, revise isso primeiro.
  • Requer revisão Foram observados apenas candidatos locais ou privados: o navegador mostrou endereços que só funcionam dentro da sua rede. Eles descrevem o formato da sua rede local, mas não permitem alcançar você pela internet.
  • Normal O navegador mascarou os candidatos literais: substituiu os endereços por identificadores mDNS, os que terminam em .local. É o comportamento habitual dos navegadores modernos, não um sinal de alarme.
  • Não verificado Não houve dados suficientes: o WebRTC não estava disponível, uma extensão ou uma política o bloqueou, ou o tempo de coleta de candidatos se esgotou. É também o status de partida, antes de o teste rodar. Repita o teste antes de tirar conclusões.

Quando aparece um endereço público, o decisivo é quem o anuncia. Uma consulta de ASN diz se ele pertence à sua operadora ou ao provedor de VPN.

Por que uma VPN nem sempre cobre o WebRTC

Uma VPN trabalha na camada de rede: cria um adaptador virtual e empurra o tráfego por ele. O WebRTC trabalha um andar acima, dentro do navegador, e a sua tarefa é listar os caminhos de conexão disponíveis. Se o sistema continua enxergando a placa de rede física, o navegador pode incluir o endereço dela entre os candidatos, mesmo que o resto do tráfego saia pelo túnel.

Por isso muitos aplicativos não bloqueiam esse caminho: não é uma falha do túnel, é que a pergunta é feita em outro lugar. Alguns provedores, como Mullvad ou IVPN, publicam extensões de navegador para fechá-lo. Isto não é um ranking nem uma recomendação: verifique o que a sua oferece e confirme o efeito com um teste.

Três situações se repetem: o túnel dividido, que deixa o navegador fora da rota protegida; a extensão de proxy usada sozinha, que cobre o HTTP mas deixa livre o UDP de que o WebRTC precisa; e o IPv6, quando o servidor só entrega IPv4 dentro do túnel.

Um vazamento de WebRTC quase nunca vem sozinho. Se esta página apontar algo, siga para o teste de vazamentos de VPN, que reúne IP, DNS, WebRTC e IPv6 em uma só passagem, e depois revise o teste de visibilidade IPv6 e o teste de vazamento de DNS. Se a mesma rota aparecer em vários sinais, revise a configuração do túnel antes de mexer em um navegador específico.

Como desativar ou limitar o WebRTC em cada navegador

Antes de mexer em qualquer coisa, tenha claro o custo: o WebRTC faz as chamadas funcionarem dentro do navegador, e desligá-lo as quebra. Os nomes das configurações mudam a cada versão, então trate esta lista como um caminho a conferir.

Chrome e Edge

Nenhum dos dois tem uma chave própria nas configurações visíveis. O caminho habitual é uma extensão de bloqueio: no uBlock Origin existe a opção “Prevent WebRTC from leaking local IP addresses”. Em computadores gerenciados por uma empresa, também é possível aplicar uma política própria. Reinicie o navegador depois da mudança.

Firefox

O Firefox permite desligá-lo. Digite about:config, aceite o aviso, procure media.peerconnection.enabled e mude para false. A mudança é global: as chamadas deixam de funcionar até você voltar para true.

Brave

O Brave reúne essa decisão nas configurações de privacidade, na política de tratamento de IP no WebRTC. A opção mais restrita desativa o UDP que não passa pelo proxy. Escolha essa opção se você não precisa descobrir dispositivos da sua rede.

Safari e navegadores móveis

O Safari oferece bem menos chaves e, na maioria das configurações, não expõe o endereço real. No celular, quem manda é o sistema: revise as permissões do navegador, a proteção contra vazamentos da VPN e o DNS privado. Repita o teste no Wi-Fi e nos dados móveis: o resultado muda em cada rede.

O que comparar e quando repetir o teste

Uma verificação isolada diz pouco. O valor está na diferença entre um antes e um depois, e ela só é legível se você mudar uma coisa de cada vez.

  1. Rode o teste sem VPN e anote quais candidatos aparecem. Esse é o seu ponto de partida.
  2. Conecte a VPN, repita o teste no mesmo navegador e perfil e compare a linha de candidatos públicos.
  3. Se aparecer um endereço inesperado, mude uma única configuração — proteção contra vazamentos, túnel dividido, extensão, política — e meça de novo.
  4. Guarde o relatório seguro de cada rodada para comparar sem anotar endereços à mão.

Repita a verificação ao atualizar o navegador, ao instalar ou remover uma extensão, quando a VPN trocar de servidor, ao passar do Wi-Fi para os dados móveis e ao usar outro perfil. Um resultado de meses atrás não diz nada sobre o de hoje.

Lembre o que fica de fora: mesmo que o navegador deixe de publicar candidatos públicos, ele continua emitindo outros sinais que uma VPN não esconde e que permitem reconhecê-lo entre sessões. Isso é verificado no teste de impressão digital do navegador.

Como este teste funciona e o que ele não cobre

A página cria uma RTCPeerConnection temporária, abre um canal de dados e pede ao navegador que reúna candidatos ICE com o servidor STUN público stun:stun.l.google.com:19302. Um servidor STUN responde a uma única pergunta: de qual endereço ele vê você. Essa resposta faz do WebRTC um sinal útil e, ao mesmo tempo, um caminho de exposição.

A classificação é feita no seu próprio navegador. Os endereços de faixa privada, de link local, de loopback e os da faixa compartilhada que algumas operadoras usam para o seu NAT não contam como exposição pública: eles não permitem alcançar você pela internet. Se o navegador não entregar candidatos em alguns segundos, o teste fecha a conexão e devolve um resultado inconclusivo.

O que ele não pode fazer: auditar os aplicativos fora do navegador, revisar cada rota do sistema ou do roteador, nem prever a sua próxima conexão. Um resultado limpo significa que nesta sessão não apareceu um candidato público, não que não exista nenhum vazamento.

Os critérios e os limites completos estão na metodologia do MyIPScan. A versão em inglês deste teste de WebRTC documenta as mesmas verificações.

Perguntas frequentes sobre WebRTC

O que é um vazamento de WebRTC?

WebRTC é a tecnologia que os navegadores usam para abrir chamadas e conexões diretas. Para negociar essa conexão, o navegador publica uma lista dos próprios endereços, os candidatos ICE. Há vazamento quando nessa lista aparece o seu endereço público real, mesmo que o resto do tráfego passe por uma VPN. O WebRTC funciona no Chrome, no Firefox, no Edge e no Safari sem instalar nada.

Como sei se o WebRTC está vazando o meu IP real?

Conecte a VPN, rode este teste e olhe a linha de candidatos públicos. Se ali aparecer um endereço diferente do servidor da VPN e que bate com o da sua operadora, há vazamento. Se a linha disser “Nenhum observado” ou mostrar apenas endereços locais, nesta sessão não houve exposição pública. Compare com o seu IP público para confirmar.

A minha VPN me protege dos vazamentos de WebRTC?

Não automaticamente. O WebRTC vive dentro do navegador e pode reunir endereços de interfaces de rede que o túnel não cobre, por isso muitos aplicativos de VPN não o bloqueiam sozinhos. Alguns, como Mullvad ou IVPN, publicam extensões de navegador pensadas para fechar esse caminho. Não é um ranking: consulte a documentação do seu aplicativo e confirme o efeito com um teste.

Como desativo o WebRTC no Chrome?

O Chrome não tem uma chave própria para desligar o WebRTC. O caminho habitual é uma extensão: no uBlock Origin, por exemplo, existe a opção “Prevent WebRTC from leaking local IP addresses” nas configurações. Em computadores gerenciados por uma empresa, também é possível aplicar uma política de WebRTC. Reinicie o navegador e rode o teste de novo para confirmar a mudança.

Como desativo o WebRTC no Firefox?

O Firefox permite desligá-lo pelas configurações avançadas. Digite about:config na barra de endereços, aceite o aviso, procure media.peerconnection.enabled e mude para false. A mudança afeta o navegador inteiro: as videochamadas e os aplicativos que usam conexões diretas deixam de funcionar até você voltar para true. Repita o teste depois de mudar.

É perigoso o teste mostrar um IP local como 192.168.1.5?

Não. Os endereços que começam com 192.168, com 10 ou de 172.16 a 172.31 são privados: só funcionam dentro da sua rede e não podem ser alcançados pela internet. Eles aparecerem só indica o formato da sua rede local, nada mais. O sinal que vale revisar é um endereço público que não coincide com a rota que você esperava.

Se eu desativar o WebRTC, as videochamadas param de funcionar?

Sim, na maioria dos casos. O WebRTC é o que torna possíveis as chamadas, as videochamadas e o compartilhamento de tela dentro do navegador, então desligá-lo por completo quebra esses serviços. Se você usa isso todo dia, costuma funcionar melhor uma opção intermediária: uma política que oculte os endereços locais ou um perfil de navegador separado para as chamadas.

Todos os navegadores vazam o IP pelo WebRTC?

Eles não se comportam da mesma forma. Chrome, Firefox e Edge expõem o WebRTC por padrão e podem mostrar um endereço público por fora da VPN. O Brave bloqueia por padrão as requisições WebRTC entre origens diferentes. O Safari tem suporte parcial e, na maioria das configurações, não expõe o endereço real. Teste o seu navegador de novo depois de cada atualização.