Błąd 504 Gateway Timeout. Jak znaleźć proces, który trwa za długo?

Błąd 504 Gateway Timeout pojawia się wtedy, gdy strona liczy coś tak długo, że serwer pośredniczący przestaje czekać na wynik. Odwiedzający widzi suchy komunikat, a właściciel witryny nie dostaje żadnej wskazówki, co właściwie trwało za długo. Najczęściej nie jest to awaria całego serwera, tylko jedno konkretne zadanie: import produktów, ciężkie zapytanie do bazy danych, zadanie w tle albo połączenie z zewnętrzną usługą, która nie odpowiada.

Ta instrukcja jest przeznaczona dla osób prowadzących stronę firmową lub sklep, przede wszystkim na WordPressie, choć opisane zasady dotyczą każdej witryny działającej na PHP. Część czynności da się wykonać samodzielnie w panelu WordPressa i w panelu hostingu, a część wymaga dostępu do konfiguracji serwera, który ma administrator albo dział pomocy hostingu.

Po lekturze czytelnik będzie umiał ustalić, które ogniwo wysyła błąd, znaleźć w dziennikach żądanie przekraczające limit czasu, wskazać wtyczkę, zapytanie albo zadanie odpowiedzialne za opóźnienie i naprawić przyczynę. Będzie też wiedział, co napisać do hostingu, żeby dostać konkretną odpowiedź, a nie ogólną formułkę.

Co dokładnie oznacza kod 504 i kto go wysyła?

Zgodnie ze specyfikacją protokołu HTTP kod 504 oznacza, że serwer działający jako brama lub pośrednik nie otrzymał na czas odpowiedzi od serwera, do którego przekazał żądanie. Ważne jest słowo „pośrednik”. Błędu nie wysyła program, który się zawiesił, tylko ogniwo stojące przed nim, które straciło cierpliwość.

Żądanie odwiedzającego przechodzi zwykle przez kilka warstw. Najpierw trafia do sieci CDN, jeżeli witryna z niej korzysta. Potem do serwera WWW, najczęściej nginx albo Apache. Serwer WWW przekazuje je do PHP, zwykle przez usługę PHP-FPM. PHP wykonuje kod WordPressa, a ten sięga do bazy danych i czasem do zewnętrznych usług, na przykład bramki płatności albo systemu magazynowego.

Każda warstwa czeka na następną tylko przez określony czas. Gdy PHP pracuje dłużej, niż serwer WWW jest gotów czekać, serwer WWW zamyka połączenie i odsyła 504. Gdy sam serwer WWW odpowiada zbyt wolno, błąd zgłasza sieć CDN. Dlatego pierwsze pytanie brzmi: kto wysłał komunikat, a dopiero drugie: co trwało za długo.

Czym 504 różni się od 500, 502 i 503?

Kod 500 oznacza błąd w kodzie lub konfiguracji, a więc program zakończył pracę, tylko nieprawidłowo. Przy 502 pośrednik dostał odpowiedź, ale nieprawidłową, na przykład dlatego, że proces PHP został przerwany w połowie. Tę sytuację opisałem osobno w tekście o tym, co przy błędzie 502 leży po stronie hostingu, a co witryny. Kod 503 informuje, że usługa jest chwilowo niedostępna, na przykład z powodu przeciążenia lub trybu konserwacji.

Przy 504 odpowiedzi nie było wcale w wyznaczonym czasie. To istotna różnica, bo proces, który spowodował błąd, bardzo często działa dalej w tle, mimo że odwiedzający zobaczył już komunikat. Import może się więc wykonać do końca, a zamówienie może zostać zapisane, choć ekran pokazał błąd.

Po czym rozpoznać, że błąd zgłasza sieć CDN, a nie serwer?

Strona błędu zwykle zdradza nadawcę. Komunikat podpisany nazwą nginx lub Apache pochodzi z serwera hostingu. Strona z logo i nazwą sieci CDN oznacza, że błąd zgłosiła ta sieć. Cloudflare stosuje dodatkowo własny kod 524, który oznacza, że połączenie z serwerem witryny zostało nawiązane, ale serwer nie odesłał odpowiedzi w wyznaczonym czasie. Według dokumentacji Cloudflare domyślny czas oczekiwania wynosi 125 sekund.

