Impressões digitais de proxy: como o Facebook/Google realmente determina que está a usar um proxy?
Ultimamente, o uso de proxies para privacidade, arbitragem de tráfego ou marketing tornou-se um verdadeiro desafio. Você comprou um proxy limpo, configurou um navegador antidetect e aqueceu os cookies para imitar um comportamento natural. No entanto, 30 segundos após entrar no gerenciador de anúncios do Facebook, você recebe um banimento. O motivo? «Atividade de rede suspeita».
De acordo com os últimos relatórios Imperva Bad Bot Report, mais de 70% dos bloqueios em plataformas publicitárias estão relacionados a anomalias de rede, e não apenas a padrões comportamentais. Os sistemas antifraude (anti-fraud) das corporações de Big Tech, como Facebook (Meta) e Google, evoluíram: eles não apenas verificam o IP em listas negras, mas analisam a «física» da conexão por meio de aprendizado de máquina. Um servidor proxy, como intermediário, deixa inevitavelmente impressões digitais.
Neste artigo, consideraremos 7 níveis de verificação nos quais as plataformas reconhecem um proxy, mesmo que o IP pareça perfeitamente limpo. Analisaremos detalhes técnicos, exemplos e soluções práticas. Para fins de visualização, utilizaremos ferramentas como Wireshark, browserleaks.com e o verificador de IP da CyberYozh App (links ao final do artigo).
Nível 1: ASN e o «Estigma Corporativo»
Este é um filtro básico, mas continua sendo fatal para muitos. Cada endereço IP possui um «passaporte» — a sua pertença a um Sistema Autónomo (ASN), que pode ser verificado através de WHOIS ou bases de dados como MaxMind.
Tipos de ASN:
ISP: Internet doméstica (Comcast, Verizon, Lietpark Communications).
Mobile: Operadoras móveis (T-Mobile, THREE, Vodafone).
Hosting/Business: Centros de dados (AWS, DigitalOcean, Hetzner).
A armadilha: Proxies de servidor baratos são alocados em centros de dados, onde o seu ASN é marcado como «corporativo». Além disso, o DNS reverso (rDNS) frequentemente revela a verdade: em vez de user.provider.com — aparece server.example.com.
Exemplo para o Google: Um usuário faz login no Gmail com o User-Agent «Chrome / Windows 10». O tráfego vem de um centro de dados em Frankfurt, onde não existem usuários residenciais.
Conclusão: O sistema vê um bot ou VPN. O Trust Score é zerado.
Solução: Escolha proxies residenciais (residential) ou móveis com ASN de provedores reais. Verifique o rDNS em busca de padrões suspeitos. Esqueça os centros de dados para tarefas como Facebook Ads ou Google Ads, onde os filtros são mais rígidos.
Nível 2: Impressão Digital Passiva do SO (p0f e TCP/IP Stack)
Aqui entra em jogo a técnica avançada: análise da pilha (stack) TCP/IP. Os sistemas operacionais formam pacotes de rede de maneira única, como impressões digitais. Ferramentas como p0f ou modelos de ML das BigTech extraem isso de forma passiva.
Parâmetros principais:
TTL (Time To Live): Windows — 128, Linux/Android/iOS — 64.
Window Size: Tamanho da janela de recepção de dados.
TCP Options: Ordem dos cabeçalhos (ex: MSS, Timestamp).
TLS Fingerprinting (JA3): O sistema analisa a estrutura do TLS Client Hello.
Esclarecimento: Se você estiver usando um proxy HTTP/SOCKS comum (método CONNECT), o handshake TLS ocorre diretamente do cliente para o site, portanto, o proxy não afeta o hash JA3. Neste caso, o JA3 serve como um detector de «navegador incorreto» (bot, script de automação), e não do proxy em si. No entanto, se o proxy funcionar como MITM (descriptografar o tráfego) ou se você usar soluções baratas sem tunelamento limpo, o JA3 mudará e revelará instantaneamente a substituição. O fato de usar um servidor Linux como proxy é mais frequentemente detectado via TCP/IP fingerprinting (TTL), e não via TLS.
Exemplo para o Facebook: No navegador antidetect é selecionado o perfil «Windows 10», mas a conexão passa por um proxy configurado em um servidor Ubuntu (Linux). O Facebook vê um User-Agent de Windows, mas os pacotes TCP recebidos têm TTL=64 (característico de Linux), e não 128.
Conclusão: Incompatibilidade (Mismatch). O sistema entende que o tráfego está passando por um nó intermediário em Linux. A confiança cai.
Solução: Navegadores antidetect mascaram perfeitamente o JA3 e os cabeçalhos, mas não podem alterar as configurações do kernel de um servidor proxy remoto.
Sincronização: Idealmente, o SO do proxy deve coincidir com o perfil (ex: proxies móveis Android para perfil Android).
Passive OS Fingerprinting: Utilize provedores de proxy (como a CyberYozh App) que sabem mascarar a pilha TCP/IP ao nível da rede. Isso permite que um proxy em Linux envie pacotes que pareçam pacotes «nativos» de Windows ou macOS para o Facebook.
Nível 3: MTU e MSS — O tamanho importa
MTU (Maximum Transmission Unit) — tamanho máximo do pacote sem fragmentação. MSS (Maximum Segment Size) — a sua parte útil menos os cabeçalhos.
Padrões:
Ethernet (doméstica): 1500
Móvel (4G/5G): 1420–1480
Se você usa um proxy, mas vê um MTU característico de VPN (ex: 1300), este é um sinal para o antifraude: o seu proxy «residencial» está na verdade conectado através de um túnel VPN (ex: OpenVPN — até 1350, WireGuard — superior).
Exemplo para a Amazon: O IP é residencial, mas o MTU é 1300 — sinal de túnel. No QUIC (protocolo do Google), isso é visível nos pacotes UDP.
Conclusão: O tráfego está «empacotado» — suspeita de proxy.
Solução: Teste o MTU através do browserleaks.com ou Wireshark. Configure o tunelamento para imitar os valores padrão. Mude de provedor se as anomalias persistirem.
Nível 4: Latência (Latency) e Geo-triangulação
A velocidade da luz é uma constante. O antifraude utiliza ataques de tempo (timing attacks): RTT (Round Trip Time) e comparação com a geolocalização.
Cenário: Proxy em Nova York, você em Lisboa, servidor do Facebook nos EUA.
Pedido: Lisboa → Nova York → Servidor.
RTT — 300 ms em vez de 20–30 ms para um usuário local.
Adicional: Triangulação via CDN — medição do RTT para vários servidores. Além da divergência com a Geolocation API do navegador.
Exemplo para o Facebook: IP em Nova York, mas latência como se viesse da Europa — um «desvio» pelo proxy.
Conclusão: Incompatibilidade entre geolocalização e ping. O tráfego não é direto.
Solução: Escolha proxies com ping baixo (<50 ms). Evite cadeias longas (Double VPN). Desative a geolocalização no navegador.
Nível 5: Portas Abertas e Escaneamento
Proxies frequentemente deixam portas «técnicas» abertas. Os sites usam uma abordagem combinada: o servidor antifraude escaneia o seu IP por fora, enquanto scripts no navegador (via WebRTC) tentam determinar o seu IP local real por dentro.
Sinais de Alerta:
Portas 3128, 8080, 1080 (Squid/SOCKS).
Portas 22 (SSH), 23 (Telnet), 3389 (RDP).
Vazamentos de WebRTC: Revelação do IP local real por trás do proxy.
Em usuários domésticos, estas portas geralmente estão fechadas pelo roteador/NAT.
Exemplo para banco: O script verifica — portas estão abertas, probabilidade de proxy 99%.
Conclusão: O dispositivo não é residencial.
Solução: Escolha provedores com filtros de portas de entrada. Bloqueie/substitua o WebRTC no navegador antidetect.
Nível 6: Impressões Digitais de Browser e Comportamentais
Um proxy não funciona no vácuo. O antifraude analisa a congruência (consistência) dos dados de rede e das impressões digitais do navegador.
Divergências críticas:
Fuso Horário e Idioma: O seu IP está em Londres, mas a hora do sistema no navegador é UTC+0 (Lisboa), e o cabeçalho Accept-Language é pt-PT. Este é um «Red Flag» instantâneo.
Hardware: O User-Agent declara que é um «iPhone», mas os atrasos de rede e o MTU são característicos de internet a cabo em um centro de dados.
Behavior (Comportamento): Movimentos de mouse por script (estritamente em linhas retas), ausência de micro-pausas ou «Impossible Travel» — login na conta em Berlim 5 minutos após sair de Nova York.
Exemplo para o YouTube: A monetização ou visualizações são descartadas se o sistema vir um comportamento «robotizado» sobre um IP residencial perfeito.
Conclusão: Anomalia complexa. Mesmo o melhor proxy não salvará se o perfil do navegador for configurado de forma descuidada.
Solução: Utilize antidetects de qualidade. Sincronize o fuso horário e a geolocalização do perfil com os dados do proxy. Imite o comportamento humano (movimentos de mouse caóticos, pausas, rolagem).
Nível 7: Listas Negras e Reputação de IP
Sistemas antifraude não adivinham, eles verificam o histórico. Bases como IPQualityScore (IPQS), MaxMind, ipdata marcam IPs como «Proxy/VPN» ou «Abuse» com base na sua atividade passada.
Exemplo para o Google: O seu IP pode estar limpo agora, mas se há uma semana foi usado para enviar spam, ele estará em uma «lista negra» (Blacklist). O Google vê a flag High Fraud Score e bloqueia a conta preventivamente.
Conclusão: A reputação do IP está manchada, embora tecnicamente a conexão esteja configurada corretamente.
Solução: Nunca confie em verificadores públicos gratuitos — eles frequentemente mostram dados desatualizados («IP limpo»), enquanto as bases corporativas pagas já marcaram o endereço como arriscado. Utilize agregadores, como o IP Checker da CyberYozh App. Nós utilizamos bases pagas dos líderes de mercado (incluindo IPQS e MaxMind) para lhe mostrar a imagem real — exatamente o que o sistema antifraude do site vê.
💡 Como ler o relatório? Para interpretar corretamente os parâmetros de Fraud Score e entender qual nível de risco é aceitável para as suas tarefas, recomendamos estudar o nosso guia detalhado sobre como trabalhar com o checker.
Mitos sobre proxies em 2025
❌ Mito 1: VPN é melhor que proxy. Realidade: VPN adiciona dados de serviço extras (diminui o MTU, aumenta a latência) e é mais facilmente detectada devido aos protocolos específicos de criptografia.
❌ Mito 2: Proxies gratuitos funcionam. Realidade: Eles já estão em listas negras, são lentos e expõem portas abertas.
❌ Mito 3: Apenas o IP é importante. Realidade: A pilha completa (do TCP ao comportamento do mouse) é verificada por IA.
Conclusão: Como sobreviver no mundo do antifraude?
Os sistemas antifraude estão atentos aos detalhes, mas não são onipotentes. Em 2025, o uso de proxy é infraestrutura, não uma «pílula mágica».
O seu checklist:
ASN e IP: Apenas residenciais/móveis, nada de centros de dados. Verifique o rDNS.
Impressões Digitais: Mascare o TCP/IP (Passive OS Fingerprinting), TLS (JA3). Sincronize o SO.
Protocolo: SOCKS5 para «limpeza» de tráfego.
Latência/MTU: Minimize atrasos, teste o MTU para anomalias.
Portas/WebRTC: Feche portas, bloqueie vazamentos de IP local.
Comportamento: Imite padrões humanos.
Verificação: Para analisar a reputação do IP, utilize o IP Checker da CyberYozh App (agrega dados de bases premium), e para verificar impressões digitais do navegador — browserleaks.com.
No catálogo da CyberYozh App, levamos em conta estes parâmetros ao nível da arquitetura. Fornecemos IPs residenciais e móveis limpos, sem portas abertas, com suporte para Passive OS Fingerprinting (por favor, verifique a disponibilidade desta opção para o seu plano no suporte técnico) e cabeçalhos corretos, para que você possa se concentrar no trabalho e não no combate aos banimentos.
Fontes e Ferramentas:
