Cum să remediați o eroare internă de server 500 pe site-ul dvs. WordPress

Temuta eroare de server intern 500. Pare întotdeauna să vină în momentul cel mai inoportun și brusc te lupți să-ți dai seama cum să-ți readuci site-ul WordPress online. Ai încredere în noi, toți am fost acolo. Alte erori care se comportă în mod similar pe care le-ați fi văzut, de asemenea, includ eroarea înspăimântătoare de a stabili o conexiune la baza de date și temutul ecran alb al morții. Însă, din momentul în care site-ul tău se prăbușește, pierzi vizitatori și clienți. Ca să nu mai vorbim că pur și simplu arată rău pentru marca ta.

Astăzi ne vom scufunda în eroarea serverului intern 500 și vă vom prezenta câteva modalități de a vă readuce rapid site-ul online. Citiți mai multe mai jos despre ce cauzează această eroare și ce puteți face pentru a o preveni în viitor.

• Ce este o eroare internă de server 500?
• Cum se remediază eroarea serverului intern 500

Consultați Ghidul nostru final pentru remedierea erorii interne de server 500

Ce este o eroare internă de server 500?

Internet Engineering Task Force (IETF) definește eroarea internă a serverului 500 ca:

Codul de stare 500 (Eroare internă a serverului) indică faptul că serverul a întâmpinat o condiție neașteptată care l-a împiedicat să îndeplinească cererea.

Când vizitați un site web, browserul dvs. trimite o solicitare către serverul pe care este găzduit site-ul. Serverul preia această solicitare, o procesează și trimite înapoi resursele solicitate (PHP, HTML, CSS etc.) împreună cu un antet HTTP. HTTP include, de asemenea, ceea ce ei numesc un cod de stare HTTP. Un cod de stare este o modalitate de a vă notifica despre starea cererii. Ar putea fi un cod de stare 200 care înseamnă „Totul este în regulă” sau un cod de stare 500 care înseamnă că ceva a mers prost.

Există o mulțime de tipuri diferite de 500 de coduri de eroare de stare (500, 501, 502, 503, 504 etc.) și toate înseamnă ceva diferit. În acest caz, o eroare internă de server 500 indică faptul că serverul a întâlnit o condiție neașteptată care l-a împiedicat să îndeplinească cererea (RFC 7231, secțiunea 6.6.1).

500 de variante ale erorilor interne ale serverului

Datorită diferitelor servere web, sisteme de operare și browsere, o eroare internă de server 500 se poate prezenta în mai multe moduri diferite. Dar toți comunică același lucru. Mai jos sunt doar câteva dintre numeroasele variații pe care le puteți vedea pe web:

• • "500 Eroare internă a server-ului"
  • „HTTP 500”
  • "Eroare interna a serverului"
  • „HTTP 500 – Eroare internă de server”
  • „Eroare 500”
  • „Eroare HTTP 500”
  • "500 Eroare internă a server-ului"
  • "500 Eroare internă a server-ului. Scuze, ceva a mers greșit."
  • „500. E o eroare. A fost o eroare. Vă rugăm să încercați din nou mai târziu. Asta e tot ce știm."
  • „Site-ul web nu poate afișa pagina – HTTP 500.”
  • „În prezent, nu poate face față acestei cereri. EROARE HTTP 500.”

Este posibil să vedeți și acest mesaj care îl însoțește:

Serverul a întâmpinat o eroare internă sau o configurare greșită și nu a putut finaliza solicitarea dvs. Vă rugăm să contactați administratorul serverului, [email protected] și să-i informați despre momentul în care s-a produs eroarea și despre orice ați putea fi făcut și care ar fi putut cauza eroarea. Mai multe informații despre această eroare pot fi disponibile în jurnalul de erori de server.

Alteori, este posibil să vedeți pur și simplu un ecran alb gol. Când aveți de-a face cu 500 de erori interne ale serverului, acest lucru este de fapt destul de comun în browsere precum Firefox și Safari.

Mărcile mai mari ar putea chiar să aibă propriile lor 500 de mesaje de eroare interne personalizate, cum ar fi acesta de la Airbnb.

Iată un alt exemplu de eroare de server creativ 500 de la cei de la readme.

