In this Article
کارپوریٹ نیٹ ورک کے اندر سے GitHub کے ساتھ کام کرنا عام طور پر ایک کنفیگریشن مسئلہ ہوتا ہے جو پانچ مختلف ٹولز میں پھیلا ہوتا ہے جو آپس میں سیٹنگز شیئر نہیں کرتے۔ ایک clone کامیاب ہو جاتا ہے مگر npm install ناکام ہو جاتی ہے؛ npm کام کرتا ہے مگر Docker pull نہیں کر پاتا؛ کمانڈ لائن پر سب کچھ چلتا ہے مگر IDE کچھ بھی حاصل نہیں کر پاتا۔
یہ گائیڈ اس بات کا احاطہ کرتی ہے کہ ہر ٹول اپنی پراکسی سیٹنگز کہاں سے پڑھتا ہے، SSH کا رویہ HTTPS سے مختلف کیوں ہوتا ہے، آپ کو نظر آنے والی چار عام قسم کی errors کو کیسے سمجھا جائے، اور وہ دو شارٹ کٹس جن سے گریز کرنا ضروری ہے۔
اہم حقائق
- ہر ٹول کی اپنی پراکسی کنفیگریشن ہوتی ہے۔ Git، npm، pip، Docker اور آپ کا shell سب مختلف سیٹنگز پڑھتے ہیں، یہی وجہ ہے کہ ایک کو ٹھیک کرنے سے باقی خراب ہی رہتے ہیں۔
- SSH عام طور پر وہاں ناکام ہوتا ہے جہاں HTTPS کام کرتا ہے، کیونکہ زیادہ تر کارپوریٹ پراکسیز صرف اسٹینڈرڈ پورٹس پر HTTP CONNECT ہی فارورڈ کرتی ہیں۔
- سرٹیفکیٹ کی errors تقریباً ہمیشہ TLS inspection کی نشاندہی کرتی ہیں، اور اس کا حل ویریفیکیشن بند کرنے کے بجائے کارپوریٹ CA پر بھروسا کرنا ہے۔
- clone کو کام کرنے کے لیے کبھی بھی سرٹیفکیٹ ویریفیکیشن بند نہ کریں۔ اس سے ایک نظر آنے والا کنفیگریشن مسئلہ ایک پوشیدہ سیکیورٹی مسئلے میں بدل جاتا ہے۔
- پراکسی URL میں credentials ڈالنے سے وہ logs اور shell history میں لیک ہو جاتی ہیں، اس لیے اس کے بجائے ٹول کے credential store کا استعمال کریں۔
ہر ٹول پراکسی سیٹنگز کہاں سے پڑھتا ہے؟
الگ الگ، اور یہی زیادہ تر الجھن کی جڑ ہے۔ ہم اسے 4-حصوں پر مشتمل ٹول چین ماڈل کہتے ہیں۔
| ٹول | یہ کہاں دیکھتا ہے | عام خامی |
|---|---|---|
| 1. Git | اپنی خود کی config، پھر environment variables | HTTPS remotes کام کرتے ہیں جبکہ SSH remotes نہیں کرتے |
| 2. پیکج مینیجرز | اپنی خود کی config فائلیں، پھر environment variables | ہر ایک کو الگ سے کنفیگر کرنا پڑتا ہے؛ registries GitHub سے مختلف ہو سکتی ہیں |
| 3. Docker | Daemon کنفیگریشن، نہ کہ صرف آپ کا shell | Shell variables اس daemon تک نہیں پہنچتیں جو images pull کرتا ہے |
| 4. IDEs اور ایڈیٹرز | اپنی خود کی سیٹنگز، کبھی کبھار system store | Terminal کام کرتا ہے، مگر مربوط فیچرز نہیں کرتے |
اس لیے ایک کارآمد github پراکسی سیٹ اپ کا مطلب پانچ کنفیگریشنز ہیں، ایک نہیں۔ عملی ترتیب یہ ہے کہ پہلے shell کے لیے environment variables سیٹ کریں، پھر git کو کنفیگر کریں، پھر ہر پیکج مینیجر کو، پھر Docker daemon کو، اور شروع ہی سے اندرونی hosts کے لیے no-proxy فہرست شامل کریں۔ آخری قدم چھوڑ دینے سے، ورنہ کامیاب سیٹ اپ کے باوجود اندرونی سروسز ناقابلِ رسائی رہ جاتی ہیں۔
HTTPS کام کرنے کے باوجود SSH کیوں ناکام ہوتا ہے؟
کیونکہ یہ مختلف پورٹس پر مختلف پروٹوکولز ہیں، اور زیادہ تر کارپوریٹ پراکسیز صرف چند مخصوص پورٹس کے لیے HTTP CONNECT ہی فارورڈ کرتی ہیں۔
HTTPS پر Git ایک عام ویب request ہے جسے پراکسی خود بخود سنبھال لیتی ہے۔ SSH پر Git پورٹ 22 استعمال کرتا ہے، جسے پراکسی کے ذریعے عام طور پر بالکل بھی اجازت نہیں ہوتی۔ نتیجہ یہ نکلتا ہے کہ ایک repository HTTPS remote کے ساتھ بخوبی clone ہو جاتی ہے مگر SSH remote کے ساتھ ٹائم آؤٹ ہو جاتی ہے، اور error message شاذ و نادر ہی وجہ بتاتا ہے۔
ترجیح کی ترتیب میں تین عملی حل ہیں: remote کو token کے ساتھ HTTPS پر منتقل کریں، جہاں GitHub سپورٹ کرتا ہو وہاں HTTPS پورٹ پر SSH استعمال کریں، یا نیٹ ورک ٹیم سے مخصوص hosts کے لیے SSH کی اجازت طلب کریں۔ پہلا حل ہر جگہ کام کرتا ہے اور زیادہ تر ٹیمیں اسی پر آ کر ٹھہرتی ہیں۔
آپ errors کو کیسے سمجھیں؟
| Error | یہ حل استعمال کریں جب | گریز کریں جب |
|---|---|---|
| Certificate verification failed | ٹول کے trust store میں کارپوریٹ CA شامل کریں | ویریفیکیشن کبھی بند نہ کریں، یہ ایک حقیقی خطرے کو چھپا دیتا ہے |
| SSH remote پر Connection timed out | HTTPS پر منتقل ہوں یا HTTPS پورٹ پر SSH استعمال کریں | دوبارہ کوشش کرنا؛ پورٹ سست نہیں بلکہ بلاک ہے |
| Proxy authentication required | ٹول کے store میں credentials کنفیگر کریں | انہیں URL میں ڈالنا، جو logs میں لیک ہو جاتا ہے |
| Terminal میں کام کرتا ہے، Docker میں ناکام | Docker daemon کنفیگر کریں، پھر اسے ری اسٹارٹ کریں | مزید shell variables شامل کرنا، جنہیں daemon کبھی نہیں پڑھتا |
| سیٹ اپ کے بعد اندرونی hosts ناقابلِ رسائی | انہیں no-proxy فہرست میں شامل کریں | پراکسی config کو مکمل طور پر ہٹا دینا |
پہلی قطار وہ ہے جس پر سختی سے قائم رہنا ضروری ہے۔ TLS inspection کا مطلب ہے کہ ایک middlebox آپ کے کنکشنز کو ختم کر کے دوبارہ سائن کر رہا ہے، اور درست ردعمل یہ ہے کہ ادارے کے CA پر جان بوجھ کر بھروسا کیا جائے۔ ویریفیکیشن بند کرنے سے error تو غائب ہو جاتی ہے مگر ہر مستقبل کی interception بھی پوشیدہ ہو جاتی ہے۔
بیرونی پراکسی کب صحیح ٹول ہے؟
اس مسئلے کے لیے شاذ و نادر ہی، اور اس بات کو واضح کر دینا ضروری ہے۔
کارپوریٹ پراکسی وہ انفراسٹرکچر ہے جسے آپ کا ادارہ چلاتا ہے، اور اس کے پیچھے GitHub تک رسائی کا حل کنفیگریشن ہے، دوسری پراکسی نہیں۔ اس نیٹ ورک کنٹرول کے گرد راستہ نکالنا جسے آپ کے آجر نے جان بوجھ کر نافذ کیا ہے، تکنیکی سوال بننے سے پہلے ایک پالیسی کا سوال ہے۔
جہاں ایک کمرشل پراکسی حقیقی طور پر لاگو ہوتی ہے وہ ایک الگ نوعیت کا کام ہے جس میں اتفاقاً GitHub بھی شامل ہوتا ہے: بڑے پیمانے پر عوامی repository ڈیٹا اکٹھا کرنا، یہ جانچنا کہ کوئی عوامی صفحہ کسی دوسرے ملک سے کیسا نظر آتا ہے، یا متعدد خطوں سے خودکار چیکس چلانا۔ خاص طور پر repository ڈیٹا اکٹھا کرنے کے لیے، token کے ساتھ GitHub API پہلا اور درست جواب ہے، اور یہ اتنا فیاض ہے کہ scraping شاذ و نادر ہی جائز قرار پاتی ہے۔
جب data اکٹھا کرنے کے کام کو واقعی distributed exits کی ضرورت ہو تو DataImpulse رہائشی پراکسی 195 ممالک کا احاطہ $1 فی GB کے حساب سے کرتی ہے۔ متعلقہ: ویب اسکریپنگ کے لیے پراکسیز، 403 Forbidden کی وضاحت۔
اکثر پوچھے جانے والے سوالات
میں git کو پراکسی استعمال کرنے کے لیے کیسے کنفیگر کروں؟
پراکسی کو git کی اپنی کنفیگریشن میں یا معیاری environment variables میں سیٹ کریں، اور ساتھ ہی اندرونی hosts کو no-proxy فہرست میں شامل کریں۔ Git اپنی config کو npm، pip اور Docker سے الگ پڑھتا ہے، اس لیے ہر ٹول کو انفرادی طور پر کنفیگر کرنا پڑتا ہے۔
پراکسی کے پیچھے SSH پر git clone کیوں ناکام ہوتا ہے؟
کیونکہ SSH پورٹ 22 استعمال کرتا ہے اور زیادہ تر کارپوریٹ پراکسیز صرف اسٹینڈرڈ ویب پورٹس کے لیے HTTP CONNECT ہی فارورڈ کرتی ہیں۔ HTTPS remotes کام کرتے ہیں کیونکہ یہ عام ویب requests ہیں۔ remote کو token کے ساتھ HTTPS پر منتقل کرنا وہ حل ہے جو زیادہ تر ماحول میں کام کرتا ہے۔
کارپوریٹ پراکسی کے پیچھے سرٹیفکیٹ کی errors کیوں آتی ہیں؟
TLS inspection: ایک middlebox آپ کے کنکشنز کو ادارے کے اپنے certificate authority کے ساتھ ختم کر کے دوبارہ سائن کرتا ہے۔ حل یہ ہے کہ اس CA کو ہر ٹول کے trust store میں شامل کیا جائے۔ سرٹیفکیٹ ویریفیکیشن بند کرنے سے error تو ختم ہو جاتی ہے مگر حقیقی interception کا پتہ لگانے کی آپ کی صلاحیت بھی ختم ہو جاتی ہے۔
جب میرا terminal کام کرتا ہے تو Docker کیوں ناکام ہوتا ہے؟
کیونکہ images pull کرنے کا کام Docker daemon کرتا ہے، آپ کا shell نہیں، اور یہ آپ کے environment variables کے بجائے اپنی خود کی کنفیگریشن پڑھتا ہے۔ daemon کی پراکسی سیٹنگز کنفیگر کریں اور اسے ری اسٹارٹ کریں۔
کیا مجھے کام پر GitHub تک رسائی کے لیے کمرشل پراکسی استعمال کرنی چاہیے؟
نہیں۔ کارپوریٹ پراکسی وہ انفراسٹرکچر ہے جسے آپ کا ادارہ جان بوجھ کر چلاتا ہے، اور حل کنفیگریشن ہے۔ کمرشل پراکسیز ایک الگ نوعیت کے کام کے لیے مناسب ہیں، جیسے متعدد خطوں سے عوامی ڈیٹا اکٹھا کرنا، اور وہاں بھی token کے ساتھ GitHub API عام طور پر بہتر راستہ ہوتا ہے۔
جب کام کنیکٹیویٹی کا نہیں بلکہ ڈیٹا اکٹھا کرنے کا ہو
یہ جانچنا کہ عوامی صفحات دوسرے خطوں سے کیسے نظر آتے ہیں، یا بڑے پیمانے پر عوامی ڈیٹا اکٹھا کرنا، کارپوریٹ نیٹ ورک کنفیگریشن سے ایک الگ مسئلہ ہے۔ DataImpulse رہائشی پراکسیز 195 ممالک کا احاطہ $1 فی GB کے حساب سے کرتی ہیں۔ جب یہی کام درکار ہو تو اکاؤنٹ بنائیں۔
متعلقہ: ویب اسکریپنگ کے لیے پراکسیز · اسکریپنگ کے دوران 403 Forbidden · ویب پراکسی کیا ہے۔
آخری تازہ کاری: 17 ستمبر، 2026۔