Playwright SOCKS5 Proxy Authenticatie: Waarom Het Faalt, 4 Oplossingen

Playwright accepteert een socks5:// server en weigert vervolgens je gebruikersnaam en wachtwoord. De beperking ligt bij Chromium, niet bij Playwright, en het probleem is al open sinds 2021 — hier zijn de vier manieren om het te omzeilen, gerangschikt.

Playwright SOCKS5 proxy authenticatie bestaat niet, en dat van tevoren weten bespaart een avond. Geef een socks5:// server samen met een gebruikersnaam en wachtwoord en Playwright weigert voordat de browser ooit navigeert. De feature-aanvraag waar iedereen op terechtkomt, microsoft/playwright#10567, werd geopend in november 2021, is nog steeds open en draagt nog steeds het label P3-collecting-feedback. De beperking is niet aan Playwright om op te lossen: het zit in Chromium. Deze post toont de exacte foutmeldingen, legt uit waarom geen enkele extensie of configuratievlag je redt, en geeft vier oplossingen — de eenregelige HTTP-wissel, IP-whitelisting, een lokale relay en Firefox.

De fout die je zoekt

Elke versie van dit probleem levert een van de twee strings op. In Node krijg je Error: Browser does not support socks5 proxy authentication; in Python, oudere releases prefixen het met playwright._impl._api_types.Error: en nieuwere met playwright._impl._errors.Error:. Het bericht is hetzelfde en wordt bij de start gegooid, niet bij navigatie:

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

Er is een stillere variant. Als je de credentialvelden weglaat en ze in de serverstring stopt — socks5://USER:PASS@host:1080 — wordt er niets gegooid. Chromium negeert simpelweg het userinfo-gedeelte van de URL, probeert een niet-geauthenticeerde handshake, en de gateway wijst het af. Je ziet dan net::ERR_SOCKS_CONNECTION_FAILED of een eenvoudige timeout bij de eerste goto(), wat mensen op jacht stuurt naar netwerkbugs die er niet zijn.

Waar Playwright SOCKS5 proxy authenticatie daadwerkelijk breekt

Playwright's eigen documentatie is expliciet: de velden username en password bij de proxy-optie worden beschreven als credentials om te gebruiken "als HTTP proxy authenticatie vereist". SOCKS wordt alleen ondersteund als een schema. Onderliggend heeft Chromium nooit de gebruikersnaam/wachtwoord sub-onderhandeling van RFC 1929 voor SOCKS5 geïmplementeerd, wat de reden is waarom de Chromium issue tracker vermelding over SOCKS5 authenticatie (40323993) jaren aan opmerkingen heeft verzameld, waarom de SwitchyOmega extensie gebruikers waarschuwt zodra ze SOCKS5 met credentials selecteren, en waarom Brave en Edge zich identiek gedragen. Het is één engine, één gat, geërfd door alles wat erop is gebouwd.

Dit is ook de reden waarom de truc die Selenium-gebruikers redt hier niet helpt. Een Manifest V3-extensie kan een proxy-uitdaging beantwoorden via chrome.webRequest.onAuthRequired, maar die haak vuurt op HTTP 407 Proxy Authentication Required reacties. Een SOCKS5-handshake is een byte-level onderhandeling op de socket voordat er enige HTTP bestaat, dus er is geen gebeurtenis om te onderscheppen. En verwar de contextoptie httpCredentials niet met proxy-auth: het beantwoordt 401 uitdagingen van de website die je bezoekt, nooit de proxy. Voor het volledige beeld over stealth frameworks, onze kaart van geauthenticeerde proxies in anti-detect frameworks dekt wie wat ondersteunt.

Oplossing 1: gebruik het HTTP-eindpunt van dezelfde gateway

