نجی API پر Requests ProxyError؟ پہلے ماحول جانچیں

VPN آن ہے، اندرونی ڈیش بورڈ براؤزر میں کھلتا ہے، اور Python اسکرپٹ پھر بھی پراکسی خرابی دیتا ہے۔ اس تصویر میں سرنگ میں کچھ غلط نہیں: انٹرپریٹر اپنے ماحول سے پراکسی پتہ پڑھتا ہے اور درخواست وہاں بھیجتا ہے۔ یہ رہنما وہ ماحول پڑھتی ہے جو عمل واقعی دیکھتا ہے، سب سے تنگ استثنا لاگو کرتی ہے اور اس کے بعد ہی واضح سیشن پالیسی پر غور کرتی ہے۔ ہر قدم ایسے حکم پر ختم ہوتا ہے جس کا آؤٹ پٹ طے کرتا ہے کہ آپ جاری رکھیں گے یا نہیں۔

وہ ماحول پڑھیں جو عمل واقعی دیکھتا ہے

ڈیسک ٹاپ پراکسی ترتیبات، shell ایکسپورٹ اور systemd یونٹ کی Environment= سطریں تین مختلف ذرائع ہیں، اور Requests صرف آخری وراثت میں ملنے والا ذریعہ پڑھتا ہے۔ نیچے دی گئی تشخیص اسی shell، کنٹینر یا یونٹ میں چلائیں جو ناکام اسکرپٹ چلاتا ہے، اپنے انٹرایکٹو ٹرمینل میں نہیں۔ آپ کے لاگ ان shell میں ایکسپورٹ کیا گیا ویری ایبل کنٹینر عمل کے لیے پوشیدہ ہے، اور یہی خلا کہیں سے نمودار ہونے والی پراکسی کے بارے میں بہت سی رپورٹوں کی وضاحت کرتا ہے۔ دونوں احکام ایک ہی ڈیٹا مختلف تفصیل کی سطحوں پر چھاپتے ہیں۔

env | grep -i -E 'proxy|requests_ca_bundle|curl_ca_bundle'
python3 -c "import os;[print(k,'=',v) for k,v in sorted(os.environ.items()) if 'proxy' in k.lower()]"

ہر ویری ایبل کی دونوں ہجے پڑھی جاتی ہیں، اور نقل شدہ اندراجات اسی ترتیب میں لاگو ہوتے ہیں جس میں عمل کو ملے، اس لیے پرانا HTTP_PROXY ابھی ایکسپورٹ کی گئی قدر کو زیر کر سکتا ہے۔ CA بنڈل ویری ایبل یہاں بھی اہم ہیں، کیونکہ وہ بدلتے ہیں کہ verify کس میں حل ہوتا ہے بغیر کوڈ میں کہیں نظر آئے۔ اگر آؤٹ پٹ خالی ہے تو ماحول آپ کا مسئلہ نہیں اور آپ یہ حصہ پڑھنا بند کر سکتے ہیں۔ اگر یہ کوئی ایسی پراکسی دکھاتا ہے جو آپ نہیں جانتے، تو کچھ بھی بدلنے سے پہلے وہ فائل یا یونٹ تلاش کریں جو اسے سیٹ کرتی ہے۔

Requests سے پوچھیں کہ وہ کسی مخصوص URL کے ساتھ کیا کرے گا۔ یہ کال بغیر کوئی پیکٹ بھیجے اس درخواست کے لیے یکجا شدہ پراکسی، verify اور cert قدریں دکھاتی ہے۔

python3 -c "import requests;s=requests.Session();print(s.merge_environment_settings('https://api.corp.example/status',{},None,None,None))"

