# Teste de vazamento WebRTC

Descubra se o seu navegador revela, pelo WebRTC, um endereço IP que a sua VPN ou proxy deveria esconder. O teste roda no seu navegador e costuma terminar em poucos segundos (espera no máximo oito).

## Resposta curta

Vazamento de WebRTC é quando qualquer página consegue ler pelo WebRTC um endereço IP público diferente do que a sua conexão usa — por exemplo, o seu endereço real com a VPN ligada — sem nenhum pedido de permissão. Este teste faz uma requisição STUN a stun.cloudflare.com:3478, espera até 8 segundos e compara cada endereço público que volta com o endereço que o servidor vê; a RFC 8828 descreve o que os navegadores devem e não devem revelar desse jeito.

### Como é obtido

A página cria uma `RTCPeerConnection` com um servidor STUN e um canal de dados, o que faz o navegador reunir candidatos ICE (RFC 8445). Os candidatos host trazem endereços locais, que os navegadores atuais em geral substituem por um nome `.local` aleatório; os candidatos server-reflexive (`srflx`) trazem o endereço público que o servidor STUN viu (RFC 8489). Cada endereço público é comparado com o endereço da sua requisição HTTP; dois endereços IPv6 contam como a mesma rede quando os primeiros 64 bits são iguais.

### Exemplo prático

Um usuário de VPN se conecta por 198.51.100.7, e a resposta STUN traz 203.0.113.25. Os dois são IPv4 e são diferentes, então o resultado é **Vazamento: o WebRTC revela outro IP público**: 203.0.113.25 provavelmente é o endereço que a VPN deveria esconder. Se a resposta tivesse sido 198.51.100.7, o resultado seria sem vazamento; se tivesse sido um endereço IPv6 em uma conexão que chegou por IPv4, a página informa que o WebRTC também revela o seu endereço IPv6, o que é esperado em uma conexão dual stack sem VPN. (Os dois endereços são de documentação, da RFC 5737.)

### Limites

- O teste vale só para este navegador e este perfil; outros navegadores no mesmo aparelho podem se comportar de outro jeito.
- Se o UDP para a porta do STUN estiver bloqueado ou a rede estiver lenta, o resultado aparece como inconclusivo, e não como seguro.
- Ele não testa vazamento de DNS nem o tráfego de outros aplicativos.

### Fontes

