Kaip ištaisyti „WordPress 500“ vidinio serverio klaidą

Kaip ištaisyti „WordPress 500“ vidinio serverio klaidą

Daugeliui mūsų kūrėjų, dizainerių ar net galutinių vartotojų teko išgyventi bent vieną savo gyvenimą. Tai yra, skausmingas procesas gauti vidinę serverio klaidą ir bandyti ją ištaisyti. Daugeliui žmonių nerūpi žinoti daugiau – jie tiesiog nori tai išspręsti. Bet jei nesistengiate to bent jau suprasti, jūs privalote dažniau ištikti šį likimą. Vidinė 500 serverio klaida yra labai svarbi, nes ji visiškai sustabdo visus procesus ir gali sugadinti visą jūsų svetainę. Taigi, jei kada nors norime jos atsikratyti, turime geriau suprasti, ką tai pirmiausia reiškia.


Šiame straipsnyje aprašysiu pagrindus, ką reiškia ši klaida, kaip galite nustatyti problemą ir, žinoma, kaip ją pašalinti. Bet prieš pradėdamas noriu jus supažindinti su įvairiomis egzistuojančiomis http (svetainės) klaidomis ir tuo, ką jos galėtų reikšti. Jei norite, galite pereiti prie problemos, kaip ištaisyti „WordPress 500“ klaidą.

Įprasti HTTP būsenos ir klaidų kodai

Pirmiausia – paaiškinsiu, ką iš tikrųjų reiškia šios klaidos. Šiuo metu yra būsenos sąrašas ir klaidos HTTP kuriuos galima pasiekti norint geriau išspręsti situaciją. Šios klaidos paprastai skirstomos į tipus. Taigi, norėdami sutrumpinti šį reikalą, apimsime svarbiausias klaidas ir informacinius būsenos kodus, kuriuos rasite dirbdami su savo „WordPress“ svetaine..

100x atsakas (būsena)

Tokio tipo atsakymą tiesiogiai pateikia žiniatinklio serveris. Priklausomai nuo jūsų prieglobos įmonės, atsakymą gali pateikti „Apache“, „nginx“ arba bet kuri kita įmonės naudojama žiniatinklio tarnyba. Šis atsakymo tipas nėra susijęs su klaidomis. Paprastai jie naudojami norint parodyti, kad yra ryšys. Jie yra būsenos atsakymo kodai į jungtis.

200 kartų atsakymas (sėkmė)

Aš juos vadinu sėkmingais. Šis atsakymo tipas visada rodo a sėkmė. Tai reiškia, kad arba serveris sėkmingai užmezgė ryšį su jumis, kad prašomi ištekliai buvo duoti teisingai, arba kad buvo užmegztas tarpinis serveris.

Dažniausiai pasitaikantis kodas yra žinomas kaip 200 gerai. Galite pamatyti to pavyzdžių, jei naudojate „WordPress“ greičio tikrinimo įrankį, tarkime, „Pingdom Tools“ ir bandote sužinoti FTTB („First time tote“). 200 atsakymų visada pateikiami į pirmą pateiktą prašymą.

300x atsakymas (peradresavimai)

Peradresavimo vaikinai. Šie kodai visada nurodomi, jei duota nuoroda nukreipiama. 300 būsenos kodų rodo sėkmingą peradresavimą ir taip pat yra, nelaikoma klaida.

Tarkime, kad turite SSL (HTTPS) svetainę, taip pat turite tiesioginę prieigą prie HTTP (nesaugių) ir norite visus nukreipti į savo svetainės HTTPS versiją. Galite nukreipti visas užklausas, gaunamas iš HTTP, nukreipti į HTTPS. Jei netyčia bandysite patekti į savo svetainę naudodamiesi HTTP, jūsų naršyklė gaus 300 atsakymų, nurodančių nukreipimą į HTTPS versiją.

Paprasti „WooCommerce“ patarimai: Yoast SEO peradresavimai išparduodamų produktų

Kitas dažnas pavyzdys, su kuriuo galbūt esate susipažinęs, yra SEO peradresavimas vietoje. Galbūt pašalinote senus įrašus ar puslapius. Padedant tokiam įskiepiui kaip Mielių SEO galite 301 nukreipti juos į naujesnius, tinkamesnius puslapius. Arba naudokite laikiną peradresavimą 307, jei dirbate su naujinimu ir norite šiek tiek nukreipti vartotojus į kitą puslapį.

400x atsakymas (kliento klaidos)

Garsiosios kliento klaidos. Šios rūšies klaidos sukelia problemų jūsų naršyklėje. Paprastai ji negali įkelti tam tikro turto (dažniausiai žinoma yra 404 klaida). Šitie yra klaidų kodai, kurie nelaikomi sunkiais.

