SOCKS5 Proxy Auth Relay: Bouw er een, of sla het volledig over

Chrome en veel automatiseringstools kunnen nog steeds niet authenticeren met een SOCKS5 proxy. Een kleine lokale relay lost dat op door de inloggegevens vast te houden — hier is een minimaal werkende, de kant-en-klare tools, en de gevallen waarin je het helemaal niet nodig hebt.

Een SOCKS5 proxy auth relay is een klein lokaal proces dat namens jou antwoordt op de gebruikersnaam/wachtwoord uitdaging van een proxy, en vervolgens je tool een eenvoudig, niet-geauthenticeerd eindpunt op 127.0.0.1 geeft. Het bestaat om een hardnekkige kloof te overbruggen: Chromium heeft nooit geauthenticeerde SOCKS5 ondersteund (bijgehouden als Chromium bug 40829748), en veel automatiseringstools accepteren alleen een kaal host:port. Een Reddit-thread die de ronde deed — iemand die gefrustreerd genoeg was om een kleine relay te bouwen omdat tools nog steeds niet met geauthenticeerde SOCKS5 konden omgaan — is het hele genre in één zin. Deze gids toont een minimaal werkende relay, de kant-en-klare tools, en, net zo belangrijk, wanneer je er geen nodig hebt.

Het patroon: geen-auth vooraan, geauthenticeerd achteraan

Elke relay in deze ruimte doet hetzelfde. Het luistert lokaal zonder authenticatie, en voor elke verbinding opent het het upstream deel met je echte inloggegevens. Je tool verbindt met 127.0.0.1 — geen wachtwoord nodig — en de relay voert de SOCKS5 auth handshake uit naar de SOCKS5 gateway. De inloggegevens blijven op één plek, op loopback, en raken nooit de configuratie van de tool. Dat is om een tweede reden belangrijk: SOCKS5 is niet versleuteld en verzendt inloggegevens in platte tekst, dus het geauthenticeerde deel op je eigen machine houden, gebonden aan 127.0.0.1, is de veilige manier om dit te doen.

De een-commando relay: gost

Je hoeft zelden zelf een relay te schrijven. gost is een open-source tunneling tool die de volledige SOCKS5 specificatie implementeert, inclusief gebruikersnaam/wachtwoord authenticatie, en het hele werk in één enkel commando omzet. Stel lokaal een geen-auth SOCKS5 listener bloot en stuur door naar je geauthenticeerde upstream:

# 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)

Als je tool HTTP spreekt maar geen SOCKS5, converteert hetzelfde commando protocollen — stel een lokale HTTP proxy bloot die doorstuurt naar de geauthenticeerde SOCKS5 gateway. Dit is het duidelijke antwoord op de terugkerende "converteer SOCKS5 naar HTTP proxy" vraag, en het overtreft de klassieke Privoxy configuratie omdat gost de upstream auth op één plek afhandelt:

# 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

Een minimale relay vanaf nul

Als je liever de bewegende delen begrijpt, hier is de kleinste nuttige versie in pure Python. Het gebruikt PySocks (pip install PySocks) om het geauthenticeerde upstream deel te openen en pijpt bytes beide kanten op. Deze specifieke schets tunnel één doelhost — genoeg om een enkele API te scrapen via een geauthenticeerde SOCKS5 exit — wat het kort en correct houdt; een algemene SOCKS5 server die de client handshake parseert is wat tools zoals gost al voor je doen:

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())

Voor een volledige lokale SOCKS5 server waar elke client naar kan wijzen, is het community socks-relay project op GitHub een goede referentie: het draait een geen-auth of gebruikersnaam/wachtwoord listener en stuurt door naar een andere SOCKS5 server, in een paar honderd regels gebouwd op PySocks. Het socks-to-http-proxy project (Rust) doet de HTTP-conversie als je de voorkeur geeft aan een gecompileerde binary. Hoe dan ook, je voert hetzelfde patroon uit dat gost je in één regel geeft.

Wanneer je GEEN relay nodig hebt

Een relay is een sprong die je zelf bezit, en vaak kun je het hele probleem verwijderen. Sla het over wanneer een van deze waar is:

