Proxy Autenticati nei Browser Anti-Detect: Mappa di Supporto 2026

Chromium non ha mai accettato credenziali su SOCKS5, e un launcher che passa solo --proxy-server non ha nessuno che risponda al prompt di autenticazione. Ecco quale framework accetta user:pass, quale necessita di un aiuto e quale è un vicolo cieco.

Un proxy autenticato in un browser anti-detect fallisce in uno dei tre modi, e i sintomi non cambiano mai: un popup di credenziali Chrome che nulla può chiudere, un 407 su ogni richiesta, o una pagina che si carica perfettamente dal tuo IP. Il proxy è raramente colpevole. Chromium non ha mai accettato un nome utente e password su SOCKS5, e un launcher che inoltra solo --proxy-server al binario non ha nessuno che risponda alla sfida di autenticazione del browser. Questa è la mappa 2026: quali framework accettano user:pass nativamente, quali necessitano di un aiuto e dove la strada finisce.

Una causa principale, tre sintomi

Lo stack proxy di Chromium ha uno slot per un indirizzo server SOCKS5 e nessuno per le credenziali. La richiesta è rimasta sul tracker di Chromium come problema 40323993 per anni, l'estensione SwitchyOmega ha registrato la conferma del team Chrome nel proprio problema #1455, e gli utenti di ChromeDriver che cercano la stessa cosa vengono indirizzati a crbug 40829748. Firefox è l'eccezione — autentica SOCKS5 nativamente — motivo per cui Camoufox si trova in una colonna diversa da tutto il resto qui. Se la divisione del protocollo è nuova per te, inizia con SOCKS5 vs proxy HTTP.

I proxy HTTP e HTTPS sono un'altra storia: le credenziali funzionano, solo mai dalla riga di comando. Chrome risponde a un 407 sollevando una sfida di autenticazione, e qualcosa deve rispondere — in un browser normale, il popup che vedi. Nell'automazione deve essere un'estensione caricata, un gestore CDP iscritto a Fetch.authRequired, o il framework stesso. Qualsiasi cosa che passi solo un flag di avvio lascia la sfida senza risposta, e quella è la pagina bloccata che le persone continuano a fare screenshot. La metà del formato delle credenziali è coperta in correzione 407 proxy authentication required.

Supporto proxy autenticati nei browser anti-detect: la mappa 2026

Tre categorie: credenziali accettate dall'API, credenziali accettate solo tramite un aiuto che costruisci, e un limite del motore che nessuna configurazione sposterà.

Funziona nativamente con user:pass

Necessita di un'estensione, un relay o un gestore CDP

Non funziona mai: SOCKS5 con credenziali

Confronto a tre colonne del supporto proxy autenticato: framework con supporto nativo per utente e password, framework che necessitano di un'estensione o gestore CDP, e SOCKS5 con credenziali che non funziona mai in Chromium
Stesso core Chromium, tre risultati. La prima colonna è un cambiamento di configurazione, la seconda è un passaggio di costruzione, e la terza è una limitazione del motore che aggiri.

Soluzione alternativa 1: usa l'endpoint HTTP del provider

Questo risolve la maggior parte dei thread collegati sopra, e non costa nulla. Se il tuo provider espone lo stesso pool su HTTP e SOCKS5, punta il browser al gateway HTTP e le credenziali diventano un parametro supportato invece di uno non supportato. Il DNS lato proxy è gratuito: Chromium delega sempre la risoluzione dei nomi a un proxy HTTP. Ogni piano QuantumProxies serve HTTP e SOCKS5 dallo stesso gateway con le stesse credenziali, quindi il passaggio è un cambiamento di schema, non un nuovo ordine.

# 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: ...

Soluzione alternativa 2: whitelist dell'IP

La risposta più pulita è eliminare il passaggio di autenticazione. Con la whitelist dell'IP registri l'IP pubblico della macchina che esegue il browser e il gateway lo autorizza per indirizzo sorgente — nessun nome utente, nessuna password, nessun popup, nulla a cui il framework debba rispondere. Ogni problema su questa pagina scompare immediatamente, SOCKS5 incluso, perché non ci sono credenziali da passare. È giusto per un server di scraping fisso o un container dietro un IP di uscita statico, e sbagliato per laptop su reti che cambiano. La whitelist si affianca a user:pass su ogni piano QuantumProxies, quindi la produzione può essere in whitelist mentre lo sviluppo mantiene le credenziali.

Metti in whitelist il tuo IP su un pool residenziale di oltre 90 milioni

Soluzione alternativa 3: un'estensione di autenticazione Chrome generata, o un gestore CDP