Dit is de oplossing voor ongeveer negen van de tien gebruikers, en het is één regel. Serieuze providers stellen dezelfde IP-pool bloot via beide protocollen op verschillende poorten — elk QuantumProxies-plan levert HTTP en SOCKS5 eindpunten met dezelfde credentials en dezelfde sessiesyntaxis. Wissel het schema en de poort, houd de rest hetzelfde, en Playwright's native credentialvelden doen hun werk:

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

Je verliest niets meetbaars. Voor browserverkeer opent een HTTP-proxy een CONNECT tunnel en vervoert dezelfde versleutelde bytes als een SOCKS5-tunnel zou doen; de verschillen tussen de twee protocollen zijn van belang voor UDP en niet-HTTP verkeer, niet voor een paginalading. Onze uiteenzetting van SOCKS5 versus HTTP proxies bevat de details. En omdat het proxy-object ook wordt geaccepteerd door newContext(), geven dezelfde credentials je per-context rotatie precies zoals beschreven in onze Playwright proxy integratie gids.

Oplossing 2: IP-whitelisting houdt socks5:// in leven

Als je echt het SOCKS5-schema nodig hebt — een proxy die alleen SOCKS spreekt, een toolchain die het aanneemt — authenticeer dan de machine in plaats van het verzoek. Registreer het publieke IP van de scraper bij je provider, verwijder de credentials, en Chromium is tevreden omdat er niets te onderhandelen valt:

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

Whitelisting authenticeert een machine, niet een script, en dat is de hele afweging. Een VPS of een kantooruitgang met een stabiel adres werkt perfect; vluchtige CI-runners, autoschaalbare containers en alles achter een roterende NAT zullen falen op het moment dat het adres verandert. Verifieer de uitgang voordat je een run vertrouwt — een stilzwijgende directe verbinding ziet er precies zo uit als een werkende proxy totdat je doel begint je eigen IP te blokkeren. Onze gratis IP-kwaliteitschecker vertelt je wat de uitgang daadwerkelijk is, niet alleen dat deze heeft gereageerd.

Vergelijking van vier oplossingen voor Playwright SOCKS5 proxy authenticatie: HTTP-eindpunt, IP-whitelisting, lokale relay en Firefox — De HTTP-eindpuntwissel kost één regel en geen capaciteit. Alles rechts daarvan koopt je het socks5:// schema tegen een prijs.

Oplossing 3: een lokale relay die de credentials verwijdert

Wanneer het IP niet kan worden gewhitelist en de provider geen HTTP-poort heeft, plaats een vertaler voor de browser. Het patroon is altijd hetzelfde: een lokale luisteraar zonder authenticatie stuurt door naar het upstream SOCKS5-eindpunt met bijgevoegde credentials. Met gost is dat een enkel commando:

# 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' }

Twee regels. Bind de luisteraar aan 127.0.0.1, nooit 0.0.0.0 — een no-auth proxy bereikbaar vanaf het internet is een open relay die binnen enkele uren zal worden gevonden en misbruikt. En behandel de relay als een proces dat je moet superviseren: als het sterft, valt Chromium terug op een verbindingsfout in plaats van een directe aanvraag, wat op zijn minst luid is. Deze aanpak is zo gangbaar geworden dat beoefenaars kleine speciaal gebouwde relays publiceren; we vergelijken de opties in onze gids voor SOCKS5 auth relay tools.

Oplossing 4: gebruik Firefox in plaats van Chromium

Firefox implementeert SOCKS5 gebruikersnaam/wachtwoord authenticatie native, wat het verschil is waar de Playwright issue-thread steeds op wijst. Wissel het browsertype en de fout verdwijnt:

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

Doe de verificatiestap, elke keer. Dat Playwright niet gooit, is geen bewijs dat de credentials zijn gebruikt — alleen een IP-echo is dat. En wees duidelijk over wat je koopt: een andere rendering engine, een ander vingerafdrukoppervlak, en een stealth-ecosysteem dat sterk naar Chromium neigt. Als je doelwit Firefox al accepteert, is dit gratis. Als je Chromium hebt gekozen om anti-bot redenen, is het wisselen van engines om een proxyprobleem op te lossen de verkeerde afweging — neem oplossing 1 en houd je browser.

