Разчитане на кодове за грешки при SOCKS5 връзки
Установете дали са се провалили SOCKS договарянето, удостоверяването или достъпът до целта, преди да обявите проксито за неработещо.
SOCKS5 сървър може да приеме TCP връзката ви, но да отхвърли заявката за достъп до цел. Прочетете отговора на правилния етап, преди да решите коя крайна точка е отказала.
Първо се избира методът. Удостоверяването с име и парола, ако бъде избрано, има собствен резултат. Едва след това сървърът връща отговор на CONNECT или друга SOCKS команда. Байтовата стойност от един етап не може да се тълкува с таблицата на друг.
Отговорите на заявки различават грешки
| Стойност на отговора | Значение в отговора на SOCKS5 заявка |
|---|---|
| 0x01 | Обща грешка на сървъра. |
| 0x02 | Връзката не е разрешена от правилата. |
| 0x03 | Мрежата е недостъпна. |
| 0x04 | Хостът е недостъпен. |
| 0x05 | Връзката е отказана. |
| 0x06 | TTL е изтекъл. |
| 0x07 | Командата не се поддържа. |
| 0x08 | Типът адрес не се поддържа. |
Например отказ на ниво заявка се съобщава след достигане на SOCKS услугата. Той се различава от отказ на операционната система за първоначалната TCP връзка с тази услуга.
Грешка в типа адрес може да засяга представяне като IPv4, IPv6 или име на хост. Това не означава автоматично, че цялата крайна точка не поддържа SOCKS5. По същия начин неподдържана UDP команда не дава окончателен извод за отделна TCP CONNECT заявка.
Съберете контекста, който прави кода полезен
При писане на доклад за грешка запазете с резултата адреса на проксито, командата, целевия хост и порт, адресното семейство и режима DNS. Сървърните журнали за политики са полезни, ако управлявате крайната точка. Отказ по правила изисква проверка на приложимото разрешение, а не увеличаване на времето за изчакване.
Отговорът е отчет на сървъра, не пълна независима диагноза на целевата мрежа. Формулировките на клиентите също се различават. Записвайте етапа и първичния отговор, когато са достъпни, вместо да разчитате само на кратък преведен текст.