Selenium Proxy Authenticatie: 4 Instellingen Die Echt Werken
Chrome toont een authenticatiedialoog die Selenium niet kan aanraken, en de truc met inloggegevens in de URL faalt stilletjes. Hier zijn de vier instellingen die daadwerkelijk een proxy in Selenium authentiseren — gerangschikt op hoe weinig ze pijn doen.
Selenium proxy authenticatie is een valstrik vermomd als een one-liner. De --proxy-server Chrome-vlag accepteert een proxyadres zonder problemen — en negeert stilletjes elke gebruikersnaam en wachtwoord die je erin opneemt. Chrome toont dan een native authenticatiedialoog die WebDriver niet kan zien, je script blijft hangen, en het beste antwoord op Stack Overflow dat je vindt (113+ stemmen) lost het op met een Manifest V2-extensie die moderne Chrome niet meer laadt. Deze gids behandelt de vier instellingen die vandaag de dag een proxy in Selenium authenticeren — IP-whitelisting, een Manifest V3-extensie, selenium-wire, en weten wanneer je het hele browserprobleem aan een API moet overlaten.
Waarom basis Selenium proxy authenticatie faalt
Drie feiten verklaren elke mislukte poging. Ten eerste, Chromium stript inloggegevens van --proxy-server=http://user:pass@host:port — het vlagformaat heeft simpelweg geen ondersteuning voor inloggegevens. Ten tweede, de 407 Proxy Authentication Required uitdaging van de proxy verschijnt als een native dialoog, buiten de DOM, waar send_keys niet bij kan. Ten derde, de oude DesiredCapabilities route (socksUsername / socksPassword) was alleen van toepassing op SOCKS-proxies en werkte nooit voor HTTP-proxies — de configuratie die 'er goed uitziet' en niets doet. Dus de echte opties vermijden de dialoog volledig.
Methode 1: IP-whitelisting — nul code, nul dialogen
Als je scraper draait vanaf een machine met een stabiel openbaar IP, sla dan inloggegevens helemaal over: registreer dat IP in het dashboard van je proxyprovider, en de gateway authentiseert je op basis van bronadres. Elk QuantumProxies-plan ondersteunt IP-whitelisting naast gebruiker:wachtwoord. Aan de Selenium-kant wordt het de eenvoudige vlag — die altijd prima heeft gewerkt zonder authenticatie:
from selenium import webdriver
options = webdriver.ChromeOptions()
options.add_argument("--proxy-server=http://gate.quantumproxies.io:PORT")
options.add_argument("--headless=new")
driver = webdriver.Chrome(options=options)
driver.get("https://httpbin.org/ip")
print(driver.find_element("tag name", "body").text) # proxy exit IP
driver.quit()
Controleer altijd de exit voordat je een run vertrouwt: laad een IP-echo eindpunt en bevestig dat het adres tot de proxy behoort, want een verkeerd geconfigureerde vlag faalt stilletjes en Chrome maakt gewoon direct verbinding. De beperking van whitelisting is topologisch: het authentiseert een machine, niet een script. Kortstondige cloud-runners, containers achter NAT en CI-machines met veranderende IP's hebben een van de onderstaande methoden nodig.
Methode 2: een Manifest V3 Chrome-extensie
De klassieke oplossing genereert een kleine Chrome-extensie die de proxy instelt en de authenticatie-uitdaging beantwoordt via chrome.webRequest.onAuthRequired. Het beroemde fragment uit 2019 gebruikt Manifest V2, dat Chrome nu heeft afgeschaft — de moderne versie heeft manifest_version: 3, een service worker en de webRequestAuthProvider permissie nodig. Dit bouwt en laadt er een tijdens runtime:
import json, os, tempfile
from selenium import webdriver
HOST, PORT = "gate.quantumproxies.io", "PORT"
USER, PASS = "USER", "PASS"
manifest = {
"name": "Proxy Auth", "version": "1.0", "manifest_version": 3,
"permissions": ["proxy", "webRequest", "webRequestAuthProvider"],
"host_permissions": ["<all_urls>"],
"background": {"service_worker": "worker.js"},
}
worker = """
chrome.proxy.settings.set({
value: { mode: "fixed_servers", rules: {
singleProxy: { scheme: "http", host: "%s", port: parseInt("%s") },
bypassList: ["localhost"] } },
scope: "regular"
}, function() {});
chrome.webRequest.onAuthRequired.addListener(
function(details) {
return { authCredentials: { username: "%s", password: "%s" } };
},
{ urls: ["<all_urls>"] },
["blocking"]
);
""" % (HOST, PORT, USER, PASS)
ext_dir = tempfile.mkdtemp()
with open(os.path.join(ext_dir, "manifest.json"), "w") as f:
json.dump(manifest, f)
with open(os.path.join(ext_dir, "worker.js"), "w") as f:
f.write(worker)
options = webdriver.ChromeOptions()
options.add_argument("--load-extension=" + ext_dir)
options.add_argument("--headless=new")
driver = webdriver.Chrome(options=options)
driver.get("https://httpbin.org/ip")
Twee valkuilen. Extensies laden alleen in de nieuwe headless-modus — gewone --headless faalt met een cryptische 'failed to wait for extension background page' fout, dus --headless=new is verplicht. En het laden van een uitgepakte directory via --load-extension is betrouwbaarder over Chrome-versies heen dan het inpakken van een zip. Als je dit liever niet onderhoudt, genereert het selenium-authenticated-proxy pakket op PyPI de extensie voor je vanuit een enkele proxy-URL.

