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

Аз управлявам няколкоWordPressВеднъж уебсайтът загуби повече от 800 посещения за един ден поради грешка 502. След тридневно разследване беше установено, че виновникът е незабележима настройка в backend-а.

Всеки, който управлява уебсайт с WordPress, знае, че най-разочароващото нещо не е липсата на трафик, а когато уебсайтът внезапно стане недостъпен, с нечетливи грешки като 500, 502, 503 и 504, изскачащи на екрана.

Мислехте, че сървърът е сринал и се втурнахте да спорите с доставчика на хостинг услуги, само за да разберете, след като те провериха, че сървърът е напълно нормален.

Може да си помислите, че е конфликт на плъгини, така че деактивирате и отстранявате неизправности един по един, прекарвайки по-голямата част от деня в това, но грешката продължава да се повтаря.

Всъщност, не е нужно да е толкова сложно. След като попаднах в безброй капани, открих, че 80% от грешките на WP уебсайтове 5xx не могат да избегнат тези 3 виновника. Всяка от тях е добре скрита, но може лесно да съсипе уебсайта ви.

Сега ще използвам собствения си практически опит, за да разкрия ясно тези капани, така че дори начинаещите да могат да следват и да отстраняват проблеми и никога повече няма да се налага да бъдете объркани от грешки.

Виновник №1: WP-CRON не е бил деактивиран, което по същество е инсталирало „скрито източване на енергия“ на уебсайта.

Много хора не знаят, че WordPress има вградена функция за планирани задачи, наречена WP-CRON, която е активирана по подразбиране.

Функциите му звучат много практично, като например планиране на публикуване на статии, автоматично архивиране, проверка за актуализации на плъгини и дори изпращане на напомняния до членовете.

Но знаехте ли, че тази на пръв поглед полезна функция всъщност е виновник номер едно, който срива сървърите и причинява 5xx грешки?

WP-CRON е различен от родния Cron на сървъра. Той не се изпълнява проактивно, а се задейства от потребителски посещения. Всеки път, когато потребител посети вашия уебсайт, той тайно ще изпълни файла /wp-cron.php, за да провери дали има планирани задачи за изпълнение.

Това означава, че всеки посетител на вашия уебсайт добавя „допълнително бреме“ и колкото повече посетители имате, толкова по-тежко става бремето.

Имах уебсайт, който получаваше над хиляда посетители на ден. Когато WP-CRON не беше деактивиран, натоварването на процесора на сървъра често скачаше до над 80% и имаше поне две грешки 503 всеки ден, като посетителите бяха пренасочвани към страница за грешка веднага щом кликнат върху нея.

Още по-лошото е, че дори и да не зададете никакви планирани задачи, WP-CRON ще се изпълнява автоматично, многократно изисквайки сървърни ресурси. С течение на времето сървърът няма да може да се справи с натоварването и ще докладва грешка.

Документацията на GitHub ясно посочва: „Неочакван HTTP код за отговор: 500 или по-висок, това означава, че на вашия сървър е възникнала грешка, която пречи на стартирането на cron spawner-а.“ Това означава, че когато WP-CRON не функционира правилно, това ще доведе до грешка на сървъра от 500 или по-висок.

Правилният подход е да деактивирате WP-CRON по подразбиране и вместо това да използвате вградените в сървъра планирани задачи. Това ще гарантира, че планираните задачи ще се изпълняват нормално, като същевременно ще намали натоварването на сървъра.

Ако вашият сървър поддържа командата curl, можете директно да добавите планирана задача по следния начин (модифициране според домейна на вашия уебсайт):

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

Тази команда изпълнява WP-CRON задача на всеки 15 минути, подходяща за повечето малки и средни уебсайтове; ако вашият уебсайт има чести планирани задачи, можете да използвате и това:

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

След като деактивирах WP-CRON и настроих планирани задачи на сървъра, натоварването на процесора на сървъра падна под 30% и нямаше грешки 503 за цял месец. Процентът на задържане на посетители също се увеличи с 18%.

Виновник номер две: Повтарящите се CRON планирани задачи и остатъчните файлове след деинсталирането на плъгина по същество „оставят боклуци“ на уебсайта.

Решаването на проблема с WP-CRON не означава, че можете да бъдете спокойни; има скрит капан, който много собственици на уебсайтове пренебрегват.

Това означава, че планираните CRON задачи се изпълняват многократно или че остатъчни планирани задачи все още се изпълняват тайно след деинсталирането на плъгина.

