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

Es pārvaldu vairākusWordPressReiz vietne zaudēja vairāk nekā 800 apmeklējumu vienas dienas laikā 502 kļūdas dēļ. Pēc trīs dienu izmeklēšanas tika atklāts, ka vaininieks ir neuzkrītošs iestatījums servera aizmugurē.

Ikviens, kurš pārvalda WordPress vietni, zina, ka visnepatīkamākais nav apmeklētāju skaita trūkums, bet gan tas, kad vietne pēkšņi kļūst nepieejama un ekrānā parādās tādas kļūdainas kļūdas kā 500, 502, 503 un 504.

Jūs domājāt, ka serveris ir avarējis, un steidzāties strīdēties ar mitināšanas pakalpojumu sniedzēju, tikai lai pēc tam, kad viņi pārbaudīja, uzzinātu, ka serveris ir pilnīgi normāls.

Jums varētu šķist, ka tas ir spraudņu konflikts, tāpēc jūs tos atspējojat un novēršat problēmas pa vienam, pavadot tam lielāko dienas daļu, taču kļūda turpina atkārtoties.

Patiesībā tam nav jābūt tik sarežģītam. Pēc iekrišanas neskaitāmos slazdos es atklāju, ka 80% WP vietņu 5xx kļūdu nevar izvairīties no šiem 4 vaininiekiem. Katrs no tiem ir labi paslēpts, taču tas var viegli sabojāt jūsu vietni.

Tagad es izmantošu savu praktisko pieredzi, lai skaidri atklātu šīs kļūdas, lai pat iesācēji varētu sekot līdzi un novērst problēmas, un jums vairs nekad nebūs jācieš no kļūdām.

Vainīgais Nr. 1: WP-CRON netika atspējots, būtībā vietnē uzstādot "slēptu enerģijas noteci".

Daudzi cilvēki nezina, ka WordPress ir iebūvēta plānoto uzdevumu funkcija ar nosaukumu WP-CRON, kas pēc noklusējuma ir iespējota.

Tās funkcijas izklausās ļoti praktiskas, piemēram, rakstu publicēšanas plānošana, automātiska dublēšana, spraudņu atjauninājumu pārbaude un pat atgādinājumu sūtīšana biedriem.

Bet vai jūs zinājāt, ka šī šķietami noderīgā funkcija patiesībā ir galvenais vaininieks serveru avārijās un 5xx kļūdu rašanās procesā?

WP-CRON atšķiras no servera iebūvētā Cron. Tas nedarbojas proaktīvi, bet gan tiek aktivizēts atkarībā no lietotāju apmeklējumiem. Katru reizi, kad lietotājs apmeklē jūsu vietni, tas slepeni izpildīs failu /wp-cron.php, lai pārbaudītu, vai ir kādi ieplānoti uzdevumi, kas jāpaveic.

Tas nozīmē, ka katrs jūsu vietnes apmeklētājs rada "papildu slogu", un jo vairāk apmeklētāju jums ir, jo lielāks kļūst šis slogs.

Man kādreiz bija tīmekļa vietne, kuru dienā apmeklēja vairāk nekā tūkstotis apmeklētāju. Kad WP-CRON nebija atspējots, servera centrālā procesora noslodze bieži pieauga līdz vairāk nekā 80%, un katru dienu bija vismaz divas 503 kļūdas, un apmeklētāji tika novirzīti uz kļūdas lapu, tiklīdz viņi uz tās noklikšķināja.

Vēl sliktāk ir tas, ka pat ja neiestatīsiet nekādus ieplānotus uzdevumus, WP-CRON darbosies automātiski, atkārtoti pieprasot servera resursus. Laika gaitā serveris nespēs tikt galā ar slodzi un ziņos par kļūdu.

GitHub dokumentācijā ir skaidri norādīts: "Negaidīts HTTP atbildes kods: 500 vai augstāks, tas nozīmē, ka jūsu serverī ir radusies kļūda, kas neļauj darboties cron spawner." Tas nozīmē, ka, ja WP-CRON nedarbojas pareizi, tas izraisīs servera kļūdu 500 vai augstāku.

Pareizā pieeja ir atspējot noklusējuma WP-CRON un tā vietā izmantot servera iebūvētos plānotos uzdevumus. Tas nodrošinās, ka plānotie uzdevumi tiks izpildīti normāli, vienlaikus samazinot servera slodzi.

Ja jūsu serveris atbalsta komandu curl, varat tieši pievienot ieplānotu uzdevumu, piemēram, šo (modificējiet atbilstoši savas vietnes domēnam):

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

Šī komanda izpilda WP-CRON uzdevumu ik pēc 15 minūtēm, kas ir piemērots lielākajai daļai mazu un vidēju vietņu; ja jūsu vietnei ir bieži ieplānoti uzdevumi, varat izmantot arī šo:

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

