Kā viens starpniekservera ports var pieņemt gan HTTP, gan SOCKS
Paskaidro, kā apzināti jaukts klausītājs var atšķirt HTTP no SOCKS, bet parasts viena protokola klausītājs to nevar.
Jaukts starpniekservera klausītājs var pieņemt HTTP un SOCKS vienā TCP portā, jo serveris pārbauda protokola sākuma baitus. Porta numurs šo atpazīšanu neveic.
HTTP starpniekservera pieprasījums sākas ar HTTP metodi, piemēram, GET vai CONNECT. SOCKS sveiciens sākas ar bināriem protokola laukiem. Šiem ievadiem paredzēta programmatūra var novirzīt savienojumu atbilstošajam apstrādātājam.
Šī ir skaidra ieviešanas iezīme. Parasts Squid HTTP klausītājs nekļūst jaukts tāpēc, ka tā ports tiek nomainīts uz 1080, un tikai SOCKS klausītājs neiemācās HTTP no pārlūka iestatījuma.
TLS pievieno vēl vienu robežu: šifrēts starpniekservera savienojums sākas ar TLS, nevis redzamu HTTP metodi. Tā atbalstīšana tajā pašā galapunktā prasa papildu apzinātu apstrādi; atklāta HTTP un SOCKS atpazīšana neapliecina šo spēju.
Izmantojiet galapunktam dokumentēto klienta protokolu. Ja darbojas abi, tas ir pierādījums par šī servera jaukto klausītāju, nevis iemesls atstāt protokolu nenorādītu katrā klientā.
Glider jauktais klausītājs sniedz konkrētu piemēru: tas ielūkojas vienā baitā to nepatērējot, nosūta 0x05 savam SOCKS5 apstrādātājam, un citādi izsauc savu HTTP parseri. Šis parsers joprojām validē ienākošo pieprasījumu; nosūtīšanas izvēle nepadara patvaļīgu ievadi par derīgu HTTP.
TCP klausītāja koplietošana pati par sevi nenodrošina SOCKS5 UDP asociāciju. Glider sāk savu UDP klausītāju atsevišķi. TCP protokola izvēle un vēlākā datagrammu pārraide ir atsevišķas spējas.