# 502 Bad Gateway

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

Source: https://cwp.sg/errors/502-bad-gateway/  
Author: Ben Johnson  
Last verified: 2026-08-04

**Also seen as:** Bad Gateway, 502 error, nginx 502

## What it 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.

## 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](/errors/508-resource-limit-is-reached/) 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 `502`s 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 `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.

### 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:

```php
$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](/errors/508-resource-limit-is-reached/), and for the same reason: the cheapest request is the one your code never handles.

## On CWP hosting specifically

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 `502`s during a PHP version change are expected and clear within a minute.

## When this means you have outgrown free hosting

Repeated `502`s 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.

---

Content Website Platform (cwp.sg) operates the free hosting it writes about; see https://cwp.sg/about/ for the methodology and the commercial disclosure.