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-ს.