SOCKS5- und SOCKS4-Proxies

Über einen SOCKS-Proxy kann eine Anwendung einen Vermittlerserver bitten, sich für sie mit einem Ziel zu verbinden. Der Proxy öffnet die gewünschte Verbindung und überträgt Daten in beide Richtungen. Die Anwendung verwendet weiterhin ihr eigenes Protokoll. Das funktioniert für Webanfragen, API-Clients, Dateitransfers und andere Software mit SOCKS-Unterstützung.

Für neue Einrichtungen bietet SOCKS5 gewöhnlich die nützlichsten Möglichkeiten: mehr Adressformate, verschiedene Authentifizierungsverfahren und UDP-Unterstützung. SOCKS4 bleibt für Software mit dieser älteren Versionsanforderung sinnvoll. Den Vergleich mit HTTP-Proxies behandelt SOCKS- und HTTP-Proxies.

Wie eine Anwendung eine SOCKS-Verbindung aufbaut

Betrachten Sie eine Anwendung, die https://example.com/ über einen SOCKS5-Proxy öffnet. Sie erreicht zunächst den Proxy, fordert eine Websiteverbindung an und tauscht erst danach Websitedaten aus. Der Vorgang hat vier Stufen:

1. Die Anwendung verbindet sich per TCP mit dem Hostnamen oder der IP-Adresse und dem Empfangsport des Proxys.
2. Anwendung und Proxy wählen ein Zugangsverfahren. Verlangt es Zugangsdaten, übermittelt die Anwendung diese zur Prüfung an den Proxy.
3. Die Anwendung sendet eine SOCKS CONNECT-Anfrage mit Zieladresse und Port. Der Proxy prüft seine Zugangsregeln, versucht die weiterführende Verbindung und meldet das Ergebnis.
4. Nach erfolgreicher Antwort kommuniziert die Anwendung über den Proxy mit dem Ziel. Bei einer HTTPS-Website baut sie TLS zur Website auf und prüft deren Zertifikat, bevor sie die Webanfrage sendet.

Die beiden Portnummern gehören zu unterschiedlichen Servern. Ein Beispielproxy könnte auf proxy.example:1080 lauschen, während die Website über example.com:443 erreicht wird. Port 1080 ist für SOCKS üblich, ein Dienst kann aber einen anderen verwenden. Verwenden Sie den zugewiesenen Empfangsport Ihres Proxys; er ersetzt nicht den Zielport.

Bei gewöhnlicher TCP-Weiterleitung überträgt SOCKS den Bytestrom der Anwendung, ohne jede HTTP-Anfrage oder jeden Dateibefehl auszuwerten. Die Anwendung spricht weiterhin ihr eigenes Protokoll mit dem Ziel. Deshalb kann derselbe SOCKS-Verbindungsmechanismus Webclients und andere Software bedienen.

CONNECT ist ein SOCKS-Befehl mit eigenem Nachrichtenformat und unterscheidet sich von der HTTP-Methode CONNECT. SOCKS definiert außerdem BIND für Anwendungen, bei denen ein Server durch den Proxy zurückverbinden muss, etwa bei aktivem FTP. BIND benötigt gesonderte Unterstützung und wird nicht für gewöhnliche Website- oder API-Anfragen verwendet.

Unterschiede zwischen SOCKS4, SOCKS4a und SOCKS5

SOCKS4 öffnet TCP-Verbindungen zu IPv4-Adressen. SOCKS4a ergänzt die Übermittlung eines Hostnamens, dessen IP-Adresse der Proxy per DNS ermitteln kann. SOCKS5 ergänzt eine Auswahl von Authentifizierungsverfahren, akzeptiert IPv4, IPv6 und Hostnamen und definiert UDP-Weiterleitung.

Das sind Protokollfähigkeiten. Client und Proxydienst müssen die benötigte Funktion tatsächlich implementieren. Ein SOCKS5-Dienst kann beispielsweise TCP-Verbindungen verarbeiten, ohne nutzbare UDP-Weiterleitung anzubieten.

