Nginx Vocabulary: 25 Terms for DevOps and Backend Developers

If you work in backend development or DevOps, you will inevitably encounter Nginx — one of the most widely used web servers and reverse proxies in the industry. Whether you are joining a new team, reviewing pull requests, or participating in architecture discussions, understanding the language around Nginx configuration is essential.

This post covers 20 core Nginx terms, explains what each one means in plain English, and shows you how real developers use them in everyday conversation. By the end, you will be able to follow — and contribute to — technical discussions about web server configuration with confidence.

Core Configuration Terms

nginx.conf — the main configuration file for Nginx, typically located at /etc/nginx/nginx.conf. It defines global settings such as worker processes, logging paths, and which other configuration files to load.

“Before you restart the service, double-check the nginx.conf — someone may have left a syntax error in there.”

“We keep the nginx.conf minimal and pull everything else in via include directives.”

server block — a configuration block inside nginx.conf (or an included file) that defines how Nginx handles requests for a specific domain or IP address. It is roughly equivalent to Apache’s VirtualHost.

“Each of our microservices has its own server block so we can manage routing independently.”

“I added a server block for the staging domain and pointed it at port 3001.”

location block — a directive inside a server block that matches URL paths and defines how Nginx should handle requests to those paths.

“We’ve got a location block that routes anything under /api/ to the backend and serves everything else as static files.”

“The location block for /uploads/ has a separate cache policy because those assets rarely change.”

include directive — an instruction that tells Nginx to load another file or a set of files into the current configuration. It helps keep large configurations organised and maintainable.

“We use the include directive to pull in all the site configs from /etc/nginx/sites-enabled/.”

“Rather than duplicating SSL settings everywhere, I extracted them into a shared file and used include to reference it.”

worker process — a separate OS process spawned by Nginx to handle incoming connections. The number of worker processes is usually set to match the number of CPU cores on the server.

“We’ve got four cores on this box, so I set worker_processes to four — each worker process handles its own set of connections.”

“If you’re seeing high CPU on one core, it might be that your worker process count isn’t tuned for the machine.”

worker connections — a setting inside the events block that defines the maximum number of simultaneous connections each worker process can handle.

“We bumped worker_connections to 2048 after the load test showed we were hitting the default limit.”

“Worker connections multiplied by worker processes gives you your theoretical max concurrent connections.”

Proxying and Load Balancing

reverse proxy — a server that sits in front of one or more backend services and forwards client requests to them. From the client’s perspective, they are talking to the reverse proxy, not the backend directly. Nginx is commonly used as a reverse proxy in front of Node.js, Python, or Java applications.

“Nginx acts as a reverse proxy here — clients hit port 443 and we forward to the app on port 3000 internally.”

“One of the advantages of a reverse proxy is that you can swap out or scale backends without touching DNS.”

proxy_pass — the Nginx directive that specifies where to forward a request when acting as a reverse proxy. It takes a URL or upstream name as its value.

“Add proxy_pass http://localhost:8080; inside the location block and Nginx will forward traffic to your app.”

“We’re using proxy_pass with an upstream name rather than a hardcoded IP so we can add more nodes later.”

upstream — a named group of backend servers used for load balancing. You define an upstream block with a list of servers, and Nginx distributes incoming requests across them.

“Define an upstream block with both app servers, then point proxy_pass at the upstream name — that’s all you need for basic load balancing.”

“The upstream block supports different balancing strategies: round-robin is the default, but you can switch to least_conn if your requests vary in processing time.”

keepalive — a setting on upstream connections that allows Nginx to reuse existing connections to backend servers rather than opening a new TCP connection for every request. This reduces latency and resource usage.

“We added keepalive 64; to the upstream block and saw a noticeable drop in response times under load.”

“Without keepalive, Nginx was opening a new connection to the app server on every request — not ideal.”

SSL, HTTP, and Performance

SSL/TLS termination — the process of decrypting HTTPS traffic at the Nginx level so that backend services receive plain HTTP. The encrypted connection ends (terminates) at Nginx, which is why it is called termination.

“We handle SSL/TLS termination at the load balancer, so the backend apps only ever see plain HTTP on the internal network.”

“Centralising SSL termination in Nginx means we only need to manage certificates in one place.”

HTTP/2 — the second major version of the HTTP protocol, which improves performance through features like request multiplexing (sending multiple requests over a single connection) and header compression. Nginx supports HTTP/2 on HTTPS connections.

“We enabled HTTP/2 in the server block and it made a measurable difference on pages with lots of small assets.”

