504 Gateway Timeout: Co oznacza i jak naprawic

Czym jest blad 504 Gateway Timeout?

504 Gateway Timeout to kod statusu HTTP, ktory oznacza, ze serwer dzialajacy jako brama lub proxy nie otrzymal odpowiedzi od serwera upstream w wyznaczonym czasie. Proxy czekal na odpowiedz upstream, ale trwalo to zbyt dlugo, wiec proxy zrezygnowal i zwrocil blad 504 do Twojej przegladarki.

Oficjalna definicja pochodzi z RFC 9110 (HTTP Semantics), sekcja 15.6.5, ktora stanowi: "Kod statusu 504 (Gateway Timeout) wskazuje, ze serwer, dzialajac jako brama lub proxy, nie otrzymal terminowej odpowiedzi od serwera upstream, do ktorego potrzebowal dostep, aby zrealizowac zadanie."

Kluczowe slowo to brama (gateway). Blad 504 zawsze dotyczy co najmniej dwoch serwerow: tego, z ktorym sie polaczyles (proxy/brama) oraz tego za nim (upstream/origin), ktory nie odpowiedzial na czas. Popularne serwery proxy to Nginx reverse proxy, Cloudflare, AWS Application Load Balancer (ALB) i CloudFront.

Jak wyglada blad 504

Komunikat bledu 504 rozni sie w zaleznosci od przegladarki, serwera WWW i CDN. Oto najczestsze komunikaty, na ktore mozesz natrafic.

• 504 Gateway Timeout

• 504 Gateway Time-out (domyslny Nginx — uzywa lacznika)

• HTTP Error 504 — Gateway Timeout

• Ta strona nie dziala — [domena] zbyt dlugo odpowiadala (Chrome / Edge)

• Gateway Timeout (Firefox)

• Error 504

• 504 Gateway Time-out — Serwer nie odpowiedzial na czas (Apache z mod_proxy)

• Error 524: A timeout occurred (specyficzny dla Cloudflare — technicznie nie 504, ale ta sama przyczyna)

• ERROR — The request could not be satisfied — 504 ERROR (AWS CloudFront)

Niezaleznie od brzmienia komunikatu, podstawowa przyczyna jest zawsze taka sama: serwer proxy czekal na odpowiedz serwera upstream, a serwer upstream nie odpowiedzial w skonfigurowanym oknie czasowym.

Jak dochodzi do bledu 504 Gateway Timeout

Aby zrozumiec blad 504, musisz zrozumiec lancuch timeoutow miedzy Twoja przegladarka a serwerem origin. Typowe zadanie webowe przechodzi przez wiele warstw, a kazda warstwa ma swoje wlasne ustawienie timeout.

Oto typowy przeplyw zadania: Przegladarka → CDN (Cloudflare) → Load Balancer → Nginx → PHP-FPM → Baza danych. Jesli zapytanie do bazy trwa 90 sekund, a proxy_read_timeout Nginx jest ustawiony na 60 sekund, Nginx przestaje czekac i zwraca 504 do load balancera, ktory przekazuje go do Twojej przegladarki.

Serwer, ktory zwraca 504, to zawsze posrednik (proxy lub brama), nigdy sam serwer origin. Serwer origin po prostu nie odpowiedzial na czas — moze nadal przetwarza zadanie lub mogl calkowicie ulec awarii.

Najczestsze przyczyny bledu 504 Gateway Timeout

Zrozumienie przyczyny to najszybsza droga do naprawy. Oto najczestsze powody, dla ktorych serwer zwraca 504, uszeregowane wedlug czestotliwosci.

• Wolny serwer origin — Skrypty PHP wykonujace zlozone zapytania do bazy danych, generujace raporty lub wywolujace wolne zewnetrzne API moga przekroczyc timeout proxy. To przyczyna nr 1 bledow 504.

• Przeciazenie serwera — CPU na 100%, brak pamieci (OOM kills) lub wszystkie workery PHP-FPM zajete. Serwer origin jest aktywny, ale zbyt przeciazony, by odpowiedziec na czas.