Se devi mantenere le credenziali su un framework Chromium che non le accetta, qualcosa all'interno del browser deve rispondere alla sfida. L'opzione uno è un'estensione che imposta il proxy e risponde a onAuthRequired — esattamente ciò che SeleniumBase costruisce dietro il suo flag --proxy. Sotto Manifest V3 le due autorizzazioni che lo fanno funzionare sono webRequest e webRequestAuthProvider; mancare la seconda e il listener non si attiva mai.

// 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"],
);

Due avvertenze. Le estensioni non si caricano in ogni configurazione headless, quindi questo spesso forza l'uso di un display virtuale sui server. E la superficie dell'estensione si muove: gli utenti di SeleniumBase hanno perso l'autenticazione proxy a causa di una modifica all'estensione di Chrome 137, quindi fissa le versioni del browser e del framework.

L'opzione due salta l'estensione e risponde alla sfida tramite CDP. Questa è la soluzione accettata nella discussione nodriver, e l'ordine confonde tutti: registra i gestori prima di abilitare il dominio Fetch, e non aspettare mai all'interno di un gestore o bloccherai il ciclo degli eventi.

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())
Lista di controllo che contrasta le semplici soluzioni per l'autenticazione proxy, come l'uso dell'endpoint HTTP e la whitelist dell'IP, contro quelle più difficili come generare un'estensione di autenticazione o scrivere un gestore CDP
Ordine delle operazioni: cambia l'endpoint, poi metti in whitelist l'IP. Costruisci solo un'estensione, un relay o un hook CDP quando nessuno dei due è possibile.

Soluzione alternativa 4: un relay locale

Un relay è un piccolo proxy che esegui su localhost che comunica con il gateway a monte con credenziali e offre al tuo framework un listener non autenticato. Il browser si connette a 127.0.0.1, non vede alcuna sfida di autenticazione, e il problema delle credenziali si sposta su un processo che non ha problemi con esso. Questo è l'unico modo per utilizzare SOCKS5 con credenziali da Chromium, ed è ciò che gli utenti di Camoufox segnalano di fare. I relay open-source su GitHub prendono le credenziali a monte come variabili d'ambiente. Mantieni il listener vincolato al loopback — un proxy aperto senza autenticazione su un'interfaccia pubblica è la larghezza di banda gratuita di qualcun altro. Costruire contro installare è coperto in strumenti di relay proxy per l'autenticazione SOCKS5.

# 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"]

Quale percorso scegliere

Domande frequenti

Perché Chrome non supporta SOCKS5 con un nome utente e una password?

Perché lo stack di rete di Chromium non ha mai implementato il metodo di autenticazione con nome utente e password di SOCKS5. La richiesta è stata sul tracker di Chromium per anni come problema 40323993, e il team Chrome ha confermato che non è supportato nei thread delle estensioni correlate. Non è un flag che ti manca: nessuna combinazione di argomenti da riga di comando passa le credenziali SOCKS5 a Chromium, e ogni framework basato su Chromium lo eredita.

Quale framework anti-detect ha il miglior supporto proxy?

Per i proxy HTTP autenticati, la famiglia Playwright — Playwright, Patchright, browser-use e Camoufox — è la meno dolorosa, perché le credenziali sono un parametro di prima classe. Camoufox va oltre allineando fuso orario, locale e WebRTC con l'IP di uscita tramite la sua opzione GeoIP. Gli strumenti CDP-first, nodriver e zendriver, sono forti sullo stealth ma si aspettano che tu risolva l'autenticazione da solo.

Un proxy di autenticazione interrompe il bypass di Cloudflare in UC Mode?

Può, e i rapporti di solito incolpano due cose separate come una. L'estensione di autenticazione generata cambia la superficie del browser, e il proxy cambia l'IP di uscita — e un IP con cattiva reputazione attiva sfide difficili che nessun framework può superare. Testa lo stesso obiettivo due volte, una volta con il proxy e una volta con un IP in whitelist, prima di incolpare il framework.

La whitelist dell'IP è più sicura di user:pass?

Operativamente è più semplice e rimuove un'intera classe di fallimenti, poiché nulla deve rispondere a una sfida e le credenziali non siedono mai in un flag di avvio o in un elenco di processi. Il compromesso è la flessibilità: lega il pool a un indirizzo sorgente fisso, quindi i laptop su reti che cambiano e i lavoratori in autoscaling hanno ancora bisogno di credenziali. La maggior parte dei team mette in whitelist la produzione e mantiene user:pass per lo sviluppo.

La mappa è abbastanza breve da memorizzare. Playwright e i suoi fork accettano credenziali; nodriver e zendriver ti fanno costruire la risposta; SeleniumBase la costruisce per te e occasionalmente si rompe; SOCKS5 con credenziali è un vicolo cieco in Chromium. Il resto è scegliere tra endpoint HTTP, IP in whitelist, estensione e relay — in quest'ordine, perché è anche da meno a più manutenzione.

Ottieni HTTP, SOCKS5 e whitelist dell'IP su un unico piano