Nginx Interview Questions

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.

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.

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.

'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.