Tą pačią klaidą galima parodyti, jei bandysite pasiekti neegzistuojantį savo svetainės vaizdą. Pvz., Galbūt norėsite naudoti peradresavimą 410, kad praneštumėte paieškos varikliams, kad turinys buvo visam laikui pašalintas, arba 451, jei padarėte puslapį nepasiekiamą dėl teisinių priežasčių (pvz., DMCA užklausą)..

500x atsakas (serverio klaidos)

Ir dabar mes pasiekėme savo pagrindinį veikėją. 500 klaidų. Kaip matote, tai yra svarbios klaidos ir visada susijusios su pačiu serveriu. Serverio klaidos yra svarbios, nes jos gali efektyviai veikti avarija Jūsų tinklalapis. Iš šių klaidų svarbiausios yra:

  • „503“ paslauga negalima
  • 502 blogo šliuzo klaida
  • 500 vidinio serverio klaida

Panagrinėkime tris iš jų pagal svarbą.

503 Paslauga neteikiama

Mažiausiai rimta yra 503 paslauga, kuria negalima naudotis. Jei pasirodo ši klaida, turite žiniatinklio serverio išteklių problemą. Beveik visą laiką rodoma, kada jūsų serveris yra perkrautas. Aiškiai tariant, jei matote šią klaidą, žinokite tai tai laikina ir jis yra tiesiogiai susijęs su Per didelis eismas ir tai yra perkraunant procesorių. Kai centrinis procesorius ir pati žiniatinklio serveris negali apdoroti daugiau gaunamų jungčių, nes pasiekė 100 proc. Procesoriaus naudojimo, pamatysite šią klaidą.

Tai galite išspręsti perjungdami į geresnę žiniatinklio serverį (pvz., Iš „Apache“ į „Nginx“) arba įdiegdami „WordPress“ talpyklos papildinį savo svetainėje..

502 Bloga tinklų sąsaja

Tai aš vadinau netinkamos konfigūracijos klaida. Ši klaida nerodoma be jokios priežasties. Jei kada nors turite šią klaidą, greičiausiai to priežastis tu ką nors padarei ir padarei neteisingai. Paprastai tai atsitinka, kai žmonės bando pataisyti „Apache“ ir PHP konfigūraciją arba bando optimizuoti „nginx“. Blogas šliuzas yra klaida, kuri beveik visada atsitinka, kai PHP FPM („Fast Process Manager“) praranda ryšį. Dėl netinkamų nustatymų pakeitimo arba dėl to, kad procesas nutrūko. Tai verčia žiniatinklio serverį atsakyti a bloga tinklo sąsaja.

Lengviausias būdas ištaisyti šią klaidą yra dar kartą patikrinti savo PHP-FPM konfigūraciją, nes tai yra labiausiai tikėtina šios klaidos priežastis. Tai atsitinka dažniau „Nginx“ pusėje nei „Apache“ ir beveik niekada neatsitinka su „cPanel“ ar „Plesk“ teikiamomis prieglobos paslaugomis. Pastarosios dvi plokštės turi apsaugos priemones, kad būtų išvengta netinkamos konfigūracijos klaidų. Tačiau tai nutinka labai dažnai valdant savo VPS.

Ieškai daugiau pagalbos dėl šio? Vykdykite mūsų vadovą, kaip ištaisyti 502 blogų šliuzų klaidą.

500 Vidinė serverio klaida

Didelis blogas berniukas klaidų. 500 vidinio serverio klaida yra blogesnė iš visų, visų pirma todėl, kad yra tokia bendroji klaida. Jei neturite pakankamai žinių apie tai, kaip su ja elgtis, tai gali būti tikras skausmas, nes tai gali sumažinti visą jūsų svetainę. 502 blogo šliuzo klaida taip pat atmeta jūsų svetainę, tačiau ją lengviau diagnozuoti ir ištaisyti. Kaip minėta, ji beveik visada yra susijusi su FPM konfigūracija.

500 vidinės serverio klaidos priežastys ir kaip jas ištaisyti

Pirmas dalykas, kurį reikia suprasti apie 500 klaidą, yra tai, kad ją gali sukelti daugybė skirtingų veiksnių, beveik visada susijusių su kodo vykdymo nesėkmėmis. Užuot bandęs diagnozuoti viską iš karto, pateiksiu klaidų sąrašą pagal problemos tipą ir tai, ką darėte.

  • Perkėlę senesnę svetainę į naujesnę prieglobą
  • Klaida „.htaccess“ apache konfigūracijoje
  • Klaida vykdant PHP kodą

