Jak naprawić „Request timed out” w WordPress: limity PHP w praktyce

Import produktów zatrzymuje się w połowie. Backup nie może się zakończyć. Generator miniatur pracuje przez chwilę, a potem zwraca błąd. Innym razem w kokpicie WordPressa pojawia się komunikat Request timed out, Maximum execution time exceeded, błąd 504 albo cURL error 28.

Wszystkie te sytuacje łączy czas, ale niekoniecznie ten sam limit. W WordPressie możesz jednocześnie trafić na ograniczenie wykonywania PHP, limit przetwarzania danych wejściowych, timeout połączenia z zewnętrznym API albo limit narzucony przez serwer WWW. Podniesienie max_execution_time do dużej wartości czasem pomaga, ale równie często tylko maskuje problem.

W tym poradniku pokażę Ci, jak rozpoznać poszczególne rodzaje timeoutów, które parametry PHP rzeczywiście mają znaczenie oraz kiedy zamiast zwiększać limit lepiej poszukać wolnego zapytania, problematycznej wtyczki lub zewnętrznej usługi.

„Request timed out” nie zawsze oznacza ten sam problem

Zanim zmienisz konfigurację PHP, ustal, który element faktycznie przerwał operację. Samo słowo timeout mówi tylko, że gdzieś został przekroczony określony czas oczekiwania.

To ważne rozróżnienie. Jeśli WordPress próbuje połączyć się z zewnętrznym API i po 10 sekundach dostajesz cURL error 28, ustawienie max_execution_time = 300 nie zmieni automatycznie timeoutu tego połączenia. Podobnie błąd 504 może pojawić się wcześniej niż limit ustawiony w samym PHP.

Jeżeli zamiast timeoutu widzisz pustą stronę lub błąd krytyczny, warto zajrzeć również do poradnika Biały ekran w WordPressie. Od logów po rozwiązanie. Metoda diagnostyczna jest podobna: najpierw zbierasz dane, dopiero potem zmieniasz konfigurację.

Zacznij od logów, a nie od zwiększania wszystkich limitów

Jeśli operacja kończy się po kilkudziesięciu sekundach, łatwo założyć, że winny jest limit PHP. Najpierw spróbuj jednak odtworzyć problem i sprawdź log dokładnie w chwili jego wystąpienia.

W cyber_Admin możesz przejść do Serwer WWW → Strony WWW, otworzyć ustawienia konkretnej strony i wybrać Logi bieżące. W przypadku problemów z WordPressem szczególnie interesuje Cię error.log. Pełną instrukcję znajdziesz w poradniku jak sprawdzić logi strony.

Szukaj przede wszystkim komunikatów z tej samej minuty, w której odtworzyłeś błąd. Przy timeoutach szczególnie przydatne są frazy:

• Maximum execution time,
• Allowed memory size exhausted,
• upstream timed out,
• Connection timed out,
• cURL error 28,
• ścieżka do konkretnego pluginu lub motywu.

Dobra praktyka. Otwórz log w jednej karcie, wykonaj problematyczną operację w drugiej i od razu odśwież log. Nie zaczynaj od analizowania setek wcześniejszych ostrzeżeń. Interesują Cię wpisy powiązane czasowo z konkretnym testem.

Jeżeli nie ma wpisu o przekroczeniu czasu PHP, nie zakładaj automatycznie, że rozwiązaniem jest jego zwiększenie. Timeout mógł nastąpić w innej warstwie.

max_execution_time. Najważniejszy limit czasu PHP

max_execution_time określa, jak długo PHP może wykonywać skrypt, zanim przerwie jego działanie. Domyślna wartość w standardowej konfiguracji PHP wynosi 30 sekund, ale hosting może ustawić inną wartość.

Limit ma znaczenie przede wszystkim przy operacjach wykonywanych w ramach jednego długiego żądania. Przykłady to:

• import dużej liczby produktów lub wpisów,
• eksport danych,
• generowanie raportów,
• przetwarzanie dużych obrazów,
• niektóre migracje i operacje backupu,
• masowe przeliczanie danych przez wtyczkę,
• długie operacje administracyjne uruchamiane z poziomu przeglądarki.

