Teste de vazamento de WebRTC

O WebRTC pode entregar a um site endereços que o seu navegador não enviaria de outra forma, inclusive o que está por trás da sua VPN. Este teste consulta três servidores STUN operados pela Cloudflare e pelo Google, mostra cada endereço que voltou e o que cada um é, e os compara com o endereço que um site já vê. Quando não consegue testar algo, ele diz isso em vez de mostrar um sinal verde.

Roda no seu navegador com os servidores STUN da Cloudflare e do Google · nada é guardado · tipos de candidato segundo a RFC 8445

Rode uma vez com a VPN desligada e outra com ela ligada. A diferença é a resposta.

Seu navegador pergunta a três servidores STUN, da Cloudflare e do Google, que endereço eles veem. Nenhum endereço que o WebRTC encontra é enviado para nós.

O que um site vê de qualquer formaIPv4IPv6Identificando sua conexão…
Todos os endereços que o WebRTC produziu
  1. Cada endereço que o WebRTC produz aparece aqui, um por linha, à medida que os servidores STUN respondem.

Nenhum endereço que o WebRTC encontra é enviado para nós. O seu navegador pergunta aos servidores STUN por conta própria, como em qualquer videochamada. Para mostrar o que um site vê, a página pergunta ao ipify.org e ao nosso próprio servidor quais são os seus endereços e as redes deles, como faz o Teste de Vazamento de DNS.

O que é um vazamento de WebRTC?

O WebRTC é o recurso do navegador por trás das videochamadas. Para conectar duas pessoas diretamente, ele coleta todos os endereços pelos quais a sua máquina pode ser alcançada e os oferece à página, inclusive endereços que o seu navegador nunca enviaria numa requisição comum.

Esse processo se chama coleta de candidatos ICE (ICE candidate gathering) e está especificado na RFC 8445. O seu navegador lista os endereços das suas próprias interfaces de rede, depois pergunta a um servidor STUN “de que endereço você me vê chegando?” e acrescenta esse também. Qualquer página da internet pode iniciar isso com poucas linhas de JavaScript e ler cada candidato à medida que ele chega, sem nenhum pedido de permissão: é assim que foi projetado, porque uma chamada precisa funcionar sem ele.

Isso vira um vazamento quando um desses endereços é algo que você estava escondendo. Uma VPN muda o caminho que as requisições do seu navegador seguem, mas o WebRTC pode perguntar ao sistema operacional sobre todas as interfaces, então, numa máquina em que a conexão física continua ativa, o endereço real pode aparecer ao lado do da VPN. Nada deu errado: o recurso está fazendo exatamente aquilo para que foi projetado.

O que qualquer página pode iniciaruma coleta, passo a passo

SEU DISPOSITIVOA INTERNETSeu roteador (NAT)Script da páginaSeu navegadorServidor STUNstun.cloudflare.comnew RTCPeerConnection()sem pedido de permissãolista todas as interfaces de rede192.168.1.20 → 8b7f4e2a-….localde que endereço você me vê chegando?192.168.1.20:54400203.0.113.7:54400203.0.113.7:54400o endereço que ele viucada candidato, à medida que chegaonicecandidateSEU DISPOSITIVOA INTERNETScript da páginaSeu navegadorServidor STUNnew RTCPeerConnection()sem pedido de permissãolista todas as interfaces de rede192.168.1.20 → 8b7f4e2a-….localde que endereço você me vê chegando?192.168.1.20203.0.113.7203.0.113.7:54400o endereço que ele viucada candidato, à medida que chegaonicecandidateSeu roteador (NAT)

O script inteiro

const pc = new RTCPeerConnection({
  iceServers: [{ urls: "stun:stun.cloudflare.com:3478" }],
});
pc.createDataChannel("");
pc.onicecandidate = (e) => e.candidate && console.log(e.candidate.candidate);
await pc.setLocalDescription(await pc.createOffer());

O que ele imprimiu

candidate:3442447574 1 udp 2122260223 8b7f4e2a-5c1d-4e6f-9a0b-3d2c1e0f4a5b.local 54400 typ host generation 0candidate:1467250027 1 udp 1686052607 203.0.113.7 54400 typ srflx raddr 0.0.0.0 rport 9 generation 0

O que cada linha é

  • hostNesta máquina8b7f4e2a-5c1d-4e6f-9a0b-3d2c1e0f4a5b.localMascarado pelo seu navegador
  • srflxVisto por um servidor STUN203.0.113.7Roteável na internet
