Changement dynamique de proxy pour des contextes de navigateur séparés

Changer un proxy après qu'une session a accumulé cookies et pages ouvertes peut préserver un état utile, mais peut aussi confondre une ancienne requête avec une nouvelle route. Utilisez un proxy par contexte lorsque la tâche reste dans une région et réservez le changement à chaud à un travail autorisé qui peut vérifier la nouvelle sortie avant de continuer.

TL;DR

• Un contexte est la plus petite unité utile pour garder ensemble route et état de session stocké.
• BotBrowser.setBrowserContextProxy modifie un contexte existant ; les requêtes déjà en cours peuvent finir par l'ancienne route.
• Enregistrez puis comparez l'IP de sortie, le fuseau horaire, les paramètres régionaux et la langue de chaque contexte après chaque changement.

Contents

• Décidez quelle unité possède la route
• Attribuez un proxy à la création du contexte
• Changez le proxy d'un contexte actif
• Vérifiez chaque contexte séparément
• Limites à prévoir
• Conclusion pratique

Décidez quelle unité possède la route

Un navigateur a rarement besoin d'un seul chemin réseau pour tout ce qu'il fait. Une équipe qui teste un service régional, garde séparés plusieurs comptes autorisés ou compare une page depuis deux emplacements veut que chacune de ces tâches sorte par sa propre route. Un proxy unique appliqué au démarrage du navigateur est simple et prévisible, mais il lie toutes les pages à la même adresse de sortie tant que le navigateur reste ouvert. Le changement dynamique de proxy répond à cette limite, mais il n'est qu'une option parmi trois, et la première décision consiste donc à choisir quelle unité possède la route : toute l'instance du navigateur, un contexte du navigateur, ou un contexte dont la route change pendant qu'il reste ouvert. BotBrowser peut appliquer un proxy par contexte isolé afin que chaque tâche autorisée garde sa propre route ; il ne peut pas obliger un réseau ou un site à accepter cette route.

Un contexte de navigateur est une session isolée à l'intérieur d'une instance de navigateur. Il a ses propres cookies, son propre stockage local et son propre cache, et il est peu coûteux à créer et à jeter par rapport au démarrage d'un autre navigateur. Playwright décrit les contextes comme des profils de navigateur isolés, et Puppeteer expose la même idée avec sa propre API de contextes. Comme le contexte est déjà la frontière de l'état stocké, il est aussi une frontière naturelle pour une route réseau : un travail qui doit rester séparé ne devrait partager ni stockage ni adresse de sortie.

Le tableau compare les trois options. Le coût en mémoire et l'isolation de l'état sont les critères de choix habituels, et le niveau de licence détermine les options dont vous disposez.

Option	Quand la choisir	Coût et isolation	Prérequis documenté
Un proxy par contexte, fixé à la création	Chaque compte ou région garde une seule route pendant toute la vie de son contexte	Les contextes partagent une instance de navigateur, donc ils consomment moins de mémoire que des instances séparées, et chacun garde ses propres cookies et son stockage	Licence ENT Tier3 pour le proxy par contexte de BotBrowser
Changement à chaud d'un contexte existant	Un flux de travail passe d'une région à l'autre, ou une route doit être remplacée sans jeter le contexte ouvert	Le contexte conserve ses pages et son état stocké pendant que la route change	Licence ENT Tier3 et la commande BotBrowser.setBrowserContextProxy
Une instance de navigateur par proxy	Vous voulez la séparation la plus large, ou le routage par contexte ne fait pas partie de votre niveau	Chaque instance porte sa propre empreinte complète de navigateur et son propre répertoire de données utilisateur	Une valeur --proxy-server au lancement, décrite dans le guide de configuration du proxy

Trois questions suffisent en général pour trancher. Si la route doit changer pendant que le même contexte reste ouvert, utilisez le changement à chaud. Si chaque compte garde une seule route pendant toute sa vie, attribuez le proxy à la création du contexte, car une route qui ne change jamais est plus facile à relire et à expliquer plus tard. Si votre licence n'inclut pas le routage par contexte, ou si vous voulez la séparation la plus large, lancez une instance de navigateur par proxy et acceptez la mémoire supplémentaire.

