SOCKS5 kann UDP tragen. Der Client öffnet eine TCP-Verbindung zum Proxy und schickt den Befehl UDP ASSOCIATE. Der Proxy antwortet mit einer Relay-Adresse und einem Port. Der Client schickt dann jedes Datagramm an dieses Relay, mit einem kleinen Header, der das echte Ziel nennt, und der Proxy leitet es von seiner eigenen Adresse aus weiter und verpackt die Antworten genauso. Die Zuordnung lebt so lange wie die TCP-Verbindung. Wenige SOCKS5-Proxies tun das tatsächlich: Am 10. Oktober 2026 leiteten 17 von 575 lebenden öffentlichen SOCKS5-Proxies aus unserer Liste eine echte DNS-Anfrage weiter.
Wir haben das an diesem Tag auf zwei Arten getestet. Unser eigener Proxy-Checker ließ seinen UDP-Test über 692 öffentliche SOCKS5-Proxies laufen und acht Minuten später über 682. Dann wiederholte unser eigenes Skript den Handshake Byte für Byte, um zu sehen, warum die anderen scheiterten. Die Fakten zum Protokoll unten stammen aus RFC 1928, dem Standard für SOCKS5.
Wie trägt SOCKS5 UDP?
In fünf Schritten, alle festgelegt in RFC 1928 (IETF, März 1996):
- Der Client öffnet eine TCP-Verbindung zum Proxy und einigt sich auf eine Anmeldemethode, wie bei jeder SOCKS5-Anfrage.
- Er schickt UDP ASSOCIATE, Befehl
0x03. Die Anfrage nennt die Adresse, von der der Client senden wird. Ein Client, der sie noch nicht kennt, „MUSS eine Portnummer und Adresse aus lauter Nullen verwenden“. - Der Proxy antwortet mit einem Relay.
BND.ADDRundBND.PORTder Antwort geben „die Portnummer und Adresse an, an die der Client UDP-Anfragen zum Weiterleiten schicken MUSS“. Viele Proxies antworten mit0.0.0.0, was Clients, unserer eingeschlossen, als die eigene Adresse des Proxys lesen. - Der Client schickt Datagramme an das Relay, jedes mit einem Header davor. Der Proxy entfernt ihn, schickt die Daten weiter und setzt denselben Header auf jede Antwort.
- Die Zuordnung endet mit der TCP-Verbindung. Der Standard sagt das in einer Zeile: „Eine UDP-Zuordnung endet, wenn die TCP-Verbindung endet, über die die Anfrage UDP ASSOCIATE kam“.
Der Header auf jedem Datagramm
Der Header aus Schritt 4 ist kurz:
| Feld | Größe | Was es enthält |
|---|---|---|
| RSV | 2 Bytes | Null, reserviert |
| FRAG | 1 Byte | Fragmentnummer; 00 für ein ganzes Datagramm |
| ATYP | 1 Byte | Adresstyp: 01 IPv4, 03 Domainname, 04 IPv6 |
| DST.ADDR | 4, 16 oder 1+n Bytes | Wohin das Datagramm soll |
| DST.PORT | 2 Bytes | Sein Port |
| DATA | der Rest | Das ursprüngliche Datagramm |
Für ein IPv4-Ziel sind das 10 Bytes, und RFC 1928 sagt Clients, sie sollen für jedes Datagramm entsprechend weniger Platz melden. Fragmentierung ist optional. Ein Relay, das sie nicht unterstützt, „MUSS jedes Datagramm verwerfen, dessen Feld FRAG etwas anderes als X'00' enthält“.
Der Austausch auf der Leitung
Hier ist der ganze Austausch mit echten öffentlichen Proxies am 10. Oktober 2026, mit jedem Byte:
Der dritte Proxy zeigt das ganze Design bei der Arbeit. Er nannte sein Relay als 0.0.0.0, und das Relay saß an der eigenen Adresse des Proxys. Unsere DNS-Anfrage ging mit dem Header 00 00 00 01 08 08 08 08 00 35 dorthin, das heißt IPv4-Adresse 8.8.8.8, Port 53. Die Antwort kam mit demselben Header und den Adressen von example.com zurück. Nachdem wir die TCP-Verbindung geschlossen hatten, bekam dieselbe Anfrage keine Antwort.
Warum braucht SOCKS5 UDP auch eine TCP-Verbindung?
Weil UDP keine Verbindung hat, an die man etwas hängen könnte. RFC 768 (IETF, August 1980) sagt über UDP, „Zustellung und Schutz vor Duplikaten sind nicht garantiert“. Die Buchführung übernimmt also die TCP-Verbindung. Sie trägt die Begrüßung, die Anmeldung und die Anfrage ASSOCIATE, und ihr Leben ist das Leben des Relays.
Das Relay ist mit Absicht still. RFC 1928 sagt, es leite ein Datagramm „still weiter, ohne jede Benachrichtigung an den anfragenden Client“, und es „verwirft Datagramme, die es nicht weiterleiten kann oder will“. Es muss außerdem Datagramme von jeder anderen Quelladresse verwerfen als der des Clients, der für die Zuordnung eingetragen ist. Ein Client erfährt also erst, dass UDP funktioniert, wenn eine Antwort zurückkommt. Deshalb schickt jeder ehrliche UDP-Test echten Traffic.
Der Standard nennt einen Weg, auf dem eine Zuordnung endet: das Ende der TCP-Verbindung. Eine Frage auf Stack Overflow von 2018 fragt, ob SOCKS5 für UDP ein Zeitlimit hat. RFC 1928 legt für eine Zuordnung kein Zeitlimit bei Untätigkeit fest; sein einziger Timer gilt dem Zusammensetzen von Fragmenten.
Wie viele SOCKS5-Proxies leiten UDP tatsächlich weiter?
Unter den öffentlichen etwa drei von hundert. Am 10. Oktober 2026 um 19:44 UTC haben wir die 400 SOCKS5-Einträge unserer kostenlosen Proxy-Liste mit der besten Verfügbarkeit genommen und die ersten 400 in ihrer Standardreihenfolge, 692 verschiedene Proxies. Unser Checker schickte jedem eine echte DNS-Anfrage über UDP ASSOCIATE und zählte ein Ja nur, wenn eine DNS-Antwort zurückkam. 575 antworteten als SOCKS5, und 17 leiteten die Anfrage weiter, 3,0 Prozent. Acht Minuten später ergab dieselbe Auswahl 16 von 549, 2,9 Prozent.
Unser eigenes Skript prüfte dann dieselben 575 Proxies und hielt fest, was jeder sagte:
Warum ein Ja wenig bedeutet
Die Antwort Ja bedeutet fast nichts. 414 Proxies antworteten mit 00, Erfolg. 343 davon nannten den Relay-Port 0, und an den lässt sich kein Datagramm schicken. 40 nannten eine private Adresse, die aus dem Internet nicht erreichbar ist. 15 nannten ein echtes Relay, das nie antwortete. Nur 28 Proxies sagten offen, mit dem Code 07, dass sie den Befehl nicht unterstützen.
Unser Test im September fand dasselbe Muster an einer kleineren Stichprobe. Am 2. September 2026 nahmen 19 von 40 SOCKS5-Einträgen mit hoher Verfügbarkeit UDP ASSOCIATE an, 17 davon nannten den Relay-Port 0, und keiner leitete eine Anfrage weiter. Dieser Test ist in SOCKS4 und SOCKS5 im Vergleich beschrieben.
Relays, die ihre Verbindung überleben
Ein weiterer Befund bricht den Standard. Nachdem ein funktionierendes Relay geantwortet hatte, schlossen wir seine TCP-Verbindung und schickten dieselbe Anfrage noch einmal. 9 der 16 Relays antworteten trotzdem, und im zweiten Lauf 10 von 17. Diese Relays überleben die Zuordnung, die laut RFC 1928 beendet ist.
Welche Clients können SOCKS5 UDP nutzen?
Der Proxy ist die eine Hälfte. Der Client muss UDP ASSOCIATE selbst schicken, und viele verbreitete Clients tun das nie:
| Client | SOCKS5 UDP | Wo das steht |
|---|---|---|
| Chrome | Nein | Dokumentation von Chromium: SOCKSv5 „kann nicht genutzt werden, um UDP-Traffic weiterzuleiten“ |
| Tor | Nein | SOCKS-Spezifikation von Tor: UDP ASSOCIATE „wird nicht unterstützt“ |
OpenSSH ssh -D | Nein | Quellcode von OpenSSH: „only socks5 connect supported“ |
| proxychains-ng | Nein | README 4.17: „Es unterstützt nur TCP (kein UDP/ICMP usw.)“ |
| PySocks (Python) | Ja, mit Einschränkungen | README: „UDP überwiegend unterstützt“ |
| Unser UDP-Proxy-Checker | Ja, als Test | Er schickt eine echte DNS-Anfrage durch das Relay |
Das beantwortet eine Suche, die uns erreicht: proxychains trägt kein UDP. ssh -D auch nicht, und das erklärt eine Frage auf Super User von 2013 zu einem SOCKS5-Tunnel, der für den Browser funktionierte und für UDP nicht. Ein Tool, das es unterstützt, sagt das in seiner eigenen Dokumentation.
Was braucht UDP durch einen Proxy?
Drei verbreitete Arten von Traffic:
- DNS. RFC 1035 (November 1987) gibt Nameservern „Zugang über Datagramme mit UDP“ auf Port 53. Deshalb ist eine DNS-Anfrage ein sauberer Test.
- HTTP/3. RFC 9000 (Mai 2021) sagt: „QUIC-Pakete werden in UDP-Datagrammen getragen“. Ein Proxy-Weg nur für TCP kann sie nicht tragen.
- Sprache und Video. RFC 3550 (Juli 2003) sagt, Anwendungen lassen „RTP typischerweise über UDP laufen“.
SOCKS5 ist nicht mehr der einzige Weg. RFC 9298 (IETF, August 2022) beschreibt, „wie man UDP in HTTP weiterleitet, ähnlich wie die Methode HTTP CONNECT das Weiterleiten von TCP erlaubt“. Das ist ein eigener Mechanismus, und unsere Tests auf dieser Seite decken ihn nicht ab.
Wie testen Sie einen Proxy auf UDP?
Schicken Sie echten Traffic und warten Sie auf die Antwort. Ein gewährtes UDP ASSOCIATE beweist nichts, wie die 343 Relays mit Port 0 zeigen. Unser UDP-Proxy-Checker macht den ganzen Test im Browser: Er öffnet eine Zuordnung, schickt über das Relay eine DNS-Anfrage für dns.google und sagt nur dann Ja, wenn eine DNS-Antwort zurückkommt. Denselben Test gibt es über die API unseres Checkers mit measure_udp auf true, wie die Dokumentation unseres kostenlosen Proxy-Checkers beschreibt.
Wenn Sie Ihren eigenen Test schreiben, halten Sie die TCP-Verbindung offen, bis die Antwort da ist, denn ihr Schließen sollte das Relay beenden. Eine Zeitüberschreitung beweist nicht, dass einem Proxy UDP fehlt, weil UDP selbst keine Zustellung verspricht. Versuchen Sie es noch einmal oder mit einem anderen Resolver, bevor Sie urteilen. In unserem ersten Lauf sagte der Checker bei 17 Proxies Ja und unser Skript bei 16, und bei 15 waren sie sich einig.
Was SOCKS5 UDP nicht leistet
- Keine Verschlüsselung. RFC 1928 verpackt Datagramme nur dann geschützt, wenn die gewählte Anmeldemethode einen eigenen Schutz mitbringt, und die übliche Methode mit Benutzername und Passwort tut das nicht. Eine Ranking-Seite behauptet, SOCKS5 UDP verschlüssele Ihren Traffic; der Standard stützt das nicht.
- Nicht standardmäßig an. Die meisten SOCKS5-Proxies in unserem Test lehnten UDP ab oder sagten Ja ohne funktionierendes Relay.
- Nichts, was Ihr Client von selbst tut. Kennt der Client nur TCP, ändert ein Proxy mit UDP nichts.
Wie es weitergeht
Für die Grundlagen des Protokolls lesen Sie Was ist ein SOCKS5-Proxy?. Für die Fehler, die ein SOCKS5-Client ausgibt, lesen Sie Fehler bei SOCKS5-Proxies erklärt. In unserem Netz öffnen SOCKS5-Leitungen von Residential Premium, die mit udp: true erzeugt werden, ein UDP-Relay; mehr dazu bei UDP-Residential-Proxies.
Was diese Seite nicht prüfen konnte
Unsere Stichprobe stammt von öffentlichen SOCKS5-Proxies unserer eigenen kostenlosen Liste; Proxies bezahlter Anbieter waren nicht dabei. Für diese Seite haben wir kein UDP-Relay über unser eigenes Netz laufen lassen, weil das einen Tarif braucht. Fragmentierung, IPv6-Relays, langlebige Zuordnungen und QUIC über SOCKS5 wurden nicht getestet. Die beiden Läufe, acht Minuten auseinander, nutzten weitgehend dieselben Proxies, sie zeigen also eine Wiederholung derselben Stichprobe. Die Tabelle der Clients stützt sich auf die eigenen Dokumente und den Code jedes Projekts; laufen lassen haben wir nicht jeden Client. Der Anteil öffentlicher Proxies, die UDP weiterleiten, kann sich ändern, wenn sich die Liste ändert, deshalb werden diese Zahlen bis zum 10. Januar 2027 neu gemessen.
Quellen
- RFC 1928, SOCKS Protocol Version 5, IETF, März 1996.
- RFC 768, User Datagram Protocol, IETF, August 1980.
- RFC 1035, Domain Names: Implementation and Specification, IETF, November 1987.
- RFC 9000, QUIC: A UDP-Based Multiplexed and Secure Transport, IETF, Mai 2021.
- RFC 3550, RTP: A Transport Protocol for Real-Time Applications, IETF, Juli 2003.
- RFC 9298, Proxying UDP in HTTP, IETF, August 2022.
- Chromium, Proxy support in Chrome, gelesen am 10. Oktober 2026.
- The Tor Project, SOCKS extensions, gelesen am 10. Oktober 2026.
- OpenSSH, channels.c in openssh-portable, gelesen am 10. Oktober 2026.
- README von proxychains-ng, Version 4.17.
- README von PySocks, gelesen am 10. Oktober 2026.
- Dokumentation von HProxy: Tarife und Erzeugen von Leitungen und der kostenlose Proxy-Checker, gelesen am 10. Oktober 2026.
- Fragen, die Leute gestellt haben, als Beispiele zitiert und ohne Beweiskraft: Stack Overflow 53361320 (November 2018); Super User 639425 (September 2013).
- Unsere eigenen Messungen, 10. Oktober 2026: der UDP-Test unseres Checkers an 692 öffentlichen SOCKS5-Proxies um 19:44 und 19:52 UTC, unsere Prüfung über rohe Sockets an den 575, die antworteten, und drei Aufzeichnungen auf Byte-Ebene. Die Prüfskripte und eine Tabelle jedes Ergebnisses ohne Adressen liegen bei der Recherche zu dieser Seite.
