Proxies authentifiés dans les navigateurs anti-détection : Carte de support 2026

Chromium n'a jamais accepté les identifiants sur SOCKS5, et un lanceur qui ne passe que --proxy-server n'a personne pour répondre à l'invite d'authentification. Voici quel framework accepte user:pass, lequel nécessite un assistant, et lequel est une impasse.

Un proxy authentifié dans un navigateur anti-détection échoue de trois manières, et les symptômes ne changent jamais : une fenêtre d'identification Chrome que rien ne peut fermer, un 407 sur chaque requête, ou une page qui se charge parfaitement depuis votre propre IP. Le proxy est rarement en cause. Chromium n'a jamais accepté un nom d'utilisateur et un mot de passe sur SOCKS5, et un lanceur qui ne fait que transmettre --proxy-server au binaire n'a personne pour répondre au défi d'authentification du navigateur. Voici la carte 2026 : quels frameworks acceptent user:pass nativement, lesquels nécessitent un assistant, et où la route s'arrête.

Une cause principale, trois symptômes

La pile proxy de Chromium a un emplacement pour une adresse de serveur SOCKS5 et aucun emplacement pour les identifiants. La demande est restée sur le traqueur Chromium comme problème 40323993 pendant des années, l'extension SwitchyOmega a enregistré la confirmation de l'équipe Chrome dans son propre problème #1455, et les utilisateurs de ChromeDriver poursuivant la même chose sont dirigés vers crbug 40829748. Firefox est l'exception — il authentifie SOCKS5 nativement — ce qui explique pourquoi Camoufox se retrouve dans une colonne différente de tout le reste ici. Si la division du protocole est nouvelle pour vous, commencez par SOCKS5 vs HTTP proxies.

Les proxies HTTP et HTTPS sont une autre histoire : les identifiants fonctionnent, mais jamais depuis la ligne de commande. Chrome répond à un 407 en soulevant un défi d'authentification, et quelque chose doit répondre — dans un navigateur normal, la fenêtre contextuelle que vous voyez. En automatisation, cela doit être une extension chargée, un gestionnaire CDP abonné à Fetch.authRequired, ou le framework lui-même. Tout ce qui ne fait que passer un drapeau de lancement laisse le défi sans réponse, et c'est la page suspendue que les gens continuent de capturer en capture d'écran. La moitié du format des identifiants est couverte dans fixer 407 proxy authentication required.

Support des proxies authentifiés dans les navigateurs anti-détection : la carte 2026

Trois catégories : identifiants acceptés par l'API, identifiants acceptés uniquement via un assistant que vous construisez, et une limite du moteur qu'aucune configuration ne déplacera.

Fonctionne nativement avec user:pass

Nécessite une extension, un relais ou un gestionnaire CDP

Ne fonctionne jamais : SOCKS5 avec identifiants

Comparaison en trois colonnes du support des proxies authentifiés : frameworks avec support natif de l'utilisateur et du mot de passe, frameworks nécessitant une extension ou un gestionnaire CDP, et SOCKS5 avec identifiants qui ne fonctionne jamais dans Chromium
Même noyau Chromium, trois résultats. La première colonne est un changement de configuration, la deuxième est une étape de construction, et la troisième est une limitation du moteur que vous contournez.

Solution de contournement 1 : utilisez le point de terminaison HTTP du fournisseur

Cela résout la plupart des discussions liées ci-dessus, et cela ne coûte rien. Si votre fournisseur expose le même pool sur HTTP et SOCKS5, pointez le navigateur vers la passerelle HTTP et les identifiants deviennent un paramètre supporté au lieu d'un non supporté. Le DNS côté proxy est gratuit : Chromium délègue toujours la résolution de noms à un proxy HTTP. Chaque plan QuantumProxies sert HTTP et SOCKS5 depuis la même passerelle avec les mêmes identifiants, donc le changement est un changement de schéma, pas une nouvelle commande.

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

Solution de contournement 2 : mise sur liste blanche de l'IP

La réponse la plus propre est de supprimer l'étape d'authentification. Avec la mise sur liste blanche de l'IP, vous enregistrez l'IP publique de la machine exécutant le navigateur et la passerelle l'autorise par adresse source — pas de nom d'utilisateur, pas de mot de passe, pas de fenêtre contextuelle, rien pour le framework à répondre. Tous les problèmes sur cette page disparaissent d'un coup, SOCKS5 inclus, car il n'y a plus d'identifiant à transmettre. C'est idéal pour un serveur de scraping fixe ou un conteneur derrière une IP de sortie statique, et inadapté pour les ordinateurs portables sur des réseaux changeants. La mise sur liste blanche est disponible avec user:pass sur chaque plan QuantumProxies, donc la production peut être mise sur liste blanche tandis que le développement conserve les identifiants.

Mettez votre IP sur liste blanche sur un pool résidentiel de plus de 90 millions

Solution de contournement 3 : une extension d'authentification Chrome générée, ou un gestionnaire CDP

