504 Gateway Timeout to kod błędu HTTP, który pojawia się, gdy serwer pełniący rolę bramy lub pośrednika (np. serwer proxy, load balancer lub reverse proxy) nie otrzymał w wymaganym czasie odpowiedzi od serwera upstream — czyli serwera docelowego obsługującego faktyczne żądanie. Innymi słowy: serwer „środkowy” czekał za długo i poddał się zanim odpowiedź w ogóle dotarła. Błąd ten różni się od 503 Service Unavailable tym, że problem leży nie w niedostępności usługi, lecz w przekroczeniu limitu czasu komunikacji między warstwami infrastruktury.
- Kod 504 sygnalizuje problem po stronie serwera, nie przeglądarki ani użytkownika.
- Najczęstsze przyczyny to przeciążony serwer aplikacji, długie zapytania do bazy danych lub błędna konfiguracja proxy.
- Błąd ma bezpośredni wpływ na indeksowanie przez Googlebot i ocenę Core Web Vitals.
- W większości przypadków jest tymczasowy — ale ignorowany, potrafi trwale zaszkodzić pozycjom w wyszukiwarce.
Jak działa błąd 504 w praktyce
Żądanie HTTP rzadko trafia wprost z przeglądarki do aplikacji — po drodze przechodzi przez kilka warstw infrastruktury. Każda z nich ma ustawiony własny limit czasu oczekiwania (timeout). Gdy limit zostaje przekroczony, warstwa pośrednicząca zwraca właśnie kod 504.
Architektura, w której pojawia się 504
Typowy stos wygląda tak: przeglądarka → CDN → load balancer (np. HAProxy, AWS ELB) → reverse proxy (np. Nginx) → serwer aplikacji (np. PHP-FPM, Node.js) → baza danych. Błąd 504 pojawia się, gdy którakolwiek z warstw po lewej stronie nie dostaje odpowiedzi od warstwy po prawej w ustalonym czasie — najczęściej w przedziale 30–120 sekund. W konfiguracji Nginx domyślna wartość proxy_read_timeout wynosi 60 sekund; jeśli aplikacja PHP potrzebuje dłużej na wygenerowanie odpowiedzi, Nginx zwróci 504 zanim PHP zdąży skończyć pracę.
Najczęstsze przyczyny błędu 504
Przeciążenie serwera aplikacji to najczęstszy winowajca — szczególnie przy nagłym skoku ruchu (wyprzedaże, kampanie reklamowe). Równie częste jest długo trwające zapytanie SQL: jeśli baza danych nie zoptymalizowała indeksów, a tabela liczy miliony rekordów, zapytanie może trwać minuty. Inne typowe przyczyny to:
- błędna konfiguracja timeoutów w Nginx, Apache lub HAProxy,
- awaria lub spowolnienie zewnętrznego API (np. bramka płatności, system CRM),
- zbyt małe zasoby serwera (RAM, CPU) względem liczby jednoczesnych połączeń,
- sieciowe problemy między serwerami w klastrze (np. w środowiskach cloud),
- błąd w konfiguracji DNS lub routingu wewnętrznego.
Jak diagnozować 504 krok po kroku
Diagnoza zaczyna się od logów serwera — zarówno access log, jak i error log (Nginx: /var/log/nginx/error.log, Apache: /var/log/apache2/error.log). Szukaj wpisów zawierających „upstream timed out” lub „gateway timeout”. Następnie sprawdź logi aplikacji i bazy danych — czy w momencie błędu nie pojawiają się wolne zapytania (slow query log w MySQL/MariaDB). Narzędzia takie jak top, htop lub iostat pokażą, czy serwer był w tym czasie przeciążony. Jeśli błąd pojawia się tylko przy konkretnych podstronach, problem najprawdopodobniej leży w logice aplikacji lub konkretnym zapytaniu do bazy.
| Warstwa | Typowy timeout | Parametr konfiguracyjny |
|---|---|---|
| Nginx (proxy) | 60 s | proxy_read_timeout |
| PHP-FPM | 30 s | request_terminate_timeout |
| MySQL | 28 800 s | wait_timeout |
| AWS ELB | 60 s | Idle Timeout (konsola AWS) |
| Cloudflare | 100 s | nie konfigurowalne w planie Free |
Jak naprawić błąd 504
Rozwiązanie zależy od przyczyny — nie ma jednej łatki pasującej do każdego przypadku. Jeśli problemem jest przeciążenie, należy zwiększyć zasoby serwera lub wdrożyć mechanizm kolejkowania żądań. Gdy winowajcą jest wolne zapytanie SQL, priorytetem jest optymalizacja zapytania i dodanie odpowiednich indeksów. Przy problemach z konfiguracją timeoutów — wydłużenie wartości proxy_read_timeout w Nginx może być doraźnym rozwiązaniem, ale nie eliminuje faktycznego problemu z wydajnością. W środowiskach opartych na zewnętrznych API warto wdrożyć mechanizm circuit breaker, który przerywa połączenie po stronie aplikacji zamiast czekać na timeout.
Znaczenie błędu 504 dla SEO i widoczności
Błąd 504 bezpośrednio zagraża pozycjom w wynikach wyszukiwania, ponieważ Googlebot traktuje go jako sygnał niedostępności strony. Jeśli robot crawluje stronę i natrafi na 504, odnotowuje błąd i może cofnąć się z indeksowania tej podstrony. Pojedynczy incydent rzadko wyrządza trwałe szkody — problem zaczyna się, gdy błąd pojawia się regularnie lub utrzymuje przez wiele godzin.
Google Search Console raportuje błędy serwera w raporcie „Pokrycie indeksu” — jeśli w tym raporcie widzisz nagłe skoki w kategorii „Błędy serwera (5xx)”, należy działać natychmiast. Długotrwałe problemy z dostępnością strony obniżają crawl budget, co u dużych serwisów (sklepy z tysiącami produktów, portale z dużą liczbą artykułów) może oznaczać, że Googlebot przestaje odwiedzać mniej popularne podstrony. Przy pozycjonowaniu sklepów internetowych błędy 504 na stronach kategorii lub produktów to jeden z poważniejszych problemów technicznych, jakie diagnozujemy w ramach audytu SEO.
Z perspektywy Core Web Vitals — 504 uniemożliwia w ogóle zmierzenie metryk, bo strona się nie ładuje. Jeśli błąd trafia do puli danych CrUX (Chrome User Experience Report), może negatywnie wpłynąć na ocenę Page Experience.
FAQ
Czym różni się błąd 504 od błędu 503?
Błąd 503 Service Unavailable oznacza, że serwer jest chwilowo niedostępny — np. z powodu planowanej konserwacji lub przeciążenia — i zazwyczaj zawiera nagłówek Retry-After z informacją, kiedy wróci do działania. Błąd 504 Gateway Timeout natomiast sygnalizuje, że serwer pośredniczący nie dostał odpowiedzi od serwera docelowego w wymaganym czasie — problem leży w komunikacji między warstwami infrastruktury, nie w samej niedostępności usługi. Praktyczna różnica: 503 mówi „niedostępny”, 504 mówi „za wolno”.
Jak długo Google „czeka” zanim uzna stronę za niedostępną?
Googlebot ma własne limity czasu połączenia — według dokumentacji Google, robot może odczekać do kilku sekund na odpowiedź serwera. Jeśli strona regularnie zwraca 504, Google może tymczasowo obniżyć częstotliwość crawlowania (crawl rate) dla danej domeny. W praktyce krótki incydent (kilkadziesiąt minut) zazwyczaj nie powoduje trwałych konsekwencji, natomiast przerwa trwająca kilka dni może skutkować wypadnięciem podstron z indeksu.
Czy błąd 504 może pojawić się tylko na niektórych podstronach?
Tak — i taka sytuacja jest wskazówką diagnostyczną. Jeśli 504 pojawia się wyłącznie przy konkretnych podstronach (np. filtrach w sklepie, stronach wyników wyszukiwania wewnętrznego lub raportach), problem najprawdopodobniej leży w logice aplikacji lub zapytaniu do bazy danych, a nie w ogólnej infrastrukturze. W takim przypadku należy przeanalizować slow query log bazy danych pod kątem zapytań generowanych przez te konkretne URL-e.
Co zrobić, gdy 504 pojawia się tylko pod dużym obciążeniem?
Błąd 504 występujący wyłącznie przy skokach ruchu (np. podczas kampanii w Google Ads) wskazuje na niewystarczającą pojemność serwera aplikacji — zbyt mało workerów PHP-FPM, za mały pool połączeń do bazy lub brak mechanizmu cachowania. Rozwiązania to wdrożenie cache’owania (np. Redis, Varnish), skalowanie horyzontalne (więcej instancji aplikacji) lub optymalizacja zapytań tak, aby serwer obsługiwał więcej żądań jednocześnie bez przekraczania timeoutów.
Błąd 504 to sygnał, nie wyrok — działaj zanim zrobi to Google
504 Gateway Timeout rzadko pojawia się „bez powodu” — zawsze stoi za nim konkretny problem techniczny, który można zlokalizować i wyeliminować. Zignorowany, szczególnie w przypadku sklepów internetowych lub dużych serwisów, potrafi trwale obniżyć widoczność w wynikach wyszukiwania i uszczuplić crawl budget. Jeśli w Google Search Console widzisz wzrost błędów 5xx lub Twoja strona sporadycznie przestaje odpowiadać — to dobry moment na audyt SEO z analizą techniczną. W Webiti diagnozujemy tego typu problemy jako część kompleksowego pozycjonowania stron, zanim zdążą odbić się na pozycjach.
