Como verificar a impressão digital do navegador: auditoria passo a passo do perfil e busca por inconsistências críticas

A impressão digital do navegador (browser fingerprint) não é uma única linha de User-Agent e nem apenas um endereço IP. É uma combinação de sinais de rede, HTTP e JavaScript: IP / GEO / ASN, DNS, WebRTC, timezone, language / locale, screen resolution, Canvas fingerprint, WebGL fingerprint, AudioContext, fonts, Client Hints e indicadores de automação como navigator.webdriver. Um site não analisa esses dados separadamente: ele os compara entre si e avalia se o perfil parece íntegro e plausível.

Por isso, verificar a impressão digital do navegador não é “rodar um checker e ver um selo verde”. Uma auditoria normal é um workflow curto: primeiro a rede, depois o browser environment, depois a consistency, e só então — as correções. O BrowserLeaks é forte em diagnósticos modulares profundos, o Pixelscan é bom para um relatório rápido all-in-one de consistency, o AmIUnique é útil para uniqueness/history, e o Cover Your Tracks mostra a camada de privacy e tracking e explica por que quase sempre um único teste não é suficiente.

Abaixo está uma ordem prática de verificação que é conveniente executar antes da primeira inicialização do perfil e antes do aquecimento da conta. O principal objetivo dessa auditoria não é “100% de anonimato”, mas eliminar inconsistências grosseiras (mismatch / consistency issue), que são as primeiras a chamar a atenção de serviços e sites. A EFF destaca separadamente que não existe proteção perfeita, e que algumas “melhorias de privacidade” podem tornar o navegador ainda mais destacável.

Resposta curta em 5 pontos

1. Primeiro verifique a rede: IP, GEO, ASN, DNS e WebRTC. Se houver leak ou mismatch aqui, verificar Canvas/WebGL ainda é secundário.
2. Depois verifique a consistency: User-Agent, Client Hints, OS, timezone, language / locale e screen. Hoje, só o User-Agent já não basta, porque os navegadores reduzem o UA e entregam parte dos detalhes via Client Hints.
3. Em seguida olhe para os sinais high-entropy: Canvas, WebGL, fonts e AudioContext. Observe não apenas a “unicidade”, mas também se o perfil parece quebrado ou excessivamente mascarado.
4. Verifique separadamente os red flags de automation/headless: navigator.webdriver, CDP, indicadores de Headless e um Navigator “enganado” muitas vezes são mais importantes do que um hash Canvas raro.
5. Após qualquer alteração, rode a auditoria novamente: um resultado verde em um serviço não equivale a um “perfil ideal” em outro.

O que é uma impressão digital do navegador e por que um único teste não basta

Se você precisa da base teórica, veja separadamente o material sobre o que são impressões digitais. Abaixo está especificamente uma abordagem operacional: como interpretar os sinais e o que corrigir primeiro.

Browser fingerprint vs cookie vs IP

Cookie são dados que o site armazena no navegador. Eles podem ser apagados, limitados ou bloqueados. Fingerprint é um conjunto de características do navegador e do dispositivo que o site coleta a partir de headers, JavaScript e Web APIs. A EFF separa explicitamente cookie tracking e browser fingerprinting como dois mecanismos diferentes: cookies “somem” quando o usuário os apaga, enquanto o fingerprint se apoia em sinais mais estáveis, como configurações, idioma, fontes, tela e hardware.

IP também não deve ser confundido com fingerprint. O IP é um endereço de rede, não a identidade digital completa do perfil. Além disso, a geolocalização por IP é aproximada: a MaxMind recomenda olhar o accuracy radius em vez de tratar o GEO em nível de cidade como um ponto exato no mapa. Separadamente, existe a Geolocation API do navegador: ela funciona por meio de navigator.geolocation, exige permissão do usuário e pode usar sinais mais precisos do dispositivo, incluindo GPS ou Wi-Fi.

Por que não importa só a unicidade, mas também a consistency

Para uma auditoria prática, não importa apenas o quão único é o perfil, mas também o quão consistente ele é. O Pixelscan descreve diretamente sua verificação como uma análise de consistency e detectability: ele observa User-Agent integrity, OS consistency, hardware parameters, timezone/language alignment e automation indicators. Um perfil pode não ser o mais raro, mas ainda assim falhar por causa de contradições internas.