- [RFC 8828: WebRTC IP Address Handling Requirements](https://www.rfc-editor.org/rfc/rfc8828): quais endereços os navegadores podem expor.
- [RFC 8445: Interactive Connectivity Establishment (ICE)](https://www.rfc-editor.org/rfc/rfc8445): candidatos host, srflx e relay.
- [RFC 8489: Session Traversal Utilities for NAT (STUN)](https://www.rfc-editor.org/rfc/rfc8489): como um servidor STUN informa o endereço público.
- [Using mDNS to protect local addresses in ICE candidates](https://datatracker.ietf.org/doc/draft-ietf-mmusic-mdns-ice-candidates/): os nomes .local que os navegadores usam.
- [RFC 5737: IPv4 Address Blocks Reserved for Documentation](https://www.rfc-editor.org/rfc/rfc5737): os endereços de exemplo.

## O que é um vazamento de WebRTC

WebRTC é a tecnologia do navegador por trás de chamadas de vídeo, compartilhamento de tela e transferência de arquivos ponto a ponto em sites como Google Meet e Discord. Para ligar duas pessoas diretamente, o navegador precisa descobrir todos os endereços pelos quais pode ser alcançado. Ele faz isso mandando uma requisição minúscula a um **servidor STUN**, que responde com o endereço público de onde viu a requisição sair. Depois, o navegador entrega esses endereços — chamados candidatos ICE — ao JavaScript da página.

Isso é útil para chamadas e um problema para a privacidade. Qualquer página pode iniciar esse processo em silêncio, sem pedido de permissão e sem câmera nem microfone. Se a requisição STUN sair do seu computador por fora do túnel da VPN, a página descobre o endereço que o seu provedor de internet deu a você, e não o que a VPN mostra. Isso é um vazamento de WebRTC: o site vê dois endereços, e um deles é justamente o que você queria esconder.

## Como usar

1. Conecte a VPN ou o proxy do jeito que você costuma navegar e abra esta página.
2. Espere o quadro de resultado no topo. O teste começa sozinho, e a linha *Testando* dá lugar a um veredito de uma linha com uma explicação curta.
3. Em **Endereços comparados**, compare *Sua conexão (HTTP)* com *IP público via WebRTC*. A linha *Servidor STUN usado* mostra qual servidor respondeu ao seu navegador.
4. Confira a tabela de **candidatos ICE**. *Tipo* diz de onde veio cada candidato (`host` é o seu aparelho, `srflx` é o que o servidor STUN viu, `relay` é um servidor TURN), e *Categoria* diz se o endereço é público, da sua rede local, atrás do NAT da operadora ou escondido atrás de um nome `.local`.
5. Depois de mudar uma configuração ou uma extensão do navegador, clique em **Rodar o teste de novo**. Se você ligou ou desligou a própria VPN, recarregue a página: o endereço HTTP é lido uma vez só, quando a página carrega.

Rode o teste uma vez com a VPN desligada e anote o endereço que o seu provedor dá. Esse é o endereço que nunca deve aparecer com o túnel ligado.

## Para que serve

- **Avaliar uma VPN antes de confiar nela.** Com o túnel ligado, o endereço público do WebRTC deve ser igual ao do HTTP ou nem aparecer. Um endereço diferente da mesma família é o resultado que pede ação.
- **Verificar uma extensão de proxy.** As extensões de proxy do navegador encaminham as requisições normais das páginas, mas a requisição STUN usa UDP e pode sair direto pelo seu provedor, a não ser que o navegador seja instruído a bloqueá-la.
- **Achar uma brecha no IPv6.** Algumas configurações de VPN passam o IPv4 pelo túnel e deixam o IPv6 de fora. O veredito então diz que o WebRTC também revela o seu endereço IPv6.
- **Conferir a política de um navegador gerenciado.** A equipe de TI que restringe o WebRTC nos notebooks da empresa pode abrir a página em uma máquina de teste e confirmar que a tabela de candidatos só mostra o que a política deveria permitir.
- **Depurar um app WebRTC em uma rede restrita.** Se a tabela lista candidatos `host`, mas nenhum `srflx`, o UDP para o servidor STUN na porta 3478 provavelmente está bloqueado, e as chamadas nessa rede vão precisar de um relay TURN.

## Como este teste funciona

1. O seu navegador carrega esta página pela sua conexão normal, então o nosso servidor vê um endereço público — mostrado acima como *Sua conexão (HTTP)*.
2. A página cria uma conexão WebRTC que nunca liga para ninguém e pergunta ao servidor STUN público da Cloudflare (`stun.cloudflare.com`) qual endereço ele vê.
3. Listamos todos os candidatos que o seu navegador gerou e comparamos os públicos com o endereço HTTP. Tudo isso acontece no seu navegador; nada é enviado de volta para nós.

## Como ler o resultado

- **Sem vazamento:** o WebRTC informa o mesmo endereço público da sua conexão, ou nenhum. Se você usa VPN, ela está cobrindo o WebRTC.
- **Vazamento:** o WebRTC informa um endereço público diferente, do mesmo tipo (IPv4 com IPv4). Com a VPN ligada, esse segundo endereço quase sempre é o seu endereço real.
- **Outro protocolo exposto:** você se conectou por IPv6 e o WebRTC também mostra um endereço IPv4, ou o contrário. Em uma conexão residencial comum, os dois são seus. Com uma VPN que só passa um protocolo pelo túnel, o outro vaza.
- **Endereço local visível:** um endereço `192.168.x.x` ou `10.x.x.x` significa que o navegador está compartilhando o endereço do seu aparelho na rede de casa. As versões atuais do Chrome, Edge, Firefox e Safari o escondem por padrão atrás de um nome `.local` aleatório.

## Como resolver um vazamento de WebRTC

- **Use o aplicativo da VPN, não só a extensão do navegador.** Uma VPN no sistema todo passa o tráfego STUN pelo túnel; uma extensão de proxy muitas vezes não.
- **Ative a proteção contra vazamento de WebRTC** no aplicativo ou na extensão da VPN, se houver.
- **Firefox:** abra `about:config` e defina `media.peerconnection.enabled` como `false` para desligar o WebRTC por completo, ou deixe-o ligado e confie na VPN.
- **Chrome e Edge:** não há uma opção nativa; use uma extensão confiável que defina a política de IP do WebRTC como “disable non-proxied UDP” (desativar UDP sem proxy).
- **Brave:** Configurações → Privacidade e segurança → Política de manuseio de IP do WebRTC → “Desativar UDP não proxy”.
- **Safari:** vazamentos são raros, porque o Safari restringe os candidatos ICE por padrão.

Depois de qualquer mudança, rode o teste de novo. Lembre que desligar o WebRTC quebra as chamadas pelo navegador, então prefira corrigir a VPN a desativar o recurso.

## O que este teste não consegue dizer

Um resultado limpo vale só para o WebRTC. As suas requisições DNS, o fuso horário e o idioma do navegador e a sua impressão digital são canais separados; a [página inicial](https://iseeu.cc/pt/) verifica a diferença de fuso horário e de idioma, e o [teste de impressão digital](https://iseeu.cc/pt/teste-impressao-digital-navegador/) cobre o resto. Não fazemos teste de vazamento de DNS, porque isso exige um servidor DNS dedicado, e preferimos não fingir.

## Perguntas frequentes

**O que é vazamento de WebRTC?**

É quando um site usa o recurso de comunicação em tempo real do navegador para descobrir um endereço IP que a sua VPN ou proxy deveria esconder. A página pergunta a um servidor STUN qual endereço ele vê, e o navegador entrega a resposta ao JavaScript da página.

**Vazamento de WebRTC quer dizer que minha VPN não funciona?**

Não necessariamente. A maioria dos bons aplicativos de VPN passa o tráfego do WebRTC pelo túnel. Um vazamento costuma significar que a VPN cobre só parte do seu tráfego, como um proxy em extensão do navegador, ou que ela passa o IPv4 pelo túnel, mas não o IPv6.

**Devo desativar o WebRTC?**

Só se você não faz chamadas pelo navegador. Chamadas de vídeo no Google Meet, no Discord, no Teams e em sites parecidos precisam do WebRTC. Um primeiro passo melhor é a proteção contra WebRTC da própria VPN ou uma configuração do navegador que limite quais endereços o WebRTC pode compartilhar.

**Por que o teste mostra um endereço .local?**

Os navegadores modernos trocam o endereço do seu aparelho na rede local por um nome aleatório terminado em .local, gerado com mDNS. Isso é uma proteção de privacidade, não um vazamento.

**Este teste guarda o meu IP?**

Não. A comparação roda no seu navegador. A única requisição ao nosso servidor busca o IP que ele vê, e ela não é registrada.

**Por que o teste não encontrou nenhum IP público?**

Um firewall, uma configuração do navegador, uma extensão ou a sua VPN bloqueou a requisição STUN. Para a privacidade no WebRTC, esse é o melhor resultado possível.

Este teste verifica um único canal de vazamento no momento em que você o roda. Os resultados dependem do navegador, das extensões e da rede, e podem mudar quando qualquer um deles mudar. Não é uma auditoria de segurança da sua VPN.

## Ferramentas relacionadas

- [Qual é o meu IP?](https://iseeu.cc/pt/): Seu endereço IP, localização, rede, cabeçalhos, TLS e testes de vazamento em uma só página.
- [Impressão digital do navegador](https://iseeu.cc/pt/teste-impressao-digital-navegador/): Os sinais que permitem reconhecer seu navegador sem cookies.
- [Recursos do navegador](https://iseeu.cc/pt/recursos-navegador/): Cerca de 60 recursos da plataforma web, testados ao vivo no seu navegador.
- [Consulta DNS](https://iseeu.cc/pt/consulta-dns/): Registros A, AAAA, MX, TXT, NS, CNAME, CAA e SOA via DNS sobre HTTPS.

[Ver todas as ferramentas](https://iseeu.cc/pt/ferramentas/)

Última atualização: 2026-10-11

Página original: https://iseeu.cc/pt/teste-vazamento-webrtc/