Nici măcar puternicul YouTube nu este ferit de 500 de erori interne ale serverului.

Dacă este un server IIS 7.0 (Windows) sau o versiune ulterioară, acestea au coduri de stare HTTP suplimentare pentru a indica mai îndeaproape cauza erorii 500:

• 500.0 – A apărut o eroare de modul sau ISAPI.
• 500.11 – Aplicația se închide pe serverul web.
• 500.12 – Aplicația este ocupată cu repornirea pe serverul web.
• 500.13 – Serverul web este prea ocupat.
• 500.15 – Solicitările directe pentru global.asax nu sunt permise.
• 500.19 – Datele de configurare sunt invalide.
• 500.21 – Modulul nu este recunoscut.
• 500.22 – O configurație ASP.NET httpModules nu se aplică în modul Managed Pipeline.
• 500.23 – O configurație ASP.NET httpHandlers nu se aplică în modul Managed Pipeline.
• 500.24 – O configurație de uzurpare a identității ASP.NET nu se aplică în modul Managed Pipeline.
• 500.50 – A apărut o eroare de rescriere în timpul procesării notificărilor RQ_BEGIN_REQUEST. A apărut o eroare de configurare sau de execuție a regulii de intrare.
• 500.51 – A apărut o eroare de rescriere în timpul procesării notificărilor GL_PRE_BEGIN_REQUEST. A apărut o eroare de configurare globală sau de execuție a regulilor globale.
• 500.52 – A apărut o eroare de rescriere în timpul procesării notificărilor RQ_SEND_RESPONSE. A avut loc o execuție a regulii de ieșire.
• 500.53 – A apărut o eroare de rescriere în timpul procesării notificărilor RQ_RELEASE_REQUEST_STATE. A apărut o eroare de execuție a regulii de ieșire. Regula este configurată pentru a fi executată înainte ca cache-ul utilizatorului de ieșire să fie actualizat.
  500.100 – Eroare ASP internă.

Impactul 500 de erori asupra SEO

Spre deosebire de erorile 503, care sunt utilizate pentru modul de întreținere WordPress și îi spun Google să verifice mai târziu, o eroare 500 poate avea un impact negativ asupra SEO dacă nu este remediată imediat. Dacă site-ul dvs. este oprit doar pentru 10 minute și este accesat cu crawlere în mod constant de multe ori, crawler-ul va primi pur și simplu pagina din cache. Sau s-ar putea ca Google să nu aibă nici măcar șansa de a-l accesa din nou cu crawlere înainte de a-i reveni. În acest scenariu, ești complet bine.

Cu toate acestea, dacă site-ul este oprit pentru o perioadă lungă de timp, să zicem peste 6 ore, atunci Google ar putea vedea eroarea 500 ca o problemă la nivel de site care trebuie rezolvată. Acest lucru ar putea afecta clasamentul dvs. Dacă sunteți îngrijorat de repetarea a 500 de erori, ar trebui să vă dați seama de ce se întâmplă pentru început. Unele dintre soluțiile de mai jos vă pot ajuta.

Cum să remediați eroarea 500 de server intern

De unde ar trebui să începeți depanarea când vedeți o eroare internă de server 500 pe site-ul dvs. WordPress? Uneori s-ar putea să nu știi nici de unde să începi. De obicei, 500 de erori sunt pe serverul în sine, dar din experiența noastră, aceste erori provin din două lucruri, primul este eroarea utilizatorului (problemă la nivelul clientului), iar al doilea este că există o problemă cu serverul . Așa că ne vom scufunda puțin în ambele.

Acest lucru nu este niciodată enervant pic.twitter.com/pPKxbkvI9K

— Dare Obasanjo (@Carnage4Life) 26 septembrie 2019

Consultați aceste cauze comune și modalități de a remedia eroarea serverului intern 500 și reveniți la funcționare în cel mai scurt timp.

1. Încercați să reîncărcați pagina

