پراکسی کے ساتھ ERR_TUNNEL_CONNECTION_FAILED کا حل
Updated:
پراکسی کے ذریعے https:// کا کوئی صفحہ لوڈ کرنے کے لیے، براؤزر CONNECT کی درخواست بھیجتا ہے اور پراکسی کی جانب سے سائٹ تک ٹنل کھولنے کا انتظار کرتا ہے۔ ERR_TUNNEL_CONNECTION_FAILED اس وقت ظاہر ہوتا ہے جب پراکسی منظوری دینے کے بجائے درخواست پر ایرر کا جواب دیتی ہے۔ اصل الجھن یہ ہے کہ Chrome یہ نہیں بتاتا کہ کون سا ایرر آیا ہے، اس لیے پہلا کام اصل کوڈ معلوم کرنا ہے۔
دو صورتیں جن کی ہم نے تصدیق کی
یہ دونوں ایک ٹیسٹ پراکسی پر چلائے گئے تھے، جنہیں یہاں دستاویزی ایڈریس 203.0.113.10:8080 اور user123:pass456 کے ساتھ لکھا گیا ہے۔ عام Chrome ونڈو میں 407 ٹنل ایرر نہیں بنتا؛ بلکہ Chrome پراکسی یوزر نیم اور پاس ورڈ کے لیے لاگ ان ڈائیلاگ کھولتا ہے۔ چنانچہ 407 کی وجہ سے پیدا ہونے والے ٹنل ایررز زیادہ تر آٹومیشن ٹولز اور ایسی ایپس میں سامنے آتے ہیں جو پاس ورڈ کا تقاضا نہیں کر سکتیں۔
| پراکسی CONNECT پر یہ جواب دیتی ہے | Chrome ظاہر کرتا ہے | curl ظاہر کرتا ہے |
|---|---|---|
407 پاس ورڈ درج کرنے کی سہولت کے بغیر (headless Chrome) | ERR_TUNNEL_CONNECTION_FAILED | curl: (56) CONNECT tunnel failed, response 407 |
502 کیونکہ پراکسی سائٹ تک نہیں پہنچ پا رہی | ERR_TUNNEL_CONNECTION_FAILED | curl: (56) CONNECT tunnel failed, response 502 |
وجوہات، سب سے زیادہ ممکنہ ترتیب سے
- کوئی آٹومیشن اسکرپٹ لاگ ان تفصیلات نہیں بھیجتا۔ Chrome کا
--proxy-serverفلیگ صرف host اور port قبول کرتا ہے، user:pass نہیں۔ Headless Puppeteer یا Selenium کو 407 ملتا ہے اور وہ ٹنل کی خرابی رپورٹ کرتے ہیں۔ - پاس ورڈ سے محفوظ Wi-Fi پراکسی پر چلنے والی فون ایپ۔ ایپ میں لاگ ان کا کوئی ڈائیلاگ نہیں ہوتا، اس لیے براؤزر کام کرتا رہتا ہے جبکہ HTTPS بند ہو جاتا ہے۔
- پراکسی مطلوبہ سائٹ تک نہیں پہنچ سکتی۔ یہ CONNECT پر 502 واپس کرتی ہے؛ ہمارا 502 Bad Gateway صفحہ اس کی تفصیلی وضاحت کرتا ہے۔
- صرف چند سائٹس نہیں کھلتیں۔ مطلوبہ سائٹ بلاک کر رہی ہے یا بند ہے جبکہ دیگر سائٹس اسی پراکسی کے ذریعے کام کر رہی ہیں۔
ایک curl کمانڈ سے اصل کوڈ معلوم کریں
اپنی تفصیلات کے ساتھ curl -v -x http://user123:[email protected]:8080 https://example.com چلائیں۔ ٹھیک > CONNECT example.com:443 HTTP/1.1 کے بعد والی لائن دیکھیں: 407 کا مطلب ہے کہ 407 گائیڈ پر عمل کریں؛ جبکہ 502 کا تعلق منزل یا پراکسی کے پیچھے موجود راستے سے ہے۔ اگر آپ ٹرمینل استعمال نہیں کرنا چاہتے، تو یہ لائن proxy checker میں پیسٹ کریں، جو انہی صورتوں میں auth failed (407) یا HTTP 502 دکھاتا ہے۔
مختلف ماحول کے لحاظ سے حل
- Puppeteer: آغاز پر
--proxy-server=http://host:portبرقرار رکھیں اور صفحے پر جانے سے پہلےpage.authenticate({ username, password })کال کریں۔ مکمل مثال Puppeteer proxy guide میں موجود ہے۔ - Playwright: براؤزر لانچ کرتے وقت
proxy: { server, username, password }پاس کریں اور Playwright آپ کے لیے 407 کا جواب خود دے دیتا ہے؛ Playwright دیکھیں۔ - Selenium: Chrome کمانڈ لائن پر user:pass قبول نہیں کرتا؛ Selenium guide قابلِ عمل طریقے دکھاتی ہے۔
- Windows پر Chrome: اگر سائن ان ڈائیلاگ کبھی ظاہر نہ ہو، تو چیک کریں کہ کیا کوئی پراکسی ایکسٹینشن اسے روک رہی ہے، پھر ایکسٹینشنز کے بغیر نئی ونڈو میں دوبارہ کوشش کریں۔
- فونز: ایسی ایپس کے لیے جنہیں تصدیق شدہ پراکسی درکار ہو، کوئی ایسی پراکسی ایپ استعمال کریں جو user:pass کو سپورٹ کرتی ہو جیسا کہ Android setup guide میں بیان کیا گیا ہے۔
مرحلہ وار
- 1
CONNECT کے جواب کی شناخت کریں
اپنی پراکسی لائن کے ساتھ
curl -v -xچلائیں، یا اسے چیکر میں پیسٹ کریں، تاکہ معلوم ہو سکے کہ پراکسی 407 واپس کر رہی ہے یا 502۔ - 2
407 کے لیے: لاگ ان تفصیلات درست طریقے سے فراہم کریں
اسکرپٹس میں،
--proxy-serverمیں user:pass ڈالنے کے بجائے متعلقہ لائبریری کا authentication hook استعمال کریں۔ - 3
502 کے لیے: کوئی دوسری سائٹ کھول کر دیکھیں
اسی پراکسی کے ذریعے کوئی بڑی سائٹ جیسے example.com لوڈ کریں۔ اگر وہ کھل جاتی ہے تو اصل مطلوبہ سائٹ میں ہی مسئلہ ہے۔
- 4
دوبارہ چلائیں اور آؤٹ گوئنگ IP کی تصدیق کریں
جب ٹنل کھل جائے، تو اسی براؤزر میں my IP کھولیں تاکہ تصدیق ہو سکے کہ ٹریفک پراکسی کے ذریعے جا رہی ہے۔
اکثر پوچھے جانے والے سوالات
http صفحات کیوں لوڈ ہو جاتے ہیں جبکہ https صفحات نہیں کھلتے؟
سادہ http کے لیے CONNECT کی ضرورت نہیں ہوتی؛ پراکسی درخواست کو براہِ راست آگے بھیج دیتی ہے۔ صرف https ٹنل کھولتا ہے، اس لیے ٹنل ایررز صرف وہیں آتے ہیں۔
Android پر ERR_TUNNEL_CONNECTION_FAILED کی کیا وجہ ہوتی ہے؟
اکثر ایسی ایپ جو Wi-Fi پراکسی کو یوزر نیم اور پاس ورڈ فراہم نہیں کر سکتی۔ وہی صفحہ Android کے لیے Chrome میں کھولیں؛ اگر Chrome تصدیق مانگ کر صفحہ لوڈ کر لے، تو مسئلہ ایپ میں ہے۔
کیا میں --proxy-server کے اندر user:pass لکھ سکتا ہوں؟
نہیں۔ Chrome اس فلیگ میں لاگ ان تفصیلات کو نظر انداز کر دیتا ہے، جس سے 407 اور ٹنل ایرر پیدا ہوتا ہے۔ اس کے بجائے Puppeteer، Playwright یا کسی ایکسٹینشن کے ذریعے تصدیق کریں۔
کیا SOCKS5 پر منتقل ہونے سے ٹنل کا ایرر ختم ہو جائے گا؟
صرف تب اگر آپ کا آرڈر SOCKS5 کا ہے۔ VinaProxy دونوں HTTP(S) اور SOCKS5 پیش کرتا ہے؛ وہی پروٹوکول منتخب کریں جو آپ کے آرڈر کے ڈیش بورڈ میں نظر آ رہا ہو، کیونکہ غلط انتخاب مختلف ایررز پیدا کرتا ہے۔
وہ پراکسیز جو Puppeteer اور Playwright کے ساتھ کام کرتی ہیں
VinaProxy کی پراکسیز معیاری user:pass لاگ ان استعمال کرتی ہیں جنہیں مقبول آٹومیشن لائبریریاں باآسانی سنبھال لیتی ہیں۔
قیمتیں دیکھیں