W razie wątpliwości najprościej na chwilę wstrzymać pośrednictwo sieci CDN dla domeny w jej panelu i powtórzyć próbę. Jeśli błąd nadal występuje, przyczyna leży na serwerze witryny. Jeśli znika, a strona ładuje się bardzo długo, przyczyna jest ta sama, tylko serwer ma dłuższy limit niż sieć.

Jakie limity czasu działają po drodze i dlaczego mają znaczenie?

Żeby znaleźć zbyt długi proces, trzeba wiedzieć, ile czasu ma do dyspozycji. Limity ustawia się w kilku miejscach i każde z nich działa niezależnie. O wyniku decyduje najkrótszy z nich.

• Serwer nginx współpracujący z PHP-FPM stosuje dyrektywę fastcgi_read_timeout. Jej wartość domyślna to 60 sekund.
• Serwer nginx działający jako pośrednik przed innym serwerem stosuje dyrektywę proxy_read_timeout, także z wartością domyślną 60 sekund.
• Serwer Apache ma dyrektywę Timeout, a przy pracy w roli pośrednika także ProxyTimeout.
• PHP ma ustawienie max_execution_time, domyślnie 30 sekund.
• Usługa PHP-FPM ma ustawienie request_terminate_timeout, domyślnie wyłączone.

Na hostingu współdzielonym wartości te ustala dostawca i często różnią się od domyślnych. Aktualne liczby należy odczytać z panelu hostingu albo zapytać o nie pomoc techniczną. Zgadywanie prowadzi do błędnych wniosków.

W dokumentacji nginx jest istotne zastrzeżenie: limit odczytu liczy się między dwiema kolejnymi operacjami odczytu, a nie dla całej odpowiedzi. W praktyce oznacza to, że skrypt, który przez minutę nie wysyła ani jednego bajtu, zostanie odcięty, nawet jeśli pracuje poprawnie. WordPress zwykle wysyła stronę dopiero po zakończeniu obliczeń, więc każde długie zadanie wykonywane w trakcie żądania jest narażone na ten limit.

Dlaczego limit PHP nie zawsze zatrzymuje skrypt na czas?

Wiele osób zakłada, że skoro PHP ma limit 30 sekund, to żaden skrypt nie będzie działał dłużej. Dokumentacja PHP wyjaśnia, że w systemach innych niż Windows do tego limitu nie wlicza się czasu wywołań systemowych ani operacji na strumieniach. Skrypt, który czeka na odpowiedź bazy danych albo zewnętrznego serwera, może więc trwać znacznie dłużej, niż wskazuje ustawienie.

Z tego wynika praktyczny wniosek. Gdy przyczyną jest ciężkie obliczenie w samym PHP, częściej pojawia się błąd o przekroczeniu maksymalnego czasu wykonania. Gdy przyczyną jest oczekiwanie na bazę danych lub cudzą usługę, PHP czeka cierpliwie, a połączenie zrywa serwer WWW i wtedy pojawia się 504. Sam kod błędu jest już więc pierwszą wskazówką, gdzie szukać.

Jak ustalić, przy której czynności pojawia się błąd?

Zanim zajrzy się do dzienników, trzeba zebrać trzy informacje: pod jakim adresem błąd występuje, po jakim czasie i w jakich okolicznościach. Bez nich przeszukiwanie dzienników przypomina szukanie po omacku.

1. Należy ustalić, czy błąd dotyczy każdej podstrony, czy tylko wybranych: panelu administracyjnego, koszyka, wyszukiwarki, jednej kategorii albo jednej czynności, na przykład zapisu wpisu lub importu pliku.
2. W przeglądarce otwiera się narzędzia dla deweloperów klawiszem F12 i przechodzi do karty „Sieć”.
3. Przy otwartej karcie trzeba powtórzyć czynność, która kończy się błędem, i odczekać do pojawienia się komunikatu.
4. Na liście żądań należy odszukać wiersz ze stanem 504 i zanotować trzy rzeczy: pełny adres żądania, czas trwania oraz dokładną godzinę próby.
5. Próbę warto powtórzyć z innego łącza, na przykład z telefonu z wyłączonym Wi-Fi. Jeżeli u innych osób strona działa, przyczyna może leżeć w sieci lokalnej, a nie w witrynie.

