UDP über SOCKS5: Der UDP ASSOCIATE-Befehl, warum HTTP-Proxys kein UDP unterstützen und wie man es prüft

Kennen Sie das? Sie haben einen Proxy eingerichtet, der Browser öffnet Websites, der Parser sammelt Daten, alles sieht perfekt aus. Und dann starten Sie einen Videoanruf – und Ihr Gesprächspartner hört Sie nicht. Oder Sie melden sich in einem Online-Spiel an, aber das Match verbindet sich nicht. Oder Sie starten einen Voice-Chat – und es bleibt still. Der Proxy funktioniert doch? Tut er. Aber auf einer tiefen Ebene ist etwas kaputt, und ohne Kenntnisse über den Transport ist das kaum zu verstehen.

Die Ursache ist fast immer dieselbe: Ihr Proxy lässt keinen UDP-Verkehr durch. Und das ist kein Defekt, sondern eine grundlegende Eigenschaft. Manche Proxy-Typen können standardmäßig mit UDP umgehen, andere können es prinzipiell nicht. Der Unterschied zwischen diesen beiden Welten bestimmt, ob bei Ihnen echte Kommunikation im Internet funktioniert oder nur das Laden von Webseiten.

In dieser Anleitung gehen wir das Thema vom Fundament bis zu praktischen Prüfwerkzeugen durch. Sie erfahren, wie der UDP ASSOCIATE-Befehl im SOCKS5-Protokoll funktioniert, warum HTTP-Proxys über die CONNECT-Methode physisch keine Datagramme übertragen können, was genau bei einem Benutzer ohne UDP kaputt geht und wie Sie selbst, buchstäblich in wenigen Minuten, jeden Proxy auf echte UDP-Unterstützung prüfen können. Wir sprechen nur über den Transport: ohne Analyse der Wahl zwischen Proxy-Typen und ohne Anleitungen zur Konfiguration bestimmter Anwendungen.

Grundlagen: TCP vs. UDP, Datagramme und die Arbeitsebene von Proxys

Um zu verstehen, warum UDP in der Proxy-Infrastruktur so empfindlich ist, müssen wir zu den grundlegenden Konzepten der Transportschicht zurückkehren. Keine Sorge: Wir erklären alles mit einfachen Analogien.

Zwei Transportprotokolle, zwei Philosophien

Im Internet werden Daten über zwei Haupttransportprotokolle übertragen: TCP (Transmission Control Protocol) und UDP (User Datagram Protocol). Beide arbeiten über IP, verhalten sich aber völlig unterschiedlich.

TCP ähnelt einem Telefonat mit ständiger Bestätigung. Bevor der Datenaustausch beginnt, stellen die beiden Seiten über einen Handshake eine Verbindung her. Jedes gesendete Paket wird vom Empfänger bestätigt. Wenn etwas verloren geht, wird es erneut gesendet. Die Reihenfolge der Pakete ist garantiert. Es ist ein zuverlässiger, geordneter, aber relativ langsamer Strom. TCP ist ideal zum Laden von Webseiten, Herunterladen von Dateien, Senden von E-Mails – überall dort, wo jedes Datenstück und die richtige Reihenfolge wichtig sind.

UDP ähnelt dem Versenden von Postkarten ohne Zustellbestätigung. Sie werfen ein Datagramm ins Netz und warten nicht auf eine Bestätigung. Es gibt keine Verbindungsherstellung, keine Liefergarantie, keine Reihenfolgegarantie. Ein Paket kann verloren gehen, doppelt ankommen oder in durcheinandergebrachter Reihenfolge – das Protokoll kümmert sich nicht darum. Klingt nach einem Nachteil? Nur auf den ersten Blick. Gerade diese Einfachheit verleiht UDP seinen Hauptvorteil: Geschwindigkeit und minimale Verzögerung.

Was ist ein Datagramm?

Ein Datagramm ist eine eigenständige Datenportion in UDP. Im Gegensatz zu TCP, wo die Daten als kontinuierlicher Bytestrom fließen, ist bei UDP jedes Paket in sich abgeschlossen. Es enthält die Zieladresse, den Port und die Nutzlast. Ein Datagramm weiß nichts über die Datagramme, die davor oder danach gesendet wurden. Es ist wie einzelne Briefe ohne Nummerierung in einer Korrespondenz.

Warum ist das für unser Thema wichtig? Weil ein Proxy, der einen kontinuierlichen TCP-Strom weiterleiten kann, nicht unbedingt in der Lage ist, einzelne eigenständige UDP-Datagramme weiterzuleiten. Das sind aus Implementierungssicht grundlegend unterschiedliche Aufgaben.

Wo genau in der Kette lebt ein Proxy?

Stellen wir uns das Netzwerkmodell als Stockwerke eines Gebäudes vor. In den unteren Etagen befinden sich die physikalische Signalübertragung und die IP-Adressierung. Darüber liegt die Transportschicht mit TCP und UDP. Noch höher liegt die Anwendungsschicht mit HTTP, DNS, Anrufprotokollen.

Ein Proxy-Server ist ein Vermittler, der zwischen Ihnen und der Zielressource steht. Aber auf welcher Ebene genau er arbeitet, hängt von seinem Typ ab. Und hier wird es interessant.

• HTTP-Proxys verstehen ursprünglich die Anwendungsschicht HTTP. Sie lesen HTTP-Anfragen, sehen Header, können sie modifizieren und cachen. Das sind Proxys, die auf ein bestimmtes Anwendungsprotokoll über TCP zugeschnitten sind.
• SOCKS-Proxys arbeiten tiefer, näher an der Transportschicht. Sie kümmern sich nicht um den Inhalt des Anwendungsprotokolls, sondern leiten einfach Verbindungen weiter. Deshalb ist SOCKS universeller: Es ist egal, ob Sie HTTP oder etwas Exotisches übertragen.

Dieser Unterschied in der Arbeitsebene ist der Kern der ganzen Geschichte. HTTP-Proxys sind in der Welt von HTTP über TCP gefangen. SOCKS5 ist als universeller Transportvermittler konzipiert, und genau deshalb wurde in seine Spezifikation ein Mechanismus zur UDP-Übertragung eingebaut.

Tiefer Einstieg: Wie SOCKS5 UDP überträgt

Das SOCKS5-Protokoll ist im RFC 1928-Standard beschrieben. Es ist ein kompaktes, elegantes Protokoll, und seine Logik zu verstehen, lohnt sich für jeden, der ernsthaft mit Proxys arbeitet. Lassen Sie uns seine Befehle und die besondere Funktionsweise der UDP-Übertragung durchgehen.

Drei SOCKS5-Befehle: CONNECT, BIND, UDP ASSOCIATE

Nachdem der Client eine Verbindung zum SOCKS5-Server hergestellt und die Authentifizierungsphase durchlaufen hat, sendet er eine Anfrage mit einem der drei Befehle. Jeder Befehl gibt an, welche Art von Operation benötigt wird.