A situação fica ainda mais complicada por causa da User-Agent reduction. A MDN escreve que os navegadores compatíveis removem do UA a versão exata da plataforma/OS, o modelo do dispositivo e a versão minor do navegador, enquanto dados mais detalhados são entregues por meio de Sec-CH-UA-* Client Hints. Por isso, hoje é preciso verificar não apenas um User-Agent, mas o conjunto User-Agent + Client Hints + sinais de JavaScript.

Quais sinais os sites comparam entre si

Na prática, os sites combinam headers HTTP comuns (User-Agent, Accept-Language), sinais de JavaScript (navigator.language, navigator.languages, timezone via Intl.DateTimeFormat().resolvedOptions()), screen resolution, rendering Canvas/WebGL, AudioContext, fonts, WebRTC IP, permissões/dados de geolocalização, além de automation indicators como navigator.webdriver. AmIUnique, BrowserLeaks, Cover Your Tracks e BrowserScan verificam essas camadas com profundidades diferentes, mas o conjunto de entidades analisadas por eles se sobrepõe bastante.

Auditoria rápida em 5 minutos: em que ordem verificar o perfil

Abaixo está a ordem básica que entrega o máximo de utilidade com o mínimo de tempo. A ideia é não gastar 20 minutos com Canvas se o seu DNS já está vazando no primeiro passo.

Etapa 1. Verifique IP, GEO, ASN, DNS e WebRTC

Comece pela camada de IP. Na página de IP do BrowserLeaks, você vê imediatamente o IP, country/state/city, ISP, organization, ASN/network, usage type, timezone e, abaixo, blocos de WebRTC, DNS, TCP/IP, TLS e HTTP/2. É uma forma rápida de entender que história a própria rede está contando sobre você, e não a interface do navegador.

Depois, olhe para DNS e WebRTC. O BrowserLeaks explica que um DNS leak acontece quando, por configuração incorreta de rede ou por um VPN/proxy problemático, as consultas DNS vão diretamente para os servidores DNS do provedor. O teste de WebRTC dele, por sua vez, mostra se as requisições STUN expõem seu IP local/público. O Whoer também coloca isso no centro da verificação: o serviço compara o país do IP com DNS, time zone/locale e sinais de tunneling. Para esta etapa, é conveniente usar o BrowserLeaks checker, o Whoer checker e a análise separada sobre WebRTC leaks.

Não confunda IP GEO com geolocalização do navegador. A localização por IP vem de uma base GeoIP e continua sendo aproximada, enquanto a Geolocation API é um mecanismo separado que pede permissão e pode usar sinais mais precisos do dispositivo. Então, uma cidade estranha pelo IP ainda não é sentença, mas uma divergência entre país, ASN, fuso horário e rota de DNS já é motivo para correções.

Etapa 2. Verifique User-Agent, OS, timezone, language, screen

A próxima camada é a verificação do browser environment: User-Agent, OS/platform, timezone, language / locale e screen resolution. Aqui é importante lembrar da UA reduction: a MDN mostra separadamente que os UA strings modernos podem parecer generalizados, e parte dos detalhes migra para os hints Sec-CH-UA-*. O teste de Client Hints do BrowserLeaks ajuda justamente a ver o que é exposto via HTTP e JavaScript API.

Compare entre si User-Agent, navigator.platform, Client Hints, Intl.DateTimeFormat().resolvedOptions().timeZone, navigator.language / navigator.languages e Accept-Language. A MDN aponta que navigator.languages e Accept-Language normalmente refletem o mesmo conjunto de locais, enquanto resolvedOptions() retorna o time zone atual do usuário. Se o UA diz “Windows”, mas a platform e os high-entropy hints apontam para macOS, ou se idioma e timezone claramente não combinam com a região do IP, isso já é uma inconsistência real, não “cosmética”.

Observe também a atualidade do núcleo do navegador. A Multilogin observa diretamente que um browser core desatualizado faz o perfil se destacar, e que um mismatch entre a versão do navegador e o OS emulado pode gerar warnings. Por isso, após qualquer atualização de engine ou edição manual do UA, é melhor repetir esta etapa.

