UDP przez SOCKS5: komenda UDP ASSOCIATE, dlaczego HTTP-proxy nie obsługuje UDP i jak to sprawdzić

Znajoma sytuacja: skonfigurowałeś proxy, przeglądarka otwiera strony, parser zbiera dane, wszystko wygląda idealnie. A potem uruchamiasz wideorozmowę i rozmówca cię nie słyszy. Albo wchodzisz do gry online i mecz się nie łączy. Albo uruchamiasz czat głosowy i milczy. Przecież proxy działa? Działa. Ale coś jest zepsute na głębokim poziomie i zrozumienie tego bez wiedzy o transporcie jest praktycznie niemożliwe.

Przyczyna jest prawie zawsze ta sama: twoje proxy nie przepuszcza ruchu UDP. I to nie jest usterka, ale fundamentalna cecha. Niektóre typy proxy potrafią pracować z UDP zgodnie ze standardem, inne w ogóle nie umieją. Różnica między tymi dwoma światami decyduje o tym, czy będziesz mieć działającą prawdziwą komunikację w internecie, czy tylko ładowanie stron internetowych.

W tym przewodniku przeanalizujemy temat od samych podstaw po praktyczne narzędzia do sprawdzania. Dowiesz się, jak działa komenda UDP ASSOCIATE w protokole SOCKS5, dlaczego HTTP-proxy przez metodę CONNECT nie może fizycznie przesyłać datagramów, co konkretnie psuje się u użytkownika bez UDP i jak samodzielnie, dosłownie w kilka minut, sprawdzić każde proxy pod kątem rzeczywistej obsługi UDP. Będziemy mówić tylko o transporcie: bez analizy wyboru między typami proxy i bez instrukcji konfiguracji konkretnych aplikacji.

Podstawy: TCP kontra UDP, datagramy i poziom działania proxy

Aby zrozumieć, dlaczego UDP jest tak kapryśny w infrastrukturze proxy, trzeba wrócić do podstawowych pojęć warstwy transportowej. Nie bój się: wyjaśnimy wszystko prostymi analogiami.

Dwa protokoły transportowe, dwie filozofie

W internecie dane przesyłane są za pomocą dwóch głównych protokołów transportowych: TCP (Transmission Control Protocol) i UDP (User Datagram Protocol). Oba działają na bazie IP, ale zachowują się zupełnie inaczej.

TCP przypomina rozmowę telefoniczną z ciągłym potwierdzaniem. Zanim rozpocznie się wymiana danych, obie strony nawiązują połączenie przez procedurę uzgadniania. Każdy wysłany pakiet jest potwierdzany przez odbiorcę. Jeśli coś się zgubi, jest przesyłane ponownie. Kolejność pakietów jest gwarantowana. To niezawodny, uporządkowany, ale stosunkowo wolny strumień. TCP jest idealny do ładowania stron internetowych, pobierania plików, wysyłania poczty – wszędzie tam, gdzie liczy się każda porcja danych i ich właściwa kolejność.

UDP przypomina wysyłanie pocztówek bez potwierdzenia doręczenia. Wrzucasz datagram do sieci i nie czekasz na potwierdzenie. Brak nawiązywania połączenia, brak gwarancji dostarczenia, brak gwarancji kolejności. Pakiet może się zgubić, przyjść dwa razy lub w pomieszanej kolejności, a protokół się tym nie przejmuje. Brzmi jak wada? Tylko na pierwszy rzut oka. To właśnie ta prostota daje UDP główną zaletę: szybkość i minimalne opóźnienie.

Czym jest datagram

Datagram to samodzielna porcja danych w UDP. W przeciwieństwie do TCP, gdzie dane płyną ciągłym strumieniem bajtów, w UDP każdy pakiet jest samowystarczalny. Zawiera adres docelowy, port i ładunek. Datagram nie wie nic o datagramach wysłanych przed nim ani po nim. To jak oddzielne listy bez numeracji w ogólnej korespondencji.

Dlaczego to ważne dla naszego tematu? Ponieważ proxy, które potrafi przesyłać ciągły strumień TCP, wcale nie musi umieć przesyłać rozproszonych, samodzielnych datagramów UDP. To zasadniczo różne zadania z punktu widzenia implementacji.

Gdzie dokładnie w łańcuchu znajduje się proxy

Wyobraźmy sobie model sieci jako piętra budynku. Na niższych piętrach mamy fizyczną transmisję sygnałów i adresację IP. Wyżej warstwa transportowa z TCP i UDP. Jeszcze wyżej warstwa aplikacji z HTTP, DNS i protokołami rozmów.

Serwer proxy to pośrednik, który stoi między tobą a zasobem docelowym. Ale na którym dokładnie poziomie działa, zależy od jego typu. I tutaj zaczyna się najciekawsze.

• HTTP-proxy początkowo rozumie warstwę aplikacji HTTP. Czyta żądania HTTP, widzi nagłówki, potrafi je modyfikować i buforować. To proxy wyspecjalizowane w konkretnym protokole aplikacyjnym na bazie TCP.
• SOCKS-proxy działa niżej, bliżej warstwy transportowej. Nie wnika w treść protokołu aplikacyjnego, a po prostu przekierowuje połączenia. Dlatego SOCKS jest bardziej uniwersalny: nie ma znaczenia, co przesyłasz – HTTP czy coś egzotycznego.

Ta różnica w poziomie działania jest źródłem całej historii. HTTP-proxy jest zamknięty w świecie HTTP na bazie TCP. SOCKS5 został zaprojektowany jako uniwersalny pośrednik transportowy i właśnie dlatego do jego specyfikacji dodano mechanizm przesyłania UDP.

Głębokie zanurzenie: jak SOCKS5 przesyła UDP

Protokół SOCKS5 został opisany w standardzie RFC 1928. To kompaktowy, elegancki protokół i zrozumienie jego logiki warto każdemu, kto poważnie pracuje z proxy. Przeanalizujmy jego komendy i specjalną strukturę transmisji UDP.

Trzy komendy SOCKS5: CONNECT, BIND, UDP ASSOCIATE

Po tym, jak klient połączy się z serwerem SOCKS5 i przejdzie etap uwierzytelniania, wysyła zapytanie z jedną z trzech komend. Każda komenda określa, jaki typ operacji jest potrzebny.

