How to Fix 500, 502, 503 and 504 Errors on Your Website

A 500 error means the website's own code or web server failed while handling the request, usually because of a PHP fatal error, a broken .htaccess file or wrong file permissions. A 502 means a proxy such as Nginx or LiteSpeed got no valid answer from PHP-FPM or the app behind it, a 503 means the server is overloaded, in maintenance or out of resources, and a 504 means the backend took too long and the proxy stopped waiting. In every case the fastest fix is to read the error log, which usually names the cause in one line. This guide covers both cPanel shared hosting and an Ubuntu VPS.

Prerequisites

• Shared hosting: your cPanel login.
• VPS or dedicated server: SSH access as root or a sudo user.
• A recent backup, or the ability to restore one with JetBackup in cPanel.
• A note of what changed recently, such as updates, deployments or config edits.

What do 500, 502, 503 and 504 errors mean?

• 500 Internal Server Error is produced by the application or web server. Typical causes are PHP fatal errors, invalid .htaccess directives, permission problems and exhausted memory_limit.
• 502 Bad Gateway is produced by the proxy, such as Nginx, LiteSpeed or Cloudflare. The backend is down, crashed mid-request or listens on a different socket.
• 503 Service Unavailable means the server refuses work. Causes include CloudLinux resource limits, all PHP workers being busy, maintenance mode or a stopped service.
• 504 Gateway Timeout is produced by the proxy. The backend is alive but too slow, often because of a slow database query, an external API call or a long import.

1. What should you check first?

• Every page or one page? If the whole site is affected, suspect the server, PHP or .htaccess. If only one URL fails, suspect that script, plugin or query.
• Constant or intermittent? Intermittent 502, 503 and 504 errors usually point to load, worker limits or memory.
• What changed? Check for plugin or theme updates, a PHP version switch, a code deployment, a config edit or a traffic spike.

If you know what changed, undo it first. That is usually the fastest fix.

2. How do I fix these errors on cPanel shared hosting?

Read the Errors log

In cPanel, open Metrics » Errors, which lists the most recent web server errors for your account. Also check for a file named error_log in public_html or in the folder of the failing script. For WordPress, you can log PHP errors by adding these lines to wp-config.php above the "stop editing" line:

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

Errors are then written to wp-content/debug.log. Set WP_DEBUG back to false when you are done.

Test the .htaccess file

In Files » File Manager, enable Show Hidden Files in Settings, then rename public_html/.htaccess to .htaccess.bak. If the site loads, the file contains an invalid or unsupported directive. Restore it and remove recent additions one at a time. For WordPress, you can also regenerate a clean file under Settings » Permalinks » Save Changes.

Check PHP version and memory limit

An "Allowed memory size exhausted" message or a recent PHP version switch often causes 500 errors. On CloudLinux servers, use Software » Select PHP Version to change the version, and its Options tab to raise memory_limit (for example to 256M). Where that page is not available, use Software » MultiPHP Manager and MultiPHP INI Editor. Older plugins may break on a newer PHP version, so switch back to test.

Fix file permissions (755 / 644)

For security, PHP handlers often refuse to run files that are writable by group or others, for example 777. Folders should be 755 and files 644. If Advanced » Terminal is available in your cPanel, run:

find ~/public_html -type d -exec chmod 755 {} \;
find ~/public_html -type f -exec chmod 644 {} \;

Without Terminal, use Permissions in File Manager on the affected files.

Rule out plugin conflicts

Rename wp-content/plugins to plugins.off to disable all plugins at once. If the site recovers, rename the folder back and disable plugins one by one until the error returns. Do the same with the active theme folder if needed.

Check resource limits (503 and 508)

Open Metrics » Resource Usage. If your account has hit its CPU, memory or entry-process limits, visitors get 503 or 508 errors. To reduce load, enable the LiteSpeed Cache plugin, block abusive bots and remove heavy cron jobs. If the site has simply outgrown the plan, request an upgrade by support ticket or consider a Cloud VPS.

Roll back

Open JetBackup in cPanel and restore the affected files or database from a backup taken before the problem started.

3. How do I fix these errors on a VPS?

Check services and logs

First find your PHP-FPM version. Ubuntu 24.04 ships PHP 8.3 and Ubuntu 22.04 ships PHP 8.1, so adjust the commands below to match your server.

systemctl list-units --type=service 'php*-fpm*'
sudo systemctl status nginx --no-pager
sudo systemctl status apache2 --no-pager
sudo systemctl status php8.3-fpm --no-pager
sudo systemctl status mysql --no-pager

Then read the logs for your web server and PHP-FPM:

sudo tail -n 50 /var/log/nginx/error.log
sudo tail -n 50 /var/log/apache2/error.log
sudo tail -n 50 /var/log/php8.3-fpm.log
sudo journalctl -u php8.3-fpm --since "1 hour ago" --no-pager

502: PHP-FPM is down or its pool is exhausted

A log line such as connect() to unix:/run/php/php8.3-fpm.sock failed means PHP-FPM is stopped, or Nginx points at the wrong socket. Restart PHP-FPM, then confirm the two socket paths match:

sudo systemctl restart php8.3-fpm
grep -R "fastcgi_pass" /etc/nginx/sites-enabled/
grep "^listen" /etc/php/8.3/fpm/pool.d/www.conf

If php8.3-fpm.log shows server reached pm.max_children setting, all PHP workers are busy. Ubuntu's default is only 5. Check the average worker size first, then make sure pm.max_children multiplied by that size fits in your free RAM:

ps -C php-fpm8.3 -o rss= | awk '{s+=$1;n++} END {print s/n/1024 " MB average"}'
sudo cp /etc/php/8.3/fpm/pool.d/www.conf /etc/php/8.3/fpm/pool.d/www.conf.bak
sudo nano /etc/php/8.3/fpm/pool.d/www.conf   # e.g. pm.max_children = 20
sudo php-fpm8.3 -t && sudo systemctl reload php8.3-fpm

504: upstream timeout

The Nginx log shows upstream timed out (110: Connection timed out). The real fix is to find the slow query or external call. To give legitimate long tasks more time, add fastcgi_read_timeout 120s; inside the location ~ \.php$ block. For apps behind proxy_pass, such as n8n or Node.js, use proxy_read_timeout 120s; instead. Also raise max_execution_time in /etc/php/8.3/fpm/php.ini to match, then test and reload:

sudo nginx -t && sudo systemctl reload nginx
sudo systemctl reload php8.3-fpm

Disk full or out of memory

These commands check disk space and inodes, find the largest folders, trim the system journal, and show memory use and any processes the kernel killed:

df -h
df -i
sudo du -xh / --max-depth=1 2>/dev/null | sort -h | tail -n 10
sudo journalctl --vacuum-size=200M
free -h
sudo dmesg -T | grep -iE "out of memory|killed process"

A full disk stops MySQL and PHP sessions from writing. Delete old logs and backups to free space. If the kernel's out-of-memory killer stopped MySQL or PHP-FPM, start them again, lower pm.max_children, and add swap or more RAM. On n8n hosting, a 502 usually means the container stopped. Check it with docker ps -a and docker logs --tail 100 <container>.

Roll back

Always copy a config file before editing it. To undo a change, restore the copy, then test and reload:

sudo cp /etc/php/8.3/fpm/pool.d/www.conf.bak /etc/php/8.3/fpm/pool.d/www.conf
sudo php-fpm8.3 -t && sudo systemctl reload php8.3-fpm

For code deployments, redeploy the previous release or tag. If you cannot reach the server at all, ask for rescue mode by support ticket.

Verify it works

Check the status code and response time:

curl -sS -o /dev/null -w "%{http_code} %{time_total}s\n" https://example.com/
sudo tail -f /var/log/nginx/error.log

You should see 200, or 301/302 for redirects. Test in a private browser window, and purge any CDN or LiteSpeed cache so you are not seeing an old cached error page.

Common problems

• 500 right after a plugin or PHP update → Disable the plugin by renaming its folder, or switch back to the previous PHP version.
• 500 after uploading files by FTP → Reset permissions to 755 for folders and 644 for files.
• Intermittent 502 under traffic → pm.max_children has been reached. Raise it within your RAM budget and add page caching.
• 503 on shared hosting at busy times → Resource limits have been hit. Check Resource Usage, cache pages, block bad bots or upgrade the plan.
• 504 only on imports or reports → Raise fastcgi_read_timeout and max_execution_time, or move the job to a cron or CLI task.

Frequently asked questions

Is a 500 error caused by my site or by the server?

Most 500 errors come from site code, .htaccess or permissions, and the error log will show which. If the log is empty and every site on the account fails, open a ticket.

Why does restarting PHP-FPM fix the 502 only for a while?

A restart clears stuck workers but does not remove the cause. Slow scripts, too few workers or memory exhaustion will fill the pool again, so fix the cause the logs point to.

Can Cloudflare cause 502 or 504 errors?

Cloudflare shows these codes when your origin server fails or responds too slowly, so the fix is almost always on the server. Pause Cloudflare temporarily to test the origin directly.

Need help? Open a ticket at https://cloudesta.com/submitticket.php with the affected URL, the time of the error and the relevant log lines, and our team will investigate.