Quando si effettua scraping di marketplace, automazione dei social media o raccolta di dati tramite API, è fondamentale scegliere correttamente la strategia di invio delle richieste. Una configurazione errata porta a blocchi IP, CAPTCHA e perdita di tempo. In questa guida, analizzeremo quando utilizzare richieste parallele per la massima velocità e quando richieste sequenziali per la sicurezza.
Qual è la differenza tra richieste parallele e sequenziali
Richieste sequenziali sono quando il tuo script o programma invia richieste una dopo l'altra: aspetta la risposta alla prima richiesta, solo dopo invia la seconda. Questo è lento, ma sicuro e appare il più naturale possibile per il sito target.
Richieste parallele sono quando vengono inviate più richieste contemporaneamente (5, 10, 50 o anche centinaia), senza aspettare le risposte alle precedenti. Questo è di gran lunga più veloce, ma crea un carico sul server e può suscitare sospetti nei sistemi antifrode.
Immagina di fare scraping dei prezzi di 10.000 prodotti su Wildberries. In sequenza con un ritardo di 2 secondi tra le richieste, ci vorrebbero 20.000 secondi o 5,5 ore. Se avvii 20 flussi paralleli, ci vorrebbero solo 16 minuti. La differenza è evidente, ma ci sono delle sfumature.
Importante: Le richieste parallele non significano "inviare 1000 richieste contemporaneamente". Questa è una parallelità controllata — ad esempio, 10-50 flussi attivi, ciascuno con ritardi. Senza controllo, riceverai immediatamente un ban.
Confronto dei metodi
| Parametro | Sequenziali | Paralleli |
|---|---|---|
| Velocità | Lento (1 richiesta alla volta) | Veloce (10-100+ contemporaneamente) |
| Rischio di blocco | Basso | Medio-alto |
| Carico sui proxy | Minimo | Alto |
| Difficoltà di configurazione | Semplice | Richiede esperienza |
| Consumo di memoria | Basso | Alto |
| Gestione degli errori | Più facile da monitorare | Più difficile da registrare |
Quando utilizzare richieste parallele
Le richieste parallele sono la scelta quando la velocità è critica e il volume di dati è grande. Ma è importante capire: funziona solo con una corretta configurazione dei proxy e controllo del carico.
Scenari ideali per richieste parallele
1. Scraping di marketplace con un ampio catalogo
Se hai bisogno di raccogliere i prezzi di 50.000 prodotti su Wildberries o Ozon, lo scraping sequenziale richiederà giorni. Con 20-30 flussi paralleli e proxy di data center, il compito si risolve in poche ore.
Configurazione: 20-30 flussi, ciascuno con un IP separato, ritardo di 1-3 secondi tra le richieste all'interno del flusso. Rotazione IP ogni 100-200 richieste.
2. Raccolta di dati da API pubbliche
Molte API (ad esempio, servizi meteorologici, database aziendali, servizi di geolocalizzazione) hanno limiti sulle richieste da un singolo IP: 100-1000 al giorno. Le richieste parallele tramite un pool di proxy consentono di aggirare i limiti.
Esempio: Devi raccogliere dati su 10.000 aziende tramite API. Limite — 500 richieste/giorno per IP. Utilizzi 20 proxy in parallelo = 10.000 richieste al giorno invece di 20 giorni.
3. Verifica della disponibilità delle risorse
Se stai controllando la disponibilità dei siti, il funzionamento dei mirror o monitorando lo stato dei server, le richieste parallele risparmiano ore. Qui non è necessaria l'imitazione del comportamento umano, conta solo la velocità.
4. Verifica massiva dei proxy
Quando acquisti grandi pool di proxy (1000+ IP) devi controllare rapidamente la loro funzionalità, velocità, geolocalizzazione. La verifica sequenziale richiederà ore, quella parallela minuti.
Attenzione: Le richieste parallele NON sono adatte per lavorare con piattaforme protette (Facebook Ads, Instagram API, Google Ads), dove è importante imitare il comportamento di un utente reale. Qui utilizza richieste sequenziali.
Requisiti chiave per richieste parallele
- Ampio pool di proxy (minimo 10-20 IP, meglio 50-100+)
- Rotazione automatica degli IP in caso di errori
- Controllo del numero di flussi simultanei (non più di 50-100)
- Ritardi tra le richieste anche all'interno dei flussi (0.5-2 sec)
- Registrazione degli errori per analizzare le cause dei blocchi
- Sistema di retry (ripetizioni) in caso di timeout
Quando utilizzare richieste sequenziali
Le richieste sequenziali sono la scelta della sicurezza e dell'affidabilità rispetto alla velocità. Imitano il comportamento di un utente reale e minimizzano il rischio di blocchi su piattaforme protette.
Scenari obbligatori per richieste sequenziali
1. Lavorare con i pannelli pubblicitari
Facebook Ads, TikTok Ads, Google Ads monitorano non solo gli IP, ma anche i modelli di comportamento. Le richieste parallele da un singolo account susciteranno immediatamente sospetti. Un account = un flusso = azioni sequenziali con ritardi di 5-15 secondi.
Esempio: Gestisci 20 pannelli pubblicitari di Facebook tramite un browser anti-detect Dolphin Anty. Ogni pannello funziona in un profilo separato con proxy mobili, le azioni sono rigorosamente sequenziali: accesso → controllo delle statistiche → regolazione delle offerte → uscita. Ritardi di 7-12 secondi tra le azioni.
2. Automazione delle azioni sui social media
Instagram, TikTok, VK hanno limiti rigorosi sulle azioni: like, iscrizioni, commenti. Superare i limiti o azioni troppo rapide = shadowban o blocco totale. Solo richieste sequenziali con ritardi casuali di 20-60 secondi.
Configurazione per Instagram: Un account può fare al massimo 60 like/ora. Questo è 1 like al minuto con ritardi di 45-75 secondi (la randomizzazione è importante!). Utilizza un proxy separato per ogni account.
3. Autenticazione e lavoro con pannelli personali
Qualsiasi azione che richiede l'accesso a un account (servizi email, banche, marketplace come venditore) deve essere eseguita in modo sequenziale. Tentativi paralleli di accesso da IP diversi a un singolo account portano direttamente al blocco.
4. Siti con protezione anti-bot rigorosa
Piattaforme con Cloudflare, Akamai, PerimeterX analizzano non solo la frequenza delle richieste, ma anche i loro modelli. Se da un singolo IP o User-Agent arrivano 10 richieste contemporaneamente — questo è un chiaro segnale di un bot. Le richieste sequenziali con ritardi di 3-10 secondi appaiono naturali.
5. Piccolo volume di dati
Se hai bisogno di fare scraping di 50-100 pagine, la differenza di tempo tra scraping sequenziale e parallelo è insignificante (5 minuti contro 1 minuto). Tuttavia, il metodo sequenziale garantisce l'assenza di problemi.
Ritardi corretti per richieste sequenziali
| Piattaforma/compito | Ritardo tra le richieste | Randomizzazione |
|---|---|---|
| Facebook Ads (azioni nel pannello) | 7-15 secondi | ±30% |
| Instagram (like, iscrizioni) | 45-90 secondi | ±40% |
| TikTok (visualizzazioni, like) | 30-60 secondi | ±35% |
| Google Ads (richieste API) | 5-10 secondi | ±25% |
| Scraping con Cloudflare | 3-7 secondi | ±30% |
| Siti normali senza protezione | 1-3 secondi | ±20% |
Consiglio: La randomizzazione dei ritardi è critica. Se il tuo script fa richieste esattamente ogni 5.00 secondi — questo è un modello di bot. Usa un valore casuale da 4 a 7 secondi per imitare un umano.
Rischi di blocco con diversi metodi
Comprendere i rischi aiuta a scegliere la strategia giusta e configurare la protezione. I blocchi non si verificano solo a causa della frequenza delle richieste, ma anche dei loro modelli.
Cosa monitorano i sistemi antifrode
1. Frequenza delle richieste da un IP
Se da un IP arrivano 100 richieste al minuto — questo è un chiaro segnale di un bot. I limiti variano: i siti normali tollerano 10-30 richieste/minuto, le piattaforme protette — 2-5 richieste/minuto.
Soluzione per richieste parallele: Distribuisci le richieste su un ampio pool di IP. Ad esempio, 1000 richieste/minuto = 50 IP con 20 richieste ciascuno. Questo appare come 50 utenti normali.
2. Intervalli identici tra le richieste
Richieste esattamente ogni 2.00 secondi — segnale di automazione. Un umano clicca con intervalli diversi: 1.8 sec, 3.2 sec, 2.1 sec.
Soluzione: Aggiungi randomizzazione ±30-50% dal ritardo base. Invece di 5 secondi fissi, usa random(3.5, 7.5).
3. Assenza di comportamento tipico dell'utente
Un utente reale non va direttamente alla pagina del prodotto — prima visita la home, cerca la categoria, clicca sul prodotto. Un bot richiede immediatamente un URL specifico.
Soluzione per piattaforme critiche: Imitare il percorso completo dell'utente. Prima di fare scraping del prodotto, fai 2-3 richieste: home → categoria → prodotto. Questo rallenta il lavoro, ma riduce il rischio di blocco del 70-80%.
4. User-Agent e intestazioni sospette
User-Agent obsoleti (ad esempio, Chrome 95 nel 2024), assenza di intestazioni Accept-Language, Referer — segnali di bot.
Soluzione: Usa User-Agent aggiornati (Chrome 120+, Firefox 120+), aggiungi un set completo di intestazioni come in un browser reale. Ruota User-Agent insieme agli IP.
Confronto dei rischi di blocco
| Scenario | Rischio con sequenziali | Rischio con paralleli |
|---|---|---|
| Scraping di marketplace (10K richieste) | Basso (5-10%) | Medio (20-30%) |
| Lavorare con Facebook Ads | Basso (2-5%) | Critico (80-95%) |
| Automazione di Instagram | Medio (15-25%) | Alto (60-80%) |
| API pubbliche (entro i limiti) | Molto basso (1-3%) | Basso (5-10%) |
| Siti con Cloudflare | Medio (10-20%) | Alto (40-60%) |
Quali proxy sono adatti per ciascun metodo
Il tipo di proxy influisce direttamente sulla possibilità di utilizzare richieste parallele o sequenziali. Una scelta errata porterà a blocchi o spese eccessive.
Proxy per richieste parallele
Proxy di data center — la scelta ottimale per scraping massivo e richieste parallele. Sono economici (da $1-3 per IP/mese), veloci (ping 20-50 ms) e disponibili in grandi quantità. Contro — facilmente identificabili come proxy, quindi non adatti per piattaforme protette.
Quando utilizzare: Scraping di marketplace, raccolta di dati da fonti pubbliche, verifica della disponibilità delle risorse, richieste API massicce a servizi senza protezione rigorosa.
Configurazione: Acquista un pool di 50-100 IP, configura 20-30 flussi paralleli, ogni flusso utilizza il proprio IP. Rotazione ogni 100-200 richieste o in caso di errore.
Proxy residenziali — più costosi (da $3-7 per 1 GB di traffico), ma appaiono come utenti reali. Adatti per richieste parallele a piattaforme protette, se necessiti di velocità, ma con cautela.
Quando utilizzare: Scraping di social media (senza autenticazione), raccolta di dati da siti con Cloudflare, lavoro con piattaforme che bloccano i data center. Per richieste parallele è necessario un ampio pool di IP con rotazione automatica.
Importante: Durante le richieste parallele tramite proxy residenziali, controlla il consumo di traffico. 10.000 richieste possono "mangiare" 5-10 GB, il che costerà $20-50. I data center sono più economici: traffico illimitato per $100-200/mese su 100 IP.
Proxy per richieste sequenziali
Proxy mobili — il tipo più affidabile per lavorare con piattaforme protette. Gli IP appaiono come dispositivi mobili reali (operatori 4G/5G), il che minimizza il rischio di blocchi. Contro — costosi (da $50-150 per IP/mese).
Quando utilizzare: Facebook Ads, Instagram, TikTok, Google Ads — tutto ciò che richiede la massima sicurezza e imitazione di un utente reale. Un account = un proxy mobile = azioni sequenziali.
Configurazione: Ogni pannello pubblicitario o account social è legato a un IP mobile separato. Le azioni sono rigorosamente sequenziali con ritardi di 10-60 secondi. Gli IP non vengono ruotati (un account funziona sempre con un solo IP).
Proxy residenziali — una buona alternativa ai mobili, se il budget è limitato. Adatti per compiti meno critici: scraping con autenticazione, automazione SMM, lavoro con marketplace come venditore.
Quando utilizzare: Gestione degli account dei marketplace (Wildberries, Ozon come venditore), automazione dei post sui social media (non massiva), scraping di dati che richiedono autenticazione.
Raccomandazioni per la scelta dei proxy
| Compito | Tipo di proxy | Metodo di richieste | Numero di IP |
|---|---|---|---|
| Scraping di marketplace (grande volume) | Data center | Parallele | 50-100+ |
| Facebook Ads (multi-accounting) | Mobili | Sequenziali | 1 IP per account |
| Automazione di Instagram | Mobili/residenziali | Sequenziali | 1 IP per account |
| Scraping con Cloudflare | Residenziali | Parallele (con cautela) | 20-50 |
| API pubbliche (raccolta massiva) | Data center | Parallele | 10-30 |
| Marketplace (pannello venditore) | Residenziali | Sequenziali | 1 IP per account |
Impostazioni ottimali: ritardi, flussi, timeout
La corretta configurazione dei parametri è fondamentale per bilanciare velocità e sicurezza. Impostazioni troppo aggressive porteranno a blocchi, mentre impostazioni troppo cautelose porteranno a perdita di tempo.
Configurazione delle richieste parallele
Numero di flussi simultanei (concurrency)
Questo è un parametro chiave. Troppi flussi = sovraccarico dei proxy e del server target. Troppo pochi = bassa velocità.
Raccomandazioni:
- Scraping di marketplace: 20-50 flussi con un pool di 50+ proxy
- API pubbliche: 10-30 flussi, orientati ai limiti API
- Siti con protezione: 5-15 flussi, di più = rischio di blocco
- Verifica dei proxy: 50-100 flussi (qui la velocità è più importante)
Ritardi all'interno dei flussi
Anche durante il lavoro parallelo, ogni flusso deve fare pause tra le proprie richieste. Questo riduce il carico su un singolo IP e diminuisce il rischio di blocco.
Raccomandazioni:
- Siti semplici: 0.5-2 secondi tra le richieste in un flusso
- Marketplace: 1-3 secondi con randomizzazione ±30%
- Siti con Cloudflare: 2-5 secondi con randomizzazione ±40%
- API con limiti: calcola in base al limite (ad esempio, 100 richieste/minuto = 0.6 sec/richiesta, fai 1 sec per sicurezza)
Timeout (timeout)
Tempo di attesa per la risposta dal server. Un timeout troppo breve = perdita di dati a causa di risposte lente. Un timeout troppo lungo = blocco dei flussi.
Raccomandazioni:
- Siti veloci: 10-15 secondi
- Siti/API lenti: 20-30 secondi
- Attraverso proxy residenziali: +5-10 secondi (sono più lenti dei data center)
- Connection timeout: 5-10 secondi (tempo di stabilimento della connessione)
Retry (ripetizioni)
In caso di errori (timeout, 503, blocco proxy) è necessario ripetere la richiesta con un altro IP. Senza retry perderai parte dei dati.
Configurazione: 2-3 tentativi per richiesta, cambio proxy dopo ogni tentativo non riuscito, pausa di 3-5 secondi prima del retry.
Configurazione delle richieste sequenziali
Ritardo base tra le richieste
Dipende dalla piattaforma e dal tipo di azioni. La regola principale: imitare un utente reale.
Raccomandazioni per le piattaforme:
- Facebook Ads (transizioni tra le sezioni del pannello): 7-15 secondi
- Instagram (like): 45-90 secondi, massimo 60 like/ora
- Instagram (iscrizioni): 60-120 secondi, massimo 30 iscrizioni/ora
- TikTok (visualizzazioni): 30-60 secondi
- Scraping con autenticazione: 3-7 secondi
- Marketplace (azioni nel pannello del venditore): 5-10 secondi
Randomizzazione
Obbligatoria per tutte le richieste sequenziali. Usa una deviazione ±30-50% dal ritardo base.
Esempio: Ritardo base di 10 secondi, randomizzazione ±40% → i ritardi effettivi saranno di 6-14 secondi (valore casuale ogni volta).
Timeout
Per le richieste sequenziali, puoi utilizzare timeout più lunghi, poiché non c'è rischio di blocco di tutti i flussi.
Raccomandazioni: 30-60 secondi per piattaforme protette (Facebook, Instagram), 15-30 secondi per siti normali.
Consiglio pratico: Inizia con impostazioni conservative (meno flussi, più ritardi), aumenta gradualmente l'aggressività monitorando la percentuale di errori. Se gli errori >5-10% — torna indietro di un passo.
Strumenti per implementare entrambi i metodi
La scelta dello strumento dipende dal tuo compito e dalle tue abilità tecniche. Per compiti aziendali (arbitraggio, SMM, e-commerce) utilizza soluzioni pronte senza codice. Per compiti tecnici — librerie e framework.
Soluzioni pronte senza codice (per le aziende)
Browser anti-detect per multi-accounting
Se lavori con pannelli pubblicitari o social media, i browser anti-detect sono lo standard del settore. Gestiscono automaticamente proxy, impronte del browser e isolano gli account.
Soluzioni popolari:
- Dolphin Anty: leader per arbitraggisti di Facebook/TikTok, piano gratuito per 10 profili, configurazione proxy semplice
- AdsPower: buono per e-commerce (Amazon, eBay), automazione tramite RPA (senza codice)
- Multilogin: il più costoso ($100+/mese), ma massima protezione per un serio arbitraggio
- GoLogin: alternativa economica ($25/mese), adatta per SMM e piccoli team
Come funzionano con i proxy: Crei un profilo del browser → colleghi il proxy → tutte le azioni in questo profilo passano attraverso questo IP. Un profilo = un account = azioni sequenziali. Per il lavoro parallelo, apri più profili contemporaneamente (ognuno con il proprio proxy).
Parser e scraper (pronti)
Per raccogliere dati da marketplace e siti esistono strumenti pronti con GUI, che non richiedono programmazione.
- Octoparse: costruttore visivo di parser, supporto proxy, possibilità di configurare flussi paralleli tramite interfaccia
- ParseHub: analogo di Octoparse, piano gratuito per 200 pagine, configurazione dei ritardi tramite GUI
- Scrapy Cloud: servizio cloud per eseguire spider Scrapy (richiede conoscenze minime di Python)
Automazione SMM (senza codice)
Per gestire i social media ci sono servizi con automazione tramite interfaccia.
- Jarvee: automazione di Instagram, TikTok, Twitter, supporto proxy integrato, configurazione dei ritardi tramite GUI (attenzione: automazione aggressiva porta a ban)
- Ingramer (Inflact): automazione sicura di Instagram, funziona tramite i loro proxy
- Combin: iscrizioni/like mirati su Instagram, supporto per proxy esterni
Strumenti tecnici (per sviluppatori)
Se scrivi i tuoi script per scraping o automazione, utilizza librerie collaudate.
Python (il più popolare per scraping):
- Requests + threading/asyncio: per richieste parallele semplici, facile configurazione dei proxy
- aiohttp: libreria asincrona per richieste ad alta parallelità (1000+ contemporaneamente)
- Scrapy: framework per scraping, supporto integrato per rotazione dei proxy, middleware per ritardi
- Selenium: per siti con JavaScript, più lento, ma bypassa molte protezioni
- Playwright: alternativa moderna a Selenium, più veloce e comoda
JavaScript/Node.js:
- Axios: libreria popolare per richieste HTTP, semplice configurazione dei proxy
- Puppeteer: libreria per automazione di Chrome, supporto per proxy, ottima per scraping di siti JS