502 Bad Gateway, 500, 503 and 504 errors: what they mean and how to fix them (2026)

First, the one thing every 5xx error has in common

Status codes that start with 5 mean the server could not complete a request that was otherwise fine. Clearing the browser cache, trying another browser or reinstalling anything on the visitor's computer will not help. The answer is always on the server side: in the application, its settings, or the server it runs on.

On modern hosting, a request usually passes through two layers: a web server such as nginx, which receives the visitor's connection and handles SSL, and the application behind it — PHP-FPM for WordPress and PHP, or your own Node.js, Python or Java process. Knowing which layer produced the error halves the work, and the number tells you.

500 Internal Server Error: the app crashed

A 500 means the request reached your application, and the application failed while handling it. The web server is fine; your code, plugin or configuration is not. Typical causes:

• A PHP fatal error, often after updating a WordPress plugin or theme, or switching to a newer PHP version the code does not support.
• Wrong database details in wp-config.php, .env or settings.py, or a database user without permission.
• A syntax error in a configuration file, or a missing file after an incomplete upload.
• File permissions that stop the app reading its own files (folders 755 and files 644 are normal for websites).
• A Node.js or Python route that throws an unhandled exception for one specific page.

Fix: open the error log — it names the file and line. For WordPress, renaming the newest plugin's folder (or the whole plugins folder) through the File Manager is the fastest test: if the site comes back, re-enable plugins one at a time to find the culprit.

502 Bad Gateway: nothing answered behind the web server

A 502 comes from the web server itself. It tried to pass the request to your app and got no valid answer at all. For WordPress and PHP sites that usually means PHP-FPM is overloaded or restarting. For Node.js, Python and Java apps it almost always means one of these:

• The app is stopped or keeps crashing on start — a missing environment variable, a database it cannot reach, a module that was never installed.
• The app listens on the wrong port. On managed platforms the app must read the port from the PORT environment variable instead of a fixed 3000 or 8000.
• The app listens only on another address, or starts a development server instead of the production one.
• The app ran out of memory and was restarted, and requests arrived while it was down.
• The app is still starting — Java and apps that connect to a remote database can take 20–40 seconds after a restart.

Fix: read the app's own log, not just the web server log. The last lines before the crash almost always say exactly what is missing — "Cannot find module", "ECONNREFUSED", "Missing DATABASE_URL", "address already in use".

503 Service Unavailable: deliberately not serving

A 503 means the server is reachable but declines to serve right now. Common reasons: WordPress left in maintenance mode after an interrupted update (a file called .maintenance in the site folder — delete it), WooCommerce's "coming soon" mode, a site or account suspended by the host (often an unpaid renewal), or a server that is overloaded and shedding traffic. Check your hosting dashboard for notices before touching code.

504 Gateway Timeout: the app was too slow

A 504 means the app did answer — just not in time. Something inside a request takes too long: a slow database query, a call to an external API that hangs, a report or export generated while the visitor waits, or an import that should run in the background. Behind Cloudflare, requests are cut at 100 seconds and shown as Cloudflare error 524.

Fix the slow operation rather than raising timeouts: add database indexes, cache results, set timeouts on external API calls, and move long jobs to a background worker or a scheduled cron job that emails the result.

Cloudflare's 52x errors decoded

If your domain uses Cloudflare, errors arrive with Cloudflare's own numbers. They point to the connection between Cloudflare and your server:

• 520 — the server sent an empty or invalid response (often an app crash mid-response).
• 521 — the server refused the connection: the web server is down or a firewall blocks Cloudflare.
• 522 — connection timed out: the server did not answer at all, or the A record points to the wrong IP.
• 524 — the app took longer than 100 seconds; same fix as a 504.
• 525 / 526 — SSL problems between Cloudflare and the server; check the SSL mode is Full and the server has a valid certificate.

A five-minute checklist for any 5xx error

Work through it in order; most problems are found by step three:

• Is it every page or one page? One page points to code; every page points to the app, server or configuration.
• What changed last? An update, a deploy, a new plugin, a PHP version switch, an expired card — roll that back first.
• Read the error log: the last 50 lines are usually enough.
• Is the app running? Check its status and restart it once — if it crashes again, the log tells you why.
• Is the database reachable, and is the disk or storage full?
• Still stuck? Contact support with the exact time, URL and error number.

Finding the cause on Cloud Ninza

Everything needed is in the dashboard, without a separate control panel. Logs shows each website's access and error logs. App settings shows a Node.js, Python or Java app's status with Start, Stop and Restart, its environment variables and the live output of the last install and build. The File Manager lets you rename a plugin folder, delete a stuck .maintenance file or fix a configuration file in the browser, and the Terminal runs commands such as wp plugin deactivate --all for WordPress.

Apps deployed from Git get a health check after every deploy: if the new release does not answer, the platform rolls back to the previous release automatically, so a bad commit does not leave visitors on a 502. Every project is also backed up twice a day, so a broken update can be undone from Backups in a few clicks.

Preventing the next one

Most 5xx errors are self-inflicted during changes. Update plugins and dependencies on a staging copy or a quiet hour, keep a fresh backup before every big change, read the PORT and database settings from environment variables, set timeouts on every external call, and watch the error log after each deploy for a few minutes. Uptime monitoring that alerts you on the first failure turns a long outage into a short one.

Key takeaways

The short version, for anyone skimming:

• 500 = the app crashed; 502 = nothing answered behind the web server; 503 = deliberately unavailable; 504 = too slow.
• The error log names the cause in nearly every case — read it before changing anything.
• For Node.js and Python apps, a 502 is usually a crash on start, a missing variable or the wrong port.
• Cloudflare's 520–526 errors point to the link between Cloudflare and your server.
• On Cloud Ninza, Logs, App settings, the File Manager and twice-daily backups cover every fix from the dashboard.