Etapa 3. Verifique Canvas, WebGL, fonts, AudioContext

Agora passe para os sinais high-entropy: Canvas fingerprint, WebGL fingerprint, fonts e AudioContext. O BrowserLeaks mostra como o Canvas é formado a partir de diferenças de rendering e como o WebGL revela dados de GPU/renderer. O AmIUnique coleta Canvas, WebGL, audio info, fonts, screen e outros sinais justamente para avaliar a identificabilidade do navegador.

Mas aqui, não é só a “raridade” que importa. A EFF alerta que, se você alterar um elemento do fingerprint isoladamente, pode tornar o navegador não menos, mas mais perceptível, porque as métricas estão fortemente ligadas. A Multilogin dá uma recomendação semelhante: alterar profundamente as fingerprint settings só vale a pena se você entende o que está fazendo. Para contexto sobre essa camada, é útil um material separado sobre Canvas fingerprinting.

Etapa 4. Observe os red flags de automation/headless

Se o perfil é usado com automação ou simplesmente parece automatizado, execute uma camada separada de bot-detection. A MDN descreve navigator.webdriver como um sinal padrão de que o document é controlado por WebDriver; no Chrome, ele se torna true se --enable-automation ou --headless for usado. O BrowserScan ainda verifica WebDriver, CDP, Headless Chrome e deceptive Navigator, enquanto o Pixelscan destaca automation indicators em um bloco separado.

Na prática, isso significa uma coisa: corrija primeiro os problemas de rede, depois os automation flags, e só depois se preocupe com métricas bonitas de uniqueness. Na maioria das verificações reais, um site vai tropeçar antes em webdriver, em um DNS leak ou em um UA/OS mismatch do que no fato de o seu hash Canvas simplesmente “não ser como o de todo mundo”. Essa é a conclusão prática baseada em como os serviços classificam e destacam problemas.

Etapa 5. Repita o teste após as alterações

Após cada correção, rode a auditoria novamente na mesma ordem: network → fingerprint → consistency → fixes. Isso não é mera formalidade. A MDN observa que Client Hints podem ser solicitados via Accept-CH e depois armazenados para a sessão de navegação atual de um origin específico. Além disso, o Cover Your Tracks e o AmIUnique usam research cookies para vincular visitas repetidas e estudar como o fingerprint muda ao longo do tempo. Portanto, é melhor repetir o teste após reiniciar o perfil e, se necessário, em um clean environment.

Quais serviços usar para verificar a impressão digital do navegador

Um único serviço não equivale a uma verificação completa. Uma auditoria normal costuma combinar no mínimo dois tipos de ferramentas: uma orientada à rede e outra orientada à consistency. O BrowserLeaks fornece módulos de baixo nível, o Pixelscan fornece um relatório único de consistency, o AmIUnique foca em uniqueness/history, o Cover Your Tracks oferece uma visão tracker/privacy, e o iphey, Whoer e BrowserScan funcionam bem como camadas rápidas adicionais.

Tabela 1. Comparação dos serviços

BrowserLeaks — para diagnóstico modular profundo

O BrowserLeaks é a melhor primeira escolha quando você precisa entender em qual camada exatamente o perfil está falhando: network, JavaScript, rendering ou transport. Ele mostra IP/GEO/ASN/usage type, DNS, WebRTC, Canvas, WebGL, fonts, Client Hints e até fingerprints de TLS/HTTP2/TCP/IP. Se você precisa do mesmo cenário dentro do ecossistema Undetectable, comece pelo BrowserLeaks checker.

Pixelscan — para uma auditoria rápida all-in-one

O Pixelscan é conveniente como um quick first pass ou como uma segunda análise depois do BrowserLeaks. Em seu próprio manifest, o serviço diz que analisa user-agent integrity, operating system consistency, sinais de Canvas/WebGL e rendering, hardware parameters, timezone/language alignment, comportamento de proxy/DNS e automation indicators; mismatches como “Windows UA, mas sinais de macOS” são destacados imediatamente. Para esse cenário, use o Pixelscan checker.

