څنګه یو پروکسي پورټ کولی شي HTTP او SOCKS دواړه ومني

ګډ پروکسي اورېدونکی کولی شي په یو TCP پورټ کې HTTP او SOCKS ومني، ځکه چې سرور د پروتوکول لومړني بایټونه ګوري. د پورټ شمېره دا پېژندنه نه کوي.

د 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 پروتوکول ټاکنه او وروسته د ډاټاګرام لېږد جلا وړتیاوې دي.