Ինչպես մեկ պրոքսի պորտը կարող է ընդունել և՛ HTTP, և՛ SOCKS

Խառը պրոքսի լսիչը կարող է ընդունել HTTP և SOCKS մեկ TCP պորտում, որովհետև սերվերը ստուգում է պրոտոկոլի սկզբնական բայթերը։ Պորտի համարը այդ հայտնաբերումը չի կատարում։

HTTP պրոքսի հարցումը սկսվում է HTTP մեթոդով, օրինակ՝ GET կամ CONNECT։ SOCKS ողջույնը սկսվում է երկուական պրոտոկոլ դաշտերով։ Այս մուտքերի համար նախատեսված ծրագրակազմը կարող է միացումը ուղղել համապատասխան մշակիչին։

Սա բացահայտ իրականացման հատկանիշ է։ Սովորական Squid HTTP լսիչը խառը չի դառնում նրա համար, որ դրա պորտը փոխվում է 1080-ի, և միայն SOCKS լսիչը HTTP չի սովորում բրաուզերի կարգավորումից։

TLS-ը ավելացնում է ևս մեկ սահման. գաղտնագրված պրոքսի միացումը սկսվում է TLS-ով, ոչ թե տեսանելի HTTP մեթոդով։ Նույն վերջնակետում այն աջակցելը պահանջում է լրացուցիչ դիտավոր մշակում. պարզ HTTP-ի և SOCKS-ի ճանաչումը չի հաստատում այդ ունակությունը։

Օգտագործեք վերջնակետի համար փաստաթղթավորված հաճախորդի պրոտոկոլը։ Եթե երկուսն էլ աշխատում են, դա վկայություն է այդ սերվերի խառը լսիչի մասին, ոչ թե պատճառ՝ պրոտոկոլը յուրաքանչյուր հաճախորդում չճշտված թողնելու։

Glider-ի խառը լսիչը տալիս է կոնկրետ օրինակ. այն նայում է մեկ բայթի՝ առանց այն սպառելու, ուղարկում է 0x05-ը իր SOCKS5 մշակիչին, հակառակ դեպքում կանչում է իր HTTP վերլուծիչը։ Այդ վերլուծիչը դեռ վավերացնում է մուտքային հարցումը. ուղարկելու ընտրությունը կամայական մուտքը վավեր HTTP չի դարձնում։

TCP լսիչը կիսելը ինքնին SOCKS5 UDP կապ չի ապահովում։ Glider-ը իր UDP լսիչը սկսում է առանձին։ TCP պրոտոկոլի ընտրությունը և հետագա դատագրամի փոխանցումը առանձին ունակություններ են։