Situação clássica: o script para monitoramento de preços no Wildberries ou Ozon funciona perfeitamente no laptop doméstico, mas após a transferência para um VPS começa a receber 403, captcha ou banimento instantâneo por IP. O desenvolvedor altera os cabeçalhos, adiciona atrasos — mas o resultado não muda. O problema quase nunca está no código do parser em si, mas no ambiente de onde ele faz as solicitações. Vamos analisar 7 razões específicas e o que mudar para que o parser funcione de forma estável no servidor.
Por que funciona localmente, mas no servidor é banido
Quando você executa o parser a partir de um computador doméstico, o site vê a solicitação de um IP residencial comum do seu provedor, da região habitual, com um ambiente de navegador real, se você estiver usando Selenium ou Playwright com um perfil verdadeiro. Assim que o mesmo script se muda para um VPS na Alemanha, Países Baixos ou EUA, a situação muda completamente: o IP pertence a um data center, o fingerprint TLS pode diferir devido a outra versão das bibliotecas, o fuso horário do servidor não coincide com a geolocalização do IP, e a frequência das solicitações aumenta drasticamente, pois o servidor opera 24/7 sem pausas.
Sistemas anti-bot do Wildberries, Ozon, Avito e a maioria dos grandes marketplaces há muito não olham apenas para o User-Agent. Eles analisam uma combinação de dezenas de sinais: tipo de IP, velocidade e regularidade das solicitações, comportamento na página, correspondência de cabeçalhos e parâmetros TLS, presença de cookies e histórico de sessão. A máquina local passa aleatoriamente no teste em muitos pontos, enquanto o servidor falha em quase todos. Abaixo, uma análise detalhada de cada razão.
Razão 1: IP do data center em vez de IP residencial
Esta é a razão número 1 em 80% dos casos. Os endereços IP de VPS e servidores em nuvem (AWS, DigitalOcean, Hetzner, hospedagens VDS comuns) estão em bancos de dados de data centers — os ASN desses provedores são publicamente conhecidos e utilizados por sistemas anti-bot para filtragem instantânea de tráfego. Os marketplaces aplicam tais listas em primeiro lugar, pois 95% da raspagem automatizada vem exatamente de IPs de servidores.
A solução é usar IPs que visualmente não se diferenciam de um usuário comum da internet. Para a raspagem do Wildberries, Ozon e Avito, os proxies residenciais são os mais adequados: são endereços IP reais de provedores domésticos, atribuídos a assinantes comuns. Sistemas anti-bot veem tal solicitação como tráfego de um usuário real, e não de um servidor em um data center, o que elimina a maior parte dos bloqueios imediatamente.
Razão 2: Sem rotação de IP e limite de frequência de solicitações
Na máquina local, você faz de 20 a 50 solicitações manualmente durante os testes, e o site não percebe. No servidor, o script é executado via cron a cada 5 minutos e processa milhares de cartões de produtos consecutivamente de um único IP. Tal padrão é um sinal direto para o sistema anti-bot: uma pessoa real não pode abrir 3000 páginas do catálogo em uma hora sem uma única pausa.
É necessário implementar a rotação de IP em um pool de proxies e limitar o número de solicitações para um endereço em uma unidade de tempo. Regra prática: não mais de 30 a 60 solicitações de um IP por minuto para cartões de produtos, com troca automática de endereço após cada lote de solicitações. Exemplo de configuração de rotação em Python através de um pool de proxies:
import requests
proxies_pool = [
"http://user:[email protected]:9000",
"http://user:[email protected]:9001",
"http://user:[email protected]:9002",
]
def get_page(url, session_id):
proxy = proxies_pool[session_id % len(proxies_pool)]
resp = requests.get(
url,
proxies={"http": proxy, "https": proxy},
headers={"User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64)"},
timeout=10
)
return resp.textAo coletar um grande volume de cartões por dia, é mais conveniente usar proxies com rotação automática de IP por solicitação ou por timer — isso elimina a necessidade de manter uma lista de endereços manualmente.
Razão 3: Cabeçalhos e User-Agent não se parecem com um navegador
Muitos parsers em requests ou aiohttp enviam solicitações com um conjunto mínimo de cabeçalhos ou com o User-Agent padrão da biblioteca, que imediatamente revela o script (por exemplo, python-requests/2.31.0). Na máquina local, através do navegador, o conjunto de cabeçalhos é completo: Accept, Accept-Language, Accept-Encoding, Sec-Ch-Ua, Referer e outros — sua combinação parece natural.
É necessário copiar o conjunto completo de cabeçalhos de um navegador real, incluindo a ordem de envio — alguns sistemas anti-bot verificam até isso. Além disso, é importante rotacionar o User-Agent em sincronia com a versão do fingerprint TLS (veja o próximo ponto), caso contrário, a discrepância entre o cabeçalho do navegador e o cliente TLS real se tornará um novo sinal de bot.
Razão 4: O fingerprint TLS/JA3 revela o script
Esta é uma razão menos conhecida, mas extremamente comum para banimentos, especialmente no servidor. As bibliotecas requests, urllib, aiohttp usam sua implementação do handshake TLS, que difere da implementação no Chrome ou Firefox. Sistemas anti-bot calculam o fingerprint JA3/JA4 da conexão TLS — e ele no script Python não se parece em nada com o fingerprint de um navegador real, mesmo que os cabeçalhos sejam copiados perfeitamente.
A solução é usar bibliotecas que emulam o fingerprint TLS do navegador (por exemplo, curl_cffi, tls-client em Python, ou um navegador headless completo baseado em Chromium através do Playwright/Puppeteer). A segunda opção é trabalhar não através de um cliente HTTP puro, mas através de um mecanismo de navegador controlado em conjunto com uma ferramenta anti-detect, onde TLS e cabeçalhos são formados pelo núcleo real do navegador, e não pela emulação da biblioteca.
Razão 5: Fuso horário, localidade e servidores DNS
Se o script emula um navegador através do Selenium ou Playwright, o sistema anti-bot pode verificar o fuso horário do sistema, o idioma da interface, o resolvedor DNS e até mesmo a vazamento WebRTC do IP real do servidor. Um VPS em um data center em Frankfurt com fuso horário do sistema UTC e provedor DNS do host, ao mesmo tempo usando um proxy com IP de Moscovo, cria uma discrepância clara de geodados — este é um dos sinais mais confiáveis para detecção.
Todos os parâmetros do ambiente — fuso horário, idioma do navegador, DNS, geolocalização via WebRTC — devem corresponder à região do endereço IP usado para a solicitação. É exatamente para resolver essa tarefa que foram criados navegadores anti-detect: Dolphin Anty, AdsPower, Multilogin, Octo Browser e GoLogin permitem configurar um "perfil de navegador" separado para cada proxy, onde automaticamente se ajustam o fuso horário, localidade, resolução de tela e WebRTC à geolocalização do IP.
Razão 6: O padrão de solicitações é muito "robotizado"
Uma pessoa navega pelo catálogo com diferentes pausas, clica em produtos aleatórios, às vezes volta, rola a página de maneira desigual. O script do servidor geralmente faz solicitações em intervalos iguais (por exemplo, exatamente a cada 2 segundos) e acessa apenas os URLs necessários sem "ruído" ao redor — sem carregar imagens, scripts, sem visitar a página inicial antes do cartão do produto.
O que mudar: adicionar atrasos aleatórios (não fixos de 2 segundos, mas aleatórios de 1,5 a 6 segundos), ocasionalmente acessar páginas intermediárias (categoria → cartão, e não solicitação direta à API), emular rolagem e movimentos do mouse ao trabalhar através de um navegador headless. Isso aumenta o tempo de coleta de dados, mas reduz drasticamente o número de banimentos.
Razão 7: Sessões e cookies não são mantidos entre solicitações
Muitas vezes, o parser no servidor cria uma nova sessão de solicitações para cada solicitação — sem cookies, sem token de autorização salvo, sem histórico de visitas. Marketplaces como Wildberries e Ozon emitem cookies temporários e tokens na primeira visita, e solicitações subsequentes sem eles parecem suspeitas, como se cada solicitação fosse feita por um novo visitante anônimo.
O esquema correto: uma sessão (requests.Session() ou contexto do navegador) — para um IP do pool de proxies, mantendo os cookies durante toda a série de solicitações para esse IP. Ao mudar de proxy, é necessário iniciar uma nova sessão com cookies limpos, simulando um novo usuário, e não continuar usando cookies antigos com um novo IP — isso também cria discrepâncias e aciona bloqueios.
Checklist: o que mudar em ordem
Se o parser é constantemente banido no servidor, mas funciona localmente, verifique as alterações nesta ordem — assim você encontrará a causa mais rapidamente:
| Passo | O que verificar | O que mudar |
|---|---|---|
| 1 | Tipo de IP do servidor | Mudar para proxies residenciais em vez de IP direto de hospedagem |
| 2 | Frequência de solicitações | Implementar rotação de IP e limite de solicitações por endereço |
| 3 | Cabeçalhos da solicitação | Copiar o conjunto completo de cabeçalhos de um navegador real |
| 4 | Fingerprint TLS | Usar curl_cffi / navegador headless em vez de requests puro |
| 5 | Fuso horário e localidade | Configurar perfil no Dolphin Anty / AdsPower para a região do IP |
| 6 | Padrão de comportamento | Randomizar atrasos, adicionar páginas intermediárias |
| 7 | Sessões e cookies | Vincular uma sessão a um IP durante todo o ciclo de solicitações |
Para a raspagem de alta frequência dos catálogos Wildberries e Ozon, onde a velocidade de navegação por milhares de páginas é importante, muitas vezes combinam-se dois tipos de proxies: proxies de data center para solicitações técnicas preliminares (verificação de disponibilidade, códigos de status) e residenciais — para a coleta final de dados dos cartões, onde a camuflagem como um usuário real é importante. Para aplicativos móveis de marketplaces e Avito, às vezes é mais eficaz usar proxies móveis, pois eles raramente entram nas listas de bloqueio automática por ASN.
Conclusão
O banimento do parser no servidor ao funcionar a versão local está quase sempre relacionado não à lógica do script, mas ao ambiente: tipo de IP, fingerprint TLS, cabeçalhos, fuso horário, padrão de solicitações e gerenciamento de sessões. Verificando cada uma das 7 razões em ordem — da mais comum (IP do data center) à mais sutil (incompatibilidade entre o fuso horário e a região do IP) — é possível restaurar o funcionamento estável do parser sem alterar a lógica de negócios principal da coleta de dados.
Se você está coletando preços e estoques no Wildberries, Ozon ou Avito em volumes industriais, comece substituindo o IP: experimente proxies residenciais em vez do endereço padrão do VPS — na maioria dos casos, isso elimina até 70% dos bloqueios antes mesmo de você começar a ajustar cabeçalhos e fingerprints TLS.