• Je provider heeft een HTTP eindpunt. HTTP proxies authenticeren met Basic auth in de URL, wat bijna elke tool aankan. Wijs naar de HTTP gateway en de SOCKS5 auth hoofdpijn verdwijnt — de afwegingen worden behandeld in SOCKS5 vs HTTP.
• IP-whitelisting is beschikbaar. Registreer je uitgaande IP bij de provider en er zijn helemaal geen inloggegevens om door te geven. Elk QuantumProxies plan ondersteunt whitelisting naast gebruikersnaam/wachtwoord op zijn residential proxies — de eenvoudigste oplossing wanneer je IP stabiel is.
• Je bibliotheek ondersteunt al SOCKS5 auth. curl, Python requests[socks] en httpx, en de meeste HTTP clients spreken geauthenticeerde SOCKS5 van nature. De relay is alleen voor tools die dat niet kunnen — voornamelijk Chromium-gebaseerde browsers.

# 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

Het eerlijke nadeel

Je eigen relay draaien voegt een falingspunt toe. Het is een ander proces om te superviseren: als het crasht, mislukt elke aanvraag erachter, en een kale script geeft je geen herstart, geen gezondheidscontrole en geen logging tenzij je ze toevoegt. Het heeft geen eigen rotatie — het stuurt door naar welke enkele upstream je ook hebt geconfigureerd, dus exit-rotatie moet nog steeds van de gateway komen. Het voegt een sprong van latentie toe, en het houdt platte tekst inloggegevens in het geheugen, wat precies de reden is waarom het moet binden aan 127.0.0.1 en nooit een publieke interface. Voor een laptop die één site scrapt, is dat prima. Voor alles waar je een melding over krijgt, geef de voorkeur aan een oplossing zonder nieuwe bewegende delen — whitelisting of een HTTP eindpunt — boven een relay die je nu in leven moet houden.

Hetzelfde relay patroon duikt op in het stealth ecosysteem, omdat Chromium's SOCKS5 kloof wordt gedeeld door elke browser die erop is gebouwd. Als je dit in een specifiek framework integreert, zie Playwright SOCKS5 authenticatie en onze 407 probleemoplossingsgids voor de fouten die je onderweg zult tegenkomen.

Veelgestelde vragen

Wat is een SOCKS5 proxy auth relay?

Een klein lokaal proces dat luistert zonder authenticatie en elke verbinding doorstuurt naar een upstream SOCKS5 proxy met je gebruikersnaam en wachtwoord. Het laat tools die geen SOCKS5 inloggegevens kunnen sturen — voornamelijk Chromium-gebaseerde browsers — een geauthenticeerde proxy bereiken door te wijzen naar een loopback adres zoals 127.0.0.1:1080. gost creëert er een met één enkel commando.

Hoe converteer ik een SOCKS5 proxy naar een HTTP proxy?

Je kunt de proxy zelf niet converteren; je draait een tussenpersoon die lokaal HTTP spreekt en upstream SOCKS5. gost -L http://:8080 -F socks5://USER:PASS@host:port stelt een lokale HTTP proxy bloot die doorstuurt naar de geauthenticeerde SOCKS5 gateway. Toegewijde tools zoals socks-to-http-proxy en Privoxy doen hetzelfde werk als je de voorkeur aan hen geeft.

Waarom kan Chrome geen geauthenticeerde SOCKS5 proxy gebruiken?

Chromium heeft nooit SOCKS5 gebruikersnaam/wachtwoord authenticatie geïmplementeerd — het is een langdurige beperking geregistreerd als Chromium bug 40829748. Niet-geauthenticeerde SOCKS5 werkt via --proxy-server=socks5://host:port, maar er is geen manier om inloggegevens te verstrekken. Een lokale relay of IP-whitelisting is de standaardoplossing, en een proxy-auth extensie dekt HTTP proxies.

Is het veilig om SOCKS5 inloggegevens naar een relay te sturen?

Alleen via loopback. SOCKS5 is niet versleuteld en verzendt inloggegevens in platte tekst, dus een relay moet binden aan 127.0.0.1 en nooit een publieke interface — dat houdt het geauthenticeerde deel op je eigen machine. De versleutelde tunnel naar het doel wordt end-to-end voor HTTPS opgezet, dus de relay ziet alleen TLS bytes die het niet kan lezen.

Grijp naar een relay alleen wanneer de tool je geen andere keuze laat. gost is het antwoord in één regel, PySocks de vanaf-nul optie — maar de snelste oplossing voor de meeste mensen is om een IP te whitelisten of een HTTP eindpunt te gebruiken en helemaal niets extra's te draaien. Minder bewegende delen, minder 3 uur 's nachts meldingen.

Verkrijg SOCKS5 proxies met IP-whitelisting