Stai avviando un parser o riscaldando account tramite proxy, calcolando il consumo in base alle dimensioni delle pagine — e ricevi una fattura 2-3 volte superiore a quella prevista. Non si tratta di una truffa da parte del provider: il traffico include tutto ciò che è realmente passato attraverso il canale — intestazioni delle richieste, handshake TLS, tentativi di connessione e pacchetti di servizio. Analizziamo da cosa deriva il "conto" per il traffico e come ridurre il consumo senza compromettere la qualità del lavoro.
Cosa considera realmente il provider come traffico
Quando valuti il consumo "a occhio", di solito hai in mente una formula: dimensione della pagina HTML più immagini. Ma il provider proxy considera il volume totale di dati che è passato attraverso entrambe le direzioni del canale — in uscita (richiesta) e in entrata (risposta). Questo volume include non solo il payload utile, ma anche tutto il traffico di servizio: intestazioni di protocollo, metadati TLS, pacchetti ACK TCP, tentativi di connessione ripetuti in caso di timeout.
Per una singola richiesta a una pagina normale, il rapporto tra "dati utili" e "dati di servizio" può essere 80/20. Ma se lavori con API, dove le risposte sono piccole (pochi kilobyte di JSON), e ci sono molte intestazioni e handshake — il rapporto può facilmente invertirsi. È per questo che gli arbitraggiatori, che inviano decine di migliaia di piccole richieste a API pubblicitarie o marketplace, spesso si sorprendono della fattura: ogni richiesta porta con sé una "tassa" fissa indipendentemente dalla dimensione del payload utile.
Un altro punto importante: il provider calcola il traffico a livello del server proxy, cioè tutto il traffico che è realmente passato attraverso l'IP — inclusi i tentativi non riusciti, i reindirizzamenti, i caricamenti ripetuti delle risorse sulla pagina (stili, script, tracker), che il tuo script o browser ha richiesto automaticamente, anche se avevi bisogno solo del testo.
Intestazioni HTTP/HTTPS: il peso nascosto di ogni richiesta
Ogni richiesta HTTP e ogni risposta portano un insieme di intestazioni: User-Agent, Cookie, Accept-Language, Referer, Content-Type e decine di altre. Nei browser moderni e negli strumenti anti-detect (Dolphin Anty, AdsPower, Multilogin) l'insieme di intestazioni può occupare da 500 byte a 2-3 KB per ogni richiesta — specialmente se nei cookie si è accumulata una sessione con decine di valori.
Esempio: se fai 10.000 richieste a un'API di un marketplace con cookie di sessione di 1.5 KB, solo per le intestazioni andranno circa 15 MB di traffico — e questo senza contare il corpo della risposta. Scalando su più account e profili, questo numero cresce linearmente.
| Tipo di intestazione | Dimensione media | Impatto sul traffico |
|---|---|---|
| User-Agent | 100-150 byte | Basso, ma si accumula su larga scala |
| Cookie (sessione) | 500-2000 byte | Alto in sessioni lunghe |
| Referer / Origin | 50-200 byte | Basso |
| Intestazioni Accept-* | 150-300 byte | Basso |
| Intestazioni di risposta del server | 300-800 byte | Medio, non dipende da te |
Conclusione pratica: se stai scrivendo uno script per monitorare i prezzi su Wildberries o Ozon, pulisci i cookie dai valori non utilizzati e non portare nelle richieste intestazioni superflue copiate "per ogni evenienza" dagli strumenti di sviluppo del browser.
Handshake TLS: quanto traffico consuma la crittografia
Praticamente tutto il web moderno funziona tramite HTTPS, il che significa che ogni nuova connessione inizia con un handshake TLS — uno scambio di certificati, chiavi di crittografia e parametri di protocollo. Un completo handshake TLS (TLS 1.2 o 1.3) pesa da 4 a 8 KB a seconda delle dimensioni del certificato del sito e delle estensioni del protocollo utilizzate.
Se apri una nuova connessione per ogni richiesta (e non utilizzi una connessione persistente), l'handshake TLS si ripete ogni volta. Con 10.000 richieste senza riutilizzare la connessione, otterrai ulteriori 40-80 MB di traffico solo per la crittografia — questo può essere più del contenuto utile stesso.
TLS 1.3 è leggermente più leggero di TLS 1.2 grazie al numero ridotto di round-trip, ma la differenza è percepibile solo con un gran numero di connessioni. Per i proxy mobili, dove la rete dell'operatore aggiunge la propria latenza e reinstallazioni di sessione, l'overhead TLS è particolarmente evidente — questo è qualcosa da considerare quando si scelgono proxy mobili per compiti con richieste brevi e frequenti.
Retry: come le richieste ripetute raddoppiano il consumo
I retry sono la voce di spesa per il traffico più invisibile e costosa. Se il tuo parser o script è impostato per ripetere automaticamente in caso di timeout o errore 429/503, ogni richiesta non riuscita ha già speso traffico per stabilire la connessione, l'handshake TLS e le intestazioni — e poi tutto questo processo si ripete da capo.
Un errore comune nell'automazione SMM e nel parsing dei marketplace è una politica di retry aggressiva senza ritardo esponenziale: lo script fa 5 tentativi consecutivi con un intervallo di un secondo al primo segno di blocco dell'IP. Di conseguenza, per una risposta "utile" si spende il traffico di cinque tentativi non riusciti più la richiesta finale riuscita.
Questo è particolarmente critico quando si lavora con proxy data center su siti con protezione aggressiva (ad esempio, Avito o grandi marketplace), che possono restituire CAPTCHA o blocchi sulla maggior parte delle richieste da un IP "caldo". In questo caso, ha senso considerare proxy residenziali — sono meno soggetti a blocchi al primo tentativo, il che riduce il numero di retry e, di conseguenza, il reale consumo di traffico.
Keep-Alive vs nuove connessioni
HTTP Keep-Alive consente di riutilizzare una singola connessione TCP/TLS per più richieste consecutive, evitando il ripetuto handshake. Questa è una delle ottimizzazioni più efficaci per il traffico, disponibile in quasi tutti i client HTTP e browser anti-detect.
Se utilizzi librerie per il parsing (requests, httpx, axios) senza specificare esplicitamente una sessione con connessione persistente, ogni richiesta per impostazione predefinita può aprire una nuova connessione TCP. In combinazione con i proxy, questo significa: nuova connessione fino al server proxy, nuovo TLS fino al sito target, e tutto l'overhead si ripete per ogni chiamata.
| Modalità di connessione | Overhead su 1000 richieste |
|---|---|
| Nuova connessione per ogni richiesta | 4-8 MB (solo TLS) |
| Keep-Alive, una sessione per 50 richieste | 0.1-0.2 MB (un handshake per gruppo) |
La differenza è notevole — e questa è una pura economia di traffico senza alcuna modifica del payload utile delle richieste.
Come calcolano il traffico i diversi tipi di proxy
Il modello di fatturazione del traffico dipende dal tipo di proxy. I proxy dei data center spesso presentano una tariffazione in base al volume di traffico o al numero di IP/porte — l'infrastruttura stessa è più veloce e aggiunge un overhead minimo per il routing. I proxy residenziali e mobili di solito hanno una tariffazione più rigorosa, perché gli IP reali degli utenti sono una risorsa più costosa e limitata, e il percorso attraverso l'operatore o il provider domestico aggiunge ulteriori hop e, di conseguenza, un po' più di dati di servizio.
I proxy mobili, in questo senso, sono i più "costosi" in termini di traffico: le reti cellulari aggiungono i propri meccanismi di reinstallazione delle sessioni, traduzioni NAT e talvolta compressione/decompressione del traffico a livello dell'operatore, il che aumenta il contatore dei dati passati rispetto alla stessa richiesta attraverso una rete fissa.
Se l'obiettivo è un volume stabile di richieste con un overhead minimo (ad esempio, parsing massivo dei prezzi su Wildberries o Ozon), i proxy dei data center sono più adatti — sono più veloci e prevedibili in termini di consumo di traffico per compiti simili.
Come ridurre il consumo di traffico nella pratica
Analizziamo i passaggi concreti che riducono il reale consumo di traffico senza compromettere la funzionalità del parser, dell'automazione o del multi-accounting.
1. Disattiva il caricamento di risorse non necessarie. Se hai bisogno solo del testo della pagina o della risposta JSON dell'API, disattiva il caricamento di immagini, font, script analitici e tracker pubblicitari nelle impostazioni del browser anti-detect o dello strumento headless. Questo riduce spesso il consumo di traffico del 60-80% per i compiti di parsing.
2. Utilizza Keep-Alive e pool di connessioni. Configura il client HTTP per riutilizzare la sessione per un gruppo di richieste a un unico host — questo riduce drasticamente il numero di handshake TLS.
3. Imposta una politica di retry ragionevole. Un ritardo esponenziale (1s → 2s → 4s) con un limite di 3 tentativi invece di 5-10 tentativi consecutivi aggressivi riduce il traffico inutile derivante da richieste non riuscite e allo stesso tempo diminuisce il rischio di un ulteriore blocco dell'IP.
4. Pulisci i cookie e le intestazioni di sessione. Periodicamente rimuovi i valori accumulati nei cookie che non sono utilizzati dal sito target — particolarmente rilevante per lunghe sessioni di riscaldamento degli account su Instagram o TikTok tramite browser anti-detect.
5. Memorizza in cache le risposte statiche. Se i dati (ad esempio, il catalogo dei prodotti) non cambiano ogni minuto, memorizza la risposta localmente invece di fare una nuova richiesta tramite proxy ad ogni ciclo di monitoraggio.
6. Utilizza la compressione. Assicurati che l'intestazione Accept-Encoding: gzip venga inviata e che il server restituisca effettivamente una risposta compressa — questo riduce il volume del traffico in entrata su pagine con molto testo o JSON.
Strumenti per il monitoraggio del traffico
Per capire dove va realmente il traffico, è utile guardare non solo al contatore del provider, ma anche alla ripartizione dettagliata delle richieste. A questo scopo, sono adatti:
- Charles Proxy / Fiddler — mostrano la dimensione di ogni richiesta e risposta, comprese le intestazioni, il che aiuta a trovare cookie "pesanti" o risorse superflue.
- Wireshark — per un'analisi approfondita dell'overhead TCP/TLS a livello di pacchetti, se è necessario valutare il reale peso dell'handshake.
- Contatori di traffico integrati nei browser anti-detect (Dolphin Anty, AdsPower, GoLogin) — molti mostrano il consumo per ogni profilo separatamente, il che è comodo per distribuire il budget tra gli account.
- Logging a livello di client HTTP — quando scrivi i tuoi script di parsing, è utile registrare la dimensione della richiesta/risposta per ogni chiamata, in modo da individuare anomalie.
Confrontare le letture dei tuoi strumenti con il contatore del provider proxy aiuta a capire rapidamente dove si perde traffico — nei retry, nel TLS o nel caricamento di risorse superflue.
Checklist di ottimizzazione prima del lancio
Prima di un lancio su larga scala del parser, dell'automazione SMM o del riscaldamento degli account pubblicitari, segui un breve elenco:
- Disattivato il caricamento di immagini, font, analisi dove non sono necessari;
- Impostato Keep-Alive / riutilizzo della sessione per una serie di richieste a un unico host;
- Politica di retry limitata a 2-3 tentativi con ritardo, e non ripetizioni infinite;
- I cookie di sessione vengono periodicamente puliti da valori non utilizzati;
- Compressione delle risposte attivata (gzip/deflate/br);
- Cache locale per richieste statiche ripetute;
- Tipo di proxy scelto in base all'attività: data center per velocità e volume, residenziali per bypassare i blocchi, mobili per social media e piattaforme pubblicitarie.
Conclusione
Il consumo di traffico tramite proxy non riguarda solo i dati utili della pagina, ma anche tutto l'overhead di servizio: intestazioni, handshake TLS, retry in caso di errori. Comprendere questa meccanica consente di pianificare meglio il budget per i proxy ed evitare spiacevoli sorprese nella fattura, soprattutto durante la scalabilità del parsing dei marketplace, dell'automazione SMM o del riscaldamento degli account pubblicitari.
Se il tuo obiettivo è un parsing stabile con un consumo di traffico prevedibile, presta attenzione ai proxy dei data center. Per lavorare con social media e piattaforme pubblicitarie, dove è importante una bassa frequenza di blocchi, sono più adatti i proxy mobili. E se hai bisogno di un equilibrio tra anonimato e stabilità per bypassare la protezione dei siti — considera i proxy residenziali, che riducono il numero di retry grazie a blocchi più rari.