• CONNECT (Code 0x01) ist der häufigste Befehl. Er sagt dem Proxy: Stelle für mich eine ausgehende TCP-Verbindung zur angegebenen Adresse und zum angegebenen Port her und leite dann Bytes in beide Richtungen weiter. Genau diesen Befehl verwendet Ihr Browser, wenn er über SOCKS5 ins Internet geht. 99 % des alltäglichen Traffics läuft über CONNECT.
• BIND (Code 0x02) ist ein Befehl für eingehende Verbindungen. Er wird für Protokolle wie klassisches FTP benötigt, bei denen der Server selbst eine Rückverbindung zum Client initiiert. Der Proxy öffnet einen Listening-Port und wartet auf eine eingehende Verbindung. Heute wird BIND selten verwendet.
• UDP ASSOCIATE (Code 0x03) ist der Star unseres Gesprächs. Dieser Befehl erstellt eine Assoziation für die Übertragung von UDP-Datagrammen über den Proxy. Genau das ermöglicht SOCKS5 die Arbeit mit Sprache, Video, Spielen, QUIC und DNS über UDP.

Wie UDP ASSOCIATE von innen funktioniert

Hier steckt ein raffinierter architektonischer Trick, der oft für Verwirrung sorgt. Der Befehl UDP ASSOCIATE wird über eine TCP-Verbindung gesendet. Ja, richtig gehört: Um mit der UDP-Übertragung zu beginnen, stellt der Client eine steuernde TCP-Verbindung zum Proxy her und sendet darüber den Befehl.

Warum wird eine steuernde TCP-Verbindung benötigt, wenn wir UDP übertragen wollen? Dafür gibt es mehrere Gründe, die in ihrer Praktikabilität genial sind.

1. Über TCP läuft die Authentifizierung und die Aushandlung der Parameter zuverlässig ab. UDP ist dafür ungeeignet, da es unzuverlässig ist.
2. Die steuernde TCP-Verbindung dient als Lebensindikator für die UDP-Assoziation. Solange die TCP-Verbindung offen ist, bleibt die UDP-Assoziation aktiv. Sobald der Client die steuernde TCP-Verbindung schließt, muss der Proxy sofort Ressourcen freigeben und die Weiterleitung von Datagrammen einstellen. Das ist eine elegante Methode zur Verwaltung der Lebensdauer.

Nach Erhalt des Befehls UDP ASSOCIATE weist der Proxy-Server einen speziellen Relay-Port für UDP zu und teilt dem Client dessen Adresse und Nummer in der Antwort mit. An diesen Relay-Port sendet der Client seine Datagramme, und der Proxy leitet sie an das Ziel weiter und gibt die Antworten zurück.

Rolle des Relay-Ports und der Bindungsadresse

In der Antwort auf UDP ASSOCIATE gibt der Server die Felder BND.ADDR und BND.PORT zurück. Das sind die Adresse und der Port, an die der Client seine UDP-Datagramme zur Weiterleitung senden muss. Ein wichtiger Punkt: Die Adresse in der Antwort kann sich von der Adresse unterscheiden, zu der der Client über TCP verbunden ist. Ein guter Client muss diese Adresse korrekt interpretieren, insbesondere wenn der Server eine Nulladresse zurückgibt, was bedeutet, denselben Host wie für die steuernde Verbindung zu verwenden.

An dieser Stelle scheitern viele Implementierungen. Eine falsche Verarbeitung von BND.ADDR führt dazu, dass der Client Datagramme an die falsche Adresse sendet, und die UDP-Übertragung schweigt, obwohl die Assoziation formal eingerichtet wurde.

Format der Kapselung eines UDP-Datagramms in SOCKS5

Es reicht nicht, ein UDP-Datagramm einfach an den Relay-Port zu senden. Der Proxy muss wissen, wohin er es weiterleiten soll. Daher wird jedes vom Client an den Relay-Port gesendete UDP-Datagramm in einen speziellen SOCKS5-Header eingepackt. Lassen Sie uns die Felder durchgehen, denn das Verständnis dieser Struktur unterscheidet den, der sich wirklich mit dem Thema auskennt.

Der UDP-Kapselungsheader besteht aus folgenden Feldern:

• RSV (2 Bytes) – reserviertes Feld, immer mit Nullen gefüllt. Für die Zukunft reserviert, aber derzeit ungenutzt.
• FRAG (1 Byte) – Fragmentnummer. Dieses Feld ist für die Fragmentierung großer Datagramme vorgesehen. Der Wert 0 bedeutet, dass das Datagramm einzeln steht und nicht fragmentiert ist. In der Praxis implementiert fast niemand die Fragmentierung von UDP über SOCKS5, und die meisten Server und Clients arbeiten nur mit FRAG gleich 0.
• ATYP (1 Byte) – Typ der Zieladresse. Kann 0x01 für IPv4, 0x03 für einen Domänennamen, 0x04 für IPv6 sein. Dieses Feld teilt dem Proxy mit, in welchem Format das nächste Adressfeld zu lesen ist.
• DST.ADDR (variable Länge) – Zieladresse des Datagramms. Die Länge hängt von ATYP ab: 4 Bytes für IPv4, 16 Bytes für IPv6, bei einem Domänennamen gibt das erste Byte die Länge an, gefolgt vom Namen selbst.
• DST.PORT (2 Bytes) – Zielport in Netzwerk-Byte-Reihenfolge.
• DATA – die eigentliche Nutzlast, also das ursprüngliche UDP-Datagramm der Anwendung.

Wenn der Proxy ein solches gekapseltes Datagramm am Relay-Port empfängt, entfernt er den SOCKS5-Header, liest die Zieladresse und den Zielport und sendet die reine Nutzlast als normales UDP-Paket an das Ziel. Wenn eine Antwort kommt, macht der Proxy den umgekehrten Vorgang: Er kapselt das Antwort-Datagramm in denselben Header und sendet es an den Client an den Relay-Port.

Beachten Sie die Eleganz des Schemas. Der Client kommuniziert nie direkt per UDP mit dem Ziel. Alles läuft über den Relay-Port des Proxys, und der Kapselungsheader dient als Adressetikett. Dies ist eine zuverlässige und standardisierte Methode, um einzelne Datagramme über einen Vermittler zu transportieren.

Warum das Feld FRAG meistens tot ist

Es lohnt sich, die Fragmentierung gesondert zu betrachten. Theoretisch erlaubt SOCKS5 die Aufteilung großer UDP-Datagramme in Fragmente und deren Zusammensetzung auf der Proxysite. In der Praxis verursacht dies enorme Komplexität: Fragmente müssen gepuffert, Timeouts für die Zusammensetzung verarbeitet und Angriffe abgewehrt werden. Daher verlangen die allermeisten Implementierungen einfach FRAG gleich 0 und verwerfen alles andere. Für Anwendungen bedeutet dies: Das Datagramm muss in ein einzelnes Paket passen. Glücklicherweise arbeiten die meisten realen Protokolle, die UDP verwenden, ohnehin mit kleinen Datagrammen.

Warum HTTP- und HTTPS-Proxys über CONNECT kein UDP übertragen können

Jetzt kommen wir zu der Frage, die die meisten Missverständnisse verursacht. Leute denken oft: Wenn ein HTTPS-Proxy verschlüsselten Traffic über die CONNECT-Methode tunneln kann, dann ist er universell und müsste auch UDP können. Das ist ein Fehler, und wir erklären jetzt, warum das grundsätzlich unmöglich ist.