• CONNECT (kod 0x01) to najpopularniejsza komenda. Mówi proxy: nawiąż dla mnie wychodzące połączenie TCP do podanego adresu i portu, a następnie przekazuj bajty w obie strony. To właśnie tę komendę używa twoja przeglądarka, gdy korzysta z internetu przez SOCKS5. 99% codziennego ruchu przechodzi przez CONNECT.
• BIND (kod 0x02) to komenda dla połączeń przychodzących. Jest potrzebna protokołom takim jak klasyczny FTP, gdzie serwer sam inicjuje połączenie zwrotne do klienta. Proxy otwiera port nasłuchowy i czeka na połączenie przychodzące. Dziś BIND jest rzadko używane.
• UDP ASSOCIATE (kod 0x03) to gwiazda naszej rozmowy. Ta komenda tworzy asocjację do przesyłania datagramów UDP przez proxy. To właśnie ona pozwala SOCKS5 działać z głosem, wideo, grami, QUIC i DNS przez UDP.

Jak działa UDP ASSOCIATE od środka

Tutaj kryje się piękny trik architektoniczny, który często powoduje nieporozumienia. Komenda UDP ASSOCIATE jest wysyłana przez połączenie TCP. Tak, dobrze słyszałeś: aby rozpocząć przesyłanie UDP, klient nawiązuje kontrolne połączenie TCP z proxy i wysyła przez nie komendę.

Po co potrzebne jest kontrolne połączenie TCP, skoro chcemy przesyłać UDP? Jest kilka powodów i są genialne w swojej praktyczności.

1. Po TCP niezawodnie odbywa się uwierzytelnianie i uzgadnianie parametrów. UDP nie nadaje się do tego, ponieważ jest zawodny.
2. Kontrolne połączenie TCP służy jako wskaźnik życia asocjacji UDP. Dopóki połączenie TCP jest otwarte, asocjacja UDP działa. Gdy tylko klient zamknie kontrolne połączenie TCP, proxy musi natychmiast zwolnić zasoby i zaprzestać przekazywania datagramów. To elegancki sposób zarządzania czasem życia.

Po otrzymaniu komendy UDP ASSOCIATE serwer proxy przydziela specjalny relay-port dla UDP i informuje klienta o jego adresie i numerze w odpowiedzi. To właśnie na ten relay-port klient będzie wysyłał swoje datagramy, a proxy będzie przekazywać je dalej do celu i zwracać odpowiedzi z powrotem.

Rola relay-portu i adresu wiązania

W odpowiedzi na UDP ASSOCIATE serwer zwraca pola BND.ADDR i BND.PORT. To adres i port, na które klient musi kierować swoje datagramy UDP w celu retransmisji. Ważny niuans: adres w odpowiedzi może różnić się od adresu, do którego klient połączył się przez TCP. Kompetentny klient musi poprawnie interpretować ten adres, zwłaszcza gdy serwer zwraca adres zerowy, co oznacza użycie tego samego hosta co dla połączenia kontrolnego.

To na tym etapie potykają się liczne implementacje. Nieprawidłowe przetwarzanie BND.ADDR powoduje, że klient wysyła datagramy w złym kierunku i transmisja UDP po cichu nie działa, mimo że formalnie asocjacja została nawiązana.

Format enkapsulacji datagramu UDP w SOCKS5

Nie można po prostu wysłać datagramu UDP na relay-port. Proxy musi wiedzieć, dokąd go dalej przekazać. Dlatego każdy datagram UDP wysyłany przez klienta na relay-port jest owijany w specjalny nagłówek SOCKS5. Przeanalizujmy go pole po polu, ponieważ zrozumienie tej struktury odróżnia osobę, która naprawdę się na tym zna.

• RSV (2 bajty) – zastrzeżone pole, zawsze wypełniane zerami. Pozostawione na przyszłość, ale na razie nieużywane.
• FRAG (1 bajt) – numer fragmentu. To pole służy do fragmentacji dużych datagramów. Wartość 0 oznacza, że datagram jest samodzielny i niefragmentowany. W praktyce fragmentacja UDP przez SOCKS5 prawie nigdy nie jest implementowana, a większość serwerów i klientów działa tylko z FRAG równym zero.
• ATYP (1 bajt) – typ adresu docelowego. Może to być 0x01 dla IPv4, 0x03 dla nazwy domenowej, 0x04 dla IPv6. To pole informuje proxy, w jakim formacie odczytać następne pole adresu.
• DST.ADDR (zmienna długość) – adres docelowy datagramu. Jego długość zależy od ATYP: 4 bajty dla IPv4, 16 bajtów dla IPv6, a dla nazwy domenowej pierwszy bajt określa długość, po którym następuje sama nazwa.
• DST.PORT (2 bajty) – port docelowy w sieciowej kolejności bajtów.
• DATA – właściwy ładunek, czyli oryginalny datagram UDP aplikacji.

Kiedy proxy otrzymuje taki owinięty datagram na relay-port, usuwa nagłówek SOCKS5, odczytuje adres i port docelowy i wysyła czysty ładunek do miejsca docelowego jako zwykły pakiet UDP. Gdy przychodzi odpowiedź, proxy wykonuje operację odwrotną: owija odpowiedź w taki sam nagłówek i wysyła do klienta na relay-port.

Zwróć uwagę na elegancję tego schematu. Klient nigdy nie komunikuje się bezpośrednio z celem przez UDP. Wszystko przechodzi przez relay-port proxy, a nagłówek enkapsulacji służy jako etykieta adresowa. To niezawodny i standaryzowany sposób przenoszenia rozproszonych datagramów przez pośrednika.

Dlaczego pole FRAG jest najczęściej martwe

Warto zatrzymać się na fragmentacji osobno. Teoretycznie SOCKS5 pozwala dzielić duże datagramy UDP na fragmenty i składać je po stronie proxy. W praktyce tworzy to ogromną złożoność: trzeba buforować fragmenty, obsługiwać limity czasowe składania i bronić się przed atakami. Dlatego zdecydowana większość implementacji po prostu wymaga FRAG równego zero i odrzuca wszystko inne. Dla aplikacji oznacza to, że datagram musi zmieścić się w jednym pakiecie. Na szczęście większość rzeczywistych protokołów używających UDP i tak działa na małych datagramach.

Dlaczego HTTP i HTTPS-proxy przez CONNECT nie mogą przesyłać UDP

Teraz doszliśmy do pytania, które wywołuje najwięcej nieporozumień. Ludzie często myślą: skoro HTTPS-proxy potrafi tunelować zaszyfrowany ruch przez metodę CONNECT, to jest uniwersalne i powinno obsługiwać UDP. To błąd i teraz wyjaśnimy, dlaczego jest on zasadniczy.

