Authentification par proxy SOCKS5 Playwright : Pourquoi ça échoue, 4 solutions

Playwright accepte un serveur socks5:// puis refuse votre nom d'utilisateur et mot de passe. La limitation vient de Chromium, pas de Playwright, et elle est ouverte depuis 2021 — voici les quatre façons de la contourner, classées.

L'authentification par proxy SOCKS5 Playwright n'existe pas, et le savoir à l'avance vous épargne une soirée. Passez un serveur socks5:// avec un nom d'utilisateur et un mot de passe et Playwright refuse avant que le navigateur ne navigue. La demande de fonctionnalité sur laquelle tout le monde tombe, microsoft/playwright#10567, a été ouverte en novembre 2021, est toujours ouverte, et porte toujours l'étiquette P3-collecting-feedback. La limitation n'est pas à résoudre par Playwright : elle réside dans Chromium. Cet article montre les chaînes d'erreur exactes, explique pourquoi aucune extension ou drapeau de configuration ne vous sauve, et propose quatre solutions — l'échange HTTP en une ligne, la liste blanche IP, un relais local, et Firefox.

L'erreur que vous cherchez

Chaque version de ce problème produit l'une des deux chaînes. En Node, vous obtenez Error: Browser does not support socks5 proxy authentication; en Python, les anciennes versions la préfixent par playwright._impl._api_types.Error: et les plus récentes par playwright._impl._errors.Error:. Le message est le même, et il est lancé au démarrage, pas à la navigation :

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

// Fails immediately — no page is ever created
const browser = await chromium.launch({
  proxy: {
    server: 'socks5://gate.quantumproxies.io:PORT',
    username: 'USER',
    password: 'PASS',
  },
});
// Error: Browser does not support socks5 proxy authentication

// Python raises the same thing:
// playwright._impl._errors.Error: Browser does not support
// socks5 proxy authentication

Il existe une variante plus discrète. Si vous omettez les champs d'identifiants et les insérez dans la chaîne du serveur à la place — socks5://USER:PASS@host:1080 — rien ne se déclenche. Chromium ignore simplement la partie userinfo de l'URL, tente une poignée de main non authentifiée, et la passerelle la rejette. Vous voyez alors net::ERR_SOCKS_CONNECTION_FAILED ou un simple timeout sur le premier goto(), ce qui pousse les gens à chercher des bugs réseau qui n'existent pas.

Où l'authentification par proxy SOCKS5 Playwright échoue réellement

La documentation de Playwright est explicite : les champs username et password sur l'option de proxy sont décrits comme des identifiants à utiliser "si le proxy HTTP nécessite une authentification". SOCKS est pris en charge uniquement en tant que schéma. En dessous, Chromium n'a jamais implémenté la sous-négociation nom d'utilisateur/mot de passe du RFC 1929 pour SOCKS5, c'est pourquoi l'entrée du traqueur d'incidents de Chromium sur l'authentification SOCKS5 (40323993) a recueilli des années de commentaires, pourquoi l'extension SwitchyOmega avertit les utilisateurs dès qu'ils sélectionnent SOCKS5 avec des identifiants, et pourquoi Brave et Edge se comportent de manière identique. C'est un moteur, une lacune, héritée par tout ce qui est construit dessus.

C'est aussi pourquoi l'astuce qui sauve les utilisateurs de Selenium ne fonctionne pas ici. Une extension Manifest V3 peut répondre à un défi proxy via chrome.webRequest.onAuthRequired, mais ce crochet se déclenche sur les réponses HTTP 407 Proxy Authentication Required. Une poignée de main SOCKS5 est une négociation au niveau des octets sur le socket avant que tout HTTP n'existe, donc il n'y a pas d'événement à intercepter. Et ne confondez pas l'option de contexte httpCredentials avec l'auth proxy : elle répond aux défis 401 du site que vous visitez, jamais du proxy. Pour une vue d'ensemble des frameworks furtifs, notre carte des proxies authentifiés dans les frameworks anti-détection couvre qui prend en charge quoi.

Solution 1 : utilisez l'endpoint HTTP de la même passerelle

C'est la solution pour environ neuf utilisateurs sur dix, et c'est une ligne. Les fournisseurs sérieux exposent le même pool d'IP sur les deux protocoles à différents ports — chaque plan QuantumProxies expédie des endpoints HTTP et SOCKS5 avec les mêmes identifiants et la même syntaxe de session. Changez le schéma et le port, gardez tout le reste, et les champs d'identifiants natifs de Playwright font leur travail :

from playwright.sync_api import sync_playwright

