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

Aš valdau kelisWordPressKartą dėl 502 klaidos svetainė per dieną prarado daugiau nei 800 apsilankymų. Po trijų dienų tyrimo paaiškėjo, kad kaltininkas buvo nepastebima aplinka vidinėje pusėje.

Kiekvienas, kas valdo „WordPress“ svetainę, žino, kad labiausiai erzina ne srauto trūkumas, o tada, kai svetainė staiga tampa neprieinama, o ekrane pasirodo iškraipytos klaidos, tokios kaip 500, 502, 503 ir 504.

Manėte, kad serveris sugedo, ir puolėte ginčytis su prieglobos paslaugų teikėju, tik tam, kad patikrinę sužinotumėte, jog serveris veikia visiškai normaliai.

Galite manyti, kad tai įskiepių konfliktas, todėl po vieną juos išjungiate ir šalinate triktis, didžiąją dienos dalį tam skirdami, tačiau klaida vis kartojasi.

Tiesą sakant, tai nebūtinai turi būti taip sudėtinga. Pakliuvęs į nesuskaičiuojamą daugybę spąstų, atradau, kad 80 % WP svetainės 5xx klaidų negali išvengti šių 4 kaltininkų. Kiekvienas iš jų yra gerai paslėptas, bet gali lengvai sugadinti jūsų svetainę.

Dabar, remdamasis savo praktine patirtimi, aiškiai atskleisiu šiuos trūkumus, kad net pradedantieji galėtų sekti ir spręsti problemas, ir jums niekada nebereikės susidurti su klaidomis.

1 kaltininkas: WP-CRON nebuvo išjungtas, iš esmės svetainėje įdiegus „paslėptą energijos nutekėjimą“.

Daugelis žmonių nežino, kad „WordPress“ turi integruotą suplanuotų užduočių funkciją, vadinamą WP-CRON, kuri įjungta pagal numatytuosius nustatymus.

Jos funkcijos skamba labai praktiškai, pavyzdžiui, straipsnių publikavimo planavimas, automatinis atsarginių kopijų kūrimas, papildinių atnaujinimų tikrinimas ir net priminimų siuntimas nariams.

Bet ar žinojote, kad ši, atrodytų, naudinga funkcija iš tikrųjų yra pagrindinė serverių gedimų ir 5xx klaidų priežastis?

„WP-CRON“ skiriasi nuo serverio „Cron“. Jis neveikia proaktyviai, o yra suaktyvinamas vartotojų apsilankymų. Kiekvieną kartą, kai vartotojas apsilanko jūsų svetainėje, jis slapta vykdys failą /wp-cron.php, kad patikrintų, ar yra kokių nors suplanuotų užduočių.

Tai reiškia, kad kiekvienas jūsų svetainės lankytojas prideda „papildomą naštą“, ir kuo daugiau lankytojų turite, tuo sunkesnė tampa našta.

Anksčiau turėjau svetainę, kurią per dieną aplankydavo daugiau nei tūkstantis lankytojų. Kai WP-CRON nebūdavo išjungtas, serverio procesoriaus apkrova dažnai šoktelėdavo iki daugiau nei 80 %, ir kasdien pasirodydavo bent dvi 503 klaidos, o lankytojai vos spustelėję nuorodą būdavo nukreipiami į klaidų puslapį.

Dar blogiau yra tai, kad net jei nenustatysite jokių suplanuotų užduočių, WP-CRON veiks automatiškai, pakartotinai prašydamas serverio išteklių. Laikui bėgant, serveris negalės susidoroti su apkrova ir praneš apie klaidą.

„GitHub“ dokumentacijoje aiškiai nurodyta: „Netikėtas HTTP atsakymo kodas: 500 arba didesnis, tai reiškia, kad jūsų serveryje įvyko klaida, neleidžianti veikti „cron“ spawneriui.“ Tai reiškia, kad kai WP-CRON neveikia tinkamai, tai sukelia 500 arba didesnę serverio klaidą.

Teisingas būdas yra išjungti numatytąjį WP-CRON ir vietoj jo naudoti serverio numatytas užduotis. Tai užtikrins, kad suplanuotos užduotys bus vykdomos normaliai, tuo pačiu sumažinant serverio apkrovą.

Jei jūsų serveris palaiko „curl“ komandą, galite tiesiogiai pridėti suplanuotą užduotį, tokią kaip ši (modifikuokite pagal savo svetainės domeną):

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

Ši komanda vykdo WP-CRON užduotį kas 15 minučių, tinka daugumai mažų ir vidutinių svetainių; jei jūsų svetainėje dažnai suplanuotos užduotys, taip pat galite naudoti šią komandą:

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