La mémoire est le coût qui départage le plus souvent les contextes et les instances séparées, et elle dépend de ce que font les pages. Les onglets ouverts, les médias, les extensions et les téléchargements s'additionnent, si bien que le résultat d'une page vide en dit peu sur une tâche de production. Mesurez avec votre charge réelle et autorisée, fixez des limites prudentes et gardez de la marge pour les pics brefs au lieu de copier un chiffre de capacité issu d'une démonstration ou de la configuration d'une autre équipe.

Certaines équipes font tourner les routes par interception des requêtes dans le framework d'automatisation, ou avec un service de proxy local qui redirige vers différents proxys amont. Ces conceptions peuvent fonctionner, mais elles ajoutent des éléments à exécuter et à surveiller. La documentation de BotBrowser précise aussi que l'alignement du fuseau horaire dépend d'un proxy défini par --proxy-server ou du proxy par contexte, et non d'options de proxy propres au framework : gardez donc la route côté navigateur lorsque les signaux régionaux comptent pour votre tâche. Un service de proxy local est aussi un service localhost, et Protection contre le sondage des ports locaux par le navigateur explique comment un navigateur peut sonder des ports locaux.

Attribuez un proxy à la création du contexte

La méthode documentée par BotBrowser pour donner à un contexte sa propre route consiste à fournir le proxy à la création du contexte. Dans Puppeteer, c'est l'option proxyServer de createBrowserContext, avec les identifiants intégrés à l'URL du proxy. Un contexte créé sans proxy propre hérite de la route de proxy et de l'identité géographique du profil de lancement, donc tout contexte qui ne doit pas utiliser la route du navigateur a besoin de son propre proxy.

const client = await browser.target().createCDPSession();

const ctx = await browser.createBrowserContext({
  proxyServer: 'socks5://user:[email protected]:1080',
});

await client.send('BotBrowser.setBrowserContextFlags', {
  browserContextId: ctx._contextId,
  botbrowserFlags: ['--bot-profile=path/to/profile.enc', '--proxy-ip=203.0.113.1'],
});

const page = await ctx.newPage();

Après la création, BotBrowser détecte l'adresse IP de sortie du proxy de ce contexte et en déduit le fuseau horaire, les paramètres régionaux et la langue du contexte. Si vous connaissez déjà l'IP de sortie, indiquez-la avec --proxy-ip et la recherche est ignorée. Lorsqu'un contexte a sa propre route et que vous déclarez aussi l'IP de sortie, fournissez les deux à la création : la documentation avertit qu'appliquer --proxy-ip seulement après la création peut laisser la résolution géographique démarrer avant que la déclaration d'adresse soit disponible. Envoyez la mise à jour des flags avant la création de la première page du contexte, comme dans l'exemple ci-dessus.

Les réglages laissés sur auto suivent le proxy du contexte, tandis que les valeurs explicites sont résolues indépendamment pour chaque contexte et chaque réglage. C'est utile lorsqu'une équipe fixe volontairement une valeur, comme une langue d'interface exigée par un plan de test, et laisse les autres suivre la route. Traitez chaque valeur fixée comme une décision qui a un responsable. Un ancien remplacement continue de sembler valide après le changement de route, et on oublie facilement qu'il a été défini.

Playwright documente sa propre option proxy pour les nouveaux contextes, et c'est la bonne référence pour ce que cette option fait dans Playwright. La documentation de BotBrowser sur le proxy par contexte est écrite autour de l'option de création de contexte et des flags présentés ci-dessus : confirmez donc les valeurs régionales sur votre propre page de test avant de vous appuyer sur l'alignement automatique dans une configuration Playwright. La page Playwright indiquée dans les sources fait foi pour le comportement du framework.

