Vazamentos do WebRTC
Teste de vazamento WebRTC: o que uma ligação pelo navegador revela sobre o seu endereço IP
Parte de: Ligação VoIP é segura? O que uma ligação pelo navegador protege e o que expõe
Adicione o callfrombrowser.org como fonte preferida no Google
Em resumo
Um teste de vazamento WebRTC lista todos os endereços IP que o seu navegador entrega a uma página web pelo WebRTC, para você identificar algum que pretendia esconder, em geral o endereço do seu provedor de internet com a VPN ativada [1]. Uma ligação do navegador para um número de telefone mostra o seu IP ao serviço de ligação, não à pessoa para quem você liga, que recebe um identificador de chamadas [2]. O teste é uma das verificações de privacidade e segurança que eu sugiro antes de fazer ligações pelo navegador.
Principais fatos
- As regras da IETF para o WebRTC dizem que uma VPN com split tunneling pode deixar o WebRTC descobrir o endereço público do seu provedor de internet além do endereço da VPN [1]. Verificado em .
- Na minha verificação local no Chrome 156, uma página sem permissão de microfone via o meu computador só como um nome .local aleatório; com o microfone permitido, ela recebeu o meu endereço local real [3][1]. Verificado em .
- O Messenger diz que as ligações individuais compartilham o seu endereço IP com o aparelho da outra pessoa [4]; a opção Proteger endereço IP nas ligações, do WhatsApp, passa as ligações pelos servidores dele [5]. Verificado em .
O que é um vazamento WebRTC?
Antes de uma ligação WebRTC, o navegador reúne as rotas de rede possíveis, chamadas de candidatos ICE, e as entrega à página web para que ela as passe ao outro lado. Cada uma traz um endereço IP, ou um nome .local aleatório no lugar de um endereço local oculto. Um site comum só vê o endereço público de onde veio a sua requisição; pelo WebRTC, uma página pode descobrir mais [1]. Vazamento é qualquer endereço dessa lista que você não pretendia compartilhar.
Como o resto da ligação viaja está em WebRTC, SIP e a rede telefônica; para vazamentos, só a lista de candidatos importa. A MDN observa que os endereços dela ficam sempre expostos à página [6].
| Tipo de candidato | Endereço que mostra | Risco para a privacidade |
|---|---|---|
| host | O endereço do seu aparelho na rede local, ou um nome aleatório terminado em .local se o navegador o esconder [7][3] | Menor que o de um endereço público, mas a IETF chama os endereços IPv4 privados de uma fonte bastante significativa de fingerprinting [1] |
| srflx (server reflexive) | O endereço público que o seu roteador ou a sua VPN mostra a um servidor STUN [7] | Alto, se for o endereço do seu provedor com a VPN ativada [1] |
| relay | Um endereço num servidor TURN que repassa a mídia [7] | Baixo: o outro lado vê o endereço do relay, não o seu [6]; o operador do relay ainda vê você |
A IETF considera o caso da VPN o mais significativo, porque algumas pessoas usam VPN para ficar anônimas [1]. Os outros dois casos são o seu endereço privado e um proxy que as verificações do WebRTC contornam, o que revela o seu endereço público real [1].
Uma ligação pelo navegador expõe o seu endereço IP?
Para o serviço de ligação, sim: todo site vê o seu endereço público [1], e uma ligação acrescenta uma conexão de mídia com os servidores do serviço. Para quem você liga num fixo ou celular, não: a ligação sai da internet no gateway do provedor [8], e a rede telefônica repassa um número de origem, não um endereço IP [2]. Ligações de app para app podem conectar dois aparelhos diretamente.
| Tipo de ligação | O serviço | A pessoa para quem você liga |
|---|---|---|
| Do navegador para um número de telefone (Google Voice, TwinPhone, Yolla) | Sim: ele mantém a conexão de mídia | Não: ela vê um identificador de chamadas [2] |
| Discadores web grátis (Call2Friends, Globfone) | Sim: o Call2Friends limita as ligações grátis por endereço IP, e a política de privacidade do Globfone lista endereços IP entre os dados técnicos e registros que ele trata [9][10] | Não: ela vê um identificador de chamadas |
| Messenger, ligação individual | Sim | Sim: a Meta diz que o seu IP é compartilhado com o outro aparelho [4] |
| Sim | Pode ver, a menos que Proteger endereço IP nas ligações esteja ativado; as ligações em grupo sempre passam por relay [5] | |
| Telegram | Sim | Pode ver: o anúncio do Telegram de 2017 diz que as ligações vão ponto a ponto sempre que possível [11] |
Nas ligações para números de verdade, a questão é o que o serviço descobre e guarda; o que a pessoa do outro lado vê no lugar do IP está em que número aparece quando você liga pelo navegador.
Como fazer um teste de vazamento WebRTC
Uma página de teste de vazamento faz o mesmo que um discador antes de uma ligação: abre uma conexão WebRTC, pergunta a um servidor STUN qual endereço público ele vê e lista cada candidato ao lado do endereço que ela vê por HTTP comum. Rode o teste em cada navegador que você usa para fazer ligações, primeiro com a VPN desativada e depois com ela ativada.
- VPN desativada: abra uma página de teste de vazamento, como o WebRTC Leak Test do BrowserLeaks. "Your Remote IP", no topo, e "Public IP Address", em "Your WebRTC IP", devem coincidir.
- VPN ativada: recarregue a página. "Your Remote IP" agora deve mostrar o endereço da VPN.
- Se a seção do WebRTC ainda listar o endereço do seu provedor, o WebRTC está contornando o túnel [1].
- Uma entrada local terminada em .local significa que o endereço está oculto [3]; uma entrada crua começando com 192.168. ou 10. não está.
- Se a página oferecer um teste de microfone, permita e teste de novo: um discador precisa de acesso ao microfone, e essa permissão pode liberar mais endereços [1]. Depois, remova a permissão nas configurações do site [12].
O que mudou no Chrome depois que permiti o microfone
Em , carreguei uma página de teste local no Chrome 156 num Mac, sem servidor STUN, então nenhum endereço foi para um servidor externo. Sem permissão de microfone, a página viu um candidato host com um nome aleatório terminado em .local [3]. Com o microfone permitido, ela recebeu o meu endereço IPv4 local real.
Isso segue o padrão, que só libera a lista completa de endereços com consentimento, como a permissão de microfone [1]; o WebKit, o motor do Safari, descreveu a mesma regra em 2017 [13]. Então um discador que você autoriza pode ver o seu endereço local: um risco menor que o do seu endereço público [1].
Configurações do navegador que limitam vazamentos WebRTC
O Brave documenta uma configuração de IP do WebRTC para os usuários. O Google documenta os controles do Chrome para extensões e administradores, e a Microsoft documenta os do Edge como política de administrador. O Firefox esconde os endereços locais por padrão e mantém uma chave para desativar o recurso em about:config. Uma regra vale em todos: desativar o WebRTC também para os discadores no navegador, porque é o WebRTC que transporta a ligação [14].
| Navegador | Controle | O que muda | Efeito nas ligações pelo navegador |
|---|---|---|---|
| Brave | Política de tratamento de IP do WebRTC nas configurações de privacidade, segundo a wiki do Brave (editada pela última vez em 2018) [15] | O padrão Default Public Interface Only não expõe nenhum endereço local [15] | A mídia pode recorrer a um servidor de relay [1] |
| Chrome | Extensões podem definir uma política de tratamento de IP do WebRTC [16]; administradores podem definir a política WebRtcIPHandling [17] | Conforme o valor, deixa de usar endereços privados ou envia a mídia só por um proxy [17] | Os valores só de proxy podem levar o áudio para TCP, o que, segundo a IETF, reduz a qualidade [1] |
| Edge | Política de administrador WebRtcLocalhostIpHandling [18] | Dois dos valores dela deixam de expor o endereço IP local [18] | Igual ao Chrome |
| Firefox | Endereços locais ocultos por padrão [19]; media.peerconnection.enabled em about:config [20] | Definir essa preferência como false desativa o WebRTC | Os discadores no navegador param de funcionar |
| Safari | Regra embutida | Páginas sem acesso ao microfone ou à câmera não recebem endereços host, como o WebKit descreveu em 2017 [13] | Nenhum |
O que uma VPN muda nas ligações pelo navegador
Uma VPN que manda todo o tráfego pelo túnel, inclusive o WebRTC, mostra ao serviço de ligação o endereço da VPN em vez do seu. Uma VPN com split tunneling também pode deixar o WebRTC encontrar o endereço do seu provedor [1], daí o teste de vazamento com a VPN ativada. A VPN também tem efeitos colaterais nas ligações.
- Alguns serviços restringem VPNs: os termos do TextNow dizem que ele pode limitar ou restringir o uso delas [21].
- Alguns discadores grátis racionam as ligações grátis por endereço IP, como faz o Call2Friends [9], então numa VPN você pode dividir essa cota com outros usuários do mesmo endereço de saída.
- Forçar a mídia por um proxy que não transporta UDP leva o áudio para TCP, o que, segundo a IETF, reduz a qualidade da mídia [1].
- O serviço continua vendo a sua conta e os registros de ligações; o Google, por exemplo, pode registrar os números, o horário e a duração das ligações [22].
Como manter o seu endereço IP privado nas ligações
Ajuste a solução ao tipo de ligação. Nas ligações para números de telefone, a pessoa para quem você liga não recebe o seu IP, então escolha um serviço em que você confie para guardá-lo e confira a sua VPN. Nas ligações de app para app, o outro aparelho pode se conectar diretamente ao seu, então use a opção de relay do app, quando houver.
- Ligações pelo navegador: faça o teste de vazamento com a VPN ativada; no Brave, escolha Default Public Interface Only [15].
- Microfone: nos discadores que você usa uma vez só, conceda a permissão com "Permitir desta vez" [12]; na minha verificação no Chrome, uma página com essa permissão conseguia ver o endereço local.
- WhatsApp: ative Proteger endereço IP nas ligações. A página de ajuda trata de Android, iOS e Mac, não da versão web, e avisa que as ligações por relay podem perder um pouco de qualidade [5].
Perguntas frequentes
O que é um teste de vazamento WebRTC?
Um teste de vazamento WebRTC é uma página web que executa a mesma preparação de conexão usada numa ligação pelo navegador e lista todos os endereços IP que o seu navegador oferece, ao lado do endereço que a página vê por HTTP comum. O endereço do seu provedor nessa lista com a VPN ativada significa que o WebRTC está contornando o túnel [1]; um nome .local aleatório significa que o seu endereço local está oculto [3].
A pessoa para quem eu ligo pelo navegador consegue ver o meu IP?
Não, numa ligação para fixo ou celular. O provedor transforma o áudio do navegador numa ligação telefônica no gateway dele [23], e a rede telefônica repassa um número de origem, não um endereço IP [2]. Ligações de app para app são diferentes: o Messenger diz que as ligações individuais compartilham o seu IP com o aparelho da outra pessoa [4].
Uma VPN impede vazamentos WebRTC?
Uma VPN que passa todo o tráfego pelo túnel, inclusive o WebRTC, impede. Uma VPN com split tunneling pode não impedir, porque o WebRTC consegue descobrir o endereço público do seu provedor ao lado do endereço da VPN [1]. O único jeito de saber é um teste de vazamento com a VPN conectada, em cada navegador que você usa, repetido depois das atualizações.
Vazamento de IP local é perigoso?
Menos que o vazamento de um endereço público. Um endereço privado como 192.168.1.20 não diz onde você está, mas a IETF chama os endereços IPv4 privados de uma fonte bastante significativa de fingerprinting, capaz de relacionar sessões normais e de navegação anônima no mesmo aparelho [1]. O Firefox esconde os endereços locais por padrão [19], o Safari os esconde de páginas sem acesso ao microfone ou à câmera [13], e o Chrome também os escondeu na minha verificação.
A navegação anônima impede vazamentos WebRTC?
Não. A IETF observa que um endereço privado revelado pelo WebRTC pode servir de identificador e mostrar a um site que uma janela normal e uma janela anônima estão no mesmo aparelho [1], então o modo anônimo sozinho não o esconde. Use as configurações do navegador acima e depois faça um teste de vazamento também numa janela anônima.
As extensões contra vazamento WebRTC funcionam?
Em parte. No Chrome, uma extensão pode definir a política de tratamento de IP do WebRTC do navegador, que o Google descreve como uma troca entre o desempenho da mídia e a quantidade de informação de endereço local exposta [16]. Conforme o valor, isso esconde os endereços locais ou força a mídia por um proxy, o que pode levar o áudio para TCP e reduzir a qualidade [1]. Faça um teste de vazamento depois de instalar uma delas para confirmar a mudança.
Como desativar o WebRTC no Firefox?
Digite about:config na barra de endereço, procure media.peerconnection.enabled e defina como false. O código-fonte da Mozilla descreve essa preferência como a chave do RTCPeerConnection, e desativá-la também tira das páginas o acesso à API do microfone [20]. Aí todos os discadores no navegador param de funcionar, então a maioria das pessoas que fazem ligações fica melhor com o padrão do Firefox, que já esconde os endereços locais [19].
Como impedir vazamentos do WebRTC no Chrome?
Por uma extensão ou por uma política, porque o Google documenta os controles de endereço do WebRTC no Chrome para esses dois casos. Uma extensão pode definir a política de tratamento de IP do WebRTC [16], e administradores podem definir a WebRtcIPHandling, cujo valor default_public_interface_only impede o WebRTC de usar endereços privados [17]. No meu teste no Chrome, uma página sem permissão de microfone já só via um nome .local aleatório [3]. Atrás de uma VPN, a solução de verdade é um túnel que leve todo o tráfego [1]. Qualquer coisa que bloqueie o WebRTC por completo também impede as ligações pelo navegador [14].
Um site consegue ver meu IP pelo WebRTC sem pedir permissão?
O seu endereço público, sim, mas os sites já veem esse de qualquer jeito: o Safari, por exemplo, só dá a páginas sem acesso ao microfone endereços que um site já poderia coletar [13]. O problema é um proxy no navegador. Se o acesso direto à internet é permitido, as verificações STUN do WebRTC podem contornar o proxy e revelar o seu endereço público real [1]. Os endereços locais são mais protegidos: o padrão condiciona a lista completa a um consentimento como a permissão de microfone [1], e no meu teste no Chrome uma página sem essa permissão só via um nome .local aleatório [3].
Pergunte a uma IA sobre esta pesquisa
Cada botão abre o assistente numa nova aba e pede que ele resuma esta página, com o link dela como fonte.
Fontes
- RFC 8828: WebRTC IP Address Handling Requirements · IETF (RFC Editor) · verificado em 1 de novembro de 2026
- 47 CFR 64.1601 -- Delivery requirements and privacy restrictions | eCFR · US Code of Federal Regulations (eCFR) · verificado em 1 de novembro de 2026
- Using Multicast DNS to protect privacy when exposing ICE candidates (draft-ietf-mmusic-mdns-ice-candidates) · IETF (Internet-Draft, work in progress) · verificado em 1 de novembro de 2026
- Voice call someone or a group on Messenger - Messenger Help Center (Computer) · verificado em 1 de novembro de 2026
- How to protect your IP address on WhatsApp calls | WhatsApp Help Center · WhatsApp · verificado em 1 de novembro de 2026
- RTCIceCandidate: address property - Web APIs | MDN · MDN Web Docs (Mozilla) · verificado em 1 de novembro de 2026
- RTCIceCandidate: type property - Web APIs | MDN · MDN Web Docs (Mozilla) · verificado em 1 de novembro de 2026
- Make calls | Sonetel help · verificado em 1 de novembro de 2026
- Free call | Call2Friends - Online call · verificado em 1 de novembro de 2026
- Privacy Policy | Globfone · verificado em 1 de novembro de 2026
- Voice Calls: Secure, Crystal-Clear, AI-Powered | Telegram Blog (30 March 2017) · Telegram · verificado em 1 de novembro de 2026
- Use your camera and microphone in Chrome - Computer - Google Chrome Help · Google · verificado em 1 de novembro de 2026
- A Closer Look Into WebRTC | WebKit (3 July 2017) · WebKit (Apple) · verificado em 1 de novembro de 2026
- WebRTC API - Web APIs | MDN · MDN Web Docs (Mozilla) · verificado em 1 de novembro de 2026
- WebRTC Custom Settings · brave/brave-browser Wiki · Brave Software (official GitHub wiki) · verificado em 1 de novembro de 2026
- chrome.privacy | API | Chrome for Developers · Google (Chrome for Developers) · verificado em 1 de novembro de 2026
- Chrome Enterprise policy list: WebRtcIPHandling (WebRTC IP handling) · Google (Chrome Enterprise) · verificado em 1 de novembro de 2026
- Microsoft Edge Browser Policy Documentation WebRtcLocalhostIpHandling | Microsoft Learn · Microsoft · verificado em 1 de novembro de 2026
- Firefox source: modules/libpref/init/all.js (mozilla-firefox/firefox) · Mozilla (official Firefox source repository) · verificado em 1 de novembro de 2026
- Firefox source: modules/libpref/init/StaticPrefList.yaml (mozilla-firefox/firefox) · Mozilla (official Firefox source repository) · verificado em 1 de novembro de 2026
- Terms of Use – TextNow · verificado em 1 de novembro de 2026
- Privacy Policy – Privacy & Terms – Google · Google · verificado em 1 de novembro de 2026
- Call From Your Browser Without a SIM Card - TwinPhone · verificado em 1 de novembro de 2026