Czas trwania żądania jest cenną wskazówką. Jeżeli błąd pojawia się zawsze po tej samej liczbie sekund, na przykład po około 60, oznacza to, że zadziałał limit serwera, a proces po prostu trwa dłużej. Jeżeli błąd pojawia się po różnym czasie albo natychmiast, bardziej prawdopodobne jest przeciążenie lub awaria usługi.

Adres żądania też wiele mówi. W WordPressie często nie zawodzi sama podstrona, tylko żądanie wysyłane w tle. Adres zawierający admin-ajax.php wskazuje na czynność wtyczki lub motywu wykonywaną w tle. Adres z fragmentem wp-json oznacza interfejs REST, z którego korzysta między innymi edytor blokowy. Adres wp-cron.php to zadania zaplanowane.

Jak zmierzyć czas odpowiedzi bez przeglądarki?

Osoba z dostępem do wiersza poleceń może zmierzyć czas jednym poleceniem. Wynik pokazuje kod odpowiedzi i łączny czas w sekundach, a pomiar warto powtórzyć kilka razy o różnych porach.

curl -o /dev/null -s -w "%{http_code} %{time_total}\n" https://adres-witryny.pl/

Pomiar należy wykonać osobno dla strony głównej, dla podstrony, na której pojawia się błąd, i dla zwykłego pliku graficznego. Jeżeli plik graficzny ładuje się szybko, a podstrona generowana przez PHP nie, serwer WWW działa poprawnie, a opóźnienie powstaje w PHP lub w bazie danych.

Jak znaleźć zbyt długie żądanie w dziennikach serwera?

Dzienniki serwera są jedynym miejscem, w którym błąd 504 zostawia trwały ślad. Na większości hostingów są dostępne w panelu klienta, w sekcji nazwanej zwykle dziennikami, logami albo statystykami. Jeżeli panel ich nie udostępnia, należy poprosić o nie pomoc techniczną.

1. W panelu hostingu otwiera się dziennik błędów serwera WWW dla właściwej domeny.
2. Należy przejść do wpisów z godziny zanotowanej podczas próby w przeglądarce.
3. W dzienniku nginx trzeba szukać wpisu ze sformułowaniem upstream timed out. Taki wpis zawiera adres żądania oraz nazwę usługi, na którą serwer czekał.
4. W dzienniku Apache podobną rolę pełnią wpisy ze słowem timeout przy module pośredniczącym lub module obsługującym PHP.
5. Następnie otwiera się dziennik dostępu i odszukuje żądania zakończone kodem 504 z tej samej minuty. Należy zanotować adres, metodę (GET lub POST) oraz adres IP i podpis programu, który wysłał żądanie.
6. Na koniec warto policzyć, ile razy ten sam adres pojawia się z kodem 504 w ciągu doby i czy są to godziny regularne.

Regularność jest bardzo wymowna. Błąd wracający co godzinę albo co noc o tej samej porze wskazuje na zadanie zaplanowane: kopię zapasową, synchronizację stanów magazynowych, wysyłkę wiadomości. Błąd pojawiający się przy dużej liczbie żądań z jednego adresu IP wskazuje na automat, który odpytuje ciężkie podstrony.

O co poprosić administratora, żeby dziennik pokazywał czas?

Standardowy dziennik dostępu nie zawsze zawiera czas obsługi żądania. Serwer nginx udostępnia zmienne $request_time oraz $upstream_response_time, które można dodać do formatu dziennika. W Apache tę samą funkcję pełni znacznik %D w dyrektywie opisującej format wpisu. Po takiej zmianie dziennik pokazuje nie tylko żądania zakończone błędem, ale także te, które zbliżają się do limitu.

To zmiana po stronie serwera, więc na hostingu współdzielonym wykonuje ją dostawca. Warto o nią poprosić, bo lista najwolniejszych adresów pozwala znaleźć kłopot, zanim zacznie on dotykać odwiedzających.

Kto woli nie zajmować się tym samodzielnie, może zadzwonić pod numer 533 525 168 albo napisać na info@lukaszwudyka.pl. Przejmę wtedy sprawę: przeanalizuję dzienniki serwera, wskażę proces przekraczający limit czasu i doprowadzę do jego naprawy we współpracy z hostingiem.

Jak wskazać w PHP funkcję albo wtyczkę, która trwa za długo?

