Як адзін проксі-порт можа прымаць і 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 і наступная перадача дэйтаграм — асобныя здольнасці.