Master Nginx: Reverse Proxy, Load Balancing, and High‑Availability Guide

This comprehensive guide explains Nginx’s core concepts—including reverse and forward proxy, load balancing, static‑dynamic separation, common commands, configuration blocks, and high‑availability setup with keepalived—providing step‑by‑step examples, diagrams, and practical tips for deploying scalable, high‑performance web services.

ITFLY8 Architecture Home
ITFLY8 Architecture Home
ITFLY8 Architecture Home
Master Nginx: Reverse Proxy, Load Balancing, and High‑Availability Guide

1. Nginx Overview

Nginx is a high‑performance HTTP and reverse‑proxy server known for low memory usage and strong concurrency, capable of handling up to 50,000 simultaneous connections.

1.1 Reverse Proxy

Forward Proxy

In a forward proxy, internal users cannot access the Internet directly and must route requests through a proxy server.

Reverse Proxy

A reverse proxy hides the real backend server IP; clients send requests to the proxy, which forwards them to the appropriate backend and returns the response.

1.2 Load Balancing

When request volume grows, a single server cannot meet demand. Adding more servers and distributing requests among them implements load balancing.

For example, 15 requests sent to a proxy can be evenly split among three backend servers, each handling five requests.

1.3 Static/Dynamic Separation

Separating static and dynamic content across different servers speeds up page rendering and reduces load on a single server.

2. Installing Nginx on Linux

Refer to the original blog for detailed installation steps.

3. Common Nginx Commands

./nginx -v

Check version. ./nginx Start Nginx.

./nginx -s stop
./nginx -s quit

Stop (graceful). ./nginx -s reload Reload configuration.

4. Nginx Configuration File

Global Block

Settings that affect the whole server, such as worker processes and connection limits.

Events Block

Controls network connections, e.g., enabling multi‑process connection handling and maximum connections.

HTTP Block

Contains reverse‑proxy, load‑balancing, and location directives.

The location syntax matches URLs:

location [=|~|~*|^~] url { }
location = /exact { ... }

Modifiers:

= : exact match, stop searching.

~ : case‑sensitive regex.

~* : case‑insensitive regex.

^~ : highest‑priority prefix match, stop further regex checks.

4.1 Reverse Proxy Practical

Configuration

Goal: Access www.123.com and have it display the Tomcat homepage.

Configure Tomcat (omitted) and set up Nginx to forward requests.

Result: Requests to www.123.com are proxied to Tomcat port 8080.

Second Example

http://192.168.25.132:9001/edu/ → 192.168.25.132:8080

http://192.168.25.132:9001/vod/ → 192.168.25.132:8081

Nginx listens on port 9001 and uses regex to route to the appropriate backend.

4.2 Reverse Proxy Summary

Browser resolves www.123.com to the server IP, Nginx listens on port 80, forwards to Tomcat 8080, or uses port 9001 with path‑based routing to Tomcat 8080/8081.

4.3 Load Balancing Practical

Modify nginx.conf to define upstream servers and load‑balancing method, then reload.

./nginx -s reload

Place a test file in Tomcat 8081 and access via the load‑balanced URL; requests are distributed according to the chosen method.

Round‑robin (default)

Weight (higher weight = higher priority)

Fair (based on response time)

ip_hash (consistent client‑IP routing, useful for sessions)

4.4 Static/Dynamic Separation Practical

Static files are served directly by Nginx, while dynamic requests are proxied to Tomcat.

5. Nginx High Availability

If Nginx fails, keepalived provides failover using a virtual IP.

5.1 Install keepalived

# yum install keepalived -y
# rpm -q -a keepalived
keepalived-1.3.5-16.el7.x86_64

5.2 Configure keepalived

# cd /etc/keepalived
# vi keepalived.conf

Key sections (virtual IP 192.168.25.50, MASTER/BACKUP states, health‑check script, etc.)

Adjust smtp_server , state , and IP addresses for the primary and backup hosts.
global_defs {
  notification_email { [email protected] }
  smtp_server 192.168.25.147
  router_id LVS_DEVEL
}

vrrp_script chk_nginx {
  script "/usr/local/src/nginx_check.sh"
  interval 2
  weight 2
}

vrrp_instance VI_1 {
  state BACKUP
  interface ens33
  virtual_router_id 51
  priority 90
  authentication { auth_type PASS; auth_pass 1111; }
  virtual_ipaddress { 192.168.25.50; }
}

Start the service:

# systemctl start keepalived.service

Accessing the virtual IP remains functional even if the primary Nginx instance stops.

6. Principle Explanation

Nginx runs a master process that manages worker processes; each worker handles client connections independently, allowing hot reloads and fault isolation.

7. Summary

The number of workers should match the CPU core count.

Multiple workers under a single master enable hot deployment; a worker failure does not affect others.

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

Backendhigh availabilityload balancingConfigurationreverse proxykeepalived
ITFLY8 Architecture Home
Written by

ITFLY8 Architecture Home

ITFLY8 Architecture Home - focused on architecture knowledge sharing and exchange, covering project management and product design. Includes large-scale distributed website architecture (high performance, high availability, caching, message queues...), design patterns, architecture patterns, big data, project management (SCRUM, PMP, Prince2), product design, and more.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.