Request Investigator: The browser received a 502

Observed symptom

Start with what the user can see

A browser requests https://app.example.com/products/42 and receives HTTP 502 Bad Gateway.

All requests, addresses, identifiers and logs in this exercise are illustrative. Nothing connects to a real service, and no result is saved.

System traceArchitecture for this caseThe components in scope. No failed boundary is marked; inspect the evidence before drawing a conclusion.

BrowserMakes the public HTTPS request
Reverse proxyTerminates TLS and has an upstream target
ApplicationWould handle the product route
Data servicesMay be used by application logic

Scenario assumptions and boundaries

This case uses HTTP/1.1 over TCP. TLS ends at an Nginx reverse proxy, which is configured to forward to an application in the same host and network namespace. No browser cache, service worker or CDN answers this request. Other architectures can take different branches.

Begin with browser-visible evidence

Inspect any observation that helps you separate name resolution, connection setup and HTTP. You do not need to open them in a hidden exact order.

Resolver resultInspect evidence
Resolver result — illustrative evidencetext
```
Illustrative browser resolver result
app.example.com → 192.0.2.10
Expected public address for this case: 192.0.2.10
```
Observation: the browser obtained the expected address for this attempt. Inference: name resolution supplied usable destination information. Unknown: whether every resolver sees the same answer. DNS does not establish a connection.
Connection detailsInspect evidence
Connection details — illustrative evidencetext
```
Illustrative connection details
Remote endpoint: 192.0.2.10:443
TCP connection: established
TLS handshake: completed
Certificate: accepted for app.example.com
```
Observation: TCP and TLS completed between this browser and the public endpoint. Inference: the browser reached the HTTPS endpoint securely. Unknown: whether a separate proxy-to-application connection worked.
HTTP exchangeInspect evidence
HTTP exchange — illustrative evidencetext
```
Illustrative browser Network entry
GET /products/42 HTTP/1.1
Host: app.example.com

HTTP/1.1 502 Bad Gateway
X-Request-ID: cw-502-01
```
Observation: an HTTP response returned with status 502 and a request identifier. Inference: HTTP reached a gateway or proxy that could not obtain a usable upstream response. Unknown: the particular upstream problem; 502 does not identify one root cause.

Decision 1

What does the browser evidence establish?

Choose the strongest statement supported so far. You can open another answer whenever your hypothesis changes.

Only DNS worked; the request never reached HTTP.

Not established by the evidence

The browser received an HTTP 502 after TCP and TLS completed. That confirms more than DNS.

What would support it: This conclusion would require the absence of a connection or HTTP response, such as a DNS or connection error.

You can close this and inspect another hypothesis. No score is recorded.

The browser reached the HTTPS proxy and received its HTTP response; the upstream result is still unknown.

Supported by the evidence

Supported. Browser ↔ proxy is the last confirmed successful exchange at this point. An HTTP error response can travel over a successful connection.

You can close this and inspect another hypothesis. No score is recorded.

The application handled the route and its database failed.

Not established by the evidence

The browser evidence does not show that application code ran or that a database was contacted.

What would support it: Application traces or correlated dependency logs would be needed to support this claim.

You can close this and inspect another hypothesis. No score is recorded.

HTTPS succeeded, so every connection behind the proxy is healthy.

Not established by the evidence

TLS covers the browser-to-proxy connection in this case, not every connection behind it.

What would support it: A successful upstream exchange or application trace would be needed to establish the next boundary.

You can close this and inspect another hypothesis. No score is recorded.

Inspect evidence behind the public response

The request identifier can correlate the browser response with a proxy record. Open the record when you are ready to refine the hypothesis.

Correlated proxy recordInspect evidence
Correlated proxy record — illustrative evidencetext
```
Illustrative proxy log — normalized fields, not literal Nginx output
request_id=cw-502-01
request=GET /products/42
status=502
upstream=http://127.0.0.1:3000
phase=connect
error=ECONNREFUSED (connection refused)
```
Observation: for the same request, the proxy's connection attempt to its configured upstream was refused during connect. Inference: investigation should move to the proxy-to-upstream boundary. Unknown: whether the process is stopped, listening on another address or port, or a network rule actively rejected the connection.
Available application recordsInspect evidence
Available application records — illustrative evidencetext
```
Illustrative evidence inventory
No application-handler trace for request_id=cw-502-01
No database trace linked to request_id=cw-502-01
```
Observation: no supplied record confirms that this request entered an application handler or queried a database. This absence is consistent with the connect-phase proxy record, but it is not proof that the application or database is globally unhealthy.

Decision 2

What is the next useful check?

Revise the hypothesis using the correlated proxy record. Choose a check that can distinguish the remaining causes.

Change public DNS and wait for caches to expire.

Not established by the evidence

This attempt resolved the expected public endpoint and reached it securely. DNS does not explain the refused connection to 127.0.0.1:3000.

What would support it: A wrong resolver result or failure to reach the intended public endpoint would support investigating DNS.

You can close this and inspect another hypothesis. No score is recorded.

Restart the database because a 502 proves it failed.

Not established by the evidence

Neither the status nor the supplied records establish a database failure.

What would support it: A handler or startup trace showing a failed database dependency would be needed before investigating that boundary.

You can close this and inspect another hypothesis. No score is recorded.

Compare the proxy target with the application's actual listener and startup/deployment records.

Supported by the evidence

Useful next check. Test from the proxy's network context, then compare the observed listener address and port with proxy configuration. This can distinguish an absent listener from a wrong target or active rejection.

You can close this and inspect another hypothesis. No score is recorded.

Increase the proxy timeout because the upstream is slow.

Not established by the evidence

The record shows connection refused during connect, not a timeout while waiting.

What would support it: A connect or response timeout record, together with timing evidence, would support investigating latency or timeout settings.

You can close this and inspect another hypothesis. No score is recorded.

Write the investigation result

A useful report separates observations from remaining possibilities. Reveal this one after you have formed your own summary.

Reveal the investigation summary

Last confirmed successful boundary: The browser reached the HTTPS reverse proxy and received its HTTP response.
First observed failure or uncertainty: The proxy's connection attempt to its configured upstream was refused during the connect phase.
Evidence supporting the conclusion: Expected DNS answer, established TCP and TLS, HTTP 502 with request ID cw-502-01, and the correlated proxy record for that ID.
Plausible causes still open: No listener at the configured target, a wrong address or port, or an active network rejection. The evidence does not choose one.
Next useful check: From the proxy's network context, inspect the intended application's listener and startup state, then compare them with the configured upstream target.

Understand the boundaries

References & further reading3 sourcesPrimary standards and official documentation used for this lesson.

RFC 9110: HTTP Semantics — 502 Bad Gateway (opens in a new tab)
IETF
The meaning of the response status; the specific failure still requires evidence.
Module ngx_http_proxy_module (opens in a new tab)
NGINX
Upstream targets and distinctions between connection errors, timeouts and invalid responses.
Module ngx_http_log_module (opens in a new tab)
NGINX
Configurable access logs. The exercise uses clearly labeled normalized evidence.