Introducing ZYNOO General Purpose & CPU Optimized Servers   Learn More >

Jak naprawić błąd 504 Gateway Timeout (7 sposobów)

Błąd 504 Gateway Timeout występuje, gdy serwer działający jako brama lub serwer proxy nie otrzyma na czas odpowiedzi od innego serwera. Zwykle dzieje się tak, gdy aplikacja obsługująca witrynę działa wolno, jest przeciążona lub ma problemy z połączeniem.

Jeśli odwiedzasz witrynę, odczekaj chwilę i odśwież stronę. Jeśli zarządzasz witryną, zacznij od sprawdzenia dzienników serwera i aplikacji, aby ustalić, gdzie występuje opóźnienie.

Oto siedem praktycznych sposobów na zdiagnozowanie tego błędu.

Co powoduje błąd 504 Gateway Timeout?

Wiele witryn korzysta z kilku serwerów lub usług do obsługi żądań.

Na przykład przeglądarka może połączyć się z Nginx lub siecią CDN, która następnie przekazuje żądanie do serwera aplikacji.

Jeśli aplikacja zbyt długo odpowiada, brama może zwrócić błąd 504 zamiast żądanej strony.

Typowe przyczyny to:

  • Przeciążone serwery aplikacji lub serwery, które nie odpowiadają.
  • Wolne zapytania do bazy danych lub żądania do zewnętrznych interfejsów API.
  • Niewystarczające zasoby procesora i pamięci RAM lub zbyt mała liczba procesów roboczych aplikacji.
  • Problemy sieciowe między bramą a serwerem zaplecza.
  • Limity czasu oczekiwania serwera proxy lub aplikacji.
  • Nieprawidłowo skonfigurowana sieć CDN lub infrastruktura hostingowa.

Błąd 504 zwykle oznacza problem po stronie serwera, choć problemy związane z konkretnym połączeniem mogą czasem dotyczyć pojedynczych odwiedzających.

Co powoduje błąd 504 Gateway Timeout

1. Odśwież witrynę i sprawdź jej dostępność

Jeśli tylko odwiedzasz witrynę, odczekaj chwilę i odśwież stronę.

Tymczasowe przeciążenie serwera lub przerwane żądanie do aplikacji może ustąpić bez interwencji.

Możesz też spróbować użyć innej przeglądarki lub sieci, aby sprawdzić, czy problem dotyczy Twojego połączenia.

Jeśli błąd występuje u wszystkich, zazwyczaj musi go zbadać właściciel witryny lub dostawca hostingu.

Nie wysyłaj wielokrotnie płatności, zamówień ani formularzy. Operacja w aplikacji mogła się zakończyć, nawet jeśli brama przekroczyła limit czasu, zanim zwróciła odpowiedź.

2. Sprawdź dzienniki serwera i aplikacji

Jeśli zarządzasz serwerem, najlepiej zacząć od plików dziennika.

W przypadku Nginx sprawdź dziennik błędów:

sudo tail -n 50 /var/log/nginx/error.log

Poszukaj komunikatów podobnych do:

upstream timed out (110: Connection timed out)

Oznacza to, że Nginx zbyt długo czekał na zakończenie operacji serwera nadrzędnego.

Następnie sprawdź dzienniki aplikacji, aby ustalić, dlaczego zaplecze odpowiadało wolno.

Możesz też sprawdzić usługę zarządzaną przez systemd:

sudo journalctl -u myapp -n 50

Zastąp myapp rzeczywistą nazwą usługi.

3. Sprawdź wykorzystanie procesora, pamięci RAM i dysku

Obciążony serwer może nie zdążyć przetworzyć żądań przed upływem limitu czasu bramy.

Sprawdź pamięć:

free -h

Sprawdź miejsce na dysku:

df -h

Monitoruj procesy:

top

Zwróć uwagę na utrzymujące się wysokie obciążenie zasobów, wyczerpaną pamięć, zapełnione systemy plików lub wyjątkowo obciążone procesy.

Takie wyniki same w sobie nie dowodzą, dlaczego upłynął limit czasu żądania, ale mogą pomóc wskazać wąskie gardła wydajności.

4. Sprawdź limity czasu Nginx i serwerów nadrzędnych

