Basculement dynamique de proxy : config par contexte

Introduction

De nombreux workflows de confidentialité nécessitent plus qu'un seul proxy pour toute une session de navigateur. Vous pouvez avoir besoin de proxies différents pour différents comptes, régions géographiques ou domaines cibles. La configuration proxy statique, où un seul proxy sert tout le trafic pendant la durée de vie du navigateur, est limitante dans ces scénarios.

BotBrowser prend en charge le basculement dynamique de proxy via les API de contexte de Playwright et Puppeteer. Chaque contexte de navigateur peut acheminer le trafic via un proxy différent avec sa propre identité géographique, et vous pouvez créer et fermer des contextes à l'exécution sans redémarrer le navigateur. Cet article couvre la configuration de proxy par contexte, les stratégies de rotation de proxy et les configurations multi-proxy pour les workflows complexes.

Impact sur la vie privée

Lorsque plusieurs comptes ou identités partagent un seul proxy, leurs schémas de trafic sont liés par l'adresse IP. Un système de suivi qui observe la même IP accédant à plusieurs comptes à des moments similaires peut corréler ces comptes. Même si les profils d'empreinte sont différents, l'identité réseau partagée crée une connexion.

L'attribution de proxy par contexte résout ce problème. Chaque contexte s'achemine via un proxy distinct, donc le trafic de différentes identités ne partage jamais une IP. Combiné avec l'isolation d'empreinte par contexte de BotBrowser, chaque contexte présente une identité complètement indépendante : empreinte différente, IP différente, métadonnées géographiques différentes.

Le basculement dynamique de proxy est également important pour les workflows qui couvrent plusieurs régions. Une identité qui doit apparaître aux États-Unis pour une tâche et en Allemagne pour une autre peut changer de proxy entre les tâches, avec BotBrowser qui ajuste automatiquement le fuseau horaire, la locale et la langue pour correspondre.

Contexte technique

Contextes de navigateur et isolation réseau

Un contexte de navigateur dans Playwright ou Puppeteer est une session de navigation isolée au sein d'une seule instance de navigateur. Chaque contexte a ses propres cookies, localStorage, sessionStorage et cache. Playwright étend cette isolation à la configuration réseau : chaque contexte peut avoir ses propres paramètres de proxy.

Lorsque vous créez un contexte avec browser.newContext({ proxy: ... }), tout le trafic de ce contexte s'achemine via le proxy spécifié. Les autres contextes dans la même instance de navigateur ne sont pas affectés. C'est une véritable isolation réseau au niveau du contexte.

Configuration proxy statique vs. par contexte

La configuration statique définit un proxy au lancement du navigateur avec --proxy-server. Tous les contextes dans cette instance de navigateur partagent le même proxy :

chrome --bot-profile="/path/to/profile.enc" \
       --proxy-server=socks5://user:pass@proxy:1080

La configuration par contexte définit des proxies lors de la création de contextes individuels :

const context = await browser.newContext({
  proxy: { server: 'socks5://proxy:1080', username: 'user', password: 'pass' },
});

Les proxies par contexte remplacent le proxy au niveau du navigateur pour ce contexte spécifique. Si aucun proxy au niveau du contexte n'est spécifié, le contexte hérite du proxy au niveau du navigateur.

Comment BotBrowser étend les proxies de contexte

Le Chromium standard prend en charge les proxies par contexte via l'API de Playwright, mais il ne dérive pas automatiquement les paramètres géographiques par contexte. BotBrowser étend ce comportement : lorsqu'un proxy par contexte est configuré, BotBrowser dérive automatiquement le fuseau horaire, la locale et la langue à partir de l'IP du proxy pour ce contexte spécifique.

Cela signifie que chaque contexte obtient une identité géographique complète sans configuration manuelle de chaque paramètre.

Approches courantes et leurs limitations

Lancement d'instances de navigateur séparées

L'approche la plus simple pour les configurations multi-proxy est de lancer une instance de navigateur séparée par proxy :

# Instance 1
chrome --bot-profile="/profiles/profile-a.enc" \
       --proxy-server=socks5://proxy-us:1080 \
       --user-data-dir="/tmp/session-1"