Uma coleta numa conexão doméstica, com endereços de documentação. O endereço privado nunca sai do navegador como ele é; o servidor STUN vê o lado público do roteador, não a máquina, e as duas respostas vão para qualquer script que tenha pedido.
Resultado do teste de vazamento de WebRTC com cada candidato ICE, o tipo, o que cada endereço é e o vereditoResultado do teste de vazamento de WebRTC com cada candidato ICE, o tipo, o que cada endereço é e o vereditoO vereditoVazamento, sem vazamento ou, com honestidade, não foi possível testar, com o motivo.Cada endereçoCom o tipo de candidato, porque um candidato host significa algo diferente de um reflexivo de servidor.O que éPrivado, NAT de operadora, um túnel ou roteável. Só um endereço roteável pode ser um vazamento.Os servidoresCada servidor STUN na sua própria linha. Um servidor que não disse nada é um teste que não rodou.O que um site vêOs endereços que o seu navegador envia de qualquer forma, com os quais os do WebRTC são comparados.
Uma execução do teste: o que cada servidor STUN respondeu, cada endereço que o WebRTC expôs, que tipo de endereço ele é e se é um que o site já vê. Selecione um número para ver o que cada parte mostra.

Como verificar se há vazamento de WebRTC

Inicie o teste acima. Ele coleta candidatos de três servidores STUN, descobre o que cada endereço é e compara os roteáveis com o endereço que um site já vê.

Há três resultados possíveis, não dois.Sem vazamento significa que todo endereço roteável que o WebRTC produziu é um que o site já tem. Vazamento significa que pelo menos um não é, ou que um endereço da sua própria máquina foi oferecido diretamente. Não foi possível testar significa que o WebRTC está desligado, bloqueado ou que nenhum servidor STUN respondeu, e é o resultado que a maioria das ferramentas transforma discretamente em aprovação.

Rode duas vezes se você usa VPN: uma com ela desligada, para ver os seus endereços de sempre, e outra com ela ligada. A segunda execução é a que importa, e a diferença entre as duas é a resposta. A página guarda o primeiro resultado para você comparar sem anotar nada.

Três resultados, não doiso que cada um significa

  1. Sem vazamento

    Todo endereço roteável que o WebRTC produziu é um que um site já tem.

    O WebRTC entregou

    • 198.51.100.23Visto por um servidor STUNOs sites já veem
    • 8b7f4e2a-….localNesta máquinaMascarado pelo seu navegador

    Um site vê

    198.51.100.23
  2. Vazamento

    Pelo menos um endereço não é um que o site já tem, ou um endereço da sua própria máquina foi oferecido diretamente.

    O WebRTC entregou

    • 198.51.100.23Visto por um servidor STUNOs sites já veem
    • 2001:db8:4a1f:7c00::1cNesta máquinaOs sites não veem

    Um site vê

    198.51.100.23
  3. Não foi possível testar

    O WebRTC está desligado ou bloqueado, ou nenhum servidor STUN respondeu. Nada foi medido.

    stun.cloudflare.comSem resposta

    stun.l.google.comSem resposta

    O que a maioria das ferramentas mostra aquiSem vazamento

Rode duas vezes

VPN desligada

O WebRTC entregou203.0.113.7

Um site vê203.0.113.7

Sem vazamento

VPN ligada

O WebRTC entregou198.51.100.23203.0.113.7

Um site vê198.51.100.23

Continua lá com a VPN ligada

Vazamento
Cada resultado com uma execução que o produz. Com a VPN desligada, o endereço do WebRTC e o do site são o mesmo; com ela ligada, os dois deveriam mudar, e o que continua igual é a resposta.

Uma VPN impede o vazamento de WebRTC?

Sozinha, não. Uma VPN muda para onde o seu tráfego vai; o WebRTC pode perguntar ao seu sistema operacional quais interfaces existem, e a física geralmente continua lá.

A própria descrição do IETF é exata: “se o cliente tenta esconder a sua localização física por meio de uma rede privada virtual (VPN), e a VPN e o sistema operacional local permitem roteamento por várias interfaces, o WebRTC pode descobrir não só o endereço público da VPN, mas também o endereço público do provedor sobre o qual a VPN está rodando”. Os dois endereços são oferecidos, e uma página que esteja atenta pode ler os dois.

