How do I fix it: Reduce the work per request

Full-page caching means most requests never reach PHP at all, so they cannot produce a `502`. It is the same fix as for [508 errors](/errors/508-resource-limit-is-reached/), and for the same reason: the cheapest request is the one your code never handles.

Error 502 · server

502 Bad Gateway

Q: How do I fix it: Wait sixty seconds and reload

Seriously. A large share of `502`s are a backend restarting, and they clear on their own. If it comes back clean, note the time and check whether it lines up with a deploy or a scheduled task before spending an afternoon on it.

Q: How do I fix it: Read the error log

The `502` page tells you nothing; the log names the cause. Look in your control panel's **Error Log**, and check for these two lines specifically: ``` PHP Fatal error: Allowed memory size of N bytes exhausted PHP Fatal error: Maximum execution time of N seconds exceeded ``` Either one means a script was killed mid-response, which is exactly what produces a `502`.

Q: How do I fix it: Rule out Cloudflare

Pause Cloudflare, or edit your local `hosts` file to point the domain straight at your origin IP, and reload. If the site works directly but not through Cloudflare, the problem is between them — usually your host firewalling Cloudflare's IP ranges. If it fails both ways, Cloudflare is innocent.

In one line

A server in front passed your request to a server behind it, and got back a broken response or none at all.

Ben Johnson · last verified 2026-08-04

Also seen as: Bad Gateway · 502 error · nginx 502

What it actually means

There are two servers involved in a 502. A front-end proxy — nginx, LiteSpeed, Cloudflare, or a load balancer — took your request and forwarded it to a backend that actually builds the page. The backend either failed, returned nonsense, or died mid-response.

So the proxy is working. The thing behind it is not.

That distinction tells you where to look: not at DNS, not at your .htaccess, but at whatever runs your code — PHP-FPM, a Node process, an application server.

If you use Cloudflare, note that Cloudflare shows its own branded 502 when your server is the failing backend. The page says which.

Diagram illustrating server errors on shared web hosting.

Why it happens

The PHP process pool is exhausted or crashed

PHP-FPM runs a fixed pool of worker processes. If they are all busy, or the pool crashed, nginx has nobody to hand the request to and returns 502.

On shared hosting this is closely related to hitting your process limit — you may see 508 and 502 alternating under load.

A script exceeded a limit and was killed

A PHP process killed for exceeding memory or execution time dies without sending a valid response. The proxy sees a truncated reply and reports 502.

This is why 502 often appears on one specific slow page — an import, a report, an image-heavy upload — while the rest of the site is fine.

The backend is restarting

During a deploy, a PHP version change, or a control-panel restart, there is a window where the proxy is up and the backend is not. Brief 502s that clear on their own are usually this and need no action.

Cloudflare cannot reach your origin

If Cloudflare is in front and your host blocks its IPs, or your origin is down, Cloudflare returns a 502-class error. The error page identifies which side failed.

How to fix it

1. Wait sixty seconds and reload

Seriously. A large share of 502s are a backend restarting, and they clear on their own. If it comes back clean, note the time and check whether it lines up with a deploy or a scheduled task before spending an afternoon on it.

2. Read the error log

The 502 page tells you nothing; the log names the cause. Look in your control panel’s Error Log, and check for these two lines specifically:

PHP Fatal error:  Allowed memory size of N bytes exhausted
PHP Fatal error:  Maximum execution time of N seconds exceeded

Either one means a script was killed mid-response, which is exactly what produces a 502.

3. Find the request that is too slow

If one page triggers it, that page is doing too much in one request. Common culprits: an import loop over thousands of rows, image processing, or an external API call with no timeout.

Always bound outbound calls:

$ctx = stream_context_create(['http' => ['timeout' => 3]]);
$body = @file_get_contents($url, false, $ctx);

Without a timeout PHP waits up to default_socket_timeout — 60 seconds — holding a process the whole time.

For genuinely long work, move it out of the request: write a job to a table and process it from a scheduled task.

4. Rule out Cloudflare

Pause Cloudflare, or edit your local hosts file to point the domain straight at your origin IP, and reload.

If the site works directly but not through Cloudflare, the problem is between them — usually your host firewalling Cloudflare’s IP ranges. If it fails both ways, Cloudflare is innocent.

5. Reduce the work per request

Full-page caching means most requests never reach PHP at all, so they cannot produce a 502. It is the same fix as for 508 errors, and for the same reason: the cheapest request is the one your code never handles.

On CWP specifically

Our platform

On CWP a 502 is almost always a PHP process killed for exceeding the 256 MB memory limit or the execution time limit — both are visible in your control panel’s error log with the exact script and line.

Brief 502s during a PHP version change are expected and clear within a minute.

When this means you've outgrown free hosting

Be honest with yourself

Repeated 502s from genuinely heavy work — large imports, video processing, report generation — mean the work does not belong in a web request on shared hosting.

The right fix is usually architectural rather than a bigger plan: move the job to a queue and process it in the background. If you cannot, you need a plan with higher memory and time limits.

Still stuck?

Post the exact error and your account name on the community forum — staff and other users answer there, and the thread helps the next person who hits this.