Холимог прокси сонсогч нэг TCP порт дээр HTTP болон SOCKS хүлээж авах боломжтой, учир нь сервер протоколын эхний байтуудыг шалгадаг. Портын дугаар тэр илрүүлэлтийг хийдэггүй.

HTTP прокси хүсэлт нь GET эсвэл CONNECT зэрэг HTTP аргаар эхэлдэг. SOCKS мэндчилгээ нь хоёртын протоколын талбаруудаар эхэлдэг. Эдгээр оролтод зориулсан програм хангамж холболтыг тохирох боловсруулагч руу илгээж чадна.

Энэ бол ил тод хэрэгжүүлэлтийн онцлог юм. Энгийн Squid HTTP сонсогч портыг нь 1080 болгосон ч холимог болохгүй, зөвхөн SOCKS сонсогч хөтчийн тохиргооноос HTTP сурахгүй.

TLS өөр нэг хил нэмдэг: шифрлэгдсэн прокси холболт харагдах HTTP аргаар биш, TLS-ээр эхэлдэг. Үүнийг ижил төгсгөлийн цэг дээр дэмжих нь нэмэлт зориуд боловсруулалт шаарддаг; энгийн HTTP болон SOCKS-ыг таних нь тэр чадварыг батлахгүй.

Төгсгөлийн цэгт зориулж баримтжуулсан клиент протоколыг ашиглана уу. Хоёулаа ажиллаж байвал энэ нь тэр серверийн холимог сонсогчийн тухай нотолгоо бөгөөд протоколыг клиент бүрт тодорхойгүй үлдээх шалтгаан биш.

Glider-ийн холимог сонсогч тодорхой жишээ өгдөг: тэр нэг байтыг хэрэглэхгүйгээр түүн рүү харж, 0x05-ыг өөрийн SOCKS5 боловсруулагч руу илгээдэг, эс бөгөөс өөрийн HTTP задлагчийг дууддаг. Тэр задлагч ирж буй хүсэлтийг баталгаажуулсн хэвээр байна; илгээх сонголт нь дур зоргоороо оролтыг хүчинтэй HTTP болгодоггүй.

TCP сонсогчийг хуваалцах нь өөрөө SOCKS5 UDP холбоог өгдөггүй. Glider өөрийн UDP сонсогчийг тусад нь эхлүүлдэг. TCP протоколын сонголт болон дараагийн датаграм дамжуулалт нь тусдаа чадварууд юм.

Холбоотой нийтлэлүүд