Alguns clientes de VPN fecham a brecha roteando todo o tráfego no nível do sistema operacional, ou incluindo uma extensão de navegador que restringe o WebRTC. Os dois métodos funcionam, e os dois são coisas para verificar, não para presumir: é para isso que serve esta página. Uma VPN cuja própria página de teste de vazamento diz que você está protegido não é uma prova independente.

Uma VPN ligada, o Wi-Fi ainda ativoduas interfaces, duas respostas

Seu notebookVPN10.64.0.2Wi-Fi192.168.1.20TÚNEL VPNServidor VPN198.51.100.23Sitesua navegaçãoServidor STUNRoteador (NAT)Seu provedor203.0.113.7O WebRTC pergunta nas duasSeu notebookVPN10.64.0.2Wi-Fi192.168.1.20TÚNEL VPNServidor VPN198.51.100.23Roteador (NAT)Seu provedor203.0.113.7sua navegaçãoSiteServidor STUNO WebRTC pergunta nas duas

O que a página recebe

  • 198.51.100.23srflxVisto por um servidor STUNpela VPNOs sites já veem
  • 203.0.113.7srflxVisto por um servidor STUNpelo Wi-Fi, fora do túnelOs sites não veem

RFC 8828

O que fecha a brecha

  • Roteamento no nível do sistema operacionalNada sai fora do túnel, então um servidor STUN só consegue ver o endereço da VPN.
  • A extensão de navegador da VPNEla restringe o WebRTC dentro do navegador, então a outra interface nunca é consultada.
  • Depois, verifique em vez de presumirRode este teste com a VPN ligada. A página de teste de vazamento da própria VPN não é uma prova independente.
O caso que o IETF descreve na RFC 8828: a VPN e o sistema operacional roteiam por mais de uma interface, então o WebRTC encontra o endereço público da VPN e, por baixo dele, o endereço do provedor.

Host, reflexivo de servidor e relay: qual candidato é qual?

Um candidato host é um endereço da sua própria máquina. Um reflexivo de servidor é o que um servidor STUN viu: o lado público do seu NAT. Um candidato relay é o endereço de um servidor TURN, não o seu.

A distinção importa, e a maioria dos testes de vazamento a joga fora. Um candidato reflexivo de servidor que carrega o seu IPv4 público geralmente não é novidade: é o mesmo endereço que o site recebe da conexão que você já está usando. Um candidato host que carrega um endereço roteável é outra coisa: é um endereço da própria máquina, oferecido diretamente à página. Ele identifica esta máquina, não só o roteador da sua casa, e muda quando a rede muda.

A página mostra o tipo ao lado de cada endereço, junto com o transporte, a porta e o endereço relacionado que um candidato reflexivo indica. Um candidato relay é o próprio endereço do servidor TURN e não revela nada sobre você; este teste não usa nenhum servidor TURN, então, se aparecer um, outra coisa na página o configurou.

Um candidato, campo por campocomo uma página o recebe

  1. candidate:1467250027Fundação
  2. 1Componente
  3. udpTransporte
  4. 1686052607Prioridade
  5. 203.0.113.7Endereço
  6. 54400Porta
  7. typ srflxTipo
  8. raddr 0.0.0.0 rport 9Endereço relacionado
  9. generation 0Extensão

Trocado por 0.0.0.0, porta 9, onde os endereços locais são mascarados

Os quatro tipos

  • typ hostNesta máquina

    Um endereço de uma das suas próprias interfaces de rede.

    Um privado é mascarado. Um roteável é o próprio dispositivo: a descoberta mais grave.

    Mais grave quando roteável

  • typ srflxVisto por um servidor STUN

    O lado público do seu roteador, como um servidor STUN o viu.

    Geralmente é o endereço que um site já tem pela sua conexão.

    Geralmente não é novidade

  • typ prflxVisto pelo outro lado

    O lado público do seu roteador, como a outra ponta de uma chamada o viu.

    Só aparece ao conectar com a outra ponta, então um teste sem chamada nunca vê um.

    Só durante uma chamada

  • typ relayO próprio endereço de um servidor relay

    O endereço de um servidor TURN, que retransmite o tráfego para você.

    O endereço do servidor, não o seu. Este teste não usa nenhum servidor TURN, então, se houver um aqui, foi outra coisa que o configurou.

    Nada sobre você

O endereço do candidato é comparado com o que um site vê; o tipo diz quão grave é uma diferença. Definições da RFC 8445, seção 4.