Jak działa metoda CONNECT w HTTP-proxy

Gdy przeglądarka korzysta z HTTP-proxy do chronionej strony, nie może po prostu wysłać żądania HTTP, ponieważ zawartość jest zaszyfrowana. Zamiast tego wysyła do proxy specjalną komendę CONNECT z podaniem hosta i portu. Proxy nawiązuje połączenie TCP do tego hosta i po sukcesie odpowiada statusem o ustanowieniu tunelu. Następnie proxy po prostu przepycha bajty między klientem a serwerem w obie strony, nie wnikając w zawartość.

Kluczowym słowem jest tutaj TCP. Metoda CONNECT zgodnie ze swoją specyfikacją tworzy właśnie tunel TCP. Otwiera strumieniowe połączenie TCP i łączy dwa strumienie bajtów. W samej definicji CONNECT nie ma żadnego mechanizmu do pracy z datagramami.

Trzy fundamentalne przyczyny niezgodności

1. CONNECT jest oparty na modelu strumieniowym. HTTP to protokół na bazie TCP. Metoda CONNECT dziedziczy tę strumieniową naturę. Potrafi łączyć dwa strumienie TCP, ale UDP to nie strumień, a zbiór niezależnych datagramów. Nie ma między nimi odpowiedniości. Nie da się upchnąć wielu rozrzuconych datagramów z różnymi adresami docelowymi w jeden tunel TCP bez dodatkowego protokołu enkapsulacji, którego w HTTP CONNECT po prostu nie ma.
2. Brak mechanizmu adresowania datagramów. W UDP każdy datagram może lecieć do swojego adresu i portu. Aplikacja głosowa może jednocześnie komunikować się z kilkoma serwerami. Tunel TCP CONNECT łączy cię z jednym konkretnym adresem, podanym w momencie ustanawiania. Nie przewiduje pola do określenia adresu docelowego każdego pojedynczego datagramu, w przeciwieństwie do SOCKS5 z jego nagłówkiem enkapsulacji DST.ADDR i DST.PORT.
3. Brak relay-portu dla UDP. SOCKS5 celowo przydziela oddzielny UDP relay-port i informuje o nim klienta. HTTP-proxy nie ma takiego mechanizmu w ogóle. Jego architektura nie zakłada otwierania gniazd UDP po stronie serwera do retransmisji. Kod programu HTTP-proxy działa na połączeniach TCP i dodanie do niego UDP oznaczałoby napisanie w zasadzie nowego protokołu.

Wniosek, który warto zapamiętać na zawsze

HTTP i HTTPS-proxy nie obsługują UDP nie dlatego, że programiści byli leniwi, ale dlatego, że ich protokół został zbudowany wyłącznie wokół TCP. Metoda CONNECT to tunel TCP i koniec. Jeśli potrzebujesz UDP przez proxy, jedyna standardowa droga to SOCKS5 z obsługą komendy UDP ASSOCIATE. Żadne HTTP-proxy, niezależnie od tego, jak zaawansowane, nie przepuści ci głosu, wideo ani ruchu gier przez UDP.

Co dokładnie się psuje bez UDP: pełna mapa symptomów

Teraz najbardziej praktyczna część. Przeanalizujmy, które technologie zależą od UDP i jak wygląda ich awaria z perspektywy zwykłego użytkownika. To pomoże ci błyskawicznie zdiagnozować problem na podstawie objawów.

WebRTC i zestaw STUN/TURN

WebRTC to technologia czasu rzeczywistego, na której oparte są wideorozmowy w przeglądarce, czaty głosowe, udostępnianie ekranu i wiele usług konferencyjnych. Podstawą transmisji strumienia multimedialnego jest UDP, ponieważ w żywej rozmowie ważniejsza jest szybkość niż gwarancja dostarczenia każdego pakietu. Niewielka utrata pakietów w głosie jest prawie niezauważalna, ale opóźnienia wynikające z ponownego wysyłania TCP niszczą jakość.

Do nawiązywania połączenia WebRTC używa protokołów STUN i TURN. STUN pomaga poznać swój zewnętrzny adres za NAT, a TURN służy jako retranslator, gdy bezpośrednie połączenie jest niemożliwe. Zarówno STUN, jak i strumienie multimedialne domyślnie idą przez UDP.

Objaw ze strony użytkownika: rozmowa wydaje się nawiązywać, pojawia się sygnał wywołania, ale rozmówca cię nie słyszy i nie widzi, lub komunikacja jest jednostronna. Czasami rozmowa urywa się po kilku sekundach. Interfejs WWW działa, czat działa, ale dźwięk i obraz nie docierają. To klasyczny objaw zablokowanego UDP.

QUIC i HTTP/3 z wycofaniem na TCP

QUIC to nowoczesny protokół transportowy zbudowany na bazie UDP. Na nim działa HTTP/3, najnowsza wersja protokołu internetowego. QUIC zapewnia szybsze nawiązywanie połączenia i lepiej radzi sobie z utratą pakietów niż klasyczny TCP. Do 2026 roku znacząca część dużych stron i usług już obsługuje HTTP/3.

Gdy UDP jest niedostępny, dzieje się interesująca rzecz: aplikacja lub przeglądarka zazwyczaj wycofują się na HTTP/2 lub HTTP/1.1 na bazie TCP. To wbudowany w projekt mechanizm odporności na awarie.

Objaw ze strony użytkownika: najczęściej nie ma wyraźnej awarii, strony się otwierają. Ale tracisz zalety QUIC: połączenia nawiązywane są wolniej, przy niestabilnej sieci mogą występować zawieszenia. Doświadczony obserwator zauważy, że HTTP/3 jest niedostępne, mimo że serwer je obsługuje. Dla większości to ukryta degradacja, a nie jawna usterka.

DNS na porcie 53 przez UDP

Klasyczne zapytania DNS tradycyjnie idą przez UDP na port 53. To szybkie i wydajne dla krótkich zapytań o nazwy.

Tu jest pewien niuans zależny od tego, jak aplikacja rozwiązuje nazwy. Jeśli rozwiązywanie odbywa się po stronie proxy, problemu może nie być. Ale jeśli aplikacja chce sama wysłać zapytanie DNS przez UDP przez proxy, a UDP nie jest obsługiwane, rozwiązywanie się zepsuje.

Objaw ze strony użytkownika: nazwy stron nie są rozwiązywane, aplikacja informuje, że host nie został znaleziony, mimo że internet jest. Czasami obserwuje się opóźnienia, gdy system próbuje UDP, nie otrzymuje odpowiedzi i przełącza się na TCP-wariant DNS.

