curl کی SOCKS سے HTTP تک پراکسی زنجیر

curl کا --preproxy اختیار HTTP یا HTTPS پراکسی تک پہنچنے سے پہلے SOCKS پراکسی سے جڑتا ہے۔ یہ اسی مخصوص زنجیر کی معاونت کرتا ہے، پراکسی سروروں کی کسی من مانی فہرست کی نہیں۔

راستہ ہے کلائنٹ → SOCKS endpoint → HTTP پراکسی → منزل۔ کمانڈ میں دونوں دستاویزی endpoint بدلیں:

curl --preproxy socks5h://203.0.113.10:1080 --proxy http://203.0.113.20:8080 --noproxy '' --connect-timeout 5 --max-time 20 --verbose https://example.com/

SOCKS سروس کو HTTP پراکسی کے پتے اور پورٹ تک پہنچنا چاہیے۔ پھر HTTP پراکسی کو منزل کی درخواست قبول کرنی چاہیے۔ دوسری پراکسی hostname استعمال کرے تو پہلا SOCKS mode طے کرتا ہے کہ اس نام کو کہاں resolve کیا جائے؛ عددی endpoint اس تلاش سے بچاتا ہے۔

ناکام مرحلہ تلاش کرنا

پہلے ہر endpoint سے درخواست الگ تصدیق کریں؛ HTTP مرحلے کے لیے وقت کی حدوں والی HTTP پراکسی جانچ استعمال کریں۔ دونوں چلیں تو بھی پہلی پراکسی دوسری تک نہ پہنچنے سے مشترک راستہ ناکام ہو سکتا ہے۔

تفصیلی trace کنکشن کی ترتیب میں پڑھیں۔ دوسری پراکسی تک پہنچتے وقت SOCKS کی ناکامی HTTP پراکسی کے ویب سائٹ تک CONNECT قبول یا مسترد کرنے کے فیصلے سے پہلے ہوتی ہے۔ نوٹ کریں کون سا handshake ناکام ہوا۔

اضافی مرحلہ کب مدد دیتا ہے

اگر مجاز HTTP پراکسی SOCKS راستے سے قابل رسائی ہو تو یہ ترتیب مفید ہو سکتی ہے۔ مگر اس سے ایک اور سروس اور نیٹ ورک راستہ بھی بڑھتا ہے جو ناکام ہو سکتا یا تاخیر بڑھا سکتا ہے۔ عوامی پراکسی فہرست کے endpoint جوڑنے سے قابل بھروسا ہونے یا گمنامی کی ضمانت نہیں ملتی اور کنکشن سنبھالنے والے فریقوں پر اعتماد ضروری رہتا ہے۔

--preproxy کو curl 7.52.0 یا نیا چاہیے؛ دوسری ایپس ممکن ہے اسی ترتیب کی معاونت نہ کریں۔