نجی ہوسٹ کے لیے خالی نہ ہونے والا proxies اندراج آپ کا جواب ہے، اور چھپی ہوئی verify قدر بتاتی ہے کہ درخواست کس CA بنڈل پر بھروسا کرے گی۔ اگر دونوں درست لگیں تو ناکامی اسٹیک میں آگے ہے اور آپ کو تصدیق کے حصے پر جانا چاہیے۔ کوڈ سے اندازہ نہ لگائیں: یکجائی ہر درخواست کے لیے ہوتی ہے، اسی لیے ایک سیشن دو ہوسٹوں کے لیے مختلف برتاؤ کر سکتا ہے۔

کچھ بھی بند کرنے سے پہلے نجی ہوسٹ کو خارج کریں

جب پراکسی دوسری منزلوں کے لیے واقعی ضروری ہو، تو تنگ حل اس ہوسٹ کے لیے استثنا ہے۔ موجودہ فہرست میں شامل کریں، اسے بدلیں نہیں، کیونکہ NO_PROXY مٹانا اس پر انحصار کرنے والی ہر دوسری اندرونی منزل کو توڑ دیتا ہے۔ نیچے دیے گئے احکام اندراج شامل کرتے ہیں اور پھر Requests سے پوچھتے ہیں کہ بائی پاس لاگو ہوتا ہے یا نہیں۔

export NO_PROXY="${NO_PROXY:+$NO_PROXY,}api.corp.example,.corp.example"
python3 -c "import requests;print(requests.utils.should_bypass_proxies('https://api.corp.example/status',None))"

ملاپ ہوسٹ لاحقے کے مطابق ہوتا ہے، اس لیے .corp.example پورا ڈومین ڈھکتا ہے جبکہ api.corp.example ایک نام ڈھکتا ہے۔ ننگا ستارہ ہر ہوسٹ کے لیے پراکسی بند کرتا ہے اور پروڈکشن کام تقریباً کبھی یہی نہیں چاہتا۔ CIDR اندراج مانا جائے گا یا نہیں یہ امیج میں Requests اور urllib3 کے ورژن پر منحصر ہے، اس لیے کام کرنے کا گمان کرنے کے بجائے درست اندراج آزمائیں۔ should_bypass_proxies کا نتیجہ اصل URL کے لیے جانچیں، یادداشت سے ٹائپ کیے گئے ہوسٹ نام کے لیے نہیں۔

دونوں تہوں کو ذہن میں الگ رکھیں۔ HTTP پراکسی سے گزرنا VPN سے نہیں گزرتا، کیونکہ پراکسی کا فیصلہ لائبریری میں اور سرنگ کا فیصلہ کرنل کی روٹنگ ٹیبل میں ہوتا ہے۔

trust_env کو صرف جان بوجھ کر لی گئی سیشن پالیسی کے طور پر بند کریں

اگر پورے کام کو ارد گرد کی ترتیب نظر انداز کرنی ہے، تو سیشن واضح طور پر بنائیں اور فیصلہ کوڈ میں درج کریں۔ یہ پالیسی ہے، وقتی حل نہیں، اور یہ ایسے diff میں ہے جو جائزہ لینے والا دیکھ سکے۔ نیچے کی مثال ٹائم آؤٹ، واضح CA راستہ اور حالت کی جانچ رکھتی ہے۔

import requests

with requests.Session() as session:
    session.trust_env = False
    response = session.get(
        "https://api.corp.example/status",
        timeout=(5, 20),
        verify="/etc/ssl/certs/corp-ca.pem",
    )
    response.raise_for_status()

trust_env بند کرنے سے ایک ساتھ تین برتاؤ بدلتے ہیں، اور ان میں سے صرف ایک پراکسی سے متعلق ہے۔ Requests .netrc اسناد پڑھنا بند کر دیتا ہے، اور REQUESTS_CA_BUNDLE اور CURL_CA_BUNDLE ویری ایبل verify پر اثر ڈالنا بند کر دیتے ہیں، جو پھر ساتھ آئے سرٹیفکیٹ اسٹور پر واپس جاتا ہے۔ اگر آپ کی تنظیم اپنے CA کے ساتھ TLS ختم کرتی ہے، تو یہ واپسی ایسی تصدیق کی خرابی پیدا کرتی ہے جو ابھی کیے گئے تبدیلی سے غیر متعلق لگتی ہے۔ verify واضح طور پر پاس کرنا ہی دونوں اثرات کو الگ رکھتا ہے۔