# Instance 2
chrome --bot-profile="/profiles/profile-b.enc" \
       --proxy-server=socks5://proxy-de:1080 \
       --user-data-dir="/tmp/session-2"

Cela fonctionne mais consomme plus de mémoire et de CPU. Chaque instance de navigateur a ses propres processus de rendu, processus GPU et processus utilitaires. Exécuter 10 instances utilise significativement plus de ressources qu'exécuter 10 contextes au sein d'une seule instance.

Rotation de proxy au niveau du framework

Certains frameworks fournissent la rotation de proxy via page.route() ou des API d'intercepteur. Ces approches modifient le trafic au niveau JavaScript/CDP, ce qui signifie :

• La connexion initiale peut utiliser le mauvais proxy avant que l'intercepteur ne s'active
• Les connexions WebSocket peuvent ne pas être couvertes
• Le préchargement DNS peut fuiter via le chemin proxy original

Les proxies par contexte configurés au niveau du moteur du navigateur n'ont pas ces problèmes de timing.

Serveurs proxy middleware

Exécuter un proxy middleware local qui gère la rotation ajoute de la complexité d'infrastructure et un point de défaillance unique. Le navigateur se connecte au middleware local, qui transmet aux différents proxies en amont. Cela fonctionne mais introduit de la latence et nécessite de maintenir un logiciel supplémentaire.

L'approche de BotBrowser

Proxy par contexte avec auto-détection

Le support de proxy par contexte de BotBrowser (ENT Tier1) fournit une identité géographique complète par contexte :

const { chromium } = require('playwright-core');

const browser = await chromium.launch({
  executablePath: '/path/to/botbrowser/chrome',
  args: [
    '--bot-profile=/path/to/profile.enc',
  ],
  headless: true,
});

// Contexte US - BotBrowser dérive automatiquement les paramètres géographiques US
const usContext = await browser.newContext({
  proxy: { server: 'socks5://us-proxy:1080', username: 'user', password: 'pass' },
});

// Contexte Allemagne - BotBrowser dérive automatiquement les paramètres géographiques allemands
const deContext = await browser.newContext({
  proxy: { server: 'socks5://de-proxy:1080', username: 'user', password: 'pass' },
});

Chaque contexte reçoit automatiquement des paramètres de fuseau horaire, de locale et de langue correspondant à la localisation géographique de son proxy.

Remplacements géographiques manuels par contexte

Lorsque vous avez besoin de paramètres géographiques spécifiques pour un contexte, combinez le proxy avec les options de locale et de fuseau horaire de Playwright :

async function createGeoContext(browser, config) {
  return browser.newContext({
    proxy: {
      server: config.proxyUrl,
      username: config.user,
      password: config.pass,
    },
    locale: config.locale,
    timezoneId: config.timezone,
  });
}

const usCtx = await createGeoContext(browser, {
  proxyUrl: 'socks5://us-east:1080',
  user: 'u', pass: 'p',
  locale: 'en-US',
  timezone: 'America/New_York',
});

const jpCtx = await createGeoContext(browser, {
  proxyUrl: 'socks5://jp-tokyo:1080',
  user: 'u', pass: 'p',
  locale: 'ja-JP',
  timezone: 'Asia/Tokyo',
});

Rotation de proxy entre les requêtes

Pour les workflows nécessitant une diversité d'IP entre les navigations, créez un nouveau contexte par rotation :

const proxyPool = [
  { server: 'socks5://proxy-1:1080', username: 'user', password: 'pass' },
  { server: 'socks5://proxy-2:1080', username: 'user', password: 'pass' },
  { server: 'socks5://proxy-3:1080', username: 'user', password: 'pass' },
];

async function navigateWithRotation(browser, url, index) {
  const proxy = proxyPool[index % proxyPool.length];
  const context = await browser.newContext({ proxy });
  const page = await context.newPage();

  try {
    await page.goto(url);
    const content = await page.content();
    return content;
  } finally {
    await context.close();
  }
}

// Chaque appel utilise un proxy différent
for (let i = 0; i < 10; i++) {
  await navigateWithRotation(browser, 'https://example.com', i);
}