Pēc tam, kad atspējoju WP-CRON un serverī iestatīju plānotos uzdevumus, servera centrālā procesora noslodze samazinājās līdz zem 30%, un veselu mēnesi nebija 503 kļūdu. Apmeklētāju noturības rādītājs arī palielinājās par 18%.

Otrais vaininieks: atkārtoti CRON ieplānotie uzdevumi un atlikušie faili pēc spraudņa atinstalēšanas būtībā "atstāj nevēlamu saturu" vietnē.

WP-CRON problēmas atrisināšana nenozīmē, ka varat justies mierīgi; pastāv slēpta kļūme, ko daudzi vietņu īpašnieki nepamana.

Tas nozīmē, ka CRON ieplānotie uzdevumi tiek izpildīti atkārtoti vai arī pēc spraudņa atinstalēšanas joprojām slepeni darbojas atlikušie ieplānotie uzdevumi.

Vai esat kādreiz saskāries ar šādu situāciju: atinstalējāt dublēšanas spraudni, bet atklājāt, ka serveris joprojām automātiski veido dublējumu katru dienu vai pat parāda dublēšanas kļūmes ziņojumu, kas galu galā noved pie 500 kļūdas?

To izraisa atlikušie ieplānotie uzdevumi no spraudņa.

Piemēram, ja spraudnis ģenerē ikdienas ieplānotu uzdevumu, WordPress turpinās izpildīt šo uzdevumu pat pēc spraudņa atinstalēšanas. Šādi ieplānotie uzdevumi ir bezjēdzīgi. Šie bezjēdzīgie atlikušie uzdevumi nepārtraukti patērēs servera resursus un galu galā novedīs pie kļūdām.

Vēl ļaunāk, daži spraudņi automātiski ģenerē vairākus atkārtotus ieplānotus uzdevumus. Piemēram, uzdevums "ikdienas atjauninājumu pārbaude" varētu tikt izveidots piecas reizes, un katrs no tiem tiktu izpildīts pēc grafika, kas nozīmē, ka serverim vienlaikus būtu jāapstrādā pieci identiski uzdevumi.

Es vienu iepriekš instalēju.SEOPēc spraudņa atinstalēšanas es to nepamanīju, un pusmēnesi vēlāk vietne bieži saskārās ar 504 taimauta kļūdām. Tikai pēc servera žurnālu pārbaudes es atklāju, ka spraudnis bija atstājis aiz sevis trīs ikdienas plānotos uzdevumus, katru ar izpildes laiku līdz 12 sekundēm. Šo trīs uzdevumu vienlaicīga darbība tieši izraisīja servera atbildes taimautu.

Vēl biedējošāk ir tas, ka šie atlikušie, atkārtotie laika ziņā ierobežotie uzdevumi...WordPress aizmugursistēmaTas ir neredzams; jums nav ne jausmas, ka tas darbojas slepeni.

Tomēr ir risinājums: WP-Crontrol spraudnis ar to lieliski tiek galā. Tas ir oficiālais Cron uzdevumu pārvaldības rīks, ko iesaka WordPress, kas ļauj skatīt, rediģēt un dzēst visus ieplānotos uzdevumus tieši servera aizmugurē.

Saskaņā ar WordPress spraudņa aprakstu, WP-Crontrol var "skatīt visus plānotos cron notikumus, rediģēt, dzēst, apturēt, atsākt un nekavējoties palaist cron notikumus". Citiem vārdiem sakot, tas var skatīt visus plānotos uzdevumus un dzēst dublētus vai nederīgus uzdevumus. To ir ļoti viegli lietot, un nav nepieciešams uzrakstīt nevienu koda rindiņu.

Pēc šī spraudņa izmantošanas problēmu novēršanai es izdzēsu 8 dublētus uzdevumus un 5 spraudņa atlikušos uzdevumus, un vietnes reakcijas ātrums uzlabojās tieši par 40%. 504 kļūda vairs neradās.

Neliels brīdinājums: dzēšot uzdevumus, rūpīgi pārbaudiet tos un izvairieties no nejaušas WordPress ieplānoto uzdevumu, piemēram, "wp_version_check" (versijas pārbaude), dzēšanas. Nejauša dzēšana var traucēt vietnes pareizu atjaunināšanu.

Lai gan WP-Crontrol spraudnis var manuāli izdzēst dublētus vai nederīgus uzdevumus, tam nepieciešama manuāla iejaukšanās, kas nav ideāli...

Tomēr mēs varam automatizēt šo procesu, izmantojot WordrPress kodu. Sīkāku informāciju skatiet tālāk sniegtajā pamācībā. ▼

