Ao fazer scraping de marketplaces, automatizar o trabalho com redes sociais ou coletar dados via API, é crucial escolher a estratégia de envio de consultas corretamente. Uma configuração inadequada leva a bloqueios de IP, captchas e perda de tempo. Neste guia, vamos discutir quando usar consultas paralelas para máxima velocidade e quando usar sequenciais para segurança.
Diferenças entre consultas paralelas e sequenciais
Consultas sequenciais são quando seu script ou programa envia consultas uma após a outra: espera pela resposta da primeira consulta, só então envia a segunda. Isso é lento, mas seguro e parece o mais natural possível para o site de destino.
Consultas paralelas são quando várias consultas (5, 10, 50 ou até centenas) são enviadas simultaneamente, sem esperar pelas respostas das anteriores. Isso é muito mais rápido, mas cria carga no servidor e pode levantar suspeitas dos sistemas antifraude.
Imagine fazer scraping de preços de 10.000 produtos no Wildberries. Sequencialmente, com um atraso de 2 segundos entre as consultas, isso levaria 20.000 segundos ou 5,5 horas. Se você iniciar 20 fluxos paralelos, levará apenas 16 minutos. A diferença é óbvia, mas há nuances.
Importante: Consultas paralelas não significam "enviar 1000 consultas ao mesmo tempo". É uma paralelidade controlada — por exemplo, 10-50 fluxos ativos, cada um com atrasos. Sem controle, você será banido instantaneamente.
Comparação de métodos
| Parâmetro | Sequenciais | Paralelas |
|---|---|---|
| Velocidade | Lento (1 consulta por vez) | Rápido (10-100+ simultaneamente) |
| Risco de bloqueio | Baixo | Médio-alto |
| Carga no proxy | Mínima | Alta |
| Complexidade de configuração | Simples | Requer experiência |
| Consumo de memória | Baixo | Alto |
| Tratamento de erros | Mais fácil de rastrear | Mais difícil de registrar |
Quando usar consultas paralelas
Consultas paralelas são a escolha quando a velocidade é crítica e o volume de dados é grande. Mas é importante entender: isso funciona apenas com a configuração correta do proxy e controle de carga.
Cenários ideais para consultas paralelas
1. Scraping de marketplaces com um grande catálogo
Se você precisa coletar preços de 50.000 produtos no Wildberries ou Ozon, o scraping sequencial levará dias. Com 20-30 fluxos paralelos e proxies de data center, a tarefa é resolvida em algumas horas.
Configuração: 20-30 fluxos, cada um com um IP separado, atraso de 1-3 segundos entre consultas dentro do fluxo. Rotação de IP a cada 100-200 consultas.
2. Coleta de dados de APIs públicas
Muitas APIs (por exemplo, serviços de clima, bancos de dados de empresas, serviços de geolocalização) têm limites de consultas de um único IP: 100-1000 por dia. Consultas paralelas através de um pool de proxies permitem contornar esses limites.
Exemplo: Você precisa coletar dados sobre 10.000 empresas através da API. O limite é de 500 consultas/dia por IP. Usando 20 proxies em paralelo = 10.000 consultas em um dia em vez de 20 dias.
3. Verificação de disponibilidade de recursos
Se você está verificando a disponibilidade de sites, o funcionamento de espelhos ou monitorando o status de servidores — consultas paralelas economizam horas. Aqui, não é necessária a simulação do comportamento humano, apenas a velocidade é importante.
4. Verificação em massa de proxies
Ao comprar grandes pools de proxies (1000+ IPs), é necessário verificar rapidamente sua funcionalidade, velocidade e geolocalização. A verificação sequencial levará horas, enquanto a paralela levará minutos.
Atenção: Consultas paralelas NÃO são adequadas para trabalhar com plataformas protegidas (Facebook Ads, Instagram API, Google Ads), onde a simulação do comportamento do usuário real é importante. Para essas, use consultas sequenciais.
Requisitos chave para consultas paralelas
- Grande pool de proxies (mínimo 10-20 IPs, melhor 50-100+)
- Rotação automática de IPs em caso de erros
- Controle do número de fluxos simultâneos (não mais que 50-100)
- Atrasos entre consultas mesmo dentro dos fluxos (0.5-2 seg)
- Registro de erros para análise das causas de bloqueios
- Sistema de retry (tentativas de repetição) em caso de timeouts
Quando usar consultas sequenciais
Consultas sequenciais são a escolha de segurança e confiabilidade sobre velocidade. Elas imitam o comportamento de um usuário real e minimizam o risco de bloqueios em plataformas protegidas.
Cenários obrigatórios para consultas sequenciais
1. Trabalho com painéis de anúncios
Facebook Ads, TikTok Ads, Google Ads monitoram não apenas o IP, mas também os padrões de comportamento. Consultas paralelas de uma única conta levantarão suspeitas instantaneamente. Uma conta = um fluxo = ações sequenciais com atrasos de 5-15 segundos.
Exemplo: Você gerencia 20 contas de anúncios do Facebook através do navegador anti-detect Dolphin Anty. Cada conta opera em um perfil separado com proxy móvel, as ações são estritamente sequenciais: login → verificação de estatísticas → ajuste de lances → logout. Atrasos de 7-12 segundos entre as ações.
2. Automação de ações em redes sociais
Instagram, TikTok, VK têm limites rígidos em ações: curtidas, seguidores, comentários. Exceder os limites ou agir muito rapidamente = shadowban ou bloqueio total. Apenas consultas sequenciais com atrasos aleatórios de 20-60 segundos.
Configuração para Instagram: Uma conta faz no máximo 60 curtidas/hora. Isso é 1 curtida por minuto com atrasos de 45-75 segundos (a randomização é importante!). Use um proxy separado para cada conta.
3. Autenticação e trabalho com contas pessoais
Qualquer ação que exija login em uma conta (serviços de email, bancos, marketplaces como vendedor) deve ser executada sequencialmente. Tentativas paralelas de login de diferentes IPs em uma conta são um caminho direto para o bloqueio.
4. Sites com proteção anti-bot rigorosa
Plataformas com Cloudflare, Akamai, PerimeterX analisam não apenas a frequência de consultas, mas também seus padrões. Se de um único IP ou User-Agent chegam 10 consultas simultaneamente — isso é um sinal claro de bot. Consultas sequenciais com atrasos de 3-10 segundos parecem naturais.
5. Pequeno volume de dados
Se você precisa fazer scraping de 50-100 páginas, a diferença de tempo entre scraping sequencial e paralelo é insignificante (5 minutos contra 1 minuto). Mas o método sequencial garante a ausência de problemas.
Atrasos corretos para consultas sequenciais
| Plataforma/tarefa | Atraso entre consultas | Randomização |
|---|---|---|
| Facebook Ads (ações no painel) | 7-15 segundos | ±30% |
| Instagram (curtidas, seguidores) | 45-90 segundos | ±40% |
| TikTok (visualizações, curtidas) | 30-60 segundos | ±35% |
| Google Ads (consultas API) | 5-10 segundos | ±25% |
| Scraping com Cloudflare | 3-7 segundos | ±30% |
| Sites comuns sem proteção | 1-3 segundos | ±20% |
Dica: A randomização de atrasos é crítica. Se seu script faz uma consulta exatamente a cada 5.00 segundos — isso é um padrão de bot. Use random de 4 a 7 segundos para imitar um humano.
Riscos de bloqueio com diferentes métodos
Compreender os riscos ajuda a escolher a estratégia correta e configurar a proteção. Bloqueios ocorrem não apenas devido à frequência de consultas, mas também devido aos seus padrões.
O que os sistemas antifraude monitoram
1. Frequência de consultas de um único IP
Se de um único IP chegam 100 consultas por minuto — isso é um bot óbvio. Os limites variam: sites comuns toleram 10-30 consultas/minuto, plataformas protegidas — 2-5 consultas/minuto.
Solução para consultas paralelas: Distribua as consultas por um grande pool de IPs. Por exemplo, 1000 consultas/minuto = 50 IPs com 20 consultas cada. Isso parece como 50 usuários comuns.
2. Intervalos iguais entre consultas
Consultas exatamente a cada 2.00 segundos — sinal de automação. Um humano clica com intervalos variados: 1.8 seg, 3.2 seg, 2.1 seg.
Solução: Adicione randomização ±30-50% do atraso base. Em vez de 5 segundos fixos, use random(3.5, 7.5).
3. Ausência de comportamento típico do usuário
Um usuário real não vai diretamente para a página do produto — ele primeiro acessa a página inicial, procura a categoria, clica no produto. Um bot solicita diretamente uma URL específica.
Solução para plataformas críticas: Imite todo o caminho do usuário. Antes de fazer scraping do produto, faça 2-3 consultas: página inicial → categoria → produto. Isso desacelera o trabalho, mas reduz o risco de bloqueio em 70-80%.
4. User-Agents e cabeçalhos suspeitos
User-Agents desatualizados (por exemplo, Chrome 95 em 2024), ausência de cabeçalhos Accept-Language, Referer — sinais de bot.
Solução: Use User-Agents atualizados (Chrome 120+, Firefox 120+), adicione um conjunto completo de cabeçalhos como em um navegador real. Rode o User-Agent junto com o IP.
Comparação de riscos de bloqueio
| Cenário | Risco em sequenciais | Risco em paralelas |
|---|---|---|
| Scraping de marketplace (10K consultas) | Baixo (5-10%) | Médio (20-30%) |
| Trabalho com Facebook Ads | Baixo (2-5%) | Crítico (80-95%) |
| Automação do Instagram | Médio (15-25%) | Alto (60-80%) |
| APIs públicas (dentro dos limites) | Muito baixo (1-3%) | Baixo (5-10%) |
| Sites com Cloudflare | Médio (10-20%) | Alto (40-60%) |
Quais proxies são adequados para cada método
O tipo de proxy influencia diretamente a possibilidade de usar consultas paralelas ou sequenciais. A escolha errada levará a bloqueios ou a pagar a mais.
Proxies para consultas paralelas
Proxies de data center — a escolha ideal para scraping em massa e consultas paralelas. Eles são baratos (a partir de $1-3 por IP/mês), rápidos (ping de 20-50 ms) e disponíveis em grandes volumes. A desvantagem — são facilmente identificados como proxies, portanto não são adequados para plataformas protegidas.
Quando usar: Scraping de marketplaces, coleta de dados de fontes públicas, verificação de disponibilidade de recursos, consultas API em massa a serviços sem proteção rigorosa.
Configuração: Compre um pool de 50-100 IPs, configure 20-30 fluxos paralelos, cada fluxo usa seu próprio IP. Rotação a cada 100-200 consultas ou em caso de erro.
Proxies residenciais — mais caros (a partir de $3-7 por 1 GB de tráfego), mas parecem usuários reais. Adequados para consultas paralelas em plataformas protegidas, se a velocidade for necessária, mas com cautela.
Quando usar: Scraping de redes sociais (sem autenticação), coleta de dados de sites com Cloudflare, trabalho com plataformas que bloqueiam data centers. Para consultas paralelas, é necessário um grande pool de IPs com rotação automática.
Importante: Ao usar proxies residenciais para consultas paralelas, controle o consumo de tráfego. 10.000 consultas podem "consumir" 5-10 GB, o que custará entre $20-50. Data centers são mais baratos: tráfego ilimitado por $100-200/mês para 100 IPs.
Proxies para consultas sequenciais
Proxies móveis — o tipo mais confiável para trabalhar com plataformas protegidas. Os IPs parecem dispositivos móveis reais (operadoras 4G/5G), o que minimiza o risco de bloqueios. A desvantagem — são caros (a partir de $50-150 por IP/mês).
Quando usar: Facebook Ads, Instagram, TikTok, Google Ads — tudo onde a segurança máxima e a simulação do usuário real são necessárias. Uma conta = um proxy móvel = ações sequenciais.
Configuração: Cada conta de anúncio ou rede social está vinculada a um IP móvel separado. As ações são estritamente sequenciais com atrasos de 10-60 segundos. O IP não é rotacionado (uma conta sempre opera a partir de um IP).
Proxies residenciais — uma boa alternativa aos móveis, se o orçamento for limitado. Adequados para tarefas menos críticas: scraping com autenticação, automação de SMM, trabalho com marketplaces como vendedor.
Quando usar: Gerenciamento de contas de marketplaces (Wildberries, Ozon como vendedor), automação de postagens em redes sociais (não em massa), scraping de dados que exigem autenticação.
Recomendações para escolha de proxies
| Tarefa | Tipo de proxy | Método de consultas | Número de IPs |
|---|---|---|---|
| Scraping de marketplaces (grande volume) | Data centers | Paralelas | 50-100+ |
| Facebook Ads (multi-conta) | Móveis | Sequenciais | 1 IP por conta |
| Automação do Instagram | Móveis/residenciais | Sequenciais | 1 IP por conta |
| Scraping com Cloudflare | Residenciais | Paralelas (com cautela) | 20-50 |
| APIs públicas (coleta em massa) | Data centers | Paralelas | 10-30 |
| Marketplaces (painel do vendedor) | Residenciais | Sequenciais | 1 IP por conta |
Configurações ideais: atrasos, fluxos, timeouts
A configuração correta dos parâmetros é crítica para o equilíbrio entre velocidade e segurança. Configurações muito agressivas levarão a bloqueios, enquanto configurações muito cautelosas resultarão em perda de tempo.
Configuração de consultas paralelas
Número de fluxos simultâneos (concurrency)
Este é um parâmetro chave. Muitos fluxos = sobrecarga no proxy e no servidor de destino. Poucos fluxos = baixa velocidade.
Recomendações:
- Scraping de marketplaces: 20-50 fluxos com um pool de 50+ proxies
- APIs públicas: 10-30 fluxos, baseando-se nos limites da API
- Sites com proteção: 5-15 fluxos, mais que isso — risco de bloqueio
- Verificação de proxies: 50-100 fluxos (aqui a velocidade é mais importante)
Atrasos dentro dos fluxos
Mesmo ao trabalhar em paralelo, cada fluxo deve fazer pausas entre suas consultas. Isso reduz a carga em um único IP e diminui o risco de bloqueio.
Recomendações:
- Sites simples: 0.5-2 segundos entre consultas em um único fluxo
- Marketplaces: 1-3 segundos com randomização ±30%
- Sites com Cloudflare: 2-5 segundos com randomização ±40%
- APIs com limites: calcule com base no limite (por exemplo, 100 consultas/minuto = 0.6 seg/consulta, faça 1 seg para margem)
Timeouts (timeout)
Tempo de espera pela resposta do servidor. Um timeout muito curto = perda de dados devido a respostas lentas. Um timeout muito longo = bloqueio de fluxos.
Recomendações:
- Sites rápidos: 10-15 segundos
- Sites/API lentos: 20-30 segundos
- Através de proxies residenciais: +5-10 segundos (eles são mais lentos que os de data center)
- Connection timeout: 5-10 segundos (tempo de estabelecimento de conexão)
Retry (tentativas de repetição)
Em caso de erros (timeout, 503, bloqueio de proxy) é necessário repetir a consulta com outro IP. Sem retry, você perderá parte dos dados.
Configuração: 2-3 tentativas por consulta, troca de proxy após cada tentativa malsucedida, pausa de 3-5 segundos antes do retry.
Configuração de consultas sequenciais
Atraso base entre consultas
Depende da plataforma e do tipo de ações. A regra principal: imitar um usuário real.
Recomendações por plataforma:
- Facebook Ads (transições entre seções do painel): 7-15 segundos
- Instagram (curtidas): 45-90 segundos, máximo 60 curtidas/hora
- Instagram (seguidores): 60-120 segundos, máximo 30 seguidores/hora
- TikTok (visualizações): 30-60 segundos
- Scraping com autenticação: 3-7 segundos
- Marketplaces (ações no painel do vendedor): 5-10 segundos
Randomização
É obrigatória para todas as consultas sequenciais. Use uma variação de ±30-50% do atraso base.
Exemplo: Atraso base de 10 segundos, randomização ±40% → os atrasos reais serão de 6-14 segundos (valor aleatório a cada vez).
Timeouts
Para consultas sequenciais, você pode usar timeouts mais longos, pois não há risco de bloqueio de todos os fluxos.
Recomendações: 30-60 segundos para plataformas protegidas (Facebook, Instagram), 15-30 segundos para sites comuns.
Dica prática: Comece com configurações conservadoras (menos fluxos, mais atrasos), aumentando gradualmente a agressividade, monitorando a porcentagem de erros. Se os erros >5-10% — volte um passo.
Ferramentas para implementar ambos os métodos
A escolha da ferramenta depende da sua tarefa e habilidades técnicas. Para tarefas de negócios (arbitragem, SMM, e-commerce), use soluções prontas sem código. Para tarefas técnicas — bibliotecas e frameworks.
Soluções prontas sem código (para negócios)
Navegadores anti-detect para multi-contas
Se você trabalha com painéis de anúncios ou redes sociais, navegadores anti-detect são o padrão da indústria. Eles gerenciam automaticamente proxies, impressões de navegador e isolam contas.
Soluções populares:
- Dolphin Anty: líder para arbitradores do Facebook/TikTok, plano gratuito para 10 perfis, configuração simples de proxies
- AdsPower: bom para e-commerce (Amazon, eBay), possui automação via RPA (sem código)
- Multilogin: o mais caro ($100+/mês), mas máxima proteção para arbitragem séria
- GoLogin: alternativa econômica ($25/mês), adequada para SMM e pequenas equipes
Como funcionam com proxies: Você cria um perfil de navegador → vincula proxies → todas as ações nesse perfil vão através desse IP. Um perfil = uma conta = ações sequenciais. Para trabalho paralelo, você abre vários perfis ao mesmo tempo (cada um com seu proxy).
Scrapers e parsers (prontos)
Para coletar dados de marketplaces e sites, existem ferramentas prontas com GUI, que não exigem programação.
- Octoparse: construtor visual de parsers, suporte a proxies, pode configurar fluxos paralelos através da interface
- ParseHub: análogo ao Octoparse, plano gratuito para 200 páginas, configuração de atrasos através da GUI
- Scrapy Cloud: serviço em nuvem para executar spiders Scrapy (requer conhecimentos mínimos de Python)
Automação de SMM (sem código)
Para gerenciar redes sociais, existem serviços com automação através da interface.
- Jarvee: automação do Instagram, TikTok, Twitter, suporte embutido a proxies, configuração de atrasos através da GUI (cuidado: automação agressiva leva a bloqueios)
- Ingramer (Inflact): automação segura do Instagram, funciona através de seus proxies
- Combin: seguidores/curtidas direcionadas no Instagram, suporte a proxies externos
Ferramentas técnicas (para desenvolvedores)
Se você está escrevendo seus scripts para scraping ou automação, use bibliotecas confiáveis.
Python (o mais popular para scraping):
- Requests + threading/asyncio: para consultas paralelas simples, fácil de configurar proxies
- aiohttp: biblioteca assíncrona para consultas altamente paralelas (1000+ simultaneamente)
- Scrapy: framework para scraping, suporte embutido a rotação de proxies, middleware para atrasos
- Selenium: para sites com JavaScript, mais lento, mas contorna muitas proteções
- Playwright: alternativa moderna ao Selenium, mais rápida e conveniente
JavaScript/Node.js:
- Axios: biblioteca popular para consultas HTTP, configuração simples de proxies
- Puppeteer: biblioteca para automação de navegadores, ideal para scraping de sites complexos