Configuration des proxys résidentiels dans Selenium et Playwright

La passerelle est identique pour les deux, mais l'authentification du proxy ne l'est pas. Voici la même configuration dans chaque framework et les différences qui influencent votre architecture.

Si vous devez choisir entre Selenium et Playwright pour un travail qui passe par des proxies résidentiels, ou maintenir les deux, l’élément utile n’est pas deux guides de configuration séparés mais la comparaison : ce qui est identique, ce qui est réellement différent, et lesquelles de ces différences devraient influencer votre façon de construire. Voici le même travail effectué dans chacun, côte à côte.

Pour le détail plus approfondi propre à chaque framework, y compris les cas limites de chacun, voir proxies résidentiels dans Selenium et proxies résidentiels avec Playwright. Ceci est la couche de comparaison au-dessus.

Ce qui est identique : la passerelle

Les deux frameworks parlent au même endpoint avec les mêmes identifiants, car le proxy ne se soucie pas de ce qui le pilote. Host p.shifter.io, port 443, et tout votre ciblage encodé dans le nom d’utilisateur :

customer-USERNAME                                # rotate, no geo
customer-USERNAME-country-de                     # German exit
customer-USERNAME-country-us-city-new_york       # city level
customer-USERNAME-country-de-sid-abc123-ttl-600  # sticky, ten minutes

Cela signifie que chaque décision concernant la géographie, la rotation et la durée de vie de la session est une chaîne de caractères, identique dans les deux frameworks. Rien dans les sections ci-dessous ne change la passerelle, seulement la façon dont chaque framework lui transmet vos identifiants. La référence du format se trouve dans comment se connecter.

La seule vraie différence : l’authentification

C’est la différence qui compte, et elle explique la plupart des frictions rencontrées.

Playwright prend en charge nativement les proxies authentifiés. Le nom d’utilisateur et le mot de passe sont des options de premier ordre, donc cela fonctionne dès le départ.

Selenium ne le fait pas. Il peut définir un hôte et un port de proxy, mais la spécification WebDriver n’a aucun mécanisme pour transmettre des identifiants, donc Chrome affiche une boîte de dialogue d’authentification native que votre script ne peut pas fermer. Chaque solution Selenium est un contournement de cette lacune, et il en existe trois : Selenium Wire, qui gère les identifiants pour vous ; une petite extension Chrome générée qui les fournit ; ou CDP, en pilotant directement le protocole de débogage du navigateur.

Si vous démarrez de zéro et que votre travail nécessite des proxies authentifiés, cette différence seule est une raison légitime de préférer Playwright.

La même configuration dans les deux

Playwright, Python :

from playwright.sync_api import sync_playwright

USER = "customer-USERNAME-country-de-sid-abc123-ttl-600"

with sync_playwright() as p:
    browser = p.chromium.launch()
    context = browser.new_context(
        proxy={"server": "http://p.shifter.io:443",
               "username": USER, "password": "PASSWORD"},
        locale="de-DE", timezone_id="Europe/Berlin",   # match the exit
    )
    page = context.new_page()
    page.goto("https://ipinfo.io/json")
    print(page.inner_text("body"))

Playwright, Node :

const ctx = await browser.newContext({
  proxy: { server: 'http://p.shifter.io:443',
           username: 'customer-USERNAME-country-de-sid-abc123-ttl-600',
           password: 'PASSWORD' },
  locale: 'de-DE', timezoneId: 'Europe/Berlin',
});

Selenium, Python, avec Selenium Wire :

from seleniumwire import webdriver

USER = "customer-USERNAME-country-de-sid-abc123-ttl-600"
proxy_url = f"http://{USER}:PASSWORD@p.shifter.io:443"

opts = {"proxy": {"http": proxy_url, "https": proxy_url,
                  "no_proxy": "localhost,127.0.0.1"}}
driver = webdriver.Chrome(seleniumwire_options=opts)
driver.get("https://ipinfo.io/json")
print(driver.find_element("tag name", "body").text)

Même passerelle, même nom d’utilisateur, même résultat. La seule différence est la façon dont les identifiants entrent en jeu.

La différence structurelle : comment vous isolez les identités

C’est celle qui devrait réellement façonner votre conception, et elle découle du coût d’une identité isolée dans chaque framework.

Dans Playwright, les contextes sont peu coûteux. Un contexte de navigateur est un profil isolé avec ses propres cookies, son propre stockage et, surtout, son propre proxy. Vous pouvez exécuter un seul processus de navigateur et créer un contexte par identité, ce qui fait de la rotation de la géographie ou des sessions une simple création de nouveau contexte plutôt que de nouveau navigateur.

browser = p.chromium.launch()          # one process
for country in ["de", "fr", "us"]:
    ctx = browser.new_context(proxy={"server": "http://p.shifter.io:443",
                                     "username": f"customer-USERNAME-country-{country}",
                                     "password": "PASSWORD"})
    page = ctx.new_page()
    page.goto("https://example.com")
    ctx.close()                        # identity discarded, process stays

