Si mund një port i vetëm proxy të pranojë HTTP dhe SOCKS
Shpjegon se si një dëgjues qëllimisht i përzier mund të dallojë HTTP nga SOCKS, ndërsa një dëgjues normal me një protokoll të vetëm nuk mundet.
Një dëgjues proxy i përzier mund të pranojë HTTP dhe SOCKS në një port të vetëm TCP sepse serveri inspekton bajtët fillestarë të protokollit. Numri i portit nuk e kryen atë zbulim.
Një kërkesë proxy HTTP fillon me një metodë HTTP, si GET ose CONNECT. Një përshëndetje SOCKS fillon me fusha binare protokolli. Programi i krijuar për këto hyrje mund ta drejtojë lidhjen te trajtuesi i duhur.
Kjo është një veçori e qartë implementimi. Një dëgjues normal HTTP i Squid nuk bëhet i përzier sepse porta e tij ndryshohet në 1080, dhe një dëgjues vetëm SOCKS nuk mëson HTTP nga një cilësim i shfletuesit.
TLS shton një kufi tjetër: një lidhje proxy e kriptuar fillon me TLS, jo me një metodë HTTP të dukshme. Mbështetja e saj në të njëjtin pikë fundore kërkon trajtim shtesë të qëllimshëm; njohja e HTTP në tekst të thjeshtë dhe SOCKS nuk e vërteton atë aftësi.
Përdorni protokollin e klientit të dokumentuar për pikën fundore. Nëse të dy funksionojnë, kjo është provë për dëgjuesin e përzier të atij serveri, jo një arsye për ta lënë protokollin të papërcaktuar në çdo klient.
Dëgjuesi i përzier i Glider jep një shembull konkret: vështron një bajt pa e konsumuar, dërgon 0x05 te trajtuesi i tij SOCKS5 dhe, në të kundërt, thërret analizuesin e tij HTTP. Ai analizues vazhdon të vërtetojë kërkesën hyrëse; zgjedhja e dërgimit nuk e bën një hyrje arbitrare HTTP të vlefshme.
Ndarja e dëgjuesit TCP nuk siguron në vetvete lidhjen UDP të SOCKS5. Glider e nis dëgjuesin e tij UDP veçmas. Zgjedhja e protokollit TCP dhe përcjellja e mëvonshme e datagrameve janë aftësi të ndara.