HTTP 504 Gateway Timeout a limit czasu twojego klienta
Odróżnij żądanie do upstreamu, które przekroczyło czas w bramie, od limitu czasu ustawionego w twoim własnym kliencie proxy.
Twój klient jest gotów czekać sześćdziesiąt sekund. Dziesięć sekund później otrzymuje HTTP 504. Podniesienie limitu czasu klienta do dwóch minut nie daje bramie kolejnych pięćdziesięciu sekund pracy.
504 opisuje bramę lub proxy, które podczas próby ukończenia żądania nie otrzymało na czas odpowiedzi z upstreamu. Brama podjęła już decyzję i zwróciła odpowiedź. Twój klient może tę odpowiedź bez problemu odczytać.
Który pośrednik ją zwrócił?
Wydawcą może być proxy forward. Również późniejsza brama obsługiwana przez witrynę. Przy zwykłym TLS od końca do końca wewnątrz CONNECT odpowiedź HTTP pochodząca z tej chronionej wymiany z miejscem docelowym nie jest tym samym co odrzucenie samego CONNECT.
Zachowaj etap, nagłówki odpowiedzi, treść strony błędu i pasujące logi, jeśli są dostępne. Etykieta serwera może być wskazówką, ale nie należy traktować jej jako nieomylnego przypisania. Trasa może zawierać więcej pośredników niż ten skonfigurowany w twoim kliencie.
Następnie sprawdź, dlaczego ta operacja po stronie upstreamu nie została ukończona. Osiągalność, przeciążone usługi, treść żądania, której upstream nie potrafi przetworzyć zgodnie z oczekiwaniem, oraz zachowanie aplikacji mogą mieć znaczenie. Sam status liczbowy nie dowodzi, że zmiana User-Agenta albo dodanie jednej opcji limitu czasu jest uniwersalnym rozwiązaniem.
Porównaj to samo żądanie
Gdy inne narzędzie działa, porównaj metodę, cel, kodowanie treści, uwierzytelnianie i trasę. „Adres URL otwiera się w przeglądarce” nie jest pełnym porównaniem z wysyłką multipart przez klienta usługi.
Jeśli zarządzasz bramą wydającą odpowiedź, dopasuj jej budżet upstreamu do obsługiwanego obciążenia i otaczających terminów. Jeśli nie, zachowaj jej wynik jako dowód i skorzystaj z udokumentowanej ścieżki dostępu lub wsparcia operatora. Dłuższe lokalne czekanie nie zmieni odpowiedzi, która już dotarła.