Vous lancez un parseur ou un réchauffement de comptes via un proxy, vous évaluez la consommation en fonction de la taille des pages — et vous recevez une facture 2 à 3 fois plus élevée que prévu. Ce n'est pas une arnaque de la part du fournisseur : le trafic inclut tout ce qui a réellement transité par le canal — les en-têtes de requêtes, la poignée de main TLS, les tentatives de connexion et les paquets de service. Analysons la composition du « chèque » pour le trafic et comment réduire la consommation sans perte de qualité de service.
Ce que le fournisseur considère comme du trafic
Lorsque vous évaluez la consommation « à l'œil », vous avez généralement en tête la formule : taille de la page HTML plus images. Mais le fournisseur de proxy compte le volume total de données ayant transité dans les deux sens du canal — sortant (requête) et entrant (réponse). Ce volume comprend non seulement la charge utile, mais aussi tout le trafic de service : en-têtes de protocole, métadonnées TLS, paquets ACK TCP, tentatives de connexion répétées en cas de timeout.
Pour une requête à une page ordinaire, le rapport « données utiles » à « données de service » peut être de 80/20. Mais si vous travaillez avec une API, où les réponses sont petites (quelques kilo-octets de JSON), et où il y a beaucoup d'en-têtes et de poignées de main — le rapport peut facilement s'inverser. C'est pourquoi les arbitragistes qui envoient des dizaines de milliers de petites requêtes à des API publicitaires ou des places de marché sont souvent surpris par la facture : chaque requête entraîne une « taxe » fixe indépendamment de la taille de la charge utile.
Un autre point important : le fournisseur compte le trafic au niveau du serveur proxy, c'est-à-dire tout le trafic qui a réellement transité par l'IP — y compris les tentatives échouées, les redirections, les rechargements de ressources sur la page (styles, scripts, trackers) que votre script ou navigateur a demandés automatiquement, même si vous n'aviez besoin que du texte.
En-têtes HTTP/HTTPS : le poids caché de chaque requête
Chaque requête HTTP et chaque réponse portent un ensemble d'en-têtes : User-Agent, Cookie, Accept-Language, Referer, Content-Type et des dizaines d'autres. Dans les navigateurs modernes et les outils anti-détection (Dolphin Anty, AdsPower, Multilogin), l'ensemble des en-têtes peut occuper de 500 octets à 2-3 Ko par requête — surtout si des sessions avec des dizaines de valeurs se sont accumulées dans les cookies.
Exemple : si vous faites 10 000 requêtes à l'API d'une place de marché avec des cookies de session de 1,5 Ko, rien que pour les en-têtes, cela prendra environ 15 Mo de trafic — et cela sans compter le corps de la réponse. En se développant sur plusieurs comptes et profils, ce chiffre augmente linéairement.
| Type d'en-tête | Taille moyenne | Impact sur le trafic |
|---|---|---|
| User-Agent | 100-150 octets | Faible, mais s'accumule à grande échelle |
| Cookie (session) | 500-2000 octets | Élevé lors de longues sessions |
| Referer / Origin | 50-200 octets | Faible |
| En-têtes Accept-* | 150-300 octets | Faible |
| En-têtes de réponse du serveur | 300-800 octets | Moyen, indépendant de vous |
Conclusion pratique : si vous écrivez un script pour surveiller les prix sur Wildberries ou Ozon, nettoyez les cookies des valeurs inutilisées et ne tirez pas dans la requête des en-têtes superflus copiés « au cas où » depuis les DevTools du navigateur.
Poignée de main TLS : combien de trafic consomme le chiffrement
Pratiquement tout le web moderne fonctionne via HTTPS, ce qui signifie que chaque nouvelle connexion commence par une poignée de main TLS — un échange de certificats, de clés de chiffrement et de paramètres de protocole. Une poignée de main TLS complète (TLS 1.2 ou 1.3) pèse entre 4 et 8 Ko selon la taille du certificat du site et les extensions de protocole utilisées.
Si vous ouvrez une nouvelle connexion pour chaque requête (et n'utilisez pas de connexion persistante), la poignée de main TLS se répète à chaque fois. Avec 10 000 requêtes sans réutilisation de connexion, vous obtiendrez 40-80 Mo de trafic supplémentaire juste pour le chiffrement — cela peut être plus que le contenu utile lui-même.
TLS 1.3 est légèrement plus léger que TLS 1.2 grâce à un nombre réduit de round-trips, mais la différence est perceptible seulement avec un grand nombre de connexions. Pour les proxies mobiles, où le réseau de l'opérateur ajoute sa propre latence et des réinitialisations de session, le surcoût TLS se fait particulièrement sentir — il est donc important de le prendre en compte lors du choix de proxies mobiles pour des tâches avec des requêtes courtes fréquentes.
Retries : comment les requêtes répétées doublent la consommation
Les retries sont la dépense de trafic la plus discrète et la plus coûteuse. Si votre parseur ou script est configuré pour répéter automatiquement en cas de timeout ou d'erreur 429/503, chaque requête échouée a déjà consommé du trafic pour établir la connexion, la poignée de main TLS et les en-têtes — et tout ce processus se répète.
Une erreur fréquente dans l'automatisation SMM et le parsing des places de marché est une politique de retries agressive sans délai exponentiel : le script fait 5 tentatives consécutives avec un intervalle d'une seconde dès le premier signe de blocage de l'IP. En conséquence, pour une seule réponse « utile », le trafic de cinq tentatives échouées plus la requête réussie finale est dépensé.
Cela est particulièrement critique lors de l'utilisation de proxies de centre de données sur des sites avec une protection agressive (par exemple, Avito ou de grandes places de marché), qui peuvent renvoyer un captcha ou bloquer la plupart des requêtes avec une IP « chaude ». Dans ce cas, il est judicieux de se tourner vers proxies résidentiels — ils sont moins souvent bloqués dès la première requête, ce qui réduit le nombre de retries et, par conséquent, la consommation réelle de trafic.
Keep-Alive vs nouvelles connexions
HTTP Keep-Alive permet de réutiliser une seule connexion TCP/TLS pour plusieurs requêtes consécutives, évitant ainsi la répétition de la poignée de main. C'est l'une des optimisations de trafic les plus efficaces, disponible dans presque tous les clients HTTP et navigateurs anti-détection.
Si vous utilisez des bibliothèques pour le parsing (requests, httpx, axios) sans spécifier explicitement une session avec connexion persistante, chaque requête peut par défaut ouvrir une nouvelle connexion TCP. En combinaison avec un proxy, cela signifie : nouvelle connexion jusqu'au serveur proxy, nouveau TLS jusqu'au site cible, et tout le surcoût se répète à chaque appel.
| Mode de connexion | Overhead sur 1000 requêtes |
|---|---|
| Nouvelle connexion pour chaque requête | 4-8 Mo (juste pour TLS) |
| Keep-Alive, une session pour 50 requêtes | 0.1-0.2 Mo (une poignée de main pour le groupe) |
La différence est énorme — et c'est une économie de trafic pure sans aucune modification de la charge utile des requêtes.
Comment différents types de proxy comptent le trafic
Le modèle de facturation du trafic dépend du type de proxy. Les proxies de centres de données ont souvent une tarification basée sur le volume de trafic ou le nombre d'IP/ports — l'infrastructure elle-même étant plus rapide et ajoutant un minimum de surcoût pour le routage. Pour les proxies résidentiels et mobiles, le trafic est généralement facturé plus strictement, car les IP réelles des utilisateurs sont une ressource plus coûteuse et limitée, et le parcours via l'opérateur ou le fournisseur d'accès domestique ajoute des sauts supplémentaires et, par conséquent, un peu plus de données de service.
Les proxies mobiles sont les plus « coûteux » en termes de trafic : les réseaux cellulaires ajoutent leurs propres mécanismes de réinitialisation de session, de NAT et parfois de compression/décompression du trafic au niveau de l'opérateur, ce qui augmente le compteur de données passées par rapport à la même requête via un réseau fixe.
Si la tâche consiste à avoir un volume stable de requêtes avec un minimum de surcoût (par exemple, le parsing massif des prix sur Wildberries ou Ozon), les proxies de centres de données sont mieux adaptés — ils sont plus rapides et plus prévisibles en termes de consommation de trafic pour des tâches similaires.
Comment réduire la consommation de trafic en pratique
Examinons des étapes concrètes qui réduisent la consommation réelle de trafic sans perte de fonctionnalité du parseur, d'automatisation ou de multi-comptes.
1. Désactivez le chargement des ressources inutiles. Si vous avez seulement besoin du texte de la page ou de la réponse JSON de l'API, désactivez le chargement des images, des polices, des scripts d'analyse et des trackers publicitaires dans les paramètres du navigateur anti-détection ou de l'outil headless. Cela réduit souvent la consommation de trafic de 60 à 80 % pour les tâches de parsing.
2. Utilisez Keep-Alive et un pool de connexions. Configurez le client HTTP pour réutiliser la session pour un groupe de requêtes vers un même hôte — cela réduit considérablement le nombre de poignées de main TLS.
3. Configurez une politique de retries raisonnable. Un délai exponentiel (1s → 2s → 4s) avec une limite de 3 tentatives au lieu de 5-10 tentatives agressives consécutives réduit le trafic inutile des requêtes échouées tout en diminuant le risque de blocage supplémentaire de l'IP.
4. Nettoyez les cookies et les en-têtes de session. Supprimez périodiquement les valeurs de cookie accumulées qui ne sont pas utilisées par le site cible — cela est particulièrement pertinent pour les longues sessions de réchauffement de comptes sur Instagram ou TikTok via des navigateurs anti-détection.
5. Mettez en cache les réponses statiques. Si les données (par exemple, le catalogue de produits) ne changent pas chaque minute, mettez en cache la réponse localement au lieu de faire une nouvelle requête via le proxy à chaque cycle de surveillance.
6. Utilisez la compression. Vérifiez que l'en-tête Accept-Encoding : gzip est transmis et que le serveur renvoie effectivement une réponse compressée — cela réduit le volume de trafic entrant sur les pages avec beaucoup de texte ou de JSON.
Outils pour surveiller le trafic
Pour comprendre où va réellement le trafic, il est utile de ne pas se fier uniquement au compteur du fournisseur, mais aussi à une répartition détaillée des requêtes. Pour cela, vous pouvez utiliser :
- Charles Proxy / Fiddler — montrent la taille de chaque requête et réponse, y compris les en-têtes, ce qui aide à trouver des cookies « lourds » ou des ressources superflues.
- Wireshark — pour une analyse approfondie du surcoût TCP/TLS au niveau des paquets, si vous devez évaluer le poids réel de la poignée de main.
- Compteurs de trafic intégrés dans les navigateurs anti-détection (Dolphin Anty, AdsPower, GoLogin) — beaucoup montrent la consommation par profil séparément, ce qui est pratique pour répartir le budget entre les comptes.
- Journalisation au niveau du client HTTP — lors de l'écriture de vos propres scripts de parsing, il est utile de journaliser la taille de la requête/réponse pour chaque appel afin de détecter des anomalies.
Comparer les lectures de vos outils avec le compteur du fournisseur de proxy aide à comprendre rapidement où le trafic est perdu — dans les retries, le TLS ou le chargement de ressources superflues.
Liste de contrôle d'optimisation avant le lancement
Avant de lancer massivement un parseur, une automatisation SMM ou un réchauffement de comptes publicitaires, passez en revue cette courte liste :
- Le chargement des images, des polices et de l'analyse est désactivé là où ce n'est pas nécessaire ;
- Keep-Alive / réutilisation de session est configuré pour une série de requêtes vers un même hôte ;
- La politique de retries est limitée à 2-3 tentatives avec un délai, et non à des répétitions infinies ;
- Les cookies de session sont périodiquement nettoyés des valeurs inutilisées ;
- La compression des réponses (gzip/deflate/br) est activée ;
- Il y a un cache local pour les requêtes statiques répétées ;
- Le type de proxy est choisi en fonction de la tâche : centre de données pour la vitesse et le volume, résidentiels pour contourner les blocages, mobiles pour les réseaux sociaux et les plateformes publicitaires.
Conclusion
La consommation de trafic via un proxy ne se limite pas aux données utiles de la page, mais inclut également tout le surcoût de service : en-têtes, poignées de main TLS, retries en cas d'erreurs. Comprendre cette mécanique permet de mieux planifier le budget pour les proxies et d'éviter les mauvaises surprises sur la facture, surtout lors de l'échelle du parsing des places de marché, de l'automatisation SMM ou du réchauffement des comptes publicitaires.
Si votre tâche consiste à effectuer un parsing stable avec une consommation de trafic prévisible, portez votre attention sur les proxies de centres de données. Pour travailler avec des réseaux sociaux et des plateformes publicitaires, où la faible fréquence de blocages est importante, les proxies mobiles sont plus appropriés. Et si vous avez besoin d'un équilibre entre anonymat et stabilité pour contourner la protection des sites — envisagez les proxies résidentiels, qui réduisent le nombre de retries grâce à des blocages moins fréquents.