Les identifiants méritent le même soin que la route. La commande documentée et l'option de création acceptent l'URL du proxy avec identifiants intégrés : gardez-les à cet endroit au lieu de les remplacer par un appel séparé à page.authenticate(). Récupérez-les depuis votre gestionnaire de secrets au démarrage de la tâche, gardez-les hors des fichiers source, des tickets et des journaux d'exécution, et renouvelez-les par l'intermédiaire de leur responsable. L'article sur l'authentification du proxy et l'hygiène des identifiants détaille ce processus.

Fermer un contexte supprime ses cookies, son stockage local et son cache, et le contexte suivant démarre vierge. C'est le comportement souhaité lorsque chaque tâche doit partir de zéro, et un problème lorsque la session d'un compte doit survivre au contexte. Si une session doit continuer, décidez avant la fermeture ce que vous exportez, où cela est stocké et qui peut le lire. Le guide du proxy par contexte explique comment garder ensemble un objectif, un contexte et une route.

Un court registre des routes permet de relire ces attributions. Pour chaque contexte, notez une étiquette lisible de la route, la tâche qu'elle sert, son responsable, la région prévue lorsqu'elle compte et la référence du secret qui contient ses identifiants. Utilisez une étiquette qui décrit l'objectif au lieu de copier un nom d'hôte dans de nombreuses tâches, afin que le fournisseur puisse renouveler un point d'accès sans que chaque modèle change. Lorsque l'objectif change, créez une nouvelle attribution plutôt que de réutiliser silencieusement une ancienne étiquette, car les revues qui s'appuient sur l'étiquette cessent alors d'être fiables.

Changez le proxy d'un contexte actif

Le changement à chaud existe pour les flux de travail dans lesquels le même contexte a besoin d'une autre route plus tard. Avec une licence ENT Tier3, BotBrowser documente la commande CDP BotBrowser.setBrowserContextProxy, qui modifie le proxy d'un contexte de navigateur existant. La commande prend le browserContextId et une URL proxyServer avec identifiants intégrés, et éventuellement proxyIp, proxyBypassList et proxyBypassRgx.

const client = await browser.target().createCDPSession();

await client.send('BotBrowser.setBrowserContextProxy', {
  browserContextId: ctx._contextId,
  proxyServer: 'socks5://user:[email protected]:1080',
  proxyIp: '198.51.100.1',
});

await page.goto(nextUrl);

La commande doit être envoyée sur une session de niveau navigateur. Dans Puppeteer, c'est browser.target().createCDPSession(), et dans Playwright, browser.newBrowserCDPSession(). Une session de niveau page n'expose pas le domaine BotBrowser, et une erreur « commande introuvable » est le symptôme habituel d'une mauvaise session. La même erreur peut apparaître lorsque la licence n'inclut pas la fonctionnalité.

Lorsque vous appelez la commande, BotBrowser met à jour la configuration de proxy de ce contexte, détecte de nouveau l'IP de sortie sauf si vous avez fourni proxyIp, et reconfigure le fuseau horaire, les paramètres régionaux et la langue pour correspondre au nouvel emplacement. La commande se termine une fois l'état géographique mis à jour appliqué, et les requêtes suivantes de ce contexte utilisent le nouveau proxy. Attendez donc la fin de la commande (await) avant de lancer toute navigation qui dépend du nouvel emplacement. Gardez en séquence les changements de proxy, les mises à jour de flags et la suppression du proxy pour un même contexte, et attendez que chaque commande se termine avant d'envoyer la suivante.

Préparez le transfert lui-même. Les pages déjà chargées continuent de fonctionner, et les requêtes en cours au moment du changement se terminent sur l'ancien proxy. Seules les nouvelles requêtes utilisent le nouveau, de sorte que le changement n'est ni instantané ni exempt de chevauchement. En pratique, laissez la navigation en attente se terminer et mettez en pause les minuteries ou l'interrogation périodique de la page avant de changer, puis naviguez de nouveau une fois la commande terminée. Une page restée ouverte pendant le changement ne doit pas être considérée comme provenant de la nouvelle route.

