ပရောက်စီသုံးရာတွင် ERR_TUNNEL_CONNECTION_FAILED အမှားကို ဖြေရှင်းနည်း
Updated:
ပရောက်စီမှတစ်ဆင့် https:// စာမျက်နှာတစ်ခုကို ဖွင့်ရန် ဘရောက်ဇာသည် CONNECT တောင်းဆိုချက်တစ်ခု ပေးပို့ပြီး ဆိုက်သို့ ပရောက်စီက tunnel ဖွင့်ပေးမည့်အချိန်ကို စောင့်ဆိုင်းသည်။ ပရောက်စီက ခွင့်ပြုမည့်အစား အမှားတစ်ခုဖြင့် တုံ့ပြန်လာသောအခါ ERR_TUNNEL_CONNECTION_FAILED ပေါ်လာသည်။ အခက်အခဲမှာ မည်သည့်အမှားဖြစ်သည်ကို Chrome က သင့်အား မပြောပြခြင်းဖြစ်သောကြောင့် ပထမဆုံးလုပ်ဆောင်ရမည့်အလုပ်မှာ အမှန်တကယ်ဖြစ်နေသော ကုဒ်ကို ရှာဖွေရန်ဖြစ်သည်။
ကျွန်ုပ်တို့ စမ်းသပ်တွေ့ရှိခဲ့သော အခြေအနေ 2 ခု
နှစ်ခုစလုံးကို စမ်းသပ် ပရောက်စီတစ်ခုဖြင့် လုပ်ဆောင်ခဲ့ပြီး ဤနေရာတွင် နမူနာလိပ်စာ 203.0.113.10:8080 နှင့် user123:pass456 ဖြင့် ရေးသားဖော်ပြထားသည်။ ပုံမှန် Chrome ဝင်းဒိုးတစ်ခုတွင် 407 အခြေအနေသည် tunnel အမှားအဖြစ်သို့ မပြောင်းလဲပါ၊ ယင်းအစား Chrome သည် ပရောက်စီ အသုံးပြုသူအမည်နှင့် စကားဝှက်အတွက် အကောင့်ဝင်ရန် dialog တစ်ခုကို ဖွင့်ပေးသည်။ ထို့ကြောင့် 407 ကြောင့်ဖြစ်သော tunnel အမှားများသည် automation ကိရိယာများနှင့် စကားဝှက်တောင်းဆိုနိုင်ခြင်းမရှိသော အက်ပ်များတွင်သာ အများဆုံး ပေါ်လာတတ်သည်။
| ပရောက်စီက 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 |
ဖြစ်နိုင်ခြေအများဆုံး အကြောင်းရင်းများ
- Automation script က အထောက်အထားများ ပေးပို့ခြင်းမရှိခြင်း။ Chrome ၏
--proxy-serverflag သည် host နှင့် port ကိုသာ လက်ခံပြီး user:pass ကို လက်မခံပါ။ Headless Puppeteer သို့မဟုတ် Selenium သည် 407 ကို ရရှိပြီး tunnel ချို့ယွင်းချက်အဖြစ် ဖော်ပြသည်။ - စကားဝှက်ဖြင့် ကာကွယ်ထားသော Wi-Fi ပရောက်စီနောက်ကွယ်ရှိ ဖုန်းအက်ပ်တစ်ခု။ အက်ပ်တွင် အကောင့်ဝင်ရန် dialog မပါရှိသဖြင့် ဘရောက်ဇာ အလုပ်လုပ်နေချိန်တွင် HTTPS ချိတ်ဆက်မှု ပြတ်တောက်သွားသည်။
- ပရောက်စီက ပစ်မှတ်ဆိုက်သို့ မရောက်ရှိနိုင်ခြင်း။ ၎င်းသည် CONNECT သို့ 502 တုံ့ပြန်ပေးပို့သည်။ ဤအကြောင်းကို 502 Bad Gateway စာမျက်နှာ တွင် အသေးစိတ် ဖော်ပြထားသည်။
- ဆိုက်အချို့သာ ချိတ်ဆက်မရခြင်း။ အခြားဆိုက်များသည် တူညီသော ပရောက်စီမှတစ်ဆင့် အလုပ်လုပ်နေသော်လည်း သွားလိုသောပစ်မှတ်ဆိုက်က ပိတ်ဆို့ထားခြင်း သို့မဟုတ် ဒေါင်းနေခြင်းဖြစ်သည်။
curl command တစ်ခုတည်းဖြင့် အမှန်တကယ်ဖြစ်နေသော ကုဒ်ကို ရှာဖွေခြင်း
သင့်ကိုယ်ပိုင် တန်ဖိုးများဖြင့် curl -v -x http://user123:[email protected]:8080 https://example.com ကို run ပါ။ > CONNECT example.com:443 HTTP/1.1 ၏ အောက်ရှိ လိုင်းကို ကြည့်ပါ - 407 ဖြစ်ပါက 407 လမ်းညွှန် ကို လိုက်နာရန်ဖြစ်ပြီး 502 ဖြစ်ပါက ပစ်မှတ်ဆိုက် သို့မဟုတ် ပရောက်စီနောက်ကွယ်ရှိ လမ်းကြောင်းတွင် ပြဿနာရှိနေခြင်းကို ညွှန်ပြသည်။ terminal အသုံးမပြုလိုပါက အဆိုပါလိုင်းကို proxy checker ထဲသို့ ကူးထည့်ပါ၊ ၎င်းသည် အလားတူ အခြေအနေများအတွက် auth failed (407) သို့မဟုတ် HTTP 502 ဟု ဖော်ပြပေးမည်ဖြစ်သည်။
ပတ်ဝန်းကျင်အလိုက် ဖြေရှင်းနည်းများ
- Puppeteer: စတင်ချိန်တွင်
--proxy-server=http://host:portကို ထားရှိပြီး စာမျက်နှာ မဖွင့်မီpage.authenticate({ username, password })ကို ခေါ်ယူပါ။ ဥပမာအပြည့်အစုံကို Puppeteer ပရောက်စီ လမ်းညွှန် တွင် ကြည့်ရှုပါ။ - Playwright: ဘရောက်ဇာကို စတင်ချိန်တွင်
proxy: { server, username, password }ကို ထည့်သွင်းပေးပါ၊ Playwright က သင့်အတွက် 407 ကို အလိုအလျောက် ဖြေရှင်းပေးမည်ဖြစ်သည်။ Playwright ကို ကြည့်ပါ။ - Selenium: Chrome သည် command line တွင် user:pass ကို လက်မခံပါ၊ အသုံးပြုနိုင်သော နည်းလမ်းများကို Selenium လမ်းညွှန် တွင် ဖော်ပြထားသည်။
- Windows ပေါ်ရှိ Chrome: အကောင့်ဝင်ရန် dialog မပေါ်လာပါက ပရောက်စီ extension တစ်ခုခုက ပိတ်ပင်ထားခြင်း ရှိမရှိ စစ်ဆေးပြီး extension မပါသော ဝင်းဒိုးတွင် ထပ်မံကြိုးစားပါ။
- ဖုန်းများ: အထောက်အထားစိစစ်ရန် လိုအပ်သော ပရောက်စီကို သုံးသည့် အက်ပ်များအတွက် Android တပ်ဆင်မှုလမ်းညွှန် တွင် ဖော်ပြထားသည့်အတိုင်း user:pass ကို ထောက်ပံ့ပေးသော ပရောက်စီအက်ပ်တစ်ခုကို အသုံးပြုပါ။
အဆင့်ဆင့် လုပ်ဆောင်ရန်
- 1
CONNECT တုံ့ပြန်မှုကို စစ်ဆေးပါ
ပရောက်စီက 407 သို့မဟုတ် 502 ပြန်ပေးခြင်း ရှိမရှိ သိရှိရန် သင့် ပရောက်စီလိုင်းဖြင့်
curl -v -xကို run ပါ၊ သို့မဟုတ် checker ထဲသို့ ကူးထည့်ပါ။ - 2
407 အတွက် - အထောက်အထားများကို မှန်ကန်စွာ ထည့်သွင်းပါ
script များတွင်
--proxy-serverထဲသို့ user:pass ထည့်မည့်အစား library ၏ authentication hook ကို အသုံးပြုပါ။ - 3
502 အတွက် - အခြားဆိုက်တစ်ခုကို စမ်းကြည့်ပါ
တူညီသော ပရောက်စီမှတစ်ဆင့် example.com ကဲ့သို့သော ဝဘ်ဆိုက်ကြီးတစ်ခုကို ဖွင့်ကြည့်ပါ။ အလုပ်လုပ်ပါက မူရင်းပစ်မှတ်ဆိုက်တွင် ပြဿနာရှိနေခြင်းဖြစ်သည်။
- 4
ထပ်မံ run ပြီး exit IP ကို အတည်ပြုပါ
tunnel ပွင့်သွားသည်နှင့် traffic များ ပရောက်စီမှတစ်ဆင့် ဖြတ်သန်းသွားခြင်း ရှိမရှိ အတည်ပြုရန် ထိုဘရောက်ဇာတွင် my IP သို့ ဝင်ရောက်ကြည့်ရှုပါ။
မကြာခဏမေးလေ့ရှိသော မေးခွန်းများ
http စာမျက်နှာများ ပွင့်ပြီး https စာမျက်နှာများ အဘယ်ကြောင့် မပွင့်သနည်း။
ရိုးရိုး http သည် CONNECT မလိုအပ်ပါ၊ ပရောက်စီက တောင်းဆိုချက်ကို တိုက်ရိုက် ပေးပို့ပေးသည်။ https သာလျှင် tunnel ဖွင့်သောကြောင့် tunnel အမှားများသည် ၎င်းတွင်သာ ပေါ်လာခြင်းဖြစ်သည်။
Android တွင် ERR_TUNNEL_CONNECTION_FAILED အဘယ်ကြောင့် ဖြစ်သနည်း။
Wi-Fi ပရောက်စီသို့ အသုံးပြုသူအမည်နှင့် စကားဝှက်ကို မပို့ပေးနိုင်သော အက်ပ်တစ်ခုကြောင့် အဖြစ်များဆုံးဖြစ်သည်။ Android အတွက် Chrome တွင် ထိုစာမျက်နှာကို စမ်းဖွင့်ကြည့်ပါ၊ Chrome က တောင်းဆိုပြီး ဖွင့်နိုင်ပါက ပြဿနာမှာ အက်ပ်ကြောင့်ဖြစ်သည်။
--proxy-server ထဲတွင် user:pass ထည့်၍ ရပါသလား။
မရပါ။ Chrome သည် အဆိုပါ flag တွင် အထောက်အထားများကို လျစ်လျူရှုသောကြောင့် 407 နှင့် tunnel အမှားကို ဖြစ်ပေါ်စေသည်။ ယင်းအစား Puppeteer၊ Playwright သို့မဟုတ် extension တစ်ခုခုမှတစ်ဆင့် အထောက်အထား စိစစ်ပါ။
SOCKS5 သို့ ပြောင်းလဲလိုက်ပါက tunnel အမှား ပြေလည်သွားမည်လား။
သင့်အော်ဒါသည် SOCKS5 ဖြစ်မှသာ ပြေလည်ပါမည်။ VinaProxy သည် HTTP(S) နှင့် SOCKS5 နှစ်မျိုးလုံးကို ပံ့ပိုးပေးထားသည်၊ ကိုက်ညီမှုမရှိပါက အခြားအမှားများ ဖြစ်ပေါ်စေနိုင်သောကြောင့် dashboard တွင် သင့်အော်ဒါဖော်ပြထားသော protocol ကို ရွေးချယ်ပါ။
Puppeteer နှင့် Playwright တို့နှင့် အလုပ်လုပ်သော ပရောက်စီများ
VinaProxy ပရောက်စီများသည် လူကြိုက်များသော automation library များ အလွယ်တကူ ကိုင်တွယ်အသုံးပြုနိုင်သည့် စံသတ်မှတ်ချက် user:pass အကောင့်ဝင်ခြင်းကို အသုံးပြုသည်။
စျေးနှုန်းများ ကြည့်ရန်