Wie die CONNECT-Methode bei HTTP-Proxys funktioniert

Wenn ein Browser über einen HTTP-Proxy auf eine sichere Website geht, kann er nicht einfach eine HTTP-Anfrage senden, da der Inhalt verschlüsselt ist. Stattdessen sendet er einen speziellen CONNECT-Befehl mit Host und Port an den Proxy. Der Proxy stellt eine TCP-Verbindung zu diesem Host her und antwortet nach Erfolg mit einem Status, der den Tunnel bestätigt. Danach leitet der Proxy einfach Bytes zwischen Client und Server in beide Richtungen, ohne sich um den Inhalt zu kümmern.

Das Schlüsselwort hier ist TCP. Die CONNECT-Methode erstellt per Definition einen TCP-Tunnel. Sie öffnet eine streamorientierte TCP-Verbindung und verbindet zwei Byteströme. In der Definition von CONNECT gibt es keinen Mechanismus für die Arbeit mit Datagrammen.

Drei grundlegende Gründe für die Inkompatibilität

Lassen Sie uns Punkt für Punkt durchgehen, warum dies kein technisches Versehen, sondern eine konzeptionelle Unmöglichkeit ist.

1. CONNECT ist an das Stream-Modell gebunden. HTTP ist ein Protokoll über TCP. Die CONNECT-Methode erbt diese Stream-Natur. Sie kann zwei TCP-Ströme verbinden, aber UDP ist kein Strom, sondern eine Sammlung unabhängiger Datagramme. Es gibt keine Entsprechung zwischen ihnen. Man kann nicht viele einzelne Datagramme mit unterschiedlichen Zieladressen in einen einzigen TCP-Tunnel packen, ohne ein zusätzliches Kapselungsprotokoll, das HTTP CONNECT einfach nicht hat.
2. Es gibt keinen Adressierungsmechanismus für Datagramme. Bei UDP kann jedes Datagramm zu seiner eigenen Adresse und seinem eigenen Port fliegen. Eine Sprachanwendung kann gleichzeitig mit mehreren Servern kommunizieren. Ein CONNECT-TCP-Tunnel verbindet Sie mit einer bestimmten Adresse, die zum Zeitpunkt der Einrichtung festgelegt wird. Es gibt kein Feld zur Angabe der Zieladresse für jedes einzelne Datagramm, anders als bei SOCKS5 mit seinem Kapselungsheader DST.ADDR und DST.PORT.
3. Es gibt keinen Relay-Port für UDP. SOCKS5 weist speziell einen separaten UDP-Relay-Port zu und teilt ihn dem Client mit. HTTP-Proxys haben einen solchen Mechanismus grundsätzlich nicht. Ihre Architektur sieht keine Öffnung von UDP-Sockets auf der Serverseite zur Weiterleitung vor. Der Programmcode eines HTTP-Proxys arbeitet mit TCP-Verbindungen, und das Hinzufügen von UDP würde bedeuten, im Wesentlichen ein neues Protokoll zu schreiben.

Fazit, das Sie sich für immer merken sollten

HTTP- und HTTPS-Proxys unterstützen UDP nicht, weil die Entwickler faul waren, sondern weil ihr Protokoll ausschließlich um TCP herum aufgebaut ist. Die CONNECT-Methode ist ein TCP-Tunnel, Punkt. Wenn Sie UDP durch einen Proxy benötigen, ist der einzige Standardweg SOCKS5 mit Unterstützung für den Befehl UDP ASSOCIATE. Kein HTTP-Proxy, egal wie fortschrittlich, wird Sprache, Video oder Spielverkehr per UDP durchlassen.

Was genau ohne UDP kaputt geht: Eine vollständige Symptomkarte

Jetzt kommt der praktischste Teil. Lassen Sie uns durchgehen, welche Technologien von UDP abhängen und wie ihr Ausfall aus Sicht eines normalen Benutzers aussieht. Das hilft Ihnen, das Problem sofort anhand der Symptome zu diagnostizieren.

WebRTC und die STUN/TURN-Kombination

WebRTC ist eine Echtzeit-Technologie, auf der Videoanrufe im Browser, Sprachchats, Bildschirmfreigaben und viele Konferenzdienste basieren. Die Übertragung von Mediastreams erfolgt über UDP, weil für ein lebendiges Gespräch Geschwindigkeit wichtiger ist als die Garantie jedes Pakets. Ein geringer Paketverlust bei Sprache ist kaum wahrnehmbar, aber Verzögerungen durch TCP-Nachsendungen töten die Qualität.

Zum Verbindungsaufbau verwendet WebRTC die Protokolle STUN und TURN. STUN hilft, die eigene externe Adresse hinter NAT zu ermitteln, und TURN dient als Weiterleitung, wenn eine direkte Verbindung nicht möglich ist. Sowohl STUN als auch Mediastreams laufen standardmäßig über UDP.

Symptom aus Benutzersicht: Der Anruf scheint aufgebaut zu werden, es gibt eine Anrufanzeige, aber der Gesprächspartner hört und sieht Sie nicht, oder die Verbindung ist einseitig. Manchmal reißt der Anruf nach einigen Sekunden ab. Die Weboberfläche funktioniert, der Chat funktioniert, aber Ton und Bild kommen nicht. Das ist ein klassisches Zeichen für blockiertes UDP.

QUIC und HTTP/3 mit Rückfall auf TCP

QUIC ist ein modernes Transportprotokoll, das auf UDP aufbaut. Darauf basiert HTTP/3, die neueste Version des Webprotokolls. QUIC ermöglicht einen schnelleren Verbindungsaufbau und kommt besser mit Paketverlusten zurecht als klassisches TCP. Bis 2026 unterstützt ein erheblicher Anteil großer Websites und Dienste bereits HTTP/3.

Wenn UDP nicht verfügbar ist, passiert etwas Interessantes: Die Anwendung oder der Browser fällt normalerweise auf HTTP/2 oder HTTP/1.1 über TCP zurück. Dies ist ein in das Design integrierter Fehlertoleranzmechanismus.

Symptom aus Benutzersicht: Meistens gibt es keinen offensichtlichen Fehler, die Websites werden geöffnet. Aber Sie verlieren die Vorteile von QUIC: Verbindungen werden langsamer aufgebaut, bei instabilen Netzwerken kann es zu Verzögerungen kommen. Ein erfahrener Beobachter wird bemerken, dass HTTP/3 nicht verfügbar ist, obwohl der Server es unterstützt. Für die meisten ist dies eine versteckte Verschlechterung, kein offensichtlicher Ausfall.

DNS über Port 53 per UDP

Klassische DNS-Abfragen laufen traditionell über UDP auf Port 53. Das ist schnell und effizient für kurze Namensabfragen.

Hier gibt es eine Nuance, die davon abhängt, wie die Anwendung Namen auflöst. Wenn die Auflösung auf der Proxysite erfolgt, kann das Problem ausbleiben. Wenn die Anwendung jedoch selbst eine UDP-DNS-Abfrage über den Proxy senden möchte und UDP nicht unterstützt wird, schlägt die Auflösung fehl.

