SOCKS5 Proxy Auth Relay: Selbst bauen oder ganz darauf verzichten

Chrome und viele Automatisierungstools können sich immer noch nicht bei einem SOCKS5-Proxy authentifizieren. Ein kleiner lokaler Relay behebt das, indem er die Anmeldedaten speichert — hier ist ein minimal funktionierender, die fertigen Tools und die Fälle, in denen Sie ihn überhaupt nicht benötigen.

Ein SOCKS5 Proxy Auth Relay ist ein kleiner lokaler Prozess, der die Benutzername/Passwort-Herausforderung eines Proxys in Ihrem Namen beantwortet und Ihrem Tool dann einen einfachen, nicht authentifizierten Endpunkt auf 127.0.0.1 bereitstellt. Es existiert, um eine hartnäckige Lücke zu überbrücken: Chromium hat nie authentifizierten SOCKS5 unterstützt (verfolgt als Chromium-Bug 40829748), und viele Automatisierungstools akzeptieren nur einen nackten host:port. Ein Reddit-Thread, der die Runde machte — jemand war frustriert genug, um einen kleinen Relay zu bauen, weil Tools immer noch nicht mit authentifiziertem SOCKS5 umgehen konnten — fasst das ganze Genre in einem Satz zusammen. Dieser Leitfaden zeigt einen minimal funktionierenden Relay, die fertigen Tools und, ebenso wichtig, wann Sie keinen benötigen.

Das Muster: vorne ohne Authentifizierung, hinten authentifiziert

Jeder Relay in diesem Bereich macht dasselbe. Er hört lokal ohne Authentifizierung zu und öffnet für jede Verbindung das Upstream-Segment mit Ihren echten Anmeldedaten. Ihr Tool verbindet sich mit 127.0.0.1 — kein Passwort erforderlich — und der Relay führt den SOCKS5-Auth-Handshake zum SOCKS5-Gateway durch. Die Anmeldedaten befinden sich an einem Ort, auf der Loopback-Schnittstelle, und berühren nie die Konfiguration des Tools. Das ist aus einem zweiten Grund wichtig: SOCKS5 ist nicht verschlüsselt und überträgt Anmeldedaten im Klartext, daher ist es sicher, das authentifizierte Segment auf Ihrem eigenen Rechner zu halten, gebunden an 127.0.0.1.

Der Ein-Befehl-Relay: gost

Sie müssen selten einen Relay von Hand schreiben. gost ist ein Open-Source-Tunneling-Tool, das die vollständige SOCKS5-Spezifikation einschließlich Benutzername/Passwort-Authentifizierung implementiert und die gesamte Aufgabe in einen einzigen Befehl verwandelt. Stellen Sie einen SOCKS5-Listener ohne Authentifizierung lokal bereit und leiten Sie ihn an Ihren authentifizierten Upstream weiter:

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

Wenn Ihr Tool HTTP, aber nicht SOCKS5 spricht, konvertiert derselbe Befehl Protokolle — stellen Sie einen lokalen HTTP-Proxy bereit, der an das authentifizierte SOCKS5-Gateway weiterleitet. Dies ist die saubere Antwort auf die wiederkehrende Frage "socks5 zu http proxy konvertieren", und es übertrifft die klassische Privoxy-Konfiguration, da gost die Upstream-Authentifizierung an einem Ort handhabt:

# 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
Flussdiagramm eines lokalen SOCKS5-Auth-Relays: ein Tool verbindet sich mit einem nicht authentifizierten Loopback-Listener, der Anmeldedaten hinzufügt und an ein authentifiziertes Proxy-Gateway weiterleitet
Der Relay hält die Anmeldedaten auf der Loopback-Schnittstelle und führt den SOCKS5-Auth-Handshake durch, sodass das Tool nur einen nicht authentifizierten Endpunkt sieht.

Ein minimaler Relay von Grund auf

Wenn Sie lieber die beweglichen Teile verstehen möchten, hier ist die kleinste nützliche Version in reinem Python. Es verwendet PySocks (pip install PySocks), um das authentifizierte Upstream-Segment zu öffnen und Bytes in beide Richtungen zu leiten. Diese spezielle Skizze tunnelt einen Zielhost — genug, um eine einzelne API durch einen authentifizierten SOCKS5-Ausgang zu scrapen — was es kurz und korrekt hält; ein allgemeiner SOCKS5-Server, der den Client-Handshake analysiert, ist das, was Tools wie gost bereits für Sie tun:

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

Für einen vollständigen lokalen SOCKS5-Server, auf den jeder Client zeigen kann, ist das Community-Projekt socks-relay auf GitHub eine gute Referenz: Es läuft ein Listener ohne Authentifizierung oder mit Benutzer/Passwort und leitet an einen anderen SOCKS5-Server weiter, in ein paar hundert Zeilen, die auf PySocks basieren. Das Projekt socks-to-http-proxy (Rust) erledigt die HTTP-Konvertierungsaufgabe, wenn Sie eine kompilierte Binärdatei bevorzugen. So oder so führen Sie dasselbe Muster aus, das gost Ihnen in einer Zeile gibt.

Wann Sie KEINEN Relay benötigen