Acest lucru ar putea părea puțin evident pentru unii, dar unul dintre cele mai simple și primele lucruri pe care ar trebui să le încercați atunci când întâmpinați o eroare internă de server 500 este să așteptați un minut și să reîncărcați pagina (F5 sau Ctrl + F5). S-ar putea ca gazda sau serverul să fie pur și simplu supraîncărcat și site-ul să revină imediat. În timp ce așteptați, puteți încerca rapid un alt browser pentru a exclude asta ca o problemă.

Un alt lucru pe care îl puteți face este să inserați site-ul web în downforeveryoneorjustme.com. Acest site web vă va spune dacă site-ul este oprit sau dacă este o problemă din partea dvs. Un astfel de instrument verifică codul de stare HTTP care este returnat de la server. Dacă este altceva decât un 200 „Totul este OK”, atunci va returna o indicație de jos.

De asemenea, am observat că uneori acest lucru se poate întâmpla imediat după ce actualizați un plugin sau o temă pe site-ul dvs. WordPress. De obicei, aceasta este pe gazde care nu sunt configurate corect. Ceea ce se întâmplă este că experimentează un timeout temporar imediat după aceea. Cu toate acestea, lucrurile se rezolvă de obicei de la sine în câteva secunde și, prin urmare, împrospătarea este tot ce trebuie să faceți.

2. Goliți memoria cache a browserului

Ștergerea memoriei cache a browserului este întotdeauna un alt pas bun de depanare înainte de a vă scufunda în depanarea mai profundă a site-ului dvs. Mai jos sunt instrucțiuni despre cum să ștergeți memoria cache în diferitele browsere:

• Cum să forțați reîmprospătarea unei singure pagini pentru toate browserele
• Cum să ștergeți memoria cache a browserului pentru Google Chrome
• Cum să ștergeți memoria cache a browserului pentru Mozilla Firefox
• Cum să ștergeți memoria cache a browserului pentru Safari
• Cum să ștergeți memoria cache a browserului pentru Internet Explorer
• Cum să ștergeți memoria cache a browserului pentru Microsoft Edge
• Cum să ștergeți memoria cache a browserului pentru Opera

3. Verificați jurnalele serverului dvs

De asemenea, ar trebui să profitați de jurnalele de erori. Dacă sunteți client Kinsta, puteți vedea cu ușurință erorile în vizualizatorul de jurnal din tabloul de bord MyKinsta. Acest lucru vă poate ajuta să restrângeți rapid problema, mai ales dacă este rezultatul unui plugin de pe site-ul dvs.

Dacă gazda dvs. nu are un instrument de înregistrare, puteți activa și modul de depanare WordPress adăugând următorul cod în fișierul wp-config.php pentru a activa înregistrarea:

 define( 'WP_DEBUG', true ); define( 'WP_DEBUG_LOG', true ); define( 'WP_DEBUG_DISPLAY', false );

Jurnalele sunt de obicei localizate în directorul /wp-content. Alții, ca aici la Kinsta, ar putea avea un folder dedicat numit „jurnal”.

De asemenea, puteți verifica fișierele jurnal în Apache și Nginx, care se află de obicei aici:

• Apache: /var/log/apache2/error.log
• Nginx: /var/log/nginx/error.log

Dacă sunteți client Kinsta, puteți profita și de instrumentul nostru de analiză pentru a obține o defalcare a numărului total de 500 de erori și pentru a vedea cât de des și când apar. Acest lucru vă poate ajuta să depanați dacă aceasta este o problemă în curs de desfășurare sau poate ceva care s-a rezolvat de la sine.

Dacă eroarea 500 se afișează din cauza unei erori PHP fatale, puteți încerca și să activați raportarea erorilor PHP. Pur și simplu adăugați următorul cod la fișierul care aruncă eroarea. De obicei, puteți restrânge fișierul în fila consolă din Google Chrome DevTools.

 ini_set('display_errors', 1); ini_set('display_startup_errors', 1); error_reporting(E_ALL);

Și ar putea fi necesar să modificați fișierul php.ini cu următoarele:

 display_errors = on

4. Eroare la stabilirea unei conexiuni la baza de date

500 de erori interne ale serverului pot apărea și din cauza unei erori de conectare la baza de date. În funcție de browser, este posibil să vedeți diferite erori. Dar ambele vor genera un cod de stare HTTP 500, indiferent de jurnalele serverului dvs.

