Teste Avançado de Vazamento de IP e DNS: Verifique sua Segurança

Muitos usuários acreditam que comprar um "proxy residencial" é suficiente para mascarar completamente a conexão como um usuário doméstico real. No entanto, motores modernos de detecção de fraudes não olham apenas tags estáticas em bancos de dados GeoIP (como IP2Location ou MaxMind). Mesmo que o IP pertença a um provedor residencial, o nó de encaminhamento geralmente roda em um servidor Linux na nuvem, criando contradições evidentes entre camadas: primeiro, a assinatura da pilha TCP na camada de transporte — o servidor de saída envia na primeira etapa SYN a ordem de opções padrão do Linux (MSS, SACK_PERM, TS, NOP, WS), e não a ordem específica do Windows ou Apple. Segundo, a MTU do caminho: a banda larga doméstica via PPPoE costuma ter MTU 1492 (e redes móveis de 1400 a 1430), enquanto redes físicas de data centers usam MTU padrão de 1500 (MSS=1460). Quando um sistema de risco detecta um IP residencial associado a uma MTU de data center e pilha TCP de Linux, a conexão é identificada como proxy automatizado.

💡 Para verificar a terminação TCP da sua conexão, use nosso Teste de Anonimato de Proxy.

O endereço IP em si não armazena dados físicos de latitude e longitude. A localização exibida depende da base de dados comercial de GeoIP utilizada e de seu ciclo de atualização: primeiro, divergência de modelos e fontes de dados — provedores como MaxMind, IP2Location e DB-IP analisam anúncios BGP, registros Whois e sondagens de latência com pesos diferentes e ciclos de atualização que variam de dias a meses. Segundo, roteamento Anycast e nós de borda de CDN — redes como a Cloudflare anunciam as mesmas faixas de IP a partir de centenas de data centers globais, roteando para a borda mais próxima. Terceiro, realocação transfronteiriça de blocos de IP — quando blocos são transferidos entre países, bases desatualizadas continuam exibindo a localização antiga. Nosso site combina a consulta a múltiplos bancos com trilateração por velocidade da luz (RTT) para estimar a localização física real.

O Score de Fraude de IP (ou Score de Risco) é um índice numérico (geralmente de 0 a 100) que quantifica a probabilidade de uma conexão ser um bot, crawler malicioso ou tráfego fraudulento. Os principais fatores de cálculo incluem: primeiro, reputação histórica e listas negras — histórico nas últimas 24 a 72 horas envolvido em ataques de força bruta, scraping excessivo, envio de spam ou varredura de portas. Segundo, tipo de ASN e infraestrutura — IPs de data center (hosting) e faixas conhecidas de proxies públicos ou VPNs possuem risco basal muito maior do que conexões residenciais ou móveis. Terceiro, consistência multiponto e de protocolos — separação de saídas IPv4/IPv6 em uma mesma sessão, divergência geográfica de DNS ou exposição de IP local via WebRTC.

💡 Para identificar vazamentos de rota que elevam seu score de risco, faça o Teste de Split Tunnel.

Mesmo com VPN ou proxy ativo, a identidade real pode vazar por canais laterais: primeiro, vazamento de DNS — quando o navegador resolve domínios, se o cliente proxy não interceptar adequadamente as requisições no nível do sistema operacional, consultas em texto claro serão enviadas diretamente ao servidor DNS do seu provedor local (ISP), revelando os domínios visitados e sua localização real. Segundo, vazamento de WebRTC — o WebRTC é um protocolo de comunicação em tempo real que, para estabelecer conexões P2P, envia pacotes STUN via UDP contornando proxies HTTP/SOCKS comuns e expondo IPs locais e públicos reais da interface. Nossa página inicial diagnostica em tempo real a saída DNS e o status do WebRTC.

💡 Para testar a integridade de hardware em Canvas, Áudio e WebRTC, acesse o Teste de Impressão Digital.

O painel de pilha de rede da página inicial executa três sondas relacionadas em paralelo: uma consulta um domínio com apenas registros A (iptestv4.myipdns.com), outra consulta um domínio com apenas registros AAAA (iptestv6.myipdns.com) e a terceira atinge um domínio de pilha dupla com ambas as famílias de registros. As duas primeiras são mandatórias: cada nome resolve exclusivamente para uma única família de endereços, sem deixar alternativa ao seu sistema, permitindo aferir independentemente suas saídas reais em IPv4 e IPv6. A terceira sonda não força o destino; pelo contrário, observa qual família de endereços seu próprio sistema escolheu, o que é exibido na coluna «Protocolo preferido»: esse desfecho é determinado pelas políticas de seleção de endereços do sistema operacional e do navegador (Happy Eyeballs, RFC 8305: havendo ambas as pilhas disponíveis, tenta-se IPv6 primeiro, usando IPv4 apenas como contingência), sem qualquer imposição nossa. Exibir as três em conjunto é vital porque muitos clientes proxy e VPN tunelam exclusivamente IPv4: se sua saída IPv4 reside no ASN do proxy enquanto sua saída IPv6 permanece na operadora de banda larga e o protocolo preferido exibe IPv6, ao navegar em sites de pilha dupla a maior parte do seu tráfego não passa pelo túnel — essa é a forma mais recorrente de «VPN ativada mas identidade real exposta», sem emitir qualquer aviso de falha.

⚠ Podemos unicamente informar se as saídas de ambas as famílias terminam em redes distintas; não podemos julgar como seu software de proxy deve ser configurado. O inverso também é verdadeiro: constar IPv6 como indisponível não equivale a segurança; pode indicar apenas ausência de IPv6 na sua rede ou que o proxy desativou o IPv6 por completo — sendo esta última, com frequência, a conduta recomendada.