Fermer le contexte après chaque utilisation assure un état propre : pas de cookies, de cache ou de réutilisation de connexion entre les rotations.

Attribution de proxy persistante par session

Pour les workflows où chaque compte a besoin d'un proxy persistant sur plusieurs chargements de page, gardez le contexte ouvert :

const accounts = [
  { name: 'account-a', proxy: 'socks5://proxy-us:1080' },
  { name: 'account-b', proxy: 'socks5://proxy-uk:1080' },
  { name: 'account-c', proxy: 'socks5://proxy-de:1080' },
];

const contexts = {};

for (const account of accounts) {
  contexts[account.name] = await browser.newContext({
    proxy: { server: account.proxy, username: 'user', password: 'pass' },
  });
}

// Chaque compte utilise son contexte et proxy dédiés
const pageA = await contexts['account-a'].newPage();
await pageA.goto('https://example.com/login');
// ... se connecter et effectuer des tâches avec le proxy du compte A

const pageB = await contexts['account-b'].newPage();
await pageB.goto('https://example.com/login');
// ... se connecter et effectuer des tâches avec le proxy du compte B

Configuration et utilisation

Proxy par défaut CLI avec remplacement par contexte

Définissez un proxy par défaut au niveau CLI, puis remplacez par contexte :

const browser = await chromium.launch({
  executablePath: '/path/to/botbrowser/chrome',
  args: [
    '--bot-profile=/path/to/profile.enc',
    // Proxy par défaut pour les contextes qui n'en spécifient pas
    '--proxy-server=socks5://default-proxy:1080',
  ],
  headless: true,
});

// Ce contexte utilise le proxy par défaut
const defaultCtx = await browser.newContext();

// Ce contexte remplace avec un proxy spécifique
const specialCtx = await browser.newContext({
  proxy: { server: 'socks5://special-proxy:1080', username: 'u', password: 'p' },
});

Combinaison avec les flags CLI de BotBrowser

Pour la meilleure cohérence géographique, combinez les proxies par contexte avec les flags CLI de BotBrowser :

const browser = await chromium.launch({
  executablePath: '/path/to/botbrowser/chrome',
  args: [
    '--bot-profile=/path/to/profile.enc',
    '--bot-local-dns',
    '--bot-webrtc-ice=google',
  ],
  headless: true,
});

Les flags --bot-local-dns et --bot-webrtc-ice s'appliquent globalement et protègent tous les contextes contre les fuites DNS et WebRTC.

Approche multi-instances Puppeteer

Puppeteer ne prend pas en charge les proxies par contexte de la même manière que Playwright. Pour Puppeteer, utilisez des instances de navigateur séparées :

const puppeteer = require('puppeteer-core');

async function createInstance(profile, proxy, timezone, locale) {
  return puppeteer.launch({
    executablePath: '/path/to/botbrowser/chrome',
    args: [
      `--bot-profile=${profile}`,
      `--proxy-server=${proxy}`,
      `--bot-config-timezone=${timezone}`,
      `--bot-config-locale=${locale}`,
      `--user-data-dir=${'/tmp/session-' + Math.random().toString(36).slice(2)}`,
    ],
    headless: true,
    defaultViewport: null,
  });
}

const usBrowser = await createInstance(
  '/profiles/us.enc', 'socks5://us-proxy:1080',
  'America/New_York', 'en-US'
);

const deBrowser = await createInstance(
  '/profiles/de.enc', 'socks5://de-proxy:1080',
  'Europe/Berlin', 'de-DE'
);

Vérification

Après avoir configuré le basculement dynamique de proxy, vérifiez chaque contexte indépendamment :

async function verifyContext(context, expectedCountry) {
  const page = await context.newPage();

  // Vérifier l'IP
  await page.goto('https://httpbin.org/ip');
  const ip = await page.textContent('body');
  console.log(`${expectedCountry} IP:`, ip);

  // Vérifier le fuseau horaire
  const tz = await page.evaluate(() =>
    Intl.DateTimeFormat().resolvedOptions().timeZone
  );
  console.log(`${expectedCountry} Timezone:`, tz);

  // Vérifier la locale
  const locale = await page.evaluate(() =>
    Intl.NumberFormat().resolvedOptions().locale
  );
  console.log(`${expectedCountry} Locale:`, locale);

  await page.close();
}

