Ao abrir a página de verificação de IP e ver que o endereço mudou para a saída esperada, é fácil pensar que todas as configurações já estão em vigor. Na verdade, isso só mostra que aquela requisição web específica usou esse endereço. A resolução de domínio, a comunicação WebRTC e as requisições IPv6 podem não ter seguido o mesmo caminho.
A chave para determinar se houve vazamento de IP ou DNS não é "quantos endereços aparecem na página", mas se alguma informação ou tráfego saiu pelo caminho que você esperava proteger. O aparecimento de endereços de rede interna, DNS público ou nomes de região diferentes da saída não pode, por si só, ser considerado conclusão de vazamento.
Este artigo é adequado para verificar seu próprio dispositivo, navegador e configurações de rede. Os resultados da detecção representam apenas o ambiente observável neste momento e não devem ser interpretados como garantia de privacidade para todos os aplicativos do dispositivo.
Primeiro, determine qual tráfego você deseja proteger
Antes de começar o teste, responda a uma pergunta simples: você configurou um proxy no navegador, um proxy no sistema ou uma VPN que assume o roteamento da rede?
Suas áreas de cobertura podem ser diferentes. Extensões de navegador não necessariamente lidam com outros aplicativos; proxy no sistema não significa que todos os protocolos seguirão as configurações de proxy. Se a VPN cobre IPv6, DNS e tráfego dividido também depende da implementação e configuração específicas.
Se você intencionalmente deixou um aplicativo se conectar diretamente, ele usar a saída original não é necessariamente uma falha. Mas se sua expectativa é que "todo o tráfego de saída use a saída especificada", o mesmo fenômeno precisa de investigação adicional.
Recomenda-se primeiro manter uma linha de base: o IPv4 público, IPv6 e os resolvedores observáveis na detecção de DNS antes de ativar a configuração alvo. A linha de base é usada para comparação antes e depois e não precisa ser publicada; especialmente em redes corporativas, não se deve expor capturas de tela de endereços internos e configurações sem cuidado.
WebRTC: primeiro distinga os endereços candidatos, depois julgue se há exposição da saída
WebRTC permite que o navegador realize comunicação de áudio/vídeo em tempo real e dados. Para estabelecer a conexão, ele coleta os caminhos de rede possíveis, ou seja, os candidatos ICE.
A documentação da MDN sobre tipos de candidatos distingue tipos como host, srflx, prflx e relay. Para usuários comuns, o mais importante é distinguir entre informações de interface local, informações observadas após a tradução de endereço e o endereço do servidor de retransmissão. Se os candidatos são expostos à página da web também é afetado pela política de privacidade WebRTC do navegador.
Resultados na detecção | Interpretação mais razoável |
|---|---|
IPv4 privados como 192.168.x.x, 10.x.x.x | Podem refletir informações da rede local; não podem por si só determinar vazamento da saída pública |
Nomes .local | Podem ser o tratamento de privacidade do navegador para candidatos locais, não equivalentes ao IP público real |
Endereço público consistente com a saída esperada | Consistente com a expectativa deste teste, mas não representa que todo o tráfego foi verificado |
Endereço público confirmado como pertencente à rede original | Se deveria estar protegido, é um sinal de exposição que merece verificação cuidadosa |
Endereço de retransmissão TURN | Indica que os candidatos relacionados passam por retransmissão, não é prova direta do endereço público original do usuário |
A exposição do endereço da rede original pelo WebRTC não é imaginação. RFC 8828 discute a exposição de informações de IP em cenários de VPN dividida, múltiplas interfaces de rede e proxy de aplicativo. Mas a implementação do navegador, as permissões e as políticas de rede afetam o desempenho real; não se pode aplicar diretamente as conclusões de testes em navegadores antigos a todos os dispositivos.
Na Teste de vazamento WebRTC, se você vir um endereço público diferente do esperado, compare primeiro com a linha de base e depois verifique a qual rede ele pertence. Não tire conclusões apenas porque “um segundo endereço apareceu”, nem iguale “nenhum candidato coletado” a segurança absoluta — comunicação bloqueada ou teste incompleto também podem produzir resultados vazios.
DNS: o que significa ver o resolvedor da operadora?
Antes de o navegador acessar um domínio, normalmente ele precisa obter o endereço correspondente. O vazamento de DNS diz respeito a se essa etapa seguiu a política de resolução esperada e se alguma parte que não deveria ter contato com as informações da consulta pode ter tido acesso a elas.
Testes comuns de vazamento de DNS fazem o navegador solicitar um conjunto de domínios de teste e, em seguida, observam a origem das consultas pelo lado do DNS autoritativo. O que a página exibe geralmente é a saída na cadeia de resolução recursiva, não uma leitura direta da configuração de DNS do seu dispositivo.
Isso significa que, após detectar um endereço DNS, você não pode concluir imediatamente que “o servidor DNS local é este”. Encaminhamento recursivo, serviços de resolução públicos e implantações Anycast podem tornar o resultado mais complexo do que a tela de configurações do sistema.
Especialmente, não olhe apenas o nome do país: a geolocalização do banco de dados da saída DNS é diferente da saída da web e não é suficiente por si só para provar vazamento. É preciso verificar ainda o operador do resolvedor, a forma de roteamento do serviço e se está de acordo com seu objetivo de configuração.
Se sua expectativa é usar somente o caminho de resolução especificado pela VPN, mas o teste observa continuamente a saída de resolução da operadora de rede original, esse é um sinal que precisa ser investigado. Se você configurou ativamente um DNS público, detectá-lo em si não é necessariamente uma anomalia.
Você pode usar a Teste de vazamento DNS para comparação antes e depois. Quando aparecerem vários resolvedores, verifique primeiro se há sobreposição ou uso simultâneo entre o “DNS seguro” do navegador, o DNS do sistema operacional, o DNS da VPN e as configurações de divisão de tráfego.
Com DoH ativado, não haverá vazamento?
O DoH resolve a criptografia do transporte da consulta DNS, mas não resolve automaticamente todas as questões de roteamento e confiança. A documentação da Cloudflare explica como encapsular consultas DNS em HTTPS, mas “transporte criptografado” não significa “a consulta certamente passou pela VPN que você especificou”.
O serviço de resolução ainda processará suas consultas. Algumas implantações podem usar EDNS Client Subnet, transmitindo informações de prefixo de rede do cliente em consultas recursivas; esse mecanismo e suas implicações de privacidade são descritos na RFC 7871. Quando testes DNS comuns não fornecem explicitamente esse resultado, não presuma que já verificaram ECS.
IPv6: saída IPv4 correta não significa que o outro endereço também esteja correto
Muitas redes oferecem IPv4 e IPv6 simultaneamente. Se um proxy ou VPN tratar apenas IPv4, e o dispositivo ainda puder usar IPv6 diretamente pela rede original, os serviços de destino compatíveis com IPv6 poderão observar outro caminho de saída.
No entanto, “endereços IPv4 e IPv6 diferentes” é normal. Eles pertencem a sistemas de endereçamento distintos, e não se pode avaliar se a proteção está ativa pela semelhança textual dos endereços.
O que se deve comparar é: a afiliação de rede dos dois protocolos, se o roteamento real está conforme o esperado e se o IPv6 ainda aponta para a rede original. Mudanças no próprio endereço temporário IPv6 não indicam automaticamente vazamento.
Na Verificação do ambiente do navegador, veja separadamente as informações disponíveis de IPv4 e IPv6. Se o teste de IPv6 não for concluído, só pode ser marcado como não confirmado; isso não é a mesma conclusão que “confirmado que IPv6 está indisponível”.
Uma sequência de investigação repetível
1. Faça comparação antes e depois no mesmo dispositivo e navegador
Registre as informações de saída sem a configuração alvo ativada e depois ative a configuração e teste novamente. Durante o teste, evite trocar simultaneamente Wi-Fi, proxy do navegador e DNS, caso contrário será difícil determinar qual etapa causou a mudança.
2. Verifique separadamente página web, WebRTC, DNS e IPv6
Registre os quatro grupos de resultados separadamente: saída pública observada pela página, candidatos WebRTC, origem das consultas DNS, alcançabilidade e saída IPv6. Não use o status verde de um item para substituir os outros.
3. Localize as configurações pelo caminho anômalo
Se o WebRTC expuser o endereço público da rede original, verifique a cobertura do proxy, a política de WebRTC e se a VPN usa divisão de tráfego. Se o DNS não estiver conforme o esperado, verifique as configurações de resolução do navegador e do sistema, além do comportamento de restauração do DNS após a desconexão da VPN. Se o IPv6 ainda passar pela rede original, verifique o suporte a IPv6 da VPN e as rotas relacionadas.
Modifique apenas uma opção relevante por vez e repita o teste. Ao lidar com problemas de negócios de longo prazo, manter registro de horário, estado da configuração e resumo dos resultados geralmente é mais útil para localizar a causa do que apenas capturar um “aviso vermelho”.
4. Verifique o comportamento após reconexão
Reconexão de rede, despertar do dispositivo do modo de suspensão e reconexão da VPN podem alterar o caminho. Quando as condições permitirem, verifique novamente após esses cenários de uso normal. Passar em um teste uma única vez só prova que o comportamento observado naquele momento estava conforme o esperado, não substitui a verificação de estabilidade subsequente.
Não é recomendado desabilitar todos os recursos de imediato
Desabilitar o WebRTC diretamente pode afetar chamadas e reuniões no navegador; desligar o IPv6 diretamente também pode mascarar problemas de configuração. Fazer isso deve depender da sua necessidade real e da perda de funcionalidade aceitável, não apenas para fazer a página de teste mostrar menos linhas.
A abordagem mais segura é primeiro definir claramente o escopo de proteção e depois corrigir as configurações correspondentes de roteamento, resolução ou navegador. Dispositivos corporativos ainda devem seguir as políticas do administrador e não devem contornar por conta própria as configurações de rede e segurança estabelecidas.
Janelas anônimas podem evitar esses vazamentos?
Você não pode tratar o modo de navegação anônima como um túnel de rede. Ele altera principalmente como o histórico de navegação, cookies e outros dados de sessão locais são processados, mas não intercepta naturalmente DNS, WebRTC ou roteamento IPv6.
Se não detectamos o IP original, isso significa que estamos totalmente anônimos?
Não. O caminho do IP é apenas parte da privacidade. Login em contas, cookies, impressão digital do navegador e informações enviadas ativamente podem permitir que um serviço identifique ou associe uma visita.
Após concluir esta verificação, a conclusão razoável deve ser: "Nas configurações e condições de teste atuais, os caminhos de rede observados estão de acordo com o esperado." Isto é mais preciso do que uma afirmação sem escopo como "zero vazamentos, anonimato total", e orienta melhor o uso futuro.
Cenário de roteamento dividido: como interpretar quatro resultados diferentes no mesmo dispositivo
Suponha que você configure roteamento por domínio, ou esteja com VPN e saída direta local ao mesmo tempo. Em um teste, a saída HTTP mostra o endereço do nó proxy A, o teste DNS mostra o endereço do servidor recursivo B, os candidatos WebRTC incluem o IP público original C e um endereço TURN D, e o IPv6 ainda usa a linha da operadora. Esses resultados podem ser facilmente mal interpretados como "quatro vazamentos". Na verdade, eles podem apenas ter caminhos diferentes. A chave não é quantos IPs aparecem, mas se esses caminhos estão de acordo com o esperado.
Neste exemplo, se você deseja apenas que o tráfego HTTP da web passe pelo proxy, a saída A pode estar de acordo com a configuração; se o DNS deve ser direto, isso precisa ser confirmado separadamente. Se os candidatos WebRTC legíveis pela página incluem o IP público original C, isso já indica que a página pôde obter C neste teste, não sendo necessário que a conexão de mídia realmente o utilize para ser considerado exposto. Se isso é um vazamento indesejado, depende se você exige ocultar esse endereço da página.
Candidatos mDNS precisam ser especialmente distinguidos. Os navegadores frequentemente usam nomes .local gerados aleatoriamente para representar interfaces de rede locais, evitando expor diretamente informações reais da rede local. Ver uma entrada como "2f8c…local" na página de detecção WebRTC deve ser entendida como tratamento de privacidade para candidatos locais, não como seu IP público ou nome de host. Tratá-la como evidência de vazamento é um equívoco comum. Se ao mesmo tempo houver um endereço público original e o aplicativo deveria estar protegido pelo túnel, então é um sinal de exposição que merece verificação aprofundada.
IPv6 também deve ser registrado separadamente. Quando a saída IPv4 passa pelo proxy A, mas o IPv6 ainda usa a linha direta da operadora, sites de destino com pilha dupla podem observar seu endereço da operadora simultaneamente ou preferencialmente via IPv6. Isso não é necessariamente causado por erro na configuração do proxy; muitos clientes que usam roteamento CIDR ou proxy apenas IPv4 não assumem o roteamento IPv6 por padrão. Nesse caso, não conclua rapidamente "vazamento de IPv6"; primeiro confirme se a VPN ou proxy afirma cobrir IPv6 e depois verifique se há uma rota padrão IPv6 local apontando para o túnel.
A diferença nos servidores recursivos DNS pode ser auxiliada pelo ASN e informações RDAP. Se o endereço de B pertence a um serviço de resolução pública que você escolheu ativamente, mesmo sendo diferente da saída HTTP, é normal; se pertence à operadora original e você pretendia que o tráfego de resolução entrasse no túnel, é uma anomalia a ser investigada. Serviços de resolução implantados com Anycast podem mostrar nós diferentes em regiões diferentes, então não se pode concluir que o DNS foi direto apenas pela mudança de localização geográfica. Deve-se prestar atenção ao nome do operador, à atribuição do ASN e se o domínio de teste observa fontes de consulta inesperadas no lado autoritativo.
Ao encontrar essa coexistência de múltiplas saídas, a primeira ação não é desativar recursos, mas escrever as "expectativas". Quais aplicativos devem usar proxy e quais devem ser diretos; quem deve processar o DNS; se o IPv6 deve ser coberto pelo túnel ou permitir conexão direta; se o WebRTC pode coletar candidatos locais quando a VPN está ativa. Após concluir uma medição, compare com a linha de base. Se um item não estiver conforme o esperado, volte às configurações e ajuste um por um. Mude apenas uma variável de cada vez, por exemplo, primeiro o DNS e depois teste novamente, para determinar qual regra causou a diferença.
Medições repetidas e recuperação de desconexão: tornando os resultados de teste reproduzíveis
Passar em um teste apenas mostra que o ambiente naquele momento estava conforme o esperado. Reconexão da VPN, despertar do sistema e mudanças nas permissões do navegador podem alterar o caminho. Recomenda-se repetir a medição após cenários de uso normal: desconecte e reconecte a VPN, desperte da hibernação, alterne entre Wi-Fi e rede móvel, e verifique separadamente a saída HTTP, a origem DNS, os candidatos WebRTC e o estado IPv6. A estabilidade desses quatro resultados é mais valiosa do que um único resultado totalmente verde.
Cada medição deve manter apenas uma variável alterada. Por exemplo, se hoje você altera apenas as configurações relacionadas ao WebRTC, mantenha as configurações de DNS e VPN inalteradas; amanhã, se alterar apenas o IPv6, teste novamente todos os quatro itens. Se você ajustar simultaneamente o "DNS seguro" do navegador, o roteamento do proxy e o interruptor IPv6 do sistema, quando ocorrer comportamento intermitente será difícil rastrear qual alteração causou a mudança. Registrar horário, estado da configuração e resumo dos resultados é mais útil para manutenção a longo prazo do que uma captura de tela de aviso vermelho.
As permissões do navegador afetam diretamente os candidatos WebRTC. Se o site não tiver permissão de microfone ou câmera, o navegador pode não coletar candidatos de interface local; uma vez autorizado o áudio/vídeo, a coleta de candidatos pode se expandir. Portanto, teste o WebRTC antes e depois de conceder permissões para observar as mudanças na lista de candidatos. Não assuma que não há exposição WebRTC porque a página não mostrou candidatos sem permissão; isso é confundir "não medido" com "protegido". Da mesma forma, a janela anônima não altera o roteamento de rede e não pode ser usada como medida anti-vazamento.
O IPv6 deve ser tratado explicitamente conforme a necessidade: se você precisa de proteção completa de pilha dupla, escolha e configure um túnel com suporte a IPv6, verificando o roteamento real e o firewall; se o produto suporta apenas IPv4, confirme qual política de bloqueio ou bypass ele tem para IPv6. Apenas adicionar uma rota padrão não garante que todos os aplicativos e estados de desconexão estejam protegidos. Desativar globalmente o IPv6 também pode afetar a compatibilidade; primeiro entenda as capacidades do cliente e mantenha uma configuração reversível, depois verifique separadamente os estados normal, reconectado e desconectado.
A validação de recuperação de desconexão deve incluir a política de "kill switch". Se uma VPN afirma bloquear todo o tráfego de saída após a desconexão, teste se as consultas DNS também falham durante a interrupção da rede, em vez de voltar ao resolvedor original. Algumas implementações cortam apenas TCP IPv4, mas permitem que IPv6 ou DNS continuem pela linha original; essa "proteção parcial" deixa uma janela de observação. Isso pode ser confirmado disparando eventos de desconexão separadamente e observando o comportamento das solicitações HTTP, DNS e IPv6.
"Não encontrado" nos resultados do teste não significa "seguro". Se o IPv6 mostrar impossibilidade de conexão porque a rede não o suporta, só pode ser marcado como "não confirmado", não como "confirmado sem vazamento de IPv6". Um caminho só pode ser considerado aprovado nesta verificação se o teste foi emitido e o resultado está conforme o esperado. Cada medição deve registrar as condições do teste, como versão do navegador, modo do proxy, protocolo VPN e ambiente de rede, para permitir reprodução futura.
Em ambientes mais complexos, como quando o CGNAT pode alterar a correspondência entre a saída pública e os endereços internos, é possível consultar Como saber seu IP público e verificar se está em CGNAT para entender os níveis de NAT; e algumas ferramentas de detecção de segurança podem erroneamente relatar fenômenos normais como características de VPN ou proxy, podendo-se consultar IP detectado como VPN ou proxy: como verificar falso positivo para interpretar melhor os resultados das ferramentas. Combinando essas referências, é possível reduzir julgamentos incorretos causados pelo tipo de endereço ou pela lógica de detecção.
Por fim, organize os resultados da investigação em um registro de aceitação: se o caminho esperado está claro, se cada tipo de tráfego atende às expectativas nos três estados — normal, reconexão e desconexão — e se os itens anômalos foram localizados em configurações específicas. A conclusão assim obtida — "dentro das condições atuais e do escopo de testes, os caminhos de rede observados estão em conformidade com o esperado" — é mais valiosa do que qualquer marcador verde pontual.