O que é um endereço mDNS .local, e ele me protege?

Os navegadores modernos trocam os seus endereços privados por um nome aleatório terminado em .local antes de oferecê-los a uma página. Funciona, para endereços privados. Nunca teve a intenção de esconder um público.

O Chrome faz isso por padrão desde a versão 76 e o Firefox tem media.peerconnection.ice.obfuscate_host_addresses definido como true: em vez de 192.168.1.20, a página recebe algo como 8b7f4e2a-….local, que não significa nada para ninguém fora da sua rede. O Safari vai além: até que um site tenha permissão de câmera ou microfone, ele não oferece nenhum candidato host. O teste acima reconhece esses nomes .local e os apresenta como a proteção funcionando, não como uma descoberta.

O rascunho do IETF que define o mecanismo é explícito sobre o que ele não faz: “um endereço que já está exposto à internet não precisa ser protegido pelo mDNS, pois pode ser observado trivialmente pelo servidor web”. Então um candidato reflexivo de servidor continua carregando o seu IPv4 público e, o que surpreende muita gente, uma máquina com um endereço IPv6 roteável ainda pode oferecer esse endereço como candidato host. Há mais uma brecha que vale conhecer: o Chrome desliga a proteção em qualquer site que já tenha permissão de câmera ou microfone, então um site de videochamada que você já usou vê os seus endereços locais reais.

O que o nome .local substituie o que ele deixa como está

O que o seu navegador tem

candidate:3442447574 1 udp 2122260223 192.168.1.20 54400 typ host generation 0

O que a página recebe

candidate:3442447574 1 udp 2122260223 8b7f4e2a-5c1d-4e6f-9a0b-3d2c1e0f4a5b.local 54400 typ host generation 0

O que cada navegador faz por padrão

  • ChromeVersão 76, agosto de 2019
  • Firefoxmedia.peerconnection.ice.obfuscate_host_addresses = true
  • SafariNenhum candidato host até que um site tenha permissão de câmera ou microfone

O mecanismo é um rascunho do IETF, revisado pela última vez em dezembro de 2021 e nunca publicado como RFC. draft-ietf-mmusic-mdns-ice-candidates-03

Um endereço que o WebRTC poderia oferecerMascarado?
192.168.1.20O seu IPv4 privado, como candidato hostMascaradoTrocado por um nome aleatório: a página não descobre nada sobre a sua rede.
203.0.113.7O seu IPv4 público, como candidato do servidor STUNVisívelJá é público, então fica. Só o endereço relacionado é apagado.
2001:db8:4a1f:7c00::1cUm IPv6 roteável, como candidato hostVisívelTambém é público, então o mascaramento nunca foi feito para cobri-lo.
2001:db8:4a1f:7c00:8d3:5e2f:a41c:9b07Um endereço IPv6 temporárioPode aparecerO rascunho deixa o navegador mantê-lo sem máscara, por escolha.
192.168.1.20Qualquer endereço local, num site com permissão de câmera ou microfoneSem máscaraO Chrome desliga o mascaramento ali: o site vê os seus endereços locais reais.
O mascaramento esconde o que só a sua própria rede sabe. O que um site poderia ver de qualquer forma, ele deixa como está: de propósito, não por engano.

Por que o IPv6 é o vazamento que sobra

Um endereço IPv6 global pertence a uma única máquina, e não a uma casa atrás de NAT, e o mDNS o deixa de lado de propósito. É a coisa mais identificadora que o WebRTC ainda entrega.

Com IPv4, o NAT do roteador da sua casa coloca tudo atrás de um único endereço, então um candidato reflexivo de servidor diz a uma página mais ou menos o que a sua conexão comum já diz. O IPv6 não tem NAT: cada dispositivo tem o próprio endereço roteável, e um candidato host que o carrega identifica o dispositivo, não a linha. Se a sua VPN só transporta IPv4 (muitas são assim), esse endereço IPv6 também fica totalmente fora do túnel.

As extensões de privacidade ajudam, porque um endereço IPv6 temporário é trocado de tempos em tempos. Mas elas não o escondem: o rascunho do mDNS diz que esses endereços podem ficar sem ofuscação. O teste acima marca um candidato host IPv6 roteável como a coisa mais grave que ele pode encontrar, e o Teste IPv6 diz se a sua conexão tem IPv6 ou não.