Mai jos este un exemplu despre cum arată un mesaj „eroare la stabilirea unei conexiuni la baza de date” în browserul dvs. Întreaga pagină este goală, deoarece nu pot fi preluate date pentru a reda pagina, deoarece conexiunea nu funcționează corect. Acest lucru nu numai că distruge front-end-ul site-ului dvs., dar vă va împiedica și să accesați tabloul de bord WordPress.

Deci de ce se întâmplă exact acest lucru? Ei bine, iată câteva motive comune mai jos.

• Cea mai frecventă problemă este că datele dvs. de conectare la baza de date sunt incorecte . Site-ul dvs. WordPress folosește informații de conectare separate pentru a se conecta la baza de date MySQL.
• Baza de date WordPress este coruptă. Cu atât de multe părți mobile cu teme, pluginuri și utilizatori care le șterg și le instalează în mod constant, uneori bazele de date sunt corupte. Acest lucru se poate datora unui tabel lipsă sau corupt individual, sau poate că unele informații au fost șterse accidental.
• Este posibil să aveți fișiere corupte în instalarea dvs. WordPress. Acest lucru se poate întâmpla chiar și uneori din cauza hackerilor.
• Probleme cu serverul de baze de date. O serie de lucruri ar putea fi greșite la nivelul gazdelor web, cum ar fi baza de date supraîncărcată de la o creștere a traficului sau nu răspunde din cauza prea multor conexiuni simultane. Acest lucru este de fapt destul de comun cu gazdele partajate, deoarece folosesc aceleași resurse pentru mulți utilizatori pe aceleași servere.

Consultați postarea noastră detaliată despre cum să remediați eroarea de stabilire a unei conexiuni la baza de date în WordPress.

5. Verificați-vă pluginurile și temele

Pluginurile și temele terță parte pot cauza cu ușurință 500 de erori interne ale serverului. Am văzut că toate tipurile le cauzează aici la Kinsta , de la pluginuri de glisare la pluginuri de rotație de anunțuri. De multe ori ar trebui să vedeți eroarea imediat după ce instalați ceva nou sau executați o actualizare. Acesta este unul dintre motivele pentru care recomandăm întotdeauna utilizarea unui mediu de pregătire pentru actualizări sau cel puțin rularea actualizărilor una câte una. În caz contrar, dacă întâmpinați o eroare internă de server 500, vă zgâriați brusc să aflați care a cauzat-o.

Câteva moduri prin care puteți depana acest lucru sunt dezactivarea tuturor pluginurilor. Amintiți-vă, nu veți pierde nicio dată dacă pur și simplu dezactivați un plugin. Dacă încă vă puteți accesa administratorul, o modalitate rapidă de a face acest lucru este să navigați la „Plugin-uri” și să selectați „Dezactivare” din meniul de acțiuni în bloc. Acest lucru va dezactiva toate pluginurile dvs.

Dacă acest lucru rezolvă problema, va trebui să găsiți vinovatul. Începeți să le activați unul câte unul, reîncărcând site-ul după fiecare activare. Când vedeți revenirea erorii interne de server 500, ați găsit pluginul care se comportă prost. Puteți contacta apoi dezvoltatorul de plugin pentru ajutor sau puteți publica un bilet de asistență în depozitul WordPress.

Dacă nu vă puteți autentifica la administratorul WordPress, puteți să faceți FTP pe serverul dvs. și să redenumiți folderul cu pluginuri la ceva de genul plugins_old. Apoi verificați din nou site-ul dvs. Dacă funcționează, atunci va trebui să testați fiecare plugin unul câte unul. Redenumiți folderul plugin-uri înapoi la „plugin-uri” și apoi redenumiți fiecare folder de plugin din interiorul acestuia, unul câte unul, până îl găsiți. Ați putea încerca, de asemenea, să reproduceți acest lucru pe un site de staging mai întâi.

Asigurați-vă întotdeauna că pluginurile, temele și nucleul WordPress sunt actualizate. Și verificați pentru a vă asigura că rulați o versiune de PHP acceptată. Dacă se dovedește a fi un conflict cu codul prost dintr-un plugin, ar putea fi necesar să apelați un dezvoltator WordPress pentru a remedia problema.

