Configuration du proxy Patchright : Lancement, Contextes, Authentification et Docker

Patchright corrige les fuites du CDP qui exposent Playwright avant le démarrage du navigateur. Il ne touche pas à la réputation de votre IP — et sa configuration furtive recommandée modifie discrètement la manière dont vous faites tourner les proxies.

Patchright est une version corrigée et indétectable de Playwright qui fonctionne comme un remplacement direct : changez l'importation, gardez le code. Les correctifs s'appliquent avant le démarrage du processus du navigateur — ils retirent les drapeaux d'automatisation et les appels du Chrome DevTools Protocol qui permettent à un site de profiler une session Playwright dans ses premières millisecondes. Ce qu'ils ne touchent pas, c'est le réseau. Chaque question sur le proxy Patchright revient à cette séparation, et à un détail que le README enterre : la configuration recommandée par le projet pour un maximum de furtivité est un contexte persistant, qui modifie discrètement la manière dont vous faites tourner les sorties. Voici le guide axé sur les proxies — lancement versus contexte, passerelles authentifiées, Docker, et un compte rendu honnête du plafond.

Installation et le proxy direct

Patchright est disponible pour Python, Node et .NET, et ne corrige que Chromium — Firefox et WebKit ne sont explicitement pas pris en charge. Installez-le et récupérez le vrai Google Chrome plutôt que le Chromium fourni, ce que le projet recommande pour la furtivité :

pip install patchright
patchright install chrome
# Node: npm i patchright && npx patchright install chrome

L'API proxy est celle de Playwright, inchangée, car les proxies sont l'une des rares choses que Patchright laisse délibérément intactes. Les identifiants vont dans des champs dédiés, jamais à l'intérieur de l'URL du serveur — c'est pourquoi les proxies authentifiés n'ont pas besoin d'une extension ici, contrairement à Selenium ou Puppeteer brut :

from patchright.sync_api import sync_playwright

PROXY = {
    "server": "http://gate.quantumproxies.io:PORT",
    "username": "USER",
    "password": "PASS",
}

with sync_playwright() as p:
    browser = p.chromium.launch(channel="chrome", proxy=PROXY)
    page = browser.new_page()
    page.goto("https://httpbin.org/ip")
    print(page.text_content("body"))   # the exit IP
    browser.close()

C'est toute la réponse à "Patchright prend-il en charge les proxies" : oui, identiquement à Playwright en amont, y compris la liste de bypass et la particularité de Chromium selon laquelle les adresses de bouclage contournent complètement le proxy — donc tester contre un serveur simulé local semblera toujours ignorer le proxy. Si vous êtes nouveau dans le modèle sous-jacent, notre guide d'intégration des proxies Playwright couvre le comportement de base, et la carte des proxies des frameworks anti-détection compare quelles piles acceptent les identifiants nativement.

Proxies par contexte et le stub global

Les contextes sont l'unité de rotation économique : cookies, stockage et cache séparés, créés en millisecondes au lieu des secondes qu'un lancement de navigateur coûte. Chacun prend sa propre option proxy, de sorte qu'un seul processus peut contenir une identité américaine et une identité allemande en même temps. Il y a un piège documenté de Playwright qui fait trébucher les gens ici — le navigateur doit être lancé avec un proxy global pour que les proxies par contexte fonctionnent sur Chromium. Si chaque contexte le remplace, la valeur globale n'est jamais utilisée et peut être n'importe quelle chaîne de remplacement :

const { chromium } = require('patchright');

(async () => {
  // the global proxy is never used — it only enables the per-context option
  const browser = await chromium.launch({
    channel: 'chrome',
    proxy: { server: 'http://per-context' },
  });

  for (const job of jobs) {
    const context = await browser.newContext({
      proxy: {
        server: 'http://gate.quantumproxies.io:PORT',
        username: 'USER-country-' + job.country,   // geo in the username
        password: 'PASS',
      },
    });
    const page = await context.newPage();
    try {
      await page.goto(job.url, { timeout: 30000 });
      // ...extract...
    } finally {
      await context.close();   // burns the cookies with the exit
    }
  }
  await browser.close();
})();

