118 Nginx Interview Questions and Answers (2026)

Nginx is a high-performance, open-source web server that also functions as a reverse proxy, load balancer, and HTTP cache. It was built to handle massive concurrency with low memory using an event-driven architecture.

• Web server: Serves static content (HTML, CSS, JS, images) very efficiently.

• Reverse proxy: Sits in front of application servers, forwarding requests and shielding backends.

• Load balancer: Distributes traffic across upstream servers (round-robin, least connections, IP hash).

• Other common roles: HTTP caching, SSL/TLS termination, API gateway, and serving as a fronting layer for dynamic apps via FastCGI/proxy_pass.

Nginx Open Source is the free community edition with core web server and proxy features; Nginx Plus is the commercial subscription that adds enterprise features, advanced load balancing, and official support.

• Nginx Open Source: Free, community-supported, covers reverse proxy, static serving, and basic load balancing.

• Nginx Plus adds:

  • Active health checks, session persistence, and dynamic reconfiguration of upstreams via an API.

  • Live activity monitoring dashboard and detailed metrics.

  • Advanced caching, clustering/state sharing, and JWT authentication.

  • Commercial 24/7 support.

• Decision driver: Choose Plus when you need enterprise features and support out of the box; otherwise Open Source covers most needs.

Nginx's main benefits are high concurrency with low resource use, versatility as web server and proxy, and stability under load, which is why it's a standard fronting layer in modern infrastructure.

• High performance and low memory: Handles tens of thousands of concurrent connections per worker via the event model.

• Multi-role versatility: Reverse proxy, load balancer, TLS termination, cache, and static server in one binary.

• Scalability and offloading: Absorbs slow clients, caches responses, and buffers requests to protect backends.

• Reliability: Graceful config reloads and worker isolation mean a crash in one worker doesn't take down the server.

• Ecosystem: Mature module system, wide adoption, and strong community/documentation.

Nginx ships in two branches: Mainline gets the newest features and fixes, while Stable receives only critical bug fixes and no new features. Choose based on whether you prioritize latest capabilities or maximum predictability.

• Mainline:

  • Actively developed: gets new features, performance improvements, and the latest bug fixes.

  • Recommended by Nginx for most production use despite the name suggesting otherwise.

• Stable:

  • Only major bug and security fixes are backported; no new features.

  • Best for environments that value minimal change (third-party module compatibility, strict change control).

• Rule of thumb: Use Mainline for latest fixes and features; use Stable when you need a frozen, predictable base.

An NGINX config is a tree of contexts (blocks), where directives placed in outer contexts set global behavior and inner contexts refine it for specific protocols, servers, and URIs. The main flow for HTTP is main → events → http → server → location.

• main context (top level): Global settings like user, worker_processes, pid, and error_log.

• events { }: Connection-processing tuning: worker_connections, use epoll.

• http { }: Wraps all HTTP handling: MIME types, logging, gzip, timeouts, and upstream and server blocks.

• server { }: A virtual host defined by listen and server_name; there can be many.

• location { }: Matches request URIs to apply rules like root, proxy_pass, or try_files.

• upstream { }: Defines a named pool of backend servers for load balancing, referenced by proxy_pass.

A directive is the basic configuration unit in NGINX: an instruction that tells NGINX how to behave, written as a name followed by parameters and terminated with a semicolon (or, for block directives, enclosing a group of further directives in braces).

• Two forms:

  • Simple directive: a name, arguments, and a trailing ;, e.g. worker_processes auto;.

  • Block directive (context): the same but its parameters are enclosed in { } and can contain other directives, e.g. server { ... }.

• Context-scoped: Each directive is valid only in specific contexts; the docs state exactly where each is allowed.

• Provided by modules: Directives come from core and add-on modules, so available directives depend on how NGINX was built.

The include directive splices the contents of another file (or files matching a glob) into the config at that point, keeping configuration modular. The conf.d and sites-available/sites-enabled directories are conventions built on top of include to organize per-site configs.