Fournir proxyIp supprime la recherche ponctuelle qui précède la première navigation après un changement. Utilisez-le lorsque vous avez déjà l'adresse de sortie auprès de votre fournisseur, et vérifiez qu'il s'agit bien de l'adresse de sortie réelle de ce proxy, car les réglages géographiques sont déduits de la valeur que vous donnez. Pour un proxy qui n'a une adresse que dans une seule famille, la documentation autorise ipv4_none ou ipv6_none afin de déclarer la famille absente. Sans proxyIp, attendez-vous à ce que le premier chargement après un changement soit un peu plus long, ce qui est normal et n'est pas en soi un échec.

La commande BotBrowser.clearBrowserContextProxy supprime le remplacement et ramène le contexte au proxy du navigateur, ou à une connexion directe lorsqu'aucun n'est configuré. Une connexion directe peut être exactement ce que vous ne voulez pas : vérifiez donc ce que fournit la configuration de lancement avant de l'utiliser. Un flux de travail qui ne doit jamais sortir sans proxy doit passer à un autre proxy approuvé plutôt que d'effacer.

L'option proxyBypassList prend une liste d'hôtes séparés par des points-virgules qui se connectent directement, et proxyBypassRgx prend un motif RE2 pour les URL qui doivent faire de même. Ces requêtes n'utilisent pas du tout le proxy. Gardez la liste courte, consignez-la dans l'attribution de la route et testez un hôte qui doit se connecter directement et un hôte qui ne le doit pas.

Les équipes qui veulent une sortie différente pour chaque tâche peuvent créer un nouveau contexte à chaque rotation ou changer un même contexte d'une tâche à l'autre. Un nouveau contexte démarre sans cookies ni cache, donc rien n'est reporté. Un contexte modifié conserve son état stocké, ce qui signifie que la session ouverte d'un compte se poursuit depuis une nouvelle adresse. Que cela soit acceptable relève du responsable du compte, et un site peut traiter ce changement autrement que prévu. L'article sur la bascule de proxy et la continuité visible par l'utilisateur décrit ce que les personnes perçoivent lorsqu'une route change au milieu d'une session.

Vérifiez chaque contexte séparément

La vérification vise à voir, pour chaque contexte, sa propre adresse de sortie et les valeurs régionales attendues. Effectuez le contrôle séparément pour chaque contexte après sa création, puis après chaque changement. Ne généralisez pas d'un contexte à un autre, car chaque contexte a sa propre route et ses propres réglages géographiques.

Pour l'adresse, ouvrez une page sur un service que vous contrôlez, ou que votre organisation approuve, qui indique l'adresse source d'une requête, et comparez-la avec l'adresse de sortie que votre fournisseur indique pour ce proxy. Une correspondance montre que le trafic est sorti par la route prévue. Une adresse différente signifie que le réglage de proxy n'a pas été appliqué à ce contexte. Si vous avez configuré des règles de connexion directe, vérifiez un hôte qui doit se connecter directement et un hôte qui ne le doit pas.

Pour le fuseau horaire, les paramètres régionaux et la langue, faites afficher par une page de test que vous contrôlez les valeurs signalées par le navigateur, et comparez-les avec la région de l'adresse de sortie. Pour un contexte avec un remplacement explicite, comparez avec ce remplacement. L'article sur le fuseau horaire, les paramètres régionaux et la langue explique comment ces valeurs sont liées et pourquoi un décalage est plus instructif qu'une valeur isolée.

Après un changement, attendez la fin de la commande, puis ouvrez une nouvelle page ou rechargez la page existante avant de contrôler de nouveau. Considérez comme périmées les pages chargées avant le changement. Confirmez ensuite l'autre sens : les contextes que vous n'avez pas modifiés doivent toujours afficher leur adresse d'origine. Ce contrôle prouve que le changement sur un contexte n'a pas modifié la route d'un autre.

Gardez les preuves limitées. Un court enregistrement avec l'étiquette de la route, l'objectif du contexte, l'adresse de sortie observée, les valeurs régionales, le résultat et l'heure suffit. Ne conservez ni contenu de pages, ni données de compte, ni identifiants pour prouver qu'une route a été appliquée.