VoIP i komunikacja głosowa

VoIP to przesyłanie głosu przez internet. Protokoły głosowe prawie zawsze używają UDP do transmisji dźwięku, ponieważ opóźnienie jest krytyczne. Żywa rozmowa jest niemożliwa, jeśli każdy pakiet czeka na potwierdzenie.

Objaw ze strony użytkownika: połączenie nawiązuje się, ale dźwięk jest nieobecny, przerywany lub mocno opóźniony. Jednostronna słyszalność, metaliczne artefakty, zerwanie po kilku sekundach rozmowy. To wszystko oznaki problemów z transportem UDP.

Gry online

Wiele gier sieciowych, zwłaszcza dynamiczne strzelanki i projekty rywalizacyjne, używa UDP do przesyłania stanu świata gry. Powód jest ten sam: opóźnienie jest ważniejsze niż gwarancja dostarczenia. Przestarzały pakiet z pozycją gracza jest bezużyteczny, lepiej otrzymać świeży.

Objaw ze strony użytkownika: gra nie łączy się z meczem, zawiesza się na ekranie połączenia, wyrzuca po czasie. Albo połączenie jest, ale gra chodzi z szarpnięciami, postacie teleportują się, akcje nie są rejestrowane. Menu i sklep mogą działać, ponieważ często korzystają z HTTP na TCP.

Torrenty i P2P

Wiele protokołów P2P aktywnie używa UDP do wymiany informacji pomocniczych i przesyłania danych. Bez UDP funkcjonalność ulega degradacji: część mechanizmów wykrywania węzłów i transmisji nie działa.

Objaw ze strony użytkownika: spowolniona praca, problemy ze znalezieniem źródeł, niepełna funkcjonalność.

Szczegółowa tabela zależności scenariuszy od UDP

• Wideorozmowa i wideochat. Używa UDP: tak, krytycznie. Bez obsługi UDP: połączenie nawiązuje się wizualnie, ale brak dźwięku i obrazu, komunikacja jednostronna lub zerwanie. Podstawowa funkcjonalność nie działa.
• Gra online. Używa UDP: tak, dla większości dynamicznych gier. Bez obsługi UDP: brak połączenia z meczem, limity czasowe, szarpnięcia, teleportacja. Proces gry niemożliwy lub mocno zdegradowany.
• Zapytania DNS. Używa UDP: tak, klasyczny DNS na porcie 53. Bez obsługi UDP: możliwe problemy z rozwiązywaniem nazw lub opóźnienia, jeśli aplikacja rozwiązuje sama; przy rozwiązywaniu po stronie proxy problemu może nie być.
• QUIC i HTTP/3. Używa UDP: tak, w całości zbudowane na UDP. Bez obsługi UDP: niewidoczne wycofanie na TCP HTTP/2, utrata szybkości i zalet, ale strony się otwierają.
• Torrent i P2P. Używa UDP: tak, dla wielu mechanizmów. Bez obsługi UDP: degradacja funkcji, problemy ze znalezieniem źródeł i transmisją.
• Zwykły parsing i web scraping. Używa UDP: nie, zazwyczaj czysty TCP przez HTTP. Bez obsługi UDP: wszystko działa normalnie, UDP nie jest wymagane.
• Połączenie VoIP. Używa UDP: tak, dla strumienia głosowego. Bez obsługi UDP: brak dźwięku, zerwania, opóźnienia, jednostronna słyszalność.

Zwróć uwagę na ostatni wiersz. Dla klasycznych zadań, takich jak parsing czy zwykłe surfowanie po sieci, UDP w ogóle nie jest potrzebne. Dlatego wielu użytkowników przez lata korzysta z proxy bez UDP i nie zdaje sobie sprawy z ograniczenia, dopóki nie napotkają rozmowy lub gry.

Praktyka sprawdzania: jak dowiedzieć się, czy proxy obsługuje UDP

Nadszedł czas na narzędzia. Przeanalizujemy kilka metod sprawdzania, od prostych do zaawansowanych, i wyjaśnimy, dlaczego popularne sposoby często wprowadzają w błąd.

Dlaczego curl sprawdza tylko TCP

Wielu próbuje sprawdzić proxy komendą typu curl przez socks5-hostname na jakąś stronę. Jeśli zapytanie przechodzi, wnioskują: proxy działa, więc UDP też działa. To pułapka.

Chodzi o to, że żądanie HTTP przez curl idzie przez TCP. Komenda z flagą socks5-hostname sprawdza, czy SOCKS5-proxy potrafi wykonać komendę CONNECT i rozwiązać nazwę po swojej stronie. Ale CONNECT to TCP. Sukces takiego sprawdzenia mówi tylko o tym, że TCP przez proxy działa. O obsłudze UDP ASSOCIATE nie informuje absolutnie nic.

Zapamiętaj żelazną zasadę: sprawdzenie narzędziem TCP nie testuje UDP. Aby sprawdzić UDP, trzeba jawnie zainicjować komendę UDP ASSOCIATE i spróbować przesłać datagram.

Metoda 1: skrypt w Pythonie przez gniazda

Najbardziej przejrzysty sposób, aby zrozumieć i sprawdzić UDP ASSOCIATE, to napisać mały skrypt działający bezpośrednio na gniazdach. Opiszemy logikę krok po kroku, bez przywiązania do konkretnego kodu, abyś zrozumiał sedno.

1. Otwórz połączenie TCP z proxy. Połącz się z hostem i portem serwera SOCKS5 za pomocą zwykłego gniazda TCP.
2. Przejdź etap powitania. Wyślij wersję protokołu i listę obsługiwanych metod uwierzytelniania. Otrzymaj wybraną przez serwer metodę. W razie potrzeby wykonaj uwierzytelnianie loginem i hasłem.
3. Wyślij komendę UDP ASSOCIATE. Sformułuj żądanie z wersją, kodem komendy 0x03, zastrzeżonym bajtem i adresem. Jako adres i port często podaje się zera, co oznacza, że klient na razie nie wie, z jakiego adresu będzie wysyłał datagramy.
4. Przeczytaj odpowiedź serwera. To kluczowy moment. Pierwsze pole po wersji to kod odpowiedzi. Wartość 0x00 oznacza sukces. Jeśli widzisz 0x07, to Command not supported, czyli proxy nie obsługuje UDP ASSOCIATE. Inne niezerowe kody również sygnalizują błąd.
5. Wyodrębnij relay-adres. W przypadku sukcesu odczytaj BND.ADDR i BND.PORT z odpowiedzi. To adres i port, na które należy wysyłać swoje datagramy.
6. Wyślij testowy datagram. Utwórz gniazdo UDP, owiń testowy ładunek w nagłówek SOCKS5 z polami RSV, FRAG, ATYP, DST.ADDR, DST.PORT i wyślij na relay-port. Jako cel warto wybrać publiczną usługę odpowiadającą przez UDP.
7. Poczekaj na odpowiedź. Jeśli nadejdzie poprawnie enkapsulowana odpowiedź, UDP przez proxy naprawdę działa. Jeśli cisza, mimo kodu odpowiedzi sukcesu, oznacza to, że asocjacja formalnie istnieje, ale faktyczne przekazywanie datagramów nie działa.