Methode 3: selenium-wire, en zijn afwegingen
selenium-wire wikkelt WebDriver in met een lokale man-in-the-middle proxy, wat geauthentiseerde upstream proxies — inclusief SOCKS5 — een eenvoudige optiedict maakt:
# pip install selenium-wire
from seleniumwire import webdriver
options = {
"proxy": {
"http": "http://USER:PASS@gate.quantumproxies.io:PORT",
"https": "http://USER:PASS@gate.quantumproxies.io:PORT",
"no_proxy": "localhost,127.0.0.1",
}
}
driver = webdriver.Chrome(seleniumwire_options=options)
driver.get("https://httpbin.org/ip")
Weet wat je koopt. Het project werd gearchiveerd door zijn beheerder in begin 2024 en ontvangt geen updates, en omdat het verkeer lokaal ontsleutelt, ziet het doelwit de TLS-handshake van selenium-wire in plaats van die van Chrome — een mismatch die JA3/JA4 vingerafdruksystemen markeren, zelfs wanneer je IP vlekkeloos is. Het blijft echt nuttig voor verzoekinspectie tijdens ontwikkeling en voor Firefox, waar de extensietruc niet bestaat. Voor productie-scraping op beschermde sites, geef de voorkeur aan methoden 1-2, of ga een laag hoger.
Firefox, en de authenticatiekloof
Firefox accepteert een niet-geauthentiseerde proxy netjes via profielvoorkeuren (network.proxy.type = 1 plus host- en poortinstellingen), maar heeft geen equivalent van Chrome's extensietruc om de inlogdialoog vanuit WebDriver te beantwoorden. In de praktijk kiezen Firefox-gebruikers voor IP-whitelisting of selenium-wire. Als je enige reden voor Firefox zijn proxy-afhandeling was, houdt die reden niet langer stand.
Wanneer te stoppen met het patchen van Selenium en over te schakelen naar een API
Authenticatie is de eerste belasting, niet de laatste. Een Chrome-instantie kost honderden MB RAM, dus een paar dozijn gelijktijdige sessies verzadigen een server; ChromeDriver-versies volgen Chrome-releases; en anti-bot leveranciers detecteren standaard Selenium ongeacht het IP erachter — navigator.webdriver en CDP-artefacten verraden het. Twee upgrades veranderen de economie. Ten eerste, laat je browsers draaien via residential proxies zodat IP-reputatie niet langer de reden is dat je geblokkeerd wordt — 90M+ huishoudelijke IP's met per-verzoek rotatie of sticky sessies voor ingelogde flows. Ten tweede, wanneer het onderhouden van browsers niet meer de moeite waard is, stort een Scraper API de hele stack in één HTTP-oproep: het rendert JavaScript op aanvraag, beheert IP's en herhalingen intern, en retourneert HTML, markdown of gestructureerde JSON. Dezelfde afweging geldt voor Selenium's neven — zie onze gidsen voor Playwright proxy-integratie en Puppeteer proxy-setup voordat je aanneemt dat een framework-switch een detectieprobleem zal oplossen.

Veelgestelde vragen
Hoe stel ik een proxy met authenticatie in Selenium ChromeDriver in?
Of whitelist het IP van je machine bij de proxyprovider en geef een eenvoudige --proxy-server vlag door, of laad een kleine Manifest V3-extensie die de proxy instelt en inloggegevens levert via chrome.webRequest.onAuthRequired. Het inbedden van user:pass@ in de vlag werkt niet — Chromium negeert het.
Waarom toont Chrome een proxy-inlogpopup met Selenium?
De proxy antwoordde met 407 en Chrome vraagt een mens om inloggegevens. De dialoog is native UI, onzichtbaar voor WebDriver, dus geen selector of send_keys oproep kan het invullen. De oplossing is om te authenticeren voordat de dialoog kan verschijnen: IP-whitelisting, een authenticatie-extensie, of een MITM-laag zoals selenium-wire.
Werkt selenium-wire nog steeds in 2026?
Het installeert en functioneert nog steeds voor veel workloads, maar het project werd gearchiveerd in begin 2024 en krijgt geen onderhoud. Het MITM-ontwerp vervangt ook de TLS-vingerafdruk van Chrome met een Python-vingerafdruk, die moderne anti-bot systemen detecteren. Behandel het als een debugging-tool, niet als de basis van een productie-scraper.
Hoe gebruik ik een geauthentiseerde proxy met Firefox in Selenium?
Firefox profielvoorkeuren configureren het proxyadres maar kunnen de inlogprompt niet beantwoorden, en er is geen extensie workaround zoals op Chrome. Gebruik IP-whitelisting zodat er geen inloggegevens nodig zijn, of routeer Firefox via selenium-wire, dat de upstream authenticatie lokaal afhandelt.
Werkt dit hetzelfde in Java en C#?
Ja — de mechanica zit in Chrome, niet in de taalbinding. IP-whitelisting plus --proxy-server is overal identiek, en de Manifest V3-extensie aanpak werkt vanuit Java of C# door dezelfde twee bestanden te schrijven en --load-extension toe te voegen aan ChromeOptions. Alleen selenium-wire is Python-specifiek; andere talen vervangen het door een lokale MITM-proxy zoals BrowserMob.
De korte versie: vecht nooit tegen de authenticatiedialoog. Whitelist wanneer je IP stabiel is, genereer een MV3-extensie wanneer dat niet zo is, bewaar selenium-wire voor inspectiewerk — en wanneer browseronderhoud de data die het produceert overtreft, promoot de taak naar een API en houd je avonden vrij.