Errore 429 durante il parsing di Wildberries e Ozon: 6 motivi che il cambio di proxy non risolve

Cambi i proxy, acquisti un nuovo pool di indirizzi IP, ma il parser continua a bloccarsi con l'errore 429 Too Many Requests? Questa è una situazione classica: il 70% dei casi di blocco non è legato all'indirizzo IP, ma a come appare la richiesta stessa. Analizziamo sei motivi reali per cui il sito continua a bloccarti anche dopo aver cambiato proxy — e cosa fare in ogni caso.

Cosa significa l'errore 429 e perché i proxy non sono una panacea

Il codice HTTP 429 Too Many Requests significa formalmente "limite di richieste superato". Ma nella pratica, i siti — specialmente Wildberries, Ozon, Avito, Yandex.Market — usano questo codice come segnale universale "crediamo che tu sia un bot". La causa può essere nella frequenza delle richieste, ma con la stessa probabilità — nelle intestazioni, nell'impronta del browser, nell'assenza di cookie di sessione o nei limiti legati non all'IP, ma al tuo account.

Ecco perché cambiare proxy spesso non aiuta: se il sistema blocca non l'IP, ma il pattern della richiesta (fingerprint, intestazioni, velocità di clic), allora dal nuovo indirizzo IP riceverai lo stesso 429 dopo pochi minuti. Analizziamo ogni motivo in dettaglio e mostriamo come verificarlo e risolverlo senza acquistare un nuovo pool di proxy.

Importante: i proxy rimangono uno strumento necessario — ma solo come parte di un sistema, e non come unica soluzione. Gli IP residenziali e mobili riducono la probabilità di finire nelle blacklist per reputazione IP, ma non salvano dal blocco per comportamento o intestazioni.

Motivo 1: Frequenza di richieste troppo alta

La causa più ovvia, ma anche la più spesso diagnosticata erroneamente. Molti pensano: "poiché cambio proxy per ogni richiesta — la frequenza non è importante". Questo è errato. I moderni sistemi anti-bot (ad esempio, Wildberries e Ozon utilizzano soluzioni di livello Cloudflare o i propri WAF) analizzano non solo la frequenza da un IP, ma anche il carico totale su un determinato endpoint API o pagina prodotto in un'unità di tempo da tutte le fonti in combinazione con segnali comportamentali.

Se il tuo parser fa 50-100 richieste al secondo sulla stessa sezione del catalogo, il sistema vede un picco anomalo di traffico indipendentemente da quanti IP diversi stai usando. La soluzione non è cambiare proxy, ma implementare ritardi artificiali (throttling) tra le richieste: 1-3 secondi di ritardo casuale invece di un intervallo fisso, più un backoff esponenziale al ricevimento di 429 (aumento della pausa di due volte dopo ogni blocco).

import time, random

def safe_request(session, url):
    for attempt in range(5):
        response = session.get(url)
        if response.status_code == 429:
            wait = (2 ** attempt) + random.uniform(0, 1)
            time.sleep(wait)
            continue
        return response
    return None

Se utilizzi un parser pronto all'uso senza codice (ad esempio, un servizio cloud di monitoraggio dei prezzi), controlla le impostazioni dell'intervallo tra le richieste — nella maggior parte di questi strumenti c'è uno slider "velocità di scansione". Ridurre la velocità del 30-40% spesso elimina completamente il 429, anche senza cambiare proxy.

Motivo 2: Intestazioni errate o mancanti

Molti parser inviano richieste con un insieme minimo di intestazioni o utilizzano la User-Agent della libreria per impostazione predefinita (ad esempio, "python-requests/2.28.1"). Tale intestazione identifica immediatamente un bot — un vero browser invia decine di intestazioni: Accept, Accept-Language, Accept-Encoding, Sec-Fetch-*, Referer e altre in un ordine rigorosamente definito.