6. Reinstalați WordPress Core

Uneori, fișierele de bază WordPress pot fi corupte, în special pe site-urile mai vechi. De fapt, este destul de ușor să reîncărcați doar nucleul WordPress fără a vă afecta pluginurile sau temele. Avem un ghid aprofundat cu 5 moduri diferite de a reinstala WordPress. Și, desigur, asigurați-vă că faceți o copie de rezervă înainte de a continua. Treceți la una dintre secțiunile de mai jos:

• Cum să reinstalați WordPress din tabloul de bord WordPress, păstrând în același timp conținutul existent
• Cum să reinstalați manual WordPress prin FTP, păstrând în același timp conținutul existent
• Cum să reinstalați manual WordPress prin WP-CLI, păstrând în același timp conținutul existent

7. Eroare de permisiuni

O eroare de permisiuni cu un fișier sau folder de pe serverul dvs. poate provoca, de asemenea, să apară o eroare internă de server 500. Iată câteva recomandări tipice pentru permisiuni atunci când vine vorba de permisiunile pentru fișiere și foldere în WordPress:

• Toate fișierele ar trebui să fie 644 (-rw-r–r–) sau 640.
• Toate directoarele ar trebui să fie 755 (drwxr-xr-x) sau 750.
• Niciun director nu ar trebui să primească vreodată 777, chiar și directoare de încărcare.
• Hardening: wp-config.php ar putea fi, de asemenea, setat la 440 sau 400 pentru a împiedica alți utilizatori de pe server să îl citească.

Consultați articolul WordPress Codex despre modificarea permisiunilor fișierelor pentru o explicație mai aprofundată.

Puteți vedea cu ușurință permisiunile pentru fișiere cu un client FTP (după cum se vede mai jos). Puteți, de asemenea, să contactați echipa de asistență pentru gazdă WordPress și să le cereți rapid permisiunile pentru fișierele GREP pentru folderele și fișierele dvs. pentru a vă asigura că sunt configurate corect.

8. Limită de memorie PHP

O eroare internă de server 500 ar putea fi cauzată și de epuizarea limitei de memorie PHP de pe serverul dvs. Puteți încerca să creșteți limita. Urmați instrucțiunile de mai jos despre cum să modificați această limită în cPanel, Apache, fișierul dvs. php.ini și fișierul wp-config.php .

Creșteți limita de memorie PHP în cPanel

Dacă rulați pe o gazdă care utilizează cPanel, puteți schimba cu ușurință acest lucru din interfața de utilizare. Sub Software, faceți clic pe „Select PHP Version”.

Faceți clic pe „Switch to PHP Options”.

Puteți apoi să faceți clic pe atributul memory_limit și să îi modificați valoarea. Apoi faceți clic pe „Salvați”.

Creșteți limita de memorie PHP în Apache

Fișierul .htaccess este un fișier ascuns special care conține diverse setări pe care le puteți utiliza pentru a modifica comportamentul serverului, până la un nivel specific de director. Mai întâi conectați-vă la site-ul dvs. prin FTP sau SSH, aruncați o privire la directorul rădăcină și vedeți dacă există un fișier .htaccess acolo.

Dacă există, puteți edita acel fișier pentru a adăuga codul necesar pentru creșterea limitei de memorie PHP. Cel mai probabil este setat la 64M sau mai jos, puteți încerca să creșteți această valoare.

 php_value memory_limit 128M

Creșteți limita de memorie PHP în fișierul php.ini

Dacă cele de mai sus nu funcționează, puteți încerca să editați fișierul php.ini . Conectați-vă la site-ul dvs. prin FTP sau SSH, accesați directorul rădăcină al site-ului dvs. și deschideți sau creați un fișier php.ini .

Dacă fișierul era deja acolo, căutați cele trei setări și modificați-le dacă este necesar. Dacă tocmai ați creat fișierul sau setările nu sunt găsite nicăieri, puteți lipi codul de mai jos. Puteți modifica, desigur, valorile pentru a răspunde nevoilor dumneavoastră.

 memory_limit = 128M

