Limite di traffico per il parsing di Wildberries e Ozon: come non esaurire il pacchetto mensile di proxy in una notte

Il venditore avvia il parser dei prezzi dei concorrenti di notte e al mattino riceve una notifica: traffico esaurito, pacchetto esaurito al 90%. Situazione familiare? Spesso non è colpa del parser stesso, ma della mancanza di limiti a livello di proxy e script. In questo articolo analizzeremo come il traffico "sfugge" inutilmente, e come impostare protezioni affinché il pacchetto mensile di proxy residenziali o mobili sia sufficiente fino alla fine del periodo di calcolo.

Perché il traffico finisce durante la notte

Il parsing di Wildberries, Ozon o Avito sembra un compito semplice: invia una richiesta e ricevi un JSON con il prezzo. Ma nella pratica, il traffico viene speso non solo per dati utili. Le principali fonti di sovraspesa sono:

• Caricamento di immagini e media. Se il parser apre la pagina del prodotto interamente tramite browser (e non effettua una richiesta diretta all'API), carica automaticamente immagini, video, banner: si tratta di decine di megabyte per ogni scheda.
• Richieste ripetute a causa di CAPTCHA e blocchi. Il marketplace riconosce il bot, restituisce un CAPTCHA o un ban temporaneo dell'IP, lo script effettua una richiesta ripetuta: il traffico viene sprecato, e i dati non arrivano.
• Assenza di caching delle richieste. Senza la logica "già parsato in quest'ora - non ripetere", lo script può interrogare le stesse schede più volte durante la notte.
• Flussi paralleli senza limitazione. Avviare 50-100 flussi contemporaneamente sembra accelerare il lavoro, ma il traffico viene consumato molto più velocemente del previsto, e parte delle richieste viene semplicemente bloccata.
• Scelta errata del tipo di proxy. I proxy residenziali e mobili di solito vengono tariffati in base al volume di traffico (GB), a differenza dei proxy dei data center, dove più spesso il pagamento avviene per numero di IP o tempo di affitto. Se il parser è impostato su un pool residenziale senza controllo, il limite si esaurisce rapidamente.

La combinazione di questi fattori porta al fatto che uno script progettato per un mese di lavoro consuma un pacchetto di traffico in una sola sessione notturna di parsing di 10-20 mila schede di prodotti.

Come viene calcolato il traffico per diversi tipi di proxy

Prima di impostare i limiti, è importante capire per cosa esattamente si sta pagando. I diversi tipi di proxy considerano il consumo in modi diversi, e questo influisce direttamente sulla strategia di risparmio.

Tipo di proxy	Tariffazione	Rischio di sovraspesa	Quando applicare
Proxy residenziali	In base al volume di traffico (GB)	Alto senza limiti	Parsing con bypass della protezione anti-bot dei marketplace
Proxy mobili	In base al volume di traffico o al tempo	Alto, traffico più costoso	Parsing delle versioni mobili dei siti, bypass di blocchi severi
Proxy dei data center	In base al numero di IP / tempo di affitto	Basso, traffico di solito illimitato	Parsing massivo senza protezione anti-bot rigorosa

Se stai parsando Wildberries o Ozon, dove la protezione contro i bot è attiva, gli IP residenziali o mobili sono quasi sempre necessari: gli indirizzi dei data center vengono bloccati rapidamente. Ma proprio a causa della tariffazione per traffico, qui è particolarmente importante impostare limiti in anticipo.

Quanto traffico è realmente necessario per il parsing

Per impostare un limite adeguato, è necessario basarsi su cifre reali, non su sensazioni. Le spese approssimative nella pratica:

• Richiesta all'API della scheda prodotto (JSON, senza immagini): 5-30 KB per scheda. Per 10.000 schede - circa 50-300 MB.
• Caricamento della pagina del prodotto tramite browser headless con immagini: 1-3 MB per scheda. Per le stesse 10.000 schede - 10-30 GB.
• Monitoraggio dei prezzi ogni ora per 1000 SKU: con richieste semplificate - circa 1-5 GB al giorno, con caricamento completo delle pagine - 50-100 GB al giorno.

La differenza tra "parsing leggero" e "parsing pesante" è di decine di volte. Pertanto, il primo passo per risparmiare traffico è disattivare il caricamento di immagini, video e script di terze parti dove possibile, e lavorare direttamente con l'API del marketplace o la versione mobile del sito, che pesa meno di quella desktop.

Limiti nei browser anti-detect e nei gestori di proxy

Per coloro che parsano tramite un browser anti-detect (ad esempio, Dolphin Anty, AdsPower, Multilogin, GoLogin, Octo Browser) o un proprio gestore di proxy, il modo più semplice per limitare il consumo è impostare limiti a livello di profilo e account del fornitore di proxy.

1. Accedi al pannello di controllo del fornitore di proxy e trova la sezione di gestione del traffico o dei limiti per sotto-utenti/porte.
2. Crea un sotto-account o una porta separata per il parsing - non utilizzare lo stesso pool di proxy che per gli account di farming su Instagram o TikTok. La separazione per compiti mostra immediatamente dove va il traffico.
3. Imposta un limite giornaliero o orario di traffico su questo sotto-account - ad esempio, 5 GB al giorno invece di esaurire l'intero pacchetto mensile in una sola sessione.
4. Disattiva il caricamento automatico delle immagini nel browser anti-detect per i profili utilizzati esclusivamente per la raccolta di dati, e non per la visualizzazione visiva delle pagine.
5. Imposta un programma di avvio dei profili in modo che il parsing avvenga non in una lunga sessione, ma in brevi intervalli con pause - questo riduce il rischio di blocchi e dà tempo per monitorare il consumo di traffico tra gli avvii.

Questo approccio è particolarmente importante per le agenzie e i freelance che effettuano parsing di più marketplace contemporaneamente: senza separazione per sotto-account è difficile capire quale progetto "ha consumato" il traffico.

Limitazione del traffico a livello di script e API

Se il parser è stato scritto autonomamente in Python o Node.js, i limiti possono e devono essere incorporati direttamente nel codice - questo offre un controllo più preciso rispetto alle impostazioni dell'interfaccia del fornitore di proxy.

Ecco un esempio di un semplice contatore di traffico in Python utilizzando requests:

import requests

MAX_BYTES_PER_DAY = 5 * 1024 * 1024 * 1024  # limite di 5 GB al giorno
used_bytes = 0

proxies = {
    "http": "http://user:pass@proxy_host:port",
    "https": "http://user:pass@proxy_host:port",
}

def safe_get(url):
    global used_bytes
    if used_bytes >= MAX_BYTES_PER_DAY:
        raise RuntimeError("Limite giornaliero di traffico esaurito, parsing interrotto")

    response = requests.get(url, proxies=proxies, timeout=10)
    used_bytes += len(response.content)
    return response

# esempio di chiamata
resp = safe_get("https://card.wb.ru/cards/detail?nm=123456")
print("Traffico utilizzato:", round(used_bytes / 1024 / 1024, 2), "MB")

La logica è semplice: lo script conta il volume di ogni risposta in byte e si ferma non appena viene raggiunto il limite impostato. Questo protegge da situazioni in cui, a causa di un errore nel ciclo o di ripetizioni infinite di richieste, lo script "consuma" un pacchetto mensile di traffico in poche ore.

Inoltre, è utile aggiungere:

• Ritardo esponenziale in caso di errori (retry con backoff) - invece di ripetere immediatamente la richiesta in caso di CAPTCHA o ban, lo script attende un intervallo crescente (5 sec, 15 sec, 60 sec), riducendo così il numero di richieste inutili.
• Limitazione del numero di flussi paralleli - ad esempio, non più di 10-20 connessioni simultanee tramite il pool di proxy, per non provocare blocchi e non sprecare traffico.
• Disattivazione del caricamento delle risorse nel browser headless - se il parsing avviene tramite Selenium o Puppeteer, nelle impostazioni del browser è possibile bloccare il caricamento di immagini, font e CSS, lasciando solo le risposte HTML/JSON.

Monitoraggio del consumo in tempo reale

Un limite senza monitoraggio funziona peggio, perché si scopre il problema solo dopo l'interruzione dello script. Per controllare il consumo in tempo reale:

• Attiva le notifiche nel pannello di controllo del fornitore di proxy per il raggiungimento del 50%, 80% e 100% del pacchetto mensile di traffico - la maggior parte dei servizi supporta tali avvisi via email o Telegram.
• Conduci un semplice log nello script stesso: registra in un file o in un database il volume di traffico per ore, per vedere i picchi di consumo e trovare rapidamente la fonte del problema.
• Separa il traffico per compiti tramite sotto-account o etichette separate - separatamente per il parsing di Wildberries, separatamente per Ozon, separatamente per Avito. Questo semplifica l'analisi di quale progetto consuma di più.
• Confronta il consumo con il volume di dati atteso: se per 10.000 schede sono stati spesi 20 GB invece dei 300 MB previsti, significa che vengono caricati risorse extra o ci sono richieste ripetute.

Checklist per il controllo del budget di traffico

Errori comuni dei principianti

Nella pratica, la maggior parte dei pacchetti di traffico "bruciati" è spiegata da alcuni errori tipici:

• Avvio del parsing "di notte senza supervisione" senza limiti. Lo script funziona 8-10 ore senza fermarsi, e se si verifica un ciclo di richieste ripetute, il traffico viene consumato continuamente fino al mattino.
• Un unico pool di proxy per tutti i compiti. Farming di account su Instagram, test di pubblicità su Facebook Ads e parsing di Ozon utilizzano lo stesso traffico - è impossibile capire cosa lo consuma.
• Ignorare il CAPTCHA. Invece di ridurre la frequenza delle richieste ai primi segni di CAPTCHA, lo script continua a colpire il sito con la stessa intensità, sprecando traffico su risposte inutili con codice di errore.
• Scelta di proxy residenziali dove sono sufficienti quelli dei data center. Se il marketplace non blocca severamente gli IP dei data center, il sovrapprezzo per il traffico del pool residenziale non è giustificato - per obiettivi meno protetti sono adatti proxy dei data center con un altro modello di tariffazione.
• Assenza di un test preliminare. Prima di avviare un parsing completo su migliaia di schede, è opportuno eseguire lo script su 50-100 schede e misurare il reale consumo di traffico, per estrapolare su tutto il volume.

Conclusione

Il traffico per il parsing "brucia" non a causa del volume di dati, ma per mancanza di controllo: immagini superflue, richieste ripetute in caso di blocchi, flussi paralleli senza limitazioni e un pool di proxy comune per tutti i compiti. La soluzione è separare il traffico per progetti, impostare limiti giornalieri a livello di account proxy, incorporare un contatore di consumo nello script stesso e impostare il monitoraggio con notifiche prima che il pacchetto si esaurisca davvero.

Se stai parsando marketplace con protezione attiva contro i bot come Wildberries o Ozon, ti consigliamo di utilizzare proxy residenziali per bypassare i blocchi e in aggiunta IP mobili per scenari più sensibili alla protezione anti-bot - ma in entrambi i casi è fondamentale impostare limiti di traffico in anticipo, affinché il pacchetto mensile non venga esaurito in una sola sessione notturna.