Wildberries e Ozon confrontano l'insieme delle intestazioni con l'"impronta" attesa di un vero browser Chrome o Safari. Se ci sono troppe poche intestazioni, non sono nell'ordine corretto o la User-Agent non corrisponde agli altri parametri (ad esempio, dichiarato Chrome su Windows, ma l'impronta TLS assomiglia a Python) — la richiesta viene bloccata con un 429 indipendentemente dall'IP.

Intestazione	Errore tipico	Soluzione
User-Agent	Versione obsoleta o stringa chiaramente di libreria	UA attuale di un vero Chrome/Safari, rotazione dal pool
Accept-Language	Assente o non corrisponde alla geolocalizzazione dell'IP	ru-RU per i marketplace russi
Referer	Vuoto, anche se un vero passaggio avviene sempre con Referer	Indicare la pagina precedente del catalogo
Sec-Fetch-*	Completamente assenti (non client browser)	Copiare l'insieme completo da DevTools di un vero browser

Il modo più semplice è copiare l'insieme completo delle intestazioni dalla scheda Network in DevTools di un vero browser, aprendo manualmente la pagina desiderata, e utilizzare proprio questo insieme nel parser — tenendo conto dell'ordine delle intestazioni, se la libreria lo consente (ad esempio, curl_cffi o httpx con ordine esplicito).

Motivo 3: Mancanza di rotazione delle sessioni e dei cookie

Un errore che spesso viene trascurato: il parser cambia IP per ogni richiesta, ma utilizza la stessa sessione di cookie o non salva affatto i cookie. Un vero utente riceve al primo accesso un insieme di cookie (token di sessione, identificatori di dispositivo, etichette di protezione antibot come Cloudflare __cf_bm o simili su Ozon/WB) e li utilizza in tutte le richieste successive all'interno della sessione.

Se invii una richiesta senza cookie ottenuti da una pagina "riscaldata", il sistema anti-bot vede una sessione "zero" — e questo è subito sospetto, specialmente quando si accede direttamente agli endpoint API, saltando la pagina principale. La soluzione è emulare l'intero scenario: prima caricare la pagina principale o la pagina di categoria, ottenere i cookie, attendere 1-2 secondi, e solo dopo accedere all'API desiderata o alla scheda prodotto, mantenendo i cookie nella stessa sessione durante la catena di richieste.

import requests

session = requests.Session()
session.headers.update({
    "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64)...",
    "Accept-Language": "ru-RU,ru;q=0.9"
})

# Riscaldamento della sessione
session.get("https://www.wildberries.ru/catalog/0/search.aspx")
time.sleep(1.5)

# Richiesta principale già con cookie
response = session.get(target_url)

Se utilizzi un browser anti-detect come Dolphin Anty o AdsPower per monitorare manualmente le schede prodotto o tramite automazione integrata, assicurati che il profilo salvi i cookie tra le sessioni e non venga avviato ogni volta "da zero" — questo attiva anche il sospetto del sistema.

Motivo 4: Comportamento simile a un bot

Anche con intestazioni e cookie perfetti, il parser può rivelarsi attraverso schemi comportamentali: ordine rigorosamente lineare nell'accesso ai prodotti (in ordine crescente di ID), intervallo identico tra le richieste fino al millisecondo, assenza di richieste "spazzatura" per la statica (immagini, CSS, JS), che un normale browser carica automaticamente.

I sistemi di protezione avanzati di Wildberries e Ozon analizzano non solo le richieste HTTP, ma anche se è stato eseguito JavaScript sulla pagina (tramite rilevamento headless), se il "mouse" si è mosso, se c'è stato scrolling. Se fai richieste HTTP pulite senza eseguire JS, e il sito si aspetta l'esecuzione di uno script per ottenere un token (ad esempio, un challenge anti-bot JavaScript), la richiesta senza l'esecuzione di questo script ottiene automaticamente 429 o 403.

La soluzione dipende dalla scala: per piccoli volumi è adatto l'uso di un browser headless (Playwright, Puppeteer) con emulazione dei movimenti del mouse e ritardi casuali. Per il parsing industriale — randomizzazione dell'ordine di scansione dei prodotti, aggiunta di "rumore" sotto forma di richieste a risorse secondarie, variabilità degli intervalli di tempo secondo una distribuzione normale, e non secondo un passo fisso.

