Geauthenticeerde Proxies in Anti-Detect Browsers: Ondersteuningskaart 2026

Chromium heeft nooit inloggegevens op SOCKS5 geaccepteerd, en een launcher die alleen --proxy-server doorgeeft heeft niemand om de auth prompt te beantwoorden. Hier is welke framework user:pass accepteert, welke een helper nodig heeft, en welke een doodlopende weg is.

Een geauthenticeerde proxy in een anti-detect browser faalt op een van drie manieren, en de symptomen veranderen nooit: een Chrome inloggegevens pop-up die niets kan sluiten, een 407 op elk verzoek, of een pagina die perfect laadt vanaf je eigen IP. De proxy is zelden de schuldige. Chromium heeft nooit een gebruikersnaam en wachtwoord op SOCKS5 geaccepteerd, en een launcher die alleen --proxy-server naar de binary doorstuurt heeft niemand om de auth-uitdaging van de browser te beantwoorden. Dit is de kaart van 2026: welke frameworks nemen user:pass native, welke hebben een helper nodig, en waar de weg eindigt.

Eén oorzaak, drie symptomen

Chromium's proxy stack heeft een slot voor een SOCKS5 serveradres en geen slot voor inloggegevens. Het verzoek staat al jaren op de Chromium tracker als issue 40323993, de SwitchyOmega extensie logde de bevestiging van het Chrome-team in zijn eigen issue #1455, en ChromeDriver gebruikers die hetzelfde nastreven worden naar crbug 40829748 verwezen. Firefox is de uitzondering — het authenticeert SOCKS5 native — daarom staat Camoufox in een andere kolom dan al het andere hier. Als de protocolsplit nieuw voor je is, begin dan met SOCKS5 vs HTTP proxies.

HTTP en HTTPS proxies zijn een ander verhaal: de inloggegevens werken, alleen nooit vanaf de command line. Chrome beantwoordt een 407 door een auth-uitdaging te verhogen, en iets moet reageren — in een normale browser, de pop-up die je ziet. In automatisering moet het een geladen extensie zijn, een CDP handler die is geabonneerd op Fetch.authRequired, of het framework zelf. Alles wat alleen een launch flag doorgeeft laat de uitdaging onbeantwoord, en dat is de vastgelopen pagina die mensen blijven screenshotten. Het credential-formaat deel wordt behandeld in het oplossen van 407 proxy authenticatie vereist.

Ondersteuning voor geauthenticeerde proxy's in anti-detect browsers: de kaart van 2026

Drie emmers: inloggegevens geaccepteerd door de API, inloggegevens alleen geaccepteerd via een helper die je bouwt, en een limiet van de engine die geen enkele configuratie zal verplaatsen.

Werkt native met user:pass

Heeft een extensie, een relay of een CDP handler nodig

Werkt nooit: SOCKS5 met inloggegevens

Driekolomsvergelijking van ondersteuning voor geauthenticeerde proxies: frameworks met native gebruikersnaam en wachtwoordondersteuning, frameworks die een extensie of CDP handler nodig hebben, en SOCKS5 met inloggegevens die nooit werkt in Chromium
Zelfde Chromium kern, drie uitkomsten. De eerste kolom is een configuratiewijziging, de tweede is een bouwstap, en de derde is een engine beperking die je omzeilt.

Workaround 1: gebruik het HTTP endpoint van de provider

Dit lost de meeste van de hierboven gelinkte threads op, en het kost niets. Als je provider dezelfde pool over HTTP en SOCKS5 blootstelt, wijs de browser dan naar de HTTP gateway en inloggegevens worden een ondersteunde parameter in plaats van een niet-ondersteunde. Proxy-zijde DNS komt gratis: Chromium delegeert altijd naamresolutie aan een HTTP proxy. Elk QuantumProxies plan bedient HTTP en SOCKS5 vanaf dezelfde gateway op dezelfde inloggegevens, dus overschakelen is een schema wijziging, geen nieuwe bestelling.

# Playwright, Patchright and Camoufox all take the same proxy object.
# Swap the import line; the proxy config does not change.
from playwright.sync_api import sync_playwright   # or: from patchright.sync_api import ...

PROXY = {
    "server": "http://gate.quantumproxies.io:PORT",  # HTTP endpoint, not socks5://
    "username": "USER",
    "password": "PASS",
}

with sync_playwright() as p:
    browser = p.chromium.launch(proxy=PROXY, headless=False)
    page = browser.new_page()
    page.goto("https://httpbin.org/ip")
    print(page.inner_text("pre"))
    browser.close()

