Как един прокси порт може да приема едновременно 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 протокол и последващото препредаване на дейтаграми са отделни възможности.