Motivo 5: Impronta TLS/JA3 e HTTP/2

Questa è la causa tecnica "meno evidente", di cui non sono a conoscenza il 90% delle persone che si occupano di parsing senza una preparazione tecnica approfondita. Ogni client TLS (libreria requests, curl, urllib) lascia un'impronta unica durante l'instaurazione di una connessione HTTPS — un insieme di cifrature supportate, versioni del protocollo, estensioni TLS. Questa impronta è chiamata impronta JA3/JA4.

I sistemi anti-bot di livello Cloudflare, Akamai e le soluzioni interne dei grandi marketplace confrontano l'impronta JA3 con un database di bot e librerie noti. Il Python requests standard o il modulo https di Node.js hanno un'impronta facilmente rilevabile, completamente diversa dall'impronta di un vero Chrome. Anche con intestazioni e cookie perfetti, la richiesta viene bloccata proprio a livello di handshake TLS, prima che il server veda le intestazioni HTTP.

Inoltre, molti marketplace richiedono HTTP/2 con parametri specifici (ordine dei frame SETTINGS, prioritizzazione dei flussi) — le librerie basate su HTTP/1.1 si distinguono automaticamente in questo contesto. La soluzione è utilizzare librerie che emulano l'impronta di un vero browser: curl_cffi (emula l'impronta TLS di Chrome), tls-client, o browser headless completi basati su Chromium, che forniscono un'impronta "reale" per definizione.

Motivo 6: Limite a livello di account o chiave API

Se lavori tramite l'API ufficiale o semi-ufficiale del marketplace (ad esempio, l'API venditore di Wildberries o Ozon Seller API), il 429 può essere legato non all'IP, ma all'account venditore stesso o al token API. In questo caso, cambiare proxy è del tutto inutile — il limite è memorizzato sul server legato al tuo identificatore di account, e qualsiasi IP da quell'account riceverà lo stesso limite.

Questa situazione è tipica per i venditori che monitorano contemporaneamente i prezzi dei concorrenti tramite il proprio account e richiamano l'API per scaricare le giacenze — entrambi i flussi di richieste si sommano nel limite totale dell'account. La soluzione è distribuire il carico nel tempo, utilizzare le quote API ufficiali in modo più economico (caching dei dati che non cambiano ogni minuto), e per il monitoraggio dei prezzi dei concorrenti utilizzare un flusso di richieste non autorizzato separato, non legato all'account del venditore.

Controllare è semplice: se il 429 continua anche quando si accede da un nuovo IP pulito e senza alcun cookie dalle sessioni precedenti, ma sei loggato nel tuo account in una scheda adiacente — è probabile che il limite sia legato all'account.

Come diagnosticare la vera causa

Prima di cambiare l'infrastruttura, esegui una diagnosi seguendo il seguente algoritmo. Prima apri la pagina manualmente in un browser normale e assicurati che il 429 non si verifichi con un comportamento reale — questo confermerà che il problema è lato parser e non un blocco globale della regione.

Poi confronta le intestazioni del tuo parser con le intestazioni di un vero browser tramite DevTools (scheda Network → Copia come cURL). Se la differenza è minima, controlla l'impronta TLS tramite servizi come tls.peet.ws — invia una richiesta con la tua libreria e confronta l'hash JA3 con quello del browser di riferimento. Se la richiesta fallisce durante l'handshake TLS (la connessione si interrompe prima di ricevere la risposta HTTP) — la causa è nell'impronta, non nella frequenza o nelle intestazioni.

Successivamente, verifica se il limite è legato all'IP o all'account: fai una richiesta da un nuovo IP pulito senza autorizzazione. Se il 429 scompare — il problema era nella reputazione del precedente IP o nella frequenza da quell'indirizzo. Se il 429 persiste — cerca la causa nelle intestazioni, nel TLS o nel comportamento, e non nei proxy.

