Relais d'authentification SOCKS5 Proxy : le construire ou l'éviter complètement
Chrome et de nombreux outils d'automatisation ne peuvent toujours pas authentifier un proxy SOCKS5. Un petit relais local résout ce problème en conservant les identifiants — voici une version minimale fonctionnelle, les outils prêts à l'emploi, et les cas où vous n'en avez pas du tout besoin.
Un relais d'authentification SOCKS5 proxy est un petit processus local qui répond au défi de nom d'utilisateur/mot de passe d'un proxy en votre nom, puis fournit à votre outil un point de terminaison simple, sans authentification sur 127.0.0.1. Il existe pour combler un écart persistant : Chromium n'a jamais pris en charge le SOCKS5 authentifié (suivi comme le bug Chromium 40829748), et de nombreux outils d'automatisation n'acceptent qu'un simple host:port. Un fil Reddit qui a fait le tour — quelqu'un suffisamment frustré pour construire un petit relais car les outils ne pouvaient toujours pas gérer le SOCKS5 authentifié — résume tout en une phrase. Ce guide montre un relais minimal fonctionnel, les outils prêts à l'emploi, et, tout aussi important, quand vous n'en avez pas besoin.
Le schéma : sans authentification devant, authentifié derrière
Chaque relais dans cet espace fait la même chose. Il écoute localement sans authentification, et pour chaque connexion, il ouvre la liaison montante en utilisant vos véritables identifiants. Votre outil se connecte à 127.0.0.1 — pas de mot de passe nécessaire — et le relais effectue la poignée de main d'authentification SOCKS5 vers la passerelle SOCKS5. Les identifiants résident en un seul endroit, sur la boucle locale, et ne touchent jamais la configuration de l'outil. Cela compte pour une deuxième raison : SOCKS5 n'est pas chiffré et transmet les identifiants en clair, donc garder la liaison authentifiée sur votre propre machine, liée à 127.0.0.1, est la manière sécurisée de procéder.
Le relais en une commande : gost
Vous n'avez que rarement besoin d'écrire un relais à la main. gost est un outil de tunneling open-source qui implémente la spécification complète SOCKS5, y compris l'authentification par nom d'utilisateur/mot de passe, et il transforme tout le travail en une seule commande. Exposez un écouteur SOCKS5 sans authentification localement et redirigez vers votre liaison montante authentifiée :
# local no-auth SOCKS5 on :1080 -> authenticated SOCKS5 upstream
gost -L socks5://:1080 -F socks5://USER:PASS@gate.quantumproxies.io:PORT
# now point any tool at the loopback address, no credentials:
# --proxy-server=socks5://127.0.0.1:1080 (Chrome, nodriver, zendriver)Si votre outil parle HTTP mais pas SOCKS5, la même commande convertit les protocoles — exposez un proxy HTTP local qui redirige vers la passerelle SOCKS5 authentifiée. C'est la réponse propre à la question récurrente "convertir SOCKS5 en proxy HTTP", et cela surpasse la configuration classique de Privoxy car gost gère l'authentification montante en un seul endroit :
# local HTTP proxy on :8080 -> authenticated SOCKS5 upstream
gost -L http://:8080 -F socks5://USER:PASS@gate.quantumproxies.io:PORT
# Chrome/curl/anything with an HTTP proxy setting can now use 127.0.0.1:8080
Un relais minimal à partir de zéro
Si vous préférez comprendre les éléments mobiles, voici la plus petite version utile en Python pur. Il utilise PySocks (pip install PySocks) pour ouvrir la liaison montante authentifiée et transfère les octets dans les deux sens. Ce croquis particulier tunnelise un hôte cible — suffisant pour extraire une seule API via une sortie SOCKS5 authentifiée — ce qui le rend court et correct ; un serveur SOCKS5 général qui analyse la poignée de main du client est ce que des outils comme gost font déjà pour vous :
import asyncio, socks # PySocks
UP_HOST, UP_PORT = "gate.quantumproxies.io", 0000 # your SOCKS5 gateway
UP_USER, UP_PASS = "USER", "PASS"
TARGET = ("example.com", 443) # the one host to reach
async def pipe(reader, writer):
try:
while data := await reader.read(65536):
writer.write(data)
await writer.drain()
finally:
writer.close()
async def handle(local_r, local_w):
# open the upstream leg with SOCKS5 auth (PySocks is blocking -> a thread)
up = await asyncio.to_thread(
socks.create_connection, TARGET,
proxy_type=socks.SOCKS5, proxy_addr=UP_HOST, proxy_port=UP_PORT,
username=UP_USER, password=UP_PASS,
)
up_r, up_w = await asyncio.open_connection(sock=up)
await asyncio.gather(pipe(local_r, up_w), pipe(up_r, local_w))
async def main():
server = await asyncio.start_server(handle, "127.0.0.1", 1080)
async with server:
await server.serve_forever()
asyncio.run(main())Pour un serveur SOCKS5 local complet auquel n'importe quel client peut se connecter, le projet communautaire socks-relay sur GitHub est une bonne référence : il exécute un écouteur sans authentification ou avec utilisateur/mot de passe et relaie vers un autre serveur SOCKS5, en quelques centaines de lignes basées sur PySocks. Le projet socks-to-http-proxy (Rust) fait le travail de conversion HTTP si vous préférez un binaire compilé. Dans tous les cas, vous exécutez le même schéma que gost vous donne en une ligne.
Quand vous n'avez PAS besoin d'un relais
Un relais est un saut que vous possédez, et souvent vous pouvez supprimer tout le problème à la place. Évitez-le lorsque l'un de ces cas est vrai :
- Votre fournisseur dispose d'un point de terminaison HTTP. Les proxies HTTP s'authentifient avec Basic auth dans l'URL, que presque tous les outils gèrent. Pointez vers la passerelle HTTP et le casse-tête d'authentification SOCKS5 disparaît — les compromis sont couverts dans SOCKS5 vs HTTP.
- Le whitelisting IP est disponible. Enregistrez votre IP de sortie auprès du fournisseur et il n'y a plus d'identifiants à relayer. Chaque plan QuantumProxies prend en charge le whitelisting en plus de user:pass sur ses proxies résidentiels — la solution la plus simple chaque fois que votre IP est stable.
- Votre bibliothèque gère déjà l'authentification SOCKS5. curl, Python
requests[socks]ethttpx, et la plupart des clients HTTP parlent nativement le SOCKS5 authentifié. Le relais est uniquement pour les outils qui ne le peuvent pas — principalement les navigateurs basés sur Chromium.
# no relay needed — curl authenticates SOCKS5 directly (socks5h resolves DNS
# through the proxy, avoiding leaks):
curl -x socks5h://USER:PASS@gate.quantumproxies.io:PORT https://httpbin.org/ip
# and HTTP Basic proxy auth is even more widely supported:
curl -x http://USER:PASS@gate.quantumproxies.io:PORT https://httpbin.org/ip
Le désavantage honnête
Exécuter votre propre relais ajoute un point de défaillance. C'est un autre processus à superviser : s'il plante, chaque requête derrière échoue, et un script simple ne vous offre ni redémarrage, ni vérification de l'état, ni journalisation à moins que vous ne les ajoutiez. Il n'a pas de rotation propre — il redirige vers le seul amont que vous avez configuré, donc la rotation de sortie doit toujours venir de la passerelle. Il ajoute un saut de latence, et il conserve les identifiants en clair en mémoire, ce qui est exactement pourquoi il doit se lier à 127.0.0.1 et jamais à une interface publique. Pour un ordinateur portable qui extrait un site, c'est correct. Pour tout ce que vous surveillez, préférez une solution sans nouvelles pièces mobiles — le whitelisting ou un point de terminaison HTTP — plutôt qu'un relais que vous devez maintenant maintenir en vie.
Le même schéma de relais apparaît dans tout l'écosystème furtif, car l'écart SOCKS5 de Chromium est partagé par chaque navigateur construit dessus. Si vous intégrez cela dans un cadre spécifique, consultez l'authentification SOCKS5 de Playwright et notre guide de dépannage 407 pour les erreurs que vous rencontrerez en cours de route.
Questions fréquemment posées
Qu'est-ce qu'un relais d'authentification SOCKS5 proxy ?
Un petit processus local qui écoute sans authentification et redirige chaque connexion vers un proxy SOCKS5 amont en utilisant votre nom d'utilisateur et mot de passe. Il permet aux outils qui ne peuvent pas envoyer d'identifiants SOCKS5 — principalement les navigateurs basés sur Chromium — d'atteindre un proxy authentifié en pointant vers une adresse de boucle locale comme 127.0.0.1:1080. gost en crée un en une seule commande.
Comment convertir un proxy SOCKS5 en proxy HTTP ?
Vous ne pouvez pas convertir le proxy lui-même ; vous exécutez un intermédiaire qui parle HTTP localement et SOCKS5 en amont. gost -L http://:8080 -F socks5://USER:PASS@host:port expose un proxy HTTP local qui redirige vers la passerelle SOCKS5 authentifiée. Des outils dédiés comme socks-to-http-proxy et Privoxy font le même travail si vous les préférez.
Pourquoi Chrome ne peut-il pas utiliser un proxy SOCKS5 authentifié ?
Chromium n'a jamais implémenté l'authentification par nom d'utilisateur/mot de passe SOCKS5 — c'est une limitation de longue date enregistrée comme le bug Chromium 40829748. Le SOCKS5 non authentifié fonctionne via --proxy-server=socks5://host:port, mais il n'y a aucun moyen de fournir des identifiants. Un relais local ou le whitelisting IP est la solution standard, et une extension de proxy-auth couvre les proxies HTTP.
Est-il sûr d'envoyer des identifiants SOCKS5 à un relais ?
Seulement via la boucle locale. SOCKS5 n'est pas chiffré et transmet les identifiants en clair, donc un relais doit se lier à 127.0.0.1 et jamais à une interface publique — cela garde la liaison authentifiée sur votre propre machine. Le tunnel chiffré vers la cible est établi de bout en bout pour HTTPS de toute façon, donc le relais ne voit jamais que des octets TLS qu'il ne peut pas lire.
Recourez à un relais uniquement lorsque l'outil ne vous laisse pas le choix. gost est la réponse en une ligne, PySocks celle à partir de zéro — mais la solution la plus rapide pour la plupart des gens est de mettre en liste blanche une IP ou d'utiliser un point de terminaison HTTP et de ne rien exécuter de plus. Moins de pièces mobiles, moins d'appels à 3 heures du matin.