# Camoufox: same dict, plus geoip so timezone/locale/WebRTC follow the exit IP.
# pip install -U "camoufox[geoip]"
# with Camoufox(geoip=True, proxy=PROXY) as browser: ...

Workaround 2: IP whitelisting

Het schoonste antwoord is om de auth stap te verwijderen. Met IP whitelisting registreer je het publieke IP van de machine die de browser draait en de gateway autoriseert het op basis van bronadres — geen gebruikersnaam, geen wachtwoord, geen pop-up, niets voor het framework om te beantwoorden. Elk probleem op deze pagina verdwijnt in één keer, SOCKS5 inbegrepen, omdat er geen inloggegevens meer zijn om door te geven. Het is geschikt voor een vaste scraping server of een container achter een statisch uitgaand IP, en ongeschikt voor laptops op wisselende netwerken. Whitelisting staat naast user:pass op elk QuantumProxies plan, zodat productie kan worden gewhitelist terwijl ontwikkeling inloggegevens behoudt.

Whitelist je IP op een 90M+ residentiële pool

Workaround 3: een gegenereerde Chrome auth extensie, of een CDP handler

Als je inloggegevens moet behouden op een Chromium framework dat ze niet accepteert, moet iets binnen de browser de uitdaging beantwoorden. Optie één is een extensie die de proxy instelt en reageert op onAuthRequired — precies wat SeleniumBase bouwt achter zijn --proxy flag. Onder Manifest V3 zijn de twee permissies die het laten werken webRequest en webRequestAuthProvider; mis de tweede en de listener wordt nooit geactiveerd.

// manifest.json (MV3) — webRequestAuthProvider is the one people forget
{
  "name": "proxy-auth",
  "version": "1.0",
  "manifest_version": 3,
  "permissions": ["proxy", "webRequest", "webRequestAuthProvider"],
  "host_permissions": ["<all_urls>"],
  "background": { "service_worker": "background.js" }
}

// background.js
const HOST = "gate.quantumproxies.io";
const PORT = 8080;              // your gateway port
const USER = "USER", PASS = "PASS";

chrome.proxy.settings.set({
  value: {
    mode: "fixed_servers",
    rules: { singleProxy: { scheme: "http", host: HOST, port: PORT } },
  },
  scope: "regular",
});

chrome.webRequest.onAuthRequired.addListener(
  () => ({ authCredentials: { username: USER, password: PASS } }),
  { urls: ["<all_urls>"] },
  ["blocking"],
);

Twee kanttekeningen. Extensies laden niet in elke headless configuratie, dus dit dwingt vaak headful plus een virtueel display op servers. En het extensie-oppervlak beweegt: SeleniumBase gebruikers verloren proxy authenticatie door een Chrome 137 extensie wijziging, dus pin je browser en framework versies.

Optie twee slaat de extensie over en beantwoordt de uitdaging via CDP. Dit is de geaccepteerde oplossing in de nodriver discussie, en de volgorde brengt iedereen in de war: registreer de handlers voordat je het Fetch domein inschakelt, en wacht nooit binnen een handler anders blokkeer je de event loop.

import asyncio, nodriver as uc

PROXY = "http://gate.quantumproxies.io:PORT"   # no credentials in the flag
USER, PASS = "USER", "PASS"

async def main():
    browser = await uc.start(browser_args=[f"--proxy-server={PROXY}"])
    tab = await browser.get("draft:,")

    async def on_auth(event: uc.cdp.fetch.AuthRequired):
        # fire-and-forget: awaiting here blocks every other request
        asyncio.create_task(tab.send(uc.cdp.fetch.continue_with_auth(
            request_id=event.request_id,
            auth_challenge_response=uc.cdp.fetch.AuthChallengeResponse(
                response="ProvideCredentials", username=USER, password=PASS),
        )))

    async def on_paused(event: uc.cdp.fetch.RequestPaused):
        asyncio.create_task(tab.send(uc.cdp.fetch.continue_request(request_id=event.request_id)))

    tab.add_handler(uc.cdp.fetch.RequestPaused, on_paused)
    tab.add_handler(uc.cdp.fetch.AuthRequired, on_auth)
    # enable AFTER the handlers are registered, or no event ever arrives
    await tab.send(uc.cdp.fetch.enable(handle_auth_requests=True))

    page = await browser.get("https://httpbin.org/ip")
    print(await page.get_content())

