Zendriver Proxy Met Authenticatie: Installatie en Oplossingen

Zendriver is de door de gemeenschap onderhouden fork van nodriver — sneller om te repareren, maar met dezelfde geauthenticeerde-proxy kloof. Hier is de volledige proxy-installatie, wat daadwerkelijk verschilt, en de oplossingen die user:pass werkend krijgen.

Een zendriver proxy is precies zo opgezet als een nodriver — wat zowel goed nieuws als een addertje onder het gras is. zendriver (het cdpdriver/zendriver project) is de door de gemeenschap onderhouden fork van nodriver: een async-first, ongedetecteerd browser-automatiseringsframework dat Chrome rechtstreeks over het DevTools Protocol aanstuurt, zonder WebDriver in zicht. Het bestaat omdat de enige beheerder van nodriver zelden externe oplossingen samenvoegde, dus de gemeenschap heeft een fork gemaakt om bugfixes te accepteren, functies toe te voegen en problemen op GitHub aan te pakken. Wat het niet heeft opgelost, zijn geauthenticeerde proxies. Deze gids behandelt de volledige proxy-installatie, wat echt verschilt van nodriver, en de oplossingen die user:pass werkend krijgen.

Installatie en basis proxy-installatie

Installatie is één regel — pip install zendriver — en de API spiegelt nodriver bijna symbool voor symbool, dus import zendriver as zd is vaak de enige verandering bij het overzetten van een script. Een niet-geauthenticeerde proxy gaat via browser_args, en het verzoek verlaat het proxy IP:

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())

Dat werkt omdat het slechts een Chrome-vlag is. Voeg inloggegevens toe — --proxy-server=http://USER:PASS@host:port — en Chromium negeert stilletjes het USER:PASS@ gedeelte, de proxy antwoordt met 407, en er verschijnt een native inlogdialoog die zendriver niet kan invullen. Dit is een Chrome-beperking, geen zendriver-bug, dus geen versie-update zal de vlag een wachtwoord laten accepteren.

De zendriver proxy authenticatie kloof

De kloof wordt openlijk gevolgd in zendriver's issues — een feature request thread (#10) en een speciale "Proxy met auth" issue (#208) — wat op zich al een verschil is dat het vermelden waard is: bij nodriver is dezelfde vraag begraven in een discussie die de beheerder één keer beantwoordde en verder ging. Een gebruiker op issue #10 vat de stand van zaken bot samen: de proxyserveroptie heeft geen manier om te authenticeren, dus gebruiken ze in plaats daarvan een proxy-extensie en dat werkt prima. Dat is de in de praktijk geteste consensus, en het wijst direct naar dezelfde drie oplossingen waar nodriver-gebruikers op vertrouwen.

Oplossing 1: IP-whitelisting (de eenvoudigste)

Als je taak draait vanaf een machine met een stabiel openbaar IP, sla dan inloggegevens volledig over. Registreer het uitgaande IP in je provider dashboard en de gateway authenticeert je op basis van het bronadres — de zendriver code blijft het eenvoudige --proxy-server fragment hierboven, zonder enige auth-logica. Elk QuantumProxies-plan ondersteunt IP-whitelisting naast user:pass, wat het de standaardaanbeveling maakt wanneer je IP vast is. De enige beperking is dat het een machine authenticeert, niet een script, dus vluchtige runners en containers achter NAT hebben een van de volgende twee methoden nodig.

Oplossing 2: beantwoord de uitdaging via CDP

Omdat zendriver het DevTools Protocol op dezelfde manier blootstelt als nodriver, kun je de auth-uitdaging in-process onderscheppen: registreer RequestPaused en AuthRequired handlers, schakel vervolgens het Fetch domein in met handle_auth_requests=True en antwoord met continue_with_auth. De twee niet voor de hand liggende regels zijn identiek aan nodriver — voeg de handlers voordat je het domein inschakelt toe, en vuur reacties af met asyncio.create_task zodat het wachten erop de lus niet kan vastlopen:

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())

De volledige uitleg waarom de volgorde van handlers ertoe doet, en wat er gebeurt als je het verkeerd doet, staat in onze nodriver proxy authenticatie gids — de mechanica is gedeeld, dus er is geen reden om ze twee keer te reproduceren.

Oplossing 3: een proxy-auth extensie, en SOCKS5