Pointé vers une passerelle rotative, chaque contexte part d'une adresse différente dans un pool résidentiel de plus de 90 millions sans gestion de liste de votre côté — c'est ce que font les proxies rotatifs côté serveur. Notez où se trouvent les contrôles géographiques et de session dans cet extrait : dans le nom d'utilisateur, pas dans un en-tête personnalisé. Cela compte plus dans Patchright que dans Playwright simple, car les conseils du projet sont d'éviter les en-têtes personnalisés et les remplacements de user-agent, car les valeurs injectées sont elles-mêmes une surface de détection. Le contrôle par paramètre de nom d'utilisateur garde la forme de la requête du navigateur intacte.

Le compromis du contexte persistant

La configuration furtive recommandée par Patchright n'est pas launch(). C'est launch_persistent_context() avec un véritable canal Chrome, un répertoire de données utilisateur, sans remplacement de viewport et en mode affiché — et explicitement sans en-têtes personnalisés ni user-agent falsifié. Cette configuration persiste également tous les cookies de validation qu'un défi vous remet, donc un défi résolu est réutilisable à travers les exécutions. La conséquence sur le proxy est structurelle : un contexte persistant est le contexte. Il n'y a pas de newContext() pour accrocher un second proxy, donc un processus équivaut à une identité de sortie.

from patchright.sync_api import sync_playwright

with sync_playwright() as p:
    ctx = p.chromium.launch_persistent_context(
        user_data_dir="profiles/it-01",   # one profile per identity
        channel="chrome",
        headless=False,
        no_viewport=True,
        proxy={
            "server": "http://gate.quantumproxies.io:PORT",
            "username": "USER-country-it-session-it01",   # sticky, pinned to the profile
            "password": "PASS",
        },
        # do NOT pass user_agent or extra_http_headers here
    )
    page = ctx.new_page()
    page.goto("https://example.com")
    ctx.close()

Ainsi, la rotation devient une décision au niveau du processus : un répertoire de profil par identité, une session collante épinglée à celui-ci, et un pool de travailleurs au lieu d'une boucle de contexte. Gardez l'appariement stable — un profil qui a accumulé des cookies derrière une sortie italienne et qui réapparaît ensuite derrière une brésilienne est une contradiction qu'aucun correctif CDP ne peut cacher. Règle pratique : nommez le répertoire d'après l'identifiant de session, supprimez le répertoire lorsque vous brûlez la session, et ne partagez jamais un profil entre deux sorties.

Exécution de Patchright dans Docker derrière un proxy

Conteneuriser un navigateur furtif comporte deux pièges, et les deux ont des conséquences sur le proxy. Le premier est --no-sandbox : la solution habituelle pour Chrome refusant de démarrer en tant que root, et un drapeau que les fournisseurs anti-bot lisent volontiers. Exécutez en tant qu'utilisateur non-root à la place. Le second est le mode sans tête — le projet recommande le mode affiché, donc utilisez un affichage virtuel plutôt que de recourir à l'option sans tête :

# Dockerfile
FROM python:3.12-slim