Quem um endereço identificaos mesmos três dispositivos, duas vezes

RoteadorIPv4, atrás de NATIPv6, sem NAT
Notebook192.168.1.202001:db8:4a1f:7c00::1c
Celular192.168.1.212001:db8:4a1f:7c00::2b
TV192.168.1.222001:db8:4a1f:7c00::3d
Roteador203.0.113.7Um endereço para a linha inteiraUm endereço por dispositivo

Um endereço IPv6 global, em duas metades

2001:db8:4a1f:7c00Prefixo de rede: a sua linha /64:8d3:5e2f:a41c:9b07Identificador de interface: este dispositivo

  • Estável2001:db8:4a1f:7c00::1c
  • Temporário: é trocado2001:db8:4a1f:7c00:8d3:5e2f:a41c:9b07

Uma VPN que só transporta IPv4

  • IPv4198.51.100.23Dentro do túnel
  • IPv62001:db8:4a1f:7c00::1cFora do túnel
Atrás do NAT do IPv4, uma casa divide um único endereço; no IPv6, cada dispositivo tem o seu, e um candidato host o oferece diretamente. O teste trata um candidato host IPv6 roteável como a descoberta mais grave.

Como impedir o vazamento de WebRTC em cada navegador

O Firefox tem preferências que funcionam. O Edge tem uma política corporativa. O Safari já restringe os candidatos. As extensões de navegador que ainda são recomendadas não fazem mais nada.

No Firefox, about:config → media.peerconnection.ice.default_address_only envia um único endereço em vez de todos, e media.peerconnection.ice.relay_only limita a coleta a candidatos relay, o que quebra as chamadas diretas, mas esconde todo o resto. As duas vêm desativadas por padrão; o mascaramento mDNS dos endereços privados (media.peerconnection.ice.obfuscate_host_addresses) já vem ativado. No Edge, a política WebRtcLocalIpsAllowedUrls controla quais sites podem ver endereços locais; a própria documentação da Microsoft observa que adicionar um site “enfraquece a proteção”. O Chrome não tem uma configuração equivalente para um usuário comum. O Safari é o mais rígido sem que você peça: sem permissão de câmera ou microfone, o WebKit só oferece candidatos reflexivos de servidor e relay, e nenhum candidato host.

Duas coisas ainda muito recomendadas não funcionam mais. A opção “Prevent WebRTC from leaking local IP addresses” do uBlock Origin foi removida na versão 1.38, com a observação de que ela “não é mais necessária nos navegadores modernos, exceto no Firefox para Android”. E a extensão WebRTC Network Limiter do Google, ainda listada na loja, não consegue rodar: as extensões Manifest V2 estão desativadas para todos os usuários do Chrome desde o Chrome 138, em julho de 2025. Se uma página manda você instalar qualquer uma das duas, essa página não é atualizada há anos.

O que cada navegador oferececonferido com a documentação de cada fabricante

  • FirefoxPreferências que funcionam

    about:config

    • media.peerconnection.ice.obfuscate_host_addressesPadrão trueMascara os endereços privados. Já vem ativado.
    • media.peerconnection.ice.default_address_onlyPadrão falseMude para trueEnvia um único endereço em vez de todos.
    • media.peerconnection.ice.relay_onlyPadrão falseMude para trueSó candidatos relay. Esconde o máximo e quebra as chamadas diretas.
  • EdgePolítica corporativa

    WebRtcLocalIpsAllowedUrls

    Lista os sites que podem ver endereços locais.

    Não configurada: os endereços locais continuam mascarados.

    A própria nota da Microsoft: adicionar um site enfraquece a proteção.

    Windows e macOS, versão 80 e posteriores

  • ChromeSem configuração

    Sem configuração para o usuário comum.

    Endereços privados mascarados por padrão desde a versão 76.

    Não num site com permissão de câmera ou microfone.

  • SafariRígido por padrão

    Sem permissão de câmera ou microfone, só candidatos do servidor STUN e relay.

    Nenhum candidato host.

Conselhos que não funcionam mais

  • Prevent WebRTC from leaking local IP addresses

    uBlock Origin

    Removida na versão 1.38

    Não é mais necessária nos navegadores modernos, segundo o uBlock Origin, exceto no Firefox para Android.

  • WebRTC Network Limiter

    Google · Chrome Web Store

    Ainda listada, não consegue rodar

    As extensões Manifest V2 estão desativadas para todos os usuários do Chrome desde o Chrome 138, julho de 2025.