• Waskie gardlo bazy danych — Wolne zapytania SQL, brakujace indeksy, blokady tabel lub wyczerpane pule polaczen. Aplikacja zawiesza sie czekajac na baze, a proxy przekracza timeout.

• Zle skonfigurowane wartosci timeout — Nginx proxy_read_timeout ustawiony zbyt nisko dla backendu, ktory realnie potrzebuje wiecej czasu (np. generator raportow lub handler uploadow plikow).

• Problemy sieciowe miedzy proxy a origin — Utrata pakietow, wysokie opoznienia lub problemy z routingiem miedzy centrami danych. Czeste w konfiguracjach multi-region lub chmury hybrydowej.

• Firewall lub security group blokuje ruch — AWS security groups nie pozwalaja na ruch na portach efemerycznych, reguly iptables blokuja polaczenia wewnetrzne lub WAF blokuje uprawnione zadania upstream.

• Niepowodzenie rozpoznawania DNS na proxy — Proxy nie moze rozwiazac nazwy hosta upstream. W Nginx dzieje sie tak, gdy uzywasz zmiennych w proxy_pass bez dyrektywy resolver.

• Timeout CDN — Cloudflare ma sztywny limit 100 sekund na planach Free/Pro/Business. Jesli Twoj origin potrzebuje dluzej niz 100 sekund, Cloudflare zwraca Error 524 niezaleznie od konfiguracji Nginx.

• Atak DDoS — Fala zadan wyczerpuje zasoby serwera, powodujac, ze origin jest zbyt wolny, aby odpowiadac na uprawniony ruch w ramach timeout proxy.

Rozwiazanie dla odwiedzajacych: Co mozesz zrobic

Jesli widzisz blad 504 na cudzej stronie, problem jest po stronie ich serwera — nie Twojego urzadzenia. Jednak jest kilka rzeczy, ktore warto sprobowac.

• Poczekaj i odswiez — Wiekszosc bledow 504 jest tymczasowa. Poczekaj 30-60 sekund, a nastepnie wymus odswiezenie strony klawiszami Ctrl+Shift+R (Windows/Linux) lub Cmd+Shift+R (Mac).

• Sprawdz, czy strona nie dziala u wszystkich — Uzyj narzedzia HTTP Headers od DNS Robot, aby sprawdzic kod odpowiedzi serwera z zewnetrznej lokalizacji. Jesli zwraca 504 dla kazdego, problem jest po stronie serwera.

• Sprobuj tryb incognito lub inna przegladarke — Wyklucza rozszerzenia przegladarki, zbuforowane strony bledow i lokalne problemy konfiguracyjne.

• Sprobuj inna siec — Przelacz sie z Wi-Fi na dane mobilne lub wylacz VPN. Problemy z routingiem miedzy Twoim ISP a serwerem moga czasem powodowac 504.

• Wyczysc cache DNS — Przestarzale rekordy DNS moga kierowac zadania do niewlasciwego serwera. W Windows: ipconfig /flushdns. Na Mac: sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder.

• Sprawdz strone statusu lub media spolecznosciowe witryny — Strona mogla opublikowac informacje o znanej awarii lub oknie serwisowym.

Fix 1: Zwieksz ustawienia timeout (Nginx i Apache)

Najczestszym rozwiazaniem bledow 504 jest zwiekszenie wartosci timeout na Twoim reverse proxy. Jesli Twoj backend realnie potrzebuje wiecej niz 60 sekund (domyslnie), proxy musi wiedziec, ze ma dluzej czekac.

# Nginx — reverse proxy to a backend (Node.js, Python, etc.)
location / {
    proxy_pass http://backend;
    proxy_connect_timeout 300;
    proxy_send_timeout    300;
    proxy_read_timeout    300;
    send_timeout          300;
}

# Nginx — FastCGI (PHP-FPM)
location ~ \.php$ {
    fastcgi_pass unix:/var/run/php-fpm.sock;
    fastcgi_read_timeout    300;
    fastcgi_send_timeout    300;
    fastcgi_connect_timeout 300;
    include fastcgi_params;
}