Employez un ordre stable : contextId, routeLabel, observedIp, timezone, locale, language et checkedAt. Deux relevés restent ainsi comparables après BotBrowser.setBrowserContextProxy sans enregistrer l'URL du proxy ni ses identifiants.

Lorsqu'un contrôle échoue, parcourez les causes dans l'ordre. Confirmez que la commande a été envoyée sur une session de niveau navigateur et que votre licence inclut la fonctionnalité. Confirmez que le proxy accepte une connexion depuis un outil simple en dehors du navigateur, ce qui distingue un problème de fournisseur d'un problème de configuration. Vérifiez si un remplacement explicite du fuseau horaire, des paramètres régionaux ou de la langue est défini pour ce contexte, puisque les remplacements ont priorité sur les valeurs déduites de la route. Vérifiez que la valeur proxyIp que vous avez fournie est l'adresse de sortie réelle de ce proxy. Ne changez qu'un élément à la fois et répétez le contrôle après chaque modification.

Limites à prévoir

Un changement de proxy modifie le chemin réseau d'un contexte et rien d'autre. La qualité de ce chemin dépend du fournisseur de proxy : la réputation de l'adresse de sortie, sa vitesse et sa stabilité, ainsi que la précision de l'enregistrement de son emplacement. Passer à un mauvais proxy donne au contexte une mauvaise route : mesurez donc le fournisseur avec vos propres tests avant de bâtir un flux de travail dessus.

Une adresse de sortie partagée est un signal de liaison parmi d'autres. Des adresses distinctes réduisent un type de lien entre des comptes, mais elles ne contrôlent pas la façon dont un site relie des identités par les données de compte, les informations de paiement, le comportement, les valeurs liées à l'appareil ou les personnes qui les exploitent. Rien ici ne garantit qu'un site accepte, ignore ou cesse de corréler vos contextes. Utilisez le routage par contexte pour un travail autorisé, comme vos propres comptes, des contrôles de qualité régionaux et la recherche sur la vie privée, et respectez les conditions de chaque service.

Décidez à l'avance de ce qui se passe lorsqu'un changement échoue. Un point d'accès du fournisseur peut être indisponible et une commande à chaud peut être refusée. Pour un flux de travail qui exige une route précise, arrêtez la tâche et consignez l'échec plutôt que de continuer sur l'ancienne route, sauf si le responsable a approuvé cette solution de repli par écrit.

BotBrowser prend en charge les proxys par contexte et, avec une licence ENT Tier3, la commande CDP BotBrowser.setBrowserContextProxy, qui modifie à chaud le proxy d'un contexte de navigateur existant et détecte de nouveau l'IP de sortie pour mettre à jour le fuseau horaire, les paramètres régionaux et la langue de ce contexte. Cela aide lorsqu'un flux de travail doit passer d'une région à l'autre, ou lorsqu'une route doit être remplacée sans jeter le contexte ouvert. BotBrowser ne peut pas fournir ni évaluer des proxys, améliorer la réputation d'IP ou la vitesse d'un proxy, détourner de l'ancien proxy les requêtes déjà en cours, ni garantir la façon dont un site corrèle ou accepte des identités au-delà du chemin réseau.

Conclusion pratique

Donnez à chaque travail autorisé un contexte nommé et une attribution de route. Lors d'un changement à chaud, attendez BotBrowser.setBrowserContextProxy, chargez une nouvelle page, comparez observedIp et les valeurs régionales à la route attendue, puis arrêtez le travail s'ils divergent. N'utilisez pas les pages ouvertes avant le changement pour cette comparaison, car leurs requêtes peuvent avoir fini auparavant.

Sources publiques

• Documentation BotBrowser sur le changement dynamique de proxy
• Documentation BotBrowser sur le proxy par contexte
• Documentation BotBrowser sur le proxy et la géolocalisation
• Documentation réseau de Playwright : proxy HTTP
• Documentation Playwright sur les contextes de navigateur