SOCKS5 kann in seiner Anfrage ein IPv6-Ziel angeben; der Proxy muss diesen IPv6-Server aber auch erreichen können. Die zwei Verbindungen dürfen unterschiedliche IP-Versionen verwenden: Die Anwendung erreicht den Proxy vielleicht per IPv4, während dieser das Ziel per IPv6 kontaktiert.

SOCKS4a ist eine SOCKS4-Erweiterung, keine andere Bezeichnung für jede SOCKS4-Verbindung. Sendet ein alter Client nur IPv4-Adressen, gibt ihm die Auswahl von SOCKS4 kein entferntes DNS. SOCKS4a verlangt Unterstützung beider Seiten. Unterstützen beide SOCKS5, ist das gewöhnlich die einfachere Wahl. SOCKS4 allein verbessert weder den Ruf noch die Geschwindigkeit der Ausgangs-IP-Adresse.

Wer den Zielnamen auflöst

Vor dem Verbindungsaufbau zu einem benannten Server muss dessen Name in eine IP-Adresse übersetzt werden. SOCKS5 akzeptiert entweder das Auflösungsergebnis oder den Namen selbst. Die DNS-Einstellung des Clients bestimmt die übermittelte Variante.

Bei lokalem DNS fragt die Anwendung ihren eingerichteten Resolver nach reports.example. Lautet die Antwort 203.0.113.27, fordert sie anschließend eine SOCKS-Verbindung zu 203.0.113.27:443 an. Die Auflösung hat bereits auf Clientseite stattgefunden, obwohl die folgende Websiteverbindung über den Proxy läuft.

Bei DNS auf Proxyseite sendet die Anwendung reports.example:443, ohne das Ziel vorher lokal aufzulösen. Der Proxy ermittelt dessen IP-Adresse per DNS und baut die gewünschte Verbindung auf. Der Hostname erreicht ihn als Bestandteil der SOCKS-Anfrage.

Das hilft, wenn der Client einen Namen nicht auflösen kann, der Proxy aber schon. Manche Dienste liefern je nach Resolver andere Adressen; die Verlagerung kann deshalb den Zielserver verändern. Sie stellt weder das Ausgangsland des Proxys ein noch garantiert sie die Anfrageannahme.

In curl wählen die folgenden zwei Befehle die beiden DNS-Modi:

curl --proxy socks5://proxy.example:1080 https://example.com/
curl --proxy socks5h://proxy.example:1080 https://example.com/

socks5:// lässt curl den Websitenamen lokal auflösen; socks5h:// übergibt ihn dem Proxy. Beide verwenden SOCKS5. Das h steht in der URL-Syntax dieses Clients für Hostnamenauflösung durch den Proxy. Es macht aus SOCKS5 kein HTTPS und ergänzt keine Verschlüsselung. Andere Anwendungen verwenden vielleicht ein Kontrollkästchen oder wählen entferntes DNS automatisch. Ersetzen Sie Beispielhostname und Port durch Ihre Dienstdaten und ergänzen Sie die erforderliche Authentifizierung.

Die Übermittlung eines Domainnamens in einer SOCKS5-TCP-Anfrage benötigt keine UDP-Weiterleitung. Der Proxy löst ihn mit seiner eigenen DNS-Konfiguration auf. Das unterscheidet sich vom Transport der UDP-Pakete eines Clients durch SOCKS5.

Soll ein Client Ziel-DNS dem Proxy überlassen, führt die Auflösung aber lokal aus, wird der gewünschte Name außerhalb des geplanten Wegs sichtbar. Das ist ein DNS-Leak. Verschlüsseltes DNS schützt den Austausch mit dem Resolver, der den Namen dennoch erhält. Die Auflösung des Proxyhostnamens ist ein getrennter Vorgang; andere Anwendungen behalten eigene DNS-Regeln. Entferntes DNS in einem Programm verlagert nicht alle Geräteabfragen.

Authentifizierung und Verschlüsselung

Bei SOCKS5 bietet der Client unterstützte Authentifizierungsverfahren an, und der Proxy wählt eines. Benutzername und Passwort sind eine Möglichkeit. Eine andere ist eine Verbindung ohne SOCKS-Anmeldedialog, die der Dienst nach Prüfung der Client-Quell-IP-Adresse gegen eine Zulassungsliste erlaubt. Ein Endpunkt ohne Passwortfeld kann den Zugang also trotzdem beschränken.