Dla Apache z mod_proxy dodaj ProxyTimeout 300 w swoim VirtualHost lub uzyj ProxyPass / http://backend:8080/ timeout=300 dla konfiguracji per-backend.

Wazne: Te timeouty mierza czas miedzy dwoma kolejnymi operacjami odczytu/zapisu, a nie calkowity czas transferu. Wiec proxy_read_timeout 300 oznacza "jesli przez 300 sekund nie nadejda zadne dane", a nie "cala odpowiedz musi byc ukonczona w 300 sekund". Po zmianie wartosci timeout przeladuj konfiguracje: sudo nginx -t && sudo systemctl reload nginx.

Fix 2: Zoptymalizuj wolne skrypty i zapytania do bazy danych

Jesli Twoj backend konsekwentnie przekracza timeout, zwiekszanie wartosci timeout tylko maskuje problem. Prawdziwe rozwiazanie to przyspieszenie odpowiedzi backendu.

• Znajdz wolne zapytania — Wlacz MySQL slow query log (slow_query_log = 1, long_query_time = 1) lub uzyj EXPLAIN ANALYZE na podejrzanych zapytaniach. Dodaj brakujace indeksy, unikaj SELECT * i paginuj duze zbiory wynikow.

• Dodaj cache — Uzyj Redis lub Memcached do cachowania kosztownych wynikow zapytan. Zapytanie, ktore trwa 5 sekund przy kazdym zaladowaniu strony, powinno byc zcachowane.

• Przenies ciezka prace do zadan w tle — Generowanie raportow, wysylanie e-maili, przetwarzanie obrazow i importy danych powinny dzialac w kolejce zadan (Celery, Sidekiq, Bull), a nie w cyklu zadania HTTP.

• Zoptymalizuj wywolania API — Jesli Twoj backend wywoluje wolne zewnetrzne API, dodaj timeouty do tych wywolan i zaimplementuj circuit breakery, aby jedno wolne API nie blokowalo wszystkich zadan.

• Zredukuj zapytania N+1 — Zapytania generowane przez ORM czesto wykonuja setki pojedynczych wywolan do bazy. Uzyj eager loading lub zapytan wsadowych, aby zmniejszyc liczbe roundtripow.

Fix 3: Sprawdz zasoby serwera (CPU, RAM, dysk)

Jesli serwer origin jest przeciazony, nie jest w stanie przetworzyc zadan wystarczajaco szybko, a proxy przekracza timeout. Sprawdz, co zuzywa zasoby.

# Check CPU and memory usage
top -bn1 | head -20

# Check disk space (full disk = silent failures)
df -h

# Check memory details
free -m

# Find processes using the most CPU
ps aux --sort=-%cpu | head -10

# Find processes using the most memory
ps aux --sort=-%mem | head -10

# Check active network connections
ss -s

Jesli CPU lub RAM jest na poziomie 90%+, musisz albo zoptymalizowac aplikacje, ubic niekontrolowane procesy, albo ulepszyc serwer. Jesli dysk jest pelny, usun stare pliki logow, kopie zapasowe lub pliki tymczasowe — pelny dysk moze po cichu powodowac awarie baz danych i kaskadowe bledy 504.

Fix 4: Sprawdz logi bledow

Logi bledow mowia dokladnie, dlaczego proxy zwrocil 504. Zawsze sprawdz logi przed zgadywaniem przyczyny.

# Nginx error log (look for "upstream timed out")
tail -50 /var/log/nginx/error.log

# Apache error log
tail -50 /var/log/apache2/error.log       # Debian/Ubuntu
tail -50 /var/log/httpd/error_log          # CentOS/RHEL

# PHP-FPM log
tail -50 /var/log/php8.2-fpm.log

# System log (OOM kills, crashes)
tail -50 /var/log/syslog

Typowe komunikaty w logach powodujace 504:

"upstream timed out (110: Connection timed out)" (Nginx) — Serwer upstream nie odpowiedzial w ramach proxy_read_timeout. Zwieksz timeout lub napraw wolny upstream.