Symptom aus Benutzersicht: Webseitennamen werden nicht aufgelöst, die Anwendung meldet, dass der Host nicht gefunden wurde, obwohl das Internet funktioniert. Manchmal treten Verzögerungen auf, wenn das System zuerst UDP versucht, keine Antwort erhält und auf die TCP-Variante von DNS umschaltet.

VoIP und Sprachkommunikation

VoIP ist die Übertragung von Sprache über das Internet. Sprachprotokolle verwenden fast immer UDP zur Übertragung von Audio, da Verzögerungen kritisch sind. Ein Live-Gespräch ist unmöglich, wenn jedes Paket auf eine Bestätigung wartet.

Symptom aus Benutzersicht: Der Anruf kommt zustande, aber der Ton fehlt, ist unterbrochen oder stark verzögert. Einseitige Hörbarkeit, metallische Artefakte, Abbruch nach einigen Sekunden Gespräch. All dies sind Anzeichen für Probleme mit dem UDP-Transport.

Online-Spiele

Viele Netzwerkspiele, insbesondere dynamische Shooter und Wettkampftitel, verwenden UDP zur Übertragung des Spielweltstatus. Der Grund ist derselbe: Verzögerung ist wichtiger als Liefergarantie. Ein veraltetes Paket mit der Spielerposition ist nutzlos, besser ein frisches.

Symptom aus Benutzersicht: Das Spiel verbindet sich nicht mit dem Match, bleibt auf dem Verbindungsbildschirm hängen, bricht mit Timeout ab. Oder die Verbindung besteht, aber das Spiel ruckelt, Charaktere teleportieren sich, Aktionen werden nicht registriert. Menü und Shop können dabei funktionieren, da sie oft über HTTP und TCP laufen.

Torrents und P2P

Viele P2P-Protokolle nutzen UDP aktiv für den Austausch von Steuerinformationen und die Datenübertragung. Ohne UDP verschlechtert sich die Funktionalität: Teile der Peer-Erkennung und Datenübertragung funktionieren nicht.

Symptom aus Benutzersicht: Langsame Arbeitsgeschwindigkeit, Probleme bei der Quellensuche, unvollständige Funktionalität.

Übersichtstabelle der UDP-Abhängigkeit von Szenarien

Nachfolgend eine praktische Tabelle, die Sie sich merken sollten. Sie zeigt auf einen Blick, was in jedem Szenario zu erwarten ist.

• Videoanruf und Videochat. Verwendet UDP: ja, kritisch. Ohne UDP-Unterstützung: Anruf wird visuell aufgebaut, aber kein Ton und Video, einseitige Kommunikation oder Abbruch. Kernfunktionalität funktioniert nicht.
• Online-Spiel. Verwendet UDP: ja, für die meisten dynamischen Spiele. Ohne UDP-Unterstützung: Keine Verbindung zum Match, Timeouts, Ruckeln, Teleportation. Spielablauf unmöglich oder stark verschlechtert.
• DNS-Abfragen. Verwendet UDP: ja, klassisches DNS auf Port 53. Ohne UDP-Unterstützung: Mögliche Auflösungsprobleme oder Verzögerungen, wenn die Anwendung selbst auflöst; bei Auflösung auf Proxysite kann das Problem ausbleiben.
• QUIC und HTTP/3. Verwendet UDP: ja, vollständig auf UDP aufgebaut. Ohne UDP-Unterstützung: Unbemerkter Rückfall auf TCP HTTP/2, Verlust von Geschwindigkeit und Vorteilen, aber Websites werden geöffnet.
• Torrent und P2P. Verwendet UDP: ja, für viele Mechanismen. Ohne UDP-Unterstützung: Funktionsverschlechterung, Probleme bei der Quellensuche und Übertragung.
• Normales Parsing und Web-Scraping. Verwendet UDP: nein, normalerweise reines TCP über HTTP. Ohne UDP-Unterstützung: Alles funktioniert normal, UDP wird nicht benötigt.
• VoIP-Anruf. Verwendet UDP: ja, für den Sprachstrom. Ohne UDP-Unterstützung: Kein Ton, Abbrüche, Verzögerungen, einseitige Hörbarkeit.

Beachten Sie die letzte Zeile. Für klassische Aufgaben wie Parsing oder normales Web-Surfen wird UDP überhaupt nicht benötigt. Deshalb nutzen viele jahrelang Proxys ohne UDP und ahnen nichts von der Einschränkung, bis sie auf einen Anruf oder ein Spiel stoßen.

Praxis der Überprüfung: Wie Sie herausfinden, ob ein Proxy UDP unterstützt

Zeit für Werkzeuge. Wir werden mehrere Testmethoden durchgehen, von einfach bis fortgeschritten, und erklären, warum beliebte Methoden oft in die Irre führen.

Warum curl nur TCP prüft

Viele versuchen, einen Proxy mit einem Befehl wie curl über socks5-hostname auf eine Website zu testen. Wenn die Anfrage durchkommt, schließen sie: Der Proxy funktioniert, also funktioniert auch UDP. Das ist eine Falle.

Der Grund ist, dass eine HTTP-Anfrage über curl über TCP läuft. Der Befehl mit dem Flag socks5-hostname prüft, ob der SOCKS5-Proxy den CONNECT-Befehl ausführen und den Namen auf seiner Seite auflösen kann. Aber CONNECT ist TCP. Der Erfolg eines solchen Tests sagt nur aus, dass TCP durch den Proxy funktioniert. Über die Unterstützung von UDP ASSOCIATE sagt er gar nichts aus.

Merken Sie sich die eiserne Regel: Ein TCP-Test prüft kein UDP. Um UDP zu prüfen, müssen Sie explizit den Befehl UDP ASSOCIATE initiieren und versuchen, ein Datagramm zu übertragen.

Methode 1: Python-Skript mit Sockets

Der transparenteste Weg, UDP ASSOCIATE zu verstehen und zu prüfen, ist ein kleines Skript, das direkt mit Sockets arbeitet. Beschreiben wir die Logik schrittweise, ohne Bindung an konkreten Code, damit Sie das Wesentliche verstehen.

