Błąd 502 Bad Gateway w WordPressie. Co leży po stronie hostingu, a co witryny?

Komunikat „502 Bad Gateway” pojawia się nagle, często na całej witrynie naraz, i nie mówi nic o tym, co się zepsuło. Właściciel firmy widzi białą stronę z jednym wierszem tekstu, a klienci w tym czasie nie mogą złożyć zamówienia ani wysłać zapytania. Najtrudniejsze jest to, że na pierwszy rzut oka nie wiadomo, do kogo się zwrócić: do firmy hostingowej czy do osoby, która opiekuje się WordPressem.

Ta instrukcja jest przeznaczona dla właścicieli stron na WordPressie i osób, które samodzielnie nimi administrują. Opisuję w niej, skąd bierze się błąd 502, jak w kilka minut ustalić, czy przyczyna leży na serwerze, w sieci pośredniczącej, czy w samej witrynie, oraz co zrobić w każdym z tych przypadków.

Po lekturze czytelnik będzie umiał odróżnić 502 od innych błędów serwera, odczytać najważniejsze wpisy w dziennikach, bezpiecznie wyłączyć wtyczki bez dostępu do panelu, napisać do hostingu zgłoszenie, na które da się konkretnie odpowiedzieć, i ocenić, czy awaria zaszkodziła widoczności strony w Google.

Co oznacza błąd 502 Bad Gateway i dlaczego nie jest zwykłą awarią strony?

Strona na WordPressie rzadko jest obsługiwana przez jeden program. Zapytanie przeglądarki trafia najpierw do serwera WWW, na przykład Nginx, Apache albo LiteSpeed. Ten serwer sam nie buduje strony. Przekazuje zapytanie dalej, do usługi PHP, która uruchamia WordPressa, wtyczki i motyw, a potem odbiera gotową stronę i odsyła ją do przeglądarki.

Kod 502 oznacza, że serwer pełniący rolę pośrednika, czyli bramy, otrzymał od serwera stojącego za nim nieprawidłową odpowiedź. Tak opisuje go dokumentacja techniczna standardu HTTP. Pośrednik działa, skoro potrafił wyświetlić komunikat. Zawiodło ogniwo znajdujące się głębiej: usługa PHP przerwała pracę w połowie, odrzuciła połączenie albo odesłała coś, czego pośrednik nie umiał przyjąć.

W praktyce pośredników bywa kilku. Jeśli witryna korzysta z sieci CDN lub usługi ochronnej, takiej jak Cloudflare, to ona stoi najbliżej odwiedzającego i ona może pokazać 502, gdy nie otrzyma poprawnej odpowiedzi z serwera hostingowego. Dlatego ten sam komunikat może mieć źródło w trzech miejscach: w sieci pośredniczącej, na serwerze hostingu albo w kodzie witryny, który doprowadza usługę PHP do przerwania pracy.

Po czym rozpoznać, że to właśnie 502, a nie inny błąd serwera?

Błędy z grupy 5xx wyglądają podobnie, ale mówią o czymś innym. Rozróżnienie ich na początku oszczędza dużo czasu, bo każdy prowadzi do innego miejsca.

Błąd 500 oznacza, że serwer sam napotkał problem przy wykonywaniu kodu, najczęściej błąd PHP albo wadliwy plik .htaccess. Osobno opisałem, jak ustalić przyczynę błędu 500 w WordPressie. Błąd 503 informuje, że usługa jest chwilowo niedostępna, na przykład w trakcie aktualizacji lub przy przeciążeniu. Błąd 504 pojawia się wtedy, gdy pośrednik w ogóle nie doczekał się odpowiedzi w wyznaczonym czasie.

Błąd 502 leży między nimi: odpowiedź przyszła, ale była nieprawidłowa, albo połączenie zostało zerwane. Granica między 502 a 504 bywa w praktyce płynna i zależy od konfiguracji serwera, dlatego oba kody diagnozuje się w podobny sposób.