🔗WordPress vietnes paātrināšanas padomi: automātiski noņemiet nederīgus CRON ieplānotos uzdevumus

Vainīgais Nr. 3: liekās datubāzes pakalpojumā WordPress

WordPress programmā parādās sekojošais 500 Kļūda Viens no iemesliem ir datubāzes dublēšana, īpaši lielas ietilpības datu tabulas, ko ģenerē noteikti spraudņi.

Izmantojot WP optimizācijas spraudni, es atklāju, ka dažas datu tabulas bija neparasti lielas, starp kurām... Wordfence konfigurācijas tabula (wfconfig) Īpaši ievērojams.

Problēmu analīze

• wfconfig ir nopietna datu tabulu dublēšana.Tas jau vienreiz tika iztīrīts, bet ļoti ātri atkal parādījās.
• Noklusējuma krātuves dzinēja problēmasWordfence konfigurācijas tabulā tiek izmantota noklusējuma InnoDB programma, kas laika gaitā uzkrās simtiem MB lieku datu.
• Ietekme uz veiktspējuDatu tabulas var viegli sasniegt simtiem MB lielumu, izraisot vietnes ielādes ātruma samazināšanos un pat 500 kļūdu rašanos.

Risinājums

Tas ir tāpēc, ka Wordfence konfigurētās datu tabulas izmanto noklusējuma Inno dzinēju. Laika gaitā tas ātri uzkrās simtiem megabaitu lieku datu, ietekmējot vietnes ielādes ātrumu.

HestiaCPNorādījumus par MariaDB noklusējuma krātuves dzinēja maiņu uz MyISAM skatiet šajā pamācībā:

Kā HestiaCP mainīt MariaDB noklusējuma krātuves dzinēju uz MyISAM? Vienkāršs risinājums, veicot tikai vienu soli!

Ceturtais vaininieks: Kļūdas pēc spraudņu/tēmu jaunināšanas ir kā "neparastas operācijas" veikšana vietnē.

Daudziem vietņu īpašniekiem ir ieradums nekavējoties noklikšķināt uz “atjaunināt”, kad viņi redz atjaunināšanas uzvednes spraudņiem vai tēmām, uzskatot, ka atjauninājumi novērsīs ievainojamības un uzlabos veiktspēju.

Taču patiesība ir gluži pretēja; daudzas 5xx kļūdas rodas, atjauninot spraudņus vai tēmas.

Esmu jau iepriekš saskāries ar šo problēmu. Pagājušajā mēnesī es jaunināju savu vietni ar populāru lapu veidotāja spraudni. Pēc noklikšķināšanas uz “Atjaunināt” lapa kļuva tukša, un pēc atsvaidzināšanas parādījās 500 iekšējā servera kļūda, kas liedza piekļuvi aizmugursistēmai.

Vēlāk es atklāju, ka jaunā spraudņa versija nebija saderīga ar manas vietnes PHP versiju. Pēc spraudņa atjaunināšanas kods nevarēja pareizi darboties, kas tieši izraisīja servera kļūdas ziņojumu.

Kļūdas pēc spraudņu vai motīvu jaunināšanas ir bieži sastopams WordPress 500 kļūdu cēlonis, īpaši, ja spraudņa jaunajai versijai ir koda ievainojamības vai tā konfliktē ar citiem vietnes spraudņiem vai tēmām.

Cits scenārijs ir tāds, ka pēc tēmas jaunināšanas iepriekšējais pielāgotais kods tiks pārrakstīts, kā rezultātā vietnes izkārtojums kļūs nesakārtots un funkcijas nedarbosies, kas savukārt novedīs pie 502 un 503 kļūdām.

darītE-komercijaDažiem lietotājiem pēc WooCommerce spraudņa jaunināšanas viņu vietnēs radās 502 kļūdas, kuru dēļ pasūtījumu veikšana nebija iespējama. Tā rezultātā tikai 3 stundu laikā tika zaudēti vairāk nekā 2000 pārdošanas apjomu, un problēmas novēršanai bija nepieciešama vesela pēcpusdiena.

Patiesībā vistiešākais un efektīvākais risinājums šai situācijai ir atgriezties pie iepriekšējās versijas, kas darbojās pareizi.

Daudzi cilvēki nezina, kā atgriezties iepriekšējā stāvoklī, taču jums nav manuāli jālejupielādē vai jāaugšupielādē faili; WP Rollback spraudnis to padara vienkāršu.