A documentação de cada fabricante, lida no dia em que esta página foi conferida. Uma página que ainda manda você instalar qualquer uma das duas últimas não é atualizada há anos.

Vazamento de WebRTC, de DNS e de IP: qual é a diferença?

São três maneiras diferentes de uma VPN ser contornada. Um vazamento de WebRTC mostra um endereço; um vazamento de DNS mostra quem responde às suas consultas; um vazamento de IP é o caso simples em que o seu tráfego nunca entrou no túnel.

Um vazamento de WebRTC tem a ver com endereços que o seu navegador oferece por conta própria, por meio de um recurso feito para oferecê-los. Um vazamento de DNS tem a ver com qual resolvedor responde às suas consultas: o seu tráfego pode passar pela VPN enquanto as suas consultas continuam indo para o resolvedor do seu provedor, o que conta a esse provedor cada site que você visita. O nosso Teste de Vazamento de DNS verifica isso com o nosso próprio servidor de nomes, então consegue ver exatamente quais resolvedores perguntaram.

Um vazamento de IP, no sentido geral, é o endereço que um site simplesmente vê, e você pode conferi-lo no Qual é Meu IP ou no Qual é Meu ISP. Rode os três juntos depois de qualquer mudança na VPN: eles falham de forma independente, e um resultado limpo em um não diz nada sobre os outros.

Três maneiras de contornar uma VPNcada uma falha por conta própria

VocêTÚNEL VPNPelo túnelVazamento de IP · seu tráfegoO site203.0.113.7Vazamento de DNS · suas consultasO resolvedor do seu provedor203.0.113.53Vazamento de WebRTC · seus endereçosO script da página203.0.113.7VocêTÚNEL VPNPelo túnelVazamento de IPseu tráfegoO site203.0.113.7Vazamento de DNSsuas consultasO resolvedor do seu provedor203.0.113.53Vazamento de WebRTCseus endereçosO script da página203.0.113.7
  • Vazamento de IP

    O que vazaO endereço que toda requisição carrega

    Quem fica sabendoCada site que você visita

    Verifique comQual é Meu IPQual é Meu ISP

  • Vazamento de DNS

    O que vazaQual resolvedor responde às suas consultas

    Quem fica sabendoO seu provedor, para cada site que você consulta

    Verifique comTeste de Vazamento de DNS

  • Vazamento de WebRTC

    O que vazaEndereços que o seu navegador oferece a uma página

    Quem fica sabendoQualquer página que pedir, sem aviso

    Verifique comTeste de Vazamento WebRTC

Eles falham de forma independente: um resultado limpo em um não diz nada sobre os outros dois. Rode os três depois de qualquer mudança na sua VPN.

Por que este teste consulta mais de um servidor STUN

Porque “nenhum endereço voltou” e “nenhum endereço existe” parecem idênticos, e só um deles é uma boa notícia.

Um firewall corporativo, uma VPN restritiva ou uma rede que bloqueia UDP pode impedir que um servidor STUN responda. Um teste que consulta um único fornecedor e não vê nada não aprendeu nada; mesmo assim, a resposta de costume é mostrar um sinal verde. Este consulta o endpoint STUN documentado da Cloudflare e o do Google, informa cada um separadamente e diz que não foi possível testar quando nenhum deles respondeu.

A escolha dos servidores é proposital. A Cloudflare publica stun.cloudflare.com:3478 como parte de um produto, então há termos para ler. O stun.l.google.com:19302 do Google só está documentado como o padrão do validador de WebRTC do próprio Google, sem termos publicados, então ele é usado como segunda opinião, não como fonte única. O da Twilio exige credenciais, e a Mozilla não documenta nenhum servidor STUN público, por mais que um seja citado.

Servidores STUN públicose quais deles este teste consulta

  • CloudflareConsultado

    stun.cloudflare.com:3478

    Um endpoint documentado, parte de um produto, com termos para ler.

  • GoogleConsultado, como segunda opinião

    stun.l.google.com:19302

    Documentado só como o padrão do validador de WebRTC do próprio Google. Sem termos publicados.

  • TwilioNão consultado

    global.stun.twilio.com:3478

    Exige credenciais da API da Twilio: não está aberto a qualquer página.

  • MozillaNão consultado

    Nenhum servidor público

    Não documenta nenhum servidor STUN público. O Firefox não vem com nenhum servidor ICE padrão.

