Teste de Anonimato de Proxy: Verificador de Vazamento VPN

Porque as duas afirmações vêm de camadas diferentes e apenas uma delas pode ser falsificada no navegador. O User-Agent é uma cadeia de texto que qualquer navegador ou extensão pode reescrever. O pacote TCP SYN que abre a conexão é construído pelo kernel do sistema operacional, e a ordem de suas opções, a escala de janela e o comportamento dos carimbos de data/hora diferem entre Linux, Windows e Apple. Dispositivos Apple enviam opções TCP na ordem MSS, NOP, WS, NOP, NOP, TS, SACK_PERM, EOL. O Linux envia MSS, SACK_PERM, TS, NOP, WS. Se o seu navegador declara iOS, mas a assinatura do kernel é Linux, a conexão TCP que recebemos não foi aberta pelo seu telefone: foi reconstruída por outra máquina, quase sempre um servidor proxy ou um nó de borda de CDN.

💡 Para verificar a integridade de hardware e Canvas do seu dispositivo, use o Teste de Impressão Digital.

O tamanho máximo de segmento (MSS) anunciado no pacote SYN permite deduzir a MTU do caminho: a MTU é igual ao MSS mais 40 bytes no IPv4 e mais 60 bytes no IPv6. Diferentes tipos de enlace possuem valores característicos: a banda larga doméstica via PPPoE é 1492; as operadoras móveis costumam ficar entre 1400 e 1430; os túneis WireGuard usam 1420 por padrão; e Ethernet pura —na prática, uma máquina em data center— é 1500. Portanto, um telefone celular reportando 1500 é uma contradição evidente: nenhum enlace móvel entrega esse valor. Em um computador desktop o mesmo número é menos conclusivo, pois redes corporativas e fibra sem PPPoE também chegam a 1500, razão pela qual atribuímos um peso muito menor.

💡 Em caso de suspeita de desvios de rota no proxy, teste múltiplos pontos finais com o Teste de Split Tunnel.

Porque a reputação de IP e o comportamento do protocolo são independentes. Comprar um IP residencial altera o que os bancos de dados dizem sobre seu endereço, mas não altera como a máquina de saída constrói os pacotes. Se essa máquina for um servidor Linux, ela continuará enviando opções TCP do Linux, anunciando uma MTU de data center e finalizando o TLS com sua própria impressão digital. Um sistema de risco que olha apenas para listas de IP verá um endereço residencial limpo; um sistema que inspeciona a pilha de protocolos verá um servidor. Este é o ponto cego mais comum, e é por isso que o relatório separa evidências comprovadas pelo protocolo daquelas que vêm apenas da reputação do endereço.

💡 Verifique informações detalhadas de ASN e score de risco na Página Inicial do MyIPDNS.

Significa que não encontramos contradições nas camadas de protocolo e estamos dependendo do que os bancos de dados dizem sobre sua saída. Isso acontece quando seu próprio dispositivo e o servidor proxy utilizam a mesma família de sistema operacional. Um desktop Linux atrás de um proxy Linux produz uma assinatura homogênea, deixando a análise entre camadas sem pontos de comparação. Exibimos o veredito com total transparência: evidências rotuladas como "protocol" foram comprovadas a partir de pacotes reais, enquanto evidências rotuladas como "reputation" não foram. Um veredito de baixa confiança baseado apenas em reputação deve ser lido como um indício, não como prova definitiva.

💡 Desenvolvedores podem obter dados estruturados através da nossa API Gratuita de IP.

Alguns sinais são de configuração e outros são fatos físicos. Uma MTU de data center pode ser atenuada configurando a MTU da interface do túnel no seu servidor entre 1420 e 1450, fazendo o caminho parecer um túnel comum de usuário. Deslocamentos compartilhados de carimbo de data/hora TCP desaparecem quando o host de saída usa um kernel que gera um deslocamento aleatório para cada conexão em vez de calculá-lo por par de endereços. Já a divergência entre o sistema operacional de saída e o declarado pelo navegador não pode ser corrigida por configurações do cliente: ela só desaparece se o host de saída rodar a mesma família de sistema ou se as opções SYN forem reescritas na saída. Nenhuma extensão de navegador pode mudar isso, pois nada disso é gerado pelo navegador.

💡 Após ajustar as configurações, volte à Página Inicial para refazer o diagnóstico.

Não. Todas as inferências descritas aqui baseiam-se exclusivamente nos pacotes que chegam às nossas sondas, os quais contêm apenas seu endereço de saída. Frequentemente podemos identificar se uma conexão foi reconstruída no caminho e descrever propriedades da máquina intermediária, mas o endereço do dispositivo original não está presente nesse tráfego e não pode ser recuperado a partir dele. Separadamente, testes de WebRTC e DNS deste site podem revelar um endereço local se o seu navegador ou resolvedor sofrerem vazamentos — este é um mecanismo separado e reportado isoladamente.

💡 Para diagnósticos de divergência de rotas e DNS, consulte o Diagnóstico de Vazamento de Rota.