502 Bad Gateway: What It Means, Common Causes, and How to Fix It

Application process stopped

• Test first: Call the upstream service locally.
• Corrective action: Start the service and investigate why it stopped.

Wrong upstream host, port, or socket

• Test first: Compare the proxy configuration with the service that is listening.
• Corrective action: Correct the upstream target and validate the configuration.

Origin overload or connection reset

• Test first: Review resource usage and proxy or application logs.
• Corrective action: Remove the bottleneck or restore capacity.

DNS, firewall, network, or TLS failure

• Test first: Check name resolution and connectivity from the gateway.
• Corrective action: Correct the DNS record, firewall rule, network route, or certificate configuration.

Invalid upstream response

• Test first: Review gateway logs and inspect the response generated by the origin.
• Corrective action: Fix malformed headers or invalid application output.

Before restarting services or changing configuration, preserve the affected URL, timestamp, HTTP status code, and relevant logs.

Preserve the URL, timestamp, status code, response headers, and relevant logs before restarting services or editing configuration.

What does a 502 Bad Gateway error mean?

RFC 9110 defines a 502 as a response from a gateway or proxy that receives an invalid response from an inbound server. The browser usually reaches the gateway; the failure occurs between server components.

A typical request path looks like this:

Browser → CDN or load balancer → reverse proxy → application

The component returning the 502 is not necessarily the cause. NGINX, for example, may display it because an application behind it stopped listening.

502 vs. 500, 503, and 504

500 Internal Server Error

The server encountered an unexpected condition while processing the request. The failure occurs inside the server handling that request.

502 Bad Gateway

A gateway or proxy received an invalid response from an upstream server. The failure occurs in the communication between server layers.

503 Service Unavailable

The service is temporarily unable to process the request. This is commonly associated with overload, maintenance, or unavailable capacity.

504 Gateway Timeout

A gateway did not receive a response from the upstream server within the permitted time. The defining problem is the wait for that response.

A slow or interrupted upstream service can produce different codes depending on the intermediary. Do not assume that every timeout will appear as a 502.

If the failing server itself returns 500, use DrMonitor’s separate 500 Internal Server Error guide.

What can a website visitor do about a 502 error?

Visitors cannot repair an origin server, but they can rule out a limited local problem:

1. Reload the page once after a short pause.
2. Open the site in a private window or another browser.
3. Try a different network and temporarily disconnect a VPN or custom proxy.
4. Check the website’s official status page, if it has one.
5. If the error persists on different devices or networks, report the URL and time to the website owner.

MDN’s 502 reference notes that most causes require the server owner, with client networking, firewall, proxy, VPN, or DNS configuration being exceptions. Clearing browser data is not a general server-side fix.

How site owners should diagnose a 502 error

Record the failure before changing anything

Capture the affected URL, time and timezone, status, error page, recent deployment, and request or trace identifier:

date -Is
curl -sS -D - -o /dev/null https://example.com/affected-path

Correlate that timestamp across CDN, proxy, application, PHP-FPM, and system logs. Connection refused, connection reset, upstream closed connection, and invalid header point to different causes.

Separate the public gateway from the origin

Test the public URL, then the origin from an authorized system. If only the public URL returns 502, focus on the CDN, load balancer, proxy, TLS, or network path. If both fail, investigate the origin and application.

When Cloudflare is involved, compare the public response with origin logs and Cloudflare’s available error information. Cloudflare’s official 502/504 troubleshooting guide recommends determining whether the response originated at the origin or Cloudflare before applying a fix.

Do not expose a private origin or permanently bypass a security layer just to test it.

Common causes of 502 errors and how to fix them

The upstream application is down

Confirm that the application, container, or PHP-FPM pool is listening on the expected port or Unix socket. Call its health endpoint from the proxy host. If stopped, restore it and inspect crash, memory, deployment, and dependency logs.

For PHP-FPM environments, use the official PHP-FPM configuration reference when checking worker, slow-log, and request-timeout settings.

The proxy points to the wrong destination

A deployment may change a hostname, port, container address, or socket while the proxy retains the old value. Compare the application’s listener with proxy_pass or the equivalent target, correct the mismatch, and validate before reloading.

The NGINX proxy module documentation defines the upstream and timeout directives; consult it instead of copying an arbitrary timeout value from another installation.

The origin is overloaded or closes connections

Review CPU, memory, worker saturation, database latency, queues, and connection limits. Resets can follow a crash, a target closing an outstanding request, or incompatible keep-alive settings.

AWS documents these and other concrete cases—including malformed target responses, invalid headers, and upstream TLS failures—in its Application Load Balancer troubleshooting guide.

Increasing a proxy timeout may be appropriate only after confirming that the application legitimately needs more time. Otherwise, it can hide a slow query, blocked worker, or failing dependency.

DNS, firewall, network, or TLS blocks the upstream

Resolve the upstream hostname from the gateway. Confirm that firewalls, routes, security groups, and network policies permit the correct port. For HTTPS upstreams, verify certificate name, trust chain, SNI, and TLS versions.

DNS can contribute to a 502 when the gateway resolves its upstream incorrectly or cannot reach the resolved destination. That does not mean every visitor-side DNS problem produces a 502.

The upstream sends an invalid response

An application can return malformed or oversized headers, inconsistent compression metadata, or close mid-response. Identify the rejection in gateway logs, reproduce it directly against the upstream, and fix the application output.

How to verify that the 502 is fixed

Repeat the failed request and confirm the intended success code. Test both origin and public paths when possible, run several external checks, and confirm the original log error has stopped.

Also verify a critical route, such as login, checkout, or an API health endpoint. A healthy homepage does not prove every upstream service recovered.

How to detect future 502 errors earlier

Monitor the public URL users request and, where appropriate, a health endpoint. Retain logs long enough to correlate incidents with deployments. Track application health, saturation, and dependencies alongside external availability.

DrMonitor’s uptime monitoring records HTTP status codes such as 502, treats failed HTTP checks as downtime, and groups consecutive failures in its incident history. It can monitor a specific public URL rather than only a homepage. When HTTP alerts and notification channels are enabled, downtime and recovery notifications can be sent through the configured email, Telegram, or SMS channel.

Do not rely on monitoring to explain the root cause by itself. The status code tells you what the public endpoint returned; proxy, application, and infrastructure logs explain why.

For a wider operational review, use the complete website monitoring checklist.

Related 502 questions

Can a 502 affect only one page or API endpoint?

Yes. A proxy can route different paths to different upstream services. If only /api/ fails while the homepage remains healthy, test that upstream and configure monitoring for the critical route itself.

Can DNS problems cause a 502 Bad Gateway error?

Yes, when the gateway depends on DNS to find its upstream and resolution returns the wrong address or fails in a way the gateway reports as 502. Verify DNS from the gateway environment, not only from a laptop.

CTA

Do not wait for a visitor to report the next gateway failure. Start monitoring your website for HTTP errors with DrMonitor and keep a timestamped history to correlate with your proxy and application logs.

Links Related

How to Fix a 500 Internal Server Error

The Complete Website Monitoring Checklist

DrMonitor Uptime Monitoring