RUN apt-get update && apt-get install -y --no-install-recommends \
      xvfb ca-certificates && rm -rf /var/lib/apt/lists/*

RUN pip install --no-cache-dir patchright \
 && patchright install --with-deps chrome

RUN useradd -m app
USER app
WORKDIR /home/app
COPY --chown=app:app scrape.py .

# headed under a virtual display: no --no-sandbox, no HeadlessChrome tell
CMD ["xvfb-run", "-a", "python", "scrape.py"]

# build & run:
#   docker build -t patchright-worker .
#   docker run --ipc=host --shm-size=1g patchright-worker

Les options --ipc=host et un /dev/shm plus grand sont les correctifs standard pour Chromium dans Docker pour les plantages d'onglets sous charge, directement issus des documents de conteneur Playwright. Un piège spécifique aux proxies : si vous exécutez un relais local pour ajouter des identifiants à un point d'extrémité SOCKS5, 127.0.0.1 à l'intérieur du conteneur est le conteneur, pas votre hôte. Soit mettez le relais dans le même conteneur, adressez explicitement l'hôte, soit exécutez le relais en tant que sidecar sur un réseau partagé. Et gardez le répertoire de profil sur un volume si vous utilisez des contextes persistants, sinon chaque redémarrage de conteneur jette les cookies de validation que vous avez payés en bande passante pour obtenir.

Ce que les correctifs couvrent, et ce qu'ils ne couvriront jamais

Il vaut la peine de savoir exactement ce que vous achetez. Le correctif principal de Patchright est la fuite Runtime.enable — il exécute JavaScript dans des contextes d'exécution isolés au lieu d'activer le domaine qui trahit le jeu. Il désactive l'API Console pour fermer Console.enable (donc l'enregistrement page.on("console") est supprimé, ce qui est un vrai coût lorsque vous déboguez une défaillance de proxy). Il réécrit les drapeaux par défaut de Playwright : ajoute --disable-blink-features=AutomationControlled, retire --enable-automation, et remet --disable-popup-blocking, --disable-component-update, --disable-default-apps et --disable-extensions. Il atteint également les racines d'ombre fermées avec des localisateurs ordinaires.

Lisez cette liste de drapeaux comme un élément de ligne de bande passante aussi. Restaurer les mises à jour des composants et les applications par défaut signifie un navigateur qui appelle à la maison en arrière-plan — à travers votre sortie mesurée. Mesurez le transfert d'une session avant de passer à l'échelle, et bloquez les types de ressources image, police et média sur le contexte pour maintenir le coût par page bas. Rien de tout cela ne touche l'autre mur : un navigateur corrigé sur une IP de centre de données brûlée est toujours une IP brûlée, et la requête est refusée sur la réputation avant que toute cette ingéniosité ne soit évaluée. Vérifiez une adresse avec le vérificateur de qualité IP gratuit avant de conclure que les correctifs ont échoué, et placez des proxies résidentiels sous le navigateur pour que les deux couches résolvent des problèmes différents.

Questions fréquemment posées

Comment définir un proxy dans Patchright ?

Exactement comme dans Playwright : passez proxy={"server": "http://host:port", "username": "USER", "password": "PASS"} à chromium.launch(), launch_persistent_context() ou new_context(). Patchright ne corrige pas la couche proxy, donc chaque comportement en amont — la liste de contournement, l'exception de bouclage — s'applique inchangé.

Patchright prend-il en charge l'authentification proxy SOCKS5 ?

Non, et c'est une limitation de Chromium plutôt qu'une de Patchright : Chromium n'a pas de mécanisme pour les identifiants SOCKS, donc les points d'extrémité SOCKS5 authentifiés échouent. Utilisez le port HTTP de la même passerelle avec les champs nom d'utilisateur et mot de passe, ou authentifiez par liste blanche IP et conservez le schéma SOCKS5 — chaque plan QuantumProxies prend en charge la liste blanche comme alternative à user:pass. L'ensemble complet des solutions de contournement est dans notre guide d'authentification SOCKS5 Playwright, qui s'applique ici sans changement.

Patchright peut-il utiliser un proxy différent par contexte ?

Oui, si vous avez lancé le navigateur avec une valeur de proxy global — même un substitut — car Chromium n'active les proxies par contexte que lorsqu'un est présent au lancement. L'exception est la configuration de contexte persistant que Patchright recommande pour la furtivité : cela vous donne un seul contexte, donc la rotation signifie un processus séparé avec son propre répertoire de profil.

Patchright est-il uniquement pour Chromium ?

Oui. Le projet déclare clairement que seuls les navigateurs basés sur Chromium sont corrigés ; Firefox et WebKit ne sont pas pris en charge. Si vous avez besoin de furtivité avec le moteur Firefox avec une géo dérivée de la sortie du proxy, c'est un outil différent — consultez notre guide proxy et geoip Camoufox.

Suis-je toujours bloqué avec Patchright ?

Sur des cibles difficiles, oui. Des tests indépendants montrent que le mode sans tête fuit toujours un indice HeadlessChrome, et des pages de défi qu'un navigateur corrigé atteint mais ne peut pas résoudre. Les correctifs ferment les vérifications d'automatisation bon marché ; la réputation IP, les empreintes digitales TLS et la résolution de défis sont des problèmes distincts qui nécessitent des réponses distinctes.

Traitez Patchright pour ce qu'il est : une très bonne solution pour une classe spécifique de fuite, livrée sans vous demander de réécrire une ligne de Playwright. Associez-le à des sorties propres, collantes là où l'identité compte, et vérifiées avant l'exécution — alors les échecs restants concernent réellement la cible, pas votre configuration. Ceci est un guide technique, pas un conseil juridique : automatisez dans le respect de la loi et des conditions du site.

Mettez Patchright sur des sorties résidentielles propres