Saskaņā ar WordPress aprakstu, WP Rollback spraudnis var "ātri un vienkārši atgriezt jebkuru tēmu vai spraudni no wordpress.org uz jebkuru iepriekšējo (vai jaunāku) versiju bez jebkādas manuālas piepūles". Citiem vārdiem sakot, tas var atgriezt spraudņus vai tēmas uz jebkuru iepriekšējo versiju ar vienu klikšķi, bez sarežģītām darbībām, padarot to viegli lietojamu iesācējiem.

Pēc tam, kad mana pēdējā spraudņa jaunināšana neizdevās, es izmantoju WP Rollback, lai ar vienu klikšķi atgrieztos iepriekšējā versijā. Vietne atgriezās normālā stāvoklī tikai 30 sekundēs, un dati netika zaudēti.

Šeit ir ieteikums: pirms spraudņu vai tēmu jaunināšanas vienmēr vispirms izveidojiet savas vietnes dublējumu. Vislabāk ir to vispirms pārbaudīt testa vidē, lai pārliecinātos, ka pirms atjaunināšanas oficiālajā vietnē nerodas problēmas un izvairītos no kļūdām.

Secinājums: Apgūstiet šos 3 punktus, lai pilnībā atvadītos no WP vietnes 5xx kļūdām.

WordPress vietnes darbības laikā 500., 502., 503. un 504. kļūdas ir kā "šķēršļi", šķietami traucējošas, taču to pamatcēlonis patiesībā ir diezgan skaidrs — ne serveris ir bojāts, ne arī vietnes programma ir nopietni bojāta, bet gan tas, ka esam nepamanījuši trīs detaļas: WP-CRON, atlikušos ieplānotos uzdevumus un spraudņu/tēmu jauninājumus.

Kā WordPress vietnes īpašniekam, no sākuma, kad mani pārņēma kļūdu pārslodze, līdz tagad, kad varu ātri novērst un atrisināt visas 5xx kļūdas, mana lielākā atziņa ir tāda, ka stabila vietnes darbība nav atkarīga no "staļļa durvju aizslēgšanas pēc tam, kad zirgs ir aizbēdzis", bet gan no "labāk novērst nekā ārstēt".

Daudzi vietņu īpašnieki uzskata, ka šīs mazās detaļas nav svarīgas, un nožēlo, ka tās iepriekš nepārbaudīja, tikai tad, kad vietne nedarbojas pareizi, zaudē apmeklētāju skaitu un cieš ieņēmumu zaudējumus.

Ir svarīgi saprast, ka tīmekļa vietnei "stabilitāte" ir galvenā konkurences priekšrocība. Viena 5xx kļūda var izraisīt 10% apmeklētāju zaudēšanu, un vairākas kļūdas var pat izraisīt meklētājprogrammu ranga kritumu, padarot visus iepriekšējos SEO centienus veltīgus.

Kā vēsta teiciens: "Tūkstoš jūdžu garu dambi var pārraut skudru caurums." WP vietnes 5xx kļūdas nekad nerodas pēkšņi, bet gan ir mazu problēmu uzkrāšanās rezultāts — neatspējots WP-CRON, atlikušie ieplānotie uzdevumi un sasteigtas jaunināšanas operācijas. Šie šķietami nenozīmīgie "skudru caurumi" galu galā iznīcinās visas vietnes "dambi".

Patiesi efektīva darbība nozīmē problēmu risināšanu jau pašā sākumā.

1. Atspējojiet noklusējuma WP-CRON un aizstājiet to ar serverī balstītu ieplānotu uzdevumu;
2. Regulāri izmantojiet WP-Crontrol, lai attīrītu atkārtotus un atlikušos ieplānotos uzdevumus;
3. Pirms spraudņu vai tēmu jaunināšanas noteikti dublējiet datus un nekavējoties atgriezieties pie iepriekšējām versijām, ja rodas kļūdas.

Šīm trim darbībām nav nepieciešamas sarežģītas tehnoloģijas vai dārgi izstrādātāji, un pat iesācēji tās var viegli apgūt, tomēr tās var pasargāt jūsu vietni no 5xx kļūdām un uzturēt stabilu darbību.

Katra stabila jūsu vietnes ielāde un katrs apmeklētāja uzturēšanās laiks ir vērtīgs īpašums, ko uzkrājat laika gaitā.

Turpmāk identificējiet šos trīs vainīgos un veiciet ikdienas apkopi, lai nodrošinātu, ka jūsu WordPress vietne var ne tikai izturēt jūsu smago darbu, bet arī pastāvīgi palielināt datplūsmu un ieņēmumus.

Ja jūs pašlaik uztrauc 5xx kļūdas, mēģiniet veikt šajā rakstā norādītās darbības, lai novērstu problēmas. Es uzskatu, ka drīz vien jūs varēsiet atbrīvoties no šīm problēmām, panākt savas vietnes stabilu darbību un ilgtermiņa izaugsmi.