Ta metoda daje wyczerpujący obraz. Osobno sprawdzasz, czy serwer akceptuje komendę UDP ASSOCIATE, i osobno sprawdzasz, czy datagramy faktycznie lecą.

Metoda 2: Zapytanie STUN przez proxy

Świetnym praktycznym testem jest użycie zapytania STUN jako ładunku. STUN to lekki protokół, publiczne serwery STUN odpowiadają szybko, a taki test jest najbliższy rzeczywistemu scenariuszowi WebRTC.

Logika jest ta sama: ustanawiasz asocjację UDP, owijasz zapytanie STUN typu Binding Request w nagłówek enkapsulacji SOCKS5, wysyłasz na relay-port z adresem publicznego serwera STUN. Jeśli nadejdzie odpowiedź STUN z twoim zewnętrznym adresem, oznacza to, że ścieżka UDP przez proxy jest w pełni funkcjonalna, ze zwrotną transmisją. To najbardziej przekonujący test dla scenariuszy czasu rzeczywistego.

Metoda 3: dig przez proxy dla DNS przez UDP

Zapytanie DNS też jest dobrym testem, ponieważ to kompaktowy datagram UDP z zrozumiałą odpowiedzią. Pomysł polega na skierowaniu zapytania DNS przez UDP przez SOCKS5-proxy do publicznego serwera DNS.

Standardowy dig sam w sobie nie umie chodzić przez SOCKS5 przez UDP, więc zwykle używa się pomocniczej otoczki, która kieruje ruch UDP przez proxy, albo implementuje się enkapsulację ręcznie według opisanego powyżej schematu. Jeśli odpowiedź DNS nadchodzi, kanał UDP działa. Jeśli zapytanie idzie w próżnię, a TCP przy tym działa, wniosek jest oczywisty: UDP nie jest obsługiwane.

Metoda 4: socat i narzędzia pomocnicze

Narzędzie socat to potężny szwajcarski scyzoryk do pracy z gniazdami. Za jego pomocą można budować łańcuchy przekierowań, w tym połączenie UDP i SOCKS. Należy jednak pamiętać o ograniczeniu: nie wszystkie wersje i tryby socat bezpośrednio obsługują UDP ASSOCIATE. Często socat używa się w połączeniu z warstwą pośrednią, która przejmuje enkapsulację SOCKS5 UDP, a socat odpowiada za lokalne przekierowanie UDP.

Praktyczne podejście: uruchomić lokalny odbiornik UDP, skierować przez warstwę pośrednią ruch UDP do proxy i sprawdzić, czy ładunek dociera do celu i czy wraca odpowiedź. To bardziej inżynierska ścieżka, przydatna przy debugowaniu infrastruktury.

Jak prawidłowo odczytywać kod odpowiedzi 0x07

Kod 0x07 Command not supported to najbardziej szczery i bezpośredni sygnał. Oznacza, że serwer SOCKS5 otrzymał twoją komendę UDP ASSOCIATE, rozpoznał ją, ale odpowiada: nie wykonuję tej komendy. Taka odpowiedź jest typowa dla proxy, które implementują tylko CONNECT.

Należy jednak uważać na bardziej podstępny scenariusz. Czasami serwer odpowiada kodem sukcesu 0x00 na komendę UDP ASSOCIATE, ale rzeczywiste przekazywanie datagramów nie działa. Powody są różne: filtr sieciowy między proxy a celem, nieprawidłowe przetwarzanie relay-adresu, ograniczenia hostingu. Dlatego nie wystarczy sprawdzić tylko kodu odpowiedzi. Prawdziwym testem jest udane, pełne przesłanie datagramu i otrzymanie odpowiedzi. Dlatego tak mocno nalegamy na test STUN lub DNS z rzeczywistą odpowiedzią.

Lista kontrolna sprawdzania obsługi UDP przez proxy

• Upewnij się, że testujesz właśnie SOCKS5, a nie HTTP-proxy, ponieważ to ostatnie z definicji nie obsługuje UDP.
• Nawiąż kontrolne połączenie TCP i przejdź uwierzytelnianie.
• Wyślij komendę UDP ASSOCIATE i sprawdź kod odpowiedzi. 0x00 dobrze, 0x07 oznacza brak obsługi.
• Wyodrębnij i poprawnie zinterpretuj BND.ADDR i BND.PORT, uwzględniając przypadek adresu zerowego.
• Wyślij rzeczywisty testowy datagram, owinięty zgodnie z formatem enkapsulacji.
• Poczekaj na poprawnie enkapsulowaną odpowiedź. Tylko to potwierdza działanie UDP.
• Powtórz test kilka razy, aby wykluczyć przypadkową utratę pakietu.

UDP w sieciach mobilnych: NAT-timeouty i keepalive

Osobny i bardzo ważny temat – zachowanie UDP w sieciach mobilnych. Tutaj kryje się przyczyna wielu tajemniczych zerwań, które wydają się niewytłumaczalne.

Dlaczego sesja UDP znika wcześniej niż TCP

Między twoim urządzeniem a internetem zawsze stoi NAT, mechanizm translacji adresów sieciowych. NAT przechowuje tablicę odwzorowań adresów i portów wewnętrznych na zewnętrzne. Dla każdego połączenia tworzony jest wpis w tej tablicy, który żyje przez ograniczony czas.

I oto kluczowa różnica. Dla TCP NAT ma wyraźne sygnały początku i końca połączenia: widzi uzgadnianie i widzi zamknięcie. Dlatego wpisy TCP w tablicy NAT żyją zazwyczaj długo, czasem kilkanaście minut lub dłużej.