Ein fehlendes gemeinsames Verfahren unterscheidet sich von einem abgelehnten Passwort: Im ersten Fall fand noch kein Passwortaustausch statt. Ein Client ohne Benutzername-Passwort-Unterstützung kann keinen ausschließlich passwortgeschützten SOCKS5-Endpunkt verwenden, nur weil er eine SOCKS5-Einstellung besitzt. SOCKS4 hat ein Nutzerkennungsfeld, aber keinen entsprechenden standardisierten Passwortaustausch. Sein Server kann dennoch Zugangsregeln anwenden.

Der übliche SOCKS5-Benutzername-Passwort-Austausch verschlüsselt die Zugangsdaten nicht. Er findet vor dem HTTPS-Aufbau der Anwendung zum Ziel statt; das spätere HTTPS schützt daher die frühere Proxyanmeldung nicht. Die Verschlüsselung zwischen Client und Proxy verlangt eine getrennte geschützte Verbindung oder einen ausdrücklich unterstützten Sicherheitsmechanismus.

Bei gewöhnlicher SOCKS-Weiterleitung schützt HTTPS den Austausch zwischen Anwendung und Website, sofern Zertifikate geprüft werden und keine TLS-Inspektion erfolgt. Ein unverschlüsseltes Anwendungsprotokoll bleibt durch den Proxy unverschlüsselt. SOCKS5 oder Passwortauthentifizierung allein verspricht keinen verschlüsselten Datenverkehr.

Der Proxy kennt weiterhin die verbindende Client-IP-Adresse, das angeforderte Ziel und die Verbindungszeiten. Das Ziel sieht die Ausgangs-IP-Adresse und erhält die an es gerichteten Anwendungsdaten. Cookies, Kontoanmeldungen und andere Kennungen können den Nutzer weiter identifizieren. Ein SOCKS-Versionswechsel entfernt sie nicht.

Wie SOCKS5 TCP und UDP transportiert

TCP stellt einen geordneten Bytestrom bereit. Browseranfrage, API-Aufruf oder SSH-Sitzung können eine SOCKS-TCP-Verbindung nutzen, wenn der Client diesen Weg unterstützt und der Proxy das Ziel zulässt. Ein Erfolg auf Websiteport 443 belegt nicht die Verfügbarkeit eines anderen Anwendungsports.

UDP sendet einzelne Datagramme. Ein SOCKS5-Client öffnet zuerst eine TCP-Steuerverbindung und fordert mit UDP ASSOCIATE eine Weiterleitung an. Der Proxy liefert Relay-Adresse und UDP-Port. Der Client sendet seine Datagramme mit SOCKS-Headern zur Zielbeschreibung dorthin. Das Schließen der TCP-Steuerverbindung beendet die UDP-Zuordnung. Die Datagramme laufen getrennt von der Steuerverbindung, nicht innerhalb eines gewöhnlichen SOCKS CONNECT-Stroms.

Anwendung und Dienst müssen diesen Mechanismus unterstützen; das Netzwerk muss den UDP-Weg zulassen. Ein Programm kann die TCP-Anmeldung abschließen, während Sprache, Spiel oder andere UDP-Funktionen weiterhin scheitern. Eine erfolgreiche HTTPS-Anfrage über SOCKS CONNECT zeigt TCP-Weiterleitung, kein funktionierendes UDP. QUIC nutzt UDP, hängt aber ebenfalls vom Client und dem gesamten Weg ab. SOCKS5 allein belegt dies nicht.

Wo SOCKS nützlich ist

SOCKS hilft Software, eine Vermittlerverbindung unter Beibehaltung des eigenen Anwendungsprotokolls zu verwenden. Ein Skript kann API-Daten über eine zugewiesene Ausgangs-IP-Adresse abrufen, ein Dateiclient einen entfernten Server über einen zugelassenen Weg erreichen und eine kompatible Desktopanwendung einen Proxy ohne Webbrowser nutzen. Jeder Fall hängt von der SOCKS-Unterstützung des Clients und den freigegebenen Zielports ab.

