nginx Configuration

A reverse proxy sits in front of one or more backend application servers and forwards incoming client requests to them, then relays the responses back. Clients only ever talk to nginx, which hides the backend topology. This enables load balancing, SSL/TLS termination, caching, compression, and centralized logging. Unlike a forward proxy (which represents clients), a reverse proxy represents servers. In nginx you configure it with proxy_pass inside a location block, optionally pointing at an upstream group of servers.

An upstream block defines a named pool of backend servers that nginx distributes traffic to. Inside it you list server addresses and tune them with weights, health-check parameters, and connection limits. A proxy_pass directive then references the pool by name. nginx supports several load-balancing methods: round-robin (default), least_conn, and ip_hash for sticky sessions. Marking a server backup or down controls failover. Upstreams are how nginx scales a service horizontally across multiple application instances.

A location block matches request URIs and applies directives to the requests that match. Matching can be a prefix, an exact match (=), or a regular expression (~ case-sensitive, ~* case-insensitive), and nginx follows specific precedence rules to pick the most specific match. Within a location you set things like root or alias for files, proxy_pass for proxying, headers, caching, and access rules. Location blocks are the core routing mechanism that decides how each URL path is handled.

nginx uses a master process plus several worker processes. The master reads configuration and manages workers, while each worker actually handles client connections. Rather than one thread per connection, each worker uses an event-driven, asynchronous loop (epoll/kqueue) to multiplex thousands of concurrent connections with minimal memory — the source of nginx's high efficiency. You typically set worker_processes auto to match CPU cores, and worker_connections caps how many connections each can handle simultaneously.

The gzip directive enables on-the-fly compression of HTTP responses before nginx sends them to clients that advertise support via Accept-Encoding. Compressing text-based content — HTML, CSS, JavaScript, JSON — typically shrinks payloads by 60–80%, speeding page loads and cutting bandwidth. You control it with gzip_types (which MIME types to compress), gzip_comp_level (CPU-vs-ratio trade-off), and gzip_min_length. For static assets, gzip_static can serve precompressed .gz files to avoid repeating the work.