Ein Relay ist ein Sprung, den Sie besitzen, und oft können Sie das gesamte Problem einfach löschen. Verzichten Sie darauf, wenn eines dieser Dinge zutrifft:

# 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
Checkliste, die vergleicht, wann ein SOCKS5-Auth-Relay unnötig ist und wann es sich lohnt, einschließlich HTTP-Endpunkten, IP-Whitelisting, nativer Bibliotheksunterstützung und Chromiums SOCKS5-Lücke
Die meisten Setups können den Relay überspringen: ein HTTP-Endpunkt, IP-Whitelisting oder ein Client, der nativ SOCKS5-Auth spricht, beseitigen die Notwendigkeit eines Relays.

Der ehrliche Nachteil

Einen eigenen Relay zu betreiben, fügt einen Fehlerpunkt hinzu. Es ist ein weiterer Prozess, den Sie überwachen müssen: Wenn er abstürzt, schlägt jede dahinterliegende Anfrage fehl, und ein einfaches Skript bietet Ihnen weder Neustart, noch Gesundheitsprüfung oder Protokollierung, es sei denn, Sie fügen sie hinzu. Es hat keine eigene Rotation — es leitet an den konfigurierten einzelnen Upstream weiter, sodass die Exit-Rotation immer noch vom Gateway kommen muss. Es fügt einen Latenzsprung hinzu und hält Klartext-Anmeldedaten im Speicher, weshalb es unbedingt an 127.0.0.1 gebunden sein muss und niemals an eine öffentliche Schnittstelle. Für einen Laptop, der eine Seite scrapt, ist das in Ordnung. Für alles, worüber Sie benachrichtigt werden, bevorzugen Sie eine Lösung ohne neue bewegliche Teile — Whitelisting oder ein HTTP-Endpunkt — gegenüber einem Relay, das Sie nun am Leben halten müssen.

Dasselbe Relay-Muster taucht im gesamten Stealth-Ökosystem auf, weil Chromium's SOCKS5-Lücke von jedem darauf basierenden Browser geteilt wird. Wenn Sie dies in ein spezifisches Framework integrieren, sehen Sie sich Playwright SOCKS5-Authentifizierung und unseren 407-Fehlerbehebungsleitfaden für die Fehler an, auf die Sie stoßen werden.

Häufig gestellte Fragen

Was ist ein SOCKS5 Proxy Auth Relay?

Ein kleiner lokaler Prozess, der ohne Authentifizierung zuhört und jede Verbindung an einen Upstream-SOCKS5-Proxy unter Verwendung Ihres Benutzernamens und Passworts weiterleitet. Es ermöglicht Tools, die keine SOCKS5-Anmeldedaten senden können — hauptsächlich auf Chromium basierende Browser — einen authentifizierten Proxy zu erreichen, indem sie auf eine Loopback-Adresse wie 127.0.0.1:1080 zeigen. gost erstellt einen in einem einzigen Befehl.

Wie konvertiere ich einen SOCKS5-Proxy in einen HTTP-Proxy?

Sie können den Proxy selbst nicht konvertieren; Sie betreiben einen Vermittler, der lokal HTTP und upstream SOCKS5 spricht. gost -L http://:8080 -F socks5://USER:PASS@host:port stellt einen lokalen HTTP-Proxy bereit, der an das authentifizierte SOCKS5-Gateway weiterleitet. Spezialisierte Tools wie socks-to-http-proxy und Privoxy erledigen die gleiche Aufgabe, wenn Sie sie bevorzugen.

Warum kann Chrome keinen authentifizierten SOCKS5-Proxy verwenden?

Chromium hat nie die SOCKS5-Benutzername/Passwort-Authentifizierung implementiert — es ist eine langjährige Einschränkung, die als Chromium-Bug 40829748 protokolliert ist. Nicht authentifizierter SOCKS5 funktioniert über --proxy-server=socks5://host:port, aber es gibt keine Möglichkeit, Anmeldedaten bereitzustellen. Ein lokaler Relay oder IP-Whitelisting ist die Standardlösung, und eine Proxy-Auth-Erweiterung deckt HTTP-Proxies ab.

Ist es sicher, SOCKS5-Anmeldedaten an einen Relay zu senden?

Nur über Loopback. SOCKS5 ist nicht verschlüsselt und überträgt Anmeldedaten im Klartext, daher muss ein Relay an 127.0.0.1 gebunden sein und niemals an eine öffentliche Schnittstelle — das hält das authentifizierte Segment auf Ihrem eigenen Rechner. Der verschlüsselte Tunnel zum Ziel wird unabhängig davon Ende-zu-Ende für HTTPS aufgebaut, sodass der Relay nur TLS-Bytes sieht, die er nicht lesen kann.

Greifen Sie nur zu einem Relay, wenn das Tool Ihnen keine andere Wahl lässt. gost ist die Ein-Zeilen-Antwort, PySocks die von Grund auf — aber die schnellste Lösung für die meisten Menschen ist es, eine IP zu whitelisten oder einen HTTP-Endpunkt zu verwenden und überhaupt nichts zusätzlich zu betreiben. Weniger bewegliche Teile, weniger 3-Uhr-Nachrichten.

Erhalten Sie SOCKS5-Proxies mit IP-Whitelisting