Zendriver Proxy Con Autenticazione: Configurazione e Soluzioni
Zendriver è il fork mantenuto dalla comunità di nodriver — più veloce nelle correzioni, ma con lo stesso problema di autenticazione del proxy. Ecco la configurazione completa del proxy, cosa cambia realmente e le soluzioni che fanno funzionare user:pass.
Un zendriver proxy è configurato esattamente come uno nodriver — il che è sia una buona notizia che un problema. zendriver (il progetto cdpdriver/zendriver) è il fork mantenuto dalla comunità di nodriver: un framework di automazione del browser asincrono e non rilevabile che guida Chrome direttamente tramite il DevTools Protocol, senza WebDriver. Esiste perché l'unico manutentore di nodriver raramente integrava correzioni esterne, quindi la comunità ha creato un fork per accettare correzioni di bug, aggiungere funzionalità e affrontare problemi su GitHub. Ciò che non ha risolto sono i proxy autenticati. Questa guida copre la configurazione completa del proxy, cosa differisce realmente da nodriver e le soluzioni che fanno funzionare user:pass.
Installazione e configurazione di base del proxy
L'installazione è una sola riga — pip install zendriver — e l'API rispecchia nodriver quasi simbolo per simbolo, quindi import zendriver as zd è spesso l'unico cambiamento quando si porta uno script. Un proxy non autenticato passa attraverso browser_args, e la richiesta esce dall'IP del 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())Funziona perché è solo un flag di Chrome. Aggiungi le credenziali — --proxy-server=http://USER:PASS@host:port — e Chromium scarta silenziosamente la parte USER:PASS@, il proxy risponde 407, e appare una finestra di dialogo di accesso nativa che zendriver non può compilare. Questa è una limitazione di Chrome, non un bug di zendriver, quindi nessun aggiornamento di versione farà accettare al flag una password.
Il problema di autenticazione del proxy zendriver
Il problema è apertamente tracciato nei problemi di zendriver — un thread di richiesta di funzionalità (#10) e un problema dedicato "Proxy con auth" (#208) — che è esso stesso una differenza degna di nota: su nodriver la stessa domanda è sepolta in una discussione che il manutentore ha risposto una volta e poi ha lasciato. Un utente sul problema #10 riassume lo stato delle cose in modo schietto: l'opzione del server proxy non ha modo di autenticarsi, quindi usano un'estensione proxy invece e funziona bene. Questo è il consenso testato sul campo, e punta direttamente alle stesse tre soluzioni su cui si affidano gli utenti di nodriver.
Soluzione 1: Whitelisting IP (la più semplice)
Se il tuo lavoro viene eseguito da una macchina con un IP pubblico stabile, salta completamente le credenziali. Registra l'IP di uscita nel dashboard del tuo provider e il gateway ti autentica per indirizzo sorgente — il codice zendriver rimane il semplice snippet --proxy-server sopra, senza logica di autenticazione. Ogni piano QuantumProxies supporta il whitelisting IP insieme a user:pass, il che lo rende la raccomandazione predefinita ogni volta che il tuo IP è fisso. L'unico limite è che autentica una macchina, non uno script, quindi i runner effimeri e i container dietro NAT necessitano di uno dei due metodi successivi.
Soluzione 2: rispondere alla sfida tramite CDP
Poiché zendriver espone il DevTools Protocol nello stesso modo di nodriver, puoi intercettare la sfida di autenticazione in-process: registra i gestori RequestPaused e AuthRequired, quindi abilita il dominio Fetch con handle_auth_requests=True e rispondi con continue_with_auth. Le due regole non ovvie sono identiche a nodriver — aggiungi i gestori prima di abilitare il dominio, e invia le risposte con asyncio.create_task in modo che aspettarle non possa bloccare il loop:
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())La guida completa sul perché l'ordine dei gestori è importante, e cosa succede quando sbagli, si trova nella nostra guida all'autenticazione del proxy nodriver — le meccaniche sono condivise, quindi non c'è motivo di riprodurle due volte.
Soluzione 3: un'estensione proxy-auth e SOCKS5
Il percorso che il problema #10 approva è un'estensione Chrome generata: un manifesto Manifest V3 più un worker che imposta il proxy e risponde a chrome.webRequest.onAuthRequired, caricato con --load-extension sotto --headless=new. Gestisce qualsiasi tipo di proxy, incluso SOCKS5, il che è importante perché SOCKS5 autenticato non funziona mai tramite il flag — Chromium non ha supporto per nome utente/password per SOCKS5 (bug di Chromium 40829748). L'alternativa per SOCKS5 è un relay locale che mantiene le credenziali e offre un endpoint senza autenticazione su 127.0.0.1, coperto nella guida al relay del proxy. Ogni piano QuantumProxies fornisce sia endpoint HTTP che SOCKS5, quindi spesso puoi evitare l'intero problema usando HTTP, che gestisce l'autenticazione Basic in modo pulito.
Cosa differisce realmente da nodriver
Il fork non è cosmetico. Nei benchmark pubblici che mettono a confronto nodriver, zendriver, Selenium e Playwright contro i moderni sistemi anti-bot, la famiglia nodriver/zendriver è stata la più forte nel superare, con zendriver che ha avuto un leggero vantaggio grazie alle correzioni non integrate a monte che porta. Praticamente, le differenze che influenzano il lavoro con i proxy sono: un tracker di problemi attivo dove i problemi vengono triage, una cadenza di rilascio più stabile, contesti del browser isolati che puoi avviare per sessione, e comodità incluse mantenute da nodriver. Nessuna di queste chiude il problema di autenticazione — ma significa che le correzioni arrivano più velocemente quando lo fanno, e rende zendriver il fork più facile da eseguire su molte sessioni parallele. Per ruotare e raggruppare le uscite attraverso quei contesti concorrenti, le nostre note su gestione dei pool di proxy si applicano a zendriver invariato, sia che instradi attraverso proxy rotanti o fissi sessioni sticky per flussi connessi.
Una chiarificazione: esiste anche un crate Rust separato chiamato zendriver su docs.rs. Non è correlato al fork Python discusso qui — se stai facendo scraping in Python, pip install zendriver è quello che vuoi.
Domande frequenti
Come uso un proxy con zendriver?
Passa l'indirizzo attraverso browser_args quando chiami zendriver.start(): browser_args=["--proxy-server=host:port"]. Questo instrada tutto il traffico attraverso il proxy per un endpoint non autenticato. Per un proxy autenticato non puoi mettere user:pass nel flag — whitelista il tuo IP, usa un gestore Fetch.AuthRequired CDP, o carica un'estensione proxy-auth.
Zendriver supporta i proxy autenticati?
Non attraverso un parametro integrato — il problema è tracciato nei problemi #10 e #208. Chromium ignora le credenziali nel flag del proxy, quindi autentichi in un altro modo: whitelisting IP presso il provider, un gestore CDP che risponde alla sfida in-process, un'estensione Chrome generata, o un relay locale che mantiene le credenziali per te.
Qual è la differenza tra nodriver e zendriver?
Zendriver è un fork mantenuto dalla comunità di nodriver con la stessa architettura CDP, obiettivi di furtività e API. La differenza è la manutenzione: zendriver accetta problemi e richieste di pull su GitHub, fornisce correzioni di bug non integrate a monte e rilascia più regolarmente. L'autenticazione del proxy si comporta in modo identico in entrambi — le soluzioni in questa guida funzionano per entrambi.
Zendriver può usare un proxy SOCKS5 autenticato?
Non tramite il flag, perché Chromium non ha mai implementato l'autenticazione nome utente/password per SOCKS5 (bug di Chromium 40829748), e zendriver eredita questo. Usa un'estensione proxy-auth, esegui un relay locale che aggiunge le credenziali, o punta zendriver all'endpoint HTTP del tuo provider — l'autenticazione proxy HTTP Basic funziona in modo affidabile dove l'autenticazione SOCKS5 no.
Zendriver è il più affilato dei due fork su cui costruire oggi, ma ti consegna lo stesso problema di proxy autenticato che fa nodriver. Whitelista quando il tuo IP è fisso, rispondi alla sfida CDP quando non lo è, e mantieni l'estensione e il relay come soluzioni di riserva. Qualunque tu scelga, l'IP di uscita fa il lavoro pesante — un fork mantenuto su un indirizzo datacenter bruciato viene comunque bloccato.