Dziennik serwera WWW mówi, które żądanie trwało za długo. Nie mówi, co PHP robiło w tym czasie. Do tego służy dziennik wolnych żądań usługi PHP-FPM, czyli najdokładniejsze narzędzie w całej diagnozie.

W konfiguracji puli PHP-FPM są dwa powiązane ustawienia. request_slowlog_timeout określa, po ilu sekundach obsługi jednego żądania usługa zapisuje ślad wywołań PHP. slowlog wskazuje plik, do którego ten ślad trafia. Domyślnie mechanizm jest wyłączony, ponieważ wartość pierwszego ustawienia wynosi 0.

1. Należy ustalić, czy witryna działa na PHP-FPM. Informację tę podaje panel hostingu albo ekran „Narzędzia” → „Stan witryny” → karta „Informacje”, sekcja „Serwer”.
2. Na serwerze własnym lub VPS w pliku konfiguracji puli wpisuje się próg krótszy od limitu serwera WWW, na przykład request_slowlog_timeout = 10s, oraz ścieżkę pliku w ustawieniu slowlog.
3. Po zapisaniu zmian trzeba przeładować usługę PHP-FPM.
4. Na hostingu współdzielonym tej zmiany nie da się zwykle wykonać samodzielnie. Należy wtedy poprosić pomoc techniczną o włączenie dziennika wolnych żądań dla konta albo o przesłanie jego fragmentu z godziny wystąpienia błędu.
5. Po kolejnym wystąpieniu błędu otwiera się plik dziennika i czyta wpis od góry: pierwsze wiersze pokazują funkcję, w której skrypt utknął, a kolejne pokazują, skąd została wywołana.

W śladzie wywołań najważniejsze są ścieżki plików. Katalog wp-content/plugins/nazwa-wtyczki wskazuje konkretną wtyczkę, a wp-content/themes motyw. Jeżeli na szczycie śladu stoi funkcja wykonująca zapytanie do bazy, kłopot leży w bazie danych. Jeżeli stoi tam funkcja związana z połączeniem sieciowym, na przykład curl_exec, skrypt czekał na zewnętrzny serwer.

Co zrobić, gdy nie ma dostępu do dziennika wolnych żądań?

W panelu WordPressa można posłużyć się wtyczką Query Monitor z oficjalnego katalogu. Pokazuje ona na pasku administratora informacje o bieżącym żądaniu, w tym zapytania do bazy z podziałem na wtyczki, motyw i funkcje oraz połączenia z zewnętrznymi usługami wraz z czasem ich trwania. Wolne zapytania są w niej wyróżnione.

Wtyczka ma jedno ograniczenie: pokazuje dane tylko dla żądań, które zdążyły się zakończyć. Przy żądaniu przerwanym kodem 504 wyniku nie będzie. Dlatego należy ją stosować na podstronach, które ładują się wolno, ale jeszcze się ładują, oraz na mniejszej próbce danych, na przykład przy imporcie krótszego pliku. Po zakończeniu diagnozy wtyczkę trzeba wyłączyć.

Pomocny jest też dziennik błędów WordPressa. Włącza się go w pliku wp-config.php, wpisując poniższe wiersze przed wierszem z komentarzem „That’s all, stop editing!”. Wpisy trafiają wtedy do pliku wp-content/debug.log i nie są widoczne dla odwiedzających.

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

W tym pliku pojawiają się między innymi komunikaty o przekroczeniu maksymalnego czasu wykonania wraz ze ścieżką pliku, w którym skrypt został zatrzymany. Dokumentacja WordPressa nie zaleca trzymania trybu diagnostycznego na działającej witrynie, dlatego po zebraniu informacji należy przywrócić wartość false, a plik dziennika skasować z serwera.

Kiedy pomaga wyłączanie wtyczek po kolei?

Gdy żaden dziennik nie jest dostępny, pozostaje metoda eliminacji. Na ekranie „Wtyczki” wyłącza się połowę wtyczek i powtarza czynność kończącą się błędem. Jeżeli błąd zniknął, winna jest jedna z wyłączonych, jeżeli nie, jedna z pozostałych. Kolejne podziały na pół prowadzą do jednej wtyczki w kilku próbach.

Na działającym sklepie ta metoda jest ryzykowna, bo wyłączenie wtyczki płatności lub dostaw zatrzymuje sprzedaż. Bezpieczniej wykonać ją na kopii witryny, czyli w środowisku testowym, które wiele hostingów pozwala utworzyć jednym kliknięciem. Szersze omówienie tej metody znajduje się w tekście o tym, co spowalnia WordPressa.