De beslissing, in één regel elk

Provider heeft een HTTP-poort: gebruik het. Eén regel, native auth, dezelfde uitgangen, geen extra proces.
Vast openbaar IP: whitelist het en houd socks5:// zonder credentials.
Geen van beide: draai een lokale relay gebonden aan loopback en wijs Playwright naar 127.0.0.1.
Al op Firefox: geef de credentials door en verifieer het exit-IP eenmaal.
Nooit: credentials binnen de server string. Chromium laat ze zonder een woord vallen.

Checklist van Playwright SOCKS5 proxy configuraties die werken in Chromium versus configuraties die gooien of stil falen — Chromium accepteert het SOCKS5-schema en nooit de credentials. Alles rechts van deze lijst faalt — de helft ervan zonder foutmelding.

Veelgestelde vragen

Ondersteunt Playwright SOCKS5 proxy authenticatie?

Niet met Chromium. Playwright's proxy-optie documenteert gebruikersnaam en wachtwoord als HTTP(S) credentials, en Chromium heeft geen SOCKS5 gebruikersnaam/wachtwoord implementatie om ze aan te geven, dus de start gooit. Firefox in Playwright ondersteunt het wel. De tracking issue, microsoft/playwright#10567, is open sinds november 2021 zonder geplande oplossing.

Wat betekent 'Browser does not support socks5 proxy authentication'?

Het betekent dat je credentials hebt doorgegeven samen met een socks5:// server aan een Chromium-start. Playwright valideert de combinatie en weigert in plaats van een browser te openen die ze stilzwijgend zou negeren. Verhuis naar de HTTP-poort van de gateway en houd de credentialvelden, of authenticeer via IP-whitelist en verwijder ze volledig.

Hoe gebruik ik een SOCKS5 proxy met Playwright in Python?

Geef proxy={"server": "socks5://host:port"} door zonder gebruikersnaam of wachtwoord, en laat de provider het publieke IP van je machine autoriseren. Als het IP niet stabiel is, gebruik dan het HTTP-eindpunt van dezelfde gateway met credentials, of stuur door via een lokale relay. Bevestig altijd de uitgang tegen een IP-echo-eindpunt.

Kan een Chrome-extensie SOCKS5-authenticatie toevoegen?

Nee. De extensietruc die wordt gebruikt voor geauthenticeerde HTTP-proxies vertrouwt op chrome.webRequest.onAuthRequired, dat vuurt op HTTP 407-reacties. SOCKS5 authenticeert tijdens de socket-handshake, voordat er enige HTTP-aanvraag bestaat, dus geen enkele extensie-API kan het zien. Proxy-switcher-extensies waarschuwen voor deze beperking om dezelfde reden.

Is SOCKS5 sneller dan HTTP voor Playwright-scraping?

Niet betekenisvol. HTTPS-verkeer door een HTTP-proxy gebruikt een CONNECT tunnel, dus beide protocollen vervoeren dezelfde versleutelde stroom met vergelijkbare overhead. De echte voordelen van SOCKS5 zijn UDP-ondersteuning en protocolneutraliteit, waarvan geen enkele door een browserpaginalading wordt gebruikt. Kies welk eindpunt dan ook dat schoon authenticeert.

De korte versie: stop met proberen om Chromium iets te laten doen wat het nooit heeft gedaan. Verplaats de taak naar het HTTP-eindpunt, of whitelist en verwijder de credentials — en als je socks5:// moet behouden met een roterende egress, plaats een relay in het midden in plaats van een workaround in je code. Zodra authenticatie uit de weg is, is het ding dat bepaalt of de run slaagt de pool erachter: residential exits in meer dan 200 landen, met per-verzoek rotatie of sticky sessies wanneer een flow één identiteit nodig heeft.

Krijg HTTP en SOCKS5 eindpunten op één plan