Proxy Zendriver Avec Authentification : Configuration et Solutions
Zendriver est le fork communautaire de nodriver — plus rapide à corriger, mais avec le même problème d'authentification des proxies. Voici la configuration complète du proxy, ce qui diffère réellement, et les solutions pour faire fonctionner user:pass.
Un proxy zendriver est configuré exactement comme un proxy nodriver — ce qui est à la fois une bonne nouvelle et un inconvénient. zendriver (le projet cdpdriver/zendriver) est le fork communautaire de nodriver : un framework d'automatisation de navigateur asynchrone et indétectable qui pilote Chrome directement via le DevTools Protocol, sans WebDriver en vue. Il existe parce que le seul mainteneur de nodriver fusionnait rarement les corrections externes, donc la communauté a créé un fork pour accepter les corrections de bugs, ajouter des fonctionnalités et traiter les problèmes sur GitHub. Ce qu'il n'a pas corrigé, ce sont les proxies authentifiés. Ce guide couvre la configuration complète du proxy, ce qui diffère réellement de nodriver, et les solutions pour faire fonctionner user:pass.
Installation et configuration de base du proxy
L'installation se fait en une ligne — pip install zendriver — et l'API reflète nodriver presque symbole pour symbole, donc import zendriver as zd est souvent le seul changement lors du portage d'un script. Un proxy non authentifié passe par browser_args, et la requête sort de l'IP du proxy :
import zendriver as zd
async def main():
browser = await zd.start(
browser_args=["--proxy-server=gate.quantumproxies.io:PORT"],
)
page = await browser.get("https://httpbin.org/ip")
print(await page.get_content()) # shows the proxy exit IP
await browser.stop()
zd.loop().run_until_complete(main())Cela fonctionne car c'est juste un drapeau Chrome. Ajoutez les identifiants — --proxy-server=http://USER:PASS@host:port — et Chromium ignore silencieusement la partie USER:PASS@, le proxy répond 407, et une boîte de dialogue de connexion native apparaît que zendriver ne peut pas remplir. C'est une limitation de Chrome, pas un bug de zendriver, donc aucune mise à jour ne fera accepter un mot de passe au drapeau.
Le problème d'authentification des proxies zendriver
Le problème est ouvertement suivi dans les problèmes de zendriver — un fil de demande de fonctionnalité (#10) et un problème dédié "Proxy avec auth" (#208) — ce qui est en soi une différence notable : sur nodriver, la même question est enfouie dans une discussion que le mainteneur a répondu une fois et est passé à autre chose. Un utilisateur sur le problème #10 résume brutalement l'état des lieux : l'option du serveur proxy n'a aucun moyen de s'authentifier, donc ils utilisent une extension proxy à la place et cela fonctionne bien. C'est le consensus éprouvé sur le terrain, et cela pointe directement vers les trois mêmes solutions sur lesquelles les utilisateurs de nodriver comptent.
Solution 1 : Liste blanche d'IP (la plus simple)
Si votre travail s'exécute à partir d'une machine avec une IP publique stable, ignorez complètement les identifiants. Enregistrez l'IP de sortie dans votre tableau de bord fournisseur et la passerelle vous authentifie par adresse source — le code zendriver reste le simple extrait --proxy-server ci-dessus, sans logique d'authentification. Chaque plan QuantumProxies prend en charge la liste blanche d'IP en plus de user:pass, ce qui en fait la recommandation par défaut chaque fois que votre IP est fixe. La seule limite est qu'il authentifie une machine, pas un script, donc les exécuteurs éphémères et les conteneurs derrière un NAT ont besoin de l'une des deux méthodes suivantes.
Solution 2 : répondre au défi via CDP
Parce que zendriver expose le DevTools Protocol de la même manière que nodriver, vous pouvez intercepter le défi d'authentification en cours de processus : enregistrez les gestionnaires RequestPaused et AuthRequired, puis activez le domaine Fetch avec handle_auth_requests=True et répondez avec continue_with_auth. Les deux règles non évidentes sont identiques à nodriver — ajoutez les gestionnaires avant d'activer le domaine, et lancez les réponses avec asyncio.create_task pour qu'attendre celles-ci ne puisse pas bloquer la boucle :
import asyncio
import zendriver as zd
async def main():
browser = await zd.start(browser_args=["--proxy-server=gate.quantumproxies.io:PORT"])
tab = await browser.get("draft:,") # blank tab first
async def on_auth(event):
asyncio.create_task(tab.send(zd.cdp.fetch.continue_with_auth(
request_id=event.request_id,
auth_challenge_response=zd.cdp.fetch.AuthChallengeResponse(
response="ProvideCredentials", username="USER", password="PASS",
),
)))
async def on_request(event):
asyncio.create_task(tab.send(
zd.cdp.fetch.continue_request(request_id=event.request_id)))
# handlers FIRST, then enable the domain
tab.add_handler(zd.cdp.fetch.RequestPaused, on_request)
tab.add_handler(zd.cdp.fetch.AuthRequired, on_auth)
await tab.send(zd.cdp.fetch.enable(handle_auth_requests=True))
page = await browser.get("https://httpbin.org/ip")
await asyncio.sleep(3)
print(await page.get_content())
await browser.stop()
zd.loop().run_until_complete(main())Le guide complet sur pourquoi l'ordre des gestionnaires est important, et ce qui se passe lorsque vous vous trompez, se trouve dans notre guide d'authentification proxy nodriver — les mécanismes sont partagés, donc il n'y a aucune raison de les reproduire deux fois.
Solution 3 : une extension proxy-auth, et SOCKS5
La voie que le problème #10 soutient est une extension Chrome générée : un manifeste Manifest V3 plus un worker qui définit le proxy et répond à chrome.webRequest.onAuthRequired, chargé avec --load-extension sous --headless=new. Il gère tout type de proxy, y compris SOCKS5, ce qui est important car SOCKS5 authentifié ne fonctionne jamais via le drapeau — Chromium n'a pas de support de nom d'utilisateur/mot de passe pour SOCKS5 (bug Chromium 40829748). L'alternative pour SOCKS5 est un relais local qui détient les identifiants et offre un point de terminaison sans authentification sur 127.0.0.1, couvert dans le guide du relais proxy. Chaque plan QuantumProxies propose à la fois des points de terminaison HTTP et SOCKS5, donc vous pouvez souvent contourner tout le problème en utilisant HTTP, qui gère proprement l'authentification Basic.
Ce qui diffère réellement de nodriver
Le fork n'est pas cosmétique. Dans les benchmarks publics opposant nodriver, zendriver, Selenium et Playwright aux systèmes anti-bot modernes, la famille nodriver/zendriver était la plus performante pour passer, avec zendriver légèrement en tête grâce aux corrections en amont non fusionnées qu'il porte. Pratiquement, les différences qui affectent le travail avec les proxies sont : un suivi des problèmes actif où les problèmes sont triés, un rythme de publication plus régulier, des contextes de navigateur isolés que vous pouvez créer par session, et des commodités tout-en-un conservées de nodriver. Rien de tout cela ne comble le problème d'authentification — mais cela signifie que les corrections arrivent plus rapidement lorsqu'elles le font, et cela rend zendriver le fork le plus facile à exécuter pour de nombreuses sessions parallèles. Pour faire tourner et regrouper les sorties à travers ces contextes concurrents, nos notes sur la gestion des pools de proxies s'appliquent à zendriver sans changement, que vous passiez par des proxies rotatifs ou que vous fixiez des sessions persistantes pour les flux connectés.
Une clarification : une crate Rust distincte également nommée zendriver existe sur docs.rs. Elle n'est pas liée au fork Python discuté ici — si vous effectuez du scraping en Python, pip install zendriver est celui que vous voulez.
Questions fréquemment posées
Comment utiliser un proxy avec zendriver ?
Passez l'adresse via browser_args lorsque vous appelez zendriver.start() : browser_args=["--proxy-server=host:port"]. Cela route tout le trafic via le proxy pour un point de terminaison non authentifié. Pour un proxy authentifié, vous ne pouvez pas mettre user:pass dans le drapeau — listez votre IP, utilisez un gestionnaire CDP Fetch.AuthRequired, ou chargez une extension proxy-auth.
Zendriver prend-il en charge les proxies authentifiés ?
Pas via un paramètre intégré — le problème est suivi dans les problèmes #10 et #208. Chromium ignore les identifiants dans le drapeau proxy, donc vous authentifiez autrement : liste blanche d'IP chez le fournisseur, un gestionnaire CDP qui répond au défi en cours de processus, une extension Chrome générée, ou un relais local qui détient les identifiants pour vous.
Quelle est la différence entre nodriver et zendriver ?
zendriver est un fork communautaire de nodriver avec la même architecture CDP, les mêmes objectifs de discrétion et la même API. La différence réside dans la maintenance : zendriver accepte les problèmes et les pull requests sur GitHub, intègre les corrections de bugs non fusionnées en amont, et publie plus régulièrement. L'authentification des proxies se comporte de manière identique dans les deux — les solutions de ce guide fonctionnent pour l'un ou l'autre.
Zendriver peut-il utiliser un proxy SOCKS5 authentifié ?
Pas via le drapeau, car Chromium n'a jamais implémenté l'authentification nom d'utilisateur/mot de passe pour SOCKS5 (bug Chromium 40829748), et zendriver hérite de cela. Utilisez une extension proxy-auth, exécutez un relais local qui ajoute les identifiants, ou pointez zendriver vers le point de terminaison HTTP de votre fournisseur à la place — l'authentification proxy HTTP Basic fonctionne de manière fiable là où l'authentification SOCKS5 ne fonctionne pas.
zendriver est le plus affûté des deux forks pour construire aujourd'hui, mais il vous pose le même problème de proxy authentifié que nodriver. Liste blanche lorsque votre IP est fixe, répondez au défi CDP lorsqu'elle ne l'est pas, et gardez l'extension et le relais comme solutions de secours. Quel que soit votre choix, l'IP de sortie fait le gros du travail — un fork maintenu sur une adresse de centre de données brûlée est toujours bloqué.