Случвало ли ви се е да се сблъскате с това: деинсталирате плъгин за архивиране, но установите, че сървърът все още автоматично архивира всеки ден или дори показва съобщение за неуспех при архивиране, което в крайна сметка води до грешка 500?

Това се дължи на остатъчните планирани задачи от плъгина.

Например, ако даден плъгин генерира ежедневна планирана задача, WordPress ще продължи да изпълнява тази задача дори след деинсталирането на плъгина. Такива планирани задачи са безсмислени. Тези безсмислени остатъчни задачи непрекъснато ще консумират сървърни ресурси и в крайна сметка ще доведат до грешки.

Още по-лошо е, че някои плъгини автоматично генерират множество повтарящи се планирани задачи. Например, задача за „ежедневна проверка на актуализации“ може да бъде създадена пет пъти и всяка от тях ще се изпълнява по график, което означава, че сървърът ще трябва да обработва пет еднакви задачи едновременно.

Инсталирах един преди.SEO РангСлед като деинсталирах плъгина, не го забелязах и половин месец по-късно уебсайтът често се сблъскваше с грешки 504 timeout. Едва след проверка на сървърните логове открих, че плъгинът е оставил след себе си три ежедневно планирани задачи, всяка с време за изпълнение до 12 секунди. Едновременното изпълнение на трите директно доведе до изтичане на времето за отговор на сървъра.

Още по-плашещо е, че тези остатъчни, повтарящи се задачи с ограничено време...Бекенд на WordPressНевидимо е; нямате представа, че работи тайно.

Има обаче решение: плъгинът WP-Crontrol може да се справи перфектно с това. Това е официалният инструмент за управление на Cron задачи, препоръчан от WordPress, който ви позволява да преглеждате, редактирате и изтривате всички планирани задачи директно в backend-а.

Според описанието на плъгина за WordPress, WP-Crontrol може да „преглежда всички планирани cron събития, да редактира, изтрива, поставя на пауза, възобновява и незабавно да изпълнява cron събития“. С други думи, може да преглежда всички планирани задачи и да изтрива дублирани или невалидни задачи. Много е лесен за използване и не изисква писане на нито един ред код.

След като използвах този плъгин за отстраняване на неизправности, изтрих 8 дублиращи се задачи и 5 остатъчни задачи от плъгина, а скоростта на реакция на уебсайта се подобри директно с 40%. Грешка 504 никога повече не се появи.

Едно предупреждение: когато изтривате задачи, не забравяйте да проверите внимателно и да избегнете случайно изтриване на основни планирани задачи на WordPress, като например „wp_version_check“ (проверка на версията). Случайното изтриване може да попречи на правилното актуализиране на уебсайта.

Въпреки че плъгинът WP-Crontrol може ръчно да изтрива дублирани или невалидни задачи, той изисква ръчна намеса, което не е идеално...

Въпреки това, можем да автоматизираме този процес, използвайки код на WordPress. Вижте урока по-долу за подробности. ▼

🔗Съвети за ускоряване на уебсайтове на WordPress: Автоматично премахване на невалидни планирани CRON задачи

Виновник номер три: Грешките след актуализации на плъгини/теми са като извършване на „неортодоксална хирургия“ на уебсайт.

Много собственици на уебсайтове имат навика веднага да кликват върху „актуализиране“, когато видят подкани за актуализиране на плъгини или теми, вярвайки, че актуализациите ще отстранят уязвимостите и ще подобрят производителността.

Но истината е точно обратната; много 5xx грешки са причинени от актуализиране на плъгини или теми.

Сблъсквал съм се с този проблем и преди. Миналия месец обнових уебсайта си с популярен плъгин за изграждане на страници. След като щракнах върху „актуализиране“, страницата стана празна и след обновяване се появи грешка 500 Internal Server Error, което направи достъпа до backend-а невъзможен.

По-късно разбрах, че новата версия на плъгина е несъвместима с PHP версията на моя уебсайт. След актуализацията на плъгина, кодът не можеше да работи правилно, което директно доведе до грешка от сървъра.

Грешки след актуализации на плъгини или теми са честа причина за грешки в WordPress 500, особено когато новата версия на плъгина има уязвимости в кода или конфликти с други плъгини или теми на уебсайта.

Друг сценарий е, че след надграждане на темата, предишният персонализиран код ще бъде презаписан, което ще доведе до неподредено оформление на уебсайта и неуспех на функциите, което от своя страна води до грешки 502 и 503.