Für wiederholte Arbeit mit demselben Konto oder Server kann ein fester Ausgang passen. Für getrennte Aufgaben kann ein rotierender Dienst helfen. SOCKS4 und SOCKS5 entscheiden dies nicht: Der Dienst bestimmt Ausgangs-IP-Adresse, Netzwerktyp, Mitnutzung und Wechselzeitpunkt. Die Version liefert auch keine Geschwindigkeitsrangfolge; Weglänge, Serverlast und Bandbreite beeinflussen das Ergebnis.

Die Clientunterstützung kann enger sein als das Protokoll. Chromes eingebaute SOCKS5-Implementierung löst Zielnamen über den Proxy auf, führt aber weder SOCKS5-Benutzername-Passwort-Authentifizierung noch UDP-Weiterleitung aus. Ein reiner Passwortendpunkt kann deshalb in curl funktionieren und in der eingebauten Browsereinstellung scheitern. Ein externer Adapter ist ein eigener Verbindungsteil mit eigenen Fähigkeiten.

Ein innerhalb eines Programms eingerichteter Proxy gilt für dessen unterstützte Verbindungen. Er konfiguriert keinen separaten Downloader oder ein anderes Skript. System-Proxyeinstellungen beeinflussen ebenfalls nur Software, die sie verwendet. Leitet ein Adapter Verbindungen einer Anwendung ohne eigene SOCKS-Unterstützung um, zählt seine Abdeckung von TCP, UDP und DNS. SOCKS bietet keine gewöhnliche ICMP-Weiterleitung; ping testet deshalb diesen Proxyweg nicht.

Verbindungseinstellungen und ein sinnvoller Test

Beginnen Sie mit Proxyadresse, Empfangsport, SOCKS-Version und Zugangsverfahren des Endpunkts. Eine Zahl wie 1080 identifiziert das Protokoll nicht allein. Wählen Sie SOCKS im Client, statt dieselbe Adresse in ein reines HTTP-Proxyfeld einzutragen.

Proxyzugangsdaten berechtigen zur Nutzung des Vermittlers; eine Websiteanmeldung zur Nutzung der Website. Sie gehören in getrennte Einstellungen. In curl übergibt --proxy-user Proxyzugangsdaten und --user Zielzugangsdaten. Bei IP-basiertem Zugang muss die Zulassungsliste zur Client-Quell-IP-Adresse passen, die der Proxy sieht. Diese kann sich beim Netzwerkwechsel ändern.

Wählen Sie den gewünschten DNS-Modus und prüfen Sie Ausnahmeregeln. Ein eingerichteter Proxy kann für Ziele einer Ausschlussliste umgangen werden. Bei curl kann NO_PROXY dies bewirken; --noproxy "" entfernt die Ausnahmen für einen Aufruf, wenn Sie bewusst den Proxyweg testen wollen.

Testen Sie aus dem tatsächlich vorgesehenen Programm. Ein IP-Prüfendpunkt oder ein selbst kontrolliertes Zielserverprotokoll zeigt die Quell-IP-Adresse der Anfrage. Vergleichen Sie das mit einer direkten Anfrage. Die zum Erreichen des Proxys verwendete Adresse und die beim Ziel sichtbare Ausgangsadresse müssen nicht identisch sein.

Testen Sie anschließend die echte Aufgabe. Eine geänderte IP-Adresse zeigt den Weg der geprüften Anfrage, misst aber nicht alle Transporte und belegt keine Reaktion anderer Websites. Testen Sie benötigtes UDP oder IPv6 getrennt und bewerten Sie Antwortzeit und Stabilität unter repräsentativer Last.

Fehler nach Verbindungsstufen eingrenzen

Unterscheiden Sie das Erreichen des Proxys, den Zugang, den Aufbau zum Ziel und die Anwendungsantwort. Diese Stufen haben unterschiedliche Fehlerursachen.

Gelingt eine geprüfte HTTPS-Verbindung und liefert die Website eine Anmeldeseite, ein CAPTCHA oder eine Ablehnung, hat SOCKS diesen Austausch bereits transportiert. Untersuchen Sie Websiteantwort und Anwendungsverhalten. Zeigt die Anfrage stattdessen Ihre gewöhnliche öffentliche IP-Adresse, prüfen Sie Proxyauswahl und Ausnahmeregeln dieses Programms.