Quando um servidor não diz nada

CloudflareGoogle
RespondeuRespondeuO resultado vale
RespondeuEm silêncioO resultado vale; o servidor em silêncio é indicado
Em silêncioRespondeuO resultado vale; o servidor em silêncio é indicado
Em silêncioEm silêncioNão foi possível testar
Dois operadores, consultados separadamente. Um servidor em silêncio é indicado e o resultado vale; quando nenhum responde, nada foi medido, e o teste diz isso em vez de mostrar uma aprovação.

O meu endereço IP é um dado pessoal?

Na UE, um endereço IP dinâmico é um dado pessoal para o operador de um site que poderia identificar você com informações que o provedor tem. O Tribunal de Justiça decidiu isso em 2016.

O caso é Breyer, C-582/14, julgado em 19 de outubro de 2016, e o comunicado de imprensa do Tribunal o resume assim: “o endereço de protocolo Internet dinâmico de um utilizador constitui, para o explorador do sítio, um dado pessoal, quando esse explorador disponha de meios legais que lhe permitam identificar o utilizador em causa graças às informações suplementares que o fornecedor de acesso à Internet do utilizador dispõe”. O mesmo comunicado de imprensa observa que um site pode ter um interesse legítimo em guardar parte desses dados para se defender de ataques.

É justamente por isso que esta página faz o trabalho no seu navegador. Os candidatos ICE são coletados pelo seu navegador, comparados no seu navegador e mostrados a você; nenhum endereço que o WebRTC encontra é enviado para nós, então não há nada dele para guardarmos, entregarmos ou perdermos. Você pode acompanhar o painel de rede enquanto o teste roda.

A decisão BreyerTribunal de Justiça da União Europeia

C-582/14Breyer v Bundesrepublik Deutschland19 de outubro de 2016

  1. O operador do siteum endereço e um horário, dos seus registros203.0.113.7 · 14:02:37
  2. os meios legais para obter isso
  3. O provedor de acesso à internetquem estava usando aquele endereço naquele horário203.0.113.7 · 14:02:37 →
  4. Dado pessoal, para esse operador

O comunicado de imprensa do Tribunal: um site pode ter um interesse legítimo em guardar parte desses dados para se defender de ataques.

Nesta página

Seu navegador

  1. Coleta
  2. Classifica
  3. Compara
  4. Mostra
  • Veem o seu endereço público, como em qualquer chamada
  • dnsrobot.netNenhum candidato é enviado
Caso C-582/14, Breyer. Um endereço IP dinâmico é um dado pessoal para o operador de um site que tenha meios legais para identificar você com os registros do provedor. Esta página mantém os candidatos no seu navegador.

Teste de vazamento de WebRTC: perguntas e respostas

O que é um vazamento de WebRTC?

O WebRTC é o recurso do navegador por trás das videochamadas. Para conectar duas pessoas diretamente, ele coleta todos os endereços pelos quais a sua máquina pode ser alcançada e os oferece à página, sem nenhum pedido de permissão. Isso vira um vazamento quando um desses endereços é um que você estava escondendo: normalmente o seu endereço real enquanto a VPN está ligada, porque o WebRTC pode perguntar sobre todas as interfaces de rede, e não só sobre a que a sua navegação usa.

Como faço um teste de vazamento de WebRTC?

Inicie o teste desta página. Ele consulta três servidores STUN de dois operadores, lista cada endereço que o WebRTC produziu, com o tipo de endereço que cada um é, e compara os roteáveis com o endereço que um site já vê. Se você usa VPN, rode uma vez com a VPN desligada e outra com ela ligada: a diferença entre as duas execuções é a resposta.

Uma VPN impede o vazamento de WebRTC?

Sozinha, não. Uma VPN muda para onde o seu tráfego vai, mas o WebRTC pode perguntar ao sistema operacional quais interfaces existem, e a conexão física geralmente continua sendo uma delas. O próprio texto do IETF diz que o WebRTC pode descobrir “não só o endereço público da VPN, mas também o endereço público do provedor sobre o qual a VPN está rodando”. Alguns clientes de VPN fecham a brecha; este teste mostra se o seu fechou.

O que significa um endereço .local nos resultados?

