Um scraper funciona na perfeição nos testes.
Depois, direciona-o para um site real e obtém:
403 Proibido.
Ou um CAPTCHA.
Ou a página carrega no Chrome, mas devolve algo completamente diferente do que o teu script esperava.
Altera-se o endereço IP. Funciona durante algumas solicitações e volta a ser bloqueado.
Este é o tipo de problema que o DataDome foi concebido para criar no tráfego automatizado.
O importante é compreender que o DataDome não se limita a perguntar:
«Este IP é suspeito?»
A deteção moderna de bots está muito mais próxima de:
«Este IP, esta ligação de rede, este navegador, este dispositivo, este padrão de pedidos e esta sessão fazem sentido quando considerados em conjunto?»
Essa distinção explica por que razão mudar de proxy por vezes ajuda, por que razão muitas vezes não ajuda e por que razão um scraper que parece perfeitamente normal ao nível do HTTP pode ainda assim falhar.
Este guia explica como o DataDome funciona, que sinais pode utilizar, como se apresenta um bloqueio do DataDome, por que razão os navegadores e os scripts se comportam de forma diferente e onde é que os proxies, a automatização do navegador e as APIs de scraping se enquadram neste contexto.
O que é o DataDome?
O DataDome é uma plataforma de proteção contra bots e fraudes online utilizada por sítios Web, aplicações móveis e APIs para distinguir utilizadores legítimos do tráfego automatizado ou malicioso.
Os proprietários de sites utilizam sistemas como o DataDome para reduzir atividades como:
- extração não autorizada de dados;
- preenchimento de credenciais;
- tentativas de apropriação de contas;
- criação de contas falsas;
- abuso de inventário;
- fraude de pagamentos;
- análise automatizada de vulnerabilidades;
- bots agressivos;
- agentes de IA indesejados.
Para quem recolhe dados públicos da Web, o DataDome surge do outro lado da equação.
A sua solicitação chega a um site protegido, mas antes de a aplicação decidir que conteúdo devolver, o DataDome pode avaliar a solicitação e determinar se esta parece legítima, suspeita ou automatizada.
O resultado pode ser:
Permitir
A solicitação prossegue normalmente.
Verificação do dispositivo
É realizada uma verificação adicional do navegador/dispositivo.
CAPTCHA
O cliente recebe um desafio interativo.
Bloquear
A solicitação é rejeitada.
É por isso que duas solicitações para exatamente o mesmo URL podem produzir respostas completamente diferentes.
O URL não mudou.
O cliente sim.
Como funciona o DataDome
Um modelo simplificado útil tem o seguinte aspeto:
Cliente → site protegido/DataDome → decisão de deteção → site
A etapa de deteção é onde ocorrem a maioria dos problemas com os scrapers.
O DataDome consegue avaliar sinais provenientes de várias camadas de uma ligação, em vez de se basear num único indicador simples.
Estas camadas podem incluir:
| Camada | Exemplos de sinais |
|---|
| Rede | Endereço IP, ASN, reputação da rede |
| TLS | Impressão digital TLS e características da ligação |
| HTTP | Cabeçalhos, consistência dos cabeçalhos, propriedades do pedido |
| Navegador | Impressão digital do navegador e ambiente |
| Dispositivo | SO, hardware e sinais de execução |
| JavaScript | Resultados de verificações do lado do cliente |
| Sessão | Cookies e continuidade entre pedidos |
| Comportamento | Tempos e padrões de interação |
| Reputação | Atividade anterior associada à infraestrutura |
Nenhuma linha, por si só, prova necessariamente que um pedido seja automatizado.
O valor advém da comparação entre todas elas.
Um IP residencial com uma impressão digital do navegador improvável pode, mesmo assim, parecer suspeito.
Um User-Agent aparentemente perfeito proveniente de um cliente TLS inconsistente pode, mesmo assim, parecer suspeito.
Um navegador real que gere centenas de pedidos altamente repetitivos pode, mesmo assim, parecer suspeito.
Essa é a diferença fundamental entre os sistemas anti-bot modernos e os antigos sistemas de bloqueio de IP.
Detecção do DataDome: As principais camadas
1. Reputação do IP
A reputação do IP continua a ser importante.
Um endereço IP pode ter um histórico.
Por exemplo, uma infraestrutura pode adquirir uma má reputação quando dela se origina um grande volume de tráfego abusivo ou manifestamente automatizado.
O DataDome pode avaliar se o tráfego provém de:
- infraestruturas de alojamento conhecidas;
- intervalos de endereços de centros de dados;
- proxies partilhados;
- proxies residenciais;
- redes de proxies públicos gratuitos;
- endereços anteriormente suspeitos.
Mas a reputação do IP é apenas um indicador.
É por isso que afirmações como:
«Use um proxy residencial e o DataDome não o conseguirá detetar.»
são enganosas.
Um endereço residencial pode fazer com que um pedido de rede pareça mais semelhante ao tráfego normal de um consumidor.
Não consegue, por si só, tornar o resto do pedido automaticamente consistente.
2. Cabeçalhos HTTP
Os navegadores enviam um conjunto reconhecível de cabeçalhos.
As ferramentas de automatização também enviam cabeçalhos.
O que é interessante não é apenas se uma solicitação contém um «User-Agent
».
É se a solicitação faz sentido como um todo.
Por exemplo, imagine um cliente que afirma ser uma versão recente do Chrome, mas que envia um conjunto de cabeçalhos que normalmente não correspondem a esse navegador.
Individualmente, cada valor pode parecer razoável.
Em conjunto, podem não o ser.
A deteção moderna de bots pode procurar estas inconsistências.
Alterar apenas:
User-Agent: Mozilla/5.0...
não transforma uma simples biblioteca HTTP no Chrome.
3. Impressão digital TLS
Antes de os dados HTTP serem trocados através de HTTPS, o cliente cria uma ligação TLS.
Clientes diferentes podem produzir características TLS diferentes.
Um navegador, uma biblioteca HTTP em Python, um cliente de linha de comandos e outro ambiente de execução podem estabelecer ligações encriptadas de formas diferentes.
Esses padrões podem ser resumidos em impressões digitais.
A documentação do DataDome refere especificamente as impressões digitais TLS, incluindo informações JA3 e JA4, como parte dos dados que podem ser utilizados na avaliação do tráfego.
Isto cria um problema importante para configurações simplistas de scraping.
Os seus cabeçalhos HTTP podem indicar:
Chrome no Windows
enquanto a ligação de rede subjacente não se assemelha em nada à versão do Chrome que afirma estar a utilizar.
Alterar um cabeçalho HTTP não altera automaticamente a pilha TLS subjacente.
Esta é uma das razões pelas quais a falsificação apenas via HTTP acaba por atingir um limite.
4. Identificação do navegador
Assim que o JavaScript puder ser executado, a deteção anti-bot tem acesso a um ambiente muito mais rico.
Um navegador verdadeiro revela uma grande quantidade de informações sobre si próprio e sobre o dispositivo em que está a ser executado.
Os sinais potenciais incluem características relacionadas com:
- versão do navegador;
- sistema operativo;
- hardware;
- CPU;
- memória;
- ambiente gráfico;
- APIs do navegador suportadas;
- comportamento de renderização;
- suporte a funcionalidades;
- artefactos de automatização.
A dificuldade da automatização não reside em produzir um valor credível.
É produzir centenas de valores mutuamente consistentes.
Suponha que um navegador automatizado afirme estar a ser executado num sistema operativo, mas que outras partes do seu ambiente se comportem como se fosse outro.
Ou que as características de hardware reportadas não correspondam ao dispositivo declarado.
Ou que a automação modifique propriedades comuns da impressão digital, mas deixe os sinais secundários inalterados.
O navegador pode parecer convincente se inspecionarmos cinco propriedades óbvias.
Um sistema de deteção não tem de se limitar a cinco.
5. Detecção de navegadores sem interface gráfica e automatizados
O Playwright, o Puppeteer e o Selenium são incrivelmente úteis.
Além disso, não são invisíveis.
Iniciar o Chromium proporciona ao seu scraper um motor de navegador real, o que resolve muitos problemas que um cliente HTTP básico não consegue resolver:
- execução de JavaScript;
- renderização;
- cookies;
- APIs do navegador;
- conteúdo dinâmico;
- estado de navegação.
Mas «motor de navegador real» não significa «indistinguível de um utilizador normal».
As estruturas de automatização podem introduzir diferenças observáveis.
A própria documentação de deteção do DataDome contém explicitamente categorias de deteção para navegadores automatizados e «headless», incluindo navegadores controlados pelo Puppeteer, Selenium e Playwright.
Isso significa que esta arquitetura simples:
Playwright + proxy
não deve ser tratada como uma solução anti-bot universal.
Pode funcionar na perfeição num site e falhar rapidamente noutro.
6. JavaScript e Device Check
O DataDome também pode solicitar uma verificação adicional ao cliente.
Um dos mecanismos é o Device Check.
Em vez de apresentar imediatamente um CAPTCHA visível, o JavaScript é executado no navegador e avalia o ambiente.
De acordo com a DataDome, a sua Verificação de Dispositivo recolhe centenas de sinais e realiza várias verificações destinadas a detetar estruturas de automação, ambientes falsificados e acesso programático.
Para um visitante real, isto pode acontecer sem qualquer interrupção óbvia.
Para um scraper, isto cria uma diferença importante entre:
cliente HTTP
e:
navegador capaz de executar a lógica esperada do lado do cliente
Se o seu scraper apenas descarregar o HTML inicial e ignorar tudo o que acontece no navegador, poderá nunca reproduzir a interação completa esperada pelo site protegido.
7. Detecção comportamental
Um navegador tecnicamente convincente pode, ainda assim, apresentar um comportamento estranho.
Considere duas sessões.
Sessão A
Um utilizador:
- abre uma página de produto;
- passa 14 segundos a ler;
- abre outra página;
- percorre a página;
- regressa;
- faz uma pesquisa;
- abre um resultado.
Sessão B
Um crawler:
- solicita o produto 1;
- 300 ms depois, solicita o produto 2;
- 300 ms depois, solicita o produto 3;
- repete isto centenas de vezes.
Ambas as sessões podem utilizar o Chrome.
Ambas podem utilizar endereços IP residenciais.
O seu comportamento é obviamente diferente.
A deteção comportamental permite que um sistema anti-bot considere padrões em vez de pedidos individuais.
Isto é especialmente importante em grande escala.
Um scraper que tenha sucesso uma vez não é necessariamente um scraper capaz de sustentar 100 000 pedidos.
8. Consistência da sessão
Os sites modernos são «stateful».
Os cookies, o estado do navegador, os endereços IP e o histórico de pedidos fazem todos parte de uma sessão.
A automação torna-se mais fácil de detetar quando esses elementos se contradizem entre si.
Por exemplo:
- o IP muda constantemente enquanto o mesmo cookie de sessão permanece;
- a identidade do navegador muda a meio de uma sessão;
- a navegação salta repentinamente para recursos não relacionados;
- os cookies esperados de um passo anterior nunca aparecem;
- cada pedido comporta-se como se fosse de um visitante totalmente novo.
É por isso que a rotação cega de um endereço IP para cada pedido pode, por vezes, tornar um scraper menos credível, em vez de mais credível.
A rotação é útil.
A continuidade é útil.
A escolha correta depende da carga de trabalho.
Como é um bloqueio do DataDome?
O DataDome não tem de responder da mesma forma a todos os pedidos suspeitos.
Existem vários resultados com que se pode deparar.
Resposta 403
O sinal mais claro é uma resposta HTTP «403 Forbidden».
Mas não presuma que todos os códigos 403 na Internet provêm do DataDome.
Verifique sempre a resposta efetiva.
Página CAPTCHA
Em vez da página de destino, a resposta pode conter um desafio do DataDome.
Verificação do dispositivo
O navegador pode realizar uma verificação invisível antes de permitir a continuação do acesso.
Isto é particularmente confuso durante a depuração, porque a página pode acabar por funcionar no seu navegador normal sem que alguma vez veja um CAPTCHA.
Página de bloqueio
O tráfego considerado suficientemente suspeito pode receber uma resposta de bloqueio direto.
Comportamento diferente no Chrome e no seu scraper
Esta é uma das pistas mais fortes de que o problema não é a própria URL.
Se:
Chrome → conteúdo
mas:
pedidos/cURL/script personalizado → desafio
a diferença está provavelmente algures no cliente, na identidade de rede, na execução do navegador ou na sessão.
Por que razão alterar o endereço IP não é suficiente
Um proxy altera uma parte importante do pedido:
a origem aparente do tráfego.
Isso é valioso.
Mas não altera automaticamente:
- a sua implementação HTTP;
- a impressão digital TLS;
- o ambiente do navegador;
- a execução de JavaScript;
- a impressão digital do navegador;
- os cookies;
- o tempo da solicitação;
- o comportamento de navegação;
- a lógica da sessão.
Pense na pilha completa:
**IP
- TLS
- HTTP
- navegador
- dispositivo
- sessão
- comportamento**
Um proxy altera principalmente a primeira camada.
Isso pode ser suficiente quando a reputação do IP é a razão pela qual uma solicitação falha.
Não é suficiente quando várias camadas estão em desacordo.
Proxies de centro de dados vs. proxys residenciais com o DataDome
Não existe um «proxy DataDome» universal.
Diferentes tipos de proxy resolvem diferentes problemas de rede.
Proxies de centro de dados
Os IPs de centro de dados são rápidos, económicos e extremamente úteis para muitas cargas de trabalho de automatização.
A sua desvantagem em sites de consumo altamente protegidos é que a sua origem de rede é mais fácil de classificar como infraestrutura de alojamento.
Isto não significa que todas as solicitações provenientes de centros de dados sejam bloqueadas.
Significa que o próprio IP pode fornecer menos indícios de que o cliente se assemelha a um consumidor comum.
Proxies residenciais
Os proxies residenciais encaminham as solicitações através de endereços IP associados a ligações à Internet de consumidores.
Isso pode proporcionar um perfil de rede mais adequado para cargas de trabalho que envolvam sites públicos voltados para o consumidor.
Mas um IP residencial não é sinónimo de ser humano.
A DataDome documenta explicitamente modelos capazes de identificar tráfego automatizado encaminhado através de proxies residenciais.
A forma útil de pensar sobre os proxies residenciais é, portanto:
melhor identidade de rede
e não:
contornamento automático da proteção contra bots
Proxies de ISP
Os proxies de ISP podem oferecer sessões estáveis ao utilizarem o espaço de IP associado aos ISP dos consumidores.
Para fluxos de trabalho que exigem uma identidade consistente ao longo de uma sessão mais prolongada, essa estabilidade pode ser valiosa.
Mais uma vez, o resto do cliente continua a ser importante.
Por que razão a rotação constante de proxies pode sair pela culatra
«Rotar com mais frequência» parece um conselho óbvio.
Nem sempre é correto.
Imagine uma sessão num site com a duração de cinco minutos.
Um utilizador real manteria normalmente a mesma identidade de rede durante a maior parte dessa sessão.
Se a sua automação mudar de país ou de rede a cada três pedidos, mantendo os mesmos cookies e a mesma sessão da conta, essa combinação pode parecer pouco natural.
Para algumas cargas de trabalho, as sessões rotativas são adequadas.
Para outras, as sessões persistentes produzem um comportamento mais coerente.
Uma estratégia de proxy deve corresponder à estrutura da aplicação à qual está a aceder.
E quanto aos programas de resolução de CAPTCHA?
O CAPTCHA não é necessariamente o ponto de partida do processo de decisão do DataDome.
Pode ser apenas uma resposta após outra detecção já ter marcado a sessão como suspeita.
Essa distinção é importante.
Resolver um CAPTCHA não corrige automaticamente:
- uma impressão digital do navegador suspeita;
- uma pilha TLS inconsistente;
- má reputação do IP;
- comportamento impossível da sessão.
A DataDome já abordou publicamente a deteção de «fazendas» de CAPTCHA e ambientes automatizados, mesmo após a resolução de um desafio.
Por isso, tratar a resolução do CAPTCHA como se fosse o problema na sua totalidade ignora o sistema mais vasto que o rodeia.
Por que razão um scraper pode funcionar hoje e falhar amanhã
Esta é outra fonte comum de confusão.
Nada no seu código muda.
De repente, a taxa de sucesso cai.
Isso não significa necessariamente que o alvo tenha redesenhado o seu site.
Os sistemas de gestão de bots alteram continuamente a lógica de deteção.
Outras variáveis também mudam:
- a reputação do IP evolui;
- as versões dos navegadores são atualizadas;
- as políticas do site mudam;
- o volume de tráfego aumenta;
- o seu padrão de pedidos muda;
- um alvo ativa uma proteção mais rigorosa para um ponto final específico.
A extração de dados contra os modernos sistemas anti-bot é, portanto, um problema operacional, não um problema pontual de configuração.
DataDome e Playwright
O Playwright é útil quando um site requer uma execução genuína no navegador.
Consegue carregar JavaScript, interagir com as páginas e manter o estado do navegador.
Isso torna-o significativamente mais capaz do que uma simples biblioteca de pedidos HTTP para sites modernos.
No entanto, o Playwright não torna automaticamente o tráfego «humano».
O site protegido pode ainda avaliar:
- características do navegador;
- artefactos de automação;
- identidade de rede;
- sessões;
- frequência de pedidos;
- comportamento.
É por isso que um scraper do Playwright pode funcionar bem em fase de desenvolvimento e tornar-se pouco fiável em grande escala.
A automação do navegador resolve a execução no navegador.
Não resolve todas as camadas anti-bot em torno do navegador.
DataDome e Puppeteer
O mesmo princípio aplica-se ao Puppeteer.
A utilização do Chromium proporciona ao rastreador um ambiente de cliente muito mais rico do que o HTTP bruto.
Isso é útil para:
- aplicações renderizadas pelo cliente;
- páginas dinâmicas;
- navegação em JavaScript;
- conteúdo carregado após o HTML inicial;
- aplicações que requerem cookies ou o estado do navegador.
Mas o navegador, o IP e o comportamento continuam a ter de formar uma sessão coerente.
O Puppeteer é uma estrutura de automação do navegador.
Não é uma camada de invisibilidade.
A pilha de scraping que realmente importa
Em vez de perguntar:
«Qual é o proxy que contorna o DataDome?»
é mais útil pensar em camadas.
| Problema | Camada relevante |
|---|
| Má reputação do IP | Proxy/rede |
| Localização errada | Proxy com segmentação geográfica |
| JavaScript necessário | Navegador/renderização |
| Conteúdo dinâmico | Navegador/renderização |
| Inconsistência TLS | Pilha HTTP/navegador |
| Incompatibilidade da impressão digital do navegador | Ambiente do navegador |
| Instabilidade da sessão | Gestão de cookies/sessões |
| Padrão de pedidos excessivo | Arquitetura de rastreamento |
| CAPTCHA/desafio | Tratamento de desafios |
| Manutenção constante do sistema anti-bot | Infraestrutura de scraping gerida |
Isto torna a resolução de problemas muito mais rápida.
Deixa de tentar resolver todos os problemas substituindo o proxy.
Três formas de recolher dados de um site protegido pelo DataDome
Para a recolha legítima de dados, em que se tem permissão para aceder ao alvo, existem, em termos gerais, três arquiteturas.
1. Criar o scraper por conta própria
O utilizador controla tudo:
- cliente HTTP;
- navegador;
- proxy;
- sessão;
- lógica de repetição de tentativas;
- análise;
- renderização;
- monitorização.
Vantagens:
Controlo máximo.
Desvantagens:
Manutenção máxima.
Isto faz sentido quando o seu fluxo de trabalho é suficientemente invulgar para justificar a posse de toda a pilha.
2. Utilizar proxies com o seu próprio navegador ou scraper
Arquitetura:
o seu scraper → rede de proxies → alvo
Isto permite-lhe manter o controlo da aplicação enquanto externaliza a infraestrutura de rede.
É útil quando os seus principais problemas envolvem:
- reputação de IP;
- segmentação geográfica;
- simultaneidade;
- rotação de rede;
- sessões estáveis.
Os Proxies Residenciais da Geonode, por exemplo, suportam segmentação geográfica e configurações de sessões tanto rotativas como fixas.
No entanto, a sua aplicação continua a ser responsável por tudo o que está acima da camada de proxy.
3. Utilizar uma API de scraping
Arquitetura:
a sua aplicação → API de scraping → alvo
Em vez de gerir você mesmo os navegadores, a seleção de proxies e a infraestrutura de extração, envie o URL para um serviço concebido para a recolha de dados da Web.
Esta opção costuma ser mais adequada quando o requisito real é:
«Dá-me o conteúdo da página.»
em vez de:
«Quero manter uma equipa de infraestrutura anti-bot/navegador.»
O Scraper API's , por exemplo, pode devolver o conteúdo da página renderizada como HTML ou Markdown e fornece renderização em JavaScript, infraestrutura de proxy gerida, segmentação geográfica, processamento em lote e rastreamento.
A distinção importante é a responsabilidade pela complexidade.
Com proxies:
você controla a pilha.
Com uma API de scraping:
a plataforma de scraping gere uma parte maior da pilha.
Nenhum dos modelos é universalmente melhor.
Resolvem problemas de engenharia diferentes.
Proxy vs. Navegador vs. API de extração
| Solução | Altera o IP | Executa JS | Gere o navegador | Lida com a extração | A sua manutenção |
|---|
| Apenas proxy | Sim | Não | Não | Não | Elevada |
| Playwright + proxy | Sim | Sim | Você | Você | Elevada |
| Puppeteer + proxy | Sim | Sim | Você | Você | Elevada |
| API de scraping | Gerida | Sim, se for suportada | Gerida | Gerida | Mais baixa |
É por isso que dizer a alguém para «usar apenas proxies residenciais» é um conselho incompleto.
Às vezes, é exatamente isso de que precisam.
Outras vezes, o proxy é apenas uma parte de um problema muito maior.
Como resolver problemas com os bloqueios do DataDome
Quando as solicitações começarem a falhar, não altere dez coisas ao mesmo tempo.
Diagnostique a camada.
Problema: Funciona no navegador, falha no script
Áreas possíveis a investigar:
- execução de JavaScript;
- diferenças entre clientes HTTP/TLS;
- impressão digital do navegador;
- cookies;
- estado da sessão.
Alterar o IP pode não ter qualquer efeito se a falha tiver origem no cliente.
Problema: Funciona inicialmente, mas depois é bloqueado
Analise:
- taxa de pedidos;
- padrões de navegação repetidos;
- rotação de IP/sessão;
- problemas crescentes de reputação do IP;
- consistência da sessão.
O primeiro pedido e o milésimo pedido não são equivalentes.
Problema: O IP do centro de dados falha, mas o residencial funciona
A reputação da rede é provavelmente um fator importante na decisão.
Isso, no entanto, não prova que outros sinais estejam a ser ignorados.
Problema: O proxy residencial também falha
Não conclua imediatamente que o proxy residencial é defeituoso.
Investigue:
- impressão digital do navegador/cliente;
- características do TLS;
- requisitos de JavaScript;
- cookies;
- padrões de pedidos;
- conceção da sessão.
Problema: o CAPTCHA aparece repetidamente
Um ciclo de CAPTCHA pode indicar que a sessão, no seu conjunto, continua a parecer suspeita.
Encare o desafio como um sintoma, não necessariamente como a causa principal.
Problema: Países diferentes produzem resultados diferentes
Verifique se:
- o próprio site se comporta de forma diferente consoante a localização geográfica;
- a disponibilidade do conteúdo muda;
- o estado dos cookies permanece consistente;
- a geolocalização do IP corresponde à sessão pretendida.
O DataDome deteta proxies residenciais?
Sim, consegue.
Isto está explicitamente refletido na documentação de deteção do DataDome.
Isso não significa que todas as solicitações de proxies residenciais sejam bloqueadas.
Se assim fosse, os utilizadores legítimos que se encontram em redes partilhadas de consumidores criariam enormes problemas de falsos positivos.
A afirmação mais precisa é:
Um IP residencial é um indício, não uma prova de que se trata de um visitante humano.
A deteção moderna combina-o com outras evidências.
O DataDome deteta o Playwright?
O DataDome documenta modelos de deteção que abrangem navegadores instrumentados através de frameworks de automatização, incluindo o Playwright, o Puppeteer e o Selenium.
Isso não significa que todas as sessões do Playwright sejam automaticamente bloqueadas.
Significa que a suposição:
«O Playwright utiliza um navegador real, pelo que não pode ser detetado»
está incorreta.
O DataDome utiliza impressões digitais do navegador?
Sim.
As impressões digitais do navegador e do dispositivo fazem parte da arquitetura de deteção do DataDome.
Isto permite que o sistema compare informações expostas pelo navegador e pelo ambiente de execução, em vez de confiar em identificadores simples, como o cabeçalho User-Agent.
O DataDome utiliza impressões digitais TLS?
A documentação do DataDome faz referência a impressões digitais TLS e recomenda as impressões digitais JA3 e JA4 como sinais disponíveis para as suas integrações de API de proteção.
Isto é importante porque a ligação TLS é criada antes de a lógica normal da aplicação web ver o pedido.
Um scraper pode, portanto, ter cabeçalhos HTTP perfeitamente editados, mas continuar a expor uma impressão digital de rede diferente, de nível inferior.
O DataDome utiliza aprendizagem automática?
O DataDome descreve os seus modelos de deteção de ameaças como baseados em aprendizagem automática e atualizados continuamente.
A aprendizagem automática não é magia.
O seu valor prático, neste contexto, reside na capacidade de combinar vários sinais e padrões, em vez de depender de uma regra estática, como, por exemplo:
bloquear o IP após 100 pedidos.
O DataDome consegue bloquear agentes de IA?
Sim.
O mercado de gestão de bots está a expandir-se cada vez mais, indo além dos scrapers tradicionais para incluir agentes de IA e rastreadores LLM.
O DataDome suporta agora explicitamente a identificação e autenticação de bots comerciais e agentes de IA, enquanto o tráfego automatizado não autenticado pode ser sujeito às suas políticas de deteção de ameaças.
É provável que isto se torne cada vez mais importante, à medida que mais sistemas de IA navegam e interagem diretamente com os sites.
É possível contornar o DataDome?
Esta é, normalmente, a pergunta errada do ponto de vista da engenharia.
Não existe nenhum cabeçalho, tipo de proxy ou sinalizador do navegador permanente que faça um sistema de deteção moderno deixar de funcionar.
Uma configuração que funcione para um ponto final com um determinado volume de tráfego pode falhar:
- noutro ponto final;
- numa escala maior;
- com outra versão do navegador;
- após alterações nos modelos de deteção.
Para cargas de trabalho legítimas de dados da Web, a questão mais sustentável é:
Que parte da minha pilha de scraping está a fazer com que o pedido seja classificado como automação, e será que quero manter essa camada por conta própria?
Por vezes, a resposta é a infraestrutura de rede.
Utilize uma configuração de proxy adequada.
Por vezes, a resposta é a renderização.
Utilize um navegador.
Por vezes, a resposta é toda a pilha operacional.
Utilize uma API de scraping gerida.
E, por vezes, a resposta certa é utilizar, em vez disso, uma API oficial ou outra fonte de dados autorizada.
DataDome vs Cloudflare
A DataDome e a Cloudflare sobrepõem-se em algumas áreas do mercado de gestão de bots, mas não devem ser consideradas produtos idênticos.
A Cloudflare oferece uma ampla plataforma de infraestrutura que inclui CDN, DNS, WAF, mitigação de DDoS e funcionalidades de gestão de bots.
O DataDome está mais especificamente focado na deteção de bots e fraudes online em websites, aplicações móveis e APIs.
Do ponto de vista de um programador de scrapers, no entanto, a lição é semelhante:
a proteção anti-bot moderna opera em várias camadas.
Uma estratégia eficaz não pode basear-se exclusivamente na alteração de um único cabeçalho HTTP.
DataDome vs CAPTCHA
O DataDome não é um serviço CAPTCHA.
O CAPTCHA é uma das respostas possíveis após a deteção.
O sistema que decide, na realidade, se um cliente é suspeito, situa-se antes disso.
Esta distinção é importante porque os programadores dedicam frequentemente um enorme esforço a tentar «resolver o CAPTCHA», ignorando os sinais que levaram ao aparecimento do desafio.
A melhor pergunta é:
Porque é que esta sessão foi desafiada, para começar?
Quando faz sentido utilizar proxies residenciais
Os proxies residenciais são úteis quando a camada de rede é importante.
Entre os exemplos contam-se cargas de trabalho legítimas que envolvem:
- conteúdos públicos específicos de uma região;
- resultados de pesquisa localizados;
- preços regionais;
- disponibilidade de produtos;
- estudos de mercado;
- recolha distribuída de dados na Web.
São especialmente úteis quando se pretende manter o controlo total do seu próprio scraper.
Os Proxies Residenciais da Geonode fornecem encaminhamento de IP residencial com segmentação geográfica e comportamento de sessão configurável.
Mas um proxy deve continuar a ser o que realmente é:
infraestrutura de rede.
Não é um navegador.
Não é um sistema CAPTCHA.
Não é um motor de scraping.
E não repara automaticamente uma impressão digital danificada.
Quando um «Scraper API» faz mais sentido
Um «Scraper API» torna-se atraente quando a manutenção anti-bot começa a dominar o desenvolvimento.
Deve, pelo menos, considerar uma API gerida quando a sua equipa dedica mais tempo a:
- atualizações do navegador;
- lógica de repetição de tentativas;
- orquestração de proxies;
- renderização;
- extração;
- gestão de sessões;
- pedidos falhados;
do que à utilização dos próprios dados.
Com Geonode Scraper API, uma aplicação pode enviar URLs e receber HTML ou Markdown extraídos, enquanto o serviço gere a renderização e a infraestrutura de proxy por trás da solicitação.
A escolha é simples:
Desenvolver por conta própria dá mais controlo.
Utilizar uma API elimina o trabalho de infraestrutura.
Escolha com base no que o seu produto realmente precisa.
Perguntas frequentes
O que é o DataDome?
O DataDome é uma plataforma de proteção contra bots e fraudes online concebida para identificar tráfego automatizado e malicioso em websites, aplicações móveis e APIs.
Como é que o DataDome deteta bots?
Combina vários sinais, incluindo reputação de IP, impressões digitais HTTP e do navegador, características TLS, informações do dispositivo, padrões comportamentais e modelos de deteção baseados em aprendizagem automática.
Por que razão o DataDome bloqueia o meu scraper?
Raramente existe uma razão única. O endereço IP, o cliente HTTP/TLS, o ambiente do navegador, o suporte a JavaScript, a consistência da sessão ou o comportamento das solicitações podem todos contribuir para isso.
O DataDome utiliza CAPTCHA?
Sim, o CAPTCHA pode ser uma resposta ao tráfego suspeito. O DataDome também pode realizar uma verificação invisível do dispositivo (Device Check) ou bloquear diretamente as solicitações.
O que é a verificação de dispositivo do DataDome?
A verificação de dispositivo é um mecanismo de verificação adicional que executa verificações do lado do cliente sem exigir necessariamente uma interação visível do utilizador. Avalia sinais do dispositivo e de execução e pode permitir, desafiar ou bloquear o cliente, dependendo do resultado.
Alterar o meu User-Agent contorna o DataDome?
Alterar o User-Agent modifica apenas um valor HTTP. Não altera automaticamente a ligação TLS, o ambiente do navegador, a impressão digital do dispositivo, os cookies ou o comportamento.
O DataDome consegue detetar o Chrome «headless»?
O DataDome documenta especificamente categorias de deteção para navegadores «headless» e automatizados, incluindo navegadores instrumentados através do Puppeteer, Selenium e Playwright.
O DataDome consegue detetar o Playwright?
Consegue identificar características associadas à automatização do navegador, incluindo ambientes controlados pelo Playwright. A utilização do Playwright não significa automaticamente que uma sessão será bloqueada, mas não deve ser considerada inerentemente invisível.
O DataDome consegue detetar o Puppeteer?
Sim, o DataDome documenta modelos de deteção que abrangem a automação baseada no Puppeteer e o Puppeteer Extra Stealth.
O DataDome consegue detetar proxies residenciais?
O DataDome dispõe de modelos de deteção relacionados com o tráfego encaminhado através de proxies residenciais. Um IP residencial pode continuar a ser útil, uma vez que altera a identidade da rede, mas não torna o tráfego automatizado automaticamente legítimo.
Os proxies residenciais são melhores do que os proxies de centro de dados para sites protegidos pelo DataDome?
Os proxies residenciais podem fornecer uma identidade de rede mais próxima do tráfego normal dos consumidores, o que pode ser útil em sites voltados para o consumidor. A escolha correta continua a depender do alvo, da carga de trabalho e de outras camadas de deteção.
Preciso de um navegador para extrair dados de um site protegido pelo DataDome?
Nem todas as páginas protegidas requerem um navegador. No entanto, os sites que dependem de renderização do lado do cliente ou da verificação de dispositivos podem exigir a execução genuína de JavaScript e um estado do navegador que um cliente HTTP básico não consegue fornecer.
Por que recebo erros 403 do DataDome?
Um erro 403 pode indicar que o pedido foi classificado como suspeito ou automatizado. Verifique se a resposta provém efetivamente do DataDome antes de assumir que o sistema anti-bot é o responsável.
Por que é que a página funciona manualmente, mas não em Python?
O seu navegador normal e a biblioteca HTTP do Python produzem ambientes de rede, TLS, HTTP, JavaScript e de navegador muito diferentes. Um sistema anti-bot pode detetar algumas dessas diferenças.
Por que razão o meu scraper funciona durante algumas solicitações e depois pára?
As causas possíveis incluem deteção comportamental, padrões de taxa, alterações na reputação do IP ou sessões inconsistentes. Os sistemas anti-bot podem avaliar a atividade ao longo de várias solicitações, em vez de julgar cada solicitação isoladamente.
A rotação de proxies resolve o problema do DataDome?
Por si só, não.
A rotação altera a identidade de rede. Não altera automaticamente a impressão digital do navegador, o cliente TLS, o ambiente JavaScript ou o comportamento das solicitações.
Uma API de scraping é melhor do que os proxies?
Resolvem problemas diferentes.
Utilize proxies quando quiser controlar o seu scraper e precisar principalmente de infraestrutura de rede.
Utilize uma API de scraping quando quiser que grande parte da infraestrutura do navegador, do proxy, da renderização e da extração seja gerida por si.
Conclusão
O mais importante a compreender sobre o DataDome é que não existe um único «sinal de bot».
A deteção anti-bot moderna analisa várias camadas.
Um pedido não é apenas um endereço IP.
É:
um IP
que estabelece uma ligação TLS
que envia cabeçalhos HTTP
a partir de um navegador ou aplicação
no âmbito de uma sessão
com um histórico
e um padrão de comportamento.
Quanto mais esses elementos forem consistentes entre si, mais coerente o cliente parecerá.
É por isso que mudar de IP pode resolver um problema e deixar outros cinco por resolver.
É por isso que o Playwright resolve a execução de JavaScript sem resolver todos os problemas de deteção.
E é por isso que as APIs de scraping geridas existem, em primeiro lugar.
Se precisar de controlo total, construa a pilha por si próprio e utilize proxies como infraestrutura de rede.
Se precisar principalmente de conteúdo web fiável sem ter de gerir navegadores e a orquestração de proxies, utilize uma API de scraping.
O importante é saber qual é a camada que está realmente a tentar resolver.