Unele gazde partajate ar putea necesita, de asemenea, să adăugați directiva suPHP în fișierul dvs. .htaccess pentru ca setările fișierului php.ini de mai sus să funcționeze. Pentru a face acest lucru, editați fișierul .htaccess , situat și la rădăcina site-ului dvs. și adăugați următorul cod în partea de sus a fișierului:

 <IfModule mod_suphp.c> suPHP_ConfigPath /home/yourusername/public_html </IfModule>

Dacă cele de mai sus nu au funcționat pentru dvs., este posibil ca gazda dvs. să aibă setările globale blocate și, în schimb, să fie configurată pentru a utiliza fișierele .user.ini . Pentru a edita fișierul .user.ini , conectați-vă la site-ul dvs. prin FTP sau SSH, accesați directorul rădăcină al site-ului și deschideți sau creați un fișier .user.ini . Apoi puteți lipi următorul cod:

 memory_limit = 128M

Creșteți limita de memorie PHP în wp-config.php

Ultima opțiune nu este una pentru care suntem fani, dar dacă toate celelalte nu reușesc, poți să o încerci. Mai întâi, conectați-vă la site-ul dvs. prin FTP sau SSH și localizați fișierul wp-config.php, care se află de obicei în rădăcina site-ului dvs.

Adăugați următorul cod în partea de sus a fișierului wp-config.php :

 define('WP_MEMORY_LIMIT', '128M');

De asemenea, puteți să întrebați gazda dacă aveți probleme legate de limita de memorie. Utilizăm instrumentul Kinsta APM și alte metode de depanare aici la Kinsta pentru a ajuta clienții să restrângă ce plugin, interogare sau script ar putea epuiza limita. De asemenea, puteți utiliza propria cheie personalizată New Relic din propria licență.

9. Problemă cu fișierul dvs. .htaccess

Kinsta folosește numai Nginx, dar dacă utilizați o gazdă WordPress care rulează Apache, s-ar putea foarte bine ca fișierul dvs. .htaccess să aibă o problemă sau să fi fost corupt. Urmați pașii de mai jos pentru a recrea unul nou de la zero.

Mai întâi, conectați-vă la site-ul dvs. prin FTP sau SSH și redenumiți fișierul .htaccess în .htaccess_old .

În mod normal, pentru a recrea acest fișier, puteți pur și simplu să re-salvați permalinkurile în WordPress. Cu toate acestea, dacă vă aflați în mijlocul unei erori interne de server 500, cel mai probabil nu vă puteți accesa administratorul WordPress, așa că aceasta nu este o opțiune. Prin urmare, puteți crea un nou fișier .htaccess și puteți introduce următorul conținut. Apoi încărcați-l pe serverul dvs.

 # BEGIN WordPress <IfModule mod_rewrite.c> RewriteEngine On RewriteBase / RewriteRule ^index\.php$ - [L] RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule . /index.php [L] </IfModule> # END WordPress

Consultați Codexul WordPress pentru mai multe exemple, cum ar fi un fișier .htaccess implicit pentru mai multe site-uri.

10. Erori de codare sau de sintaxă în scriptul dvs. CGI/Perl

500 de erori cauzate de erori în CGI și Perl sunt mult mai puțin frecvente decât înainte. Deși merită menționat, mai ales pentru cei care folosesc cPanel, unde încă se folosesc o mulțime de scripturi CGI cu un singur clic. După cum spune AEM pe Stack Overflow:

CGI a fost înlocuit cu o mare varietate de tehnologii de programare web, inclusiv PHP, diverse extensii Apache precum mod_perl, Java cu diverse arome și cadre, inclusiv Java EE, Struts, Spring etc, cadre bazate pe Python precum Django, Ruby on Rails și multe alte cadre Ruby și diverse tehnologii Microsoft.

Iată câteva sfaturi atunci când lucrați cu scripturi CGI:

• Când editați, utilizați întotdeauna un editor de text simplu, cum ar fi Atom, Sublime sau Notepad++. Acest lucru asigură că rămân în format ASCII.
• Asigurați-vă că sunt utilizate permisiunile corecte ale chmod 755 pentru scripturile și directoarele CGI.
• Încărcați scripturile dvs. CGI în modul ASCII (pe care îl puteți selecta în editorul dvs. FTP) în directorul cgi-bin de pe serverul dvs.
• Confirmați că modulele Perl de care aveți nevoie pentru script-ul dvs. sunt instalate și acceptate.