Jeżeli log pokazuje na przykład:

PHP Fatal error: Maximum execution time of 60 seconds exceeded
in /wp-content/plugins/example-plugin/includes/import.php on line 417

masz mocny dowód, że skrypt rzeczywiście doszedł do limitu PHP. Wtedy zwiększenie max_execution_time może być uzasadnionym testem.

Nie ustawiaj jednak od razu 600 czy 1800 sekund tylko po to, aby operacja „w końcu przeszła”. Jeśli prosty zapis produktu trwa kilka minut, większy limit nie usuwa przyczyny. Może nią być nieefektywna wtyczka, bardzo wolne zapytanie SQL, oczekiwanie na API albo zbyt duża partia danych wykonywana w jednym żądaniu.

Warto też pamiętać, że PHP nie jest jedynym elementem kontrolującym czas. Dokumentacja PHP wprost zaznacza, że własne timeouty może mieć również serwer WWW. Dlatego ustawienie max_execution_time na 300 sekund nie gwarantuje, że każde żądanie HTTP będzie mogło faktycznie działać przez pięć minut. Szczegóły znajdziesz w dokumentacji konfiguracji PHP.

memory_limit. Gdy problem wygląda jak timeout, ale brakuje pamięci

Długa operacja często zużywa również więcej pamięci. Dlatego przy analizowaniu timeoutów sprawdzaj memory_limit równolegle z czasem wykonywania. Jeśli proces zakończy się przez brak pamięci, samo zwiększenie max_execution_time niczego nie zmieni.

Typowy wpis wygląda tak:

PHP Fatal error: Allowed memory size of 268435456 bytes exhausted

W takim przypadku skrypt osiągnął limit pamięci. Możesz testowo zwiększyć memory_limit, ale ponownie warto zadać sobie pytanie, dlaczego dana operacja potrzebuje tak dużej ilości RAM.

PHP 8.5 wprowadził dodatkowo dyrektywę max_memory_limit, która może określać górny pułap dla memory_limit. Jeśli interesują Cię również pozostałe zmiany w tej wersji, zajrzyj do wpisu PHP 8.5 dostępny w cyber_Folks. Zobacz, co się zmienia.

W praktyce oznacza to jeszcze jedną rzecz: wartość wpisana przez aplikację nie zawsze musi być wartością, z którą PHP ostatecznie będzie pracować. Ograniczenie może istnieć wyżej, na poziomie konfiguracji środowiska.

Dokładne działanie memory_limit i max_memory_limit opisuje również oficjalny podręcznik PHP.

max_input_time, post_max_size i max_input_vars. Nie każdy limit dotyczy wykonywania kodu

Przy dużych formularzach, importach i uploadzie znaczenie mają również parametry, które nie określają bezpośrednio czasu działania całego skryptu.

max_input_time łatwo pomylić z max_execution_time. Pierwszy parametr dotyczy etapu przetwarzania danych wejściowych, zanim rozpocznie się właściwe wykonywanie skryptu. Nie jest więc uniwersalnym rozwiązaniem na wolne działanie WordPressa.

Podobnie upload_max_filesize i post_max_size rozwiązują inny problem niż timeout. Jeśli chcesz dowiedzieć się, jak te wartości współpracują ze sobą przy mediach i importach, zobacz poradnik jak podnieść limit przesyłania plików w WordPressie.

Zwróć uwagę. Nie zwiększaj wszystkich parametrów jednocześnie. Jeśli zmienisz pięć wartości, a problem zniknie, nadal nie będziesz wiedzieć, co było jego przyczyną. Zmieniaj jeden istotny parametr, powtarzaj test i sprawdzaj log.

Jak zmienić limity PHP w direct_Admin?

Jeśli korzystasz z hostingu zarządzanego przez DirectAdmin, część limitów PHP możesz zmienić bez edytowania plików konfiguracyjnych. Po zalogowaniu do panelu wybierz domenę, której dotyczy problem, a następnie przejdź do Pozostałe ustawienia -> PHP – ustawienia globalne -> Zakładka „Opcje„.

