NGINX Interview Questions: Reverse Proxies, Upstreams, Timeouts, and 502 Errors

NGINX interview questions often start with a simple symptom—“the site returns 502”—and then test whether you can trace a request across the proxy boundary. A strong answer identifies the selected server and location, the upstream target, the timeout or connection result, and the evidence that distinguishes a proxy problem from an application failure.

Use this guide to practice the reasoning, not just directive names.

What does a reverse proxy do in the request path?

A client connects to NGINX; NGINX evaluates the listening socket, server name, and location rules, then either serves the response itself or sends a new request to an upstream. That creates two legs to reason about: client-to-proxy and proxy-to-backend. A successful client connection only proves the first leg worked.

When asked to explain proxy_pass, state the selected location and how the configured URI changes the forwarded request. Do not assume every slash combination is equivalent. Confirm the effective configuration with nginx -T, because included files and location precedence often explain why the request reaches a different upstream than expected.

How do you debug an NGINX 502 response?

A 502 generally means the gateway could not obtain a valid response from the upstream; it does not identify the root cause. Start with the error log at the request timestamp, then test the upstream from the NGINX host and under the relevant network and DNS conditions. Check whether the backend is listening, whether the configured address and port are correct, whether a Unix socket has the right permissions, and whether the application closed or malformed the connection.

1. Record the request path, host header, timestamp, and response status.
2. Use the access log to identify the server/location and upstream address selected.
3. Correlate the error log message with the application log for the same request window.
4. Test name resolution and connectivity from the proxy host, not only from a laptop.
5. Change one layer, repeat the same request, and confirm the upstream response and user-visible outcome.

If the log says “connection refused,” investigate listener state, address, port, and startup timing. If it reports a timeout, determine whether the backend is overloaded, blocked on a dependency, or simply slower than the configured budget. Raising a timeout without observing backend latency can hide a capacity problem and tie up proxy resources longer.

How are upstreams and load balancing tested?

An upstream group names backend servers and lets NGINX distribute requests according to its configured method and health-related behavior. In an interview, clarify whether the workload is stateless, whether a session must stay on one backend, and what “healthy” means. Load balancing cannot make an application safe to retry if a request may have committed a side effect before the connection failed.

For example, imagine three application servers and a POST that charges an account. If the proxy times out after sending the request, it may not know whether the application committed the charge. Do not present automatic retry as a universal fix. Use an idempotency key or application-level deduplication when the operation must be safely repeated, and make retry policy depend on method, failure point, and upstream configuration.

Signal	What it suggests	Next check
Connection refused	No listener at the selected endpoint or an active reject	Backend bind address, port, socket permissions, and startup
Upstream timed out	No response within the relevant timeout	Backend latency, queueing, dependency calls, and timeout budget
Wrong content or route	Unexpected server/location/URI mapping	Effective config, Host header, location selection, proxy_pass URI
Intermittent 502s	One backend or network path may differ	Log the selected upstream and compare instances

Which timeout should you change?

First identify which phase is waiting. NGINX exposes separate controls for connecting to an upstream, sending a request, and reading a response. These are not interchangeable “make it slower” knobs. A connect timeout points toward establishing the upstream connection; a read timeout often reflects waiting for upstream data between reads. Check the exact directive semantics and version documentation before changing production values.

Derive a budget from the request’s end-to-end objective. If a client deadline is 2 seconds, a proxy that waits 30 seconds can consume capacity for work the caller has already abandoned. Include queue time and downstream calls, and leave room for cancellation and response handling. Measure percentiles under representative load; do not infer a good value from one successful manual request.

How do headers and scheme affect proxy behavior?

Applications may need the original host, client address, or original scheme to generate redirects and audit requests. Explain which forwarding headers are set, which trusted proxies may supply them, and how the application validates that trust boundary. Blindly trusting a client-provided forwarding header can let an attacker spoof the apparent source or scheme.

Also inspect TLS termination. If TLS ends at NGINX and the backend sees plain HTTP, the application must receive a trustworthy indication of the external scheme if it builds secure redirects. Verify both the request and response: a proxy configuration can route correctly yet cause redirect loops or cookie-security errors.

How should you answer a configuration-debugging prompt?

Use a compact sequence: trace the request, identify the effective configuration, classify the failure as routing, connection, protocol, or latency, test that layer, and verify recovery. Name the evidence before proposing a fix. For a production change, say how you will validate syntax, reload safely, monitor error rates, and roll back if the expected signal does not improve.

For instance, a new deployment causes intermittent 502s. Compare the access log’s upstream address with the error log and backend health. If failures cluster on one instance, remove or repair that instance through the deployment control plane rather than globally increasing every timeout. If every backend shows elevated latency, inspect the shared dependency and saturation signals before changing NGINX.

Common NGINX interview follow-ups

• Does a 502 prove NGINX is misconfigured? No. It identifies a gateway/upstream response problem; logs and direct-from-proxy tests narrow the cause.
• Should proxy timeouts always be increased? No. First establish the waiting phase, latency distribution, caller deadline, and capacity impact.
• Can the proxy retry every failed request? No. A connection failure does not always prove the application did not perform the operation.
• Why test from the NGINX machine? DNS, routes, firewall rules, and socket permissions differ by execution environment.

Sources and further reading

• NGINX proxy module directives
• NGINX upstream module

Research checked September 23, 2026. Directive behavior depends on configuration and NGINX version; use the effective configuration and version-specific documentation during diagnosis.