Nginx Interview Questions

A curated set of Nginx interview questions, from core concepts to practical configuration details.

Q: What's the difference between Nginx acting as a reverse proxy versus a load balancer? As a reverse proxy, Nginx's role is intercepting client requests and forwarding them on behalf of a backend server — handling TLS termination, compression, and hiding the backend's existence from direct exposure, typically for a single backend. As a load balancer, Nginx forwards requests to one of several backend servers in a defined pool (an upstream block), distributing load across them using a strategy like round robin, least connections, or IP hash. In practice a single Nginx config commonly does both at once — proxying and distributing traffic across multiple backends.

Q: How does Nginx decide which location block matches a request, when several could apply? Nginx does not simply use first-match-wins. The order of precedence is: (1) an exact match (location = /path), (2) a prefix match marked with ^~ (which, if it matches, skips regex checking entirely), (3) regex matches (~ case-sensitive, ~* case-insensitive), evaluated in the order they appear in the file, and finally (4) the longest matching plain prefix location if nothing more specific matched. This is a common trip-up: two overlapping prefix locations don't resolve by file order, they resolve by which is longer.

Q: Why forward X-Forwarded-For and X-Real-IP to the backend? Because from the backend application's point of view, every single request otherwise appears to originate from Nginx's own IP address (typically 127.0.0.1 or the proxy's internal IP) — the backend has no way to know the real client IP. This breaks anything that depends on the client's actual address: rate limiting, geo-IP lookups, audit/access logs, and abuse detection. X-Real-IP carries the single IP that connected to Nginx directly; X-Forwarded-For accumulates the full chain of proxies a request passed through, which is why most frameworks prefer it, provided the backend is configured to trust it only from Nginx's known IP.

Q: What does it mean for Nginx to do SSL/TLS termination? It means Nginx accepts the encrypted HTTPS connection from the client, decrypts it, and forwards the request to the backend as plain HTTP over an internal, trusted network — the backend never has to handle certificates or encryption at all. This centralizes certificate management and renewal in one place (often automated via Let's Encrypt/Certbot) instead of configuring TLS on every application server, at the cost of that internal Nginx-to-backend hop being unencrypted, which is normally acceptable within a private network or VPC.

Q: What's the difference between the least_conn and ip_hash load balancing methods, and when would you choose each? least_conn routes each new request to whichever backend currently has the fewest active connections — it's a good general-purpose choice when request processing time varies significantly between requests. ip_hash instead routes a given client's IP consistently to the same backend every time, sacrificing perfectly even load distribution in exchange for "session stickiness" — useful only when a backend holds per-client state in memory that other backends don't share. Where possible, moving session state to a shared store like Redis is preferable to relying on ip_hash, since it lets you use a more effective load balancing method and any server can serve any request.

Q: Why isn't a 301 redirect from HTTP to HTTPS enough on its own, and what does HSTS add? A plain redirect still requires the browser's very first request to go out over unencrypted HTTP before Nginx can respond with the redirect — a brief window where a network attacker could intercept or tamper with that initial request. Strict-Transport-Security (HSTS) is a response header that tells the browser to rewrite every future request to that domain as HTTPS internally, for a configured duration, so subsequent visits never attempt the insecure connection at all. It only takes effect after the first successful HTTPS load, so it hardens repeat visits rather than the very first one.

Q: What does proxy_cache do, and what kind of routes should never be cached this way? It stores a reverse-proxied backend's response in Nginx and serves matching subsequent requests directly from that cache, without contacting the backend again until the entry expires — cutting backend load significantly for responses that are identical across many requests, like a public product listing. Routes serving personalized content (a logged-in dashboard, a cart) or anything that must always reflect the latest state (a payment confirmation) should bypass the cache entirely, since caching them risks serving one user's private or stale response to someone else entirely.

Q: What do the burst and nodelay parameters control on limit_req? The base rate on a limit_req_zone sets the sustained request rate a client is allowed; burst allows a configured number of requests beyond that rate to still be accepted (queued briefly) rather than immediately rejected, absorbing a short, legitimate spike. nodelay changes how queued burst requests are handled — instead of being held and released slowly to smooth the rate, they're served immediately up to the burst limit, after which further requests are rejected outright; without nodelay, burst requests are still accepted but deliberately delayed.

Q: Is turning server_tokens off a meaningful security measure on its own? Only a small one. It removes the Nginx version number from the Server response header and default error pages, denying an attacker easy, passive reconnaissance about which specific version — and therefore which known vulnerabilities — might apply. It does nothing to actually patch or protect the server itself; an outdated Nginx is still just as vulnerable with server_tokens off as without it, so it's a cheap hardening step, never a substitute for keeping the software genuinely up to date.