Nginx Interview Questions

Analogy categoryAnalogies

Nginx interview questions tend to cluster around a few themes: whether you understand its event-driven architecture well enough to reason about performance, whether you can write and debug real configuration (location matching, proxying, rewrites), and whether you've operated it in production, meaning TLS, logging, and troubleshooting a 502 at 2am. This topic organizes representative questions with model answers across those themes so you can both study for interviews and use them as a checklist of what a working Nginx engineer should actually know.

🏏

Cricket analogy: An interview probing both theory and hands-on config is like a selector testing a player's technique in the nets and also watching how they handle a real match-pressure chase.

Architecture and Concurrency Questions

A very common opener is 'Explain how Nginx handles concurrent connections differently from Apache,' expecting you to describe the master-worker model, the event loop built on epoll/kqueue, and why that keeps memory per connection low. A frequent follow-up is 'What does worker_processes auto do, and how does worker_connections interact with it?' — the answer is that worker_processes auto sets one worker per detected CPU core, and worker_connections sets the max simultaneous connections each worker can hold, so total theoretical capacity is roughly worker_processes × worker_connections, though real capacity is lower once you account for connections used for both client and upstream sides of a proxied request.

🏏

Cricket analogy: worker_processes auto matching CPU cores is like fielding exactly eleven players regardless of format, always sizing the squad to the resource available rather than over- or under-staffing.

Configuration and Location Matching Questions

Interviewers frequently probe location block matching precedence: exact match (location = /path), then the longest prefix match among literal locations, then regex locations evaluated in the order they appear in the config (location ~ or location ~*), with the first matching regex winning and no further regex locations checked, and finally the longest matching non-regex prefix if no regex matched at all. Another classic is 'What's the difference between return and rewrite?' — return issues an immediate response (like a redirect) without further processing, while rewrite modifies the URI and continues processing the request through the remaining config, which can cause unexpected loops if not scoped carefully with the last or break flags.

🏏

Cricket analogy: Location match precedence with exact matches winning first is like DRS reviewing the clearest evidence first, only falling back to secondary angles when the primary replay is inconclusive.

A strong signal in interviews is being able to state the location matching order from memory: exact match (=) first, then longest matching prefix, then the first matching regex (~ or ~*) in config file order, then the previously found longest prefix match as a fallback if no regex matches.

Production Troubleshooting Questions

'A user reports intermittent 502 Bad Gateway errors — how do you debug it?' is a near-universal question. A strong answer starts with checking Nginx's error log (typically /var/log/nginx/error.log) for upstream connection refused, timed out, or reset messages, then checks whether the backend app server is actually running and listening on the expected socket or port, whether it's crashing under load (check its own logs and process supervisor status), and whether proxy_read_timeout is too short for a genuinely slow request. A related question, 'How would you debug a 504 Gateway Timeout,' points specifically at the backend taking longer than proxy_read_timeout to respond, distinguishing it from a 502 where the backend connection itself failed.

🏏

Cricket analogy: Checking error logs first when debugging a 502 is like reviewing the match footage before deciding whether a run-out decision was legitimate, rather than guessing from the scoreboard alone.

A common interview trap is confusing 502 and 504: a 502 Bad Gateway means Nginx could not get a valid response from the upstream at all (connection refused, reset, or malformed response), while a 504 Gateway Timeout means Nginx did connect but the upstream did not respond within proxy_read_timeout. Conflating these two in an answer is an easy way to lose credibility with an interviewer.

bash

# Quick troubleshooting checklist for a 502 Bad Gateway
tail -f /var/log/nginx/error.log
nginx -t                          # validate config syntax
systemctl status my-app.service   # is the backend running?
ss -ltnp | grep 8080              # is it actually listening?
curl -v http://127.0.0.1:8080/health   # can Nginx reach it directly?

Be ready to explain Nginx's master-worker, event-driven architecture and how worker_processes/worker_connections determine capacity.
Know the exact location block matching precedence: exact match, longest prefix, first matching regex in file order, then fallback prefix.
Understand the difference between return (immediate response, no further processing) and rewrite (modifies URI, continues processing).
A 502 Bad Gateway means the upstream connection failed or returned an invalid response; a 504 Gateway Timeout means the upstream didn't respond in time.
Debugging production issues starts with the Nginx error log, then verifying the backend process is running and listening.
Be prepared to discuss TLS termination, rate limiting, and reverse proxy header forwarding as practical operational knowledge.
Interviewers value candidates who can both explain concepts and demonstrate hands-on config debugging.