Checklist per risolvere il 429 senza cambiare proxy

1. Aggiungi ritardi casuali di 1-4 secondi tra le richieste invece di un intervallo fisso.
2. Copia l'insieme completo delle intestazioni di un vero browser, comprese Sec-Fetch-* e Accept-Language.
3. Salva e trasmetti i cookie all'interno di una sessione, iniziando dal riscaldamento della pagina principale.
4. Controlla l'impronta TLS della tua libreria — utilizza curl_cffi o un browser headless invece di un client HTTP pulito.
5. Randomizza l'ordine di scansione delle pagine e aggiungi richieste "di rumore" a risorse statiche.
6. Dividi il carico dell'account API e del monitoraggio anonimo dei prezzi in flussi diversi.
7. Implementa un backoff esponenziale al ricevimento di 429, e non una ripetizione immediata della richiesta.
8. Solo dopo aver verificato tutti i punti sopra — cambia proxy o espandi il pool di IP.

Quando i proxy sono comunque necessari e quali scegliere

Dopo aver risolto tutti e sei i motivi, i proxy rimangono un elemento importante dell'infrastruttura — ma già come mezzo di scalabilità, e non come unico modo per combattere i blocchi. Se il tuo compito è il monitoraggio parallelo di migliaia di schede Wildberries e Ozon da diversi "utenti virtuali", hai bisogno di un pool di IP con buona reputazione, per non accumulare una storia di blocchi su un unico indirizzo.

Per il monitoraggio massivo dei prezzi e dei cataloghi dei marketplace, i proxy residenziali sono i più adatti — utilizzano veri IP di provider domestici, quindi i sistemi anti-bot percepiscono le richieste come traffico di normali acquirenti, e non di data center. Questo è critico, poiché Wildberries e Ozon da tempo tengono blacklist di intervalli di IP di data center.

Se il compito è legato al controllo della versione mobile del sito, al lavoro tramite l'app del marketplace o al test della pubblicità in TikTok Ads e Facebook Ads con precisione geografica fino alla città, sono rilevanti i proxy mobili — hanno il massimo livello di fiducia nella maggior parte dei sistemi di protezione, poiché gli IP appartengono a veri operatori di telefonia mobile.

Per compiti meno sensibili — ad esempio, il parsing di cataloghi aperti senza autorizzazione su piccole quantità — si possono utilizzare proxy di data center: sono significativamente più economici e veloci, ma richiedono una configurazione più attenta delle intestazioni e dell'impronta TLS, poiché di per sé portano un rischio maggiore di essere sospettati.

Tipo di proxy	Quando risolve il 429	Quando non aiuta
Residenziali	IP già in blacklist per reputazione	Blocco per impronta TLS o intestazioni
Mobili	Necessaria la massima fiducia IP per scenari sensibili	Limite legato all'account, non all'IP
Data center	Parsing semplice di pagine aperte senza autorizzazione	Sistemi anti-bot rigorosi con controllo della reputazione degli intervalli

Conclusione

L'errore 429 durante il parsing raramente si risolve con un semplice pulsante "cambia proxy". Nella maggior parte dei casi, il problema risiede nella frequenza delle richieste, nelle intestazioni incomplete, nell'assenza di cookie di sessione, in un'impronta TLS rilevabile, in schemi comportamentali o nei limiti legati all'account, e non all'indirizzo IP. Esegui la diagnosi su ciascuno dei sei punti di questo articolo prima di spendere il budget per espandere il pool di proxy.

Quando la parte tecnica è impostata correttamente — le intestazioni corrispondono a un vero browser, l'impronta TLS non rivela la libreria, e le richieste imitano il comportamento naturale dell'utente — i proxy diventano davvero uno strumento efficace di scalabilità. Per il monitoraggio dei prezzi su Wildberries e Ozon in volumi industriali, ti consigliamo di iniziare con proxy residenziali: offrono il miglior equilibrio tra costo e livello di fiducia dei sistemi anti-bot.