Dans Selenium, le proxy est lié au driver. Le changer implique généralement un nouveau driver, et un driver est tout un processus de navigateur : lent à démarrer et lourd en mémoire. Le schéma Selenium est donc l’inverse : réutiliser un driver pour de nombreuses requêtes sur une seule identité, et traiter un changement d’identité comme une opération coûteuse que l’on regroupe plutôt que d’effectuer par requête.

La conséquence pratique : un travail nécessitant de nombreuses identités de courte durée est nettement moins coûteux avec Playwright, tandis qu’un travail qui conserve une seule identité pour une longue séquence convient aux deux. Si vous exécutez Selenium et que vous vous retrouvez à lancer un driver par requête, c’est ce qu’il faut corriger en premier, pas la configuration du proxy.

Géographie, rotation et sessions

Comme le ciblage se trouve dans le nom d’utilisateur, cette partie est indépendante du framework. Omettez sid et chaque nouvelle connexion obtient une adresse de sortie fraîche ; incluez-en un et la même adresse est conservée jusqu’à l’expiration du TTL. Dans Playwright, vous le définissez par contexte ; dans Selenium, par driver.

Une chose à bien faire dans les deux cas : lorsque vous définissez un pays, faites correspondre la locale et le fuseau horaire du navigateur à celui-ci. Une adresse de sortie allemande signalant un fuseau horaire de New York est une contradiction facile à détecter et facile à éviter, et les deux frameworks exposent ces éléments comme options de contexte, voir faire correspondre géo, fuseau horaire et locale.

Bande passante : le coût partagé par les deux frameworks

Les navigateurs sont coûteux sur un produit facturé au Go car ils récupèrent tout ce qu’un vrai navigateur récupérerait : images, polices, médias, analytics. Bloquer ce dont vous n’avez pas besoin est la plus grande économie disponible, et les deux frameworks la prennent en charge.

Playwright :

context.route("**/*", lambda route: route.abort()
              if route.request.resource_type in {"image", "media", "font", "stylesheet"}
              else route.continue_())

Selenium n’a pas d’équivalent en une ligne dans sa forme classique ; avec Selenium Wire vous pouvez filtrer les requêtes, ou vous pouvez bloquer les types de ressources via CDP. Dans tous les cas, cela vaut la peine, car cela réduit généralement le poids de la page d’un facteur important. L’argument plus large, y compris la question de savoir si vous avez réellement besoin d’un navigateur, se trouve dans quand avez-vous besoin d’un navigateur headless et réduire les coûts de bande passante proxy.

Vérifier que ça fonctionne, dans les deux cas

Ne présumez pas que le proxy est appliqué. Naviguez vers un endpoint qui signale l’adresse et vérifiez qu’elle n’est pas la vôtre :

# Playwright
page.goto("https://ipinfo.io/json"); print(page.inner_text("body"))

# Selenium
driver.get("https://ipinfo.io/json"); print(driver.find_element("tag name", "body").text)

Si l’adresse est la vôtre, le proxy n’est pas appliqué du tout. Si elle est correcte mais que le contenu ne correspond pas à la région, suspectez le DNS ou une incohérence de locale avant d’incriminer le pool, voir prévenir les fuites DNS.

Lequel choisir

Si vous n’avez aucun engagement existant et que votre travail implique des proxies authentifiés et de nombreuses identités, Playwright est la voie la plus simple : le support natif des identifiants et l’isolation peu coûteuse par contexte suppriment deux problèmes que vous devriez sinon contourner par ingénierie.

Selenium reste un choix raisonnable là où vous disposez déjà d’un parc Selenium, où vous avez besoin de son grid et de son écosystème multi-navigateurs, ou là où le travail consiste en une seule session de longue durée plutôt qu’en de nombreuses courtes. La prise en charge du proxy est tout à fait viable, cela vous coûte simplement une bibliothèque ou une petite extension pour faire entrer les identifiants.

Et dans les deux cas, souvenez-vous que le navigateur n’est que la moitié de la solution pour éviter les blocages : l’adresse vous mène à la porte, et les en-têtes, l’empreinte et le rythme décident de ce qui se passe ensuite, voir éviter les blocages.

En résumé

La passerelle est identique pour les deux frameworks, donc la géographie, la rotation et la durée de vie de la session sont la même chaîne de caractères dans chacun. La vraie différence est l’authentification, que Playwright prend en charge nativement et Selenium non, nécessitant Selenium Wire, une extension, ou CDP. La différence qui devrait façonner votre architecture est le coût de l’isolation : les contextes Playwright sont peu coûteux, donc vous faites tourner l’identité par contexte, alors qu’un proxy Selenium est lié à un driver, donc vous réutilisez les drivers et regroupez les changements d’identité. Faites correspondre la locale et le fuseau horaire à l’adresse de sortie dans les deux cas, bloquez les ressources inutiles dans les deux cas car vous payez par gigaoctet, et vérifiez l’adresse de sortie avant d’y faire confiance.

Les deux fonctionnent sur les mêmes proxies résidentiels, une seule passerelle avec ciblage par pays et ville et sessions persistantes quand un flux en a besoin, facturés par Go de sorte que le blocage de ressources décrit ci-dessus se traduit directement par une facture plus légère.