Every one of these errors looks like a cryptic wall of text to a visitor, but each one is actually a fairly specific signal about where, in the chain between browser and server, something broke. Knowing which error you’re looking at narrows the fix dramatically — a 502 and a 403 are almost never caused by the same thing, even though both just look like “the site is broken” from the outside.

This guide covers the errors you’ll actually encounter running a website, what each one specifically means, and the troubleshooting steps in the order that resolves them fastest.

1. How to Use This Guide

Find the exact error code or message you’re seeing in the table of contents above and jump straight there — each section is self-contained. If you’re not sure which error you’re dealing with, check your browser’s address bar and page title first; most errors display their status code prominently, even if the page styling around it varies by host or CDN.

2. 500 Internal Server Error

Per the HTTP specification, a 500 is a generic “catch-all” response, used when the server hit an unexpected problem but can’t identify a more specific 5xx error to return instead. It’s the least specific error on this list, which makes it the hardest to diagnose from the error page alone — the real cause is almost always found in your server’s error log, not the error page itself.

# What you'll see in your server's PHP error log:
PHP Fatal error:  Allowed memory size of 268435456 bytes exhausted
(tried to allocate 20480 bytes) in /home/user/public_html/wp-includes/file.php
on line 123

Your host’s control panel almost always has an error log viewer (Errors log in cPanel, or an equivalent in Plesk or a custom panel) — check it first rather than guessing, since the exact cause is usually stated directly in the log.

3. 502 Bad Gateway

A 502 specifically means a server acting as a gateway or proxy received an invalid or malformed response from the upstream server it was trying to reach. This distinguishes it from a plain 500: a 502 tells you the failure happened somewhere in a proxy chain, not directly in your application code.

• Check if a CDN or reverse proxy sits in front of your origin server (Cloudflare and similar services are the most common cause of seeing a 502 specifically, rather than a plain 500) — the proxy is reporting that your actual server gave it a bad response
• Restart PHP-FPM or your application’s process manager, if you have access to do so, since a crashed or overloaded backend process is a frequent cause
• Check for a recently deployed code change or plugin update that could be causing the origin server to error out
• Check your origin server’s resource usage — CPU or memory exhaustion at the origin can cause it to drop or malform its response to the proxy in front of it

4. 503 Service Unavailable

A 503 means the server is temporarily not ready to handle the request — explicitly a temporary-condition status code, ideally paired with a Retry-After header telling clients when to try again. Common legitimate causes include scheduled maintenance mode and the server intentionally shedding load when it’s overloaded, as backpressure to avoid a full crash.

• Check if your site (or a plugin) was put into maintenance mode deliberately and never taken back out
• Check server resource usage — a 503 under real traffic often means the server hit a connection or resource limit and is intentionally rejecting new requests rather than crashing outright; see our traffic spike guide if this is happening during a genuine surge
• Check for a runaway process or infinite loop in recently changed code consuming all available resources
• If it’s intermittent under normal traffic, this is often a sign the hosting plan’s resource allocation is genuinely undersized for the site’s actual load

5. 504 Gateway Timeout

A 504 is closely related to a 502, with one specific difference: instead of receiving a bad response from the origin server, the proxy or gateway received no response at all within its timeout window. The origin server may still be working — it’s just taking too long to respond.

• Identify what’s actually slow — a long-running database query, an external API call your site depends on, or a resource-intensive script are the most common causes of a request that never completes in time
• Check your server and proxy timeout settings — if a legitimate operation genuinely needs more than the default timeout window, the timeout value itself (not just the code) may need adjusting
• Look for a recent change involving a slow external dependency — a payment gateway, a third-party API, or an external data feed that’s currently slow or down can cause your otherwise-healthy server to time out waiting on it
• Rule out a client-side issue — if the site loads fine for others but times out for you specifically, check your own network or VPN before assuming it’s server-side

6. 403 Forbidden and 404 Not Found

These are 4xx client errors rather than 5xx server errors — the server responded successfully, but the specific request couldn’t be fulfilled as asked.

403 Forbidden

The server understood the request but is refusing to authorize it. On hosting specifically, this is most often caused by incorrect file/folder permissions, a missing or misconfigured index file in a directory, an IP block from a security plugin or firewall rule, or a .htaccess rule explicitly denying access.

404 Not Found

The requested URL doesn’t exist on the server. This is usually a genuinely missing or moved page, but it can also follow a migration (see our migration guide) where permalinks or a rewrite configuration didn’t carry over correctly, or a .htaccess issue breaking URL routing for what should be a valid page.

7. Error Establishing a Database Connection

This one is specific to database-driven sites (WordPress and similar CMS platforms) rather than a generic HTTP status code. It means the application can’t reach its database at all — a different failure mode than a slow query or a corrupted table, both of which usually produce a different, more specific error.

Start by verifying credentials, since a recently changed password or a config file that wasn’t updated to match is the single most common cause of this specific error.

8. Cloudflare and CDN-Specific Error Codes

If your site sits behind Cloudflare or a similar CDN/proxy, you may see error codes that don’t appear in the standard HTTP specification — these are the CDN’s own way of being more specific than a generic 502 or 504 about exactly where in the connection to your actual server things broke.

All of these point to a problem between the CDN and your actual hosting server specifically — not the CDN itself, and not your visitors’ connections. Your hosting provider’s support team, not the CDN’s, is usually the right place to start, since the origin server is what these codes are describing.

9. DNS and SSL Errors

These show up as browser-level errors rather than a page your server ever gets to serve, which means the problem is happening before the request even reaches your host.

• DNS_PROBE_FINISHED_NXDOMAIN (or similar “server not found” browser errors) — the domain isn’t resolving to any server at all. Check that your domain hasn’t expired and that nameservers/DNS records are correctly configured; see our DNS explained and DNS propagation guides.
• “Your connection is not private” / SSL certificate errors — usually an expired certificate, a certificate that doesn’t match the domain being accessed, or a certificate chain that isn’t correctly installed. See our SSL certificates guide and free vs. paid SSL comparison.
• Mixed content warnings — the page itself loads over HTTPS but references some resources (images, scripts) over plain HTTP, which browsers flag or block. This is a page-content fix, not a hosting or certificate issue.

10. General Troubleshooting Checklist

• Identified the exact status code or error message, not just “the site is broken”
• Checked your host’s status page for a known, host-wide incident
• Checked your server’s error log for the specific underlying cause
• Identified what (if anything) changed recently — a plugin update, a deployment, a config edit
• Tested from a different network to rule out a local/client-side issue
• Checked resource usage (CPU, memory, database connections) for signs of exhaustion
• Documented the exact error, timestamp, and URL before contacting support, if needed

11. Frequently Asked Questions