Išjungus WP-CRON ir serveryje nustačius suplanuotas užduotis, serverio procesoriaus apkrovimas sumažėjo iki mažiau nei 30 %, o visą mėnesį nebuvo jokių 503 klaidų. Lankytojų išlaikymo rodiklis taip pat padidėjo 18 %.

Antras kaltininkas: pasikartojančios CRON suplanuotos užduotys ir likę failai po įskiepio pašalinimo iš esmės „palieka šlamštą“ svetainėje.

WP-CRON problemos sprendimas nereiškia, kad galite būti ramūs; yra paslėptas trūkumas, kurio daugelis svetainių savininkų nepastebi.

Tai reiškia, kad CRON suplanuotos užduotys vykdomos pakartotinai arba kad likusios suplanuotos užduotys vis dar slapta vykdomos pašalinus papildinį.

Ar kada nors susidūrėte su tokia situacija: pašalinote atsarginių kopijų kūrimo įskiepį, bet pastebėjote, kad serveris vis tiek automatiškai kuria atsargines kopijas kiekvieną dieną arba netgi rodo atsarginės kopijos kūrimo nesėkmės pranešimą, kuris galiausiai sukelia 500 klaidą?

Taip yra dėl likusių suplanuotų užduočių iš papildinio.

Pavyzdžiui, jei įskiepis sugeneruoja kasdienę suplanuotą užduotį, „WordPress“ toliau vykdys šią užduotį net ir po to, kai įskiepis bus pašalintas. Tokios suplanuotos užduotys yra beprasmės. Šios beprasmės likutinės užduotys nuolat eikvos serverio išteklius ir galiausiai sukels klaidų.

Dar blogiau, kai kurie papildiniai automatiškai generuoja kelias pasikartojančias suplanuotas užduotis. Pavyzdžiui, užduotis „kasdienis atnaujinimų patikrinimas“ gali būti sukurta penkis kartus, ir kiekviena iš jų būtų vykdoma pagal tvarkaraštį, o tai reiškia, kad serveris turėtų vienu metu apdoroti penkias identiškas užduotis.

Vieną anksčiau įdiegiau.SEOPašalinęs įskiepį, jo nepastebėjau, ir po pusės mėnesio svetainė dažnai susidurdavo su 504 skirtojo laiko klaidomis. Tik patikrinęs serverio žurnalus, sužinojau, kad įskiepis paliko tris kasdien suplanuotas užduotis, kurių kiekvienos vykdymo laikas buvo iki 12 sekundžių. Šių trijų užduočių vykdymas vienu metu tiesiogiai sukėlė serverio atsakymo skirtojo laiko pabaigą.

Dar labiau baugina tai, kad šios pasikartojančios, laikui bėgant nustatytos užduotys...WordPress backendTai nematoma; jūs net neįsivaizduojate, kad tai veikia slapta.

Tačiau yra sprendimas: „WP-Crontrol“ įskiepis puikiai su tuo susidoroja. Tai oficiali „WordPress“ rekomenduojama „Cron“ užduočių valdymo priemonė, leidžianti peržiūrėti, redaguoti ir ištrinti visas suplanuotas užduotis tiesiai administratoriaus sąsajoje.

Remiantis „WordPress“ įskiepio aprašymu, „WP-Crontrol“ gali „peržiūrėti visus suplanuotus „cron“ įvykius, redaguoti, ištrinti, pristabdyti, atnaujinti ir nedelsiant vykdyti „cron“ įvykius“. Kitaip tariant, jis gali peržiūrėti visas suplanuotas užduotis ir ištrinti pasikartojančias arba negaliojančias užduotis. Juo labai paprasta naudotis ir nereikia rašyti nė vienos kodo eilutės.

Panaudojęs šį papildinį trikčių šalinimui, ištryniau 8 pasikartojančias užduotis ir 5 papildinio likučių užduotis, o svetainės reagavimo greitis tiesiogiai pagerėjo 40 %. 504 klaida daugiau niekada nepasikartojo.

Atsargumo žodis: trinant užduotis, atidžiai patikrinkite ir netyčia neištrinkite pagrindinių „WordPress“ suplanuotų užduočių, tokių kaip „wp_version_check“ (versijos patikrinimas). Atsitiktinis ištrynimas gali sutrikdyti svetainės tinkamą atnaujinimą.

Nors „WP-Crontrol“ įskiepis gali rankiniu būdu ištrinti pasikartojančias arba negaliojančias užduotis, tam reikia rankinio įsikišimo, o tai nėra idealu...