await verifyContext(usContext, 'US');
await verifyContext(deContext, 'DE');

Confirmez que chaque contexte affiche une IP, un fuseau horaire et une locale différents. Vérifiez qu'aucun trafic d'un contexte ne fuite dans un autre.

Bonnes pratiques

1. Fermez les contextes lorsque vous avez terminé. Les contextes ouverts consomment de la mémoire. Fermez-les après utilisation pour libérer des ressources.

2. Utilisez Playwright pour les proxies par contexte. Le support natif de proxy par contexte de Playwright est plus efficace que l'exécution d'instances de navigateur séparées.

3. Faites correspondre la géographie du proxy avec la locale. Alignez toujours le fuseau horaire, la locale et la langue avec l'emplacement du proxy. BotBrowser gère cela automatiquement lors de l'utilisation de proxies par contexte.

4. Définissez --bot-local-dns et --bot-webrtc-ice globalement. Ces flags protègent tous les contextes contre les fuites réseau indépendamment de la configuration du proxy.

5. Utilisez des profils d'empreinte différents pour différents comptes. Bien que les proxies par contexte isolent l'identité réseau, utiliser des profils différents par compte fournit également l'isolation d'empreinte.

6. N'utilisez pas page.authenticate() avec BotBrowser. L'API page.authenticate() peut interférer avec l'auto-détection géographique de BotBrowser. Utilisez plutôt des identifiants intégrés dans l'URL du proxy.

Questions fréquemment posées

Puis-je changer le proxy d'un contexte après sa création ? Non. Les paramètres de proxy sont fixés lors de la création du contexte. Pour changer de proxy, fermez le contexte actuel et créez-en un nouveau.

Combien de contextes peuvent fonctionner simultanément ? Il n'y a pas de limite stricte. Chaque contexte consomme de la mémoire proportionnelle à ses pages ouvertes et ses ressources en cache. En pratique, des centaines de contextes peuvent fonctionner au sein d'une seule instance de navigateur sur une machine avec suffisamment de RAM.

Les proxies par contexte supportent-ils SOCKS5H ? Oui. Tous les protocoles proxy supportés par --proxy-server sont également supportés dans la configuration de proxy par contexte.

BotBrowser détecte-t-il automatiquement la géographie pour les proxies par contexte ? Oui (ENT Tier1). Lorsque vous définissez un proxy par contexte, BotBrowser détecte l'IP du proxy et dérive automatiquement le fuseau horaire, la locale et la langue pour ce contexte.

Puis-je mélanger des proxies statiques et par contexte ? Oui. Définissez un proxy par défaut avec --proxy-server au lancement. Les contextes qui spécifient leur propre proxy remplacent le défaut. Les contextes sans paramètre de proxy héritent du défaut au niveau du navigateur.

Que se passe-t-il avec les cookies quand je ferme un contexte ? Tous les cookies, localStorage et cache de ce contexte sont supprimés. Si vous avez besoin de persistance des cookies, exportez-les avant de fermer le contexte.

Le basculement de proxy par contexte est-il supporté dans Puppeteer ? Puppeteer a un support limité de proxy par contexte. Pour un contrôle complet de proxy par contexte, utilisez Playwright. Pour Puppeteer, lancez des instances de navigateur séparées avec différentes valeurs --proxy-server.

Résumé

Le basculement dynamique de proxy permet des workflows multi-identités complexes au sein d'une seule instance de navigateur. Le support de proxy par contexte de BotBrowser, combiné avec la détection géographique automatique, fournit à chaque contexte une identité réseau complète : IP unique, fuseau horaire correspondant, locale appropriée et paramètres de langue cohérents.

Pour les fondamentaux du proxy, consultez Configuration du proxy. Pour la prévention des fuites réseau sur tous les contextes, combinez avec Prévention des fuites DNS et Prévention des fuites WebRTC. Pour l'isolation complète de l'identité, consultez Isolation multi-comptes du navigateur.