Dla UDP jest inaczej. UDP nie ma pojęcia połączenia, więc NAT nie wie, kiedy sesja się rozpoczęła i zakończyła. Po prostu przechowuje wpis, dopóki trwa ruch, i usuwa go po okresie ciszy. Ten okres ciszy nazywa się UDP NAT-timeout i w sieciach mobilnych jest często bardzo krótki, czasem tylko kilkadziesiąt sekund.

Rezultat: jeśli przez kanał UDP przez jakiś czas nie ma ruchu, NAT po cichu usuwa wpis. Twoje kolejne datagramy nie mają już gdzie zostać dostarczone w drugą stronę i sesja się urywa. Tymczasem połączenie TCP w tych samych warunkach nadal by żyło.

Po co jest keepalive

Keepalive to regularne wysyłanie małych pakietów, aby NAT uznał sesję za aktywną i nie usuwał wpisu. Dla UDP keepalive jest szczególnie krytyczne właśnie ze względu na krótkie limity czasu.

Dobrze zaprojektowane protokoły czasu rzeczywistego same wysyłają okresowe keepalive lub pakiety pomocnicze. Na przykład w WebRTC mechanizm sprawdzania łączności stale potwierdza ścieżkę. Ale jeśli aplikacja milczy, a timeout NAT jest krótki, zerwanie jest nieuniknione. Dlatego przy pracy z UDP przez proxy w sieciach mobilnych należy pamiętać o konieczności utrzymywania kanału przy życiu.

Praktyczne obserwacje dotyczące sieci mobilnych

• Operatorzy komórkowi często stosują bardziej agresywną politykę wobec UDP niż TCP, aby oszczędzać zasoby NAT.
• UDP NAT-timeout może się różnić u różnych operatorów i zmieniać się w czasie, więc nie ma jednej wartości.
• Objaw krótkiego timeoutu: połączenie działa doskonale w fazie aktywnej, ale urywa się podczas przerw, np. gdy rozmówca milczy w rozmowie.
• Kontrolne połączenie TCP SOCKS5 dla asocjacji UDP również trzeba utrzymywać przy życiu, w przeciwnym razie proxy zamknie całą asocjację.

To subtelny szczegół, który odróżnia powierzchowne zrozumienie od głębokiego. Nawet gdy proxy poprawnie obsługuje UDP ASSOCIATE, niestabilność może pochodzić ze strony mobilnego NAT, a nie samego proxy. Diagnozując zerwania, zawsze miej w pamięci czynnik timeoutów.

Typowe błędy przy pracy z UDP przez proxy

Zbierzmy w jednym miejscu najczęstsze błędne przekonania. Unikając ich, zaoszczędzisz godziny debugowania.

Błąd 1: mylenie socks5 i socks5h

W ustawieniach wielu narzędzi są dwa warianty zapisu SOCKS5. Schemat socks5 zazwyczaj oznacza, że rozwiązywanie nazwy domeny odbywa się lokalnie, po stronie klienta, a proxy otrzymuje gotowy adres IP. Schemat socks5h oznacza, że rozwiązywanie odbywa się po stronie serwera proxy.

Dlaczego to ważne? Po pierwsze, lokalne rozwiązywanie może wyciekać przez twoje zwykłe DNS, co jest niepożądane dla prywatności zadania. Po drugie, przy nieprawidłowym wyborze schematu część logiki może zachowywać się inaczej, niż oczekujesz. Mylenie socks5 i socks5h generuje trudne do wyłapania bugi, gdy wydaje się, że proxy działa co drugi raz. Zawsze świadomie wybieraj, gdzie rozwiązuje się nazwa.

Błąd 2: myślenie, że skoro SOCKS5, to UDP działa

To chyba najczęstsze i najbardziej niebezpieczne błędne przekonanie. Standard SOCKS5 przewiduje komendę UDP ASSOCIATE, ale nie zobowiązuje każdej implementacji do jej obsługi. Ogromna liczba SOCKS5-proxy implementuje tylko CONNECT i BIND, a na UDP ASSOCIATE odpowiada kodem 0x07.

Innymi słowy, napis SOCKS5 to nie gwarancja UDP. To tylko możliwość, która może być zrealizowana lub nie. Jedyny sposób, aby się upewnić, to sprawdzić, jak opisaliśmy powyżej. Nigdy nie polegaj na marketingowej etykiecie, polegaj na rzeczywistym teście.

Błąd 3: sprawdzanie UDP przeglądarką

Niektórzy próbują sprawdzić obsługę UDP, po prostu otwierając stronę przez proxy w przeglądarce. Ale przeglądarka odwiedza strony przez TCP. Nawet jeśli strona obsługuje HTTP/3 przez UDP, przy niedostępności UDP przeglądarka po cichu wycofa się na TCP i nic nie zauważysz. Udane otwarcie strony nie dowodzi działania UDP.

Co więcej, WebRTC w przeglądarce ma własną skomplikowaną logikę omijania ograniczeń sieciowych i może używać TURN przez TCP w niektórych konfiguracjach, co dodatkowo zaciemnia obraz. Dlatego przeglądarka jest złym narzędziem do czystego testowania transportu UDP. Używaj bezpośrednich testów gniazd.

Błąd 4: ignorowanie testu kompleksowego

Jak już podkreślaliśmy, odpowiedź 0x00 na UDP ASSOCIATE nie jest równoznaczna z działającym UDP. Błędem jest poleganie tylko na kodzie odpowiedzi. Zawsze doprowadzaj test do rzeczywistej wymiany datagramów z otrzymaniem odpowiedzi. To oddziela formalne wsparcie od faktycznej wydajności.

Błąd 5: nieuwzględnianie keepalive i timeoutów

Po skonfigurowaniu UDP łatwo zapomnieć o NAT-timeoutach. Wtedy kanał działa w momencie testu, ale urywa się na przerwach w rzeczywistej eksploatacji. Zawsze uwzględniaj mechanizm utrzymywania kanału przy życiu, zwłaszcza w sieciach mobilnych.

Błąd 6: nieprawidłowe przetwarzanie relay-adresu

Jak wspomniano, serwer może zwrócić w BND.ADDR adres zerowy, implikując ten sam host co połączenie kontrolne. Klienci, którzy ślepo wysyłają datagramy na adres zerowy, zawodzą. Poprawna implementacja podstawia adres proxy z połączenia TCP. Ta subtelność jest przyczyną wielu cichych awarii.

Narzędzia i zasoby do pracy z UDP przez SOCKS5

Podsumujmy praktyczny arsenał, który warto mieć pod ręką.

Narzędzia diagnostyczne