• include directive:

  • Pulls in files so nginx.conf stays small, e.g. include /etc/nginx/conf.d/*.conf;.

  • Supports wildcards to load many files at once.

• conf.d convention: A directory (typically included from http) where each .conf file is loaded automatically; common on RHEL-family installs.

• sites-available / sites-enabled convention:

  • Debian/Ubuntu pattern: full site configs live in sites-available, and you enable a site by symlinking it into sites-enabled, which NGINX includes.

  • Lets you enable/disable a site by adding or removing the symlink without deleting the config.

You validate a configuration with nginx -t, which parses the full config (following all include files) and checks syntax and basic validity without applying it or restarting the server. Only after it reports success should you reload.

• What nginx -t does:

  • Loads and parses the config, verifies syntax, and confirms referenced files (certs, includes) can be opened, then exits.

  • Reports the file and line number of any error, and prints "syntax is ok" / "test is successful" on success.

• Useful variants:

  • nginx -T: same test but also dumps the entire merged configuration, handy for debugging includes.

  • nginx -t -c /path/conf: test a specific config file.

• Safe apply workflow: Run nginx -t, and only if it passes run nginx -s reload (or systemctl reload nginx), which reloads gracefully without dropping connections.

expires 7d; tells Nginx to add caching headers instructing clients (and proxies) to treat the response as fresh for 7 days, so browsers reuse the cached copy instead of re-requesting it.

• What it sets: Emits an Expires header 7 days in the future and a matching Cache-Control: max-age=604800.

• Effect:

  • Fewer requests and less bandwidth: the browser serves the asset from local cache until it expires.

  • Ideal for static assets (images, CSS, JS), especially versioned/fingerprinted filenames.

• Caveats:

  • Long expiry means updated files may be stale until the URL changes; use cache-busting filenames.

  • Accepts other units/keywords like 1h, max, or off.

Both map a request URI to a filesystem path, but they differ in how the location prefix is treated: root appends the full URI to the given path, while alias replaces the matched location prefix with the given path.

• root: path + full URI:

  • With root /data; a request for /images/a.png resolves to /data/images/a.png.

  • The location prefix stays part of the final path.

• alias: replaces the matched location prefix:

  • With location /images/ { alias /data/; } a request for /images/a.png resolves to /data/a.png.

  • The matched prefix (/images/) is dropped.

• Practical rules:

  • Use alias when the URL path and disk path differ; use root when they line up.

  • With alias inside a regex location you must include the capture in the replacement; alias cannot be used at server level, only in a location.

autoindex makes NGINX generate an HTML directory listing when a request maps to a directory that has no index file. It is off by default and should stay off in most production sites.

• What it does:

  • When autoindex on; and no matching index file exists, NGINX returns an auto-generated page listing the directory contents.

  • Related directives: autoindex_exact_size and autoindex_localtime control how sizes and dates are shown.

• When to enable it:

  • Internal file/download servers, mirrors, or artifact repositories where browsing is intended.

  • Debugging or a trusted intranet share.

• When not to: Public sites: it leaks file names and structure, so leave it off (the default) to avoid information disclosure.

NGINX picks the Content-Type header from a lookup table that maps file extensions to MIME types, loaded from mime.types; anything unknown falls back to a configured default.

• The types table:

  • The types directive (usually via include mime.types; in the http block) maps extensions like .css to text/css.

  • Matching is by file extension only, not by inspecting content.

• The fallback: default_type sets the type for unmatched extensions, commonly application/octet-stream (triggers a download) or text/plain.

• Charset:

  • The charset directive can append ; charset=utf-8 to text types.

  • If a type looks wrong, check that the extension exists in mime.types.

Both change URLs, but a rewrite alters the URI internally (the client usually never knows), while a redirect sends an HTTP 3xx response telling the browser to request a new URL.

• Rewrite (internal):

  • The rewrite directive changes the request URI and NGINX keeps processing internally; no round trip to the client.

  • Used to map pretty URLs to real files or query strings without the browser seeing it.

• Redirect (external):

  • Returns a 301/302 with a Location header; the browser makes a new request and the URL bar changes.

  • Triggered by return 301, or by rewrite ... redirect/permanent, or automatically when the replacement starts with http:// / https://.

• Rule of thumb: internal remapping = rewrite; force the client to a canonical/new address = redirect.

An upstream block defines a named group of backend servers that Nginx can load balance across, so proxy_pass can reference the group by name instead of a single hardcoded address.

• Purpose:

  • Groups multiple servers under one logical name and distributes requests among them.

  • Enables load balancing, health handling, and connection reuse.

• Common options:

  • Load balancing methods: round-robin (default), least_conn, ip_hash.

  • Per-server params: weight, max_fails, fail_timeout, backup.

  • keepalive: reuses connections to upstreams to reduce overhead.

Using Nginx as a reverse proxy centralizes traffic handling in front of your backends, giving you load balancing, security, performance, and flexibility without changing application code.

• Load balancing and scaling: Distributes requests across many backends and lets you add/remove servers behind one endpoint.

• Security and isolation: Hides backend topology, terminates TLS centrally, and can enforce rate limits and access rules.

• Performance:

  • Caching, compression, and connection keepalive offload work from backends.

  • Serves static content directly, freeing app servers for dynamic work.

• Flexibility:

  • Path/host-based routing, header manipulation, and A/B or canary routing at the edge.

  • Buffering slow clients so backends aren't tied up on slow connections.

The weight parameter on a server entry sets how large a share of requests it receives relative to peers: higher weight means proportionally more traffic.

• Default is weight=1 for every server, giving equal distribution.

• Ratios, not absolutes: With weight=3 and weight=1, the first server gets roughly 3 of every 4 requests.

• Use case: Route more load to more powerful hardware, or shift traffic gradually (canary).

• Works with round-robin and least_conn; not meaningful with pure hash (though consistent hash respects it).

The ssl_certificate directive specifies the path to the certificate file (which should contain the leaf plus intermediate chain). It is paired with ssl_certificate_key for the private key.

• ssl_certificate /path/fullchain.pem; points to the PEM-encoded cert chain.

• ssl_certificate_key /path/privkey.pem; points to the matching private key.

• Both can appear multiple times to serve different cert types (e.g. RSA and ECDSA) on the same server.

There is no single "force HTTPS" directive: you create a separate HTTP (port 80) server that issues a permanent redirect to the HTTPS URL, typically with return 301.

• Preferred approach:

  • Use return 301 https://$host$request_uri; in the port 80 server: it is fast and unambiguous.

  • Avoid rewrite and if for this; return is cheaper and clearer.

• Reinforce with HSTS so browsers auto-upgrade future requests before hitting the server.

The allow and deny directives (from the ngx_http_access module) grant or reject requests by client IP, evaluated top to bottom with the first match winning.

• First-match rule: NGINX reads rules in order and stops at the first allow or deny that matches the client.

• Common pattern: allowlist then deny all: List trusted IPs/CIDRs with allow, then finish with deny all.

• Scope: Valid in http, server, location, and limit_except contexts.

• Caveat behind a proxy: The seen IP is the proxy's; use the realip module with X-Forwarded-For to get the true client IP.

auth_basic enables HTTP Basic Authentication: NGINX challenges the client for a username and password and checks them against a password file listed in auth_basic_user_file.

• How the challenge works: Without valid credentials NGINX returns 401 with WWW-Authenticate; the browser prompts and resends the Authorization header on every request.

• The htpasswd file: Lines of user:hashed_password, created with the htpasswd tool (bcrypt/APR1 hashes, not plaintext).

• The realm string: The value of auth_basic is the realm shown in the prompt; set it to off to disable auth in a nested location.

• Security note: Credentials are only base64-encoded, so always serve it over HTTPS.

The stub_status module exposes a lightweight real-time snapshot of NGINX's connection and request activity at a URL, useful for monitoring and feeding metrics into tools like Prometheus.

• What it reports: Active connections, total accepted/handled connections and requests, plus reading/writing/waiting counts.

• How to enable it: Add stub_status in a dedicated location (module is built into most packages).

• Lock it down: Restrict with allow/deny so only internal monitoring can read it.

• Scope: It's basic (open-source) metrics; NGINX Plus adds a richer per-upstream status API.

They control NGINX's two log streams: error_log records server/processing problems and diagnostics, while access_log records every request served. Both can be customized per context and format.

• error_log:

  • Syntax: error_log <path> <level>; the level sets minimum severity recorded.

  • Used for diagnosing failures (upstream errors, config issues, permission problems).

• access_log:

  • Syntax: access_log <path> <format>; logs one line per request.

  • Can be disabled with access_log off;.

• Customization:

  • Define a log_format in the http block using variables, then reference it.

  • Both directives can be placed at http, server, or location level, with inner contexts overriding.

The access log is a per-request record NGINX writes after serving a response, capturing who requested what, when, and the outcome. Its contents depend on the active log_format.

• Typical fields (combined format):

  • Client IP ($remote_addr) and user ($remote_user).

  • Timestamp ($time_local) and the request line ($request: method, URI, protocol).

  • Response status ($status) and bytes sent ($body_bytes_sent).

  • Referer ($http_referer) and user agent ($http_user_agent).

• Common additions for diagnostics: $request_time, $upstream_response_time, $upstream_addr for backend performance.

• Timing note: The line is written when the request completes, so it reflects the final status.

combined is a built-in, predefined log_format (the default); a custom log_format is one you define yourself to include exactly the variables you need.

• combined (built-in):

  • Fixed fields: client IP, user, time, request line, status, bytes, referer, user agent.

  • Used automatically if no format is named in access_log.

• Custom log_format:

  • You choose the variables and layout, e.g. adding timing, upstream, or headers.

  • Enables JSON logs, correlation IDs, or trimming fields for volume.

• When to go custom: Debugging performance, feeding log aggregators, or capturing app-specific headers.

The error_page directive maps HTTP status codes to a custom URI or file, letting you replace default error pages or internally reroute requests to friendlier responses.

• Basic syntax:

  • error_page 404 /404.html; serves a custom page for that code.

  • You can list multiple codes: error_page 500 502 503 504 /50x.html;

• Internal redirects: The target URI is served via an internal request, so pair it with a location block (often marked internal) to prevent direct client access.

• Overriding the response code: Use = to change the status, e.g. error_page 404 =200 /empty.json; turns a 404 into a 200.

• Proxy to a named location or upstream: error_page 502 = @fallback; reroutes to a named location, useful for backend failover pages.

• Inheritance: Valid in http, server, and location contexts; a more specific block overrides the inherited one entirely.

Nginx runs one master process that manages configuration and privileges, and multiple worker processes that do the actual work of handling connections. This separation gives both security and reliability.

• Master process:

  • Runs as root to read config, bind privileged ports (80/443), and read TLS keys.

  • Spawns, monitors, and restarts workers; handles signals for reload and graceful shutdown.

• Worker processes:

  • Run as an unprivileged user and do all request processing via the event loop.

  • Count is set by worker_processes, usually one per CPU core.

• Graceful reloads: On nginx -s reload, the master starts new workers with the new config and lets old workers finish in-flight requests before exiting: zero downtime.

NGINX Unit is a separate, dynamically-configurable application server (and runtime) that runs your application code directly, whereas NGINX (the web server) mainly serves static content and acts as a reverse proxy/load balancer in front of app servers.

• What Unit is:

  • A polyglot application server that runs code for languages like Python, PHP, Go, Node.js, Java, Ruby, and Perl without a separate per-language server.

  • It replaces the app-server tier (e.g. Gunicorn, uWSGI, PHP-FPM).

• Key differences from NGINX web server:

  • Configured entirely via a REST/JSON API over a control socket, with no config file to edit and no reload needed: changes apply live.

  • Executes application code itself; classic NGINX proxies to something that does.

• How they relate: They are complementary: NGINX often sits in front for TLS termination, caching, and static files, proxying dynamic requests to Unit.

The ssi directive can be placed in the http, server, or location context, and you set it to ssi on; to enable Server Side Includes for that scope.

• Scope choice: Put it in http to enable SSI globally, in server for one virtual host, or in location to limit it to specific URIs (common, e.g. only .shtml files).

• Inheritance applies: A setting in an outer context is inherited by inner ones unless overridden.

Directives set in an outer context are inherited by nested (child) contexts, so a value defined once at http applies to every server and location below it. If a child redefines that directive, its value completely replaces the inherited one for that block and its own children (override, not merge).

• Downward inheritance: Applies to directives that support inheritance (many array-style directives like gzip, root); the child sees the parent's value if it doesn't set its own.

• Redefinition replaces, it doesn't accumulate:

  • Setting the directive in a child discards the inherited value entirely for that scope; there is no additive merge.

  • Classic trap: defining add_header in a location drops all add_header values inherited from server, so you must repeat them.

• Not every directive inherits: Some are context-local (e.g. listen, location matching) and only affect the block they appear in.

Nginx variables are named placeholders (prefixed with $) that hold request-time values, letting a single config adapt its behavior per request instead of being hardcoded.

• What they are:

  • Evaluated lazily per request; some are built-in (set by modules), others you create with set, map, or geo.

  • Used in logging, proxy_pass, rewrite, headers, and conditional routing.

• Common built-in variables:

  • $uri and $request_uri: normalized path vs. full original URI with query string.

  • $args, $query_string: the query arguments.

  • $host, $http_host: server name / Host header.

  • $remote_addr, $request_method, $scheme: client IP, HTTP verb, http/https.

  • $http_<name> and $arg_<name>: read any request header or query arg dynamically.

• Caveat: Variables carry a small runtime/memory cost since they are resolved per request; avoid overusing them in hot paths.

The map directive defines a new variable whose value is looked up from the value of another variable, giving you declarative conditional logic without the pitfalls of if.

• How it works:

  • Syntax: map <source> <new_var> { ... } declared at http level.

  • Keys can be exact strings, default, hostname wildcards, or regex (~/~*).

  • Lazily evaluated: the lookup runs only if the derived variable is referenced.

• Why it's preferred over if:

  • No surprising directive inheritance or crashes; it just computes a value.

  • Centralizes many-to-one logic in one readable table instead of scattered if branches.

  • Efficient: internally optimized as a hash/regex lookup.

Nginx serves static files with an efficient event-driven core that maps requests to files on disk using a few path-resolution directives, then streams them (often via sendfile) with minimal overhead.

• root: Defines a base directory; the full path is root + URI. A request for /img/a.png with root /data; serves /data/img/a.png.

• alias: Replaces the matched location prefix rather than appending to it; used to remap a URL to a different directory.

• index: Names the default file to serve for a directory request (e.g. index index.html;).

• try_files: Tries each path in order and serves the first that exists, with a final fallback (a URI or =404).

• Performance features: sendfile, tcp_nopush, open file cache, and gzip reduce syscalls and bytes on the wire.

Nginx typically acts as both a static file server and a reverse proxy: it serves files directly from disk when they exist, and forwards everything else to an application backend, using location blocks to split the two.

• Static content:

  • Served directly with root/alias and sendfile, offloading the app server entirely.

  • Cacheable with expires and compressed with gzip.

• Dynamic content:

  • Proxied to an app via proxy_pass, or to PHP/apps via fastcgi_pass / uwsgi_pass.

  • Nginx buffers responses and handles slow clients so backend workers are freed quickly.

• Routing pattern: Prefix/regex location blocks send asset paths to disk and app paths to the upstream; try_files can serve a file if present else fall back to the app.

try_files checks a list of paths/URIs in order and internally serves the first one that exists, falling back to a last argument if none match: it replaces fragile if -f existence checks.

• How it evaluates:

  • Each argument is tested as a filesystem path relative to root; a trailing / (as in $uri/) tests for a directory.

  • The final argument is the fallback and is treated differently: it's an internal redirect (a URI or named location) or a status code like =404.

• Common uses:

  • SPA fallback: try_files $uri $uri/ /index.html;.

  • Serve file if present, else hand to an app: try_files $uri @backend;.

• Why it's better: Safe and efficient inside location, avoiding the pitfalls of if.

sendfile tells NGINX to copy file data directly from disk to the socket inside the kernel, skipping the round trip through user space and eliminating extra buffer copies.

• Without sendfile: extra copies:

  • Data is read from disk into a user-space buffer, then copied back into a kernel socket buffer to be sent.

  • That context switching and double-copying wastes CPU and memory bandwidth.

• With sendfile on;: zero-copy in the kernel:

  • Uses the sendfile() syscall so the kernel streams the file straight to the socket, no user-space buffer.

  • Lower CPU usage and higher throughput for static assets.

• Common companions:

  • tcp_nopush on; batches the response headers and file into full packets (works with sendfile).

  • Caveat: sendfile bypasses NGINX buffers, so it doesn't help when the response must be filtered/modified (e.g. gzip), and behaves differently over some network filesystems.

NGINX implements virtual hosts with multiple server blocks on the same IP/port; for each request it reads the Host header and matches it against each block's server_name to choose which one handles the request.

• Selection flow:

  1. First NGINX filters server blocks by the matching listen (IP:port).

  2. Among those, it compares the request's Host header to each server_name.

  3. The best matching block serves the request.

• server_name forms: Exact names (example.com), wildcards (*.example.com), and regex (~^www\.).

• No match: If nothing matches, the default_server for that listen handles it (or the first block if none is flagged).

To stop NGINX from serving requests whose Host header matches no defined server_name, define an explicit default_server block that rejects them (typically returning 444).

• Why it matters:

  • Without a catch-all, the first block for that listen silently answers unknown/spoofed Host headers.

  • Blocking them prevents Host-header abuse and unintended exposure.

• How to do it:

  • Add a server block with listen ... default_server; and server_name _; (a non-matching dummy name).

  • Return 444 to close the connection without a response.

The listen directive first narrows candidates to blocks bound to the request's IP and port, and default_server designates which of those handles a request when no server_name matches the Host header.

• listen selects the socket:

  • NGINX matches by the most specific address:port (an explicit IP beats 0.0.0.0).

  • Only blocks sharing that listen compete for the request.

• server_name refines within that group: After the socket is chosen, the Host header is matched against server_name.

• default_server is the fallback:

  • It is a per-listen flag: one block per address:port can hold it.

  • If no server_name matches, the default_server wins; if none is marked, the first defined block for that listen is used.

NGINX evaluates server_name matches in a fixed priority order, stopping at the first winner: exact names first, then wildcards, then regular expressions.

1. Exact name: A literal match like www.example.com always wins if present.

2. Leading wildcard: Names starting with *, e.g. *.example.com.

3. Trailing wildcard: Names ending with *, e.g. www.example.*.

4. Regular expression: Names prefixed with ~, matched in configuration order (first regex to match wins).

• Tie-breaker note: Among wildcards, the longest match is preferred; regex is only consulted when no exact or wildcard matches.

A location block defines how NGINX handles requests whose URI matches a pattern. NGINX does not pick the first match in file order: it applies a fixed precedence where exact and priority-prefix matches can short-circuit, regex matches are tested in file order, and the longest plain prefix is the fallback.

• Match types:

  • Exact: location = /path matches only that exact URI.

  • Priority prefix: location ^~ /path matches a prefix and, if chosen, skips regex checks.

  • Regex: location ~ pattern (case-sensitive) and location ~* pattern (case-insensitive).

  • Plain prefix: location /path with no modifier.

• Precedence order:

  1. Exact = match wins immediately.

  2. Longest ^~ prefix match wins and stops here (no regex tested).

  3. Otherwise, regex locations are tried in the order written; first match wins.

  4. If no regex matches, the longest stored plain prefix match is used.

• Key nuance: NGINX remembers the longest prefix match first, then checks regex; regex beats a plain prefix but not an = or a selected ^~.

A location block selects which set of directives handles a request based on its URI; a rewrite rule modifies the URI itself. One routes, the other transforms.

• location = routing/dispatch:

  • It's a container that groups configuration (proxying, root, headers) applied when its pattern matches.

  • It decides where a request goes, not what its URI becomes.

• rewrite = URI transformation:

  • It rewrites the request path (often with regex capture groups) before or during processing.

  • After a rewrite, NGINX may re-evaluate locations, so the two interact.

• Together: a rewrite inside a location can change the URI, which can then cause a different location to handle it.

Both can change the response, but return immediately stops processing and sends a status or redirect, while rewrite changes the URI and (usually) continues processing. Prefer return for simple redirects because it's faster and clearer; use rewrite when you need regex-based URI transformation.

• return:

  • Ends the request at once: return 301 https://example.com$request_uri; or return 404;.

  • No regex; cheaper and unambiguous, so it's the recommended way to do redirects.

• rewrite:

  • Regex match and replace on the URI: rewrite ^/old/(.*)$ /new/$1;.

  • By default keeps processing (may re-run location matching), enabling internal remapping.

• rewrite flags:

  • last: stop current rewrite set and re-search locations with the new URI.

  • break: stop rewrite processing and stay in the current location.

  • redirect: return a temporary 302 to the client.

  • permanent: return a permanent 301 to the client.

• Guideline: use return for external redirects; use rewrite only when you must transform the path with a pattern.

A named location, written location @name, is an internal-only block that never matches a client URI directly; you jump to it explicitly from other directives. It's used for fallback or error-handling routing.

• Not externally reachable: NGINX won't route an incoming request to @name based on the URL; only internal redirects reach it.

• Invoked internally: Common triggers: try_files ... @fallback; and error_page 404 @fallback;.

• Typical uses:

  • Fall back to a backend (e.g. app server) when a static file isn't found.

  • Centralize error handling or proxy logic that multiple locations reuse.

The ^~ modifier marks a prefix location as high priority: if it's the longest matching prefix, NGINX uses it and skips regex location matching entirely.

• It's still a prefix match: Matches URIs that start with the given string, like a plain prefix location.

• It suppresses regex: Normally a matching regex location would override a plain prefix; with ^~ chosen, regex locations are never tested.

• When to use it: Serving static assets under a path (e.g. location ^~ /static/) where you don't want a regex rule (like a PHP handler) to intercept.

• Precedence note: only an exact = match outranks a selected ^~.

Serve the SPA's static files with a try_files fallback to index.html (so client-side routing works), and put a separate location /api block that proxies to the backend before the catch-all handles it.

• SPA fallback: try_files $uri $uri/ /index.html; returns the file if it exists, else serves index.html so the frontend router handles the path.

• API proxy:

  • A dedicated location /api/ with proxy_pass forwards to the backend and must be matched before the / fallback (longer prefix wins).

  • Forward client info via proxy_set_header (Host, X-Forwarded-For).

• Caching: let static assets cache long, but avoid caching index.html so new deploys are picked up.

As a reverse proxy, Nginx sits in front of backend servers, accepts client requests, forwards them to an upstream, and returns the response: the client only ever talks to Nginx. The core of this is proxy_pass inside a location block, supported by header and buffering directives.

• Request flow: Client hits Nginx, which matches a location, then relays the request to the address in proxy_pass and streams the upstream response back.

• Key directives:

  • proxy_pass: the upstream URL or named upstream to forward to.

  • proxy_set_header: rewrites/forwards headers (e.g. Host, X-Forwarded-For).

  • proxy_read_timeout, proxy_connect_timeout: control how long to wait on the backend.

  • proxy_buffering and proxy_buffers: manage buffering of the upstream response.

proxy_set_header sets or overrides headers sent to the upstream. Because the backend sees Nginx as the client, these headers preserve the original request context (real hostname, client IP, and scheme) that would otherwise be lost.

• Host: Without it, the upstream may receive the proxy_pass hostname. Set proxy_set_header Host $host; so the backend sees the original requested domain (matters for virtual hosts and redirects).

• X-Forwarded-For: Carries the client IP since $remote_addr at the backend would just be Nginx. Use $proxy_add_x_forwarded_for to append the client and preserve any existing chain.

• X-Forwarded-Proto: Tells the backend whether the original request was http or https (set via $scheme) when Nginx terminates TLS, so the app builds correct URLs and honors secure cookies.

• Trust caveat: These headers are client-spoofable, so the backend must only trust them when they come from a known proxy.

WebSockets start as an HTTP request that is upgraded to a persistent bidirectional connection. Nginx supports this by explicitly forwarding the Upgrade and Connection headers and using HTTP/1.1 for the upstream connection.

• The upgrade handshake: Client sends Upgrade: websocket and Connection: Upgrade; Nginx must pass these through for the switch to succeed.

• Required directives:

  • proxy_http_version 1.1; because upgrade requires HTTP/1.1.

  • proxy_set_header Upgrade $http_upgrade; and proxy_set_header Connection "upgrade"; to relay the handshake.

• Long-lived connections: Raise proxy_read_timeout so idle WebSocket connections aren't closed prematurely.

client_max_body_size caps the allowed size of a client request body; if a request exceeds it, Nginx rejects it with 413 Request Entity Too Large before it ever reaches the backend. As a reverse proxy, Nginx's limit must be aligned with the app server's own limit or uploads will fail confusingly.

• How it works:

  • Checks the Content-Length (or the streamed body) against the limit; default is 1m.

  • Settable in http, server, or location (so you can allow large uploads only on specific paths).

• Reverse-proxy implication:

  • There are two limits in play: Nginx's and the app server's (e.g. body limits in the framework). The stricter one wins.

  • If Nginx rejects, the backend never sees the request, so 413s appear even if the app would have accepted it.

• Practical tips:

  • Set 0 to disable the check entirely (use cautiously).

  • Scope large limits to upload routes rather than globally, to limit abuse.

The trailing slash on proxy_pass decides whether the matched location prefix is stripped before forwarding. With a URI (trailing slash or any path) after the host, Nginx replaces the matched location prefix; without it, the full original URI is passed through unchanged.

• With a trailing slash (proxy_pass http://backend/;):

  • The matched location prefix is removed and replaced by the /.

  • Request to /api/users with location /api/ becomes /users at the upstream.

• Without a trailing slash (proxy_pass http://backend;):

  • The original URI is passed unchanged.

  • Request to /api/users is forwarded as /api/users.

• Caveat: The URI-rewrite behavior does not apply when proxy_pass uses variables or when rewrite changes the URI: then you must handle the path explicitly.

proxy_redirect rewrites the Location and Refresh headers in a backend's redirect response so they point at the client-facing URL instead of the internal upstream address.

• The problem it solves:

  • A backend often builds absolute redirect URLs using its own host/port (e.g. http://127.0.0.1:8080/path), which is invisible or wrong for the client.

  • proxy_redirect rewrites that to the public scheme/host (e.g. https://example.com/path).

• Modes:

  • proxy_redirect default (the default): derives the rewrite from proxy_pass and the request Host.

  • proxy_redirect off: leave headers untouched.

  • Explicit form: proxy_redirect http://backend/ / maps old prefix to new.

• When it's needed: backends that emit absolute redirects with an internal address, or when you terminate TLS at NGINX so the backend only knows http.

All three bound how long NGINX waits during different phases of talking to an upstream, and each covers a distinct stage: connecting, sending the request, and reading the response.

• proxy_connect_timeout (default 60s):

  • Time to establish the TCP connection to the upstream. Should be short: a healthy backend accepts connections fast.

  • Cannot exceed 75s in most builds.

• proxy_send_timeout (default 60s): Timeout between two successive write operations while sending the request to the upstream (resets on each successful write, not a total limit).

• proxy_read_timeout (default 60s):

  • Timeout between two successive reads of the response. Also resets per read, so it's an inactivity timeout, not a cap on total response time.

  • Most commonly raised for long-running backends (slow queries, report generation).

• Common gotcha: a 504 Gateway Timeout usually means proxy_read_timeout was hit, while a slow proxy_connect_timeout points to an unreachable or overloaded backend.

These directives control which upstream response headers NGINX forwards to the client: proxy_hide_header suppresses a header, and proxy_pass_header re-enables one that NGINX hides by default.

• Default behavior: NGINX already hides a few upstream headers by default, notably Date, Server, X-Pad, and X-Accel-* (it consumes the X-Accel ones internally).

• proxy_hide_header: Stops a named header from reaching the client, e.g. hide a backend's X-Powered-By or an internal Server version for security.

• proxy_pass_header: Whitelists a header from the default-hidden list so it does reach the client (e.g. proxy_pass_header X-Accel-Redirect is not typical, but you might pass Date).

• To add or overwrite a header sent to the client, use add_header instead; these two only filter what comes from the upstream.

NGINX talks to PHP-FPM over the FastCGI protocol (not HTTP): fastcgi_pass points at the FPM socket, and fastcgi_param supplies the CGI environment variables PHP needs, above all SCRIPT_FILENAME.

• fastcgi_pass: Targets a TCP address (127.0.0.1:9000) or a Unix socket (unix:/run/php-fpm.sock).

• fastcgi_param:

  • SCRIPT_FILENAME tells FPM which PHP file to execute: the single most common misconfiguration.

  • Most params come from the shared fastcgi_params file; include fastcgi_params; pulls in the standard set.

• Security note: use try_files to avoid passing non-existent scripts to FPM, which can enable arbitrary code execution.

They all forward a request to a backend, but each speaks a different protocol; you pick the one matching what your backend understands.

• proxy_pass: Speaks HTTP/HTTPS. Used for app servers, other web servers, or any HTTP backend.

• fastcgi_pass: Speaks the FastCGI protocol. Classic use is PHP-FPM.

• uwsgi_pass: Speaks the uwsgi binary protocol, typically for Python apps behind the uWSGI server.

• grpc_pass: Speaks gRPC over HTTP/2, for proxying gRPC services.

• Common thread: each has its own directive family (proxy_*, fastcgi_*, etc.) for buffering, timeouts, and parameters, and each can target an upstream block for load balancing.

NGINX load balances by defining a pool of backends in an upstream block and forwarding via proxy_pass. The chosen method decides which server handles each request; pick based on whether requests are uniform, unevenly costly, or need session stickiness.

• Round-robin (default):

  • Rotates evenly through servers; add weight= to bias larger nodes.

  • Best when requests are roughly equal in cost and backends are stateless.

• least_conn:

  • Sends the next request to the server with the fewest active connections.

  • Best when request durations vary a lot, so slow requests don't pile up on one node.

• ip_hash:

  • Hashes the client IP so a given client consistently hits the same backend (session stickiness).

  • Best when backends hold local session state and you can't use shared session storage; note it can distribute unevenly behind NAT/proxies.

• Others worth knowing: hash key [consistent] for stickiness on a custom key (e.g. URL), and random (with optional two-choice) for lightweight distribution.

Together they define passive health checking: NGINX watches real client traffic and marks a server unavailable after too many failed attempts within a time window, without sending separate probe requests. max_fails is the failure threshold and fail_timeout is both the counting window and how long the server stays out.

• max_fails: Number of failed communication attempts within fail_timeout that mark the server unavailable (default 1; 0 disables checking).

• fail_timeout: Dual role: the window over which failures are counted, and the duration the server is considered down before NGINX retries it (default 10s).

• How the cycle works: Once failures reach max_fails in the window, NGINX stops routing to that server for fail_timeout, then sends a probe request from real traffic; success reinstates it.

• Passive nature: Failures are detected only from actual proxied requests (defined by proxy_next_upstream); no dedicated health probes are sent, so a fully idle server is never checked.

They control a server's role in the upstream pool: backup makes a server a standby used only when primaries fail, and down marks a server permanently out of rotation.

• backup:

  • The server receives no traffic while any primary is up; it activates only when all non-backup servers are unavailable.

  • Useful for failover capacity (e.g. a slower DR node) you don't want in normal rotation.

  • Not compatible with ip_hash or hash in open-source NGINX.

• down:

  • Permanently marks the server as unavailable so NGINX never routes to it.

  • Handy for taking a node out for maintenance without deleting its config line.

Compression shrinks text-based responses before sending them, reducing bandwidth and speeding up page loads. NGINX supports gzip natively via the ngx_http_gzip_module; Brotli needs the third-party ngx_brotli module.

• gzip configuration:

  • gzip on; enables it.

  • gzip_types lists MIME types to compress (HTML is always included).

  • gzip_comp_level (1-9) trades CPU for smaller output; gzip_min_length skips tiny responses.

• Brotli: brotli on; with brotli_types; typically compresses text better than gzip at comparable levels.

• Benefits:

  • Smaller transfers, faster load times, lower bandwidth cost; the browser signals support via Accept-Encoding.

  • Caveat: don't compress already-compressed formats (JPEG, PNG, video) or you just waste CPU.

NGINX's built-in modules are about handling encoding on the response path, not compressing outgoing requests to upstreams. The ngx_http_gunzip_module does the opposite of what the question implies: it decompresses responses.

• gunzip module:

  • gunzip on; decompresses a gzipped upstream response for clients that sent no Accept-Encoding: gzip.

  • It inflates, it does not compress, and it acts on responses.

• No built-in request compression:

  • NGINX does not gzip the request body it forwards to an upstream out of the box.

  • gzip / brotli apply to responses NGINX sends to clients.

• If an upstream needs a compressed body, that's usually handled by the client/app or a custom module, not standard NGINX directives.

There is no directive that names types to exclude; instead you control compression by listing the types you want to include with gzip_types. To "exclude" a type, you simply leave it off that list.

• gzip_types:

  • Whitelist of MIME types to compress; anything not listed is sent uncompressed.

  • text/html is always compressed and can't be disabled via this directive.

• Related exclusion controls:

  • gzip_min_length skips responses below a size threshold.

  • gzip_disable turns off gzip for clients matching a User-Agent regex (e.g. old browsers).

• Practical rule: omit already-compressed binary types (images, video, archives) from gzip_types.

gzip_static (from ngx_http_gzip_static_module) serves a pre-compressed .gz file from disk instead of compressing the response on each request, saving CPU at request time.

• How it works:

  • With gzip_static on;, a request for app.js checks for a neighboring app.js.gz and serves it directly when the client accepts gzip.

  • You generate the .gz files ahead of time (build step), often at max compression level.

• Difference from on-the-fly gzip:

  • Regular gzip on; compresses dynamically per response, spending CPU every time.

  • gzip_static does no compression at runtime; it only reads a file already compressed.

• When to use:

  • Best for static assets that rarely change; lets you use higher compression than would be cheap on the fly.

  • Not suitable for dynamic content, which has no pre-built file.

Nginx caches upstream responses on disk using proxy_cache. You define a storage area with proxy_cache_path (the cache zone), enable it on a location with proxy_cache, and each cached entry is stored under a key derived from proxy_cache_key.

• Cache zone (proxy_cache_path):

  • Defines the on-disk directory plus a shared memory zone (keys_zone=name:size) that holds keys and metadata in RAM for fast lookup.

  • Also sets max_size, inactive (evict if unused), and levels (directory hashing).

• Cache key (proxy_cache_key):

  • A string built from variables that uniquely identifies a response; default is $scheme$proxy_host$request_uri.

  • Nginx MD5-hashes it to name the cache file; add fields (cookies, query args) if responses vary.

• Enabling and tuning:

  • Use proxy_cache zone_name in the location and proxy_cache_valid to set TTLs per status code.

  • Add $upstream_cache_status to logs to see HIT/MISS/EXPIRED.

Nginx offers several caching subsystems depending on what it is fronting: proxied HTTP responses, FastCGI/uwsgi/SCGI apps, static file metadata, and SSL sessions.

• Content caches (per upstream protocol):

  • proxy_cache: caches responses from proxy_pass backends.

  • fastcgi_cache: caches FastCGI responses (e.g. PHP-FPM).

  • uwsgi_cache and scgi_cache: same idea for those protocols.

• open_file_cache: Caches file descriptors, existence, and metadata (not the content) for static files to save syscalls.

• ssl_session_cache: Caches TLS session parameters to speed up handshake resumption.

• Also worth noting: Nginx can pass caching to clients via expires / Cache-Control headers (browser caching), which is not server-side storage.

fastcgi_cache works exactly like proxy_cache but caches responses from a FastCGI backend (like PHP-FPM) rather than an HTTP backend behind proxy_pass. The concepts and directives are parallel, only the prefix differs.

• Same model, different upstream: proxy_cache caches proxy_pass (HTTP upstreams); fastcgi_cache caches fastcgi_pass (FastCGI apps).

• Parallel directives: fastcgi_cache_path, fastcgi_cache_key, fastcgi_cache_valid, fastcgi_cache_use_stale mirror their proxy_* counterparts.

• Why it matters: For a PHP site, fastcgi_cache caches rendered pages directly, avoiding PHP execution entirely on a HIT (big performance win for WordPress-style apps).

• Analogous families exist for uwsgi_cache and scgi_cache.

SSL/TLS termination means Nginx decrypts inbound HTTPS traffic at the edge and (optionally) forwards it as plain HTTP to backends. You configure a listen 443 ssl server, point it at a certificate and private key, and then tune protocols, ciphers, and session handling for security and performance.

• Core setup:

  • Listen on TLS with listen 443 ssl; and set ssl_certificate (full chain) plus ssl_certificate_key.

  • Serve the full chain (leaf + intermediates) so clients can build trust.

• Security considerations:

  • Restrict protocols: ssl_protocols TLSv1.2 TLSv1.3; (drop SSLv3/TLS1.0/1.1).

  • Use strong ciphers and let TLS 1.3 defaults apply; enforce HSTS to prevent downgrade.

  • Protect the private key file with tight permissions.

• Performance considerations:

  • Enable session resumption (ssl_session_cache) to avoid full handshakes.

  • Enable OCSP stapling to skip client-side revocation lookups.

  • Prefer TLS 1.3 (fewer round trips, 0-RTT) and keep connections alive.

Enable HTTP/2 by adding the http2 parameter to a TLS listen directive (in modern Nginx use the separate http2 on; directive). It requires TLS in practice because browsers only speak HTTP/2 over HTTPS.

• How to enable:

  • Older syntax: listen 443 ssl http2;.

  • Nginx 1.25.1+: listen 443 ssl; plus http2 on;.

• Benefits:

  • Multiplexing: many requests share one connection without head-of-line blocking at the HTTP layer.

  • Header compression (HPACK) reduces overhead.

  • Binary framing and stream prioritization improve efficiency versus text-based HTTP/1.1.

• Note: server push was largely deprecated; don't rely on it.

HSTS (HTTP Strict Transport Security) is set with the Strict-Transport-Security response header via add_header in your HTTPS server. It tells browsers to only ever connect over HTTPS for the specified duration, preventing protocol downgrade and SSL-stripping attacks.

• Configuration:

  • add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;.

  • Use the always flag so the header is sent even on error responses.

• Directive meanings:

  • max-age: seconds the browser enforces HTTPS.

  • includeSubDomains: applies the policy to all subdomains.

  • preload: eligible for browsers' built-in HSTS preload list.

• Caveats:

  • Only serve HSTS over HTTPS (browsers ignore it on plain HTTP).

  • Be careful with includeSubDomains and preload: misconfiguration can lock out subdomains that lack TLS.

Use server_tokens off to strip the NGINX version from the Server header and error pages, and manage other identifying headers deliberately.

• server_tokens off: Set in http, server, or location; hides the version number (header still says nginx).

• Fully removing the Server header: Requires the headers_more module (more_clear_headers Server) since stock NGINX can't delete it.

• Strip backend leaks: When proxying, hide upstream headers with proxy_hide_header X-Powered-By and similar.

• Custom error pages: Use error_page so default branded pages don't reveal the software.

A 502 means NGINX (as a proxy) got an invalid or no response from the upstream, so troubleshooting works backward from the error log to the upstream itself.

1. Check the error log first: Look in error_log for the exact cause: "connection refused", "no live upstreams", or "upstream prematurely closed connection".

2. Verify the upstream is running and reachable: Confirm the backend process/port is up and NGINX can connect (curl the upstream directly, check firewall/socket).

3. Check the proxy target config: Ensure proxy_pass points to the correct host/port and scheme (http vs https).

4. Look at buffer and header limits: Large upstream headers can trigger 502; raise proxy_buffer_size / proxy_buffers.

5. Inspect SELinux/permissions (esp. Unix sockets): SELinux often blocks NGINX from connecting to a backend socket, showing "permission denied".

Effective NGINX debugging combines config validation, log inspection, and targeted tracing rather than guessing.

• Validate the config: Run nginx -t to catch syntax errors, and nginx -T to dump the full effective config (includes resolved).

• Turn up log verbosity: Set error_log to debug (requires --with-debug build) for detailed request processing.

• Use custom access logs: Add $upstream_response_time, $upstream_status, and $request_time to a log_format to isolate slow or failing upstreams.

• Reproduce with precise clients: Use curl -v to inspect headers/status; compare requesting NGINX vs the upstream directly.

• Trace at the OS level: Use strace, tcpdump, or check ss/ports when logs are inconclusive.

NGINX supports conditional logging via the if= parameter on access_log, and can skip logging entirely with access_log off; in the relevant context.

• Disable for specific paths: Put access_log off; in a location (common for static assets, health checks, /favicon.ico).

• Conditional logging with a variable: Use a map to compute a flag, then access_log ... if=$flag; logs only when the value is non-empty and non-zero.

• Typical use cases: Skip 2xx/3xx and log only errors, or exclude noisy monitoring probes to reduce volume.

The error_log level sets the minimum severity that gets written; NGINX has eight levels from most to least severe, and you raise or lower verbosity to balance detail against noise.

• Levels (severe to verbose):

  1. emerg: system unusable.

  2. alert: immediate action needed.

  3. crit: critical conditions.

  4. error: request-level errors (a common default).

  5. warn: warnings.

  6. notice: normal but significant events.

  7. info: informational.

  8. debug: full diagnostic detail (needs a debug build).

• Choosing a level:

  • A level logs its severity and everything more severe (e.g. warn includes error, crit, etc.).

  • Lower to debug/info temporarily when diagnosing a hard problem.

  • Raise to warn or error in production to keep logs small and readable.

Keepalive connections are persistent TCP connections reused across multiple requests instead of opening and closing a new one per request, cutting connection setup overhead.

• Two directions:

  • Client-side: NGINX keeps the browser connection open (keepalive_timeout).

  • Upstream-side: NGINX reuses connections to backend servers via a keepalive directive in the upstream block.

• Why they matter:

  • Avoids repeated TCP three-way handshakes and TLS negotiations, saving latency and CPU.

  • Reduces the number of sockets churning through TIME_WAIT state.

• Upstream caveat: For upstream keepalive to HTTP/1.1 backends you must set proxy_http_version 1.1; and clear the Connection header (proxy_set_header Connection "";).

Together these bound how much a client connection is reused: keepalive_timeout limits idle time before closing, and keepalive_requests limits how many requests one connection may serve before NGINX closes it.

• keepalive_timeout:

  • e.g. keepalive_timeout 65; keeps an idle connection open 65s awaiting the next request.

  • Too low kills reuse (more handshakes); too high ties up sockets on idle clients.

• keepalive_requests: e.g. keepalive_requests 1000; closes the connection after 1000 requests to free per-connection memory and rebalance.

• Connection closes when either limit is hit: Whichever comes first (idle timeout or request count) triggers closure, and the client opens a fresh connection.

• Tuning tradeoff: Higher values favor throughput and lower latency; lower values favor freeing resources under many clients.

Both control resource usage per client: limit_conn caps the number of simultaneous connections, while limit_rate caps the download bandwidth of a single connection.

• limit_conn limits concurrent connections:

  • Requires a shared memory zone defined with limit_conn_zone, keyed by something like $binary_remote_addr.

  • Once the count for a key exceeds the limit, extra connections get 503 (configurable via limit_conn_status).

• limit_rate limits bandwidth per connection:

  • Value in bytes/sec, e.g. limit_rate 100k; applies per connection, so a client opening two connections gets double.

  • Combine with limit_rate_after to send the first N bytes fast, then throttle (good for media so playback starts quickly).

• They solve different problems: Pair limit_conn with limit_rate to bound both how many connections a client holds and how much bandwidth each consumes.

Dynamic modules are compiled as separate .so shared objects that NGINX loads at startup via the load_module directive, so you can add features without recompiling the whole binary.

• Static vs dynamic: Historically all modules were compiled into the binary (--with-...); dynamic modules (--with-...=dynamic) build a loadable .so instead.

• How load_module works:

  • Placed in the main (top-level) context, before events and http, pointing at the module path.

  • Loaded when the config is parsed at start/reload; a bad path or ABI mismatch fails startup.

• Constraints:

  • The module must be built against the exact same NGINX version and build options, or it won't load.

  • Lets you distribute optional features (e.g. ngx_http_geoip2_module) as packages.

Nginx uses an event-driven, asynchronous, non-blocking model: a small number of worker processes each run an event loop that multiplexes thousands of connections instead of dedicating a thread or process per connection.

• Event loop per worker: Each worker uses an OS event notification mechanism (epoll on Linux, kqueue on BSD) to watch many sockets at once.

• Non-blocking I/O: A worker never waits idle on one request; when a socket isn't ready it processes another ready connection.

• State machine, not threads: Each connection is a lightweight state that advances on events, so memory stays low even at high concurrency.

• Workers match CPU cores: Typically one worker per core (worker_processes auto), avoiding context-switch overhead.

• Caveat: Blocking operations (e.g. disk reads) can stall a worker, so Nginx offloads them via thread pools with aio.

The core difference is the connection model: Apache traditionally uses a process/thread-per-connection model, while Nginx uses an event-driven model where a few workers handle thousands of connections. This makes Nginx more memory-efficient under high concurrency.

• Connection handling:

  • Apache (prefork/worker MPM) allocates a thread or process per connection, so memory grows with concurrent clients.

  • Nginx uses asynchronous event loops, keeping memory flat as connections rise.

• Static vs dynamic content: Nginx excels at static files and proxying; Apache can run dynamic code in-process via modules like mod_php.

• Configuration: Apache supports per-directory .htaccess overrides; Nginx uses central config only, which is faster but less flexible.

• Common pattern: Nginx in front as reverse proxy/static server, Apache behind it for dynamic processing.

The C10k problem is the challenge of handling 10,000 concurrent connections on a single server. Traditional thread/process-per-connection servers couldn't scale to it because memory and context-switching costs exploded; Nginx solved it with an event-driven, non-blocking architecture.

• Why the old model failed: One thread/process per connection means 10k connections need 10k threads: huge memory and heavy CPU spent on context switching.

• Nginx's solution: A few workers each run an event loop over epoll/kqueue, multiplexing thousands of connections as cheap state machines.

• Result: Concurrency scales with events rather than threads, so memory stays roughly constant as connections grow.

NGINX uses epoll (Linux) or kqueue (BSD/macOS) as a scalable event notification interface so a single worker process can monitor thousands of connections at once and only act on the ones that are actually ready for I/O, which is the foundation of its event-driven, non-blocking concurrency model.

• The problem they solve: Older APIs like select and poll scan the entire set of file descriptors on every call, so cost grows linearly (O(n)) with connection count.

• How epoll/kqueue differ:

  • You register interest in descriptors once, and the kernel returns only those that became ready, giving roughly O(1) readiness notification regardless of total connections.

  • NGINX blocks in a single call (epoll_wait) until events arrive, then processes each ready connection without idle polling.

• Why it matters for concurrency:

  • One worker handles many thousands of simultaneous connections with a tiny, constant number of threads instead of one thread per connection.

  • Memory and CPU stay flat as idle keep-alive connections pile up, which is why NGINX excels at the C10K problem.

• Configured via use epoll; in the events block, though NGINX auto-selects the best method for the platform.

Both geo and map are directives (in the http block) that compute a new variable from an existing input at request time: geo maps client IP addresses, while map maps the value of any source variable.

• geo module:

  • Sets a variable based on the client IP ($remote_addr by default), matching CIDR ranges.

  • Common for country/region tagging, allowlists, or rate-tiering by network.

• map module:

  • Derives a variable from any source variable using a lookup table, with a default and optional regex keys.

  • Evaluated lazily (only when the derived variable is actually used), so it is cheap.

• Why they matter: They replace nested if logic with declarative, table-driven variables that are safe and fast.

The phrase "if is evil" comes from the Nginx wiki: inside a location block, if belongs to the rewrite module and interacts unpredictably with other directives, so it can silently produce wrong results or crashes.

• Why it's dangerous:

  • It creates an implicit nested location with surprising directive inheritance; other directives inside may be ignored.

  • Combining if with proxy_pass, try_files, or return in the same block can segfault or behave inconsistently.

• When it's safe: Only two uses are guaranteed reliable: return ... and rewrite ... last inside if.

• What to use instead: Prefer map for conditional variables, separate location blocks for routing, and try_files for file existence checks.

NGINX evaluates locations in a strict priority order, not in the order they appear (except for regex, which is order-sensitive among themselves). It finds the best prefix match first, then decides whether regex gets a chance.

1. Exact match: check all location = /uri blocks; on a match, use it and stop.

2. Prefix scan: find the longest matching prefix location (both plain and ^~), and remember it.

3. Priority prefix short-circuit: if that longest prefix uses ^~, use it immediately and skip regex.

4. Regex: otherwise test ~ and ~* locations in the order written; the first one that matches wins.

5. Fallback: if no regex matches, use the longest prefix match remembered in step 2.

So exact beats priority-prefix beats regex beats plain prefix, with regex evaluated in configuration order among themselves.

In Kubernetes, an Ingress is a set of routing rules, and an Ingress controller is the component that actually implements them. The Nginx Ingress controller runs Nginx inside the cluster and translates Ingress resources into live Nginx reverse-proxy configuration.

• Ingress resource vs controller:

  • The Ingress object is declarative rules (host/path to Service); it does nothing on its own.

  • The controller watches those objects and reconfigures Nginx to enforce them.

• What Nginx does here:

  • Acts as the L7 reverse proxy/load balancer: host and path routing, TLS termination, rewrites.

  • Routes to Kubernetes Services (and their pod endpoints) as its upstreams.

• Reconfiguration: When Ingress rules or pod endpoints change, the controller regenerates Nginx config and reloads it automatically.

• Note: Two variants exist: the community ingress-nginx and NGINX Inc.'s own controller; they use different annotations.

Proxy buffering lets NGINX read the entire response from an upstream into its own buffers (memory and, if needed, disk) before or while sending it to the client, so a slow client can't tie up a backend connection.

• What buffering does:

  • Controlled by proxy_buffering on (default). NGINX drains the upstream as fast as possible, then feeds the client at its own pace.

  • Frees the upstream worker quickly, which is critical when backends are limited (PHP-FPM, app servers).

• Key directives:

  • proxy_buffer_size: size of the buffer for the response headers (and first chunk).

  • proxy_buffers: number and size of buffers for the body (e.g. 8 4k).

  • proxy_busy_buffers_size: how much buffered data can be sent to the client while the rest is still being read.

  • proxy_max_temp_file_size: when the response exceeds memory buffers, it spills to a temp file on disk.

• Performance implications:

  • Too-small buffers force disk spillover, adding I/O latency; size them to fit typical responses.

  • Turning buffering off (proxy_buffering off) streams responses immediately (good for streaming/SSE) but keeps the upstream connection open for the whole transfer.

By default NGINX reads the full client request body into buffers (memory, then a temp file) before contacting the upstream; disabling proxy_request_buffering streams the body to the backend as it arrives.

• Default (buffering on):

  • Sized by client_body_buffer_size; larger bodies spill to disk (client_body_temp_path).

  • Shields the backend from slow clients (slowloris-style uploads) and lets NGINX retry to another upstream because it holds the whole body.

• With proxy_request_buffering off:

  • The body is forwarded to the upstream in real time, reducing latency and disk I/O for large uploads (streaming, big files).

  • Downsides: NGINX can no longer retry the request to another upstream, and the backend is directly exposed to slow uploads holding a connection open.

• Interacts with client_max_body_size, which still caps allowed body size regardless of buffering mode.

The resolver directive tells NGINX which DNS server to use to resolve hostnames at runtime, which is required whenever an upstream name must be re-resolved instead of being fixed at startup.

• The default problem: When proxy_pass uses a literal hostname, NGINX resolves it once at config load and caches the IP forever, so if the backend IP changes (cloud, containers, autoscaling) traffic breaks.

• How resolver fixes it:

  • With a resolver set and the host given via a variable, NGINX resolves the name at request time and honors DNS TTL (tunable with valid=).

  • Trigger re-resolution by using a variable in proxy_pass, e.g. set $backend api.internal; proxy_pass http://$backend;.

• Typical use: dynamic environments (Kubernetes, ECS, service discovery) and proxying to external APIs whose IPs rotate.