1. Öffnen Sie eine TCP-Verbindung zum Proxy. Verbinden Sie sich über einen normalen TCP-Socket mit dem Host und Port des SOCKS5-Servers.
2. Durchlaufen Sie die Begrüßungsphase. Senden Sie die Protokollversion und die Liste der unterstützten Authentifizierungsmethoden. Erhalten Sie die vom Server ausgewählte Methode. Führen Sie bei Bedarf eine Authentifizierung mit Benutzername und Passwort durch.
3. Senden Sie den Befehl UDP ASSOCIATE. Erstellen Sie eine Anfrage mit Version, Befehlscode 0x03, reserviertem Byte und Adresse. Als Adresse und Port werden oft Nullen angegeben, was bedeutet: Der Client weiß noch nicht, von welcher Adresse er Datagramme senden wird.
4. Lesen Sie die Antwort des Servers. Hier ist der entscheidende Punkt. Das erste Feld nach der Version ist der Antwortcode. Der Wert 0x00 bedeutet Erfolg. Wenn Sie 0x07 sehen, ist dies Command not supported, d. h. der Proxy kann UDP ASSOCIATE nicht. Andere Nicht-Null-Codes signalisieren ebenfalls einen Fehler.
5. Extrahieren Sie die Relay-Adresse. Bei Erfolg lesen Sie BND.ADDR und BND.PORT aus der Antwort. Das sind die Adresse und der Port für den Versand Ihrer Datagramme.
6. Senden Sie ein Test-Datagramm. Erstellen Sie einen UDP-Socket, kapseln Sie eine Test-Nutzlast in den SOCKS5-Header mit den Feldern RSV, FRAG, ATYP, DST.ADDR, DST.PORT und senden Sie diese an den Relay-Port. Als Ziel eignet sich ein öffentlicher Dienst, der über UDP antwortet.
7. Warten Sie auf eine Antwort. Wenn eine korrekt gekapselte Antwort eintrifft, funktioniert UDP über den Proxy tatsächlich. Wenn Stille herrscht, obwohl der Antwortcode erfolgreich war, dann besteht die Assoziation formal, aber die tatsächliche Weiterleitung von Datagrammen findet nicht statt.

Diese Methode liefert ein vollständiges Bild. Sie prüfen separat, ob der Server den Befehl UDP ASSOCIATE akzeptiert, und separat, ob Datagramme tatsächlich fliegen.

Methode 2: STUN-Anfrage über den Proxy

Ein hervorragender praktischer Test ist die Verwendung einer STUN-Anfrage als Nutzlast. STUN ist ein leichtes Protokoll, öffentliche STUN-Server antworten schnell, und dieser Test kommt dem realen WebRTC-Szenario am nächsten.

Die Logik ist dieselbe: Stellen Sie eine UDP-Assoziation her, kapseln Sie eine STUN-Anfrage vom Typ Binding Request in den SOCKS5-Kapselungsheader, senden Sie diese an den Relay-Port mit der Adresse eines öffentlichen STUN-Servers. Wenn eine STUN-Antwort mit Ihrer externen Adresse eintrifft, ist der UDP-Pfad durch den Proxy vollständig funktionsfähig, einschließlich der bidirektionalen Übertragung. Dies ist der überzeugendste Test für Echtzeit-Szenarien.

Methode 3: dig über den Proxy für DNS per UDP

Eine DNS-Anfrage ist ebenfalls ein guter Test, da es sich um ein kompaktes UDP-Datagramm mit einer klaren Antwort handelt. Die Idee ist, eine DNS-Anfrage per UDP über den SOCKS5-Proxy an einen öffentlichen DNS-Server zu senden.

Standardmäßig kann dig nicht über SOCKS5 per UDP gehen, daher wird normalerweise ein Hilfsprogramm verwendet, das den UDP-Verkehr durch den Proxy leitet, oder die Kapselung wird manuell nach dem oben beschriebenen Schema implementiert. Wenn eine DNS-Antwort eintrifft, funktioniert der UDP-Kanal. Wenn die Anfrage ins Leere geht, während TCP funktioniert, ist die Schlussfolgerung offensichtlich: UDP wird nicht unterstützt.

Methode 4: socat und Hilfsprogramme

Das Dienstprogramm socat ist ein mächtiges Schweizer Taschenmesser für die Arbeit mit Sockets. Damit können Sie Umleitungsketten erstellen, einschließlich der Kombination von UDP und SOCKS. Es ist jedoch wichtig, die Einschränkung zu verstehen: Nicht alle Versionen und Modi von socat unterstützen UDP ASSOCIATE direkt. Oft wird socat in Kombination mit einer Zwischenschicht verwendet, die die SOCKS5-UDP-Kapselung übernimmt, während socat für die lokale UDP-Umleitung zuständig ist.

Praktischer Ansatz: Starten Sie einen lokalen UDP-Empfänger, leiten Sie UDP-Verkehr über eine Zwischenschicht in den Proxy und prüfen Sie, ob die Nutzlast das Ziel erreicht und eine Antwort zurückkommt. Dies ist ein eher technischer Weg, der beim Debuggen der Infrastruktur nützlich ist.

So lesen Sie den Antwortcode 0x07 richtig

Der Code 0x07 Command not supported ist das ehrlichste und direkteste Signal. Er bedeutet, dass der SOCKS5-Server Ihren Befehl UDP ASSOCIATE empfangen und erkannt hat, aber antwortet: Ich führe diesen Befehl nicht aus. Eine solche Antwort ist typisch für Proxys, die nur CONNECT implementieren.

Seien Sie jedoch vorsichtig bei einem heimtückischeren Szenario. Manchmal antwortet der Server mit dem Erfolgscode 0x00 auf den Befehl UDP ASSOCIATE, aber die tatsächliche Weiterleitung von Datagrammen funktioniert nicht. Die Gründe sind vielfältig: ein Netzwerkfilter zwischen Proxy und Ziel, falsche Verarbeitung der Relay-Adresse, Einschränkungen des Hostings. Daher reicht es nicht, nur den Antwortcode zu prüfen. Der wahre Test ist die erfolgreiche Ende-zu-Ende-Übertragung eines Datagramms und der Empfang einer Antwort. Deshalb bestehen wir so auf einem STUN- oder DNS-Test mit einer tatsächlichen Antwort.

Checkliste zur Überprüfung der UDP-Unterstützung eines Proxys

• Stellen Sie sicher, dass Sie genau SOCKS5 testen und nicht einen HTTP-Proxy, da Letzterer per Definition kein UDP kann.
• Stellen Sie eine steuernde TCP-Verbindung her und führen Sie die Authentifizierung durch.
• Senden Sie den Befehl UDP ASSOCIATE und prüfen Sie den Antwortcode. 0x00 ist gut, 0x07 bedeutet fehlende Unterstützung.
• Extrahieren und interpretieren Sie BND.ADDR und BND.PORT korrekt, unter Berücksichtigung des Falls der Nulladresse.
• Senden Sie ein tatsächliches Test-Datagramm, das gemäß dem Kapselungsformat verpackt ist.
• Warten Sie auf eine korrekt gekapselte Antwort. Nur das bestätigt die UDP-Funktion.
• Wiederholen Sie den Test mehrere Male, um zufälligen Paketverlust auszuschließen.

UDP in mobilen Netzen: NAT-Timeouts und Keepalive

Ein separates und sehr wichtiges Thema ist das Verhalten von UDP in mobilen Netzen. Hier liegt die Ursache vieler rätselhafter Abbrüche, die unerklärlich erscheinen.

Warum eine UDP-Sitzung vorzeitig abbricht

Zwischen Ihrem Gerät und dem Internet befindet sich immer ein NAT (Network Address Translation), ein Mechanismus zur Übersetzung von Netzwerkadressen. NAT speichert eine Tabelle mit Zuordnungen von internen und externen Adressen und Ports. Für jede Verbindung wird ein Eintrag in dieser Tabelle erstellt, der nur eine begrenzte Zeit gültig ist.

Und hier ist der entscheidende Unterschied. Bei TCP hat NAT klare Signale für Verbindungsbeginn und -ende: NAT sieht den Handshake und die Schließung. Daher leben TCP-Einträge in der NAT-Tabelle normalerweise lange, manchmal zehn Minuten oder länger.