Jak sprawdzić, czy winne jest zapytanie do bazy danych?

Baza danych jest jedną z najczęstszych przyczyn błędu 504 w witrynach, które przez lata urosły. Zapytanie działające sprawnie przy tysiącu zamówień może trwać kilkadziesiąt sekund przy stu tysiącach, jeśli tabela nie ma odpowiedniego indeksu.

Serwer MySQL ma do tego osobne narzędzie: dziennik wolnych zapytań. Według dokumentacji jest on domyślnie wyłączony. Włącza go zmienna slow_query_log, a próg czasu ustawia zmienna long_query_time, której wartość domyślna to 10 sekund. Do dziennika trafia pełna treść każdego zapytania trwającego dłużej niż próg.

Na serwerze własnym dziennik włącza administrator, a do diagnozy warto obniżyć próg do kilku sekund. Na hostingu współdzielonym należy poprosić pomoc techniczną o listę najwolniejszych zapytań dla konkretnej bazy z ostatnich dni. Większość dostawców ma takie dane i udostępnia je na prośbę.

W treści wolnego zapytania najważniejsza jest nazwa tabeli. Tabele z przedrostkiem konkretnej wtyczki wskazują ją wprost. Tabela wp_postmeta oznacza zwykle wyszukiwanie lub filtrowanie po polach dodatkowych, typowe dla sklepów i rozbudowanych katalogów. Tabela wp_options wskazuje na nadmiar ustawień ładowanych przy każdym żądaniu, często pozostawionych przez dawno usunięte wtyczki.

Jak rozpoznać blokadę tabel?

Osobnym przypadkiem jest sytuacja, w której zapytania same w sobie są szybkie, ale czekają w kolejce, bo inne zadanie zablokowało tabelę. Dzieje się tak na przykład podczas kopii zapasowej bazy, dużego importu albo naprawy tabel. Objawem jest błąd 504 na wszystkich podstronach jednocześnie, trwający kilka minut i ustępujący samoistnie.

Administrator może to potwierdzić w trakcie zdarzenia poleceniem SHOW FULL PROCESSLIST, które wyświetla listę działających zapytań wraz z czasem trwania i stanem. Jeżeli wiele zapytań czeka na zwolnienie blokady, a jedno trwa od dawna, to właśnie ono jest szukanym procesem.

Co sprawdzić w zadaniach w tle i połączeniach z zewnętrznymi usługami?

WordPress nie ma własnego stałego harmonogramu. Mechanizm WP-Cron uruchamia zaplanowane zadania przy okazji wizyt na stronie. Jeżeli jedno z tych zadań jest ciężkie, obciąża serwer w chwili, gdy ktoś właśnie otwiera podstronę, i zajmuje proces PHP na długi czas.

Listę zaplanowanych zadań pokazuje wtyczka WP Crontrol z oficjalnego katalogu, a osoba z dostępem do wiersza poleceń zobaczy ją po wpisaniu wp cron event list. Należy szukać zadań, których termin wykonania dawno minął, a mimo to pozostają na liście. To znak, że zadanie zaczyna się, przekracza limit czasu, zostaje przerwane i przy następnej wizycie zaczyna się od nowa.

Sklepy na WooCommerce oraz wiele wtyczek korzystają dodatkowo z biblioteki Action Scheduler. Jej kolejkę widać w panelu WooCommerce na ekranie stanu systemu, w karcie z zaplanowanymi działaniami. Tysiące pozycji oczekujących albo zakończonych niepowodzeniem oznaczają, że kolejka nie nadąża i stale obciąża serwer.

Jak rozpoznać, że witryna czeka na cudzy serwer?

Wiele wtyczek łączy się w trakcie ładowania strony z zewnętrznymi usługami: sprawdza licencję, pobiera kursy walut, stany magazynowe, opinie albo czcionki. Gdy taka usługa przestaje odpowiadać, witryna czeka na nią przy każdym żądaniu. Objawem jest nagłe spowolnienie całej witryny bez żadnych zmian po stronie właściciela.