آپ کو جو نہیں کرنا چاہیے وہ ہے نتیجے میں آنے والی خرابی کو خاموش کرنے کے لیے verify=False سیٹ کرنا۔ یہ پراکسی کی غلط ترتیب کو غیر تصدیق شدہ کنکشن سے بدلتا ہے، اور اس سرٹیفکیٹ مسئلے کو چھپاتا ہے جسے استثنا ظاہر کرنا تھا۔

ناکام تہہ کی تصدیق کریں اور واپسی کی گنجائش رکھیں

تین ناکامیاں لاگ میں یکساں دکھتی ہیں اور ان میں کچھ مشترک نہیں: منزل تک نہ پہنچنے والی پراکسی ProxyError پھینکتی ہے یا 502 لوٹاتی ہے، بھروسے کا مسئلہ SSLError پھینکتا ہے، اور ایپلیکیشن کی مستردگی 401 یا 403 لوٹاتی ہے۔ آپ کے پاس کون سی ہے یہ دیکھنے کے لیے درخواست کو Requests سے باہر دوبارہ چلائیں۔ نیچے دیے گئے احکام پراکسی ہٹاتے ہیں، سرٹیفکیٹ زنجیر جانچتے ہیں اور پھر لائبریری کے ذریعے کال دہراتے ہیں۔

curl -sv --noproxy '*' https://api.corp.example/status -o /dev/null
openssl s_client -connect api.corp.example:443 -servername api.corp.example </dev/null
python3 -c "import requests;r=requests.get('https://api.corp.example/status',timeout=10);print(r.status_code)"

اگر curl کال کامیاب ہو اور Python کال ناکام ہو، تو فرق اب بھی ماحول ہے۔ اگر دونوں TLS مرحلے پر ناکام ہوں، تو پراکسی کبھی مسئلہ نہیں تھی اور مسئلہ سرٹیفکیٹ زنجیر ہے۔ اگر دونوں 401 لوٹائیں، تو درخواست ایپلیکیشن تک پہنچ گئی اور باقی کام تصدیق ہے۔ تینوں میں سے کون سی دیکھی، یہ درج کرنا اگلے شخص کا ایک گھنٹہ بچاتا ہے۔

واپسی کسی بھی سمت میں ایک سطر ہے: استثنا ہٹائیں، یا trust_env واپس پلٹیں۔ شامل کرنے سے پہلے پچھلی NO_PROXY قدر محفوظ کریں، اور صرف آپ کے ٹرمینل کی تاریخ میں زندہ رہنے والی ایکسپورٹ کے بجائے ریپر اسکرپٹ یا یونٹ سطح کے Environment= اندراج کو ترجیح دیں۔ دونوں تبدیلیاں عمل کے ماحول میں نظر آتی ہیں، اس لیے دوبارہ شروع کرنا عام طور پر آپ کو پرانے برتاؤ پر لوٹا دیتا ہے۔

چار چیزیں یقینی بنا کر ختم کریں: نجی URL کے لیے یکجا ترتیبات کوئی پراکسی نہیں دکھاتیں، سرٹیفکیٹ مطلوبہ CA کے خلاف درست ثابت ہوتا ہے، درخواست آپ کی متوقع حالت لوٹاتی ہے، اور تبدیلی کہیں دوبارہ پیدا کی جا سکنے والی جگہ پر commit ہے۔ غیر واضح ماحول کے ساتھ سبز اسکرپٹ وہ اصلاح ہے جو اگلی مشین پر پھر ٹوٹے گی۔ اس رہنما کے احکام ہی ٹکٹ میں چپکانے والے ہیں۔