Parsing Walmart: come scegliere un proxy e configurare la raccolta dati senza blocchi

1. Analisi della reputazione IP

PerimeterX controlla ogni indirizzo IP in base a un database di proxy noti, data center e VPN. Se il tuo IP è in questo database — riceverai un blocco o un CAPTCHA. Walmart filtra in modo particolarmente severo gli IP dei provider cloud popolari (AWS, Google Cloud, DigitalOcean).

2. Analisi comportamentale

Il sistema monitora come l'utente interagisce con la pagina: movimenti del mouse, velocità di scorrimento, clic. I parser su Selenium o Puppeteer vengono spesso identificati proprio qui — aprono le pagine troppo velocemente, senza pause naturali, non muovono il mouse.

3. TLS e fingerprinting HTTP

PerimeterX analizza l'impronta TLS della tua connessione (ordine dei cipher, estensioni) e le intestazioni delle richieste HTTP. Le librerie standard di Python (requests, urllib) hanno impronte uniche che vengono facilmente riconosciute. Anche se hai cambiato il User-Agent, il sistema vede una discrepanza tra le intestazioni e il reale browser.

4. Sfide JavaScript

In caso di richiesta sospetta, PerimeterX invia codice JavaScript che esegue controlli nel browser: disponibilità del Canvas API, WebGL, parametri dello schermo, font installati. I semplici parser HTTP (senza motore browser) non possono superare questi controlli e ricevono un blocco.

Tipo di proxy	Efficacia per Walmart	Velocità	Costo	Raccomandazione
Proxy residenziali	⭐⭐⭐⭐⭐ Ottimo — IP di utenti reali, minimo blocco	Media (200-800 ms)	Alta (da $7-15/GB)	Ottimale per la produzione
Proxy mobili	⭐⭐⭐⭐⭐ Ottimo — alto trust score, rari blocchi	Bassa (500-1500 ms)	Molto alta (da $50-100/mese per IP)	Per casi complessi
Proxy di data center	⭐⭐ Scarso — alta probabilità di blocco (70-90%)	Alta (50-150 ms)	Bassa (da $1-3/IP)	Non raccomandato
Proxy ISP	⭐⭐⭐⭐ Buono — IP residenziali statici	Alta (80-200 ms)	Media (da $30-80/mese per IP)	Per compiti a lungo termine

Proxy residenziali — standard d'oro per Walmart

Questi sono indirizzi IP di veri provider di servizi Internet domestici (Comcast, AT&T, Verizon negli Stati Uniti). Walmart li vede come normali acquirenti, quindi la percentuale di blocchi è minima — circa il 5-10% con una corretta configurazione. Il principale vantaggio è l'enorme pool di indirizzi (milioni di IP), che consente di impostare una rotazione efficace.

Quando utilizzare: monitoraggio dei prezzi su migliaia di prodotti, raccolta dati quotidiana, progetti a lungo termine. Per il parsing di Walmart i proxy residenziali sono la scelta ottimale in termini di efficienza e costo.

Proxy mobili — massima affidabilità