W dzienniku wolnych żądań PHP taki przypadek widać po funkcjach sieciowych na szczycie śladu. W Query Monitor odpowiada mu panel połączeń HTTP, w którym przy każdym połączeniu podany jest adres, czas trwania i wtyczka, która je wywołała. Rozwiązaniem doraźnym jest wyłączenie tej jednej funkcji lub wtyczki do czasu, aż zewnętrzna usługa wróci do pracy.

Czy przyczyną może być ruch automatów?

Tak, i jest to przyczyna często pomijana. Roboty odpytujące wyszukiwarkę wewnętrzną, filtry produktów w sklepie albo plik xmlrpc.php wywołują wiele ciężkich żądań jednocześnie. Usługa PHP-FPM ma ograniczoną liczbę procesów, którą określa ustawienie pm.max_children. Gdy wszystkie są zajęte, kolejne żądania czekają w kolejce i przekraczają limit, choć same byłyby szybkie.

W dzienniku dostępu widać to jako serię żądań z jednego adresu IP lub z jednym podpisem programu do adresów z parametrami wyszukiwania i filtrowania. Podobne objawy opisałem w tekście o tym, dlaczego przy błędzie 503 usługa bywa niedostępna, ponieważ oba kody mają wtedy wspólne źródło.

Jak naprawić przyczynę, zamiast tylko wydłużać limit?

Po ustaleniu, który proces trwa za długo, wybór naprawy jest zwykle prosty. Ogólna zasada brzmi: długie zadanie należy skrócić, podzielić albo przenieść poza żądanie odwiedzającego. Wydłużenie limitu jest rozwiązaniem tylko w nielicznych, uzasadnionych przypadkach.

Import, eksport i operacje masowe

Duże pliki należy dzielić na mniejsze części. Większość wtyczek importujących ma ustawienie liczby rekordów przetwarzanych w jednym kroku i jego zmniejszenie zwykle usuwa błąd. Osoba z dostępem do wiersza poleceń może wykonać zadanie przez WP-CLI. Skrypt uruchomiony z wiersza poleceń nie przechodzi przez serwer WWW, a PHP w tym trybie domyślnie nie ma limitu czasu wykonania.

Wolne zapytania do bazy danych

Treść zapytania z dziennika należy przekazać autorowi wtyczki albo programiście. Rozwiązaniem bywa aktualizacja wtyczki, dodanie indeksu do tabeli, ograniczenie zakresu danych albo zmiana ustawienia, które wywołuje zapytanie, na przykład wyłączenie licznika produktów w filtrach. Samodzielne dodawanie indeksów i usuwanie wierszy z bazy bez kopii jest ryzykowne, bo błąd może uszkodzić dane. Przed każdą zmianą w bazie trzeba mieć sprawdzoną kopię zapasową WordPressa.

Zadania zaplanowane

Dokumentacja WordPressa opisuje przeniesienie harmonogramu do systemu serwera. Polega to na dwóch czynnościach. W pliku wp-config.php wpisuje się wiersz wyłączający uruchamianie zadań przy wizytach:

define( 'DISABLE_WP_CRON', true );

Następnie w panelu hostingu, w sekcji zadań cron, ustawia się cykliczne wywołanie pliku wp-cron.php, na przykład co 15 minut:

*/15 * * * * wget --delete-after https://adres-witryny.pl/wp-cron.php

Obie czynności muszą być wykonane razem. Samo wyłączenie mechanizmu bez ustawienia wywołania w systemie zatrzyma wszystkie zadania, w tym publikację zaplanowanych wpisów i wysyłkę wiadomości ze sklepu.

Zewnętrzne usługi i ruch automatów

Połączenia z cudzymi serwerami powinny odbywać się w tle, a ich wyniki powinny być przechowywane w pamięci podręcznej. Jeżeli wtyczka łączy się z zewnętrzną usługą przy każdym wyświetleniu strony, należy zgłosić to jej autorowi albo wymienić ją na inną. Ruch automatów ogranicza się regułami w zaporze sieci CDN lub hostingu oraz włączeniem pamięci podręcznej stron, dzięki której powtarzalne żądania w ogóle nie docierają do PHP.

Kiedy wydłużenie limitu jest uzasadnione?

Bywają zadania, których nie da się sensownie podzielić, na przykład generowanie dużego raportu w panelu raz w miesiącu. Wtedy limit można podnieść, ale spójnie na wszystkich warstwach: w PHP, w PHP-FPM, w serwerze WWW i w sieci CDN. Podniesienie tylko jednego z nich nic nie zmienia, bo zadziała najkrótszy z pozostałych.