Yra ir kitų mažiau paplitusių atvejų, kai vidinė serverio klaida gali sukelti 500 klaidų, tačiau šio straipsnio paprastumo ir patogumo dėlei sutelksiu dėmesį į šiuos tris.

1. Senesnės svetainės perkėlimas į naujesnį prieglobą

Yra keletas būdų, kaip ši klaida gali būti rodoma, tačiau beveik visada ji atrodo susijusi su PHP versija, kuri yra susieta su jūsų žiniatinklio serveriu. Naujesnės PHP versijos gali sukelti tiesioginę 500 vidinių serverio klaidų, jei dabartinė svetainė ar papildiniai nepalaiko dabartinės versijos.

Ši klaida yra klasikinė, pavyzdžiui, kai jūs perkeliate savo svetainę iš vidutiniškos prieglobos su senesne PHP versija į naujesnę prieglobą, priimančią tik naujesnes versijas (7.0 ir naujesnes). Jei jūsų svetainė neseniai nebuvo atnaujinta, problemą gali sukelti senas įskiepis. Aš tai vadinu „migracijos vidinio serverio klaida“, nes ji beveik visada atsitinka, kai perkeliate svetainę.

Sprendimas

Geriausias būdas ištaisyti šią baisią klaidą, kai jūs taip sunkiai bandote perkelti savo „WordPress“ svetainę į naują prieglobą, turite padaryti pilną savo papildiniai ir jūsų svetainės tema. Tai padarius, prašau, ištrinti visus papildinius iš savo svetainės ir bandykite dar kartą. Jei klaida išnyks, beveik garantuojama, kad klaidą sukūrė naujesnė jūsų hostingo PHP versija, kuri tiesiog atsisako vykdyti kodą senesniame papildinyje. Iš naujo įkėlę vieną papildinį vienu metu, galite lengvai sužinoti, kuris iš jų sukėlė problemą.

Šios klaidos beveik visada pasireiškia perkeliant senesnes svetaines, veikiančias PHP 5.4 ir 5.6, į naujesnę prieglobą su PHP 7.0, 7.1 ar 7.2..

Tas pats pasakytina ir apie jūsų temą. Kadangi temos gali ir gali įdiegti papildomą PHP kodą funkcijosephp, single ir page.php bylos. Labiausiai tikėtina, kad senesnė tema be atnaujinimų gali sugriauti jūsų svetainę, kai ji buvo perkelta į prieglobą su naujesne PHP versija, tokia situacija yra apgailėtina, nes vienintelis būdas tai išspręsti yra pakeisti temą ir atkurti jūsų svetainę. Tai blogiausias scenarijus.

2. .htaccess Apache konfigūracijos klaida

Tarkime, jūs sukonfigūravote papildinį ir staiga viskas sugenda. Jei konfigūruodami gaunate 500 vidinių serverio klaidų, pavyzdžiui, talpyklos papildinį ar bet kurį papildinį, susijusį su optimizavimu, turite patikrinti, ar papildinys pridėjo papildomą kodą jūsų .htaccess faile.

Kadangi apache galima modifikuoti realiu laiku sukonfigūravus .htaccess failo funkcijas (kurios beveik visada yra paslėptos), netinkama konfigūracija gali sugadinti jūsų svetainę.

Sprendimas

Tai galite išspręsti naudodamiesi prieiga prie savo svetainės per FTP ir modifikuodami .htaccess failą arba tiesiogiai redaguodami, tarkime, su „CPanel“ ar „Plesk“ failų naršykle..

Jei nežinote, kaip atkurti papildinio padarytą funkciją, ir jums vėl reikia svetainės, sukurkite esamo turinio kopiją kaip teksto failą. Išsaugokite tai kaip atsarginę kopiją. Tada pakeiskite visą .htaccess tokiu kodu:

# BEGIN „WordPress“

„RewriteEngine“ įjungta
„RewriteBase“
„RewriteRule“ rodyklė \ .php $ - [L]
„RewriteCond% {REQUEST_FILENAME}! -F
„RewriteCond% {REQUEST_FILENAME}! -D
„RewriteRule“. /index.php [L]

# END WordPress

Tai yra numatytasis „WordPress“ .htaccess byla. Tai turėtų veikti su bet kuria svetaine. Taigi, jei esate beviltiškas ir nežinote, kurią dalį pašalinti, tiesiog pašalinkite viską ir įklijuokite šį kodą. Tai padės jums akimirksniu sutaupyti. Vėliau galite pašalinti papildinį arba pabandyti dar kartą sukonfigūruoti. Dabar jūs žinote, kaip išgelbėti jus nuo šios katastrofiškos klaidos. Bent jau jei tai susiję su .htaccess.