with sync_playwright() as p:
    browser = p.chromium.launch(proxy={
        # was: "socks5://gate.quantumproxies.io:SOCKS_PORT"
        "server": "http://gate.quantumproxies.io:PORT",
        "username": "USER",
        "password": "PASS",
    })
    page = browser.new_page()
    page.goto("https://httpbin.org/ip")
    print(page.text_content("body"))   # must be the proxy exit IP
    browser.close()

Vous ne perdez rien de mesurable. Pour le trafic du navigateur, un proxy HTTP ouvre un tunnel CONNECT et transporte les mêmes octets chiffrés qu'un tunnel SOCKS5 le ferait ; les différences entre les deux protocoles comptent pour le trafic UDP et non-HTTP, pas pour le chargement d'une page. Notre analyse de SOCKS5 versus HTTP proxies contient les détails. Et parce que l'objet proxy est également accepté par newContext(), les mêmes identifiants vous offrent une rotation par contexte exactement comme décrit dans notre guide d'intégration de proxy Playwright.

Solution 2 : la liste blanche IP maintient socks5:// en vie

Si vous avez vraiment besoin du schéma SOCKS5 — un proxy qui ne parle que SOCKS, une chaîne d'outils qui le suppose — authentifiez la machine au lieu de la requête. Enregistrez l'IP publique du scraper auprès de votre fournisseur, retirez les identifiants, et Chromium est content car il n'y a rien à négocier :

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

const browser = await chromium.launch({
  proxy: { server: 'socks5://gate.quantumproxies.io:PORT' }, // no creds
});
const page = await browser.newPage();
await page.goto('https://httpbin.org/ip');
console.log(await page.textContent('body'));
await browser.close();

La liste blanche authentifie une machine, pas un script, et c'est tout le compromis. Un VPS ou une sortie de bureau avec une adresse stable fonctionne parfaitement ; les runners CI éphémères, les conteneurs autoscalés et tout ce qui se trouve derrière un NAT rotatif échoueront dès que l'adresse changera. Vérifiez la sortie avant de faire confiance à un run — une connexion directe silencieuse ressemble exactement à un proxy fonctionnel jusqu'à ce que votre cible commence à bloquer votre propre IP. Notre vérificateur de qualité IP gratuit vous indique ce qu'est réellement la sortie, pas seulement qu'elle a répondu.

Comparaison des quatre solutions pour l'authentification par proxy SOCKS5 Playwright : endpoint HTTP, liste blanche IP, relais local et Firefox — L'échange d'endpoint HTTP coûte une ligne et aucune capacité. Tout ce qui se trouve à droite de cela vous achète le schéma socks5:// à un prix.

Solution 3 : un relais local qui supprime les identifiants

Lorsque l'IP ne peut pas être mise en liste blanche et que le fournisseur n'a pas de port HTTP, placez un traducteur devant le navigateur. Le modèle est toujours le même : un écouteur local sans authentification transfère à l'endpoint SOCKS5 en amont avec les identifiants attachés. Avec gost, c'est une seule commande :

# Local no-auth HTTP listener -> authenticated upstream SOCKS5
gost -L=http://127.0.0.1:8080 \
     -F=socks5://USER:PASS@gate.quantumproxies.io:PORT

# Playwright then points at the local hop, with no credentials:
#   proxy: { server: 'http://127.0.0.1:8080' }

Deux règles. Lie l'écouteur à 127.0.0.1, jamais 0.0.0.0 — un proxy sans authentification accessible depuis Internet est un relais ouvert qui sera trouvé et abusé en quelques heures. Et traitez le relais comme un processus que vous devez superviser : s'il meurt, Chromium retombe sur une erreur de connexion plutôt qu'une requête directe, ce qui est au moins bruyant. Cette approche est devenue suffisamment courante pour que les praticiens publient de petits relais conçus à cet effet ; nous comparons les options dans notre guide des outils de relais d'auth SOCKS5.

Solution 4 : exécutez Firefox à la place de Chromium

Firefox implémente nativement l'authentification nom d'utilisateur/mot de passe SOCKS5, ce qui est la différence que le fil de discussion sur le problème Playwright continue de souligner. Changez le type de navigateur et l'erreur disparaît :

from playwright.sync_api import sync_playwright

with sync_playwright() as p:
    browser = p.firefox.launch(proxy={
        "server": "socks5://gate.quantumproxies.io:PORT",
        "username": "USER",
        "password": "PASS",
    })
    page = browser.new_page()
    page.goto("https://httpbin.org/ip")
    print(page.text_content("body"))   # confirm the exit before trusting it
    browser.close()