Jeśli Nginx pełni funkcję zwrotnego serwera proxy, sprawdź, czy aplikacja na serwerze nadrzędnym odpowiada w ramach skonfigurowanych limitów czasu.

W przypadku zaplecza HTTP konfiguracja może zawierać:

location / {
    proxy_pass http://127.0.0.1:3000;
    proxy_read_timeout 60s;
}

Ustawienie proxy_read_timeout określa, jak długo Nginx czeka między kolejnymi odczytami danych z zaplecza, a nie całkowity czas trwania żądania.

Zanim zwiększysz ten limit, przetestuj bezpośrednio zaplecze:

curl --max-time 15 -i http://127.0.0.1:3000/

Zastąp adres rzeczywistym punktem końcowym aplikacji. Niektóre ścieżki aplikacji mogą wymagać uwierzytelnienia lub zwracać prawidłową odpowiedź inną niż HTTP 200.

Jeśli sama aplikacja działa wolno, zwiększenie limitu czasu w Nginx może jedynie ukryć przyczynę problemu.

Gdy dłuższy limit czasu jest rzeczywiście uzasadniony, sprawdź również ustawienia limitów czasu aplikacji. Aplikacje oparte na PHP-FPM i FastCGI korzystają z innych dyrektyw Nginx niż zaplecza obsługiwane przez proxy HTTP.

Po zmianie konfiguracji sprawdź jej poprawność przed ponownym wczytaniem Nginx:

sudo nginx -t
sudo systemctl reload nginx

Wczytaj konfigurację ponownie tylko wtedy, gdy test zakończy się pomyślnie.

5. Sprawdź Cloudflare lub swoją sieć CDN

Jeśli Twoja witryna korzysta z Cloudflare lub innej sieci dostarczania treści, ustal, czy limit czasu upływa w sieci CDN, czy na serwerze źródłowym.

Sprawdź informacje o błędach swojej sieci CDN i porównaj je z dziennikami serwera źródłowego.

Błąd 504 może pochodzić z usługi nadrzędnej działającej za serwerem źródłowym lub z innej warstwy na drodze żądania.

Cloudflare ma własne zasady dotyczące limitów czasu połączenia i odpowiedzi, więc zwiększenie limitu w Nginx nie musi znosić ograniczenia narzuconego przez sieć CDN.

Nie wyłączaj funkcji bezpieczeństwa ani pamięci podręcznej bez ustalenia źródła przekroczenia limitu czasu.

6. Zbadaj wolne zapytania do bazy danych i zewnętrzne interfejsy API

Czasem serwer WWW działa prawidłowo, ale aplikacja czeka na inną usługę.

Typowe przykłady to:

  • Zapytanie do bazy danych, które trwa zbyt długo.
  • Zewnętrzny interfejs API, który odpowiada wolno.
  • Wyczerpana pula procesów roboczych aplikacji.
  • Zadania działające w tle konkurujące o zasoby.
  • Blokady bazy danych opóźniające żądania.

Przejrzyj dzienniki aplikacji, dzienniki wolnych zapytań i metryki usług, aby znaleźć przyczynę opóźnienia.

Jeśli przyczyną jest zapytanie do bazy danych, sprawdź indeksowanie, plany wykonania zapytań i wykorzystanie połączeń.

W przypadku wywołań zewnętrznych interfejsów API skonfiguruj rozsądne limity czasu i obsługę błędów. Jeśli aplikacja na to pozwala, długotrwałe zadania lepiej wykonywać asynchronicznie.

7. Skontaktuj się z dostawcą hostingu

Jeśli nie możesz usunąć błędu 504 Gateway Timeout, skontaktuj się z dostawcą hostingu i przekaż zebrane informacje.

Podaj nazwę dotkniętej problemem domeny, czas wystąpienia problemu, informację, czy błąd pojawia się sporadycznie, oraz istotne komunikaty z dzienników.

Wspomnij o niedawnych zmianach w aplikacji, bazie danych, sieci CDN lub konfiguracji zwrotnego serwera proxy.

Dostawca hostingu może pomóc zbadać ograniczenia zasobów i problemy z infrastrukturą, do której nie masz dostępu administracyjnego.

Błędy bramy 502 i 504: czym się różnią?

