Voltar ao blog

Por que o Pixelscan ainda te identifica depois de trocar de IP: consistência é o que decide

Quem opera várias contas conhece a cena: proxy novo, cookies apagados e a página de teste continua vermelha. O problema raramente é ter mudado "de menos" — quase sempre o ambiente se contradiz. O proxy diz Nova York, mas o relógio do sistema roda no horário de Berlim. Serviços de detecção modernos como o Pixelscan já não perguntam o que você alterou; eles verificam se a identidade que você declara bate com o comportamento real do dispositivo. Este artigo detalha as quatro contradições mais comuns e termina com um checklist que dá para executar hoje.

O que o Pixelscan realmente mede: de características a contradições

A lógica central do Pixelscan é uma auditoria de consistência: o ambiente do navegador é tratado como um conjunto de sinais que se confirmam mutuamente, e qualquer conflito lógico entre eles expõe a identidade falsificada por completo.

Motores antigos caçavam "características ruins": assinaturas conhecidas de automação, combinações de parâmetros desatualizadas. Trocava os valores e passava batido. Hoje a abordagem mudou: o motor cruza sinais de rede, limites de hardware e comportamento de renderização numa mesma matriz. Cada leitura isolada parece inofensiva; juntas, são matematicamente impossíveis num dispositivo genuíno.

As ferramentas irmãs dividem o trabalho: o CreepJS escava vestígios de manipulação de API, enquanto o Pixelscan foca numa pontuação geral de consistência e serve de referência para times antifraude. Para quem gerencia várias contas, a conclusão é direta: dá para preencher qualquer valor nos parâmetros, mas as relações entre eles não podem ser falsificadas.

Trocou o IP e ainda assim foi marcado: as quatro contradições mais comuns

Esses quatro pontos explicam a maioria dos casos de "configurei tudo e mesmo assim marquei". Verifique um a um e normalmente você localiza o vazamento.

  1. Fuso horário não bate com a geolocalização. O tráfego sai por um proxy de Nova York (UTC-5) e o relógio da máquina marca hora de Berlim (UTC+1) — o deslize clássico e mais tosco. Uma chamada a getTimezoneOffset entrega o fuso real do sistema, que o motor cruza com idioma do sistema, API de geolocalização e a rede do proxy (ASN). Quando a localização declarada fica longe demais da posição real do hardware, a marcação dispara.

  2. A renderização de fontes entrega o sistema operacional. Colar um User-Agent de macOS numa máquina Windows é o erro manual mais comum. O motor renderiza texto oculto num Canvas fora da tela e analisa a grade de pixels: Windows usa DirectWrite, Apple usa Core Text e Linux usa FreeType — e a disposição subpixel de cada motor está gravada no kernel. Mudar uma string de texto não engana as métricas de fonte em C++.

  3. O WebGL denuncia o "notebook falso". Celulares na nuvem e servidores virtuais sem GPU dedicada costumam desenhar a tela com rasterizadores de software como o SwiftShader. Quando o ambiente diz ser um MacBook Air e o diagnóstico lê strings de fabricante de renderização por software, a contradição fica provada na hora — nenhum notebook de consumidor desenha interface 3D com fallback de servidor.

Comparação entre o que o perfil declara e as leituras reais do ambiente

  1. O WebRTC vaza seu endereço real por fora do proxy. O tráfego das páginas passa pelo túnel, mas o WebRTC — protocolo ponto a ponto feito para chamadas — abre canal próprio. Uma única requisição ICE do avaliador pode revelar seu IP local ou da operadora, que o Pixelscan compara com o IP do proxy. Dois endereços diferentes e o proxy vira uma cortina de papel. Em uma frase: a confiança num ambiente vale tanto quanto o seu sinal contraditório mais fraco.

Três erros frequentes — a maioria tropeça no segundo

Todos são manuais: as ferramentas estão certas, a montagem é que não.

  1. Copiar e colar User-Agent. Pegou um UA de macOS num tutorial e colocou num host Windows: a string muda, o comportamento de renderização não. É se entregar sozinho.

  2. Cuidou do proxy, esqueceu do sistema. Proxy em Los Angeles, mas fuso, idioma e formatos numéricos continuam locais. Cada um desses itens contradiz o proxy.

Dois operadores conferem a consistência da configuração no painel do MakoBrowser

  1. Rodar contas valiosas em celulares na nuvem ou ambientes sem GPU. A renderização por software aparece nas leituras do WebGL. Vale para testes rápidos; carregar uma contradição conhecida em contas de longo prazo é se sabotar.

Checklist de consistência: cinco checagens antes de colocar no ar

Em vez de tentativa e erro, transforme a lista numa rotina fixa de pré-lançamento:

  1. A localização do proxy coincide com o fuso do sistema — alinhamento por cidade vale mais que por país.
  2. Idioma do sistema e formatos regionais confirmam a localização do proxy; nada de combinação "sistema em inglês + proxy brasileiro".
  3. O sistema declarado no User-Agent corresponde ao que Canvas e WebGL realmente renderizam; o ideal é o ambiente rodar nativamente nesse sistema.
  4. O WebRTC está desativado por completo ou confirmado para sair pelo proxy; dois IPs diferentes são sinal vermelho.
  5. Depois de configurar, rode uma verificação completa na página de teste e zere todas as contradições antes do uso real.

Consistência como padrão, não como tarefa manual

Equilibrar dezenas de parâmetros na mão quase garante esquecer um detalhe — por isso a consistência de fingerprint virou capacidade central dos navegadores antidetecção. O MakoBrowser embute o alinhamento no próprio ambiente: cada conta roda num perfil separado, com fingerprint, cookies, proxy, fuso e idioma gerenciados individualmente; conforme a documentação oficial, os parâmetros do ambiente se alinham em bloco aos metadados do proxy, e não um por um. Tais promessas merecem verificação com o checklist acima durante o período de teste — o resultado final é o da sua própria checagem.

Se "troquei o IP e continuei marcado" faz parte do seu dia, baixe o cliente MakoBrowser, audite seus perfis com o checklist e transforme esse fluxo de configuração em padrão.

Perguntas frequentes

Por que o Pixelscan me marca mesmo com IP residencial?

IP residencial resolve a qualidade do endereço, não as contradições internas. Qualquer conflito entre fuso, idioma do sistema, renderização de fontes ou vazamento de WebRTC com a localização do proxy será revelado pela auditoria de consistência. Rode primeiro o checklist de cinco itens — normalmente ele aponta a contradição exata.

Celulares na nuvem são mesmo mais seguros para contas?

Eles eliminam a configuração local, mas a maioria depende de renderização por software, e as leituras do WebGL expõem a ausência de GPU real — dedução clara em qualquer auditoria. Aceitável para tarefas leves; para contas valiosas de longo prazo, prefira um ambiente desktop com renderização por hardware real.

Verificar minha pontuação no Pixelscan com frequência me prejudica?

A página de teste lê os mesmos sinais que o navegador já envia; o ato de verificar não gera penalidade. O que pesa são as contradições que cada verificação revela. Use um perfil fixo e bem configurado para os testes e trate a pontuação como indicador de saúde do ambiente.