uc.loop().run_until_complete(main())
Checklist die de eenvoudige oplossingen voor proxy authenticatie contrasteert, zoals het gebruik van het HTTP endpoint en IP whitelisting, tegen de moeilijkere zoals het genereren van een auth extensie of het schrijven van een CDP handler
Volgorde van operaties: verander het endpoint, dan whitelist het IP. Bouw alleen een extensie, een relay of een CDP hook wanneer geen van beide mogelijk is.

Workaround 4: een lokale relay

Een relay is een kleine proxy die je op localhost draait die met inloggegevens met de upstream gateway praat en je framework een ongeauthenticeerde luisteraar biedt. De browser verbindt met 127.0.0.1, ziet geen auth-uitdaging, en het inloggegevensprobleem verschuift naar een proces dat er geen moeite mee heeft. Dit is de enige manier om SOCKS5 met inloggegevens vanuit Chromium te gebruiken, en wat Camoufox gebruikers melden te doen. Open-source relays op GitHub nemen de upstream inloggegevens als omgevingsvariabelen. Houd de luisteraar gebonden aan loopback — een open no-auth proxy op een publieke interface is iemands anders gratis bandbreedte. Bouw versus installatie wordt behandeld in proxy relay tools voor SOCKS5 auth.

# SeleniumBase UC Mode: one flag, extension generated for you
pytest test_proxy.py --uc --proxy=USER:PASS@gate.quantumproxies.io:PORT

# Relay route: credentials upstream, no auth on the local listener
SOCKS5_SERVER=gate.quantumproxies.io:PORT \
SOCKS5_USER=USER SOCKS5_PASSWORD=PASS \
  ./socks-relay.py 127.0.0.1:1080

# now every framework can use it, credentials and limitations gone
# playwright: proxy={"server": "socks5://127.0.0.1:1080"}
# nodriver:   browser_args=["--proxy-server=socks5://127.0.0.1:1080"]

Welke route te kiezen

Veelgestelde vragen

Waarom ondersteunt Chrome geen SOCKS5 met een gebruikersnaam en wachtwoord?

Omdat Chromium's netwerkstack nooit de SOCKS5 gebruikersnaam en wachtwoord authenticatiemethode heeft geïmplementeerd. Het verzoek staat al jaren op de Chromium tracker als issue 40323993, en het Chrome-team heeft bevestigd dat het niet wordt ondersteund in gerelateerde extensie threads. Het is geen vlag die je mist: geen enkele combinatie van command-line argumenten geeft SOCKS5 inloggegevens door aan Chromium, en elk op Chromium gebaseerd framework erft dat.

Welk anti-detect framework heeft de beste proxy ondersteuning?

Voor geauthenticeerde HTTP proxies, de Playwright familie — Playwright, Patchright, browser-use en Camoufox — is het minst pijnlijk, omdat inloggegevens een eersteklas parameter zijn. Camoufox gaat het verst door tijdzone, locatie en WebRTC af te stemmen op het exit IP via zijn GeoIP-optie. De CDP-eerst tools, nodriver en zendriver, zijn sterk op stealth maar verwachten dat je zelf de authenticatie oplost.

Breekt een auth proxy Cloudflare omzeiling in UC Modus?

Het kan, en de rapporten geven meestal de schuld aan twee afzonderlijke dingen als één. De gegenereerde auth extensie verandert het oppervlak van de browser, en de proxy verandert het exit IP — en een IP met een slechte reputatie triggert harde uitdagingen die geen enkel framework kan doorstaan. Test hetzelfde doelwit twee keer, één keer met de proxy en één keer met een gewhitelist IP, voordat je het framework de schuld geeft.

Is IP whitelisting veiliger dan user:pass?

Operationeel is het eenvoudiger en verwijdert het een hele klasse van fouten, aangezien niets een uitdaging hoeft te beantwoorden en inloggegevens nooit in een launch flag of proceslijst staan. De trade-off is flexibiliteit: het bindt de pool aan een vast bronadres, dus laptops op wisselende netwerken en autoscaling workers hebben nog steeds inloggegevens nodig. De meeste teams whitelisten productie en houden user:pass voor ontwikkeling.

De kaart is kort genoeg om te onthouden. Playwright en zijn forks nemen inloggegevens; nodriver en zendriver laten je het antwoord bouwen; SeleniumBase bouwt het voor je en breekt af en toe; SOCKS5 met inloggegevens is een doodlopende weg in Chromium. De rest is kiezen tussen HTTP endpoint, gewhitelist IP, extensie en relay — in die volgorde, omdat dat ook het minste tot meeste onderhoud is.

Krijg HTTP, SOCKS5 en IP whitelisting op één plan