HTTP 504 Gateway Timeout და თქვენი კლიენტის timeout
განასხვავეთ gateway-ში ვადაგასული upstream მოთხოვნა თქვენივე proxy კლიენტში დაყენებული timeout-ისგან.
თქვენი კლიენტი მზადაა სამოცი წამი დაელოდოს. ათი წამის შემდეგ ის იღებს HTTP 504-ს. კლიენტის timeout-ის ორ წუთამდე გაზრდა gateway-ს კიდევ ორმოცდაათ წამს არ აძლევს სამუშაოდ.
504 აღწერს gateway-ს ან proxy-ს, რომელმაც მოთხოვნის დასრულების მცდელობისას დროული upstream პასუხი არ მიიღო. Gateway-მა უკვე მიიღო გადაწყვეტილება და დააბრუნა პასუხი. თქვენს კლიენტს შეუძლია ეს პასუხი წარმატებით წაიკითხოს.
რომელმა შუამავალმა დააბრუნა ის?
გამომცემი შეიძლება იყოს წინა proxy. ასევე შეიძლება იყოს ვებსაიტის მიერ მართული შემდგომი gateway. CONNECT-ის შიგნით ჩვეულებრივი ბოლოდან ბოლომდე TLS-ის დროს, ამ დაცული დანიშნულების გაცვლიდან მოსული HTTP პასუხი არ არის იგივე, რაც თავად CONNECT-ის უარყოფა.
შეინახეთ ეტაპი, პასუხის სათაურები, შეცდომის გვერდის ფორმულირება და შესაბამისი ჟურნალები, სადაც ხელმისაწვდომია. სერვერის ეტიკეტი შეიძლება მინიშნება იყოს, მაგრამ არ უნდა ჩაითვალოს უშეცდომო მიკუთვნებად. მარშრუტი შეიძლება შეიცავდეს უფრო მეტ შუამავალს, ვიდრე თქვენს კლიენტშია კონფიგურირებული.
შემდეგ შეამოწმეთ, რატომ არ დასრულდა ის upstream ოპერაცია. ხელმისაწვდომობა, გადატვირთული სერვისები, მოთხოვნის სხეული, რომელსაც upstream ვერ ამუშავებს მოსალოდნელად, და აპლიკაციის ქცევა — ყველა შეიძლება მნიშვნელოვანი იყოს. მხოლოდ რიცხვითი სტატუსი არ ამტკიცებს, რომ User-Agent-ის შეცვლა ან ერთი timeout ოფციის დამატება უნივერსალური გადაწყვეტაა.
შეადარეთ იგივე მოთხოვნა
როცა სხვა ხელსაწყო მუშაობს, შეადარეთ მეთოდი, სამიზნე, სხეულის კოდირება, ავთენტიფიკაცია და მარშრუტი. „URL იხსნება ბრაუზერში“ არ არის სრული შედარება სერვისის კლიენტით multipart გაგზავნასთან.
თუ თქვენ მართავთ გამომცემ gateway-ს, შეუსაბამეთ მისი upstream ბიუჯეტი მხარდაჭერილ დატვირთვას და გარშემო არსებულ ვადებს. თუ არა, შეინახეთ მისი შედეგი როგორც მტკიცებულება და გამოიყენეთ ოპერატორის დოკუმენტირებული წვდომის ან მხარდაჭერის გზა. ლოკალურად უფრო ხანგრძლივი ლოდინი ვერ შეცვლის უკვე მოსულ პასუხს.