Não lemos as configurações locais do seu sistema: os navegadores não têm permissão técnica para acessá-las, e qualquer página que alegue ler suas definições locais de DNS está meramente adivinhando. O procedimento real baseia-se em testar pelo caminho inverso: nosso site opera seu próprio servidor DNS autoritativo e gera, para cada verificação, um subdomínio aleatório transitório (como k3f9x2ab.leakv4.myipdns.com) para resolução pelo seu navegador. Esse nome surge uma única vez no mundo e jamais existirá em cache algum; logo, sua cadeia de resolução recursiva precisa consultar obrigatoriamente nosso servidor autoritativo; nós anotamos quem efetuou a consulta e retornamos esse endereço à página. Dessa forma, a coluna «Saída DNS» reflete o endereço de rede de saída real do seu resolvedor recursivo, e não o endereço registrado nas configurações do seu sistema: se você definir 8.8.8.8, quem nos consultará será uma máquina específica desse cluster, a qual pode perfeitamente residir em outro país; grandes resolvedores públicos operam sob anycast e estruturas em cluster, de modo que é perfeitamente normal surgirem múltiplos endereços distintos em um mesmo teste. O critério determinante não é a coincidência exata de endereços, mas sim: se essa saída recai na rede da sua própria operadora de banda larga enquanto seu IP de navegação transita pelo proxy, isso comprova que o DNS não acompanhou o túnel.

⚠ Este método enxerga unicamente quem realizou consultas ao nosso próprio servidor autoritativo; não vemos nem temos como monitorar outros domínios acessados por você. Há também uma limitação conhecida: caso seu proxy também intercepte as requisições de DNS, visualizaremos o resolvedor da provedora do proxy — confirmando a ausência de vazamento para a operadora local, porém suas consultas permanecem visíveis para a provedora do proxy; essa é uma questão à parte que nossa ferramenta não diagnostica.

Por intermédio do WebRTC, sondas individuais são despachadas a múltiplos servidores STUN para coletar os candidatos srflx retornados — isto é, o endereço IP público e a porta efetivamente observados pelo servidor remoto após a tradução por NAT. Há um critério decisivo exclusivo: os candidatos são agrupados pelo IP público traduzido; se sob o mesmo IP surgirem duas ou mais portas distintas, classifica-se como NAT simétrico (atribui uma nova porta externa para cada novo destino); caso contrário, classifica-se como NAT cônico (mapeia invariavelmente a mesma porta interna para a mesma porta pública externa). Agrupar os candidatos antes de confrontar as portas é um cuidado deliberado: em ambientes de proxy com divisão de tráfego, servidores STUN distintos podem utilizar rotas de saída divergentes, gerando portas diferentes; contudo, isso decorre de diferenças de percurso e não do comportamento do NAT — sem esse agrupamento, todos esses cenários seriam incorretamente rotulados como simétricos. A exibição do estado «Desconhecido» decorre de duas razões: primeiro, ausência de qualquer candidato srflx dentro do tempo limite de 4 segundos (WebRTC desativado no navegador, bloqueado por extensões ou tráfego UDP de saída filtrado); segundo, recepção de apenas um candidato cujo IP público não coincide com o IP de acesso a este site, tornando impossível distinguir desduplicação do navegador de divisão de rotas; nesses casos, optamos por exibir desconhecido.

⚠ Esclarecimento honesto: nós diferenciamos estritamente as categorias NAT cônico e simétrico, sem subcategorizar em cônico total, restrito ou restrito por porta. A classificação em quatro categorias da RFC 3489 exige controlar ativamente combinações de portas de origem e destinos em sondagens sucessivas, e o WebRTC no navegador não concede tal controle; quando utilitários web informam uma dessas quatro categorias, geralmente apenas reetiquetaram esses dois desfechos.

Uma única checagem na página inicial despacha em paralelo seis sondas direcionadas a domínios distintos: uma estritamente IPv4, uma estritamente IPv6, duas encarregadas de coletar impressões digitais de pilha de rede em IPv4 e IPv6 respectivamente, uma voltada a um domínio de pilha dupla para aferir a família priorizada pelo seu sistema e uma forçada exclusivamente via HTTP/1.1. Não se tratam de requisições repetidas; cada sonda captura parâmetros completamente distintos. Seu envio segregado é indispensável porque nossa análise fundamenta-se na correlação entre camadas: um mesmo dispositivo expõe assinaturas de pilha diferentes sob IPv4 frente a IPv6 e sob HTTP/1.1 frente a HTTP/2 (e HTTP/3, quando suportado), as quais só podem ser confrontadas após coleta individual. Ademais, o paralelismo não visa apenas agilidade: se processadas de forma sequencial, uma alternância temporária de rede, chaveamento de proxy ou reconexão de túnel consolidaria registros referentes a uma máquina híbrida inexistente; a emissão paralela assegura que todas as seis sondas examinem a mesma rota no mesmíssimo instante. Entre elas, a sonda HTTP/1.1 dispara deliberadamente apenas uma requisição — o HTTP/1.1 não utiliza tabela dinâmica HPACK, de modo que chamadas adicionais não agregam entropia, enquanto uma requisição única assegura que os cabeçalhos correspondam estritamente ao mesmo registro.

⚠ O ônus dessa abordagem é a conexão simultânea a vários subdomínios logo na abertura, o que bloqueadores de anúncios ou extensões rigorosas de privacidade podem eventualmente barrar. Sob tais condições, o indicador correspondente exibirá um ponto cinza no estado desconhecido; jamais aproveitaremos dados de outras sondas para forjar um resultado aparentemente íntegro.