Isso é o mDNS, e é uma boa notícia. Os navegadores modernos trocam os seus endereços privados por um nome aleatório terminado em .local antes de oferecê-los a uma página, então, a partir desses nomes, um site não descobre nada sobre a sua rede doméstica. O Chrome faz isso desde a versão 76 e o Firefox faz o mesmo; o Safari vai além e não oferece nenhum candidato host até que um site tenha permissão de câmera ou microfone. O teste marca esses nomes como a proteção funcionando, e não como uma descoberta.

Se o mDNS esconde o meu IP local, estou seguro?

Em parte. O mDNS foi criado para esconder endereços privados e, de forma explícita, não para esconder um que já é público: o rascunho do IETF que o define diz isso. O seu IPv4 público continua aparecendo como candidato reflexivo de servidor, e uma máquina com um endereço IPv6 roteável ainda pode oferecer esse endereço diretamente. O Chrome também desliga a proteção em qualquer site que já tenha permissão de câmera ou microfone.

Por que o teste às vezes diz que não foi possível testar?

Porque essa é a verdade. Se o WebRTC está desligado, bloqueado por uma extensão ou uma política, ou nenhum servidor STUN respondeu (um firewall, uma VPN restritiva, uma rede que bloqueia UDP), então nada foi medido. A maioria das ferramentas mostra um sinal verde nessa situação, que é a coisa mais enganosa que um teste de vazamento pode fazer. Este diz o que aconteceu e indica quais servidores ficaram em silêncio.

Como desativo o WebRTC no Firefox?

As preferências documentadas do Firefox restringem o WebRTC em vez de desligá-lo. Em about:config, media.peerconnection.ice.default_address_only envia um único endereço em vez de todos, e media.peerconnection.ice.relay_only limita a coleta a candidatos relay: isso esconde o máximo, mas quebra as chamadas diretas. O mascaramento dos endereços privados, media.peerconnection.ice.obfuscate_host_addresses, já vem ativado por padrão. Rode o teste de novo depois de cada ajuste para ver o que ele trouxe.

Como impedir vazamentos de WebRTC no Chrome?

O Chrome não dá ao usuário comum nenhuma configuração para isso; o mascaramento mDNS dos endereços privados vem ativado por padrão, e essa é a proteção que você tem. O Edge, que usa o mesmo motor do Chrome, tem a política corporativa WebRtcLocalIpsAllowedUrls. As extensões ainda muito recomendadas não funcionam: o uBlock Origin removeu a opção de WebRTC na versão 1.38, e o WebRTC Network Limiter do Google não consegue rodar desde que o Manifest V2 foi desativado no Chrome 138.

Qual é a diferença entre um candidato host e um reflexivo de servidor?

Um candidato host é um endereço da sua própria máquina. Um candidato reflexivo de servidor é o que um servidor STUN viu: o lado público do seu NAT, que geralmente é o endereço que o site já tem pela sua conexão. Um candidato host roteável é a descoberta mais grave, porque é um endereço do próprio dispositivo e, no IPv6, identifica o dispositivo, e não a casa.

Vazamento de WebRTC é o mesmo que vazamento de DNS?

Não. Um vazamento de WebRTC revela um endereço; um vazamento de DNS revela qual resolvedor responde às suas consultas, o que conta ao seu provedor cada site que você visita, mesmo quando o tráfego em si passa pela VPN. Eles falham de forma independente, então um resultado limpo em um não diz nada sobre o outro. Rode também o nosso Teste de Vazamento de DNS depois de qualquer mudança na VPN.

Este teste envia o meu endereço IP para algum lugar?

Só para onde qualquer site o veria. O seu navegador contata os servidores STUN, como qualquer videochamada: esse é o teste. Para saber o que um site vê, a página pergunta ao ipify.org e ao nosso próprio servidor quais são os seus endereços e as redes deles, como faz o Teste de Vazamento de DNS. Os endereços que o WebRTC encontra ficam no seu navegador: nenhum é enviado para nós. Acompanhe o seu painel de rede enquanto o teste roda.

O meu endereço IP é um dado pessoal segundo o direito da UE?

Para o operador de um site na UE, um endereço IP dinâmico é um dado pessoal quando esse operador tem meios legais para identificar você com informações que o provedor de internet guarda. Essa é a decisão do Tribunal de Justiça no caso Breyer, C-582/14, de outubro de 2016. É um dos motivos pelos quais esta página mantém a parte WebRTC do teste no seu navegador, e não num servidor nosso.

Sentiu falta de algo?Sugira um recurso ou uma nova ferramenta