AmIUnique — para avaliar a unicidade e o histórico do fingerprint

O AmIUnique é necessário quando a pergunta é “o quanto sou identificável?” e não “por que meu DNS está vazando?”. O projeto estuda a diversidade dos browser fingerprints, coleta um amplo conjunto de headers e sinais de JS e vincula visitas repetidas por meio de um research cookie para mostrar o histórico das mudanças do fingerprint ao longo do tempo. Para acesso rápido, mantenha à mão o AmIUnique checker.

Cover Your Tracks (antigo Panopticlick) — para education sobre privacy/fingerprint

Cover Your Tracks é o nome atual do histórico serviço Panopticlick: a EFF o renomeou em 2020 e mudou o foco de uma simples demonstração de que “fingerprinting existe” para uma explicação mais clara dos trade-offs entre tracking e privacy. O serviço mostra como os trackers veem o navegador e, na visualização detalhada, revela métricas como System Fonts, Language e AudioContext. Para executá-lo dentro do Undetectable, use o Panopticlick / Cover Your Tracks checker.

Além disso: iphey, Whoer, BrowserScan

Entre as ferramentas adicionais, mantenha por perto o iphey checker, caso precise de um quick heuristic score de “trustworthy / suspicious / unreliable” com base em browser, location, IP, hardware e software, e o Whoer checker, se precisar de uma verificação instantânea de IP/DNS/privacy com comparação de time zone e locale. O BrowserScan é útil como uma camada separada de bot-detection: ele analisa WebDriver, CDP, Headless Chrome e deceptive Navigator properties.

Como ler os resultados: quais red flags são realmente críticos

Abaixo está uma hierarquia prática de problemas. Trata-se de um esquema editorial de trabalho derivado do que BrowserLeaks, Pixelscan, AmIUnique, Cover Your Tracks, Whoer e as recomendações da Multilogin realmente destacam: primeiro corrigir o que quebra a consistency e a confiança da rede, e não aquilo que apenas aumenta o uniqueness score.

Tabela 2. Diagnóstico de problemas

IP/GEO mismatch

IP mismatch não é apenas “cidade errada”. Na página de IP do BrowserLeaks, são importantes country, ISP, ASN/network e usage type; o Whoer também compara o país do IP com DNS, time zone/locale e sinais de tunneling. Na prática, o GEO exato em nível de cidade costuma ser menos importante do que a combinação país + ASN + timezone + tipo de rede.

A primeira correção quase sempre é do lado da rede: troque o proxy ou o tipo de proxy, não esconda as consequências no navegador. Se a tarefa for sensível ao tipo de IP e à reputação do ASN, compare separadamente os cenários no material sobre mobile vs residential proxies. E não comece com geolocation spoofing manual: a Multilogin adverte explicitamente que uma geolocation customizada pode criar um geolocation/IP mismatch.

DNS/WebRTC leaks

DNS/WebRTC leaks são um red flag crítico porque podem revelar o roteamento real, mesmo quando o IP externo parece “correto”. O BrowserLeaks escreve que, com configuração incorreta, as consultas DNS podem ir diretamente para o DNS do ISP, e seu teste de WebRTC mostra a exposição do IP local/público por meio de STUN. O Whoer também trata DNS, WebRTC e IP leaks como problemas básicos de privacy/mascaramento.

A ordem das correções aqui é sempre a mesma: DNS path → WebRTC mode → reteste. Se o WebRTC ou o DNS ainda falharem, não avance para sessões de trabalho e, principalmente, não vá para o aquecimento. Primeiro normalize a connection layer; os detalhes estão na análise sobre como se proteger contra WebRTC leaks.

Incompatibilidade entre User-Agent e OS

UA/OS mismatch é um dos problemas operacionais mais frequentes. O Pixelscan dá diretamente o exemplo em que um Windows user-agent entra em conflito com sinais de macOS. A Multilogin também escreve que um core desatualizado faz o perfil se destacar e que um mismatch entre a versão do navegador e o OS emulado pode gerar warnings. Considerando a UA reduction, é preciso comparar não apenas a string do UA, mas também os Client Hints.