Komunikat może mieć różną postać. Serwer Nginx pokazuje zwykle białą stronę z napisem „502 Bad Gateway” i nazwą serwera pod spodem. Przeglądarka może wyświetlić „HTTP ERROR 502”. Cloudflare pokazuje własną planszę z rysunkiem trzech ogniw połączenia: przeglądarki, sieci Cloudflare i serwera docelowego. Część firm hostingowych podmienia komunikat na własną stronę z informacją o chwilowej niedostępności.

Zanim zacznie się szukać przyczyny, należy wykluczyć problem po stronie własnego komputera. Wystarczy otworzyć stronę w oknie prywatnym przeglądarki oraz na telefonie korzystającym z sieci komórkowej, a nie z firmowego Wi-Fi. Jeśli na innym urządzeniu i w innej sieci strona działa, przyczyną jest pamięć podręczna przeglądarki albo lokalna sieć, a nie serwer.

Jak w kilka minut ustalić, po której stronie leży przyczyna?

1. Należy otworzyć stronę główną, dowolny wpis oraz adres logowania do panelu, czyli adres witryny z końcówką /wp-admin. Trzeba zanotować, które z tych miejsc pokazują błąd.
2. Stronę odświeża się kilka razy w odstępie minuty. Błąd, który raz jest, a raz go nie ma, wskazuje na przeciążenie albo wyczerpanie zasobów. Błąd stały wskazuje raczej na zatrzymaną usługę lub trwałą usterkę w kodzie.
3. Należy przyjrzeć się stronie z komunikatem: czy jest to plansza sieci CDN, strona firmy hostingowej, czy surowy napis serwera. Nazwa widoczna pod komunikatem mówi, który pośrednik zgłosił błąd.
4. W panelu klienta firmy hostingowej oraz na jej stronie ze statusem usług trzeba poszukać informacji o awarii lub pracach serwisowych. Jeśli hosting zgłasza awarię, dalsza diagnoza po stronie witryny nie ma sensu.
5. Trzeba ustalić, co zmieniło się tuż przed awarią: aktualizacja wtyczki, motywu lub WordPressa, zmiana wersji PHP w panelu hostingu, instalacja nowej wtyczki, import produktów, wysyłka dużej kampanii reklamowej.
6. Jeśli na tym samym koncie hostingowym działa inna strona, należy ją otworzyć. Gdy ona również pokazuje 502, przyczyna prawie na pewno leży po stronie serwera.

Wyniki tych sześciu czynności zwykle układają się w jeden z trzech obrazów. Pierwszy: nie działa nic, także inne strony na koncie, a błąd pojawił się bez żadnej zmiany w witrynie. To sprawa dla hostingu. Drugi: błąd pojawił się zaraz po aktualizacji albo dotyczy jednej czynności, na przykład zapisu wpisu lub finalizacji zamówienia. To sprawa witryny. Trzeci: błąd pojawia się falami, w godzinach większego ruchu albo o stałych porach. Tu przyczyna leży na styku: witryna zużywa więcej zasobów, niż przewiduje pakiet hostingowy.

Co mówi miejsce, w którym błąd się pojawia?

Błąd wyłącznie w panelu administracyjnym, przy działającej stronie publicznej, jest częstym obrazem na witrynach z pamięcią podręczną. Odwiedzający dostają zapisane wcześniej kopie stron, których serwer nie musi budować od nowa. Panel zawsze wymaga pracy PHP, więc to on pierwszy pokazuje, że usługa PHP nie nadąża lub przerywa działanie.

Błąd przy jednej czynności, takiej jak wgrywanie dużego pliku, eksport zamówień albo uruchomienie kopii zapasowej, oznacza zwykle zadanie, które trwa zbyt długo lub zużywa zbyt dużo pamięci, przez co serwer je przerywa. Błąd na wszystkich adresach naraz, łącznie z plikami graficznymi, wskazuje na serwer albo sieć pośredniczącą, bo do wyświetlenia obrazka WordPress nie jest potrzebny.

