curl آپ کی PAC فائل نہیں پڑھ سکتا: اس کی بجائے proxy پاس کریں

کنفگ فائل میں PAC فائل کا پتہ اور proxy کا اینڈ پوائنٹ ایک دوسرے کی جگہ استعمال ہونے والے لگتے ہیں، مگر ایسا نہیں ہے۔ ایک پالیسی پروگرام ہے جس کا ہر URL کے لیے اندازہ لگانا پڑتا ہے؛ دوسرا وہ ہوسٹ اور پورٹ ہے جو کنکشن قبول کرتا ہے۔ curl صرف دوسرے کو سمجھتا ہے۔ PAC پتہ --proxy کو پاس کرنا ایک قسم کی غلطی ہے جو الجھانے والے انداز میں ناکام ہوتی ہے، عام طور پر کسی ویب سرور کی طرف طویل CONNECT ٹائم آؤٹ کے بعد۔

ہر ایک حقیقت میں کیا ہے

یہ واضح طور پر کہتا ہے curl کے بارے میں اکثر پوچھے جانے والے سوالات: curl کسی JavaScript یا PAC کی تشریح فراہم نہیں کرتا۔ curl کے گرد PAC سمجھنے والا غلاف یہ کر سکتا ہے، مگر خود curl نہیں، اور کوئی فلگ اسے براؤزر نہیں بناتا۔

براؤزر کیوں کام کرتا ہے اور curl کیوں نہیں

براؤزر سسٹم کی proxy ترتیب کے ساتھ جڑتا ہے، PAC فائل لاتا ہے اور آپ کے کھولے جانے والے URL کے خلاف اس کے قواعد چلاتا ہے۔ وہی جائزہ PAC فائل کی فراہم کردہ خدمت ہے، اور یہ براؤزر کے اندر ہوتا ہے، آپ کے ٹرمینل میں نہیں۔

curl کے ساتھ PAC فائل ڈاؤن لوڈ کرنے سے صرف اس کا متن ملتا ہے۔ یہ curl کو پالیسی پر عمل کرنے پر مجبور نہیں کرتا، اور proxy تلاش کرنے کے لیے اسے ہاتھ سے پڑھنا اسی جائزے کا ہاتھ سے کیا گیا ورژن ہے، غلط شاخ چننے کا اتنا ہی امکان ہے۔ اگر آپ اسے پڑھیں، تو فائل میں پہلے proxy نام کی بجائے اپنے ہوسٹ سے مطابقت رکھنے والا return بیان پڑھیں۔ زیادہ تر PAC فائلوں میں کئی ہوتے ہیں، اور آپ پر صرف ایک شاخ لاگو ہوتی ہے۔

منظور شدہ HTTP proxy اور منظور شدہ HTTPS خدمت کے لیے، ایک مثال درخواست یہ ہے:

curl --proxy http://proxy.corp.example:8080 https://service.example.net/status

پہلا پتہ proxy کا سننے والا ہے، دوسرا وہ خدمت ہے جو آپ چاہتے ہیں۔ یہ مثالی اینڈ پوائنٹ ہیں، کسی کا کیا ہوا امتحان نہیں، اس لیے انہیں اپنے ادارے کی اسکیم، پورٹ اور تصدیق کے عمل سے بدلیں۔

اس منزل کے لیے proxy منتخب کریں

منتظم سے پوچھیں کہ پالیسی آپ کے مطلوبہ URL کے لیے کون سا proxy چنتی ہے، نہ کہ ادارے کے پاس کون سا proxy ہے۔ PAC قواعد اندرونی خدمات، عوامی سائٹس اور ناکامی پر تبدیلی کی حالتوں کے لیے مختلف نتائج دے سکتے ہیں، اور آج آپ کے URL سے میل کھانے والا قاعدہ ترمیم کے بعد کسی دوسرے سے میل کھا سکتا ہے۔

اگر کام کے بہاؤ کو ایک سے زیادہ معلوم درخواستیں درکار ہوں، تو منتظم کے تعاون یافتہ مستقل ترتیب یا منظور شدہ PAC سمجھنے والا انضمام استعمال کریں۔ ایک نقل شدہ پتہ ہارڈ کوڈ کرنا اس دن تک چلے گا جب پالیسی بدل جائے اور کسی کو یاد نہ رہے کہ وہ پتہ کیوں چنا گیا تھا۔

پھر دیکھیں curl کیا ورثے میں لیتا ہے۔ proxy کے ماحول کے متغیرات اور NO_PROXY آپ کا پاس کردہ proxy اوور رائیڈ یا خارج کر سکتے ہیں، اور آپ کی منزل سے میل کھانے والا اخراج درخواست کو خاموشی سے براہ راست بھیج دیتا ہے۔ ہر اخراج مٹانے یا سب کچھ ایک پتے سے گزارنے کی بجائے مطلوبہ پالیسی برقرار رکھیں۔ درخواست ایک بار -v کے ساتھ چلائیں اور دیکھیں کہ یہ واقعی کس پتے سے جڑی۔

دو TLS شناختوں کو الگ رکھیں

HTTPS proxy کے ساتھ، دو TLS کنکشن زیر عمل ہیں: آپ کا proxy کی طرف اور proxy کا منزل کی طرف۔ ہر ایک کی تصدیق کے لیے اپنی شناخت ہے، اور ان میں سے کسی کے لیے تصدیق بند کرنا PAC کی درستی نہیں، پہلی دشواری میں شامل دوسری دشواری ہے۔

تصدیق کو آن رکھیں اور جو ناکامی ملے اسے پڑھیں۔ proxy کی تصدیق کا چیلنج، ناقابل رسائی proxy اور ویب سائٹ کا انکار تین مختلف نتائج ہیں، اور صرف پہلا اسناد سے متعلق ہے۔ VPN کو اب بھی نجی proxy تک اجازت شدہ راستہ دینا ہوتا ہے، جس میں proxy ہوسٹ کے لیے نام کی تحلیل بھی شامل ہے، اس سے پہلے کہ ان میں سے کچھ کامیاب ہو۔

اینڈ پوائنٹ، اسکیم، پورٹ، تصدیق کا طریقہ، اخراجات اور proxy تک VPN راستہ لکھ لیں۔ وہی ریکارڈ اگلی درخواست کو دوبارہ پیدا کرنے کے قابل بناتا ہے، اور آپ کے proxy کو جاننے اور اس کے بارے میں اندازہ لگانے کے درمیان فرق یہی ہے۔