Najbezpieczniej poprosić hosting o wyższy limit tylko dla panelu administracyjnego albo dla jednego adresu. Wysoki limit dla całej witryny sprawia, że każdy zawieszony proces dłużej zajmuje miejsce i przy większym ruchu serwer szybciej przestaje odpowiadać.

Po czym poznać, że naprawa zadziałała, i co zrobić, gdy nie zadziałała?

Brak błędu przy jednej próbie niczego nie dowodzi. Naprawę należy potwierdzić w tych samych miejscach, w których szukało się przyczyny.

1. Należy powtórzyć czynność, która kończyła się błędem, i zmierzyć jej czas w karcie „Sieć” przeglądarki. Czas powinien być wyraźnie krótszy od limitu serwera, a nie tylko mieścić się w nim o kilka sekund.
2. Po dobie trzeba przejrzeć dziennik dostępu i policzyć żądania z kodem 504. Powinno ich nie być.
3. W dzienniku wolnych żądań PHP nie powinny przybywać nowe wpisy dla naprawionego adresu.
4. Na liście zadań zaplanowanych nie powinno być pozycji z dawno minionym terminem.
5. Po zakończeniu kontroli wyłącza się tryb diagnostyczny WordPressa i wtyczki użyte do diagnozy.

Jeżeli błąd wraca, zwykle przyczyn jest więcej niż jedna i usunięta została tylko najbardziej widoczna. Należy wtedy wrócić do dzienników i sprawdzić, czy 504 dotyczy tego samego adresu, czy już innego. Nowy adres oznacza kolejny proces do zbadania tą samą metodą.

Jeżeli dzienniki PHP i bazy danych są puste, a błąd nadal występuje, przyczyna leży najpewniej w infrastrukturze hostingu: w przeciążonym serwerze, awarii dysku albo usterce sieci. Wtedy potrzebne jest zgłoszenie do pomocy technicznej. Im konkretniejsze, tym szybsza odpowiedź. Sprawdza się taka treść:

„Od [dzień, godzina] witryna [adres] zwraca błąd 504 Gateway Timeout przy żądaniach do [pełny adres]. Błąd pojawia się po około [liczba] sekundach. Proszę o sprawdzenie dziennika błędów serwera WWW i dziennika wolnych żądań PHP z godziny [godzina] oraz o informację, jakie limity czasu obowiązują na moim koncie dla serwera WWW i PHP. Proszę też o listę najwolniejszych zapytań do bazy [nazwa bazy] z ostatnich trzech dni.”

Jakich błędów unikać przy diagnozie?

Najczęstszy błąd to wielokrotne odświeżanie strony po pojawieniu się komunikatu. Poprzedni proces zwykle nadal działa, więc każde odświeżenie uruchamia kolejny i pogłębia przeciążenie. Przy formularzach i zamówieniach grozi to dodatkowo zdublowaniem danych. Po błędzie 504 należy odczekać kilka minut i sprawdzić, czy czynność nie została jednak wykonana.

Drugi błąd to podnoszenie limitów jako pierwsza reakcja. Witryna przestaje wtedy pokazywać komunikat, ale odwiedzający czeka na stronę dwie minuty zamiast jednej, co dla sprzedaży i widoczności w wyszukiwarce nie jest żadną poprawą. Limit jest sygnałem ostrzegawczym, a nie przyczyną.

Trzeci błąd to diagnoza bez zapisanej godziny i adresu. Dzienniki ruchliwej witryny mają tysiące wierszy na godzinę i bez tych dwóch informacji nie da się w nich niczego znaleźć. Pomoc techniczna hostingu także nie będzie w stanie odpowiedzieć konkretnie.

Czwarty błąd to pozostawienie włączonych narzędzi diagnostycznych. Stała SAVEQUERIES, tryb diagnostyczny i wtyczki pomiarowe same obciążają serwer, co dokumentacja WordPressa zaznacza wprost. Plik debug.log pozostawiony w publicznym katalogu może ponadto ujawnić ścieżki i szczegóły konfiguracji.

Piąty błąd to zmiany w bazie danych i w pliku wp-config.php bez kopii. Jedna literówka w tym pliku wyłącza całą witrynę, dlatego przed edycją należy pobrać jego kopię na dysk.

