Read the status code as a layer clue

A 502 usually means a gateway or reverse proxy received an invalid response from its upstream. A 503 usually means the service is unavailable, overloaded or deliberately refusing traffic. A 504 usually means a gateway waited too long for an upstream response. Exact behavior depends on the proxy and application, so confirm with logs.

Check whether DNS is involved

First confirm that the hostname resolves to the intended public IP and that HTTPS reaches the expected server. If the response is a consistent 502, 503 or 504, DNS is often already working; changing DNS can hide the real origin problem.

Use diagnostics before changing configuration

Record the status code, response time, final URL and response headers. A fast 502 points to an immediate proxy or upstream protocol failure, while a slow 504 points toward a timeout, overloaded application, database or network dependency. Headers can reveal whether the response came from a CDN, proxy or origin.

Trace the request path

Inspect the edge or CDN, reverse proxy, web-server virtual host, upstream socket or port, application process, database and external APIs in order. Check that the proxy target is correct, the upstream is listening, firewall rules allow the connection and the application can finish within the configured timeout.

Check resource and process limits

Review CPU, memory, disk space, file descriptors, worker counts, connection pools and process restarts. A 503 can appear when all workers are busy or a deployment has stopped the application. A 504 can occur when workers are blocked on a slow database or external service.

Compare logs by timestamp

Use the exact request time from the diagnostic result and compare CDN, proxy, web-server and application logs. Look for upstream connection refused, connection reset, timeout, broken pipe, application exception and database errors. Correlating timestamps is more reliable than repeatedly refreshing the page.

Fix and verify one layer at a time

Restore the upstream process or correct its address, adjust an appropriate timeout only after fixing slow work, then test the origin directly where authorized. Re-test the public HTTPS URL, confirm the final URL and check more than one path or hostname. Avoid hiding an application failure with a generic longer timeout.

Common mistakes

Do not treat every 5xx as a DNS problem, assume a 200 response from an unrelated path proves the whole application is healthy, or increase proxy timeouts without measuring the upstream. Keep a rollback plan for configuration changes.

Check real data now

Use the live IIPP tool to inspect the domain or IP address you are working with.

Website Diagnostics →