11. Problemă cu serverul (consultați gazda)

În cele din urmă, deoarece pot apărea și 500 de erori interne ale serverului de la expirarea timpului PHP sau erori fatale PHP cu pluginuri terță parte , puteți oricând să verificați cu gazda dvs. WordPress. Uneori, aceste erori pot fi dificil de depanat fără un expert. Iată doar câteva exemple comune ale unor erori care declanșează 500 de coduri de stare HTTP pe server, care ar putea să te facă să te zgârie.

 PHP message: PHP Fatal error: Uncaught Error: Call to undefined function mysql_error()...

 PHP message: PHP Fatal error: Uncaught Error: Cannot use object of type WP_Error as array in /www/folder/web/shared/content/plugins/plugin/functions.php:525

Monitorizăm toate site-urile clienților aici la Kinsta și suntem notificați automat când apar aceste tipuri de erori . Acest lucru ne permite să fim proactivi și să începem să remediem problema imediat. De asemenea, folosim gazde gestionate LXD și containere software LXC orchestrate pentru fiecare site. Aceasta înseamnă că fiecare site WordPress este găzduit în propriul său container izolat, care are toate resursele software necesare pentru a-l rula (Linux, Nginx, PHP, MySQL). Resursele sunt 100% private și nu sunt partajate cu nimeni altcineva sau chiar cu propriile site-uri.

Timeout-urile PHP pot apărea și din lipsa lucrătorilor PHP , deși, de obicei, aceștia cauzează erori 504, nu erori 500. Acestea determină câte solicitări simultane poate gestiona site-ul dvs. la un moment dat. Pentru a spune simplu, fiecare solicitare nememorizată în cache pentru site-ul dvs. este gestionată de un lucrător PHP.

Când lucrătorii PHP sunt deja ocupați pe un site, încep să formeze o coadă. Odată ce ați atins limita de lucrători PHP, coada începe să împingă cereri mai vechi, care ar putea duce la 500 de erori sau cereri incomplete. Citiți articolul nostru detaliat despre lucrătorii PHP.

Monitorizați-vă site-ul

Dacă sunteți îngrijorat de aceste tipuri de erori care se vor întâmpla pe site-ul dvs. în viitor, puteți utiliza și un instrument precum updown.io pentru a monitoriza și a vă anunța imediat dacă apar. Trimite periodic o solicitare HTTP HEAD la adresa URL la alegere. Puteți utiliza pur și simplu pagina dvs. de pornire. Instrumentul vă permite să setați frecvențele de verificare pentru:

• 15 secunde
• 30 de secunde
• 1 minut
• 2 minute
• 5 minute
• 10 minute

Vă va trimite un e-mail dacă și când site-ul dvs. se defectează. Iată un exemplu mai jos.

Acest lucru poate fi util mai ales dacă încercați să depanați un plugin defect sau dacă vă aflați pe o gazdă partajată, care are tendința de a-și supraaglomera serverele. Acest lucru vă poate oferi o dovadă a cât de des s-ar putea ca site-ul dvs. să se deterioreze (chiar și în miezul nopții). De aceea, vă recomandăm întotdeauna să mergeți cu o gazdă WordPress gestionată. Asigurați-vă că consultați postarea noastră care explorează primele 9 motive pentru a alege găzduirea WordPress gestionată.

rezumat

500 de erori interne ale serverului sunt întotdeauna frustrante, dar sperăm că acum cunoașteți câteva modalități suplimentare de a le depana pentru a vă reporni rapid site-ul. Amintiți-vă, de obicei, aceste tipuri de erori sunt cauzate de pluginuri terță parte, erori PHP fatale, probleme de conectare la baza de date, probleme cu fișierul dvs. .htaccess sau limitele de memorie PHP și, uneori, expirări PHP.

A fost ceva ce ne-a scapat? Poate aveți un alt sfat pentru depanarea a 500 de erori interne ale serverului. Dacă da, anunțați-ne mai jos în comentarii.