Как один прокси-порт может принимать и HTTP, и SOCKS
Объясняет, как намеренно смешанный слушатель может различать HTTP и SOCKS, тогда как обычный однопротокольный слушатель этого не может.
Смешанный прокси-слушатель может принимать HTTP и SOCKS на одном TCP-порту, потому что сервер проверяет первые байты протокола. Номер порта не выполняет это определение.
Запрос HTTP-прокси начинается с метода HTTP, например GET или CONNECT. Приветствие SOCKS начинается с двоичных полей протокола. Программное обеспечение, рассчитанное на такие входные данные, может направить соединение соответствующему обработчику.
Это явная особенность реализации. Обычный HTTP-слушатель Squid не становится смешанным из-за того, что его порт меняют на 1080, а слушатель только с SOCKS не узнаёт HTTP из настройки браузера.
TLS добавляет ещё одну границу: зашифрованное прокси-соединение начинается с TLS, а не с видимого метода HTTP. Его поддержка на той же конечной точке требует дополнительной намеренной обработки; распознавание открытого HTTP и SOCKS не доказывает эту возможность.
Используйте клиентский протокол, задокументированный для конечной точки. Если работают оба, это свидетельство о смешанном слушателе того сервера, а не причина оставлять протокол неуказанным в каждом клиенте.
Смешанный слушатель Glider даёт конкретный пример: он заглядывает в один байт, не потребляя его, отправляет 0x05 своему обработчику SOCKS5, а в остальных случаях вызывает свой HTTP-парсер. Этот парсер по-прежнему проверяет входящий запрос; выбор отправки не делает произвольные данные допустимым HTTP.
Совместное использование TCP-слушателя само по себе не обеспечивает UDP-ассоциацию SOCKS5. Glider запускает свой UDP-слушатель отдельно. Выбор протокола TCP и последующая передача дейтаграмм — отдельные возможности.