Najczęstsze pytania

Czy błąd 504 szkodzi pozycji strony w Google?

Pojedyncze, krótkie wystąpienia nie mają trwałych skutków, ponieważ robot wraca na stronę później. Kłopot zaczyna się, gdy błędy z grupy 5xx powtarzają się przez dłuższy czas: robot ogranicza wtedy częstotliwość odwiedzin, a adresy stale zwracające błąd mogą zostać usunięte z indeksu. Stan ten widać w Google Search Console, w raporcie statystyk indeksowania oraz w raporcie indeksowania stron.

Czy wyczyszczenie pamięci przeglądarki usuwa błąd 504?

Zazwyczaj nie, ponieważ błąd powstaje na serwerze, a nie w przeglądarce. Wyjątkiem są kłopoty z siecią po stronie odwiedzającego, na przykład z pośrednikiem sieciowym, zaporą albo połączeniem VPN. Jeżeli u innych osób i na innym łączu witryna działa poprawnie, należy sprawdzić własne ustawienia sieci.

Dlaczego błąd pojawia się tylko w panelu administracyjnym?

Część publiczna witryny jest zwykle obsługiwana z pamięci podręcznej, więc odpowiedź nie wymaga pracy PHP ani bazy danych. Panel administracyjny nie korzysta z tej pamięci i każde żądanie jest liczone od nowa. Dlatego ciężkie zapytanie albo wolne połączenie z zewnętrzną usługą ujawnia się najpierw w panelu, na przykład na liście zamówień lub na ekranie kokpitu.

Czy zmiana hostingu rozwiąże problem?

Tylko wtedy, gdy przyczyną jest przeciążona lub niewydolna infrastruktura. Jeżeli za błąd odpowiada zapytanie bez indeksu albo wtyczka czekająca na cudzy serwer, na nowym hostingu błąd wróci, najwyżej nieco później. Dlatego decyzję o przenosinach należy podejmować po diagnozie, a nie zamiast niej.

Czy po błędzie 504 zamówienie albo formularz mogły się zapisać?

Tak. Serwer WWW zrywa połączenie z odwiedzającym, ale proces PHP często pracuje dalej i doprowadza czynność do końca. Przed ponowną próbą należy sprawdzić listę zamówień, skrzynkę pocztową albo listę wpisów. Powtórzenie czynności bez kontroli prowadzi do zdublowanych zamówień i podwójnych wiadomości.

Jak długo może trwać jedno żądanie?

Nie ma jednej wartości, bo decyduje najkrótszy limit na drodze żądania. Wartości domyślne podane w dokumentacji to 60 sekund dla odczytu w nginx i 30 sekund czasu wykonania w PHP, ale dostawcy hostingu ustawiają je po swojemu. Niezależnie od limitów strona, która powstaje dłużej niż kilka sekund, wymaga poprawy, ponieważ odwiedzający nie czekają tak długo.

Czy wtyczka pamięci podręcznej wystarczy, żeby pozbyć się błędu?

Pamięć podręczna stron odciąża serwer i często usuwa objawy na podstronach publicznych. Nie obejmuje jednak koszyka, panelu klienta, wyszukiwarki, panelu administracyjnego ani zadań w tle. Jeżeli zbyt długi proces działa w jednym z tych miejsc, pamięć podręczna go nie skróci i trzeba naprawić samą przyczynę.

Brak czasu albo ochoty, żeby zająć się tym samodzielnie?

Szukanie procesu, który trwa za długo, wymaga cierpliwości i dostępu do kilku miejsc naraz, a w tym czasie firma i tak ma swoje codzienne sprawy. Mogę przejąć całość: ustalę, które ogniwo zgłasza błąd, przejrzę dzienniki serwera, PHP i bazy danych, wskażę wtyczkę, zapytanie lub zadanie odpowiedzialne za opóźnienie, a potem doprowadzę do naprawy i sprawdzę po kilku dniach, czy błąd nie wraca. W razie potrzeby sam porozmawiam z pomocą techniczną hostingu.

Wystarczy zadzwonić pod numer 533 525 168 albo napisać na adres info@lukaszwudyka.pl i podać adres witryny oraz krótki opis, kiedy błąd się pojawia. Resztę ustalę już samodzielnie.