Bei UDP ist alles anders. UDP kennt keinen Verbindungsbegriff, daher weiß NAT nicht, wann eine Sitzung beginnt und endet. NAT behält den Eintrag einfach, solange Datenverkehr fließt, und löscht ihn nach einer Phase der Stille. Diese Phase der Stille wird als UDP-NAT-Timeout bezeichnet, und in mobilen Netzen ist sie oft sehr kurz, manchmal nur einige zehn Sekunden.

Ergebnis: Wenn über einen UDP-Kanal eine Weile kein Verkehr fließt, löscht NAT stillschweigend den Eintrag. Ihre nachfolgenden Datagramme können nicht mehr zurückgesendet werden, und die Sitzung bricht ab. Dabei würde eine TCP-Verbindung unter denselben Bedingungen weiterleben.

Wozu Keepalive?

Ein Keepalive ist das regelmäßige Senden kleiner Pakete, damit NAT die Sitzung als aktiv betrachtet und den Eintrag nicht löscht. Für UDP ist Keepalive aufgrund der kurzen Timeouts besonders kritisch.

Gut konzipierte Echtzeitprotokolle senden selbst periodische Keepalives oder Kontrollpakete. Beispielsweise bestätigt der Prüfmechanismus für die Verbindung in WebRTC ständig den Pfad. Wenn die Anwendung jedoch schweigt und das NAT-Timeout kurz ist, ist ein Abbruch unvermeidlich. Daher sollten Sie bei der Arbeit mit UDP über einen Proxy in mobilen Netzen die Notwendigkeit berücksichtigen, den Kanal aktiv zu halten.

Praktische Beobachtungen in mobilen Netzen

• Mobile Betreiber wenden oft eine aggressivere Richtlinie für UDP als für TCP an, um NAT-Ressourcen zu schonen.
• Das UDP-NAT-Timeout kann je nach Betreiber variieren und sich im Laufe der Zeit ändern, daher gibt es keinen einheitlichen Wert.
• Symptom eines kurzen Timeouts: Die Verbindung funktioniert in der aktiven Phase einwandfrei, bricht aber in Pausen ab, z. B. wenn der Gesprächspartner in einem Anruf schweigt.
• Die steuernde TCP-Verbindung für SOCKS5-UDP muss ebenfalls aktiv gehalten werden, da sonst der Proxy die gesamte Assoziation schließt.

Dies ist eine feine Nuance, die oberflächliches Verständnis von tiefem Wissen unterscheidet. Selbst wenn der Proxy UDP ASSOCIATE korrekt unterstützt, kann die Instabilität vom mobilen NAT und nicht vom Proxy selbst ausgehen. Denken Sie bei der Diagnose von Abbrüchen immer an den Faktor Timeout.

Typische Fehler bei der Arbeit mit UDP über einen Proxy

Fassen wir die häufigsten Missverständnisse an einem Ort zusammen. Wenn Sie sie vermeiden, sparen Sie Stunden des Debuggings.

Fehler 1: Verwechslung von socks5 und socks5h

In den Einstellungen vieler Tools gibt es zwei Schreibweisen für SOCKS5. Die Notation socks5 bedeutet normalerweise, dass die Auflösung des Domänennamens lokal auf der Clientseite erfolgt und der Proxy die fertige IP-Adresse erhält. Die Notation socks5h bedeutet, dass die Auflösung auf der Proxyserver-Seite erfolgt.

Warum ist das wichtig? Erstens kann die lokale Auflösung über Ihr normales DNS erfolgen, was für Privatsphäre-Aufgaben unerwünscht ist. Zweitens kann sich bei falscher Auswahl ein Teil der Logik anders verhalten als erwartet. Die Verwechslung von socks5 und socks5h führt zu schwer fassbaren Fehlern, bei denen der Proxy scheinbar nur manchmal funktioniert. Wählen Sie immer bewusst, wo der Name aufgelöst wird.

Fehler 2: Zu glauben, dass SOCKS5 automatisch UDP bedeutet

Dies ist vielleicht das häufigste und gefährlichste Missverständnis. Der Standard SOCKS5 sieht den Befehl UDP ASSOCIATE vor, verpflichtet jedoch nicht jede Implementierung, ihn zu unterstützen. Eine riesige Anzahl von SOCKS5-Proxys implementiert nur CONNECT und BIND und antwortet auf UDP ASSOCIATE mit dem Code 0x07.

Mit anderen Worten: Die Aufschrift SOCKS5 ist keine Garantie für UDP. Es ist lediglich eine Möglichkeit, die implementiert sein kann oder nicht. Der einzige Weg, es sicher zu wissen, ist der oben beschriebene Test. Verlassen Sie sich niemals auf Marketing-Labels, sondern auf echte Tests.

Fehler 3: UDP mit dem Browser prüfen

Manche versuchen, die UDP-Unterstützung zu prüfen, indem sie einfach eine Website über den Proxy im Browser öffnen. Aber der Browser geht über TCP auf Websites zu. Selbst wenn die Website HTTP/3 über UDP unterstützt, fällt der Browser bei Nichtverfügbarkeit von UDP stillschweigend auf TCP zurück, und Sie bemerken nichts. Das erfolgreiche Öffnen einer Seite beweist keine UDP-Funktion.

Darüber hinaus verfügt WebRTC im Browser über eine eigene komplexe Logik zur Umgehung von Netzwerkbeschränkungen und kann in einigen Konfigurationen TURN über TCP verwenden, was das Bild zusätzlich verwirrt. Daher ist der Browser ein schlechtes Werkzeug für einen reinen UDP-Transporttest. Verwenden Sie direkte Socket-Tests.

Fehler 4: Ende-zu-Ende-Test ignorieren

Wie bereits betont, ist der Antwortcode 0x00 auf UDP ASSOCIATE nicht gleichbedeutend mit funktionierendem UDP. Der Fehler besteht darin, sich nur auf den Antwortcode zu verlassen. Führen Sie den Test immer bis zum tatsächlichen Austausch von Datagrammen und dem Empfang einer Antwort durch. Das trennt formale Unterstützung von tatsächlicher Funktionsfähigkeit.

Fehler 5: Keepalive und Timeouts nicht berücksichtigen

Nach der Einrichtung von UDP vergisst man leicht die NAT-Timeouts. Dann funktioniert der Kanal zum Zeitpunkt des Tests, bricht aber in der realen Nutzung während Pausen ab. Planen Sie immer einen Mechanismus ein, um den Kanal aktiv zu halten, insbesondere in mobilen Netzen.

Fehler 6: Falsche Verarbeitung der Relay-Adresse

Wie erwähnt, kann der Server in BND.ADDR eine Nulladresse zurückgeben, was denselben Host wie die steuernde Verbindung bedeutet. Clients, die blind Datagramme an die Nulladresse senden, brechen ab. Eine korrekte Implementierung setzt die Proxy-Adresse aus der TCP-Verbindung ein. Diese Nuance verursacht viele stille Ausfälle.

Werkzeuge und Ressourcen für die Arbeit mit UDP über SOCKS5

Fassen wir das praktische Arsenal zusammen, das Sie griffbereit haben sollten.

