proxy_redirect-ը NGINX-ը չի միացնում ձեր VPN հոսթին
proxy_redirect-ը վերագրում է արդեն հասած պատասխանի վերնագրերը, այն երբեք չի ընտրում upstream-ը։ Ստուգեք proxy_pass-ը, դեպի backend տանող երթուղին, հետո վերնագրերը։
Անվան մեջ կա redirect բառը, ուստի այն փակցվում է location բլոկի մեջ, երբ VPN-ի հետևում գտնվող backend-ը հասանելի չէ։ Ոչինչ չի փոփոխվում, և ակնհայտ եզրակացությունն այն է, որ հրահանգը կոտրված է կամ այլ շարահյուսություն է պահանջում։ Իրականում եղածն ավելի պարզ ու քիչ շողոքորթ է՝ proxy_redirect-ը աշխատում է արդեն վերադարձած պատասխանի վրա, և այս տեղակայման մեջ ոչ մի հարցում այդքան հեռու չի հասել։
Երկու հրահանգ, երկու պահ մեկ հարցման մեջ
Հակադարձ պրոքսիով անցնող HTTP հարցումը հերթով անցնում է մի քանի որոշումներով, և երկու հրահանգները գտնվում են այդ հաջորդականության հակառակ ծայրերում։ Մեկը ընտրում է, թե ուր է գնում հարցումը։ Մյուսը խմբագրում է որոշակի վերնագրեր վերադարձող պատասխանի մեջ։
| Directive | When it acts | What it can change |
|---|---|---|
proxy_pass | Before any bytes leave the proxy | Which upstream receives the request |
proxy_redirect | After the upstream responds | Matching Location and Refresh text |
Այդ հերթականությունն է ամբողջ պատասխանը։ Եթե երկրորդ տողը երբեք չի կատարվում, որովհետև առաջինը ձախողվել է, երկրորդ հրահանգը սխալ կազմաձևված չէ, այն պարզապես անհասանելի է։ Ինչքան էլ վերագրեք երկրորդ տողը, պատասխանը, որը պետք է խմբագրեր, չի ստեղծվի։ Ախտորոշեք առաջին տողից դեպի դուրս, և շփոթեցնող վարքագիծը հանգում է բացակայող երթուղու կամ մերժված կապի։
Upstream-ի ընտրությունը proxy_pass-ինն է
Ենթադրենք՝ NGINX-ը աշխատում է հանրային մուտքի հոսթի վրա և իր VPN-ով հասնում է 10.40.0.20:8080 հասցեում գտնվող հավելվածին։ Այդ հավելվածն ընտրող հատվածը այսպիսի տեսք ունի՝ գոյություն ունեցող server բլոկի ներսում:
location / {
proxy_pass http://10.40.0.20:8080;
}Օգտագործեք իրական սխեման, հասցեն ու պորտը, և դա համարեք հատված, ոչ թե տեղակայում։ Մուտքի հոսթը նաև պետք է պահի VPN երթուղին, թույլատրված փոխանցման ուղին և աշխատող վերադարձի տրաֆիկը դեպի այդ ծառայությունը, որովհետև թղթի վրա հասցեին հասնող պրոքսին դեռ պետք է միջուկի համաձայնությունը։
proxy մոդուլի տեղեկատուն upstream-ի ընտրությունը առանձին է պահում պատասխանի վերնագրերի վերագրումից և նշում է, որ URI պարունակող proxy_pass արժեքը փոխում է, թե ինչպես է փոխարինվում համապատասխան location նախածանցը։ Ուղու բաղադրիչներ ավելացնելը կամ հեռացնելը՝ առանց հավելվածի սպասած URL-ը ստուգելու, 404 ստեղծելու հուսալի ձև է, որը նման է երթուղավորման ձախողման։
proxy_redirect-ը ուղղում է մասնավոր հասցե արտահոսող պատասխանները
Երբ տրաֆիկը սկսում է հոսել, backend-ը կարող է պատասխանել Location վերնագրով, որը նշում է իր մասնավոր հասցեն։ Այդ վերնագրին հետևող դիտարկիչը թողնում է հանրային մուտքի կետը և փորձում հասնել մի բանի, որը չի կարող լուծել։ Դիտավորյալ կազմաձևված պատասխանի վերագրումը մասնավոր URL-ը քարտեզագրում է հանրայինի վրա:
proxy_redirect http://10.40.0.20:8080/ https://app.example.com/;Փոխարինեք երկու կողմերն էլ իրական արժեքներով։ Հասկացեք նաև նեղ շրջանակը՝ համապատասխան Location և Refresh վերնագրերի տեքստը վերագրվում է, իսկ HTML-ում, JavaScript-ում կամ ներբեռնված ֆայլերում ներկառուցված URL-ները՝ ոչ։
Եթե հավելվածը ամենուր բացարձակ հղումներ է կառուցում, կայուն լուծումը նրա սեփական արտաքին URL-ի կազմաձևն է, ոչ թե պրոքսիի վրա աճող վերագրման կանոնների ցանկը։ Կանոններ ավելացնելը, մինչև ելքը ճիշտ տեսք ունենա, ստեղծում է կազմաձև, որը ձախողվում է առաջին էջում, որը ոչ ոք չի փորձարկել։ Հավելվածի մեկ ճիշտ կարգավորում փոխարինում է ամբողջ հավաքածուն։
Ինչ չի կարող ուղղել վերնագրի վերագրումը
Մի քանի հարակից խնդիրներ նման են վերահասցեավորման խնդիրների, բայց այդպիսին չեն։ Upstream-ին ուղարկվող Host վերնագիրը կարող է պահանջել համապատասխանել backend-ի վիրտուալ հոսթին։ TLS upstream-ը կարող է պահանջել կոնկրետ սերվերի անուն և վկայագրի ստուգում, և պատասխանի վերնագրի վերագրումը ոչ մեկին չի օգնում։
Cookie-ների շրջանակը և դոմենի ատրիբուտները պատկանում են հավելվածին և նրա կազմաձևին։ Պրոքսին կարող է ամբողջ օրը գցել կամ վերագրել վերնագրեր և այնուամենայնիվ ստեղծել սեսիա, որը ձախողվում է երկրորդ հարցման ժամանակ, որովհետև cookie-ն տրվել է հոսթի համար, որը դիտարկիչը երբեք չի այցելել։ Այդ ձախողումը ընդհատվող է թվում, դրա համար էլ այդքան երկար է ապրում տոմսերի հերթում։ Cookie-ի դոմենը կարդալը սովորաբար մեկ րոպեում ավարտում է հետաքննությունը։
Նույնպես պահեք նույնականացումը և backend-ի ընտրությունը նախատեսված հավելվածի սահմաններում։ Հանրային հակադարձ պրոքսին պետք է մեկ հավելված բացահայտի սերվերի VPN-ով, փոխարենը՝ դառնալու ընդհանուր դարպաս դեպի յուրաքանչյուր մասնավոր հասցե, որին այդ հոսթը կարող է հասնել։ Մեկ ընդհանուր location, որը փոխանցում է այն ամենը, ինչ խնդրում է կանչողը, մեկ բացահայտված ծառայությունը վերածում է ձեր մասնավոր ցանցի քարտեզի։ Անվանեք upstream-ը հստակ և թողեք այնտեղ։
Փորձարկեք այն հերթականությամբ, որով անցնում է հարցումը
Հերթով հաստատեք երեք բան՝ NGINX-ը ընտրեց նախատեսված location-ը, ավարտեց հարցումը դեպի backend, և դիտարկիչը հետևեց ցանկացած հետագա վերահասցեավորման ու բեռնեց ենթապաշարները։ Յուրաքանչյուր քայլ ունի իր լոգի տողերը, և դրանք հերթով կարդալը անորոշ 502-ը դարձնում է կոնկրետ հայտնագործություն։
Ձեզ անհրաժեշտ տարբերությունը ձախողված upstream կապի և անհասանելի մասնավոր անվան ուղարկված դիտարկիչի միջև է։ Առաջինը երևում է պրոքսիի սխալների լոգում, երկրորդը՝ որպես հարցում, որը երբեք չի հասնում, մինչ դիտարկիչը բողոքում է հոսթից, որը չի կարող լուծել։ Երկու տարբեր խնդիր, երկու տարբեր ֆայլ, և դրանցից միայն մեկն է առնչվում proxy_redirect-ին։