• Własny skrypt w Pythonie z gniazdami. Najbardziej elastyczne i przejrzyste narzędzie. Daje pełną kontrolę nad formowaniem komendy UDP ASSOCIATE i enkapsulacją datagramów. Idealne do precyzyjnej diagnostyki.
• Klient STUN przez proxy. Najlepszy test dla scenariuszy czasu rzeczywistego. Szybka odpowiedź, zrozumiały wynik, maksymalnie blisko WebRTC.
• Test DNS przez UDP. Kompaktowy i czytelny, doskonały do sprawdzania kompleksowego przesyłania krótkich datagramów.
• socat i otoczki do enkapsulacji UDP. Inżynieryjne narzędzia do budowania i debugowania łańcuchów przekierowań UDP przez SOCKS5.
• Analizator ruchu. Obserwacja pakietów pomaga zobaczyć, czy datagramy faktycznie trafiają na relay-port i czy nadchodzą odpowiedzi. Nieoceniony przy głębokim debugowaniu.

Co warto wiedzieć o standardach

Kluczowym dokumentem dotyczącym SOCKS5 jest RFC 1928, gdzie opisano komendy, format zapytań i odpowiedzi oraz enkapsulację UDP. Zrozumienie tego standardu odróżnia eksperta od użytkownika działającego na ślepo. Dodatkowo warto rozumieć zasady STUN, QUIC i działania NAT, ponieważ to właśnie na styku tych technologii pojawiają się praktyczne problemy z UDP.

Mini-framework podejmowania decyzji

1. Określ, czy w ogóle potrzebujesz UDP. Do parsowania i zwykłego internetu nie, do rozmów, gier i czasu rzeczywistego tak.
2. Jeśli potrzebujesz UDP, upewnij się, że proxy to SOCKS5, a nie HTTP.
3. Sprawdź rzeczywistą obsługę UDP ASSOCIATE testem kompleksowym, a nie po etykiecie.
4. Uwzględnij keepalive i NAT-timeouty, szczególnie w sieciach mobilnych.
5. Poprawnie przetwarzaj relay-adres i format enkapsulacji.

Przypadki i rezultaty zastosowania

Przeanalizujmy kilka typowych sytuacji pokazujących, jak znajomość transportu rozwiązuje rzeczywiste problemy.

Przypadek 1: milcząca wideorozmowa

Sytuacja. Użytkownik skarży się, że przez proxy otwierają się wszystkie strony, czat konferencyjny działa, ale podczas rozmowy nie ma ani dźwięku, ani obrazu. Rozmówcy widzą wskaźnik połączenia, ale brak komunikacji.

Diagnostyka. Test TCP przez proxy przechodzi pomyślnie, co początkowo dezorientuje. Następnie przeprowadzany jest kompleksowy test STUN przez UDP ASSOCIATE. Serwer odpowiada na komendę kodem 0x07 Command not supported.

Wniosek. Proxy implementuje tylko CONNECT, UDP w ogóle nie jest obsługiwane. Strumień medialny WebRTC przez UDP nie przechodzi, stąd cisza. Rozwiązanie na poziomie transportu: potrzebne jest SOCKS5 z rzeczywistą obsługą UDP ASSOCIATE, potwierdzoną testem kompleksowym.

Przypadek 2: zerwanie połączenia na przerwach w sieci mobilnej

Sytuacja. Komunikacja głosowa przez proxy w sieci mobilnej działa doskonale podczas aktywnej rozmowy, ale gdy rozmówcy zamilkną na pół minuty, połączenie się urywa.

Diagnostyka. Kompleksowy test UDP przechodzi pomyślnie, datagramy latają w obie strony. Oznacza to, że samo proxy obsługuje UDP. Obserwacja zachowania pokazuje, że zerwania występują właśnie w przerwach bez ruchu.

Wniosek. Winowajcą jest krótki UDP NAT-timeout operatora komórkowego. Wpis w tablicy NAT jest usuwany podczas ciszy. Rozwiązanie na poziomie transportu: zapewnić keepalive, utrzymujące kanał i kontrolne połączenie TCP przy życiu.

Przypadek 3: fałszywa pewność z powodu kodu 0x00

Sytuacja. Inżynier sprawdził proxy, wysyłając komendę UDP ASSOCIATE, otrzymał kod sukcesu 0x00 i ogłosił, że UDP działa. Ale użytkownicy nadal skarżą się na niedziałające rozmowy.

Diagnostyka. Ponowne sprawdzenie idzie dalej niż kod odpowiedzi: wysyłany jest rzeczywisty datagram STUN na relay-port. Odpowiedź nie nadchodzi, mimo kodu sukcesu.

Wniosek. Formalne wsparcie istnieje, faktycznego przekazywania brak, prawdopodobnie z powodu filtracji między proxy a siecią zewnętrzną lub błędu w przetwarzaniu relay-adresu. Lekcja: kod 0x00 nie wystarczy, tylko kompleksowe przesłanie datagramu dowodzi działania.

Przypadek 4: ukryta degradacja HTTP/3

Sytuacja. Wszystko wydaje się działać, strony się otwierają, brak skarg, ale zespół zauważa, że połączenia nawiązywane są wolniej niż oczekiwano, a HTTP/3 nigdzie nie jest używane.

Diagnostyka. Sprawdzenie pokazuje, że UDP przez proxy nie przechodzi, więc QUIC jest niedostępny, a klienci po cichu wycofują się na TCP.

Wniosek. To nie awaria, ale ukryta utrata wydajności. Zrozumienie transportu pozwala świadomie zdecydować, czy QUIC jest ważny dla zadania, i w razie potrzeby zapewnić obsługę UDP.

FAQ: często zadawane pytania

Czy w ogóle można przesłać UDP przez HTTP-proxy w jakikolwiek sposób?

Standardowymi środkami nie. Metoda CONNECT w HTTP-proxy tworzy wyłącznie tunel TCP i nie ma mechanizmu adresowania i przesyłania datagramów. Wszelkie próby przepchnięcia UDP przez czyste HTTP-proxy rozbijają się o brak odpowiedniego protokołu. Dla UDP przeznaczony jest SOCKS5 z komendą UDP ASSOCIATE. To właściwa i ustandaryzowana ścieżka.

Jeśli proxy nazywa się SOCKS5, na pewno obsługuje UDP?

Nie, i to jest kluczowy niuans. Standard przewiduje UDP ASSOCIATE, ale nie wymaga jego obowiązkowej implementacji. Wiele SOCKS5-proxy obsługuje tylko CONNECT. Jedynym niezawodnym sposobem, aby się upewnić, jest przeprowadzenie testu kompleksowego z rzeczywistą transmisją datagramu, a nie poleganie na nazwie czy marketingu.