Które przyczyny leżą po stronie hostingu?

Po stronie serwera błąd 502 ma kilka typowych źródeł. Właściciel witryny na hostingu współdzielonym nie ma na nie bezpośredniego wpływu, ale powinien je znać, żeby zadać obsłudze właściwe pytanie.

Pierwsze źródło to zatrzymana albo ponownie uruchamiana usługa PHP. Dzieje się tak podczas prac serwisowych, po zmianie wersji PHP lub po awarii. W tym czasie serwer WWW nie ma komu przekazać zapytania i zgłasza 502. Taka przerwa trwa zwykle krótko i mija sama.

Drugie źródło to wyczerpany limit procesów PHP. Każdy pakiet hostingowy pozwala obsługiwać jednocześnie określoną liczbę zapytań wymagających pracy PHP. Gdy wszystkie procesy są zajęte, kolejne zapytania czekają w kolejce, a po jej zapełnieniu są odrzucane. Limit jest ustawieniem hostingu, ale o tym, jak szybko się wyczerpuje, decyduje witryna i ruch na niej.

Trzecie źródło to przeciążenie całego serwera, na przykład przez inną witrynę na tej samej maszynie, awaria sprzętu lub sieci w centrum danych. Czwarte to błędna konfiguracja po stronie hostingu: zbyt małe bufory na nagłówki odpowiedzi, zbyt krótki czas oczekiwania na usługę PHP albo zapora, która blokuje adresy sieci CDN i przez to odcina ją od serwera.

Kto woli nie zajmować się tym samodzielnie, może zadzwonić pod numer 533 525 168 albo napisać na info@lukaszwudyka.pl. Przejmę sprawę: ustalę na podstawie dzienników, czy błąd 502 wywołuje serwer, sieć pośrednicząca czy witryna, usunę przyczynę po stronie WordPressa, a jeśli leży ona na serwerze, przygotuję konkretne zgłoszenie do firmy hostingowej.

Które przyczyny leżą po stronie witryny?

WordPress sam z siebie nie wysyła kodu 502. Może natomiast doprowadzić do sytuacji, w której usługa PHP przerywa pracę, a wtedy komunikat wyświetla serwer. Dlatego w panelu WordPressa nie ma żadnego ekranu z opisem tego błędu, a w oficjalnej dokumentacji WordPressa najbliższe mu opisy dotyczą wyczerpania pamięci i przekroczenia czasu wykonywania.

Najczęstsza przyczyna po stronie witryny to wtyczka lub motyw po aktualizacji, niezgodne z wersją PHP ustawioną na serwerze. Zwykle kończy się to komunikatem o błędzie krytycznym, ale w niektórych konfiguracjach proces PHP po prostu kończy działanie i odwiedzający widzi 502.

Druga przyczyna to zadania trwające zbyt długo: import dużego pliku z produktami, tworzenie kopii zapasowej w godzinach ruchu, generowanie miniatur dla całej biblioteki mediów, rozbudowany raport sprzedaży. Serwer ma ustawiony czas, po którym przerywa proces, i wtedy zrywa połączenie.

Trzecia przyczyna to zbyt wiele kosztownych zapytań naraz. Witryna bez pamięci podręcznej stron, z ciężkim kreatorem i kilkudziesięcioma wtyczkami potrzebuje dużo czasu na zbudowanie każdej podstrony. Przy większym ruchu procesy PHP kończą się szybciej, niż zdążą się zwolnić. Jeśli strona od dawna ładuje się długo, przydatny będzie opis tego, co spowalnia WordPressa i jak to zmierzyć.

Czwarta przyczyna to ruch automatów albo zbyt duże nagłówki odpowiedzi, na przykład przy bardzo wielu plikach cookie zapisywanych przez wtyczki. Masowe próby logowania na adres wp-login.php, zapytania do pliku xmlrpc.php albo agresywne roboty przeszukujące sklep z filtrami potrafią zająć wszystkie procesy PHP. Dla serwera wygląda to jak zwykłe przeciążenie, a dla właściciela jak awaria bez powodu.