Si vous devez conserver les identifiants sur un framework Chromium qui ne les accepte pas, quelque chose à l'intérieur du navigateur doit répondre au défi. L'option un est une extension qui définit le proxy et répond à onAuthRequired — exactement ce que SeleniumBase construit derrière son drapeau --proxy. Sous Manifest V3, les deux autorisations qui le font fonctionner sont webRequest et webRequestAuthProvider ; manquez la seconde et l'écouteur ne se déclenche jamais.

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

Deux mises en garde. Les extensions ne se chargent pas dans toutes les configurations sans tête, donc cela force souvent une tête plus un affichage virtuel sur les serveurs. Et la surface de l'extension bouge : les utilisateurs de SeleniumBase ont perdu l'authentification proxy à cause d'un changement d'extension Chrome 137, donc fixez vos versions de navigateur et de framework.

L'option deux évite l'extension et répond au défi via CDP. C'est la solution acceptée dans la discussion nodriver, et l'ordre des opérations piège tout le monde : enregistrez les gestionnaires avant d'activer le domaine Fetch, et n'attendez jamais à l'intérieur d'un gestionnaire ou vous bloquez la boucle d'événements.

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())
Liste de contrôle contrastant les solutions simples pour l'authentification proxy, telles que l'utilisation du point de terminaison HTTP et la mise sur liste blanche de l'IP, contre les plus difficiles comme la génération d'une extension d'authentification ou l'écriture d'un gestionnaire CDP
Ordre des opérations : changez le point de terminaison, puis mettez l'IP sur liste blanche. Ne construisez une extension, un relais ou un crochet CDP que si ni l'un ni l'autre n'est possible.

Solution de contournement 4 : un relais local

Un relais est un petit proxy que vous exécutez sur localhost qui parle à la passerelle en amont avec des identifiants et offre à votre framework un écouteur non authentifié. Le navigateur se connecte à 127.0.0.1, ne voit pas de défi d'authentification, et le problème d'identifiants se déplace vers un processus qui n'a aucun problème avec cela. C'est le seul moyen d'utiliser SOCKS5 avec des identifiants depuis Chromium, et ce que les utilisateurs de Camoufox rapportent faire. Les relais open-source sur GitHub prennent les identifiants en amont comme variables d'environnement. Gardez l'écouteur lié à la boucle locale — un proxy ouvert sans authentification sur une interface publique est la bande passante gratuite de quelqu'un d'autre. La construction contre l'installation est couverte dans outils de relais proxy pour l'authentification 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"]

Quelle route choisir

Questions fréquemment posées

Pourquoi Chrome ne supporte-t-il pas SOCKS5 avec un nom d'utilisateur et un mot de passe ?

Parce que la pile réseau de Chromium n'a jamais implémenté la méthode d'authentification par nom d'utilisateur et mot de passe SOCKS5. La demande est sur le traqueur Chromium depuis des années comme problème 40323993, et l'équipe Chrome a confirmé qu'elle n'est pas supportée dans les discussions d'extension connexes. Ce n'est pas un drapeau que vous manquez : aucune combinaison d'arguments en ligne de commande ne passe les identifiants SOCKS5 à Chromium, et chaque framework basé sur Chromium hérite de cela.

Quel framework anti-détection a le meilleur support proxy ?

Pour les proxies HTTP authentifiés, la famille Playwright — Playwright, Patchright, browser-use et Camoufox — est la moins douloureuse, car les identifiants sont un paramètre de première classe. Camoufox va plus loin en alignant le fuseau horaire, la locale et WebRTC avec l'IP de sortie via son option GeoIP. Les outils CDP-first, nodriver et zendriver, sont forts en furtivité mais vous attendent pour résoudre l'authentification vous-même.

Un proxy d'authentification casse-t-il le contournement Cloudflare en mode UC ?

Cela peut, et les rapports blâment généralement deux choses séparées comme une seule. L'extension d'authentification générée change la surface du navigateur, et le proxy change l'IP de sortie — et une IP avec une mauvaise réputation déclenche des défis difficiles qu'aucun framework ne peut passer. Testez la même cible deux fois, une fois avec le proxy et une fois avec une IP sur liste blanche, avant de blâmer le framework.

La mise sur liste blanche de l'IP est-elle plus sûre que user:pass ?

Opérationnellement, c'est plus simple et élimine toute une classe d'échecs, car rien n'a à répondre à un défi et les identifiants ne se retrouvent jamais dans un drapeau de lancement ou une liste de processus. Le compromis est la flexibilité : cela lie le pool à une adresse source fixe, donc les ordinateurs portables sur des réseaux changeants et les travailleurs à mise à l'échelle automatique ont toujours besoin d'identifiants. La plupart des équipes mettent en liste blanche la production et gardent user:pass pour le développement.

La carte est assez courte pour être mémorisée. Playwright et ses dérivés prennent les identifiants ; nodriver et zendriver vous font construire la réponse ; SeleniumBase la construit pour vous et casse occasionnellement ; SOCKS5 avec identifiants est une impasse dans Chromium. Le reste consiste à choisir entre point de terminaison HTTP, IP sur liste blanche, extension et relais — dans cet ordre, car c'est aussi du moins au plus de maintenance.

Obtenez HTTP, SOCKS5 et la mise sur liste blanche IP sur un seul plan