Timezone/language mismatch

Timezone e language são sinais pequenos que só ficam “altos” quando contradizem o restante do perfil. A MDN afirma que resolvedOptions() retorna o time zone atual, enquanto navigator.languages e Accept-Language normalmente refletem o mesmo conjunto de locales. A Multilogin observa que os sites frequentemente comparam o timezone derivado do IP com as configurações regionais derivadas do JavaScript.

A primeira correção depende da fonte da verdade. Se o proxy foi escolhido corretamente, mas o locale/timezone do navegador não, alinhe o navegador. Se o locale é intencional e estável, mas a região do IP é estranha, troque o proxy. Para best results, os idiomas normalmente devem corresponder ao proxy/task locale, e não ficar como um conjunto aleatório.

Canvas/WebGL anomalies

Canvas/WebGL anomalies não devem ser ignoradas, mas raramente são a primeira causa dos problemas. O BrowserLeaks mostra que os fingerprints de Canvas e WebGL são construídos a partir de diferenças de rendering, e a MDN observa que WEBGL_debug_renderer_info pode revelar o vendor/renderer da stack gráfica. Ao mesmo tempo, a EFF alerta: alterar um fingerprint-sinal isoladamente pode tornar o navegador mais perceptível.

Por isso, é muito mais perigoso um rendering totalmente desativado, quebrado ou excessivamente ruidoso do que um “hash raro”. A Multilogin escreve diretamente que muitos sites populares reagem mal a graphics fingerprints totalmente únicos ou alterados, enquanto outputs reais de Canvas/AudioContext muitas vezes simplesmente se misturam com um grande número de dispositivos semelhantes.

Perfil excessivamente “aleatório” e automation flags

Os automation indicators são mais fáceis de interpretar: se navigator.webdriver estiver visível, ou se BrowserScan/Pixelscan detectarem traços de CDP/headless/deceptive Navigator, isso é um red flag real, e não cosmética. A MDN relaciona diretamente navigator.webdriver às flags de inicialização automation/headless.

Já o TCP/IP fingerprint não deve ser supervalorizado na primeira passagem. A Multilogin observa que o proxy reempacota os dados de rede, por isso o passive OS fingerprint pode não corresponder ao OS real, e a maioria dos sites ignora esse detalhe porque essas discrepâncias são comuns. Verifique isso como uma nuance de second-pass, não como o primeiro motivo para recriar o perfil.

Por que serviços diferentes mostram resultados diferentes

Profundidade de verificação diferente

A primeira explicação é a profundidade diferente. O BrowserLeaks é um conjunto de módulos separados, o Pixelscan tenta empacotar várias camadas em um actionable report, o AmIUnique se concentra em identifiability e history, o Cover Your Tracks no tracker/privacy view, e o BrowserScan adiciona mais peso aos sinais de bot-detection. Se as ferramentas fazem perguntas diferentes, as respostas também serão diferentes.

Metodologias e heurísticas diferentes

A segunda é a metodologia diferente. A MDN divide Client Hints em low-entropy e high-entropy; alguns hints exigem opt-in via Accept-CH. O AmIUnique compara o fingerprint com um dataset de pesquisa, o Cover Your Tracks avalia a proteção contra tracking/fingerprinting, e o Pixelscan enfatiza a consistency interna. Por isso, dois serviços podem olhar para o mesmo perfil, mas analisar recortes de risco diferentes.

Por que “verde” em um serviço não equivale a “perfil ideal”

Um resultado verde em um checker não significa que o perfil seja ideal em todos. O perfil pode parecer normal em um serviço orientado à uniqueness e, ao mesmo tempo, vazar via DNS/WebRTC; pode receber bom feedback de privacy, mas parecer fraco para uma stack de automação; pode parecer limpo em um all-in-one scan, mas ter uma transport oddity de baixa prioridade. Por isso, o mínimo operacional é um network-oriented checker e um consistency-oriented checker.

O que corrigir primeiro se o perfil não passar na auditoria

Se o perfil não passar na auditoria, não tente corrigir tudo de uma vez. É mais rápido ir de cima para baixo: connection layer → consistency layer → high-entropy layer → rebuild. Essa ordem coincide tanto com a forma como os checkers estruturados mostram os problemas quanto com as recomendações práticas para mismatchs.

