Situazione classica: uno script per monitorare i prezzi su Wildberries o Ozon funziona perfettamente sul laptop di casa, ma dopo il trasferimento su VPS inizia a ricevere 403, captcha o un ban immediato per IP. Lo sviluppatore cambia le intestazioni, aggiunge ritardi — ma il risultato non cambia. Il problema quasi mai risiede nel codice del parser in sé, ma nell'ambiente da cui effettua le richieste. Analizziamo 7 motivi specifici e cosa cambiare affinché il parser funzioni stabilmente proprio sul server.
Perché funziona tutto localmente, ma sul server c'è un ban
Quando si avvia il parser da un computer di casa, il sito vede la richiesta da un normale IP residenziale del proprio provider, dalla regione abituale, con un ambiente browser reale, se si utilizza Selenium o Playwright con un profilo autentico. Non appena lo stesso script si sposta su VPS in Germania, Paesi Bassi o Stati Uniti, la situazione cambia completamente: l'IP appartiene a un data center, il fingerprint TLS può differire a causa di versioni diverse delle librerie, il fuso orario del server non coincide con la geolocalizzazione dell'IP e la frequenza delle richieste aumenta drasticamente, poiché il server funziona 24/7 senza interruzioni.
I sistemi anti-bot di Wildberries, Ozon, Avito e la maggior parte dei grandi marketplace non si basano più solo sull'User-Agent. Analizzano un insieme di decine di segnali: tipo di IP, velocità e regolarità delle richieste, comportamento sulla pagina, corrispondenza delle intestazioni e dei parametri TLS, presenza di cookie e storia delle sessioni. La macchina locale supera casualmente il controllo su molti punti, il server fallisce quasi su tutti. Di seguito è riportata un'analisi dettagliata di ciascun motivo.
Motivo 1: IP del data center invece di un IP residenziale
Questo è il motivo n. 1 nell'80% dei casi. Gli indirizzi IP dei VPS e dei server cloud (AWS, DigitalOcean, Hetzner, normali hosting VDS) si trovano nelle banche dati dei data center — gli ASN di questi provider sono pubblicamente noti e utilizzati dai sistemi anti-bot per la filtrazione immediata del traffico. I marketplace utilizzano tali elenchi in primo luogo, poiché il 95% del parsing automatizzato proviene proprio da IP server.
La soluzione è utilizzare IP che visivamente non si differenziano da un normale utente di internet. Per il parsing di Wildberries, Ozon e Avito, i proxy residenziali sono i più adatti: si tratta di indirizzi IP reali di provider domestici, assegnati a normali abbonati. I sistemi anti-bot vedono tale richiesta come traffico da un utente reale, e non da un server in un data center, il che elimina gran parte dei blocchi immediatamente.
Motivo 2: Nessuna rotazione degli IP e limite sulla frequenza delle richieste
Su una macchina locale si effettuano 20–50 richieste manualmente durante i test, e il sito non se ne accorge. Sul server, lo script viene eseguito tramite cron ogni 5 minuti e gestisce migliaia di schede prodotto consecutive da un solo IP. Tale pattern è un segnale diretto per il sistema anti-bot: una persona reale non può aprire 3000 pagine di catalogo in un'ora senza una singola pausa.
È necessario introdurre la rotazione degli IP su un pool di proxy e limitare il numero di richieste a un indirizzo in un'unità di tempo. Regola pratica: non più di 30–60 richieste da un IP al minuto per le schede prodotto, con cambio automatico dell'indirizzo dopo ogni lotto di richieste. Ecco un esempio di impostazione della rotazione in Python tramite un pool di proxy:
import requests
proxies_pool = [
"http://user:[email protected]:9000",
"http://user:[email protected]:9001",
"http://user:[email protected]:9002",
]
def get_page(url, session_id):
proxy = proxies_pool[session_id % len(proxies_pool)]
resp = requests.get(
url,
proxies={"http": proxy, "https": proxy},
headers={"User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64)"},
timeout=10
)
return resp.textQuando si raccolgono grandi volumi di schede al giorno, è più comodo utilizzare proxy con rotazione automatica degli IP su richiesta o tramite timer — questo elimina la necessità di mantenere manualmente un elenco di indirizzi.
Motivo 3: Intestazioni e User-Agent non simili a un browser
Molti parser su requests o aiohttp inviano richieste con un insieme minimo di intestazioni o con lo User-Agent standard della libreria, che rivela immediatamente lo script (ad esempio python-requests/2.31.0). Su una macchina locale, tramite browser, l'insieme delle intestazioni è completo: Accept, Accept-Language, Accept-Encoding, Sec-Ch-Ua, Referer e altri — la loro combinazione appare naturale.
È necessario copiare l'intero insieme di intestazioni di un browser reale, inclusa l'ordine di invio — alcuni sistemi anti-bot controllano anche questo. Inoltre, è importante ruotare l'User-Agent in modo sincrono con la versione del fingerprint TLS (vedi il punto successivo), altrimenti la discrepanza tra l'intestazione del browser e il reale client TLS diventerà un nuovo segnale di bot.
Motivo 4: Il fingerprint TLS/JA3 rivela lo script
Questo è un motivo meno noto, ma estremamente comune per i ban proprio sul server. Le librerie requests, urllib, aiohttp utilizzano la propria implementazione del handshake TLS, che differisce dall'implementazione in Chrome o Firefox. I sistemi anti-bot calcolano il fingerprint JA3/JA4 della connessione TLS — e questo del python-script non assomiglia affatto al fingerprint di un vero browser, anche se le intestazioni sono state copiate perfettamente.
La soluzione è utilizzare librerie che emulano il fingerprint TLS di un browser (ad esempio curl_cffi, tls-client in Python, o un vero browser headless basato su Chromium tramite Playwright/Puppeteer). La seconda opzione è lavorare non tramite un client HTTP puro, ma tramite un motore browser gestito in combinazione con uno strumento anti-detect, dove TLS e intestazioni sono formati dal vero kernel del browser, e non dall'emulazione della libreria.
Motivo 5: Fuso orario, locale e server DNS
Se lo script emula un browser tramite Selenium o Playwright, il sistema anti-bot può controllare il fuso orario di sistema, la lingua dell'interfaccia, il risolutore DNS e persino la perdita WebRTC del vero IP del server. Un VPS in un data center di Francoforte con fuso orario di sistema UTC e provider DNS dell'host, utilizzando proxy con IP da Mosca, crea una chiara discrepanza nei dati geografici — questo è uno dei segnali più affidabili per il rilevamento.
Tutti i parametri dell'ambiente — fuso orario, lingua del browser, DNS, geolocalizzazione tramite WebRTC — devono corrispondere alla regione dell'indirizzo IP utilizzato per la richiesta. È proprio per risolvere questo problema che sono stati creati i browser anti-detect: Dolphin Anty, AdsPower, Multilogin, Octo Browser e GoLogin consentono di impostare un "profilo browser" separato per ogni proxy, dove il fuso orario, il locale, la risoluzione dello schermo e WebRTC vengono automaticamente adattati alla geolocalizzazione dell'IP.
Motivo 6: Il pattern delle richieste è troppo "robotico"
Un umano scorre il catalogo con pause diverse, clicca su prodotti casuali, a volte torna indietro, scorre la pagina in modo irregolare. Lo script server di solito effettua richieste a intervalli regolari (ad esempio esattamente ogni 2 secondi) e si rivolge solo agli URL necessari senza "rumore" attorno — senza caricare immagini, script, senza visitare la homepage prima della scheda prodotto.
Cosa cambiare: aggiungere ritardi casuali (non fissi di 2 secondi, ma casuali da 1.5 a 6 secondi), visitare periodicamente pagine intermedie (categoria → scheda, e non richiesta diretta all'API), emulare lo scroll e i movimenti del mouse quando si lavora tramite un browser headless. Questo aumenta il tempo di raccolta dei dati, ma riduce drasticamente il numero di ban.
Motivo 7: Le sessioni e i cookie non vengono mantenuti tra le richieste
Spesso il parser sul server crea una nuova sessione di richieste per ogni richiesta — senza cookie, senza token di autorizzazione salvato, senza storia delle visite. I marketplace come Wildberries e Ozon forniscono cookie temporanei e token al primo accesso, e le richieste successive senza di essi appaiono sospette, come se ogni richiesta fosse effettuata da un nuovo visitatore anonimo.
Schema corretto: una sessione (requests.Session() o contesto del browser) — per un IP dal pool di proxy, con salvataggio dei cookie durante l'intero ciclo di richieste a questo IP. Quando si cambia proxy, è necessario iniziare una nuova sessione con cookie puliti, imitando un nuovo utente, e non continuare a utilizzare vecchi cookie con un nuovo IP — questo crea anch'esso una discrepanza e attiva il blocco.
Checklist: cosa cambiare in ordine
Se il parser viene costantemente bloccato sul server, ma funziona localmente, controlla le modifiche in questo ordine — così troverai più rapidamente la causa:
| Passo | Cosa controllare | Cosa cambiare |
|---|---|---|
| 1 | Tipo di IP del server | Passare a proxy residenziali invece di un IP diretto di hosting |
| 2 | Frequenza delle richieste | Introdurre la rotazione degli IP e il limite delle richieste per indirizzo |
| 3 | Intestazioni della richiesta | Copiare l'intero insieme di intestazioni di un browser reale |
| 4 | Fingerprint TLS | Utilizzare curl_cffi / browser headless invece di pure requests |
| 5 | Fuso orario e locale | Impostare il profilo in Dolphin Anty / AdsPower per la regione dell'IP |
| 6 | Pattern di comportamento | Randomizzare i ritardi, aggiungere pagine intermedie |
| 7 | Sessioni e cookie | Collegare una sessione a un IP per l'intero ciclo di richieste |
Per il parsing ad alta frequenza dei cataloghi di Wildberries e Ozon, dove la velocità di navigazione di migliaia di pagine è importante, spesso si combinano due tipi di proxy: proxy dei data center per richieste tecniche preliminari (controllo della disponibilità, codici di stato) e proxy residenziali — per la raccolta finale dei dati dalle schede, dove è importante mascherarsi da un utente reale. Per le applicazioni mobili dei marketplace e Avito, a volte sono più efficaci proxy mobili, poiché raramente finiscono nelle liste di blocco automatico per ASN.
Conclusione
Il ban del parser sul server durante il funzionamento della versione locale è quasi sempre legato non alla logica dello script, ma all'ambiente: tipo di IP, fingerprint TLS, intestazioni, fuso orario, pattern delle richieste e gestione delle sessioni. Controllando ciascuno dei 7 motivi in ordine — dal più comune (IP del data center) al meno evidente (discrepanza tra fuso orario e regione dell'IP) — è possibile ripristinare il funzionamento stabile del parser senza modificare la logica aziendale principale della raccolta dei dati.
Se raccogli prezzi e disponibilità su Wildberries, Ozon o Avito in volumi industriali, inizia sostituendo l'IP: prova i proxy residenziali invece dell'indirizzo standard VPS — nella maggior parte dei casi questo elimina fino al 70% dei blocchi ancora prima di iniziare a configurare intestazioni e fingerprint TLS.