Kiel unu prokura pordo povas akcepti kaj HTTP kaj SOCKS
Klarigas kiel intence miksita aŭskultanto povas distingi HTTP disde SOCKS, dum ordinara unuprotokola aŭskultanto ne povas.
Miksita prokura aŭskultanto povas akcepti HTTP kaj SOCKS sur unu TCP-pordo, ĉar la servilo inspektas la komencajn protokolbajtojn. La pordnumero ne faras tiun rekonon.
HTTP-prokura peto komenciĝas per HTTP-metodo, kiel GET aŭ CONNECT. SOCKS-saluto komenciĝas per binuraj protokolkampoj. Programaro desegnita por ĉi tiuj enigoj povas sendi la konekton al la taŭga traktilo.
Ĉi tio estas eksplicita efektiviga trajto. Ordinara HTTP-aŭskultanto de Squid ne fariĝas miksita ĉar ĝia pordo ŝanĝiĝas al 1080, kaj aŭskultanto nur por SOCKS ne lernas HTTP el agordo de retumilo.
TLS aldonas alian limon: ĉifrita prokura konekto komenciĝas per TLS, ne per videbla HTTP-metodo. Subteni ĝin en la sama finpunkto postulas plian intencan pritraktadon; rekoni klartekstan HTTP kaj SOCKS ne pruvas tiun kapablon.
Uzu la klientan protokolon dokumentitan por la finpunkto. Se ambaŭ funkcias, tio estas pruvo pri la miksita aŭskultanto de tiu servilo, ne kialo lasi la protokolon nespecifita en ĉiu kliento.
La miksita aŭskultanto de Glider donas konkretan ekzemplon: ĝi rigardas unu bajton sen konsumi ĝin, sendas 0x05 al sia SOCKS5-traktilo, kaj alie vokas sian HTTP-analizilon. Tiu analizilo ankoraŭ validigas la envenantan peton; la elekto de sendado ne faras arbitran enigon valida HTTP.
Kunhavigi la TCP-aŭskultanton mem ne provizas UDP-asocion de SOCKS5. Glider startigas sian UDP-aŭskultanton aparte. Elekto de TCP-protokolo kaj la posta datagrama plusendo estas apartaj kapabloj.