کھلا TCP پورٹ ثابت نہیں کرتا کہ پراکسی کام کرتی ہے

کامیاب پورٹ جانچ صرف کنکشن بناتی ہے۔ پراکسی handshake اور منزل کے متوقع جواب کی بھی جانچ کریں۔

کھلا TCP پورٹ بتاتا ہے کہ listener نے کنکشن قبول کیا۔ یہ پراکسی، عام ویب سرور یا دوسری سروس ہو سکتی ہے؛ پورٹ 8080 پروٹوکول کی شناخت نہیں کرتا۔

HTTP پراکسی کے طور پر دستاویز شدہ endpoint کا اصل پتہ وقت کی حدوں والی HTTPS درخواست میں استعمال کریں:

curl --proxy http://203.0.113.10:8080 --noproxy '' --connect-timeout 5 --max-time 15 --verbose https://example.com/

دستاویزی پتے کو اپنے HTTP endpoint یا HTTP پراکسی فہرست کے امیدوار سے بدلیں۔ SOCKS کے لیے متعلقہ SOCKS client mode استعمال کرکے مذاکرات مکمل کریں۔ غلط handshake TCP قبول ہونے کے فوراً بعد ناکام ہو سکتا ہے۔

دیکھا گیا مرحلہکیا ثابت ہوتا ہے
TCP قبول ہواListener تک رسائی ہے۔
پراکسی handshake قبول ہواListener نے یہ پراکسی عمل قبول کیا۔
منزل کا TLS تصدیق شدہکلائنٹ نے اپنی اعتماد کی ترتیبات کے مطابق مطلوبہ محفوظ کنکشن مکمل کیا۔
متوقع status اور مواد موصول ہوئےایپلیکیشن درخواست نے متوقع نتیجہ دیا۔

HTTP پراکسی کے ذریعے HTTPS کے لیے منزل کے پورٹ تک CONNECT کی اجازت ہونی چاہیے۔ حتیٰ کہ CONNECT 200 بھی درمیانی مرحلہ ہے: TLS یا آخری درخواست کامیاب ہونے سے پہلے tunnel بند ہو سکتا ہے۔ بغیر خفیہ کاری HTTP کی کامیابی یہ tunnel صلاحیت ثابت نہیں کرتی۔

متوقع مواد والی منزل استعمال کریں، بہتر ہے آپ کے اپنے اختیار میں ہو، اور دستیاب ہو تو اس کا درخواست ریکارڈ دیکھیں۔ بغیر خفیہ کاری HTTP listener منزل سے رابطہ کیے بغیر ہی مستقل صفحہ status 200 کے ساتھ دے سکتا ہے۔ کوئی بھی کامیاب status ملنا متوقع جواب سے مطابقت کے مقابلے میں کمزور ثبوت ہے؛ HTTPS شناخت کی تصدیق اضافی تحفظ دیتی ہے۔

آخری کامیاب مرحلہ درج کریں۔ ‘پورٹ کھلا، SOCKS مذاکرات مسترد’ اگلی تفتیش کے لیے مفید نقطۂ آغاز ہے۔

متعلقہ مضامین