имам какво да направяЕлектричество доставчикаСлед обновяване на плъгина WooCommerce, някои потребители са имали грешки 502 в уебсайтовете си, което е направило невъзможно извършването на поръчки. Това е довело до загуба на над 2000 продажби само в рамките на 3 часа и е отнело цял следобед, за да се разреши проблемът.

Всъщност, най-директното и ефективно решение на тази ситуация е да се върнете към предишна версия, която е работила правилно.

Много хора не знаят как да се върнат към предишното си състояние, но не е нужно ръчно да изтегляте или качвате файлове; плъгинът WP Rollback го улеснява.

Според описанието на WordPress, плъгинът WP Rollback може „бързо и лесно да върне всяка тема или плъгин от wordpress.org към всяка предишна (или по-нова) версия без никаква ръчна суета“. С други думи, той може да върне плъгини или теми към всяка предишна версия с едно щракване, без сложни операции, което го прави лесен за употреба от начинаещи.

След като последното ми обновяване на плъгина се провали, използвах WP Rollback, за да се върна към предишната версия с едно щракване. Уебсайтът се върна към нормалното си състояние само за 30 секунди и не бяха загубени никакви данни.

Ето едно предложение: преди да надстроите плъгини или теми, винаги първо правете резервно копие на уебсайта си. Най-добре е първо да го тествате в тестова среда, за да се уверите, че няма проблеми, преди да го актуализирате на официалния уебсайт, за да избегнете грешки.

Заключение: Овладейте тези 3 точки, за да се сбогувате напълно с грешките 5xx на WP уебсайта.

При стартиране на уебсайт с WordPress, грешките 500, 502, 503 и 504 са като „препятствия“, на пръв поглед обезпокоителни, но основната причина всъщност е съвсем ясна – не е, че сървърът е повреден, нито има сериозен проблем с програмата на уебсайта, а по-скоро, че сме пропуснали три детайла: WP-CRON, остатъчни планирани задачи и надстройки на плъгини/теми.

Като собственик на WordPress уебсайт, от това, че в началото бях затрупан с грешки, до това сега да мога бързо да отстранявам и разрешавам всички 5xx грешки, най-важното ми заключение е, че работата на уебсайта на конюшнята не разчита на „заключване на вратата на конюшнята, след като конят е избягал“, а по-скоро на „по-добре е да се предотврати, отколкото да се лекува“.

Много собственици на уебсайтове смятат, че тези малки детайли са маловажни и съжаляват, че не са ги проверили предварително, само когато уебсайтът не работи правилно, губи трафик и претърпява загуба на приходи.

Важно е да се разбере, че за един уебсайт „стабилността“ е основното конкурентно предимство. Една единствена грешка 5xx може да доведе до загуба на 10% от посетителите ви, а множество грешки могат дори да доведат до спад в класирането в търсачките, което ще направи всички ваши предишни SEO усилия напразни.

Както се казва, „Хилядамилен диг може да бъде пробита от мравуняк“. Грешките 5xx на WP уебсайта никога не се появяват внезапно, а са резултат от натрупването на малки проблеми – недеактивиран WP-CRON, остатъчни планирани задачи и прибързани операции по надграждане. Тези на пръв поглед незначителни „мравуняци“ в крайна сметка ще унищожат „дигата“ на целия уебсайт.

Наистина ефективните операции означават пресичане на проблемите в зародиш.

1. Деактивирайте WP-CRON по подразбиране и го заменете със сървърно-базирана планирана задача;
2. Редовно използвайте WP-Crontrol за почистване на повтарящи се и остатъчни планирани задачи;
3. Не забравяйте да архивирате данните си, преди да надстроите плъгини или теми, и незабавно се върнете към предишната версия, ако възникнат грешки.

Тези три операции не изискват сложна технология или скъпи разработчици и дори начинаещите могат лесно да ги овладеят, но въпреки това могат да предпазят уебсайта ви от грешки 5xx и да поддържат стабилна работа.

Всяко стабилно зареждане на вашия уебсайт и всеки престой на посетител е ценен актив, който натрупвате с течение на времето.

Отсега нататък, идентифицирайте тези три виновника и извършвайте ежедневна поддръжка, за да сте сигурни, че вашият WordPress уебсайт може не само да понесе упоритата ви работа, но и постоянно да увеличава трафика и приходите.

Ако в момента изпитвате проблеми с грешки 5xx, опитайте да следвате стъпките в тази статия, за да ги отстраните. Вярвам, че скоро ще можете да се отървете от тези проблеми, да накарате уебсайта си да работи стабилно и да постигнете дългосрочен растеж.