De route die issue #10 aanbeveelt is een gegenereerde Chrome-extensie: een Manifest V3 manifest plus een worker die de proxy instelt en chrome.webRequest.onAuthRequired beantwoordt, geladen met --load-extension onder --headless=new. Het behandelt elk proxytype, inclusief SOCKS5, wat van belang is omdat geauthenticeerde SOCKS5 nooit werkt via de vlag — Chromium heeft geen gebruikersnaam/wachtwoord ondersteuning voor SOCKS5 (Chromium bug 40829748). Het alternatief voor SOCKS5 is een lokale relay die de inloggegevens vasthoudt en een geen-auth eindpunt biedt op 127.0.0.1, behandeld in de proxy relay gids. Elk QuantumProxies-plan levert zowel HTTP als SOCKS5 eindpunten, dus je kunt vaak het hele probleem omzeilen door HTTP te gebruiken, dat Basic auth netjes afhandelt.

Wat daadwerkelijk verschilt van nodriver

De fork is niet cosmetisch. In openbare benchmarks waarin nodriver, zendriver, Selenium en Playwright worden getest tegen moderne anti-bot systemen, was de nodriver/zendriver familie de sterkste in het doorkomen, waarbij zendriver voorop liep dankzij niet-gesamengestelde upstream fixes die het meedraagt. Praktisch gezien zijn de verschillen die invloed hebben op proxywerk: een actieve issue tracker waar problemen worden getrieerd, een stabielere release-cadans, geïsoleerde browsercontexten die je per sessie kunt opstarten, en ingebouwde gemakken behouden van nodriver. Geen van dat sluit de auth kloof — maar het betekent dat oplossingen sneller landen wanneer ze dat doen, en het maakt zendriver de gemakkelijkere fork om veel parallelle sessies op te draaien. Voor het roteren en poolen van exits over die gelijktijdige contexten, zijn onze notities over proxy pool management van toepassing op zendriver ongewijzigd, of je nu routeert via roterende proxies of sticky sessies vastzet voor ingelogde stromen.

Eén verduidelijking: een aparte Rust crate ook genaamd zendriver bestaat op docs.rs. Het is niet gerelateerd aan de Python fork die hier wordt besproken — als je in Python aan het scrapen bent, is pip install zendriver degene die je wilt.

Veelgestelde vragen

Hoe gebruik ik een proxy met zendriver?

Geef het adres door via browser_args wanneer je zendriver.start() aanroept: browser_args=["--proxy-server=host:port"]. Dat routeert al het verkeer via de proxy voor een niet-geauthenticeerd eindpunt. Voor een geauthenticeerde proxy kun je user:pass niet in de vlag zetten — whitelist je IP, gebruik een CDP Fetch.AuthRequired handler, of laad een proxy-auth extensie.

Ondersteunt zendriver geauthenticeerde proxies?

Niet via een ingebouwde parameter — de kloof wordt gevolgd in issues #10 en #208. Chromium negeert inloggegevens in de proxy vlag, dus je authenticeert op een andere manier: IP-whitelisting bij de provider, een CDP handler die de uitdaging in-process beantwoordt, een gegenereerde Chrome-extensie, of een lokale relay die de inloggegevens voor je vasthoudt.

Wat is het verschil tussen nodriver en zendriver?

zendriver is een door de gemeenschap onderhouden fork van nodriver met dezelfde CDP-architectuur, stealth doelen en API. Het verschil is het onderhoud: zendriver neemt issues en pull requests op GitHub aan, levert niet-gesamengestelde upstream bugfixes, en brengt vaker releases uit. Proxy-authenticatie gedraagt zich identiek in beide — de oplossingen in deze gids werken voor beide.

Kan zendriver een geauthenticeerde SOCKS5 proxy gebruiken?

Niet via de vlag, omdat Chromium nooit SOCKS5 gebruikersnaam/wachtwoord authenticatie heeft geïmplementeerd (Chromium bug 40829748), en zendriver dat erft. Gebruik een proxy-auth extensie, draai een lokale relay die de inloggegevens toevoegt, of wijs zendriver naar het HTTP eindpunt van je provider — HTTP Basic proxy auth werkt betrouwbaar waar SOCKS5 auth dat niet doet.

zendriver is de scherpere van de twee forks om vandaag op te bouwen, maar het geeft je hetzelfde geauthenticeerde-proxy probleem als nodriver. Whitelist wanneer je IP vast is, beantwoord de CDP uitdaging wanneer dat niet het geval is, en houd de extensie en relay als back-ups. Welke je ook kiest, het exit IP doet het zware werk — een onderhouden fork op een verbrande datacenteradres wordt nog steeds geblokkeerd.

Geef zendriver schone residentiële exits