Faites l'étape de vérification, à chaque fois. Le fait que Playwright ne lance pas d'erreur n'est pas une preuve que les identifiants ont été utilisés — seul un écho IP l'est. Et soyez clair sur ce que vous achetez : un moteur de rendu différent, une surface d'empreinte digitale différente, et un écosystème furtif qui penche fortement vers Chromium. Si votre cible accepte déjà Firefox, c'est gratuit. Si vous avez choisi Chromium pour des raisons anti-bot, changer de moteur pour résoudre un problème de proxy est le mauvais compromis — prenez la solution 1 et gardez votre navigateur.

La décision, en une ligne chacune

Le fournisseur a un port HTTP : utilisez-le. Une ligne, authentification native, mêmes sorties, pas de processus supplémentaire.
IP publique fixe : mettez-la en liste blanche et gardez socks5:// sans identifiants.
Aucun des deux : exécutez un relais local lié à la boucle locale et pointez Playwright sur 127.0.0.1.
Déjà sur Firefox : passez les identifiants et vérifiez l'IP de sortie une fois.
Jamais : identifiants à l'intérieur de la chaîne server. Chromium les ignore sans un mot.

Liste de configurations de proxy SOCKS5 Playwright qui fonctionnent dans Chromium contre celles qui échouent ou échouent silencieusement — Chromium accepte le schéma SOCKS5 et jamais les identifiants. Tout ce qui se trouve à droite de cette liste échoue — la moitié sans erreur.

Questions fréquemment posées

Playwright prend-il en charge l'authentification par proxy SOCKS5 ?

Pas avec Chromium. L'option de proxy de Playwright documente le nom d'utilisateur et le mot de passe comme des identifiants HTTP(S), et Chromium n'a pas d'implémentation nom d'utilisateur/mot de passe SOCKS5 pour les transmettre, donc le lancement échoue. Firefox dans Playwright le prend en charge. Le problème de suivi, microsoft/playwright#10567, est ouvert depuis novembre 2021 sans correctif prévu.

Que signifie 'Browser does not support socks5 proxy authentication' ?

Cela signifie que vous avez passé des identifiants avec un serveur socks5:// à un lancement Chromium. Playwright valide la combinaison et refuse plutôt que d'ouvrir un navigateur qui les ignorerait silencieusement. Soit passez à l'endpoint HTTP de la passerelle et gardez les champs d'identifiants, soit authentifiez par liste blanche IP et retirez-les entièrement.

Comment utiliser un proxy SOCKS5 avec Playwright en Python ?

Passez proxy={"server": "socks5://host:port"} sans nom d'utilisateur ni mot de passe, et demandez au fournisseur d'autoriser l'IP publique de votre machine. Si l'IP n'est pas stable, utilisez l'endpoint HTTP de la même passerelle avec identifiants, ou transférez via un relais local. Confirmez toujours la sortie par rapport à un endpoint d'écho IP.

Une extension Chrome peut-elle ajouter une authentification SOCKS5 ?

Non. L'astuce d'extension utilisée pour les proxies HTTP authentifiés repose sur chrome.webRequest.onAuthRequired, qui se déclenche sur les réponses HTTP 407. SOCKS5 s'authentifie pendant la poignée de main socket, avant qu'une requête HTTP n'existe, donc aucune API d'extension ne peut la voir. Les extensions de commutation de proxy avertissent de cette limitation pour la même raison.

Le SOCKS5 est-il plus rapide que HTTP pour le scraping Playwright ?

Pas de manière significative. Le trafic HTTPS via un proxy HTTP utilise un tunnel CONNECT, donc les deux protocoles transportent le même flux chiffré avec une surcharge comparable. Les véritables avantages de SOCKS5 sont le support UDP et la neutralité du protocole, dont aucun n'est utilisé par le chargement d'une page de navigateur. Choisissez l'endpoint qui s'authentifie proprement.

La version courte : arrêtez d'essayer de faire faire à Chromium quelque chose qu'il n'a jamais fait. Déplacez le travail vers l'endpoint HTTP, ou mettez en liste blanche et retirez les identifiants — et si vous devez garder socks5:// avec une sortie rotative, mettez un relais au milieu plutôt qu'un contournement dans votre code. Une fois l'authentification réglée, ce qui décide si l'exécution réussit est le pool derrière : sorties résidentielles dans plus de 200 pays, avec rotation par requête ou sessions persistantes lorsqu'un flux nécessite une identité.

Obtenez des endpoints HTTP et SOCKS5 sur un seul plan