Diagnosewerkzeuge

• Eigenes Python-Skript mit Sockets. Das flexibelste und transparenteste Werkzeug. Gibt Ihnen die volle Kontrolle über die Erstellung des UDP ASSOCIATE-Befehls und die Kapselung von Datagrammen. Ideal für präzise Diagnosen.
• STUN-Client über den Proxy. Der beste Test für Echtzeit-Szenarien. Schnelle Antwort, klares Ergebnis, maximal nah an WebRTC.
• DNS-Test per UDP. Kompakt und anschaulich, ideal zum Testen der End-to-End-Übertragung kurzer Datagramme.
• socat und Zwischenschichten für UDP-Kapselung. Ingenieurswerkzeuge zum Aufbau und Debuggen von Umleitungsketten für UDP über SOCKS5.
• Verkehrsanalysator. Die Beobachtung von Paketen hilft zu sehen, ob Datagramme tatsächlich zum Relay-Port gesendet werden und ob Antworten eingehen. Unverzichtbar für tiefgehendes Debugging.

Was Sie über Standards wissen sollten

Das Schlüsseldokument für SOCKS5 ist RFC 1928, in dem die Befehle, das Anfrage- und Antwortformat sowie die UDP-Kapselung beschrieben werden. Das Verständnis dieses Standards unterscheidet einen Experten von einem Benutzer, der nur rät. Darüber hinaus ist es hilfreich, die Prinzipien von STUN, QUIC und der NAT-Funktionsweise zu verstehen, da genau an der Schnittstelle dieser Technologien praktische Probleme mit UDP auftreten.

Mini-Entscheidungsrahmen

1. Bestimmen Sie, ob Sie UDP überhaupt benötigen. Für Parsing und normales Web: nein, für Anrufe, Spiele, Echtzeit: ja.
2. Wenn UDP benötigt wird, stellen Sie sicher, dass der Proxy genau SOCKS5 und nicht HTTP ist.
3. Überprüfen Sie die tatsächliche Unterstützung von UDP ASSOCIATE mit einem End-to-End-Test, nicht nach Etikett.
4. Berücksichtigen Sie Keepalive und NAT-Timeouts, insbesondere in mobilen Netzen.
5. Verarbeiten Sie die Relay-Adresse und das Kapselungsformat korrekt.

Fallbeispiele und Anwendungsergebnisse

Lassen Sie uns einige typische Situationen durchgehen, die zeigen, wie Transportwissen reale Probleme löst.

Fall 1: Stummer Videoanruf

Situation. Ein Benutzer beschwert sich, dass über den Proxy alle Websites geöffnet werden, der Chat in der Konferenz funktioniert, aber während des Anrufs weder Ton noch Video vorhanden sind. Die Gesprächspartner sehen eine Verbindungsanzeige, aber es gibt keine Kommunikation.

Diagnose. Der TCP-Test über den Proxy verläuft erfolgreich, was zunächst verwirrt. Dann wird ein End-to-End-STUN-Test über UDP ASSOCIATE durchgeführt. Der Server antwortet auf den Befehl mit dem Code 0x07 Command not supported.

Fazit. Der Proxy implementiert nur CONNECT, UDP wird überhaupt nicht unterstützt. Der WebRTC-Mediastream über UDP kommt nicht durch, daher die Stille. Lösung auf Transportebene: Ein SOCKS5 mit echter UDP ASSOCIATE-Unterstützung, bestätigt durch einen End-to-End-Test, ist erforderlich.

Fall 2: Verbindungsabbruch in Pausen im mobilen Netz

Situation. Die Sprachverbindung über den Proxy im mobilen Netz funktioniert bei aktivem Gespräch einwandfrei, aber sobald die Gesprächspartner eine halbe Minute schweigen, bricht die Verbindung ab.

Diagnose. Der End-to-End-UDP-Test verläuft erfolgreich, Datagramme fliegen in beide Richtungen. Der Proxy selbst unterstützt UDP also. Die Beobachtung des Verhaltens zeigt, dass die Abbrüche genau in den Pausen ohne Datenverkehr auftreten.

Fazit. Der Übeltäter ist das kurze UDP-NAT-Timeout des Mobilfunkanbieters. Der Eintrag in der NAT-Tabelle wird während der Stille gelöscht. Lösung auf Transportebene: Bereitstellung von Keepalive, das den Kanal und die steuernde TCP-Verbindung aktiv hält.

Fall 3: Falsche Sicherheit durch Code 0x00

Situation. Ein Ingenieur hat den Proxy getestet, den Befehl UDP ASSOCIATE gesendet, den Erfolgscode 0x00 erhalten und verkündet, dass UDP funktioniert. Aber die Benutzer beschweren sich weiterhin über nicht funktionierende Anrufe.

Diagnose. Der erneute Test geht über den Antwortcode hinaus: Ein echtes STUN-Datagramm wird an den Relay-Port gesendet. Trotz des erfolgreichen Codes kommt keine Antwort.

Fazit. Formale Unterstützung ist vorhanden, aber tatsächliche Weiterleitung nicht, wahrscheinlich aufgrund von Filterung zwischen Proxy und externem Netz oder eines Fehlers bei der Verarbeitung der Relay-Adresse. Lektion: Code 0x00 reicht nicht aus; nur die End-to-End-Übertragung eines Datagramms beweist die Funktionsfähigkeit.

Fall 4: Versteckte Verschlechterung von HTTP/3

Situation. Alles scheint zu funktionieren, Websites werden geöffnet, keine Beschwerden, aber das Team stellt fest, dass Verbindungen langsamer aufgebaut werden als erwartet und HTTP/3 nirgendwo genutzt wird.

Diagnose. Der Test zeigt, dass UDP über den Proxy nicht durchkommt, daher ist QUIC nicht verfügbar, und die Clients fallen stillschweigend auf TCP zurück.

Fazit. Dies ist kein Fehler, sondern ein versteckter Leistungsverlust. Das Verständnis des Transports ermöglicht eine bewusste Entscheidung, ob QUIC für die Aufgabe wichtig ist, und bei Bedarf die Sicherstellung der UDP-Unterstützung.

FAQ: Häufig gestellte Fragen

Kann man UDP überhaupt auf irgendeine Weise durch einen HTTP-Proxy übertragen?

Mit Standardmitteln nicht. Die CONNECT-Methode in HTTP-Proxys erstellt ausschließlich einen TCP-Tunnel und hat keinen Mechanismus zur Adressierung und Weiterleitung von Datagrammen. Jegliche Versuche, UDP durch einen reinen HTTP-Proxy zu pressen, scheitern am Fehlen eines entsprechenden Protokolls. Für UDP ist SOCKS5 mit dem Befehl UDP ASSOCIATE gedacht. Das ist der richtige und standardisierte Weg.

Wenn ein Proxy SOCKS5 heißt, unterstützt er dann automatisch UDP?

Nein, und das ist eine der wichtigsten Nuancen. Der Standard sieht UDP ASSOCIATE vor, verlangt aber keine zwingende Implementierung. Viele SOCKS5-Proxys unterstützen nur CONNECT. Der einzige zuverlässige Weg, sich zu vergewissern, ist ein End-to-End-Test mit einer tatsächlichen Datagramm-Übertragung, nicht das Vertrauen auf den Namen oder das Marketing.

