Como testar se o seu navegador está vazando (teste de 60 segundos)

Por que "eu uso proxy" não significa "eu estou protegido"

Proxy muda uma coisa só: o endereço IP que o servidor grava no log dele. Ele fica no meio do caminho entre a sua máquina e o destino e repassa os pacotes. Esse é o trabalho inteiro, e é um trabalho útil — mas cobre uma de três camadas que um detector moderno lê.

• Camada de rede. IP público, a operadora dona dele, país e cidade que ele geolocaliza e o histórico daquela faixa. É a camada que o proxy substitui.
• Camada de transporte. O handshake TLS — o primeiro pacote que o navegador manda, antes de chegar um byte de HTML. Ele carrega um fingerprint próprio, resumido em JA3 e JA4. O proxy repassa isso intacto.
• Camada de aplicação. Cabeçalhos HTTP, Client Hints e tudo que a página lê por JavaScript: canvas, WebGL, fontes, áudio, tela, fuso, idioma, hardware. O proxy nem enxerga esses dados, quanto mais altera.

O que derruba conta não é o detector "perceber um proxy". Milhões de pessoas comuns navegam atrás de rede corporativa, NAT de operadora e VPN. O que é sinalizado é contradição: um IP que geolocaliza em São Paulo enquanto o fuso do sistema diz America/New_York, o locale diz en-US e o WebGL informa uma GPU que não existe no sistema operacional que o seu user agent jura estar rodando. Isolado, nada ali é irregular. Junto, aquilo descreve um aparelho que não poderia existir.

Como testar se o seu navegador está vazando?

Quatro checagens, nesta ordem, porque cada uma cobre uma camada que a anterior não alcança. Rode o verificador de fingerprint para a superfície de JavaScript e para os cruzamentos de coerência, teste o WebRTC à parte porque ele escapa do proxy por outro caminho, confira o JA3/JA4 do seu handshake porque JavaScript não chega lá, e depois leia os quatro resultados como uma história só, não como quatro notas soltas.

Uma regra antes de começar: rode o teste duas vezes. Uma no seu navegador do dia a dia e outra dentro do perfil onde você realmente trabalha. A diferença entre os dois relatórios é o valor que a sua configuração está entregando. Sem essa base de comparação você está olhando números soltos, e uma nota bonita significa muito pouco.

Passo 1 — rode o verificador de fingerprint

Abra o verificador de fingerprint dentro do perfil que você usa para trabalhar — não nesta janela em que você está lendo. Essa diferença pesa mais do que parece: quase todo mundo testa o navegador em que navega, recebe um relatório limpo e nunca testa o ambiente onde as contas de fato vivem.

A página lê o que qualquer site lê sem pedir permissão: o objeto navigator (user agent, plataforma, fabricante, idiomas, número de núcleos, memória do dispositivo), o bloco de tela (resolução, profundidade de cor, densidade de pixel), o fuso do Intl, um hash de canvas, as strings de fabricante e renderizador do WebGL, a lista de fontes instaladas, um hash de áudio, os candidatos de WebRTC e os Client Hints que o navegador anuncia.

Anote três valores antes de seguir, porque você vai precisar deles nos próximos passos: o IP público e o país dele, o fuso informado e o hash do canvas. O resto dá para conferir na tela mesmo.

Passo 2 — leia o resultado: user agent, canvas, WebGL, fontes

A nota no topo do relatório é um resumo, não um diagnóstico. É nestes quatro blocos que moram as contradições de verdade.

User agent contra plataforma contra Client Hints

Três campos precisam contar a mesma história. A string de user agent nomeia um sistema operacional; o navigator.platform tem que bater com ele (Win32 no Windows, MacIntel no macOS, Linux x86_64 no Linux); e os cabeçalhos de Client Hints (Sec-CH-UA, Sec-CH-UA-Platform) precisam informar a mesma marca e a mesma versão principal. User agent dizendo Chrome 131 no Windows enquanto os Client Hints ficam mudos é um Chromium que teve a string editada e mais nada. Essa é a falha mais comum em configuração caseira, e ela está destrinchada em por que trocar a string não engana ninguém.

Canvas: o que você quer é estável, não bloqueado

O instinto é querer o canvas "bloqueado". Alvo errado. Recarregue o verificador três vezes e observe o hash. Dentro de um mesmo perfil ele tem que ser idêntico nas três recargas e diferente do hash dos outros perfis. Hash que muda a cada leitura significa que a ferramenta está injetando ruído aleatório novo em toda chamada — e máquina física nenhuma se comporta assim. A instabilidade vira uma assinatura por conta própria.

WebGL: uma GPU plausível para o sistema declarado

O verificador lê as strings de fabricante e renderizador sem máscara. O que importa é se aquela GPU poderia existir na plataforma que você está declarando. Uma string no formato ANGLE (Intel, Intel(R) UHD Graphics ... Direct3D11 ...) é Windows — Direct3D não existe no macOS nem no Linux. Um Mac com chip Apple informa GPU Apple. llvmpipeou um renderizador Mesa por software grita "máquina virtual sem GPU" alto o bastante para algumas plataformas tratarem isso como sinal sozinho.

