Proxies pour ZennoPoster et BAS en 2026 : flux, rotation et suivi du trafic

ZennoPoster et BAS (Browser Automation Studio) sont deux constructeurs de bots populaires dans la communauté russophone : ils sont utilisés pour les enregistrements, le réchauffement, le posting et le parsing. Dans les deux cas, le proxy est le principal consommable, et les erreurs surviennent souvent non pas dans le format de la chaîne, mais dans le schéma : deux flux se connectent à une seule IP, l'adresse change au milieu de l'enregistrement, et le modèle de navigateur télécharge des dizaines de gigaoctets d'images pendant la nuit. D'ici l'automne 2026, il est devenu plus facile de contrôler cela : ZennoPoster 7.9.1 du 11 août a appris à compter le trafic par proxy directement depuis le projet, tandis que ZennoPoster 7.9.2 (17 septembre) et BAS 30.8.0 (16 septembre) ont mis à jour les navigateurs vers Chromium 152 et 153. Ci-dessous se trouve un schéma de travail « un flux - une IP » pour les deux programmes, le choix de la rotation selon la tâche et le calcul du trafic avant que la facture ne soit reçue.

Qu'est-ce qui a changé en 2026 et pourquoi est-ce important pour les proxies

Si les modèles fonctionnent sur les versions du début de l'année, une partie des problèmes de proxy peut être résolue par une simple mise à jour. Dans les journaux de modifications de ZennoLab et Bablosoft, cinq points sont importants pour le travail avec les proxies :

• ZennoPoster 7.9.0 (25 juin). Le bloc « Traitement d'image → Enregistrement d'image → URL » a appris à fonctionner via un proxy. Avant cela, le bloc allait chercher l'image sans proxy, avec l'IP de la machine sur laquelle le modèle fonctionne, ce qui constitue une fuite silencieuse, facilement négligée.
• ZennoPoster 7.9.1 (11 août). La prise en compte du trafic entrant et sortant en octets par proxy a été introduite : pour les navigateurs Chromium et ChromiumFromZB (y compris WebSocket, sans réponses du cache) et pour tous les blocs HTTP — ordinaires, alternatifs et TLS. Les données sont accessibles via l'objet ZennoPoster.ProxyTrafficInfo.
• Dans la même version, l'émulation des données géographiques et du fuseau horaire a commencé à prendre en compte les adresses IPv6, et les profils ZennoBrowser avec des proxies SOCKS5 en intégration ne se sont plus arrêtés en raison d'un timeout au démarrage.
• ZennoPoster 7.9.2 (17 septembre). API HTTP publique pour plus de 100 opérations, trois serveurs MCP pour assistants IA et mode agent du bloc « IA Agent », qui gère lui-même le navigateur de la tâche. Moteur — Chromium 152.
• BAS 30.8.0 (16 septembre). Le moteur a été mis à jour vers la version 153, et un mode Agent a été introduit, qui crée, modifie et teste des scripts selon une description textuelle, ainsi qu'un module de génération de codes d'authentification à deux facteurs.

Conclusion pratique : avant de mettre à l'échelle les modèles, mettez à jour au moins vers ZennoPoster 7.9.1 et BAS 30.8.0. La prise en compte du trafic par proxy est exactement ce qui manquait lors du paiement pour des gigaoctets.

Étape 1. Choisissez le mode de rotation selon la tâche

Réponse courte : pour travailler avec des comptes, une session collante avec un port séparé pour chaque flux est nécessaire ; pour le parsing avec des requêtes HTTP — une nouvelle IP pour chaque requête ; pour le parsing de navigateur sans connexion au compte — une session collante avec un court intervalle.

Dans ProxyCove, le mode est défini par le port. Le port 824 change l'IP à chaque requête. Les ports 10000–20000 fonctionnent avec une rotation par intervalle : chaque port fournit sa propre IP et la maintient pendant un temps défini — de 1 à 120 minutes. L'intervalle peut être modifié dans les paramètres de rotation dans la fiche proxy.

