Како један прокси порт може да прима и HTTP и SOCKS

Мешовити прокси слушалац може да прима HTTP и SOCKS на једном TCP порту зато што сервер прегледа почетне бајтове протокола. Број порта не обавља то препознавање.

HTTP прокси захтев почиње HTTP методом, као што су GET или CONNECT. SOCKS поздрав почиње бинарним пољима протокола. Софтвер намењен тим улазима може да усмери везу на одговарајући руковаоц.

То је изричита карактеристика имплементације. Обичан Squid HTTP слушалац не постаје мешовит зато што му се порт промени на 1080, а слушалац само за SOCKS не научи HTTP из поставке прегледача.

TLS додаје још једну границу: шифрована прокси веза почиње TLS-ом, а не видљивом HTTP методом. Подршка за то на истој крајњој тачки захтева додатно намерно руковање; препознавање обичног HTTP-а и SOCKS-а не доказује ту способност.

Користите клијентски протокол документован за крајњу тачку. Ако оба раде, то је доказ о мешовитом слушаоцу тог сервера, а не разлог да протокол остане неодређен у сваком клијенту.

Мешовити слушалац Glider-а даје конкретан пример: зађе погледом у један бајт без да га троши, шаље 0x05 свом SOCKS5 руковаоцу, а иначе позива свој HTTP парсер. Тај парсер и даље проверава долазни захтев; избор слања не чини произвољан улаз важећим HTTP-ом.

Дељење TCP слушаоца само по себи не пружа SOCKS5 UDP асоцијацију. Glider засебно покреће свој UDP слушалац. Избор TCP протокола и касније прослеђивање датаграма су одвојене способности.