Mastering Nginx: Reverse Proxy, Master‑Worker Model, Hot Reload & High‑Availability

Nginx is a lightweight web server and reverse‑proxy server known for low memory usage, fast startup, and strong high‑concurrency capabilities, widely used in internet projects.

The diagram illustrates a popular modern architecture where Nginx acts as an entry gateway.

Reverse Proxy Server?

People often mention terms like reverse proxy; what exactly are reverse and forward proxies?

Forward Proxy:

Reverse Proxy:

Because of firewalls, direct access to Google may be blocked; a VPN acts as a simple forward proxy, where the client knows the target but the target does not know the client’s origin. Conversely, when accessing Baidu from the external network, the request is forwarded to the internal server—this is a reverse proxy, transparent to the client.

Nginx Master‑Worker Model

After starting Nginx, it listens on port 80. Nginx consists of a Master process and multiple Worker processes.

Master process responsibilities: read and validate the configuration file nginx.conf, manage Worker processes.

Worker process responsibilities: each Worker maintains a thread (avoiding thread switching) to handle connections and requests; the number of Workers is set in the configuration, usually matching the CPU core count.

Thought: How does Nginx achieve hot deployment?

Hot deployment means updating nginx.conf without stopping Nginx or interrupting requests (using nginx -s reload , nginx -t to test config, nginx -s stop to stop). Two approaches: 1. After modifying nginx.conf , the Master pushes the new configuration to Workers, which update their internal thread information. 2. After modifying nginx.conf , Nginx spawns new Worker processes with the new configuration; new requests go to the new Workers, and old Workers exit after finishing existing requests. Nginx uses the second method for hot deployment.

Thought: How does Nginx handle high concurrency efficiently?

Worker count is tied to CPU cores, and each Worker contains a thread for efficient request looping, but additional mechanisms are needed. Nginx leverages Linux's epoll event‑driven model, which monitors multiple file descriptors for readiness and processes ready events asynchronously, allowing Workers to handle many connections without blocking on I/O.

Thought: What if Nginx crashes?

Since Nginx often serves as an entry gateway, a single point of failure is unacceptable. Solution: combine Keepalived with Nginx for high availability. Keepalived provides a virtual IP (VIP) that clients contact first, monitors Nginx health via custom scripts, and performs failover by adjusting weights.

Our Main Battlefield: nginx.conf

In development and testing environments, we often need to configure Nginx via nginx.conf , a typical segmented configuration file.

Virtual Host

Reverse Proxy (proxy_pass)

To set up a reverse proxy, replace root in a location block with proxy_pass . root serves static files, while proxy_pass forwards dynamic requests to back‑ends like Tomcat. Requests become transparent: client → Nginx → Tomcat, and Tomcat sees Nginx’s IP as the source. Custom HTTP headers can also be added.

Load Balancing (upstream)

Using upstream , define a group of back‑end servers (e.g., multiple Tomcat instances) and specify a load‑balancing strategy (IP‑hash, weighted, least connections) and health checks. Then set proxy_pass to the upstream name. Be aware of session persistence issues when load balancing.

Cache

Nginx provides a caching mechanism to accelerate access; enabling it involves configuring a cache directory, with details available in the official Nginx documentation.