⌚ About 3 min read

View my favorites

Real-world problem · V2

Quick troubleshooting view

What you are seeing

The proxy or front server does not get a valid response from the upstream application server.

Likely causes

Backend arrested
PHP-FPM unavailable
Timeout

First checks

Identify the frontal
Test backend directly
Read the logs proxy and application

Recommended actions

Restore the backend
Correct the Address/port of the proxy
Adapt timesouts only after understanding the cause

Start Symptom → Cause →

BAOI

Contextual technician plan

Identify the frontal

Determine whether Nginx, Apache, CDN or proxy returns 502.

Expected result

“Identify the frontal” should produce an observation that clearly confirms or rules out “Backend arrested”.

If OK

If the observation is normal, lower “Backend arrested” in the ranking and continue with the next distinct check.

If not OK

If the observation is abnormal, keep the evidence and investigate “Backend arrested” first. Related action: Restore the backend.

RiskManual check

Test backend directly

If possible, check the upstream service.

Expected result

“Test backend directly” should produce an observation that clearly confirms or rules out “PHP-FPM unavailable”.

If OK

If the observation is normal, lower “PHP-FPM unavailable” in the ranking and continue with the next distinct check.

If not OK

If the observation is abnormal, keep the evidence and investigate “PHP-FPM unavailable” first. Related action: Correct the Address/port of the proxy.

RiskManual check

Read the logs proxy and application

Look for timeout, connection, or reset.

Expected result

“Read the logs proxy and application” should produce an observation that clearly confirms or rules out “Timeout”.

If OK

If the observation is normal, lower “Timeout” in the ranking and continue with the next distinct check.

If not OK

If the observation is abnormal, keep the evidence and investigate “Timeout” first. Related action: Adapt timesouts only after understanding the cause.

RiskManual check

Check resources

CPU, RAM, workers and connections can be saturated.

Expected result

“Check resources” should produce an observation that clearly confirms or rules out “Reverse proxy misconfigured”.

If OK

If the observation is normal, lower “Reverse proxy misconfigured” in the ranking and continue with the next distinct check.

If not OK

If the observation is abnormal, keep the evidence and investigate “Reverse proxy misconfigured” first.

RiskManual check

✓

Validation after action

Repeat the same validation test after the correction and confirm the original symptom is gone. Validate stability before closing the incident.

↶

Change safety / rollback

Before changing configuration, record the current value and a way back.

When to escalate

Scramble to the host if the backend or server resources are out of your control.

WebIntermediate.

The proxy or front server does not get a valid response from the upstream application server.

Important: relevez toujours le message d’erreur exact et l’heure du problème avant de modifier la configuration. Les actions proposées doivent être adaptées à votre environnement.

Causes probables

Backend arrested
PHP-FPM unavailable
Timeout
Reverse proxy misconfigured
Saturated application

Diagnostic étape par étape

1
Identify the frontal
Determine whether Nginx, Apache, CDN or proxy returns 502.
2
Test backend directly
If possible, check the upstream service.
3
Read the logs proxy and application
Look for timeout, connection, or reset.
4
Check resources
CPU, RAM, workers and connections can be saturated.

Solutions possibles

Restore the backend
Correct the Address/port of the proxy
Adapt timesouts only after understanding the cause

Quand escalader ?

Scramble to the host if the backend or server resources are out of your control.

← All les pannes Lancer un diagnostic guidé

Operational context

A 502 Bad Gateway means the proxy, gateway or load balancer could not obtain a valid response from the upstream application. Isolate DNS, edge/proxy health, upstream reachability, TLS/SNI and application response time before changing the public site configuration.

Step-by-step checks

Confirm the failure is specific to one hostname and compare the response from an external client, the reverse proxy itself and a direct request to the upstream service where permitted.
Resolve the public and internal DNS names and verify that the proxy is targeting the intended IP, port and protocol rather than a stale or private address.
Check the upstream TCP/TLS connection, SNI/Host header and certificate chain; a healthy TCP port can still fail when the virtual host or TLS identity is wrong.
Correlate the 502 timestamp with reverse-proxy and application logs, paying attention to connection refused, timeout, premature close and invalid-header messages.

Useful verification commands

Use commands only on systems you administer and capture the read-only output before making a configuration change.

curl -I https://example.com/

curl -vk https://example.com/

nslookup example.com

How to validate the result

The public hostname must return the expected application response through the proxy and the upstream health check must remain stable without connection errors or timeout spikes.

Evidence to keep

Keep DNS answers, response headers, upstream endpoint/port, proxy error log lines, application log lines and the exact UTC/local timestamp of a failed request.

Frequently asked question

Does a 502 mean the website application is always down?

No. The application may be healthy while the reverse proxy uses the wrong address, port, protocol, SNI, certificate trust or timeout policy.

Related BAOI resources: IT tools · procedures · IT dictionary.