Warum zeigt curl, dass der Proxy funktioniert, aber der Anruf kommt nicht zustande?

Weil curl TCP über den CONNECT-Befehl prüft, während der Anruf UDP verwendet. Es sind zwei verschiedene Transporte. Der Erfolg eines TCP-Tests sagt nichts über UDP aus. Um UDP zu prüfen, müssen Sie UDP ASSOCIATE initiieren und ein Datagramm senden, z. B. eine STUN-Anfrage, und auf eine Antwort warten.

Was bedeutet der Antwortcode 0x07 bei einem UDP ASSOCIATE-Versuch?

Das ist Command not supported. Der Proxy hat Ihren Befehl empfangen und erkannt, teilt Ihnen aber mit, dass er UDP ASSOCIATE nicht ausführt. Praktisch bedeutet das, dass der Proxy kein UDP weiterleiten kann. Sie benötigen einen anderen Proxy mit echter Unterstützung für diesen Befehl.

Warum verwendet UDP ASSOCIATE eine TCP-Verbindung, wenn wir UDP übertragen?

Die steuernde TCP-Verbindung dient zwei Zwecken. Erstens werden darüber Authentifizierung und Aushandlung zuverlässig durchgeführt. Zweitens definiert sie die Lebensdauer der UDP-Assoziation: Solange das TCP offen ist, ist die Assoziation aktiv; sobald es geschlossen wird, gibt der Proxy die Ressourcen frei. Das ist eine elegante Möglichkeit, die Sitzung zu verwalten und zu bereinigen.

Warum bricht die UDP-Verbindung im mobilen Netz ab, während TCP hält?

Aufgrund der Besonderheiten von NAT. Bei TCP hat NAT explizite Signale für Beginn und Ende, daher leben Einträge lange. UDP kennt keinen Verbindungsbegriff, und NAT löscht den Eintrag nach einer kurzen Stillephase. In mobilen Netzen ist das UDP-Timeout besonders kurz. Lösung: Regelmäßiges Keepalive, das den Kanal aktiv hält.

Kann man die UDP-Unterstützung direkt im Browser prüfen?

Zuverlässig nicht. Der Browser geht über TCP auf Websites zu und fällt bei Nichtverfügbarkeit von UDP stillschweigend auf TCP für QUIC zurück. WebRTC im Browser hat eine komplexe Logik und kann Umgehungsmechanismen nutzen. All dies maskiert den tatsächlichen UDP-Status. Für einen reinen Test verwenden Sie direkte Socket-Tests, STUN oder DNS über UDP ASSOCIATE.

Was ist in der Praxis der Unterschied zwischen socks5 und socks5h?

Der Unterschied liegt darin, wo der Domänenname aufgelöst wird. Bei socks5 wird der Name normalerweise lokal auf der Clientseite aufgelöst, bei socks5h auf der Proxysite. Dies beeinflusst sowohl die Privatsphäre der Auflösung als auch das Verhalten in einigen Szenarien. Eine bewusste Wahl der Notation vermeidet schwer fassbare Fehler.

Muss man die Fragmentierung von Datagrammen in SOCKS5 implementieren?

In der Praxis nicht. Das FRAG-Feld ist im Standard vorgesehen, aber die allermeisten Implementierungen arbeiten nur mit FRAG gleich 0, also ohne Fragmentierung. Datagramme müssen in ein einzelnes Paket passen. Reale Protokolle, die UDP verwenden, arbeiten normalerweise mit kleinen Datagrammen, daher verursacht dies selten Probleme.

Wie unterscheidet man ein Problem des Proxys von einem Problem des mobilen NAT?

Führen Sie einen End-to-End-UDP-Test durch. Wenn er gar nicht funktioniert und der Befehl 0x07 zurückgibt oder Datagramme nicht ankommen, liegt das Problem am Proxy. Wenn der Test erfolgreich ist, die Abbrüche aber nur in Pausen im realen Betrieb auftreten, ist mit hoher Wahrscheinlichkeit ein kurzes UDP-NAT-Timeout schuld. Diese Analyse lokalisiert die Quelle genau.

Fazit: Der Transport entscheidet alles

Wir haben den Weg von den grundlegenden Konzepten von TCP und UDP bis zu den Feinheiten der Datagramm-Kapselung in SOCKS5 und den heimtückischen NAT-Timeouts in mobilen Netzen zurückgelegt. Lassen Sie uns die wichtigsten Schlussfolgerungen festhalten, die Sie von einem Benutzer, der im Trüben fischt, zu einem Menschen machen, der genau versteht, was auf der Transportebene passiert.

Erstens: UDP und TCP sind zwei verschiedene Welten. UDP transportiert einzelne Datagramme ohne Garantien, um der Geschwindigkeit willen, und darauf basieren Anrufe, Spiele, QUIC und klassisches DNS. Ein Proxy, der TCP weiterleiten kann, muss nicht unbedingt UDP können.

Zweitens: Nur SOCKS5 über den Befehl UDP ASSOCIATE bietet einen Standardweg für UDP. Der Mechanismus ist elegant: eine steuernde TCP-Verbindung, ein separater Relay-Port und die Kapselung jedes Datagramms in einen Header mit den Feldern RSV, FRAG, ATYP, DST.ADDR und DST.PORT.

Drittens: HTTP- und HTTPS-Proxys lassen UDP grundsätzlich nicht durch. Die CONNECT-Methode erstellt ausschließlich einen TCP-Tunnel; in ihrer Architektur gibt es weder eine Adressierung von Datagrammen noch einen Relay-Port noch einen Mechanismus zur UDP-Weiterleitung.

Viertens: Die Aufschrift SOCKS5 garantiert kein UDP. Überprüfen Sie dies immer mit einem End-to-End-Test, bei dem Sie ein Datagramm übertragen und eine Antwort erhalten. Der Code 0x00 ohne tatsächlichen Austausch beweist nichts, und der Code 0x07 teilt ehrlich das Fehlen der Unterstützung mit.

Fünftens: In mobilen Netzen ist UDP aufgrund kurzer NAT-Timeouts empfindlicher. Keepalive und die Aufrechterhaltung der steuernden Verbindung schützen vor rätselhaften Abbrüchen in Pausen.

Ihre nächsten Schritte sind einfach. Bestimmen Sie anhand unserer Szenario-Tabelle, ob Sie UDP für eine bestimmte Aufgabe benötigen. Wenn ja, stellen Sie sicher, dass Sie mit SOCKS5 arbeiten, und überprüfen Sie die tatsächliche Unterstützung von UDP ASSOCIATE mit Ihrem eigenen Test, sei es STUN, DNS oder ein direktes Socket-Skript. Planen Sie Keepalive ein und verarbeiten Sie die Relay-Adresse korrekt. Wenn Sie dies tun, werden Sie nie wieder in die Situation geraten, dass der Proxy scheinbar funktioniert, aber der Anruf stumm bleibt. Jetzt wissen Sie genau, wo Sie die Ursache suchen und wie Sie sie auf Transportebene beheben können.