W tym miejscu szukaj przede wszystkim parametrów max_execution_time, memory_limit, max_input_time, max_input_vars, post_max_size i upload_max_filesize. Jeśli diagnozujesz komunikat Maximum execution time exceeded, zacznij od max_execution_time zamiast podnosić wszystkie wartości jednocześnie.

Jak zmienić limity PHP w cyber_Admin?

W cyber_Admin parametry PHP możesz sprawdzić dla konkretnej witryny. Przejdź do Serwer WWW → Strony WWW, wybierz stronę i otwórz zakładkę Ustawienia PHP. W tym miejscu możesz również sprawdzić wersję interpretera przypisaną do danej strony.

Panel udostępnia najpopularniejsze opcje bez konieczności ręcznej edycji konfiguracji. Szczegółowy opis znajdziesz w aktualnej instrukcji jak zmienić ustawienia PHP w cyber_Admin.

W środowiskach, w których konfiguracja na to pozwala, parametr może być ustawiany również na poziomie pliku .htaccess. Przykładowo:

php_value max_execution_time 120
php_value memory_limit 256M
php_value max_input_time 120
php_value max_input_vars 5000

Traktuj te liczby jako przykład składni, a nie uniwersalne zalecane wartości. To, jaki limit ma sens, zależy od aplikacji, rodzaju operacji oraz ograniczeń konkretnego środowiska hostingowego.

Po każdej zmianie wykonaj dokładnie tę samą operację, która wcześniej kończyła się błędem. Jeżeli po podniesieniu limitu ze 60 do 120 sekund proces zaczyna działać, otrzymujesz dodatkową informację diagnostyczną. Nadal jednak warto sprawdzić, dlaczego trwa tak długo.

cURL error 28 i 504. Kiedy zmiana max_execution_time nie pomoże?

To jedna z najważniejszych pułapek podczas diagnozowania WordPressa. Nie każdy timeout jest timeoutem PHP.

cURL error 28

WordPress ma własny mechanizm wykonywania żądań HTTP. Korzystają z niego między innymi aktualizacje, integracje API, systemy płatności, wtyczki SMTP, połączenia licencyjne i wiele innych rozszerzeń.

Domyślny timeout w WordPress HTTP API wynosi obecnie 5 sekund. Wtyczka może jednak ustawić własną wartość. Jeśli więc widzisz:

cURL error 28: Operation timed out after 10001 milliseconds

najpierw ustal, z jakim adresem WordPress próbował się połączyć. Przyczyną może być wolne API, problem z DNS, blokada sieciowa, firewall, problem z TLS albo zbyt niski timeout ustawiony przez konkretną wtyczkę.

Jeżeli tworzysz własną integrację, timeout możesz ustawić dla konkretnego żądania zamiast zmieniać globalne limity PHP:

$response = wp_remote_get(
    'https://api.example.com/data',
    array(
        'timeout' => 15,
    )
);

Dokumentacja WP_Http::request() opisuje dostępne parametry, w tym timeout połączenia.

504 Gateway Timeout

Przy błędzie 504 odpowiedź mogła zostać przerwana przez serwer lub element pośredniczący, który zbyt długo czekał na backend. PHP nadal może być źródłem problemu, jeśli aplikacja generuje stronę bardzo długo, ale zwiększanie wyłącznie max_execution_time nie jest gwarantowanym rozwiązaniem.

Jeżeli chcesz lepiej rozróżniać kody 500, 502, 503 i 504, pomocny będzie również wpis Spokojnie, to tylko error.

Timeout w praktyce. Co sprawdzić w typowych sytuacjach?

Import kończy się po kilkudziesięciu sekundach

Sprawdź error.log pod kątem Maximum execution time exceeded. Jeśli taki wpis istnieje, zwiększenie limitu może pomóc. Jeszcze lepszym rozwiązaniem jest jednak import w mniejszych partiach, jeśli narzędzie daje taką możliwość. Krótsze operacje są mniej podatne na timeout i łatwiejsze do wznowienia.

Backup lub migracja nie może się zakończyć