Proxies e sticky sessions

Comece pela qualidade do proxy e pela estabilidade da sessão. Se o IP do proxy mudar no meio de uma sessão de trabalho, o alinhamento de timezone/geolocation/WebRTC pode “derivar”, e você acabará perseguindo sintomas em vez da causa. A Multilogin descreve cenários em que o sistema precisa ajustar WebRTC e geolocation após uma mudança de IP do proxy no meio da sessão; o BrowserLeaks e o Whoer também mostram que o comportamento de IP/DNS leak é a base, não um detalhe. Por isso, no first run e no início do aquecimento da conta, é melhor manter uma história de rede estável por sessão e retestar o perfil após cada troca de proxy. Se o problema for especificamente o tipo de rede e o ASN, compare as opções no material sobre mobile vs residential proxies.

Isolamento do perfil

Audite o perfil em isolamento: sem extensões desnecessárias, sem experimentos antigos e com permissões previsíveis. A EFF escreve separadamente que extensões de privacy e medidas de proteção incomuns podem elas mesmas se tornar parte do fingerprint. A Multilogin, por sua vez, lembra da same-origin policy: os sites não veem cookies de outros domínios. A conclusão prática é simples — perfil separado, mínimo de extras, configuração repetível.

Versão do núcleo do navegador e headers

Se a network layer estiver limpa, passe para o browser core e para os headers. Um núcleo desatualizado, restos de spoofing manual de UA ou um conflito entre a versão do navegador e o OS emulado provocam warnings com mais frequência do que problemas exóticos de Canvas. A recomendação aqui é direta: mantenha o core atualizado e certifique-se de que o User-Agent corresponda à versão real do navegador e ao OS declarado.

Não exagerar na randomização

Não exagere na randomization. A EFF não recomenda explicitamente alterar um elemento do fingerprint separadamente dos demais, porque as métricas são inter-relacionadas. A Multilogin também adverte que configurações profundas de fingerprint é melhor não tocar sem compreender as consequências. Na prática, defaults estáveis e coerentes quase sempre são melhores do que uma “camuflagem” manual agressiva.

Quando é preciso recriar o perfil do zero

Recrie o perfil quando as contradições estruturais voltarem após as correções básicas: o proxy já está limpo, mas UA/OS continuam em conflito; timezone/language precisam ser remendados manualmente; permissões e extensões continuam contaminando o resultado; automation flags reaparecem após o relaunch. Esta é uma conclusão prática, mas ela decorre logicamente da mesma ideia apontada pela EFF e pela documentação dos vendors: as métricas do fingerprint estão interligadas e, quando a “história do perfil” deixa de ser coerente, um rebuild muitas vezes é mais rápido do que um patching infinito.

Checklist antes de colocar o perfil em trabalho

Abaixo está uma lista curta que é conveniente salvar antes do first run ou antes do aquecimento da conta.

Checklist antes de lançar o perfil

• IP country, ASN e usage type são adequados para a tarefa; city-level GEO não é tratado como geografia exata.
• Os DNS servers não revelam rota pelo ISP, e o WebRTC não mostra o IP local/público real.
• User-Agent, Client Hints e OS/platform contam a mesma história.
• Accept-Language, navigator.language(s) e timezone correspondem ao proxy/task locale.
• A screen resolution parece realista para o dispositivo e a equipe.
• Canvas/WebGL/AudioContext não estão quebrados, não estão desativados sem motivo e não parecem excessivamente “ruidosos”.
• navigator.webdriver, CDP e headless flags estão ausentes, se a automação não fizer parte do cenário.
• O browser core está atual, e o mismatch entre version e OS foi eliminado.
• O comportamento da Geolocation API é intencional: prompt/allow/block não contradiz a IP-story.
• Após cada alteração, você executa novamente pelo menos um network checker e um consistency checker.

Quando um navegador comum é suficiente e quando um antidetect é necessário