Tačiau šį procesą galime automatizuoti naudodami „WordrPress“ kodą. Išsamesnės informacijos ieškokite toliau pateiktame vadove. ▼

🔗„WordPress“ svetainės spartinimo patarimai: automatiškai pašalinkite netinkamas CRON suplanuotas užduotis

3 kaltininkas: nereikalingos duomenų bazės „WordPress“ sistemoje

„WordPress“ sistemoje atrodo taip 500 Klaida Viena iš priežasčių yra duomenų bazės perteklius, ypač didelės talpos duomenų lentelės, kurias generuoja tam tikri įskiepiai.

Naudodamas WP optimizavimo įskiepį, pastebėjau, kad kai kurios duomenų lentelės buvo neįprastai didelės, tarp kurių... „Wordfence“ konfigūracijos lentelė (wfconfig) Ypač žymus.

Problemų analizė

• „wfconfig“ turi rimtą duomenų lentelių perteklių.Jis buvo kartą išvalytas, bet labai greitai vėl atsirado.
• Numatytosios saugyklos modulio problemos„Wordfence“ konfigūracijos lentelėje naudojamas numatytasis „InnoDB“ variklis, kuris laikui bėgant sukaups šimtus MB nereikalingų duomenų.
• Poveikis našumuiDuomenų lentelės gali lengvai pasiekti šimtus MB dydžio, todėl svetainės įkėlimo greitis gali sumažėti ir net sukelti 500 klaidų.

Sprendimas

Taip yra todėl, kad „Wordfence“ konfigūruojamos duomenų lentelės naudoja numatytąjį „Inno“ variklį. Laikui bėgant, tai greitai sukaups šimtus megabaitų nereikalingų duomenų, kurie turės įtakos svetainės įkėlimo greičiui.

HestiaCPInstrukcijas, kaip pakeisti numatytąjį „MariaDB“ saugojimo variklį į „MyISAM“, rasite šiame vadove:

Kaip pakeisti numatytąjį „MariaDB“ saugojimo variklį į „MyISAM“ „HestiaCP“? Paprastas vieno žingsnio sprendimas!

Ketvirtas kaltininkas: klaidos po įskiepių / temų atnaujinimų yra tarsi „netradicinės operacijos“ atlikimas svetainėje.

Daugelis svetainių savininkų turi įprotį iš karto spustelėti „atnaujinti“, kai pamato atnaujinimo raginimus papildiniams ar temoms, manydami, kad atnaujinimai ištaisys pažeidžiamumus ir pagerins našumą.

Tačiau tiesa yra visiškai priešinga; daugelį 5xx klaidų sukelia papildinių ar temų atnaujinimas.

Su šia problema jau esu susidūręs anksčiau. Praėjusį mėnesį atnaujinau savo svetainę naudodamas populiarų puslapių kūrimo įskiepį. Paspaudus „Atnaujinti“, puslapis tapo tuščias, o atnaujinus jį, pasirodė 500 vidinė serverio klaida, dėl kurios nebuvo įmanoma pasiekti serverio.

Vėliau sužinojau, kad nauja įskiepio versija nesuderinama su mano svetainės PHP versija. Atnaujinus įskiepį, kodas negalėjo tinkamai veikti, todėl serveris pranešė apie klaidą.

Klaidos po papildinio ar temos atnaujinimo yra dažna „WordPress 500“ klaidų priežastis, ypač kai naujoje papildinio versijoje yra kodo pažeidžiamumų arba ji konfliktuoja su kitais svetainės papildiniais ar temomis.

Kitas scenarijus yra tas, kad atnaujinus temą, ankstesnis pasirinktinis kodas bus perrašytas, todėl svetainės išdėstymas taps netvarkingas ir funkcijos neveiks, o tai savo ruožtu sukels 502 ir 503 klaidas.

darytiEl. KomercijaKai kuriems vartotojams, atnaujinus „WooCommerce“ įskiepį, jų svetainėse atsirado 502 klaida, dėl kurios nebuvo įmanoma pateikti užsakymų. Dėl to vos per 3 valandas pardavimai sumažėjo daugiau nei 2000, o problemai išspręsti prireikė visos popietės.

Tiesą sakant, tiesiausias ir efektyviausias šios situacijos sprendimas yra grįžti prie ankstesnės versijos, kuri veikė tinkamai.

Daugelis žmonių nežino, kaip atšaukti atliktus pakeitimus, tačiau jums nereikia rankiniu būdu atsisiųsti ar įkelti failų; „WP Rollback“ papildinys tai palengvina.