Jak odczytać dzienniki błędów i znaleźć w nich przyczynę?

Dziennik błędów serwera jest jedynym miejscem, w którym przyczyna 502 jest zapisana wprost. Większość firm hostingowych udostępnia go w panelu klienta, w części poświęconej statystykom lub dziennikom, albo jako plik w katalogu konta dostępny przez FTP. Nazwy tych miejsc różnią się między firmami, więc w razie wątpliwości najprościej zapytać obsługę, gdzie znajduje się dziennik błędów serwera WWW i dziennik PHP.

1. Należy zanotować dokładną godzinę ostatniego wystąpienia błędu, najlepiej wywołując go samodzielnie przez odświeżenie strony.
2. W panelu hostingu otwiera się dziennik błędów dla danej domeny i przewija do zanotowanej godziny.
3. Trzeba wyszukać wiersze ze słowem upstream. To określenie usługi stojącej za serwerem WWW, czyli w przypadku WordPressa usługi PHP.
4. Z wiersza należy przepisać dwie informacje: treść komunikatu oraz adres, którego dotyczyło zapytanie. Adres pokazuje, czy błąd wywołuje konkretna podstrona, plik wtyczki czy każde zapytanie.
5. Jeśli hosting udostępnia osobny dziennik PHP, należy otworzyć go dla tej samej godziny i odnaleźć wpisy o błędach krytycznych, czyli zaczynające się od słów PHP Fatal error.

Na serwerach Nginx powtarza się kilka komunikatów, a ich znaczenie pozwala od razu zawęzić poszukiwania.

• connect() failed (111: Connection refused) while connecting to upstream – usługa PHP nie działa albo nie przyjmuje połączeń. Przyczyna leży po stronie serwera, więc sprawę należy zgłosić hostingowi.
• upstream prematurely closed connection while reading response header from upstream – proces PHP zakończył się w trakcie budowania strony. Powodem bywa błąd w kodzie wtyczki lub motywu, brak pamięci albo przerwanie zbyt długiego zadania.
• upstream sent too big header while reading response header from upstream – odpowiedź miała zbyt duże nagłówki. Trzeba ograniczyć liczbę plików cookie i nagłówków dodawanych przez wtyczki albo poprosić hosting o zwiększenie buforów.
• server reached pm.max_children setting w dzienniku usługi PHP – wyczerpał się limit jednoczesnych procesów. Trzeba ustalić, co je zajmuje, a dopiero potem rozmawiać o wyższym limicie.

Jeśli w dzienniku serwera przy błędzie stale powtarza się ten sam adres, na przykład plik admin-ajax.php, wp-cron.php albo xmlrpc.php, to jest to mocna wskazówka. Pierwszy obsługuje zapytania wtyczek działające w tle, drugi zadania zaplanowane, trzeci zdalny dostęp do WordPressa, często nadużywany przez automaty.

Jak włączyć dziennik błędów WordPressa?

Gdy hosting nie udostępnia dziennika PHP, można włączyć zapis błędów w samym WordPressie. Dokumentacja WordPressa opisuje do tego trzy ustawienia w pliku wp-config.php. Wstawia się je przed wierszem z komentarzem kończącym edycję, czyli przed tekstem zaczynającym się od słów „That’s all, stop editing”.

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

Pierwszy wiersz włącza tryb diagnostyczny, drugi zapisuje błędy do pliku debug.log w katalogu wp-content, trzeci ukrywa je przed odwiedzającymi. Po odtworzeniu błędu należy pobrać plik debug.log i przeczytać ostatnie wpisy. Ścieżka w komunikacie o błędzie krytycznym zawiera nazwę katalogu wtyczki lub motywu, który go wywołał.

Po zakończeniu diagnozy trzeba przywrócić w pierwszym wierszu wartość false i usunąć plik dziennika z serwera. Dokumentacja WordPressa odradza pozostawianie trybu diagnostycznego na działającej witrynie, a plik dziennika pozostawiony w publicznym katalogu może ujawnić osobom postronnym ścieżki i szczegóły konfiguracji.

