Overview
A 500 Internal Server Error means your web server reached the application but it failed to run correctly. The real cause is almost always recorded in a log file. This article shows where to look and how to fix common cases.
Before you begin
- Root or sudo access to the Pod.
- Know which stack you are running (Nginx/Apache with PHP-FPM, a control panel, or a language runtime).
Steps
- Read the web server error log first. For Nginx:
bash
sudo tail -n 50 /var/log/nginx/error.log
For Apache:
```bash sudo tail -n 50 /var/log/apache2/error.log
RHEL-family:
sudo tail -n 50 /var/log/httpd/error_log ```
- Check the application/PHP log. PHP-FPM and application logs often contain the real message:
bash
sudo tail -n 50 /var/log/php*-fpm.log
sudo tail -n 50 /var/www/html/storage/logs/*.log
- Confirm PHP-FPM is running (a very common cause):
bash
systemctl status php*-fpm
sudo systemctl restart php*-fpm
- Validate your configuration after any recent edit:
bash
sudo nginx -t
sudo apachectl configtest
- Check file ownership and permissions. Web files should be readable by the web user but not world-writable:
bash
ls -la /var/www/html
sudo chown -R www-data:www-data /var/www/html
- Look at recent changes. A new plugin, theme, deployment or
.htaccess/.user.inirule is a frequent trigger. Revert the last change and retest. - Check disk space and memory — a full disk or OOM kill can produce 500s:
bash
df -h
free -h
- If it is a control-panel site, use the panel's error log viewer and check that the PHP version is compatible with the application.
Troubleshooting
- Problem: Nginx returns 502 instead of 500. Solution: The PHP-FPM backend is down or its socket path is wrong — check the
fastcgi_passsetting and restart PHP-FPM. - Problem: The site works for static files but not PHP. Solution: Confirm the PHP handler is configured and the PHP version required by the app is installed.
Related articles
- [Diagnosing high CPU or memory usage]
- [Disk is full: how to free space]
- [Configuring a TLS / SSL certificate]