"server reached pm.max_children" (PHP-FPM) — Wszystkie procesy PHP worker sa zajete. Zwieksz pm.max_children w konfiguracji puli PHP-FPM.

"connect() failed (111: Connection refused)" (Nginx) — Serwer upstream nie dziala lub nie nasluchuje na oczekiwanym porcie. Zrestartuj backend.

"Too many connections" (MySQL) — Limit polaczen bazy danych jest wyczerpany. Zwieksz max_connections w konfiguracji MySQL lub zoptymalizuj pooling polaczen.

Fix 5: Dostosuj ustawienia PHP-FPM

Po zmianie ustawien PHP-FPM zrestartuj usluge: sudo systemctl restart php8.2-fpm. Upewnij sie, ze fastcgi_read_timeout Nginx jest zawsze wiekszy lub rowny max_execution_time PHP. W przeciwnym razie Nginx poddaje sie przed zakonczeniem pracy PHP, co powoduje blad 504.

Fix 6: Sprawdz konfiguracje CDN i proxy

Uzytkownicy Cloudflare: Jesli jestes na planie Free, Pro lub Business i Twoj origin potrzebuje wiecej niz 100 sekund, zawsze otrzymasz Error 524. Jedyne opcje to: zoptymalizuj backend, aby odpowiadal w ciagu 100 sekund, przenies dlugotrwale zadania do zadan w tle lub przejdz na plan Enterprise.

Uzytkownicy AWS CloudFront: Zwieksz timeout odpowiedzi origin w ustawieniach origin Twojej dystrybucji. Domyslne 30 sekund czesto nie wystarcza dla dynamicznej tresci.

Uzyj narzedzia HTTP Headers od DNS Robot, aby sprawdzic naglowki odpowiedzi i zidentyfikowac, ktora warstwa zwraca 504. Szukaj naglowkow takich jak server: cloudflare, server: awselb/2.0 lub server: nginx, aby wskazac proxy.

Fix 7: Rozwiazania specyficzne dla WordPress

Strony WordPress sa szczegolnie narazone na bledy 504 z powodu ciezkich wtyczek, rozdecia bazy danych i limitow hostingu wspoldzielonego. Oto ukierunkowane rozwiazania.

• Zidentyfikuj wolne wtyczki — Dezaktywuj wszystkie wtyczki, a nastepnie aktywuj je po jednej. Jesli nie mozesz dostac sie do wp-admin, zmien nazwe folderu plugins przez SSH: mv wp-content/plugins wp-content/plugins_disabled. Uzyj wtyczki Query Monitor do identyfikacji wolnych zapytan do bazy.

• Zwieksz pamiec PHP — Dodaj define('WP_MEMORY_LIMIT', '512M'); do wp-config.php. Wiele wtyczek potrzebuje wiecej niz domyslne 128MB.

• Zainstaluj wtyczke cachowania — WP Super Cache, W3 Total Cache lub WP Rocket zmniejsza obciazenie serwera, serwujac statyczne HTML zamiast uruchamiania PHP przy kazdym zadaniu.

• Uzyj object caching — Zainstaluj Redis lub Memcached i wtyczke WordPress object cache. Cachuje to wyniki zapytan bazy danych w pamieci, zmniejszajac obciazenie MySQL.

• Wyczysc baze danych — Usun stare rewizje postow, transienty, komentarze spamowe i osierocone metadane. Uzyj WP-Optimize lub WP-Sweep. Dodaj define('WP_POST_REVISIONS', 5);, aby ograniczyc przyszle rewizje.

• Wylacz wp-cron — Wirtualny cron WordPress uruchamia sie przy kazdym zaladowaniu strony i moze gromadzic zadania. Dodaj define('DISABLE_WP_CRON', true); do wp-config.php i skonfiguruj prawdziwe zadanie cron serwera: */5 * * * * curl -s https://yoursite.com/wp-cron.php > /dev/null 2>&1.

504 vs 502 vs 503 vs 408: Jaka jest roznica?

