Bir proxy portu necə həm HTTP, həm də SOCKS qəbul edə bilər
Qəsdən qarışıq dinləyicinin HTTP ilə SOCKS-u necə ayırd edə bildiyini, adi təkprotokollu dinləyicinin isə bunu edə bilmədiyini izah edir.
Qarışıq proxy dinləyicisi bir TCP portunda HTTP və SOCKS qəbul edə bilər, çünki server ilkin protokol baytlarını yoxlayır. Port nömrəsi bu aşkarlamanı etmir.
HTTP proxy sorğusu HTTP metodu ilə başlayır, məsələn GET və ya CONNECT. SOCKS salamlaması binar protokol sahələri ilə başlayır. Bu girişlər üçün nəzərdə tutulmuş proqram təminatı bağlantını uyğun idarəediciyə yönəldə bilər.
Bu, açıq şəkildə tətbiq xüsusiyyətidir. Adi Squid HTTP dinləyicisi portu 1080-ə dəyişdirildiyi üçün qarışıq olmur, və yalnız SOCKS dinləyicisi brauzerin ayarından HTTP öyrənmir.
TLS başqa bir sərhəd əlavə edir: şifrələnmiş proxy bağlantısı görünən HTTP metodu ilə deyil, TLS ilə başlayır. Onu eyni son nöqtədə dəstəkləmək əlavə qəsdən idarəetmə tələb edir; açıq HTTP və SOCKS-u tanımaq bu qabiliyyəti təsdiqləmir.
Son nöqtə üçün sənədləşdirilmiş müştəri protokolundan istifadə edin. Əgər hər ikisi işləyirsə, bu həmin serverin qarışıq dinləyicisi haqqında sübutdur, protokolu hər müştəridə qeyri-müəyyən qoymaq üçün səbəb deyil.
Glider-in qarışıq dinləyicisi konkret nümunə verir: o, bir baytı istehlak etmədən ona baxır, 0x05-i SOCKS5 idarəedicisinə yönəldir, əks halda HTTP parserini çağırır. Həmin parser yenə də gələn sorğunu yoxlayır; göndərmə seçimi ixtiyari girişi etibarlı HTTP etmir.
TCP dinləyicisini paylaşmaq özlüyündə SOCKS5 UDP assosiasiyası təmin etmir. Glider UDP dinləyicisini ayrıca başladır. TCP protokol seçimi və sonrakı datagram ötürülməsi ayrı qabiliyyətlərdir.