• Enregistrement, réchauffement, posting. Le compte a besoin d'une adresse stable pendant tout le cycle. Réglez l'intervalle avec une marge par rapport à la durée d'un passage : si l'enregistrement avec confirmation par e-mail prend 20 à 25 minutes, choisissez 40 à 60. Changer d'IP au milieu d'un formulaire est une cause typique de checkpoints.
• Collecte de données avec des blocs GET/POST. Chaque requête est autonome, il n'est pas nécessaire de maintenir une session. Le port 824 répartit la charge sur le pool et réduit le risque de rencontrer des limites sur une seule IP.
• Parsing de navigateur sans connexion. Ici, la rotation à chaque requête est nuisible. Selon les données de Web Almanac 2025, la page médiane sur desktop effectue 77 requêtes vers différentes ressources, et sur le port 824, des parties d'une même page partiront de différentes adresses. Pour les systèmes anti-bots, cela constitue un comportement atypique, donc choisissez un port collant avec un intervalle de 1 à 5 minutes et changez d'IP entre les pages, et non à l'intérieur d'elles.

Étape 2. Choisissez le type de proxy

Le type détermine non seulement le prix du gigaoctet, mais aussi la façon dont la plateforme considère l'adresse :

• Résidentiels — IP des fournisseurs d'accès domestiques. Choix de base pour les modèles de navigateur, les places de marché, le scraping SEO et les enregistrements sur des sites de moyenne rigueur. Dans ProxyCove, les proxies résidentiels avec choix de pays et d'intervalle de rotation coûtent 2,70 $ par Go.
• Mobiles — adresses des opérateurs de télécommunications. Avec une telle IP via CGNAT, de nombreux abonnés réels accèdent simultanément à Internet, donc les réseaux sociaux les bloquent plus prudemment. C'est le choix pour les comptes sur les réseaux sociaux et les plateformes strictes : les proxies mobiles coûtent 3,80 $ par Go.
• Datacenter — 1,50 $ par Go, rapides et bon marché, mais leurs sous-réseaux sont bien connus des systèmes anti-bots. Convient pour le parsing HTTP de sites loyaux et d'API, mais c'est un mauvais choix pour les comptes sur les réseaux sociaux.

Si la plateforme attache de l'importance à une géographie stable, et non à une adresse spécifique, activez le ciblage par ville ou opérateur (ASN). L'IP changera, mais dans les limites d'une même ville ou d'un même réseau, comme un utilisateur ordinaire. Le ciblage est plus cher : pour les résidentiels — 4,70 $ par Go.

Étape 3. Préparez la liste « un port — un flux »

1. Ouvrez la fiche proxy dans le cabinet ProxyCove et activez la rotation par intervalle.
2. Dans le champ « Nombre de flux », indiquez combien de lignes sont nécessaires. Les ports ne sont pas facturés séparément — vous ne payez que pour le trafic, donc prenez une liste 2 à 3 fois plus longue que le nombre de flux. Pourquoi — nous l'expliquerons ci-dessous.
3. Choisissez le format http ou socks5. Le cabinet générera des lignes avec les ports 10000, 10001, 10002, etc. : chaque ligne est une session distincte avec sa propre IP.
4. Enregistrez la liste dans un fichier, par exemple proxies.txt. La ligne ressemble à ceci : socks5://login:[email protected]:10000.

Si le ciblage est activé, les paramètres de pays, de ville ou d'ASN sont ajoutés au login par un point-virgule. Copiez la ligne dans son intégralité et ne la modifiez pas manuellement : une erreur dans les paramètres cassera l'autorisation ou le ciblage.

Étape 4. ZennoPoster : un proxy pour chaque flux

Dans ZennoPoster, le proxy peut être défini globalement, pour le projet ou pour le flux. Pour un travail multi-flux, il est plus fiable de prendre une ligne de la liste à l'intérieur du modèle :