„WordPress“ aprašyme teigiama, kad „WP Rollback“ įskiepis gali „greitai ir lengvai grąžinti bet kurią temą ar įskiepį iš „wordpress.org“ į bet kurią ankstesnę (ar naujesnę) versiją be jokio rankinio darbo“. Kitaip tariant, jis gali grąžinti įskiepius ar temas į bet kurią ankstesnę versiją vienu spustelėjimu, be sudėtingų operacijų, todėl pradedantiesiems juo lengva naudotis.

Po paskutinio įskiepio atnaujinimo nesėkmės panaudojau „WP Rollback“, kad vienu spustelėjimu grįžčiau prie ankstesnės versijos. Svetainė grįžo į įprastą būseną vos per 30 sekundžių, ir jokie duomenys nebuvo prarasti.

Štai patarimas: prieš atnaujindami papildinius ar temas, visada pirmiausia sukurkite savo svetainės atsarginę kopiją. Geriausia pirmiausia išbandyti ją bandymų aplinkoje, kad įsitikintumėte, jog nėra problemų prieš atnaujinant oficialioje svetainėje ir išvengtumėte klaidų.

Išvada: Įvaldykite šiuos 3 punktus, kad visiškai atsisveikintumėte su WP svetainės 5xx klaidomis.

Paleidus „WordPress“ svetainę, 500, 502, 503 ir 504 klaidos yra tarsi „kliūtys“, iš pažiūros keliančios problemų, tačiau jų priežastis iš tikrųjų yra gana aiški – ne serverio gedimas ir ne didelė svetainės programos problema, o tiesiog pamiršome tris detales: WP-CRON, likusias suplanuotas užduotis ir papildinių / temų atnaujinimus.

Kaip „WordPress“ svetainės savininkas, nuo pat pradžių, kai mane pribloškė klaidos, iki dabar galiu greitai pašalinti visas 5xx klaidas ir jas išspręsti, svarbiausia mano išvada yra ta, kad stabilus svetainės veikimas nepriklauso nuo „arklidės durų užrakinimo, kai arklys jau pabėgo“, o veikiau nuo „prevencija yra geriau nei gydymas“.

Daugelis svetainių savininkų mano, kad šios smulkios detalės yra nesvarbios, ir gailisi, kad jų nepatikrino iš anksto, tik tada, kai svetainė sugenda, praranda srautą ir patiria pajamų nuostolius.

Svarbu suprasti, kad svetainės „stabilumas“ yra pagrindinis konkurencinis pranašumas. Viena 5xx klaida gali lemti 10 % lankytojų praradimą, o kelios klaidos gali netgi lemti paieškos sistemų reitingo sumažėjimą, todėl visos ankstesnės SEO pastangos nueis perniek.

Kaip sakoma: „Tūkstančio mylių pylimą gali pralaužti skruzdėlynas.“ WP svetainės 5xx klaidos niekada neatsiranda staiga, o yra mažų problemų – neišjungto WP-CRON, likusių suplanuotų užduočių ir skubotų atnaujinimo operacijų – susikaupimo rezultatas. Šios, atrodytų, nereikšmingos „skruzdėlynių skylės“ galiausiai sunaikins visą svetainės „pylimą“.

Tikrai efektyvios operacijos reiškia problemų sprendimą dar pačioje pradžioje.

1. Išjunkite numatytąjį WP-CRON ir pakeiskite jį serverio pagrindu suplanuota užduotimi;
2. Reguliariai naudokite WP-Crontrol, kad išvalytumėte pasikartojančias ir likusias suplanuotas užduotis;
3. Prieš atnaujindami papildinius ar temas, būtinai sukurkite duomenų atsarginę kopiją ir nedelsdami atkurkite pradinę būseną, jei įvyktų klaidų.

Šioms trims operacijoms nereikia sudėtingų technologijų ar brangių kūrėjų, ir net pradedantieji gali jas lengvai įvaldyti, tačiau jos gali apsaugoti jūsų svetainę nuo 5xx klaidų ir išlaikyti stabilų veikimą.

Kiekvienas stabilus jūsų svetainės įkrovimas ir kiekvienas lankytojo apsilankymas yra vertingas turtas, kurį kaupiate laikui bėgant.

Nuo šiol nustatykite šiuos tris kaltininkus ir atlikite kasdienę priežiūrą, kad jūsų „WordPress“ svetainė ne tik atlaikytų jūsų sunkų darbą, bet ir nuolat didintų srautą bei pajamas.

Jei šiuo metu jus vargina 5xx klaidos, pabandykite atlikti šiame straipsnyje nurodytus veiksmus, kad pašalintumėte triktis. Manau, kad netrukus galėsite atsikratyti šių problemų, užtikrinti stabilų svetainės veikimą ir ilgalaikį augimą.