Duża witryna może wymagać jednocześnie czasu, pamięci i operacji dyskowych. Sprawdź więc nie tylko max_execution_time, ale również memory_limit, rozmiar tworzonego archiwum i log konkretnej wtyczki.

Jeżeli narzędzie próbuje spakować całą stronę podczas jednego żądania HTTP, warto sprawdzić, czy obsługuje dzielenie procesu na partie albo wykonywanie operacji w tle.

Operacja w WooCommerce trwa bardzo długo

Przy dużym sklepie przyczyną może być PHP, ale równie dobrze baza danych. Eksport tysięcy produktów, masowa zmiana cen czy przetwarzanie zamówień może wykonywać bardzo ciężkie zapytania. Wtedy zwiększenie czasu pozwoli skryptowi działać dłużej, ale nie sprawi, że zapytania staną się szybsze.

Wtyczka czeka na zewnętrzne API

Jeżeli log pokazuje cURL error 28, ustal docelową domenę i czas ustawiony dla połączenia. Sprawdź, czy problem występuje stale, czy tylko okresowo. Jeśli zewnętrzny serwer nie odpowiada, zwiększenie limitów PHP jedynie wydłuży oczekiwanie użytkownika.

Długa operacja administracyjna

Jeśli zadanie nie musi być wykonywane przez przeglądarkę, rozważ uruchomienie go z CLI. PHP uruchamiane z linii poleceń może mieć inną konfigurację niż PHP obsługujące stronę WWW, a WP-CLI pozwala wykonywać wiele operacji administracyjnych bez utrzymywania jednego żądania HTTP.

Praktyczne przykłady znajdziesz w poradniku WP-CLI. Co to jest i jak usprawnia pracę z WordPress?

Kiedy nie zwiększać limitów PHP?

Większy limit jest dobrym rozwiązaniem wtedy, gdy aplikacja wykonuje uzasadnioną, cięższą operację i po prostu potrzebuje trochę więcej zasobów. Nie powinien być natomiast pierwszą reakcją na każdą wolną stronę.

Podnoszenie limitów raczej nie jest właściwym kierunkiem, gdy:

• zwykła podstrona generuje się kilkadziesiąt sekund,
• jedna wtyczka nagle zaczęła wykorzystywać ogromną ilość pamięci,
• problem występuje dopiero po jej aktualizacji,
• WordPress czeka na niedostępne zewnętrzne API,
• w bazie wykonywane są bardzo wolne zapytania,
• zadanie można łatwo podzielić na krótsze partie,
• timeout pojawia się wcześniej niż limit ustawiony w PHP.

W takiej sytuacji limit jest bardziej sygnałem ostrzegawczym niż przyczyną. Jeśli aplikacja potrzebuje 180 sekund na czynność, która wcześniej zajmowała pięć, lepiej ustalić, co się zmieniło.

W praktyce szczególnie często warto sprawdzić bazę, zapytania wykonywane przez wtyczki, zewnętrzne integracje, zadania cron oraz operacje wykonywane podczas każdego żądania. Dopiero gdy wiesz, co zużywa czas, możesz zdecydować, czy potrzebujesz optymalizacji, czy rzeczywiście większego limitu.

Najpierw diagnoza, potem wyższy limit

Przy błędzie Request timed out najważniejsze jest ustalenie, który zegar odliczył do zera. Jeśli log pokazuje Maximum execution time exceeded, sprawdź max_execution_time. Jeśli widzisz Allowed memory size exhausted, zainteresuj się pamięcią. Przy cURL error 28 analizuj konkretne połączenie HTTP, a przy 504 również warstwę serwera WWW.

Podniesienie limitu jest narzędziem, nie naprawą samą w sobie. Najlepszy efekt daje połączenie trzech kroków: odtworzenia problemu, sprawdzenia logu i zmiany tylko tego parametru, który rzeczywiście ogranicza operację.

Jeśli tworzysz lub utrzymujesz strony WordPress, przydaje się środowisko, w którym możesz wygodnie zarządzać wersją i parametrami PHP, korzystać z logów oraz narzędzi deweloperskich bez walki z konfiguracją.