Dlaczego curl pokazuje, że proxy działa, a rozmowa nie przechodzi?

Ponieważ curl sprawdza TCP przez komendę CONNECT, a rozmowa używa UDP. To dwa różne transporty. Sukces testu TCP nic nie mówi o UDP. Aby sprawdzić UDP, trzeba zainicjować UDP ASSOCIATE i przesłać datagram, na przykład zapytanie STUN, czekając na odpowiedź.

Co oznacza kod odpowiedzi 0x07 przy próbie UDP ASSOCIATE?

To Command not supported. Proxy otrzymało twoją komendę, rozpoznało ją, ale informuje, że nie wykonuje UDP ASSOCIATE. Praktycznie oznacza to, że proxy nie umie przesyłać UDP. Potrzebujesz innego proxy z rzeczywistą obsługą tej komendy.

Po co UDP ASSOCIATE używa połączenia TCP, skoro przesyłamy UDP?

Kontrolne połączenie TCP służy dwóm celom. Po pierwsze, przez nie niezawodnie odbywa się uwierzytelnianie i uzgadnianie. Po drugie, określa czas życia asocjacji UDP: dopóki TCP jest otwarte, asocjacja działa, gdy tylko się zamknie, proxy zwalnia zasoby. To elegancki sposób zarządzania sesją i czyszczenia.

Dlaczego połączenie UDP urywa się w sieci mobilnej, a TCP trzyma?

Ze względu na specyfikę NAT. Dla TCP NAT ma wyraźne sygnały początku i końca, więc wpisy żyją długo. UDP nie ma pojęcia połączenia, a NAT usuwa wpis po krótkim okresie ciszy. W sieciach mobilnych UDP-timeout jest szczególnie krótki. Rozwiązanie: regularny keepalive utrzymujący kanał aktywny.

Czy można sprawdzić obsługę UDP bezpośrednio w przeglądarce?

Nie ma niezawodnego sposobu. Przeglądarka odwiedza strony przez TCP, a przy niedostępności UDP po cichu wycofuje się na TCP dla QUIC. WebRTC w przeglądarce ma skomplikowaną logikę i może korzystać z mechanizmów omijających. To wszystko maskuje rzeczywisty stan UDP. Do czystego testowania używaj bezpośrednich testów gniazd, STUN lub DNS przez UDP ASSOCIATE.

Jaka jest różnica między socks5 a socks5h w praktyce?

Różnica polega na tym, gdzie rozwiązywane jest nazwa domeny. Przy socks5 nazwa jest zwykle rozwiązywana lokalnie po stronie klienta, przy socks5h po stronie proxy. Wpływa to zarówno na prywatność rozwiązywania, jak i na zachowanie w niektórych scenariuszach. Świadomy wybór schematu eliminuje trudne do wyłapania błędy.

Czy obowiązkowe jest implementowanie fragmentacji datagramów w SOCKS5?

W praktyce nie. Pole FRAG jest przewidziane przez standard, ale zdecydowana większość implementacji działa tylko z wartością FRAG równą zero, czyli bez fragmentacji. Datagramy muszą zmieścić się w jednym pakiecie. Rzeczywiste protokoły używające UDP zazwyczaj operują małymi datagramami, więc rzadko to powoduje problemy.

Jak odróżnić problem proxy od problemu mobilnego NAT?

Przeprowadź kompleksowy test UDP. Jeśli w ogóle nie przechodzi, a komenda zwraca 0x07 lub datagramy nie docierają, problem leży po stronie proxy. Jeśli test przechodzi pomyślnie, a zerwania występują tylko na przerwach w rzeczywistej eksploatacji, najprawdopodobniej winny jest krótki UDP NAT-timeout. Taka analiza precyzyjnie lokalizuje źródło.

Podsumowanie: transport decyduje o wszystkim

Przeszliśmy drogę od podstawowych pojęć TCP i UDP po szczegóły enkapsulacji datagramów w SOCKS5 i podstępne NAT-timeouty w sieciach mobilnych. Utrwalmy główne wnioski, które zmieniają cię z użytkownika zgadującego na podstawie fusów w osobę dokładnie rozumiejącą, co dzieje się na poziomie transportu.

Po pierwsze, UDP i TCP to dwa różne światy. UDP niesie rozproszone datagramy bez gwarancji, dla szybkości, i to na nim opierają się rozmowy, gry, QUIC i klasyczny DNS. Proxy, które potrafi przesyłać TCP, nie musi umieć UDP.

Po drugie, tylko SOCKS5 przez komendę UDP ASSOCIATE daje standardową ścieżkę dla UDP. Mechanizm jest piękny: kontrolne połączenie TCP, osobny relay-port i enkapsulacja każdego datagramu w nagłówek z polami RSV, FRAG, ATYP, DST.ADDR i DST.PORT.

Po trzecie, HTTP i HTTPS-proxy w ogóle nie przepuszczają UDP. Metoda CONNECT tworzy wyłącznie tunel TCP, w jej architekturze nie ma ani adresowania datagramów, ani relay-portu, ani mechanizmu przesyłania UDP.

Po czwarte, napis SOCKS5 nie gwarantuje UDP. Zawsze sprawdzaj testem kompleksowym, doprowadzając do rzeczywistej transmisji datagramu i otrzymania odpowiedzi. Kod 0x00 bez faktycznej wymiany niczego nie dowodzi, a kod 0x07 uczciwie informuje o braku obsługi.

Po piąte, w sieciach mobilnych UDP jest bardziej kapryśne z powodu krótkich NAT-timeoutów. Keepalive i utrzymywanie kontrolnego połączenia przy życiu ratują przed tajemniczymi zerwaniami na przerwach.

Twoje następne kroki są proste. Określ, czy potrzebujesz UDP do konkretnego zadania, korzystając z naszej tabeli scenariuszy. Jeśli tak, upewnij się, że pracujesz z SOCKS5, i sprawdź rzeczywistą obsługę UDP ASSOCIATE swoim testem, czy to STUN, DNS, czy bezpośredni skrypt gniazd. Uwzględnij keepalive i poprawnie przetwarzaj relay-adres. Po wykonaniu tego nigdy więcej nie znajdziesz się w sytuacji, gdy proxy niby działa, a rozmowa milczy. Teraz dokładnie wiesz, gdzie szukać przyczyny i jak ją wyeliminować na poziomie transportu.