Gli IP degli operatori mobili (T-Mobile, Verizon Wireless) hanno il punteggio di fiducia più alto nei sistemi anti-bot. Il motivo è che un IP è utilizzato da migliaia di utenti reali (attraverso NAT dell'operatore), quindi bloccare un IP significa bloccare migliaia di acquirenti. Walmart praticamente non blocca gli IP mobili.

Quando utilizzare: se i proxy residenziali non riescono, se è necessario eseguire il parsing di sezioni particolarmente protette (ad esempio, prezzi per regioni specifiche), se il budget lo consente. I proxy mobili offrono praticamente il 100% di richieste riuscite, ma costano di più.

Proxy di data center — non per Walmart

Gli indirizzi IP dei server nei data center (AWS, OVH, Hetzner) vengono immediatamente riconosciuti da PerimeterX. Anche se acquisti IP "puliti" che non sono stati utilizzati in precedenza per il parsing, il sistema vede comunque che si tratta di un data center e non di un provider domestico. La percentuale di blocchi è del 70-90%.

Unico scenario d'uso: testare il parser su un piccolo volume di dati (10-50 pagine). Per la produzione non sono assolutamente adatti.

Con proxy residenziali:

• Dimensione media della pagina prodotto di Walmart: ~500 KB
• 10.000 prodotti × 500 KB = 5 GB di traffico al giorno
• Traffico mensile: 150 GB
• Costo a $10/GB: $1.500/mese
• Percentuale di richieste riuscite: 90-95%
• Costo reale considerando le ripetizioni: ~$1.650/mese

Con proxy di data center (teoricamente):

• Costo di 100 IP: ~$200/mese
• Percentuale di richieste riuscite: 10-30% (il resto sono blocchi)
• Necessità di fare 3-10 tentativi per ogni prodotto
• Traffico reale: 15-50 GB (a causa delle ripetizioni)
• Risultato: compito non realizzabile — gli IP vengono rapidamente bannati, CAPTCHA a ogni passo

Se hai bisogno di raccogliere dati per un'analisi di mercato o una ricerca una sola volta, puoi provare un approccio combinato:

• Utilizza proxy di data center per la raccolta iniziale degli URL dei prodotti (pagine delle categorie)
• Passa a proxy residenziali per ottenere informazioni dettagliate sui prodotti
• Costo: ~$50-100 per compito una tantum
• Tempo di esecuzione: 2-4 ore invece di 10-20 ore con i data center

Criterio	Residenziali	Data center
Volume di dati	Qualsiasi — da 100 a milioni di pagine	Solo piccoli volumi (fino a 1000 pagine)
Regolarità	Parsing quotidiano/settimanale	Solo compiti una tantum
Velocità di esecuzione	Stabile — senza ritardi per ripetizioni	Imprevedibile — molte ripetizioni
Affidabilità	Alta — 90-95% di successo	Bassa — 10-30% di successo
Costo dell'errore	Basso — paghi solo per il traffico riuscito	Alto — perdi tempo e denaro a causa dei ban

1. Rotazione per ogni richiesta (Rotating Proxies)

Ogni richiesta HTTP passa attraverso un nuovo indirizzo IP. Questo è il modo standard di operare della maggior parte dei fornitori di proxy residenziali.

Pro:

• Rischio minimo di blocco — ogni IP effettua 1-2 richieste
• Configurazione semplice — il fornitore gestisce il pool
• È possibile eseguire il parsing in modo aggressivo — centinaia di richieste al minuto

Contro:

• Problemi con le sessioni — se il sito utilizza i cookie, ogni richiesta = nuova sessione
• Più lento — ci vogliono 200-500 ms per stabilire una nuova connessione

Quando utilizzare: Per il parsing delle pagine dei prodotti Walmart, dove non è necessaria l'autenticazione e le sessioni. Questa è la strategia ottimale per la maggior parte dei compiti di monitoraggio dei prezzi.

2. Sticky Sessions (sessioni sticky)

Un indirizzo IP viene utilizzato per una serie di richieste per un certo periodo di tempo (di solito 5-30 minuti), poi si passa a un nuovo IP.

Pro:

• Conservazione delle sessioni e dei cookie — è possibile lavorare con il carrello, l'autenticazione
• Più veloce — riutilizza la connessione TCP
• Comportamento più "naturale" per i sistemi anti-bot

Contro:

• Rischio di blocco più alto — un IP effettua 10-50 richieste
• È necessario controllare i limiti — non più di 30-50 richieste da un IP

Quando utilizzare: Se hai bisogno di eseguire il parsing di dati che richiedono autenticazione (ad esempio, prezzi per utenti registrati), o se stai emulando il comportamento di un acquirente reale (navigazione nella categoria → prodotto → aggiunta al carrello).

3. Pool di IP statici con rotazione manuale

Prendi 50-100 IP residenziali statici (proxy ISP) e gestisci tu stesso la distribuzione delle richieste tra di essi.

Pro:

• Controllo completo — sai quanti richieste ha fatto ogni IP
• Massima velocità — gli IP statici sono più veloci dei rotating
• È possibile "riscaldare" gli IP — effettuare richieste legittime per aumentare la reputazione

Contro:

• Configurazione complessa — è necessario scrivere la logica di distribuzione delle richieste
• Più costoso — i proxy ISP costano $30-80 per IP al mese
• Rischio di perdita di IP — se uno viene bannato, dovrai sostituirlo

Quando utilizzare: Per sistemi ad alta richiesta con un volume di oltre 100.000 richieste al giorno, dove la velocità e la stabilità sono critiche. Richiede esperienza nello sviluppo di parser.

Per il monitoraggio dei prezzi (parsing semplice delle pagine dei prodotti):

• Tipo: Proxy rotanti con rotazione per ogni richiesta
• Ritardo tra le richieste: 2-5 secondi
• Parallelismo: 10-20 thread
• Geolocalizzazione: Stati Uniti (preferibilmente stato in cui ci sono negozi fisici Walmart)

Per il parsing complesso (con autenticazione, carrello):

• Tipo: Sticky sessions con durata di 10-15 minuti
• Limite di richieste per IP: massimo 30-40
• Ritardo tra le richieste: 3-7 secondi (simulazione umana)
• Parallelismo: 5-10 thread (meno aggressività)

1. User-Agent e intestazioni HTTP

Le librerie standard (Python requests, Node.js axios) inviano intestazioni che rivelano immediatamente un bot. Ad esempio, User-Agent: python-requests/2.28.1 — questo porta a un blocco del 100%.

Cosa sostituire:

• User-Agent — utilizza versioni recenti di Chrome/Firefox
• Accept — deve corrispondere al tipo di contenuto
• Accept-Language — en-US per il parsing di Walmart USA
• Accept-Encoding — gzip, deflate, br
• Referer — pagina precedente (categoria o principale)
• Sec-Fetch-* — intestazioni di Chrome per la protezione CSRF

2. Fingerprint TLS (JA3)

Ogni client HTTP ha un'impronta TLS unica — ordine dei cipher, estensioni TLS, versioni del protocollo. PerimeterX confronta questa impronta con il User-Agent: se scrivi "Chrome 120", ma l'impronta TLS è di Python — sei bloccato.

Soluzione:

• Utilizza librerie con supporto per TLS personalizzato: curl-impersonate (Python), tls-client (Go)
• Oppure utilizza un vero browser tramite Selenium/Puppeteer — hanno un'impronta TLS reale

3. Sfide JavaScript e fingerprinting Canvas

PerimeterX può inviare codice JavaScript che verifica: se il Canvas API è disponibile, WebGL, quali font sono installati, dimensione dello schermo, fuso orario. I semplici parser HTTP non possono eseguire questo codice.

Soluzione:

• Utilizza browser headless: Puppeteer, Playwright, Selenium
• Assicurati di attivare la modalità di bypass del rilevamento: puppeteer-extra-plugin-stealth
• Randomizza i parametri: dimensione della finestra, fuso orario, lingua del browser

GET /ip/Product-Name/12345678 HTTP/1.1
Host: www.walmart.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.9
Accept-Encoding: gzip, deflate, br
Referer: https://www.walmart.com/browse/electronics/tv-video/3944_1060825
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: same-origin
Sec-Fetch-User: ?1
Upgrade-Insecure-Requests: 1
Connection: keep-alive

Tipo di richiesta	Ritardo tra le richieste	Massimo richieste da un IP	Parallelismo
Pagine prodotto	2-5 secondi	30-50 pagine (con rotating)	10-20 thread
Pagine categoria	3-7 secondi	20-30 pagine	5-10 thread
Ricerca	5-10 secondi	10-15 richieste	3-5 thread
API-endpoint	1-3 secondi	50-100 richieste	20-30 thread

Se fai richieste esattamente ogni 3 secondi (3.000, 6.000, 9.000...), il sistema anti-bot riconosce il pattern. Un vero essere umano non può essere così preciso — avrà variazioni: 2.8 sec, 3.4 sec, 2.9 sec.

Implementazione corretta del ritardo (Python):

import random
import time

# Sbagliato — ritardo fisso
time.sleep(3)

# Corretto — ritardo randomizzato
delay = random.uniform(2.0, 5.0)  # da 2 a 5 secondi
time.sleep(delay)

1. Rate limiting adattivo

Monitora la percentuale di richieste riuscite. Se inizi a ricevere 403 o CAPTCHA — aumenta automaticamente i ritardi e diminuisci il parallelismo.

success_rate = successful_requests / total_requests

if success_rate < 0.8:  # meno del 80% di successo
    delay_multiplier *= 1.5  # aumentiamo i ritardi
    parallel_workers -= 2    # diminuiamo i thread
elif success_rate > 0.95:  # più del 95% di successo
    delay_multiplier *= 0.9  # possiamo accelerare
    parallel_workers += 1

2. Distribuzione per ore del giorno

Esegui il parsing durante le ore di picco di attività degli utenti reali (sera negli Stati Uniti, 18:00-22:00 EST). In questo momento, il tuo traffico si mescola con quello legittimo, e il sistema anti-bot è meno aggressivo. Di notte (2:00-6:00 EST) la protezione può essere più severa, poiché ci sono meno utenti reali.

3. Riscaldamento degli indirizzi IP

Prima di iniziare un parsing massiccio, "riscalda" gli indirizzi IP con richieste legittime: apri la pagina principale, alcune categorie, fai una ricerca. Questo crea una storia di attività e aumenta il punteggio di fiducia degli IP.

# Sequenza di riscaldamento per un nuovo IP
1. GET https://www.walmart.com/  # principale
2. Ritardo 3-5 sec
3. GET https://www.walmart.com/browse/electronics  # categoria
4. Ritardo 4-7 sec
5. GET https://www.walmart.com/search?q=laptop  # ricerca
6. Ritardo 3-6 sec
# Ora puoi eseguire il parsing dei prodotti target