Jak czytać kody błędów połączenia SOCKS5
Ustal, czy zawiodła negocjacja SOCKS, uwierzytelnianie czy dostęp do celu, zanim uznasz każdy błąd za niedziałające proxy.
Serwer SOCKS5 może przyjąć połączenie TCP, a mimo to odrzucić żądanie dostępu do celu. Przeczytaj odpowiedź na właściwym etapie, zanim zdecydujesz, który punkt zawiódł.
Najpierw następuje wybór metody. Uwierzytelnianie nazwą użytkownika i hasłem, jeśli zostanie wybrane, ma własny wynik. Dopiero potem serwer odpowiada na CONNECT lub inne polecenie SOCKS. Wartości bajtu z jednego etapu nie wolno interpretować tabelą innego etapu.
Odpowiedzi na żądania rozróżniają błędy
| Wartość odpowiedzi | Znaczenie w odpowiedzi na żądanie SOCKS5 |
|---|---|
| 0x01 | Ogólny błąd serwera. |
| 0x02 | Połączenie niedozwolone przez zestaw reguł. |
| 0x03 | Sieć nieosiągalna. |
| 0x04 | Host nieosiągalny. |
| 0x05 | Odmowa połączenia. |
| 0x06 | Upłynął TTL. |
| 0x07 | Polecenie nieobsługiwane. |
| 0x08 | Typ adresu nieobsługiwany. |
Na przykład odmowa na poziomie żądania jest zgłaszana po dotarciu do usługi SOCKS. Różni się od odmowy początkowego połączenia TCP z tą usługą przez system operacyjny.
Błąd typu adresu może dotyczyć reprezentacji IPv4, IPv6 lub nazwy hosta. Nie oznacza automatycznie, że cały punkt końcowy nie obsługuje SOCKS5. Podobnie nieobsługiwane polecenie UDP nie pozwala rozstrzygać o oddzielnym żądaniu TCP CONNECT.
Zbierz kontekst, dzięki któremu kod jest przydatny
Przy pisaniu zgłoszenia błędu zachowaj wraz z wynikiem adres proxy, polecenie, docelowy host i port, rodzinę adresów i tryb DNS. Jeśli zarządzasz punktem końcowym, przydają się serwerowe logi polityk. Odrzucenie przez reguły wymaga sprawdzenia odpowiedniego uprawnienia, nie zwiększenia limitu czasu połączenia.
Odpowiedź to raport serwera, a nie pełna niezależna diagnoza sieci docelowej. Sformułowania klientów też się różnią. Zapisz etap i źródłową odpowiedź, gdy są dostępne, zamiast polegać wyłącznie na krótkim przetłumaczonym komunikacie.