Kluczowa roznica: 502 oznacza, ze proxy otrzymal bledna odpowiedz, podczas gdy 504 oznacza, ze proxy nie otrzymal zadnej odpowiedzi. 503 nie wymaga proxy — kazdy serwer moze go zwrocic przy przeciazeniu. 408 to timeout po stronie klienta (klasa 4xx), gdzie serwer zrezygnowal z czekania na klienta.

Jesli widzisz 502 i 504 jednoczesnie, serwer upstream prawdopodobnie ulega awarii. 502 wystepuje, gdy proxy otrzymuje czesciowa lub uszkodzona odpowiedz od umierajacego procesu, a 504 wystepuje, gdy proces jest calkowicie niereaktywny.

Czy blad 504 wplywa na SEO?

Krotka odpowiedz: krotki 504 nie ma wplywu na SEO. Dlugotrawly 504 moze prowadzic do deindeksacji.

Minuty do godzin: Brak wplywu. Google rozumie tymczasowe bledy serwerowe i nie karze natychmiast. Jesli Googlebot nie zaindeksuje strony podczas awarii, nawet jej nie zauwazy.

Godziny do dni: Google zmniejsza czestotliwosc crawlowania dla stron zwracajacych bledy 5xx, aby nie dokladac obciazenia do zmagajacego sie serwera. Strony moga pojawic sie jako "Blad serwera (5xx)" w raporcie Indeksowania stron w Google Search Console.

Dni do tygodni: Utrzymujace sie bledy 504 moga prowadzic do deindeksacji dotknionych stron. Rankingi znaczaco spadaja. Wedlug Johna Muellera z Google: jesli serwer nie dziala przez dzien, sprawy moga byc "niestabilne" przez jeden do trzech tygodni po naprawie.

Odzyskiwanie: Po ustabilizowaniu serwera Google automatycznie ponownie crawluje i indeksuje strony. Uzyj narzedzia Inspekcja URL w Google Search Console, aby zlozyc prosbe o ponowne zaindeksowanie waznych stron. Czas odzyskiwania zalezy od rozmiaru witryny i czasu trwania bledow.

Jak zapobiegac bledom 504 Gateway Timeout

Zapobieganie jest lepsze niz gaszenie pozarow. Te praktyki utrzymaja Twoj serwer w ramach limitow timeout.

• Skonfiguruj monitoring — Uzyj monitoringu uptime (UptimeRobot, Pingdom lub narzedzia Ping od DNS Robot), aby wykrywac bledy 504, zanim zglsza je uzytkownicy.

• Dopasuj lancuch timeoutow — Upewnij sie, ze timeout CDN >= timeout proxy >= timeout aplikacji. Niedopasowane wartosci powoduja nieprzewidywalne bledy 504.

• Zaimplementuj health checki — Load balancery i proxy powinny sprawdzac stan serwerow upstream i kierowac ruch z dala od niereaktywnych instancji.

• Agresywnie cachuj — Cachuj zasoby statyczne, odpowiedzi API i zapytania do bazy danych. Zcachowana odpowiedz nigdy nie jest wystarczajaco wolna, aby spowodowac 504.

• Auto-skalowanie — Uzyj skalowania horyzontalnego (wiecej instancji), aby skoki ruchu nie przeciazaly pojedynczego serwera.

• Przenies ciezka prace na zewnatrz — Przenies przetwarzanie plikow, generowanie raportow, wysylanie e-maili i masowe importy do kolejek zadan w tle. Nigdy nie wykonuj kosztownych operacji w ramach zadania HTTP.

• Monitoruj wolne zapytania — Wlacz logowanie wolnych zapytan w MySQL/PostgreSQL. Ustaw alarmy dla zapytan przekraczajacych 1 sekunde.

• Dbaj o zdrowie zaleznosci — Monitoruj zewnetrzne API, od ktorych zalezy Twoj backend. Dodaj timeouty i circuit breakery, aby jedno wolne API nie powodowalo kaskadowych bledow 504 dla wszystkich uzytkownikow.