1. Ajoutez dans ProjectMaker le bloc « Liste », activez « Charger depuis un fichier » et « Enregistrer les modifications de la liste dans un fichier », puis indiquez le chemin vers proxies.txt.
2. Ajoutez « Opération sur la liste » : « Obtenir une ligne » → « Première » avec la case « Supprimer la ligne après obtention » cochée. Placez le résultat dans une variable, par exemple proxy. La suppression garantit que deux flux parallèles ne prendront pas le même port.
3. Ajoutez « Navigateur → Paramètres → Définir le proxy » et transmettez {-Variable.proxy-}. Activez l'émulation de la localisation et du fuseau horaire : le navigateur obtiendra des données géographiques et un fuseau horaire via l'IP du proxy.
4. Dans chaque bloc HTTP (GET, POST), indiquez le même proxy — via une variable ou l'option proxy du projet. Un champ proxy vide dans le bloc signifie une requête avec l'IP du serveur.
5. À la fin du passage — tant dans le chemin réussi que dans le chemin d'erreur — renvoyez la ligne à la fin de la liste. Sinon, la liste se videra progressivement, et chaque flux échoué « mangera » le port pour toujours.

Le ProxyChecker intégré est pratique pour les listes publiques, mais pour une passerelle avec paiement au trafic, vérifier régulièrement toute la liste est inutile : chaque vérification consomme des mégaoctets payés, et sur le port 824, la prochaine requête partira de toute façon avec une autre IP. Avant un grand lancement, il suffit de vérifier quelques lignes.

Étape 5. BAS : ressource avec proxy et action Proxy

1. Créez une ressource de type « Fichier » ou « URL » avec la liste des proxies — c'est exactement ce que recommande la documentation de Bablosoft, afin que l'utilisateur du modèle choisisse lui-même la source.
2. Dans les paramètres de la ressource, limitez l'utilisation simultanée de la ligne à un seul flux. C'est là que sont définis les limites d'utilisations réussies et échouées et l'intervalle entre les utilisations — pour les ports collants, définissez-le pas plus court que l'intervalle de rotation.
3. Comme première action du flux, avant de charger n'importe quelle page, placez « Proxy » et transmettez la ligne de la ressource. BAS comprend de nombreux formats, y compris login:password@host:port et socks5://login:password@host:port, fonctionne avec HTTP et SOCKS5 avec autorisation et envoie des requêtes DNS via le proxy.
4. Activez dans l'action le changement de géolocalisation et de fuseau horaire selon l'IP du proxy.
5. Si le modèle accède au site également en tant que client HTTP, définissez le proxy pour lui aussi : le client HTTP de BAS a ses propres paramètres, distincts de ceux du navigateur.

Deux particularités de BAS doivent être prises en compte. Le proxy change sans redémarrer le flux, par une action répétée « Proxy », — c'est pratique pour changer d'IP en cas d'erreur. Et si le proxy ne répond plus, BAS redémarre le flux et prend le suivant. Pour le parsing, c'est un avantage, mais pour les comptes, c'est un risque : le travail continuera avec une autre IP. Conservez l'association « compte — port » et renvoyez le compte à son port.

Étape 6. Calculez le trafic avant le lancement

Lors du paiement par gigaoctet, le modèle de navigateur est la partie la plus coûteuse du schéma. Selon les données de Web Almanac 2025, la page principale médiane pèse 2862 Ko sur desktop, dont 1058 Ko sont des images. 10 000 chargements de telles pages représentent environ 28,6 Go, ce qui coûte environ 77 $ pour des proxies résidentiels. Sans images, cela représente environ 18 Go et 49 $. Les chiffres réels dépendent du site et du cache, mais l'ordre de grandeur est clair : les images représentent plus d'un tiers de la facture.