Um navegador comum muitas vezes é suficiente quando a tarefa é simples: verificar seu IP/DNS/WebRTC, entender o que os sites veem nos headers, comparar rapidamente alguns browser signals ou simplesmente entender como funciona o fingerprinting. Para essas verificações pontuais, BrowserLeaks, Cover Your Tracks, AmIUnique, iphey e Whoer já são suficientes.

Um navegador antidetect faz sentido quando você precisa não de um teste único, mas de um fluxo de trabalho repetível: vários perfis isolados com seus próprios cookies, language, timezone, proxy e launch parameters, além de API/automation para criar, iniciar, atualizar e fechar perfis. A documentação da Undetectable API descreve diretamente métodos de lifecycle e parâmetros como proxy, language, cookies e timezone; nas atualizações do produto também são mencionados separadamente proxy checks antes de iniciar o perfil e headless/background operation.

O caminho prático é o seguinte: primeiro verifique a configuração no BrowserLeaks checker, Pixelscan checker, AmIUnique checker, Panopticlick / Cover Your Tracks checker e, se necessário, complemente com iphey e Whoer. Se você precisa não de um teste único, mas de um workflow constante com perfis, cookies, proxy e automation, passe para o download do Undetectable e depois para os planos. E mesmo nesse caso, a auditoria continua obrigatória: nenhum produto, por si só, garante a ausência de mismatchs.

FAQ

1. O que é browser fingerprint?

Browser fingerprint é um conjunto de características do navegador e do dispositivo que um site coleta a partir de HTTP headers, JavaScript e Web APIs para distinguir um navegador de outro. Isso inclui UA, idioma, timezone, screen, fonts, Canvas/WebGL, audio e outros sinais. Não é a mesma coisa que cookie, nem a mesma coisa que IP.

2. Por que o BrowserLeaks e o Pixelscan podem mostrar resultados diferentes?

Porque eles resolvem tarefas diferentes. O BrowserLeaks é um conjunto modular de testes de baixo nível, enquanto o Pixelscan é um relatório all-in-one de consistency com foco em detectability, internal mismatchs e automation indicators. Eles não precisam avaliar o mesmo perfil da mesma forma, porque analisam camadas diferentes e usam heurísticas diferentes.

3. Limpar cookies muda a impressão digital do navegador?

Normalmente não. Cookies e fingerprint são mecanismos diferentes. Apagar cookies remove identificadores salvos do site, mas não muda seu language, timezone, screen, fonts, GPU ou comportamento de WebRTC. Ao mesmo tempo, alguns serviços como Cover Your Tracks e AmIUnique usam eles próprios research cookies para vincular testes repetidos e estudar como o fingerprint muda ao longo do tempo.

4. O que é mais importante: proxy ou fingerprint?

É preciso começar pelo proxy e pela network layer. Se você tem DNS leak, WebRTC leak, um ASN estranho ou um IP/timezone mismatch, o ajuste fino de Canvas/WebGL não vai salvar o perfil. Primeiro — a rede, depois — a consistency do browser fingerprint.

5. Com que frequência é preciso verificar novamente o perfil?

No mínimo — antes da primeira execução, após trocar o proxy, após atualizar o browser core, após editar manualmente UA/language/timezone/geolocation e após alterações na configuração de automation/headless. Além disso, faz sentido voltar à auditoria periodicamente, porque os serviços e as métricas evoluem, e parte dos sinais depende da sessão atual e do origin específico.

6. O que fazer se WebRTC ou DNS leak não passarem?

Pare e corrija a connection layer: rota DNS, modo WebRTC, qualidade do proxy e estabilidade da sessão. Só depois repita os testes. O BrowserLeaks e o Whoer colocam diretamente os DNS/WebRTC leaks na lista básica de problemas, e a Multilogin mostra separadamente como é importante sincronizar o WebRTC com a IP-story.

7. Por que o perfil passa em um teste, mas falha em outro?

Porque diferentes checkers verificam profundidades diferentes e definem prioridades de modo diferente. Um pode analisar uniqueness/history, outro — privacy protection, um terceiro — internal consistency, e um quarto — automation traces. Isso é normal; é exatamente por isso que uma auditoria completa sempre consiste em vários serviços.

Undetectable Team Especialistas em Anti-deteção