Te błędy są ze sobą powiązane, ale wskazują na różne problemy z serwerem nadrzędnym.

BłądZnaczenie
502 Bad GatewayBrama otrzymała nieprawidłową odpowiedź od serwera nadrzędnego
504 Gateway TimeoutBrama nie otrzymała na czas wymaganej odpowiedzi od serwera nadrzędnego

Na przykład aplikacja, która nieoczekiwanie zamyka połączenie, może spowodować błąd 502, a aplikacja, która zbyt długo odpowiada — błąd 504.

Jak zapobiegać błędom 504 Gateway Timeout

Nie każdemu przekroczeniu limitu czasu da się zapobiec, ale właściwe zarządzanie infrastrukturą pomaga ograniczyć ich liczbę.

  • Monitoruj czas odpowiedzi aplikacji i wykorzystanie zasobów.
  • Badaj wolne zapytania do bazy danych.
  • Stosuj odpowiednie buforowanie często żądanych treści.
  • Ustaw rozsądne limity czasu dla serwerów nadrzędnych i aplikacji.
  • Monitoruj usługi zaplecza i dostępność procesów roboczych.
  • Testuj większe zmiany konfiguracji przed ich wdrożeniem.

Zwiększanie limitów czasu powinno być przemyślaną decyzją, a nie pierwszym krokiem przy diagnozowaniu problemu.

Często zadawane pytania

Czy 504 Gateway Timeout to błąd serwera?

Tak. HTTP 504 to kod stanu wskazujący na problem po stronie serwera: brama lub serwer proxy nie otrzymały na czas odpowiedzi od serwera nadrzędnego.

Czy wyczyszczenie pamięci podręcznej przeglądarki może naprawić błąd 504?

Zwykle nie. Pamięć podręczna przeglądarki nie rozwiąże problemu przeciążonego serwera zaplecza ani serwera, który nie odpowiada. Sprawdzenie innej przeglądarki lub połączenia może jednak pomóc wykluczyć problemy lokalne.

Czy błąd 504 jest tymczasowy?

Może być. Tymczasowe przeciążenie lub wolne żądanie do zaplecza może szybko ustąpić, ale powtarzające się przekroczenia limitu czasu wskazują na problem wymagający zbadania.

Czy w witrynach opartych na WordPressie może wystąpić błąd 504?

Tak. W WordPressie i innych aplikacjach mogą występować błędy 504, gdy zapytania do bazy danych, przetwarzanie PHP lub usługi nadrzędne działają zbyt długo.

Czy należy zwiększyć limit czasu w Nginx, aby naprawić błąd 504?

Tylko wtedy, gdy aplikacja rzeczywiście potrzebuje więcej czasu i pozwalają na to pozostałe limity infrastruktury. Najpierw ustal, dlaczego odpowiedź zaplecza jest opóźniona.

Podsumowanie

Błąd 504 Gateway Timeout oznacza, że brama zbyt długo czekała na odpowiedź serwera nadrzędnego.

Odwiedzający mogą sprawdzić, czy problem jest tymczasowy, natomiast administratorzy powinni przeanalizować dzienniki, zasoby serwera, wydajność aplikacji i ustawienia serwera proxy.

Najpewniejszym sposobem naprawy jest znalezienie źródła opóźnienia zamiast zwiększania limitów czasu lub ponownego uruchamiania usług bez ustalenia przyczyny.

Table of Content

Błąd 502 Bad Gateway w Nginx zwykle oznacza, że Nginx nie otrzymał prawidłowej odpowiedzi z

Serwer MCP to program, który umożliwia aplikacjom AI łączenie się z zewnętrznymi narzędziami, usługami i

Czy potrzebujesz hostingu VPS? Prawdopodobnie nie, jeśli Twoja strona działa płynnie na hostingu współdzielonym. VPS

Build your next project with ZYNOO

From your first website to demanding applications, choose the resources and control you need.

Shared Hosting

Start your blog or business website with cPanel, LiteSpeed and CloudLinux.

VPS Hosting

Grow your websites and applications with NVMe storage, KVM virtualization and full root access.

Dedicated Servers

Power demanding projects with your own physical server, dedicated resources and control over your environment.

Przewijanie do góry