Fontes: o sistema se entrega

Enumeração de fontes é um dos vetores mais antigos e mais estáveis de fingerprint, e um dos mais fáceis de errar. Perfil Windows sem Segoe UI nem Calibri, perfil macOS sem Helvetica Neue, ou perfil que se diz macOS listando fontes que só vêm no Windows: cada um desses é uma contradição que não custa nada para o site detectar.

Passo 3 — teste o WebRTC separadamente

O WebRTC merece um passo só dele porque não anda pela mesma estrada do tráfego da página. Ele negocia uma conexão ponto a ponto por UDP, com descoberta de endereço própria, e um proxy HTTP ou SOCKS configurado no navegador não carrega isso automaticamente.

O mecanismo é simples. O RTCPeerConnectionpergunta a um servidor STUN "de qual endereço eu pareço estar vindo?". A resposta volta como um candidato server-reflexive. Se aquele pacote UDP saiu pela sua placa de rede de verdade, o candidato carrega o seu IP público real — enquanto a página foi carregada pelo proxy. A página e a conexão ponto a ponto discordam, e o site vê as duas.

Rode o teste de vazamento de WebRTC e só depois decida o tratamento. Existem cinco modos comuns, e eles não são intercambiáveis: bloquear (nenhum candidato é coletado), falsificar (um endereço sintético coerente com o proxy), real (passa intacto — só está certo se o seu proxy realmente carregar UDP), encaminhar (leva a conexão ponto a ponto pelo proxy) e desabilitar UDP (força a negociação por TCP). O confronto completo entre eles está no mergulho sobre vazamento de WebRTC.

Passo 4 — confira o JA3/JA4 do seu handshake

Antes de qualquer HTML, antes de qualquer cabeçalho, antes de existir JavaScript, o seu navegador abre a conexão com um ClientHello de TLS. Essa mensagem lista a versão do TLS, as suítes de cifra que ele aceita e em que ordem, as extensões, as curvas elípticas suportadas e os protocolos de ALPN. Cada navegador monta essa lista de um jeito, e a lista é um fingerprint.

O JA3 resume esses campos na ordem em que aparecem. Funcionou bem até o Chrome passar a embaralhar a ordem das extensões de TLS a partir da versão 110, o que faz o JA3 de um Chrome legítimo mudar de conexão para conexão — barulhento sozinho, ainda útil no agregado.

O JA4 é o sucessor e corrige exatamente isso. Ele ordena as listas de cifras e extensões antes de resumir, então o embaralhamento deixa de importar, e mantém um prefixo legível em vez de um hash opaco: um fingerprint como t13d1516h2_... se lê como TLS sobre TCP, TLS 1.3, 15 suítes de cifra, 16 extensões, ALPN fechado em HTTP/2. Dois desses campos sozinhos já separam famílias de navegador.

O que você procura é concordância: o JA4 que o seu handshake produz tem que ser o mesmo que um Chrome real da versão declarada no seu user agent produz. Navegador que diz Chrome 131 na string e emite um handshake que não pertence a nenhum Chrome lançado está descrevendo um aparelho inexistente.

O que é normal vazar e o que não é

Nem todo valor visível é problema. Tentar esconder todos cria um perfil mais raro do que simplesmente deixá-los quietos. Use esta tabela como chave de leitura do seu relatório:

O que fazer se o teste vier ruim

Corrija na ordem do estrago e uma coisa por vez. A tentação depois de um relatório ruim é mexer em seis configurações de uma vez, rodar de novo e ver verde — e aí você não faz ideia de qual mudança resolveu, nem se alguma delas piorou outra coisa.

• IP real exposto pelo WebRTC. Prioridade máxima, porque anula o proxy inteiro. Defina o modo de WebRTC no perfil e teste de novo.
• Fuso ou locale brigando com o país do IP. Barato de corrigir, caro de ignorar — é a contradição que as checagens automáticas pegam primeiro.
• User agent, plataforma e Client Hints fora de sintonia. Mude os três como conjunto, nunca a string sozinha.
• Hash de canvas ou de áudio instável. O que você quer é semente fixa por perfil, não aleatoriedade nova a cada chamada.
• Handshake TLS que não bate com navegador real nenhum. O mais difícil de resolver por configuração, porque é propriedade do binário do navegador, não de uma chave que se marca na tela.

Se você quiser rodar essa mesma sequência num ambiente feito para isso, a versão desktop do AlterAntiX é gratuita e todo perfil abre numa página interna de diagnóstico que roda essas checagens antes de você navegar para qualquer lugar. Baixe aqui e compare os dois relatórios lado a lado: o seu navegador normal contra um perfil isolado. Essa comparação é o teste honesto, e ela leva cerca de um minuto.