18 octombrie 2026 · by Alex M.
Eroarea 500 Internal Server Error este una dintre cele mai frecvente și frustrante probleme pe care le poate întâmpina un administrator de site WordPress. Pagina albă, un mesaj generic de eroare sau un ecran complet gol — toate sunt simptome ale acestui tip de problemă. Vestea bună este că, în marea majoritate a cazurilor, cauza este identificabilă și rezolvabilă fără a pierde date sau a reinstala WordPress de la zero.
În acest ghid complet vei afla cum să diagnostichezi și să rezolvi eroarea 500 în WordPress pe un VPS Linux, pas cu pas, cu comenzi concrete și explicații clare.
Codul HTTP 500 înseamnă că serverul a întâmpinat o condiție neașteptată care l-a împiedicat să proceseze cererea. Spre deosebire de eroarea 404 (pagina nu există), eroarea 500 este pe partea serverului, nu a clientului. Ea poate apărea din cauza:
.htaccess corupt sau configurat greșitDacă ai un VPS NVMe sau VPS SSD cu acces root, ai avantajul că poți inspecta logurile serverului direct — un pas esențial în diagnosticare.
Primul lucru de făcut este să activezi debug-ul WordPress pentru a vedea mesajul exact al erorii.
Conectează-te la VPS prin SSH:
ssh root@IP_SERVER
Deschide fișierul wp-config.php:
nano /var/www/html/wp-config.php
Caută liniile existente legate de WP_DEBUG și înlocuiește-le (sau adaugă-le dacă lipsesc) cu:
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors', 0);
Atenție: Nu activa
WP_DEBUG_DISPLAYpe un site de producție cu trafic real — erorile PHP ar putea fi vizibile utilizatorilor.
După salvare, încearcă să reproduci eroarea, apoi verifică fișierul de log:
cat /var/www/html/wp-content/debug.log
Acesta este primul pas de diagnostic și îți va oferi deseori indicii clare despre cauza problemei.
Indiferent dacă rulezi Apache sau Nginx, logurile serverului sunt sursa principală de informații.
tail -n 50 /var/log/apache2/error.log
# sau pentru site-ul specific:
tail -n 50 /var/log/apache2/exemplu.com-error.log
tail -n 50 /var/log/nginx/error.log
# sau:
tail -n 50 /var/log/nginx/exemplu.com.error.log
tail -n 50 /var/log/php8.1-fpm.log
Caută mesaje de tipul: PHP Fatal error, Maximum execution time, Allowed memory size, Permission denied sau No such file or directory. Fiecare dintre acestea indică o soluție diferită.
Dacă ai nevoie de ajutor cu interpretarea logurilor sau configurarea serverului, serviciul de administrare server de la CLIQHOST poate prelua întregul management tehnic.
Un fișier .htaccess corupt este una dintre cele mai comune cauze ale erorii 500 pe Apache. Pentru a verifica, redenumește temporar fișierul:
cd /var/www/html
mv .htaccess .htaccess_backup
Accesează site-ul în browser. Dacă funcționează, înseamnă că .htaccess era problema. Regenerează-l din WordPress:
WordPress va rescrie automat fișierul .htaccess cu regulile corecte.
Dacă dorești să îl creezi manual, conținutul standard pentru WordPress este:
# 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
Plugin-urile incompatibile sau corupte sunt a doua cauză ca frecvență. Dacă nu poți accesa panoul de administrare WordPress, dezactivează-le din linia de comandă:
cd /var/www/html/wp-content
mv plugins plugins_backup
mkdir plugins
Acum accesează din nou site-ul. Dacă funcționează, reactiveaza plugin-urile unul câte unul pentru a identifica vinovatul:
rm -rf plugins
mv plugins_backup plugins
Apoi, din panoul WordPress, activează plugin-urile pe rând și testează după fiecare.
Dacă ai un plan de shared hosting cPanel, poți dezactiva plugin-urile și prin File Manager din cPanel, fără SSH.
Uneori tema activă poate cauza eroarea 500, mai ales după o actualizare. Schimbă tema din SSH:
cd /var/www/html/wp-content/themes
mv tema-mea tema-mea_backup
WordPress va trece automat la tema implicită (de exemplu, twentytwentyfour). Dacă nici o temă implicită nu există:
wp theme install twentytwentyfour --activate --path=/var/www/html
Această comandă necesită WP-CLI instalat pe server.
Depășirea limitelor de memorie PHP este o cauză frecventă, mai ales pe site-uri cu multe plugin-uri sau cu imagini mari.
php -i | grep memory_limit
php.ini:nano /etc/php/8.1/fpm/php.ini
Modifică sau adaugă:
memory_limit = 512M
max_execution_time = 300
max_input_time = 300
post_max_size = 64M
upload_max_filesize = 64M
Restartează PHP-FPM:
systemctl restart php8.1-fpm
Alternativ, poți adăuga în wp-config.php:
define('WP_MEMORY_LIMIT', '512M');
Sau în .htaccess (dacă folosești Apache):
php_value memory_limit 512M
Dacă resursele VPS-ului tău sunt insuficiente pentru un site WordPress cu mult trafic, poate fi momentul să treci la un VPS NVMe cu mai multă memorie RAM și performanță superioară.
Permisiunile incorecte pot cauza erori fatale. Standardul recomandat pentru WordPress este:
755644600 (sau 640)Corectează permisiunile cu:
find /var/www/html -type d -exec chmod 755 {} \;
find /var/www/html -type f -exec chmod 644 {} \;
chmod 600 /var/www/html/wp-config.php
Verifică și proprietarul fișierelor:
ls -la /var/www/html/
Toate fișierele ar trebui să aparțină utilizatorului sub care rulează serverul web (www-data pe Ubuntu/Debian, apache sau nginx pe CentOS):
chown -R www-data:www-data /var/www/html/
O bază de date coruptă sau un server MySQL oprit pot genera eroarea 500.
systemctl status mysql
# sau:
systemctl status mariadb
Dacă serviciul este oprit:
systemctl start mysql
Adaugă în wp-config.php:
define('WP_ALLOW_REPAIR', true);
Accesează: https://exemplu.com/wp-admin/maint/repair.php
După reparare, elimină obligatoriu linia adăugată din wp-config.php.
wp db repair --path=/var/www/html
wp db check --path=/var/www/html
Pe setări Nginx + PHP-FPM, un socket configurat greșit poate cauza erori 500 sau 502.
Verifică că socket-ul PHP-FPM există:
ls -la /run/php/php8.1-fpm.sock
Verifică configurarea pool-ului:
nano /etc/php/8.1/fpm/pool.d/www.conf
Asigură-te că listen din blocul Nginx se potrivește cu socket-ul:
fastcgi_pass unix:/run/php/php8.1-fpm.sock;
Restartează ambele servicii:
systemctl restart php8.1-fpm
systemctl restart nginx
În unele configurații, un certificat SSL expirat sau greșit configurat poate genera erori 500, mai ales când WordPress are URL-ul setat cu https:// dar certificatul nu mai este valid.
Verifică expirarea:
openssl x509 -enddate -noout -in /etc/letsencrypt/live/exemplu.com/cert.pem
Pentru certificate SSL profesionale și administrate, explorează certificatele SSL de la CLIQHOST.
| Cauză | Soluție rapidă |
|---|---|
.htaccess corupt |
Redenumire + regenerare din Permalink-uri |
| Plugin incompatibil | Dezactivare folder /plugins |
| Temă coruptă | Redenumire folder temă |
| Memorie PHP insuficientă | Crește memory_limit în php.ini |
| Permisiuni greșite | chmod 755/644 + chown www-data |
| Baza de date coruptă | Repair prin wp db repair |
| PHP-FPM oprit | systemctl restart php8.1-fpm |
| Certificat SSL expirat | Reînnoire certificat |
Pentru mai multe sfaturi despre optimizarea și securizarea serverului, vizitează blogul CLIQHOST.
Eroarea 500 Internal Server Error în WordPress poate fi intimidantă la prima vedere, dar cu un proces metodic de diagnosticare — activare WP_DEBUG, inspecție loguri, testare plugin-uri, verificare permisiuni și limite PHP — vei putea rezolva problema în majoritatea cazurilor fără ajutor extern.
Dacă preferi să lași gestionarea serverului pe mâna unor profesioniști, CLIQHOST oferă servicii complete de administrare server și VPS-uri NVMe optimizate pentru WordPress, cu suport tehnic disponibil 24/7. Contactează-ne și îți pregătim o soluție adaptată nevoilor tale.
Real reviews from customers who trust CLIQHOST for performance, reliability and expert technical support.
"We moved our online shop from a foreign host and the difference is night and day — pages load instantly and support replies in minutes, in Romanian."
"Migrated 12 client sites to CLIQHOST. Free migration, zero downtime, and the cPanel setup is exactly what my team needed. Highly recommend."
"Our NVMe VPS handles traffic spikes without a sweat. Full root, local datacenter, and billing in MDL — everything we wanted from a provider."