• BAS. Les actions « Request mask deny » et « Request mask allow » sont placées avant le chargement de la page et acceptent des masques avec des astérisques. Dans la documentation de Bablosoft, un exemple : interdire *.png, *.jpg et *.gif, puis autoriser l'image du captcha pour qu'elle soit la seule à se charger.
• ZennoPoster. La plus grande économie consiste à transférer la collecte de données du navigateur vers des blocs GET/POST : ils ne tirent pas les images, les polices et les scripts. Dans la fenêtre « Trafic », vous pouvez voir quelles requêtes pèsent le plus, et depuis la version 7.9.1, le volume par proxy peut être lu dans le code via ZennoPoster.ProxyTrafficInfo, écrit dans le log et arrête le flux en cas de dépassement du seuil.
• Attention aux réseaux sociaux. Une page sans images pour un utilisateur vivant est rare, et sur certaines plateformes, cela semble atypique en soi. Pour les comptes, il est préférable de se limiter à bloquer les vidéos lourdes et les médias, tout en laissant les images.

Vérifiez votre compte avec le cabinet : vous pouvez y voir le solde et le graphique de consommation pour chaque proxy. Les données du fournisseur sont mises à jour avec un délai, donc le contrôle opérationnel est plus pratique à maintenir dans le modèle lui-même.

Pièges

• Fuites de l'IP réelle. Bloc HTTP sans proxy, enregistrement d'images par URL dans ZennoPoster jusqu'à 7.9.0, WebRTC. Comme première étape du modèle, ouvrez une page de vérification de l'IP et de WebRTC et comparez le résultat avec l'adresse du proxy — c'est moins cher que de gérer un ban.
• Changement d'IP au milieu d'une session. Si l'intervalle de rotation est plus court que le cycle du compte, la plateforme voit un saut d'adresse entre les étapes d'un même formulaire. L'intervalle maximum dans ProxyCove est de 120 minutes ; divisez les scénarios longs en courtes sessions tout en conservant le profil.
• Une IP pour deux comptes. Tant que l'intervalle de rotation n'est pas écoulé, le port renvoie l'ancienne adresse. Si le port est immédiatement attribué au compte suivant, celui-ci accède à Internet avec l'IP de l'ancien. D'où le conseil d'avoir une longue liste : avec 30 flux et 90 ports, chaque port a le temps de « refroidir » avant une nouvelle utilisation.
• Disparité géo. Le fuseau horaire et la géolocalisation du navigateur doivent correspondre au pays de l'IP. Si le proxy est « allemand » mais que le site affiche les Pays-Bas, cela est généralement dû aux bases de données de géolocalisation, et non au proxy — voici comment fonctionne la géolocalisation IP et pourquoi les bases divergent.
• Empreinte du moteur. Les nouvelles versions de Chromium apportent de nouveaux signaux. Dans Chrome 152, une propriété navigator.cpuPerformance est apparue — la classe du processeur, qui dépend principalement du nombre de cœurs, et ZennoPoster 7.9.2 et BAS 30.8.0 fonctionnent sur Chromium 152 et 153. Si les modèles tournent sur VPS avec deux cœurs, tandis que les profils affichent des ordinateurs de bureau puissants, vérifiez ce que renvoie cette propriété : analyse du nouveau signal de détection dans Chrome 152.
• Agents IA et trafic. Le mode agent du bloc « IA Agent » dans ZennoPoster 7.9.2 gère le navigateur de la tâche, ce qui signifie qu'il accède à Internet via son proxy. Son cycle est limité par un quota d'itérations obligatoire — ne définissez pas de quota avec une grande marge : chaque itération supplémentaire coûte à la fois des tokens et des mégaoctets.

Conclusion

Le schéma pour les deux programmes est le même : un port collant séparé pour chaque flux, un intervalle de rotation plus long que le cycle du compte, une pause avant une nouvelle utilisation du port, une géolocalisation et un fuseau horaire selon l'IP, un proxy dans toutes les requêtes HTTP et une prise en compte du trafic dès le premier jour. Commencez avec un flux : vérifiez l'IP, WebRTC et le fuseau horaire, exécutez une centaine de cycles et observez la consommation dans ZennoPoster.ProxyTrafficInfo ou dans le cabinet. Après cela, il est plus sûr et moins cher d'étendre le modèle à des dizaines et des centaines de flux. Pour les scénarios de navigateur avec des comptes, choisissez des proxies résidentiels ou mobiles avec rotation par intervalle, pour le parsing HTTP — un port avec une nouvelle IP pour chaque requête.