“HTTP/2 requires HTTPS, so you need SSL termination set up first.”

gzip compression — a setting that tells Nginx to compress responses before sending them to the client. This reduces the amount of data transferred over the network, which speeds up page loads.

“Turn on gzip compression for text-based responses — HTML, CSS, JS, and JSON all compress well.”

“We had gzip enabled but forgot to add application/json to the mime types list, so API responses weren’t being compressed.”

cache headers — HTTP response headers (such as Cache-Control and Expires) that tell browsers and intermediate proxies how long to store a cached copy of a resource. Nginx can add or modify these headers.

“Static assets get cache headers with a one-year max-age since we use content-hashed filenames.”

“Make sure the cache headers on the API responses are set to no-store — we don’t want those cached anywhere.”

rate limiting (limit_req) — a feature that restricts how many requests a client can make within a given time window. It is used to protect services from abuse, brute-force attacks, and traffic spikes.

“We added limit_req on the login endpoint to prevent brute-force attempts — ten requests per minute per IP.”

“Rate limiting is configured in two parts: you define the zone in the http block, then reference it with limit_req inside the location block.”

Routing, Rewrites, and Logging

try_files — a directive that tells Nginx to check for files or directories in a specified order and serve the first one that exists, falling back to a final option (often a PHP file or a named location) if none are found. It is widely used for single-page applications and PHP frameworks.

“For the React app we use try_files $uri $uri/ /index.html; so that deep-linking works correctly.”

“If try_files can’t find a static file, it falls through to the index.php fallback — that’s how WordPress routing works in Nginx.”

rewrite rule — a directive that modifies the URL of an incoming request, either redirecting the client to a new URL or changing the path internally before Nginx processes it further.

“We added a rewrite rule to redirect all HTTP traffic to HTTPS using a 301 permanent redirect.”

“Be careful with rewrite rules — they can create redirect loops if you’re not precise with the conditions.”

error_page — a directive that specifies a custom response or redirect for specific HTTP error codes such as 404, 500, or 503.

“Set up an error_page for 502 so users see a friendly maintenance message instead of a blank screen when the backend is down.”

“We have a shared error_page include file that handles 404, 403, and 5xx errors consistently across all our sites.”

access log / error log — two types of log files that Nginx writes by default. The access log records every request (client IP, status code, response time, etc.). The error log records problems such as failed upstream connections or configuration errors.

“Check the error log first — it will tell you exactly why Nginx is returning a 502.”

“We ship the access log to our analytics pipeline so we can track real user traffic without client-side scripts.”

map module — an Nginx module that lets you create variables whose values depend on other variables, effectively building lookup tables inside your configuration. It is useful for conditional logic without complex if statements.

“We use the map module to translate user-agent strings into device categories, then route mobile traffic to a different backend.”

“The map module is much more efficient than a chain of if blocks — Nginx evaluates the mapping lazily.”

How to Use These in Conversation

Knowing the terms is only half the battle. Here is how you might hear them combined in real team discussions:

During a code review:

“The proxy_pass in this location block points directly to an IP — can we move that into an upstream block so we have room to add more nodes later?”

During an incident:

“The error log shows upstream timed out — looks like the worker connections limit was hit during the traffic spike. Let’s increase it and also add rate limiting on the public endpoints.”

During an architecture discussion:

“We’ll handle SSL/TLS termination at the Nginx layer, enable HTTP/2, and use gzip compression on all text responses. The map module can handle the A/B routing logic so we don’t need application-level feature flags for this.”

During onboarding:

“Our Nginx config is split into per-site files in sites-enabled/ — each one is pulled in by the include directive from nginx.conf. The upstream definitions live in a separate file. Try_files handles SPA routing on the frontend apps.”

Quick Reference Table

Term	What it does
server block	Defines how Nginx handles a domain or IP
location block	Matches URL paths and sets per-path behaviour
proxy_pass	Forwards requests to a backend server or upstream
upstream	Named group of backends for load balancing
SSL/TLS termination	Decrypts HTTPS at Nginx; backends receive plain HTTP
try_files	Checks for files in order; fallback for SPAs and PHP
limit_req	Rate limiting — caps requests per IP per time window
gzip compression	Compresses responses to reduce transfer size
access log / error log	Records requests and problems respectively
map module	Lookup-table variables for conditional routing logic

Mastering Nginx vocabulary will make you a more effective communicator on any team that runs web infrastructure. These terms come up constantly in code reviews, incident post-mortems, and architecture discussions — so the sooner you are comfortable with them, the faster you will be able to contribute and be understood.