L'errore classico quando si scala un parser è acquistare proxy "a occhio": si prendono 100 IP, si avvia il parser e si ricevono ban dopo mezz'ora. Il problema non è nel numero di indirizzi, ma nel fatto che nessuno calcola il carico reale su ogni IP. Analizziamo la formula per calcolare il pool di proxy, basata su RPS (richieste al secondo), ritardi e limiti del sito target — con numeri concreti e codice Python.
Perché calcolare il pool in base al numero di IP è un errore
L'approccio tipico di un principiante nel parsing: "devo raccogliere 50.000 schede prodotto, quindi compriamo 500 proxy e distribuiamo il carico". La logica sembra valida, ma non tiene conto del fatto principale: siti come Wildberries e Ozon non bannano in base al numero assoluto di richieste, ma in base all'intensità delle richieste da un singolo IP in un'unità di tempo. Quindi 500 proxy, ognuno dei quali invia 20 richieste al secondo, verranno bannati immediatamente: i sistemi anti-bot vedono un modello simile a un DDoS.
D'altra parte, se hai 50 proxy, ma ognuno fa 1 richiesta ogni 5-10 secondi con pause casuali, imitando il comportamento umano, puoi fare parsing in modo stabile per settimane senza un solo ban. Il numero di IP non è la causa della stabilità, ma una conseguenza di un carico calcolato correttamente. Ecco perché la formula deve basarsi non su "quanti IP acquistare", ma su "quanti RPS è necessario raggiungere e quale carico sicuro per un singolo IP".
Un altro aspetto: diversi tipi di proxy hanno una diversa "riserva di robustezza" per un singolo IP. I proxy datacenter vengono bannati più rapidamente con alta frequenza di richieste, perché le loro sottoreti sono facilmente riconoscibili come hosting. Gli IP residenziali e mobili sembrano utenti normali, e possono permettersi una frequenza leggermente più alta senza rischio di blocco — ma ciò non significa che si possano ignorare completamente i limiti.
Formula di base per il calcolo del pool di proxy
La formula per calcolare il numero di proxy nel pool è la seguente:
N = (RPS_target × Delay_per_ip) / Concurrency_per_ip
Dove:
- N — numero necessario di proxy nel pool;
- RPS_target — velocità target di parsing (richieste al secondo per l'intero sistema);
- Delay_per_ip — pausa minima sicura tra le richieste da un singolo IP (in secondi);
- Concurrency_per_ip — quante connessioni parallele si consentono per un singolo IP (di solito 1, massimo 2 per proxy residenziali).
La logica è semplice: se vuoi mantenere 10 richieste al secondo in totale, e la pausa sicura tra le richieste da un singolo IP è di 8 secondi, allora un IP può fisicamente inviare solo 1 richiesta ogni 8 secondi, cioè 0.125 RPS. Per ottenere 10 RPS in totale, hai bisogno di 10 / 0.125 = 80 proxy. Questo è il calcolo che sostituisce la congettura di "500 IP per sicurezza".
Come calcolare il RPS target per il parsing
Prima di calcolare il pool, è necessario determinare RPS_target — quante richieste al secondo ti servono realmente per raccogliere i dati in un tempo ragionevole. La formula qui è inversa:
RPS_target = Total_requests / Time_budget_seconds
Esempio: è necessario raccogliere 100.000 schede prodotto da Wildberries in 8 ore (28.800 secondi). Se per ogni scheda è necessaria 1 richiesta, RPS_target = 100.000 / 28.800 ≈ 3.47 richieste al secondo. Non è così tanto come sembra a prima vista: molti sovrastimano la velocità necessaria e acquistano un numero eccessivo di proxy.
Se il compito include diversi tipi di richieste (ad esempio, prima ottenere l'elenco delle categorie, poi le schede, poi le recensioni), calcola il RPS per ogni fase separatamente — possono andare in parallelo con diversi pool di proxy, e il carico totale sul sito sarà distribuito su diversi endpoint.
Limiti per un singolo IP: quante richieste al minuto sono sicure
Delay_per_ip è il parametro più importante nella formula, e deve essere determinato empiricamente per ogni sito. Linee guida generali, basate sulla pratica del parsing dei marketplace:
| Piattaforma | Pausa sicura tra le richieste da 1 IP | Massimo richieste/min da 1 IP |
|---|---|---|
| Wildberries (API schede) | 4-6 sec | 10-15 |
| Ozon (pagine prodotto) | 5-8 sec | 8-12 |
| Avito (annunci) | 6-10 sec | 6-10 |
| Yandex.Market | 5-7 sec | 8-12 |
Questi numeri sono un punto di partenza, non una dogma. Inizia con valori conservativi (limite superiore della pausa), monitora la percentuale di errori 429 e 403, e riduci gradualmente la pausa se i ban non aumentano. Aumentare drasticamente il RPS senza test graduali è il modo più comune per bruciare l'intero pool di proxy in un giorno.
Calcoli pratici: Wildberries, Ozon, Avito
Analizziamo tre scenari reali con calcolo completo secondo la formula.
Scenario 1: monitoraggio dei prezzi su Wildberries. È necessario aggiornare i prezzi di 20.000 prodotti ogni 2 ore. RPS_target = 20.000 / (2 × 3600) ≈ 2.78 RPS. Con una pausa di 5 sec per 1 IP e Concurrency = 1: N = (2.78 × 5) / 1 ≈ 14 proxy. Per precauzione in caso di ban di alcuni IP è consigliabile prendere un pool con un coefficiente di 1.5-2x, quindi 21-28 proxy.
Scenario 2: raccolta una tantum del catalogo Ozon. 500.000 schede in 24 ore. RPS_target = 500.000 / 86.400 ≈ 5.79 RPS. Con una pausa di 6 sec: N = (5.79 × 6) / 1 ≈ 35 proxy. Con riserva — 50-60 proxy.
Scenario 3: monitoraggio dei concorrenti su Avito in tempo reale. 5000 annunci, aggiornamento ogni 15 minuti. RPS_target = 5000 / 900 ≈ 5.56 RPS. Con una pausa di 8 sec: N = (5.56 × 8) / 1 ≈ 45 proxy. Qui è importante considerare che Avito blocca attivamente le sottoreti datacenter, quindi per questo compito è più ragionevole pianificare subito IP residenziali o mobili.
Proxy residenziali, mobili e datacenter nella formula
Il tipo di proxy influisce direttamente su Delay_per_ip e, di conseguenza, su N finale nella formula. I proxy datacenter sono più economici e veloci, ma richiedono pause più lunghe tra le richieste e vengono bannati più frequentemente con alta frequenza — di fatto, per gli stessi 5 RPS potresti aver bisogno di 2-3 volte più IP datacenter rispetto a quelli residenziali.
| Tipo di proxy | Delay_per_ip medio | Quando utilizzare |
|---|---|---|
| Proxy datacenter | 8-15 sec | API aperti, siti senza rigido anti-bot |
| Proxy residenziali | 4-8 sec | Wildberries, Ozon, Avito e altri marketplace con anti-bot |
| Proxy mobili | 3-6 sec | Le protezioni più aggressive, social media, API mobili |
Per il parsing di marketplace come Wildberries e Ozon, la scelta ottimale sono di solito proxy residenziali — bilanciano prezzo e stabilità, consentendo di mantenere pause più brevi senza un aumento drastico dei ban. I proxy datacenter dovrebbero essere considerati solo per piattaforme senza un anti-bot aggressivo o per compiti una tantum con un RPS non elevato.
Implementazione del pool in Python: codice con rotazione
Di seguito è riportata un'implementazione semplificata di un pool di proxy con controllo della frequenza delle richieste per ogni IP. La logica: ogni proxy memorizza l'orario dell'ultimo utilizzo, e il pianificatore seleziona solo quegli IP per cui è passato abbastanza tempo dall'ultima richiesta.
import time
import random
from dataclasses import dataclass, field
from typing import List, Optional
@dataclass
class ProxyNode:
address: str
delay_per_ip: float # pausa sicura in secondi
last_used: float = field(default=0.0)
class ProxyPool:
def __init__(self, proxies: List[str], delay_per_ip: float):
self.nodes = [ProxyNode(address=p, delay_per_ip=delay_per_ip) for p in proxies]
def get_available_proxy(self) -> Optional[ProxyNode]:
now = time.time()
available = [
node for node in self.nodes
if now - node.last_used >= node.delay_per_ip
]
if not available:
return None
# scegliamo casualmente tra quelli disponibili, per evitare un modello di coda
node = random.choice(available)
node.last_used = now
return node
def size(self) -> int:
return len(self.nodes)
def calculate_pool_size(rps_target: float, delay_per_ip: float, concurrency: int = 1) -> int:
"""Formula: N = (RPS_target * Delay_per_ip) / Concurrency_per_ip"""
return max(1, int((rps_target * delay_per_ip) / concurrency))
# Esempio di utilizzo
rps_target = 5.79 # calcolato dal volume del compito e dal tempo
delay_per_ip = 6.0 # pausa sicura per Ozon
n_proxies = calculate_pool_size(rps_target, delay_per_ip)
print(f"Proxy necessari nel pool: {n_proxies}") # ~35, con riserva 50-60
In un parser reale, questa logica dovrebbe essere integrata con una coda di attività (ad esempio, tramite asyncio o multiprocessing), in modo che i worker aspettino la disponibilità di un proxy libero, invece di terminare con un errore in assenza di essi. È anche consigliabile aggiungere un backoff esponenziale in caso di ricezione di 429/403 — questo aumenterà automaticamente la pausa per un IP specifico in caso di segni di blocco.
Monitoraggio e correzione dinamica del pool
Il calcolo statico secondo la formula è un punto di partenza, non una soluzione finale. Nella pratica reale, è necessario monitorare tre metriche chiave:
- Success rate — percentuale di richieste riuscite (codice 200) sul totale. Una diminuzione sotto il 90-95% segnala che Delay_per_ip deve essere aumentato o che è necessario aggiungere proxy al pool;
- Ban rate — quota di proxy che hanno mostrato segni di blocco (captcha, 403, reindirizzamento a un modulo di verifica) nell'ultima ora;
- Real RPS — velocità effettiva di elaborazione delle richieste, che può differire da quella calcolata a causa di timeout e tentativi ripetuti.
Regola pratica: se il ban rate supera il 5-7% all'ora, aumenta Delay_per_ip del 20-30% e ricalcola N secondo la formula. Se il success rate rimane stabilmente sopra il 98% per diverse ore, puoi gradualmente ridurre la pausa e diminuire la dimensione del pool — questo è un risparmio diretto sul budget per i proxy senza perdita di stabilità.
Una buona pratica è tenere un log per ogni IP separatamente: orario dell'ultima richiesta riuscita, numero di errori consecutivi, tempo medio di risposta. Questo consente di escludere automaticamente i proxy "rovinati" dalla rotazione per 30-60 minuti invece di continuare a inviare richieste attraverso di essi e ricevere captcha a ogni passo.
Errori comuni nel calcolo del pool di proxy
Anche conoscendo la formula, è facile commettere errori nei dettagli del calcolo. Ecco un elenco di errori tipici:
- Ignorare il margine per i ban. Anche con un calcolo perfetto, il 5-10% dei proxy saranno temporaneamente non disponibili a causa di blocchi o problemi di rete. Aggiungi sempre un coefficiente di 1.3-2x al N di base;
- Delay_per_ip uguale per tutti gli endpoint. La pagina di categoria e la pagina della scheda prodotto possono avere limiti diversi — calcola separatamente;
- Concurrency maggiore di 1 senza test. Richieste parallele da un singolo IP aumentano drasticamente il rischio di ban, specialmente su proxy residenziali — inizia con Concurrency = 1;
- Assenza di rotazione di User-Agent e intestazioni. Anche un pool di proxy calcolato correttamente non salverà se tutte le richieste provengono con la stessa impronta del browser;
- Pausa fissa senza jitter. Un intervallo rigorosamente uguale tra le richieste (ad esempio, esattamente 5.0 sec) è un modello facilmente riconoscibile dagli anti-bot. Aggiungi una deviazione casuale ±20-30%.
Conclusione
La formula N = (RPS_target × Delay_per_ip) / Concurrency_per_ip trasforma il calcolo del pool di proxy da una congettura a un compito ingegneristico con numeri concreti. Prima determina la velocità target di parsing in base al volume di dati e al tempo, poi trova empiricamente la pausa sicura per la piattaforma specifica, e solo dopo calcola il numero necessario di IP — con un margine del 30-100% per i ban e i guasti.
Questo approccio fa risparmiare sul budget: invece di acquistare un numero eccessivo di IP "per sicurezza", paghi esattamente per il volume di proxy necessario per raggiungere il RPS target senza rischio di blocchi. Per il parsing di marketplace e altri siti protetti, ti consigliamo di iniziare con proxy residenziali — offrono il miglior equilibrio tra stabilità e costo quando si lavora con i sistemi anti-bot di Wildberries, Ozon e Avito.