Jak sprawdzić wtyczki i motyw, gdy panel nie działa?

Jeśli obserwacje i dzienniki wskazują na witrynę, najszybszą metodą jest wyłączenie wszystkich wtyczek naraz i sprawdzenie, czy błąd ustąpił. Gdy panel pokazuje 502, robi się to przez FTP albo menedżer plików w panelu hostingu. Dokumentacja WordPressa zaleca w tym celu zmianę nazwy katalogu z wtyczkami. Przed rozpoczęciem należy mieć aktualną kopię plików i bazy. Sposób jej wykonania i sprawdzenia opisałem w tekście o tym, jak zrobić kopię zapasową WordPressa.

1. Należy połączyć się z serwerem przez FTP lub otworzyć menedżer plików w panelu hostingu i przejść do katalogu witryny, a w nim do wp-content.
2. Nazwę katalogu plugins zmienia się na plugins_old. WordPress nie znajdzie wtyczek i uzna je wszystkie za wyłączone. Ustawienia wtyczek pozostają w bazie danych i nie zostaną utracone.
3. Trzeba otworzyć stronę i panel administracyjny. Jeśli błąd 502 zniknął, przyczyną jest jedna z wtyczek. Jeśli pozostał, wtyczki są poza podejrzeniem i należy przejść do motywu.
4. Katalogowi przywraca się nazwę plugins. Wtyczki pozostaną wyłączone, ale znów będą widoczne w panelu.
5. W panelu, w menu „Wtyczki”, włącza się je pojedynczo, zaczynając od tych, które były ostatnio aktualizowane. Po każdym włączeniu należy otworzyć stronę oraz miejsce, w którym wcześniej pojawiał się błąd.
6. Wtyczkę, po której włączeniu błąd wraca, trzeba pozostawić wyłączoną i sprawdzić, czy jej autor wydał poprawkę albo czy wymaga ona innej wersji PHP niż ustawiona na serwerze.

W sklepie internetowym wyłączenie wszystkich wtyczek oznacza chwilowe wyłączenie koszyka i płatności. Skoro witryna i tak pokazuje błąd, strata jest niewielka, ale przy błędzie pojawiającym się tylko czasami lepiej wykonać tę próbę poza godzinami największej sprzedaży albo na kopii testowej witryny.

Jak sprawdzić motyw?

Motyw sprawdza się podobnie. W katalogu wp-content/themes zmienia się nazwę katalogu aktywnego motywu. Jeśli na serwerze znajduje się jeden z domyślnych motywów WordPressa, system przełączy się na niego. Gdy po tej zmianie błąd ustępuje, przyczyną jest motyw albo jego motyw potomny z własnymi modyfikacjami. Jeśli domyślnego motywu nie ma, należy najpierw wgrać go do katalogu motywów.

A jeśli panel działa i błąd pojawia się tylko czasami?

Przy błędzie nieregularnym wyłączanie wszystkiego na ślepo niewiele daje, bo nie wiadomo, kiedy błąd miałby wrócić. Lepiej oprzeć się na dziennikach i na godzinach wystąpień. Stała pora, na przykład codziennie w nocy, wskazuje na zadanie zaplanowane: kopię zapasową, synchronizację stanów magazynowych, wysyłkę wiadomości lub skanowanie bezpieczeństwa. Takie zadanie należy przenieść na godziny najmniejszego ruchu albo podzielić na mniejsze części w ustawieniach danej wtyczki.

Pomocna jest też wtyczka Health Check & Troubleshooting, przygotowana przez społeczność WordPressa. Jej tryb rozwiązywania problemów wyłącza wtyczki i przełącza motyw wyłącznie dla zalogowanego administratora, a odwiedzający nadal widzą witrynę bez zmian. Informacje o wersji PHP i limitach serwera można odczytać w panelu, w menu „Narzędzia”, na ekranie „Stan witryny”, w zakładce „Informacje”.

Co zrobić, gdy witryna działa za Cloudflare lub inną siecią CDN?

Sieć pośrednicząca dodaje do łańcucha jeszcze jedno ogniwo i jeszcze jedno możliwe źródło błędu. Dokumentacja Cloudflare rozróżnia dwa przypadki i podaje prosty sposób ich rozpoznania po wyglądzie strony.

Jeśli komunikat 502 widnieje na planszy z oznaczeniami Cloudflare, błąd pochodzi z serwera docelowego, czyli z hostingu. Cloudflare jedynie przekazuje to, co otrzymał. Dokumentacja zaleca wtedy kontakt z firmą hostingową i sprawdzenie trzech rzeczy: czy serwer odpowiada na zapytania dla danej domeny, czy nie jest przeciążony lub nie uległ awarii oraz czy któraś z usług nie została zablokowana albo nie przekroczyła czasu.

Jeśli komunikat pojawia się na pustej stronie bez oznaczeń Cloudflare, źródłem może być sama sieć pośrednicząca. Dokumentacja wymienia tu między innymi wadliwą kompresję odpowiedzi po stronie serwera oraz chwilowe przekierowanie ruchu między centrami danych, które trwa zwykle kilka sekund. W takim przypadku należy sprawdzić stronę ze statusem usług Cloudflare i odczekać kilka minut.

Pewność daje ominięcie sieci pośredniczącej na czas próby. W panelu Cloudflare służy do tego wstrzymanie usługi dla domeny albo przełączenie rekordu DNS na tryb bez pośrednictwa. Trzeba jednak wiedzieć, że na ten czas witryna traci ochronę i pamięć podręczną sieci, a adres serwera staje się widoczny publicznie. Jeśli witryna była wcześniej celem ataków, bezpieczniej poprosić hosting o sprawdzenie, czy serwer odpowiada poprawnie na zapytania kierowane do niego bezpośrednio.

Jak napisać zgłoszenie do hostingu, żeby dostać konkretną odpowiedź?

Zgłoszenie o treści „strona nie działa” kończy się zwykle odpowiedzią, że serwer pracuje poprawnie, a przyczyny należy szukać we wtyczkach. Obsługa nie ma złej woli. Po prostu bez godziny i adresu nie jest w stanie odnaleźć zdarzenia w dziennikach. Dobre zgłoszenie zawiera dane, które pozwalają to zrobić od razu.

1. W tytule podaje się domenę i rodzaj błędu, na przykład: „Błąd 502 Bad Gateway w domenie [adres] od godziny [godzina]”.
2. W treści wpisuje się dokładne godziny kilku wystąpień błędu razem ze strefą czasową oraz adresy, na których się pojawił.
3. Należy opisać zakres: cała witryna czy wybrane miejsca, błąd stały czy okresowy, inne strony na koncie działają czy nie.
4. Trzeba wymienić, co już zostało sprawdzone: wyłączenie wtyczek, zmiana motywu, próba z innego urządzenia i z innej sieci.
5. Na końcu zadaje się konkretne pytania, na które da się odpowiedzieć na podstawie dzienników.

Pytania można przepisać w gotowej postaci:

Proszę o sprawdzenie dziennika błędów serwera WWW i dziennika usługi PHP dla wskazanych godzin oraz o informację: jaki komunikat towarzyszył błędom 502, czy konto osiągnęło limit jednoczesnych procesów PHP lub limit pamięci, czy w tym czasie usługa PHP była ponownie uruchamiana albo trwały prace serwisowe oraz czy zapora serwera blokowała adresy sieci CDN.

Odpowiedź na takie zgłoszenie rozstrzyga sprawę. Jeśli hosting potwierdzi wyczerpanie limitu procesów, trzeba ustalić, co je zajmuje, i dopiero potem zdecydować o wyższym pakiecie. Jeśli wskaże przerwanie zbyt długiego zadania, należy odnaleźć to zadanie wśród wtyczek. Jeśli potwierdzi awarię lub prace po swojej stronie, po stronie witryny nie trzeba robić nic.

Czy błąd 502 szkodzi widoczności strony w Google?

Krótka awaria nie zmienia pozycji strony. Dokumentacja Google opisuje reakcję robotów na błędy serwera dość dokładnie. Kody z grupy 5xx są dla nich sygnałem, że na jakiś czas należy zwolnić odwiedzanie witryny. Adresy, które były już w indeksie, pozostają w nim, ale jeśli błąd się utrzymuje, po pewnym czasie są usuwane. Treść otrzymana z adresu zwracającego taki kod jest pomijana.

Gdy serwer znów zaczyna odpowiadać poprawnie, Google stopniowo wraca do wcześniejszego tempa. Google nie podaje, po ilu dniach adresy wypadają z indeksu, dlatego nie należy opierać się na krążących w sieci terminach. Bezpieczne założenie jest takie: kilka godzin przerwy przechodzi bez śladu, a awaria trwająca wiele dni albo wracająca codziennie to już realne ryzyko.

Skutki awarii można odczytać w Google Search Console. W raporcie „Indeksowanie stron” adresy dotknięte problemem trafiają do grupy z przyczyną „Błąd serwera (5xx)”. W menu „Ustawienia”, w części „Statystyki indeksowania”, widać z kolei, ile zapytań robota zakończyło się błędem serwera i w jakich dniach. Jeśli po naprawie w wynikach wyszukiwania ubyło podstron, pomocna będzie lista tego, co sprawdzić, gdy strona zniknęła z Google.

Po usunięciu przyczyny należy otworzyć w raporcie szczegóły problemu „Błąd serwera (5xx)” i użyć przycisku „Sprawdź poprawkę”. Google ponownie odwiedzi wskazane adresy i zaktualizuje ich stan. Nie przyspiesza to powrotu pozycji, ale pozwala potwierdzić, że robot nie napotyka już błędu.

Po czym poznać, że naprawa zadziałała, i co robić, gdy błąd wraca?

Zniknięcie komunikatu z ekranu nie jest jeszcze dowodem naprawy, zwłaszcza przy błędzie okresowym. Pewność dają trzy rzeczy. Po pierwsze, w dzienniku błędów serwera nie przybywa nowych wierszy ze słowem upstream. Po drugie, czynność, która wcześniej wywoływała błąd, kończy się poprawnie kilka razy z rzędu. Po trzecie, witryna przechodzi bez błędu porę, w której wcześniej się wyłączała, czyli godziny największego ruchu albo godzinę zadania zaplanowanego.

Jeśli błąd wraca mimo wyłączenia podejrzanej wtyczki i potwierdzenia przez hosting, że serwer działa poprawnie, pozostają trzy kierunki. Pierwszy to ruch automatów: w dzienniku dostępu należy poszukać adresów, z których w krótkim czasie przychodzą setki zapytań, i ograniczyć je zaporą lub ustawieniami sieci CDN. Drugi to brak pamięci podręcznej stron, przez co każda odsłona angażuje PHP. Trzeci to pakiet hostingowy zbyt mały dla danej witryny, co po uporządkowaniu dwóch pierwszych spraw widać na wykresach zużycia zasobów.

Limit pamięci WordPressa można podnieść wierszem define( 'WP_MEMORY_LIMIT', '256M' ); w pliku wp-config.php, ale działa to tylko do wysokości limitu ustawionego przez hosting. Na hostingu współdzielonym o zmianę limitu pamięci i czasu wykonywania często trzeba poprosić obsługę, o czym wspomina również dokumentacja WordPressa.

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

• Usuwania wtyczek zamiast ich wyłączania. Usunięcie może skasować ustawienia i dane, a do diagnozy wystarczy zmiana nazwy katalogu.
• Przywracania kopii zapasowej jako pierwszej czynności. Jeśli przyczyna leży na serwerze, kopia niczego nie zmieni, a w sklepie cofnie zamówienia złożone po jej wykonaniu.
• Kupowania wyższego pakietu bez znajomości przyczyny. Większe zasoby nie usuną błędu w kodzie ani ruchu automatów.
• Pozostawiania włączonego trybu diagnostycznego i pliku debug.log na serwerze po zakończeniu prac.

Najczęstsze pytania

Czy błąd 502 może minąć sam?

Tak. Jeśli wywołało go chwilowe przeciążenie albo ponowne uruchomienie usługi na serwerze, strona wraca po kilku minutach bez żadnych działań. Jeżeli jednak błąd trwa dłużej niż kilkanaście minut albo powtarza się, nie należy czekać, tylko zebrać godziny wystąpień i sprawdzić dzienniki.

Strona działa, ale panel pokazuje 502. Co to oznacza?

Najczęściej odwiedzający otrzymują strony z pamięci podręcznej, a panel wymaga pracy PHP, która zawodzi. Należy sprawdzić dziennik błędów dla adresów zaczynających się od /wp-admin i zwrócić uwagę na plik admin-ajax.php. Często winna jest wtyczka, która wykonuje w panelu ciężkie zadanie w tle.

Czy zmiana wersji PHP może wywołać ten błąd?

Tak, na dwa sposoby. Sama zmiana wiąże się z ponownym uruchomieniem usługi i krótką przerwą. Trwały błąd po zmianie oznacza zwykle wtyczkę lub motyw niezgodne z nową wersją. Wtedy najprościej wrócić w panelu hostingu do poprzedniej wersji, zaktualizować wtyczki i motyw, a zmianę powtórzyć na kopii testowej.

Hosting twierdzi, że serwer działa poprawnie. Co dalej?

Należy poprosić o konkretne wiersze z dziennika błędów dla podanych godzin. Sama informacja, że serwer działa, nie wyjaśnia, dlaczego zgłosił 502. Jeśli w dzienniku widnieje przerwane połączenie z usługą PHP, kolejnym etapem jest próba z wyłączonymi wtyczkami i dziennik błędów WordPressa.

Czy pamięć podręczna stron chroni przed błędem 502?

W dużej mierze tak, bo zapisane strony są wysyłane bez udziału PHP, więc procesy nie wyczerpują się tak szybko. Nie chroni jednak panelu, koszyka, finalizacji zamówienia ani stron zalogowanych użytkowników, które zawsze są budowane na bieżąco. Pamięć podręczna ogranicza skutki, ale nie usuwa wadliwej wtyczki.

Czy przeniesienie strony na inny hosting rozwiąże problem?

Tylko wtedy, gdy przyczyna rzeczywiście leży po stronie serwera, co powinny potwierdzić dzienniki i odpowiedź obsługi. Jeśli błąd wywołuje wtyczka, motyw albo ruch automatów, witryna zabierze go ze sobą na nowy serwer. Przenosiny bez diagnozy to koszt i ryzyko bez pewności efektu.

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

Błąd 502 jest niewdzięczny, bo wymaga zaglądania w kilka miejsc naraz, a w tym czasie strona nie pracuje. Mogę zająć się tym od początku do końca: sprawdzę, gdzie i kiedy błąd się pojawia, przeczytam dzienniki serwera i WordPressa, ustalę, czy przyczyną jest hosting, sieć pośrednicząca, wtyczka, motyw czy nadmierny ruch automatów, a następnie ją usunę. Jeśli sprawa wymaga działania po stronie serwera, przygotuję zgłoszenie do firmy hostingowej i dopilnuję odpowiedzi. Na koniec sprawdzę w Google Search Console, czy awaria nie zostawiła śladów, i opiszę prostymi słowami, co się stało oraz jak uniknąć powtórki.

Wystarczy zadzwonić pod numer 533 525 168 albo napisać na adres info@lukaszwudyka.pl i podać adres strony oraz godzinę, o której błąd wystąpił. Odpowiem, co da się zrobić i od czego zacznę.