504 zwykle oznacza, że warstwa pośrednia czekała na odpowiedź upstreamu dłużej, niż pozwala jej konfiguracja. Użytkownik widzi „Gateway Timeout”, ale prawdziwy problem może być głębiej: ciężkie zapytanie SQL, import, komunikacja z zewnętrznym API, generowanie raportu, zapętlony kod albo brak wolnych zasobów PHP.
Szybka odpowiedź
Zwiększenie proxy_read_timeout czy limitu wykonania może ukryć objaw, ale nie poprawia automatycznie wydajności. Najpierw trzeba zmierzyć, co faktycznie trwa długo. Jeżeli zwykła podstrona odpowiada w 300 ms, a konkretny eksport po 60 sekundach kończy się 504, masz zupełnie inny problem niż serwis, który przy każdym żądaniu czeka kilkanaście sekund na bazę.
Znajdź konkretny endpoint
Zapisz URL, metodę i moment błędu. Jeśli 504 dotyczy wyłącznie /wp-admin/admin-ajax.php, REST API albo konkretnego importu, analizuj tę operację. Jeśli timeout dostaje nawet strona główna bez cache, sprawdź podstawowe zapytania i stan serwera. Uogólnienie „WordPress jest wolny” utrudnia pracę; konkretne żądanie daje punkt zaczepienia.
Baza danych potrafi trzymać proces PHP
Wolne zapytanie, brak indeksu, ogromna tabela opcji lub blokada w bazie może sprawić, że PHP tylko czeka. Sprawdź slow query log, czas zapytań i rozmiary tabel. Nie zaczynaj od automatycznego „czyszczenia bazy” wtyczką, bo problem może wymagać indeksu, zmiany kodu lub ograniczenia zapytań.
Zewnętrzne API i brak rozsądnych timeoutów
Wtyczki integracyjne łączą się z płatnościami, kurierami, CRM-em, ERP, systemami marketingowymi i usługami licencyjnymi. Jeśli zewnętrzny serwis nie odpowiada, źle napisany kod może trzymać całe żądanie. Zobacz logi HTTP i czasy połączeń. Długie operacje często powinny przejść do kolejki w tle zamiast blokować odpowiedź użytkownika.
Importy i generowanie dużych danych
Import tysięcy produktów albo eksport dużego raportu nie powinien zależeć od jednego długiego żądania HTTP. Lepszy model dzieli pracę na mniejsze porcje, zapisuje postęp i pozwala wznowić zadanie. Dzięki temu chwilowe opóźnienie nie kończy całej operacji 504.
Timeout jest zabezpieczeniem, nie wrogiem
Limity zapobiegają zajmowaniu procesów w nieskończoność. Czasem trzeba je zwiększyć dla świadomie długiej operacji administracyjnej, ale decyzja powinna wynikać z pomiaru. Jeśli front potrzebuje 90 sekund do wygenerowania strony, właściwym celem jest optymalizacja, nie 180-sekundowy timeout.
Jak potwierdzić, że naprawa naprawdę działa?
Po poprawce zmierz czas tego samego endpointu kilka razy i zapisz medianę oraz najgorszy wynik. Jeżeli import wcześniej kończył się po 60 sekundach, a teraz potrzebuje 55 sekund, problem formalnie zniknął, ale margines nadal jest zbyt mały. Dobra naprawa skraca pracę lub przenosi ją do bezpiecznego procesu w tle, zamiast tylko zbliżać się do nowego limitu timeoutu.
Co obserwować po zmianie?
Sprawdź także liczbę równoległych procesów podczas długiej operacji. Jedno 50-sekundowe żądanie może być akceptowalne administracyjnie, ale dziesięć takich żądań potrafi zająć całą pulę PHP. W logach bazy i HTTP szukaj najwolniejszego etapu. Jeżeli czas znika po wyłączeniu zewnętrznego API, dodaj kontrolowane timeouty, retry i obsługę błędu zamiast blokować użytkownika.
Kiedy przekazać temat dalej?
Eskaluj, gdy nie masz slow query logu, profilera lub dostępu do konfiguracji proxy, a 504 dotyczy operacji biznesowych. Bez pomiaru można przypadkiem zwiększyć timeout i pogorszyć dostępność całego serwera. W takich przypadkach potrzebny jest pełny profil żądania od proxy aż do bazy lub API zewnętrznego.
Praktyczny scenariusz diagnostyczny
Przykład: eksport zamówień w panelu WooCommerce po 60 sekundach kończy się 504, podczas gdy zwykłe podstrony są szybkie. Zamiast zwiększać timeout całej witryny, ustal, co robi eksport: jakie zapytania wykonuje, ile rekordów pobiera i czy blokuje proces PHP. Sprawdź czas odpowiedzi upstreamu i log aplikacji. Jeśli operację można porcjować, uruchomić w kolejce lub ograniczyć zakresem dat, to zwykle bezpieczniejsza droga niż ustawienie kilkuminutowych timeoutów dla każdego requestu. Po zmianie przetestuj mały i duży eksport oraz zwykły ruch. Celem jest skrócenie lub asynchroniczne wykonanie ciężkiej operacji, a nie nauczenie proxy cierpliwości do źle zaprojektowanego żądania.
Bezpieczna kolejność działań
- Zidentyfikuj endpoint i czas trwania żądania.
- Sprawdź log Nginx/proxy, PHP i slow query log bazy.
- Zmierz połączenia z zewnętrznymi API.
- Rozdziel ciężkie procesy na zadania w tle, jeśli to możliwe.
- Dopiero potem dostosuj timeout do realnej charakterystyki operacji.
- Po wdrożeniu mierz TTFB i liczbę 504 w monitoringu.
Czego nie robić
Nie zwiększaj timeoutu do kilku minut jako pierwszego ruchu. To może zająć wszystkie workery PHP i zmienić pojedynczy timeout w pełną niedostępność serwisu. Nie zakładaj też, że „więcej RAM-u” naprawi wolne zapytanie SQL.
Powiązane poradniki HeatLogic
Potrzebujesz pomocy?
Jeśli 504 pojawia się przy imporcie, panelu albo losowych podstronach, HeatLogic może zmierzyć czas na każdej warstwie, znaleźć najwolniejszy fragment i dobrać rozwiązanie bez sztucznego pompowania timeoutów.
Najczęściej zadawane pytania
Czy 504 oznacza wolny internet użytkownika?
Zwykle nie. To timeout między serwerami lub usługami po stronie infrastruktury aplikacji.
Czy zwiększenie timeoutu jest błędem?
Nie zawsze. Dla świadomie długiej operacji może być uzasadnione, ale powinno nastąpić po pomiarze i optymalizacji.
Czy WooCommerce może powodować 504?
Tak, szczególnie przy ciężkich raportach, importach, integracjach i zadaniach, które czekają na zewnętrzne API.
Jak odróżnić 504 od 502?
504 zwykle oznacza przekroczenie czasu oczekiwania, a 502 nieprawidłową odpowiedź upstreamu.