Jei nežinote, ar tai susiję su „.htaccess“, ar ši klaida pasirodė rodoma nelietant jokių papildinių, paleiskite ją saugiai. Tiesiog nukopijuokite .htaccess turinį ir nukopijuokite aukščiau esantį kodą, kad bandytumėte diagnozuoti. Jei tai neišsprendžia, palikite .htaccess tokį, koks jis yra, ir tada išbandykite kitą pasiūlymą.

3. PHP kodo vykdymo klaida

Šios klaidų rūšys yra dažnesnės, nei manote, ir dažniausiai jos įvyksta, jei papildinys vykdo netinkamą kodą. Dažniausias netinkamo kodo vykdymo būdas yra bandant vykdyti nebenaudojamas instrukcijas. Galbūt jūs bandote paleisti seną papildinį, kuris buvo skirtas veikti tik su PHP 5.4 arba 5.6 su PHP 7.0 ar naujesnėmis versijomis. Nebenaudojamos ir netinkamos funkcijos sukurs vidinę serverio klaidą, kurią gali diagnozuoti tik įgalinant WP derinimo režimą.

Įgalinti „wp_debug“

„WordPress“ derinimo režimas pateiks išsamią informaciją apie klaidą, kuri buvo sustabdyta vykdant. Mes tai įgaliname pakeisdami vertę iš „Klaidinga“ į „teisinga“ wp_debug failo viduje wp-config.php pagrindiniame savo svetainės aplanke.

Jei naudojate „Plesk“ arba „cPanel“, galite tai padaryti tiesiog pakeisdami šią vertę naudodami „File Explorer“ ir redaguodami wp-config.php. Taip pat galite sekti tuo derinimo vadovas pateikė „Blogvault“, jei norite gauti išsamesnių veiksmų.

Redagavę failą, galėsite pamatyti faktinę sugeneruotą klaidą, kuri sustabdė vykdymą. Klaida taip pat nurodys kelią ir failą, kur tai įvyko, todėl nesunku atspėti, koks papildinys sukėlė tai. Autorius jį išjungus klaidą galime praleisti ir vėliau atnaujinti papildinį arba pašalinti jį, atsižvelgiant į situaciją.

Sprendimas

Didžioji dauguma 500 vidinės serverio klaidų atvejų yra susiję senesnės temos versijos ar papildiniai. Pakeisdami savo temą į bet kurią standartinę WP temą, galėsite atgauti prieigą prie savo svetainės. Išjungę nesuderinamus papildinius taip pat grįšite prieiga prie informacijos suvestinės. Jei atsitiks situacija, kai už jūsų svetainės pažeidimą atsakinga jūsų tema, geriausias būdas ją išspręsti yra sukūrus šios temos ZIP failą iš temos aplanko. wp-turinys / temos / tema tada ištrinkite jį iš savo svetainės. Tai pašalins klaidą, kad galėtumėte atgauti prieigą prie savo svetainės. Tada galite iš naujo įkelti ir atnaujinti, nesuaktyvinę. Tą patį veiksmą galite padaryti naudodami papildinius.

Dažniausiai pasitaikančios 500 vidinių serverio klaidų situacijos gali būti pataisytas atnaujinant. Tais atvejais, kai minėtame papildinyje / temoje nėra atnaujinimo, galite pabandyti perjungti į senesnę PHP versiją. Bet žinokite, kad tai yra trumpalaikis sprendimas. Naujesnės PHP versijos tampa stabilios, o senesnės versijos reguliariai nebetenka galios. Anksčiau ar vėliau jūsų svetainė tikrai nustos veikti. Geriausias būdas visada bus atnaujinti ar pašalinti / pakeisti atitinkamus papildinius.

Visada atsiminkite, kad geriau užkirsti kelią ir atnaujinti, nei bandyti padaryti žalos valdymą vėliau.

Apibendrinkite mūsų „WordPress 500“ vidinio serverio klaidų vadovą

„WordPress 500“ vidinė serverio klaida gali būti tikras skausmas. Bet daugeliu atvejų juos galima lengvai diagnozuoti ir ištaisyti paprasčiausiai pašalinant / atnaujinant nesuderinamas jūsų svetainės dalis. Nors gali būti situacijų, kai šios klaidos nepatenka į normą (pavyzdžiui, kai kuriate papildinį), tai viršija šio straipsnio tikslą.

Didesnei daliai žmonių, atlikdami aukščiau pateiktus patarimus, turėtumėte išspręsti jūsų problemą. Atminkite, kad „wp-debug“ yra geriausias jūsų draugas, ir visada atsargiai atlikite veiksmus. Jūs netrukus turėsite savo internetinę svetainę.

Ar turite kitų klausimų? Arba patarimai, kaip pašalinti „WordPress 500“ vidinio serverio klaidą? Leisk man žinoti!

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me