Как читать коды сбоев соединения 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. Если вы управляете узлом, полезны серверные журналы политик. Отказ по правилам требует проверки применимого разрешения, а не увеличения тайм-аута соединения.
Ответ — сообщение сервера, а не полная независимая диагностика целевой сети. Формулировки клиентов тоже различаются. По возможности фиксируйте этап и исходный ответ, не полагаясь только на короткое переведённое сообщение об ошибке.