ERR_TUNNEL_CONNECTION_FAILED սխալի շտկումը պրոքսիի հետ

Updated: 2026-11-05

Պրոքսիի միջոցով https:// էջ բեռնելու համար բրաուզերն ուղարկում է CONNECT հարցում և սպասում, որ պրոքսին թունել բացի դեպի կայքը: ERR_TUNNEL_CONNECTION_FAILED-ն ի հայտ է գալիս, երբ համաձայնելու փոխարեն պրոքսին այդ հարցմանը պատասխանում է սխալով: Խնդիրն այն է, որ Chrome-ը չի նշում, թե որ սխալն է դա, ուստի առաջին քայլը բուն կոդը պարզելն է:

Պրոքսիներ, որոնք աշխատում են Puppeteer-ի և Playwright-ի հետ

Տեսնել գները Free Proxy Checker

Երկու դեպք, որոնք մենք վերարտադրել ենք

Երկուսն էլ գործարկվել են թեստային պրոքսիի վրա, որոնք այստեղ ներկայացված են փաստաթղթային 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-ը մատնանշում է նպատակակետը կամ պրոքսիից այն կողմ գտնվող ուղին: Եթե նախընտրում եք չօգտագործել տերմինալ, տեղադրեք տողը պրոքսիի ստուգիչի մեջ, որը նույն իրավիճակների համար ցույց է տալիս 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-ը հրամանային տողում չի ընդունում user:pass. Selenium-ի ուղեցույցը ցույց է տալիս կիրառելի տարբերակներ:
Chrome-ը Windows-ում. եթե մուտքի երկխոսությունը չի հայտնվում, ստուգեք՝ արդյոք պրոքսիի ընդլայնումն այն չի ճնշում, ապա նորից փորձեք առանց ընդլայնումների պատուհանում:
Հեռախոսներ. նույնականացում պահանջող պրոքսիով աշխատող հավելվածների համար օգտագործեք user:pass ապահովող պրոքսի-հավելված, ինչպես նկարագրված է Android-ի կարգավորման ուղեցույցում:

Քայլ առ քայլ

1
Պարզեք CONNECT-ի պատասխանը
Գործարկեք curl -v -x-ը ձեր պրոքսիի տվյալներով կամ տեղադրեք այն ստուգիչի մեջ՝ պարզելու համար, թե արդյոք պրոքսին վերադարձնում է 407 կամ 502:
2
407-ի դեպքում՝ տրամադրեք տվյալները ճիշտ եղանակով
Սկրիպտներում user:pass-ը --proxy-server-ում նշելու փոխարեն օգտագործեք գրադարանի նույնականացման հնարավորությունը:
3
502-ի դեպքում՝ փորձեք այլ կայք
Նույն պրոքսիով բեռնեք որևէ հայտնի կայք, օրինակ՝ example.com-ը: Եթե այն աշխատում է, ապա խնդիրը սկզբնական նպատակակետի մեջ է:
4
Կրկին գործարկեք և ստուգեք ելքային IP-ն
Թունելը բացվելուն պես նույն բրաուզերով այցելեք իմ IP-ն՝ համոզվելու, որ թրաֆիկն անցնում է պրոքսիի միջով:

Հաճախ տրվող հարցեր

Ինչո՞ւ են http էջերը բեռնվում, իսկ https էջերը՝ խափանվում:

Սովորական http-ն CONNECT-ի կարիք չունի. պրոքսին հարցումն ուղղակիորեն վերահասցեավորում է: Միայն https-ն է թունել բացում, ուստի թունելի սխալներն առաջանում են միայն այնտեղ:

Ի՞նչն է առաջացնում ERR_TUNNEL_CONNECTION_FAILED սխալը Android-ում:

Առավել հաճախ՝ այնպիսի հավելվածը, որը չի կարողանում օգտանունն ու գաղտնաբառը փոխանցել Wi-Fi պրոքսիին: Փորձեք նույն էջը բացել Chrome for Android-ում. եթե Chrome-ը կարողանում է հարցնել տվյալները և բեռնել էջը, ապա խնդիրը հավելվածի մեջ է:

Կարո՞ղ եմ user:pass նշել --proxy-server-ի ներսում:

Ո՛չ: Chrome-ն անտեսում է այդ դրոշակի մեջ նշված նույնականացման տվյալները, ինչը հանգեցնում է 407-ի և թունելի սխալի: Փոխարենը նույնականացումն իրականացրեք Puppeteer-ի, Playwright-ի կամ ընդլայնման միջոցով:

Արդյո՞ք SOCKS5-ին անցնելը կվերացնի թունելի սխալը:

Միայն եթե ձեր պատվերը SOCKS5 է: VinaProxy-ն առաջարկում է և՛ HTTP(S), և՛ SOCKS5. ընտրեք այն արձանագրությունը, որը նշված է ձեր պատվերում՝ կառավարման վահանակում, քանի որ անհամապատասխանությունն այլ սխալներ է առաջացնում: