WORDPRESS网站500、502、503、504错误的4大罪魁祸首

Prowadzę kilkaWordPressStrona internetowa straciła kiedyś ponad 800 odwiedzin w ciągu jednego dnia z powodu błędu 502. Po trzech dniach śledztwa odkryto, że winowajcą jest niepozorne ustawienie w zapleczu.

Każdy, kto prowadzi witrynę opartą na WordPressie, wie, że najbardziej frustrującą rzeczą nie jest brak ruchu, ale sytuacja, gdy witryna nagle staje się niedostępna, a na ekranie pojawiają się niezrozumiałe błędy, takie jak 500, 502, 503 i 504.

Pomyślałeś, że serwer się zawiesił i pobiegłeś do dostawcy hostingu, by się z nim skontaktować, ale po sprawdzeniu okazało się, że serwer jest całkowicie sprawny.

Można pomyśleć, że to konflikt wtyczek, więc wyłączasz je i rozwiązujesz problemy po kolei, poświęcając temu większość dnia, ale błąd ciągle się powtarza.

Właściwie to nie musi być takie skomplikowane. Po wpadnięciu w niezliczone pułapki odkryłem, że 80% błędów 5xx na stronach WP nie uniknie tych 4 sprawców. Każdy z nich jest dobrze ukryty, ale może z łatwością zepsuć Twoją stronę.

Teraz wykorzystam własne doświadczenie praktyczne, aby wyraźnie wskazać te pułapki, dzięki czemu nawet początkujący będą mogli nadążać i rozwiązywać problemy, a Ty nigdy więcej nie będziesz musiał czuć się przytłoczony błędami.

Przyczyna nr 1: WP-CRON nie został wyłączony, co w istocie spowodowało powstanie „ukrytego źródła poboru energii” na stronie internetowej.

Wiele osób nie wie, że WordPress ma wbudowaną funkcję planowania zadań o nazwie WP-CRON, która jest domyślnie włączona.

Jego funkcje wydają się bardzo praktyczne, na przykład planowanie publikacji artykułów, automatyczne tworzenie kopii zapasowych, sprawdzanie aktualizacji wtyczek, a nawet wysyłanie przypomnień dla członków.

Ale czy wiesz, że ta pozornie użyteczna funkcja jest w rzeczywistości główną przyczyną zawieszania się serwerów i występowania błędów 5xx?

WP-CRON różni się od natywnego crona serwera. Nie działa proaktywnie, lecz jest aktywowany przez wizyty użytkowników. Za każdym razem, gdy użytkownik odwiedza Twoją witrynę, w ukryciu uruchamia plik /wp-cron.php, aby sprawdzić, czy są jakieś zaplanowane zadania do wykonania.

Oznacza to, że każda osoba odwiedzająca Twoją witrynę internetową dodaje „dodatkowe obciążenie”, a im więcej odwiedzających, tym obciążenie to staje się większe.

Miałem kiedyś stronę internetową, którą odwiedzało ponad tysiąc osób dziennie. Gdy WP-CRON nie był wyłączony, obciążenie procesora serwera często przekraczało 80%, a błędy 503 pojawiały się co najmniej dwa razy dziennie, a odwiedzający byli przekierowywani na stronę błędu zaraz po kliknięciu.

Co gorsza, nawet jeśli nie ustawisz żadnych zaplanowanych zadań, WP-CRON uruchomi się automatycznie, wielokrotnie żądając zasobów serwera. Z czasem serwer nie będzie w stanie obsłużyć obciążenia i zgłosi błąd.

Dokumentacja GitHub wyraźnie stwierdza: „Nieoczekiwany kod odpowiedzi HTTP: 500 lub wyższy. Oznacza to, że na serwerze wystąpił błąd uniemożliwiający uruchomienie generatora cron”. Oznacza to, że gdy WP-CRON nie działa prawidłowo, spowoduje to błąd serwera o wartości 500 lub wyższej.

Prawidłowym podejściem jest wyłączenie domyślnego WP-CRON i użycie natywnych zadań zaplanowanych serwera. Zapewni to prawidłowe wykonywanie zadań zaplanowanych przy jednoczesnym zmniejszeniu obciążenia serwera.

Jeżeli Twój serwer obsługuje polecenie curl, możesz bezpośrednio dodać zadanie zaplanowane w następujący sposób (zmodyfikuj je zgodnie z domeną swojej witryny):

*/15 * * * * curl https://www. 你的域名/wp-cron.php?doing_wp_cron > /dev/null 2>&1

To polecenie uruchamia zadanie WP-CRON co 15 minut i jest odpowiednie dla większości małych i średnich witryn internetowych. Jeśli Twoja witryna ma często zaplanowane zadania, możesz użyć również tego:

*/5 * * * * curl https://www. 你的域名/wp-cron.php?doing_wp_cron > /dev/null 2>&1

Po wyłączeniu WP-CRON i skonfigurowaniu zaplanowanych zadań na serwerze, obciążenie procesora spadło poniżej 30%, a przez cały miesiąc nie wystąpił żaden błąd 503. Wskaźnik retencji odwiedzających wzrósł również o 18%.

Przyczyna numer dwa: Powtarzające się zadania CRON i pozostałe pliki po odinstalowaniu wtyczki to w zasadzie „pozostawianie śmieci” na stronie internetowej.

Rozwiązanie problemu WP-CRON nie oznacza, że ​​możesz spać spokojnie; kryje się w nim ukryta pułapka, którą wielu właścicieli stron internetowych ignoruje.

Oznacza to, że zaplanowane zadania CRON są uruchamiane wielokrotnie lub że resztkowe zaplanowane zadania są nadal uruchamiane w ukryciu po odinstalowaniu wtyczki.

Czy kiedykolwiek przydarzyła Ci się taka sytuacja: odinstalowałeś wtyczkę do tworzenia kopii zapasowej, ale okazało się, że serwer nadal automatycznie tworzy kopie zapasowe każdego dnia, a nawet wyświetla komunikat o błędzie tworzenia kopii zapasowej, co ostatecznie prowadzi do błędu 500?

Jest to spowodowane pozostałymi zaplanowanymi zadaniami z wtyczki.

Na przykład, jeśli wtyczka generuje codzienne zaplanowane zadanie, WordPress będzie kontynuował jego wykonywanie nawet po odinstalowaniu wtyczki. Takie zaplanowane zadania są bezsensowne. Te bezsensowne, resztkowe zadania będą stale zużywać zasoby serwera i ostatecznie prowadzić do błędów.

Co gorsza, niektóre wtyczki automatycznie generują wiele powtarzających się zaplanowanych zadań. Na przykład zadanie „codziennego sprawdzania aktualizacji” może być tworzone pięć razy, a każde z nich będzie wykonywane zgodnie z harmonogramem, co oznacza, że ​​serwer musiałby przetwarzać pięć identycznych zadań jednocześnie.

Już kiedyś taki instalowałem.SEOPo odinstalowaniu wtyczki nie zauważyłem tego i pół miesiąca później strona regularnie zgłaszała błędy 504 przekroczenia limitu czasu. Dopiero po sprawdzeniu logów serwera odkryłem, że wtyczka pozostawiła trzy zaplanowane zadania dziennie, każde o czasie wykonania do 12 sekund. Jednoczesne uruchomienie tych trzech zadań bezpośrednio powodowało przekroczenie limitu czasu odpowiedzi serwera.

Jeszcze bardziej przerażające są te szczątkowe, powtarzalne zadania wykonywane w określonym czasie...Zaplecze WordPressJest niewidzialny; nie masz pojęcia, że ​​działa w ukryciu.

Istnieje jednak rozwiązanie: wtyczka WP-Crontrol doskonale sobie z tym radzi. To oficjalne narzędzie do zarządzania zadaniami Cron, rekomendowane przez WordPressa, które umożliwia przeglądanie, edycję i usuwanie wszystkich zaplanowanych zadań bezpośrednio w zapleczu.

Zgodnie z opisem wtyczki WordPress, WP-Crontrol może „wyświetlać wszystkie zaplanowane zdarzenia cron, edytować je, usuwać, wstrzymywać, wznawiać i natychmiast uruchamiać zdarzenia cron”. Innymi słowy, może wyświetlać wszystkie zaplanowane zadania i usuwać duplikaty lub nieprawidłowe zadania. Jest bardzo łatwy w użyciu i nie wymaga napisania ani jednej linijki kodu.

Po użyciu tej wtyczki do rozwiązywania problemów usunąłem 8 zduplikowanych zadań i 5 zadań resztkowych po wtyczce, a szybkość reakcji witryny poprawiła się bezpośrednio o 40%. Błąd 504 nigdy więcej się nie pojawił.

Uwaga: usuwając zadania, należy je dokładnie sprawdzić i unikać przypadkowego usunięcia podstawowych zaplanowanych zadań WordPressa, takich jak „wp_version_check” (sprawdzanie wersji). Przypadkowe usunięcie może uniemożliwić prawidłową aktualizację witryny.

Chociaż wtyczka WP-Crontrol umożliwia ręczne usuwanie zduplikowanych lub nieprawidłowych zadań, wymaga ręcznej interwencji, co nie jest idealnym rozwiązaniem...

Możemy jednak zautomatyzować ten proces za pomocą kodu WordrPress. Szczegóły znajdziesz w poniższym samouczku. ▼

🔗Wskazówki dotyczące przyspieszenia witryny WordPress: automatyczne usuwanie nieprawidłowych zaplanowanych zadań CRON

Winowajca nr 3: Nadmiarowe bazy danych w WordPressie

W WordPressie pojawia się następujący komunikat Błąd 500 Jednym z powodów jest redundancja bazy danych, zwłaszcza tabel danych o dużej pojemności generowanych przez niektóre wtyczki.

Podczas korzystania z wtyczki optymalizacyjnej WP zauważyłem, że niektóre tabele danych mają nienaturalnie duży rozmiar, wśród nich... Tabela konfiguracji Wordfence (wfconfig) Szczególnie widoczne.

Analiza problemu

• wfconfig ma poważną redundancję tabeli danych.Został już raz oczyszczony, ale bardzo szybko pojawił się ponownie.
• Problemy z domyślnym silnikiem pamięci masowejTabela konfiguracji Wordfence korzysta z domyślnego silnika InnoDB, który z czasem będzie gromadził setki MB powtarzających się danych.
• Wpływ na wydajnośćRozmiar tabel danych może z łatwością osiągnąć setki MB, co powoduje spadek szybkości ładowania strony internetowej, a nawet występowanie błędów 500.

Rozwiązanie

Dzieje się tak, ponieważ tabele danych skonfigurowane przez Wordfence korzystają z domyślnego silnika Inno. Z czasem dane te szybko się zbiorą, gromadząc setki megabajtów zbędnych danych, co negatywnie wpłynie na szybkość ładowania strony.

HestiaCPInstrukcje dotyczące zmiany domyślnego mechanizmu magazynującego MariaDB na MyISAM można znaleźć w poniższym samouczku:

Jak zmienić domyślny silnik bazy danych MariaDB na MyISAM w HestiaCP? Proste rozwiązanie w jednym kroku!

Czwarty winowajca: Błędy pojawiające się po aktualizacji wtyczek/motywów przypominają „nietypową operację chirurgiczną” na stronie internetowej.

Właściciele wielu stron internetowych mają zwyczaj natychmiastowego klikania przycisku „aktualizuj”, gdy widzą monity o aktualizację wtyczek lub motywów, wierząc, że aktualizacje naprawią luki w zabezpieczeniach i poprawią wydajność.

Prawda jest jednak zupełnie inna: wiele błędów 5xx jest spowodowanych aktualizacją wtyczek lub motywów.

Spotkałem się już z tym problemem. W zeszłym miesiącu zaktualizowałem swoją witrynę za pomocą popularnej wtyczki do tworzenia stron. Po kliknięciu „Aktualizuj” strona stała się pusta, a po odświeżeniu pojawił się błąd wewnętrzny serwera 500, uniemożliwiający dostęp do zaplecza.

Później odkryłem, że nowa wersja wtyczki była niezgodna z wersją PHP mojej strony. Po aktualizacji wtyczki kod nie mógł działać poprawnie, co bezpośrednio spowodowało zgłoszenie błędu przez serwer.

Błędy występujące po aktualizacji wtyczek lub motywów są częstą przyczyną błędów WordPress 500, szczególnie gdy nowa wersja wtyczki ma luki w kodzie lub powoduje konflikty z innymi wtyczkami lub motywami na stronie internetowej.

Innym scenariuszem jest to, że po uaktualnieniu motywu poprzedni niestandardowy kod zostanie nadpisany, co spowoduje zaburzenie układu witryny i awarię funkcji, co z kolei doprowadzi do błędów 502 i 503.

zrób cośE-commerceU niektórych użytkowników, po aktualizacji wtyczki WooCommerce, na ich stronach internetowych pojawiał się błąd 502, uniemożliwiający składanie zamówień. Spowodowało to utratę ponad 2000 sprzedaży w ciągu zaledwie 3 godzin, a rozwiązanie problemu zajęło całe popołudnie.

W rzeczywistości najbardziej bezpośrednim i skutecznym rozwiązaniem tej sytuacji jest powrót do poprzedniej wersji, która działała poprawnie.

Wiele osób nie wie, jak przywrócić poprzednią wersję, ale nie trzeba ręcznie pobierać ani przesyłać plików; wtyczka WP Rollback bardzo to ułatwia.

Według opisu WordPressa, wtyczka WP Rollback umożliwia „szybkie i łatwe przywrócenie dowolnego motywu lub wtyczki z wordpress.org do dowolnej poprzedniej (lub nowszej) wersji bez konieczności ręcznego wprowadzania zmian”. Innymi słowy, umożliwia przywrócenie wtyczek lub motywów do dowolnej poprzedniej wersji jednym kliknięciem, bez skomplikowanych operacji, co ułatwia korzystanie z niej nawet początkującym.

Po nieudanej aktualizacji mojej ostatniej wtyczki, skorzystałem z WP Rollback, aby jednym kliknięciem przywrócić poprzednią wersję. Strona wróciła do normy w zaledwie 30 sekund, a żadne dane nie zostały utracone.

Oto sugestia: przed aktualizacją wtyczek lub motywów zawsze najpierw wykonaj kopię zapasową swojej witryny. Najlepiej najpierw przetestować ją w środowisku testowym, aby upewnić się, że nie ma problemów przed aktualizacją na oficjalnej stronie, i uniknąć błędów.

Podsumowanie: Opanuj te 3 punkty, aby całkowicie pożegnać się z błędami 5xx na stronie WP.

Podczas prowadzenia witryny WordPress błędy 500, 502, 503 i 504 działają jak „przeszkody” – pozornie uciążliwe, ale ich główna przyczyna jest całkiem jasna: nie chodzi o awarię serwera ani o poważną awarię programu witryny, ale o to, że przeoczyliśmy trzy szczegóły: WP-CRON, pozostałe zaplanowane zadania oraz aktualizacje wtyczek/motywów.

Jako właściciel witryny WordPress, który początkowo był przytłoczony błędami, a teraz jest w stanie szybko rozwiązywać problemy i rozwiązywać wszystkie błędy 5xx, moim największym wnioskiem jest to, że stabilne działanie witryny nie polega na „zamykaniu drzwi stajni po ucieczce konia”, ale raczej na zasadzie „lepiej zapobiegać niż leczyć”.

Właściciele wielu stron internetowych uważają, że te drobne szczegóły nie mają znaczenia i żałują, że nie sprawdzili ich wcześniej, dopiero gdy strona przestaje działać prawidłowo, traci ruch lub traci dochody.

Ważne jest, aby zrozumieć, że dla witryny internetowej „stabilność” jest podstawową przewagą konkurencyjną. Pojedynczy błąd 5xx może spowodować utratę 10% odwiedzających, a wiele błędów może nawet doprowadzić do spadku pozycji w wynikach wyszukiwania, przez co wszystkie dotychczasowe działania SEO pójdą na marne.

Jak głosi przysłowie: „Tysiącmilowa tama może zostać przerwana przez mrowisko”. Błędy 5xx na stronie WP nigdy nie pojawiają się nagle, lecz są wynikiem nagromadzenia drobnych problemów – nieaktywnego WP-CRON, resztkowych zaplanowanych zadań i pośpiesznych aktualizacji. Te pozornie nieistotne „mrowiskowce” ostatecznie zniszczą „groblę” całej witryny.

Naprawdę efektywne działanie oznacza rozwiązywanie problemów w zarodku.

1. Wyłącz domyślny WP-CRON i zastąp go zaplanowanym zadaniem na serwerze;
2. Regularnie używaj WP-Crontrol do usuwania powtarzających się i resztkowych zaplanowanych zadań;
3. Przed uaktualnieniem wtyczek lub motywów należy wykonać kopię zapasową danych, a w przypadku wystąpienia błędów natychmiast przywrócić poprzednią wersję.

Te trzy operacje nie wymagają skomplikowanej technologii ani drogich programistów i nawet początkujący mogą je z łatwością opanować, a przy tym mogą uchronić Twoją witrynę przed błędami 5xx i zapewnić jej stabilne działanie.

Każde stabilne obciążenie Twojej strony internetowej i każda wizyta odwiedzającego jest cennym zasobem, który gromadzisz z czasem.

Od teraz zidentyfikuj te trzy przyczyny i wykonuj codzienną konserwację, aby mieć pewność, że Twoja witryna WordPress nie tylko wytrzyma Twoją ciężką pracę, ale także będzie stale zwiększać ruch i przychody.

Jeśli obecnie borykasz się z błędami 5xx, spróbuj wykonać kroki opisane w tym artykule, aby je rozwiązać. Wierzę, że wkrótce uda Ci się pozbyć tych problemów, zapewnić stabilne działanie Twojej witryny i osiągnąć długoterminowy wzrost.