Reverse Proxy and Load Balancing

Overview

• What you’ll learn: Reverse proxy concepts, configuring Nginx as a reverse proxy, upstream directives, load balancing algorithms (round-robin, least_conn, ip_hash), health checks, and proxy headers (X-Forwarded-For, X-Real-IP).
• Prerequisites: Module 3 — Lessons 21–25 (HTTP Fundamentals, Apache2, Nginx, TLS/HTTPS, PHP Deployment)
• Estimated reading time: 18 minutes

Introduction

A reverse proxy is a server that sits between client devices and one or more backend servers, forwarding client requests to the appropriate backend and returning the backend’s response to the client. Unlike a forward proxy (which acts on behalf of clients), a reverse proxy acts on behalf of servers. This architecture is fundamental to modern web infrastructure, enabling load distribution, SSL termination, caching, and security isolation.

Load balancing extends the reverse proxy concept by distributing incoming requests across multiple backend servers. This ensures no single server becomes a bottleneck, improves fault tolerance, and enables horizontal scaling. When one backend server fails, the load balancer automatically routes traffic to the remaining healthy servers, providing high availability without client-side intervention.

In this lesson, you will learn the theory behind reverse proxies and load balancing, then implement these patterns using Nginx on Ubuntu Server. You will configure upstream groups, explore different load balancing algorithms, set up health checks, and properly forward client information through proxy headers.

Reverse Proxy Concepts

In a traditional web architecture, clients connect directly to a web server that processes requests and returns responses. A reverse proxy introduces an intermediary layer: clients connect to the proxy, which then forwards the request to one or more backend servers. The client is unaware of the backend servers — it only communicates with the proxy.

This architecture provides several benefits:

• Security: Backend servers are hidden from the public Internet. Only the reverse proxy needs a public IP address, reducing the attack surface.
• SSL Termination: The proxy handles TLS encryption and decryption, offloading this CPU-intensive task from backend servers.
• Caching: The proxy can cache responses from backends, reducing load and improving response times for repeated requests.
• Compression: The proxy can compress responses before sending them to clients, reducing bandwidth usage.
• Centralized Logging: All access logs are consolidated at the proxy, simplifying monitoring and analysis.

The basic Nginx configuration for a reverse proxy uses the proxy_pass directive within a location block:

# /etc/nginx/sites-available/reverse-proxy.conf
server {
    listen 80;
    server_name app.example.com;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

# Enable the site
$ sudo ln -s /etc/nginx/sites-available/reverse-proxy.conf /etc/nginx/sites-enabled/
$ sudo nginx -t
$ sudo systemctl reload nginx

The proxy_pass directive tells Nginx to forward all requests matching the location to the specified backend address. The proxy_set_header directives ensure the backend receives the original client information rather than the proxy’s own address.

Upstream Directive and Load Balancing Algorithms

When you have multiple backend servers, Nginx’s upstream directive groups them into a named pool. The proxy_pass directive then references this pool instead of a single backend address. This is the foundation of load balancing in Nginx.

# /etc/nginx/conf.d/upstream-app.conf
upstream app_backends {
    # Default: round-robin (requests distributed sequentially)
    server 10.0.1.10:8080;
    server 10.0.1.11:8080;
    server 10.0.1.12:8080;
}

server {
    listen 80;
    server_name app.example.com;

    location / {
        proxy_pass http://app_backends;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Nginx supports several load balancing algorithms, each suited to different use cases:

• Round-Robin (default): Requests are distributed sequentially across the backend servers. Server 1 gets the first request, server 2 the second, server 3 the third, then back to server 1. This is the simplest and most commonly used method.
• Least Connections (least_conn): Requests are sent to the server with the fewest active connections. This is ideal when request processing times vary significantly — slower requests won’t cause one server to become overloaded.
• IP Hash (ip_hash): The client’s IP address is used to determine which server receives the request. The same client always reaches the same backend, providing session persistence (sticky sessions). This is useful for applications that store session data locally.
• Weighted: Servers can be assigned different weights to receive a proportional share of traffic. Higher-capacity servers receive more requests.

# Least connections algorithm
upstream app_least {
    least_conn;
    server 10.0.1.10:8080;
    server 10.0.1.11:8080;
    server 10.0.1.12:8080;
}

# IP hash algorithm (sticky sessions)
upstream app_sticky {
    ip_hash;
    server 10.0.1.10:8080;
    server 10.0.1.11:8080;
    server 10.0.1.12:8080;
}

# Weighted round-robin
upstream app_weighted {
    server 10.0.1.10:8080 weight=5;   # receives 5x more traffic
    server 10.0.1.11:8080 weight=3;   # receives 3x more traffic
    server 10.0.1.12:8080 weight=1;   # baseline
}

Health Checks and Server Parameters

In a production load balancing environment, backend servers may fail or become unresponsive. Nginx provides passive health checking by default: if a connection to a backend fails, Nginx marks it as unavailable and temporarily stops sending requests to it. You can control this behavior with server parameters.

upstream app_backends {
    least_conn;

    # max_fails: number of failed attempts before marking unavailable
    # fail_timeout: time period for max_fails AND how long to wait before retrying
    server 10.0.1.10:8080 max_fails=3 fail_timeout=30s;
    server 10.0.1.11:8080 max_fails=3 fail_timeout=30s;
    server 10.0.1.12:8080 max_fails=3 fail_timeout=30s;

    # Backup server — only receives traffic when all primary servers are down
    server 10.0.1.99:8080 backup;

    # Mark a server as permanently offline for maintenance
    # server 10.0.1.10:8080 down;
}

server {
    listen 80;
    server_name app.example.com;

    location / {
        proxy_pass http://app_backends;

        # Timeout settings for proxied requests
        proxy_connect_timeout 5s;
        proxy_send_timeout 10s;
        proxy_read_timeout 30s;

        # Retry on specific error conditions
        proxy_next_upstream error timeout http_502 http_503 http_504;
        proxy_next_upstream_tries 3;

        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

The max_fails parameter sets how many consecutive failures are allowed before a server is marked as unavailable. The fail_timeout parameter serves a dual purpose: it defines the time window in which max_fails must occur, and also how long the server stays unavailable before Nginx tries it again. The proxy_next_upstream directive defines which error conditions trigger a retry on the next server.

Proxy Headers: X-Forwarded-For and X-Real-IP

When a reverse proxy forwards requests, the backend server sees the proxy’s IP address as the client address, not the original client’s IP. This is problematic for logging, access control, and geolocation. Proxy headers solve this by passing the original client information through the proxy chain.

• X-Real-IP: Contains the IP address of the original client. Set by the first proxy in the chain.
• X-Forwarded-For: A comma-separated list of IP addresses showing the full proxy chain. Each proxy appends the address of the previous hop.
• X-Forwarded-Proto: Indicates the original protocol (http or https) used by the client, essential when TLS is terminated at the proxy.
• X-Forwarded-Host: The original Host header sent by the client.

# Complete reverse proxy configuration with headers
server {
    listen 443 ssl;
    server_name app.example.com;

    ssl_certificate /etc/letsencrypt/live/app.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/app.example.com/privkey.pem;

    location / {
        proxy_pass http://app_backends;

        # Forward original client information
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-Host $host;
        proxy_set_header X-Forwarded-Port $server_port;

        # WebSocket support (if needed)
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";

        # Buffering settings
        proxy_buffering on;
        proxy_buffer_size 4k;
        proxy_buffers 8 4k;
    }
}

# Backend application: configure to trust proxy headers
# Example for Apache backend — enable remoteip module
$ sudo a2enmod remoteip
# In Apache config:
# RemoteIPHeader X-Forwarded-For
# RemoteIPTrustedProxy 10.0.1.0/24

The $proxy_add_x_forwarded_for variable automatically appends the client’s IP to any existing X-Forwarded-For header, correctly handling multi-proxy chains. Backend applications must be configured to trust and read these headers for accurate client identification.

Key Takeaways

• A reverse proxy sits between clients and backend servers, providing security, SSL termination, caching, and centralized logging.
• Nginx’s upstream directive groups backend servers into a pool, and proxy_pass distributes requests across them.
• Load balancing algorithms — round-robin, least_conn, ip_hash, and weighted — suit different workload patterns and session requirements.
• Passive health checks with max_fails and fail_timeout automatically remove failed backends from the pool and retry after a cooldown period.
• Proxy headers (X-Real-IP, X-Forwarded-For, X-Forwarded-Proto) preserve original client information through the proxy chain and must be trusted by backend applications.

What’s Next

In Lesson 27, you will learn about Squid Proxy Server, covering forward proxy concepts, installation and configuration of Squid on Ubuntu, access control lists (ACLs), cache management, and proxy authentication.

# /etc/nginx/sites-available/reverse-proxy.conf
server {
    listen 80;
    server_name app.example.com;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

# 啟用站點
$ sudo ln -s /etc/nginx/sites-available/reverse-proxy.conf /etc/nginx/sites-enabled/
$ sudo nginx -t
$ sudo systemctl reload nginx

# /etc/nginx/conf.d/upstream-app.conf
upstream app_backends {
    # 預設：round-robin（請求按順序分配）
    server 10.0.1.10:8080;
    server 10.0.1.11:8080;
    server 10.0.1.12:8080;
}

server {
    listen 80;
    server_name app.example.com;

    location / {
        proxy_pass http://app_backends;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

# 最少連線演算法
upstream app_least {
    least_conn;
    server 10.0.1.10:8080;
    server 10.0.1.11:8080;
    server 10.0.1.12:8080;
}

# IP 雜湊演算法（黏性會話）
upstream app_sticky {
    ip_hash;
    server 10.0.1.10:8080;
    server 10.0.1.11:8080;
    server 10.0.1.12:8080;
}

# 加權 round-robin
upstream app_weighted {
    server 10.0.1.10:8080 weight=5;   # 接收 5 倍流量
    server 10.0.1.11:8080 weight=3;   # 接收 3 倍流量
    server 10.0.1.12:8080 weight=1;   # 基準
}

upstream app_backends {
    least_conn;

    # max_fails：標記為不可用之前允許的失敗次數
    # fail_timeout：max_fails 的時間段以及重試前的等待時間
    server 10.0.1.10:8080 max_fails=3 fail_timeout=30s;
    server 10.0.1.11:8080 max_fails=3 fail_timeout=30s;
    server 10.0.1.12:8080 max_fails=3 fail_timeout=30s;

    # 備用伺服器——僅在所有主要伺服器都停機時接收流量
    server 10.0.1.99:8080 backup;
}

server {
    listen 80;
    server_name app.example.com;

    location / {
        proxy_pass http://app_backends;

        # 代理請求的逾時設定
        proxy_connect_timeout 5s;
        proxy_send_timeout 10s;
        proxy_read_timeout 30s;

        # 在特定錯誤條件下重試
        proxy_next_upstream error timeout http_502 http_503 http_504;
        proxy_next_upstream_tries 3;

        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

# 具有完整標頭的反向代理設定
server {
    listen 443 ssl;
    server_name app.example.com;

    ssl_certificate /etc/letsencrypt/live/app.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/app.example.com/privkey.pem;

    location / {
        proxy_pass http://app_backends;

        # 轉發原始用戶端資訊
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-Host $host;
        proxy_set_header X-Forwarded-Port $server_port;

        # WebSocket 支援（如需要）
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

# 後端應用程式：設定信任代理標頭
$ sudo a2enmod remoteip

# /etc/nginx/sites-available/reverse-proxy.conf
server {
    listen 80;
    server_name app.example.com;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

# サイトを有効化
$ sudo ln -s /etc/nginx/sites-available/reverse-proxy.conf /etc/nginx/sites-enabled/
$ sudo nginx -t
$ sudo systemctl reload nginx

# /etc/nginx/conf.d/upstream-app.conf
upstream app_backends {
    # デフォルト：round-robin（リクエストを順番に分配）
    server 10.0.1.10:8080;
    server 10.0.1.11:8080;
    server 10.0.1.12:8080;
}

server {
    listen 80;
    server_name app.example.com;

    location / {
        proxy_pass http://app_backends;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

# 最少接続数アルゴリズム
upstream app_least {
    least_conn;
    server 10.0.1.10:8080;
    server 10.0.1.11:8080;
    server 10.0.1.12:8080;
}

# IP ハッシュアルゴリズム（スティッキーセッション）
upstream app_sticky {
    ip_hash;
    server 10.0.1.10:8080;
    server 10.0.1.11:8080;
    server 10.0.1.12:8080;
}

# 重み付き round-robin
upstream app_weighted {
    server 10.0.1.10:8080 weight=5;   # 5倍のトラフィックを受信
    server 10.0.1.11:8080 weight=3;   # 3倍のトラフィックを受信
    server 10.0.1.12:8080 weight=1;   # 基準
}

upstream app_backends {
    least_conn;

    # max_fails：使用不可にする前に許可される失敗回数
    # fail_timeout：max_fails の期間および再試行前の待機時間
    server 10.0.1.10:8080 max_fails=3 fail_timeout=30s;
    server 10.0.1.11:8080 max_fails=3 fail_timeout=30s;
    server 10.0.1.12:8080 max_fails=3 fail_timeout=30s;

    # バックアップサーバー——すべてのプライマリサーバーがダウンした時のみ使用
    server 10.0.1.99:8080 backup;
}

server {
    listen 80;
    server_name app.example.com;

    location / {
        proxy_pass http://app_backends;

        # プロキシリクエストのタイムアウト設定
        proxy_connect_timeout 5s;
        proxy_send_timeout 10s;
        proxy_read_timeout 30s;

        # 特定のエラー条件でリトライ
        proxy_next_upstream error timeout http_502 http_503 http_504;
        proxy_next_upstream_tries 3;

        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

# ヘッダー付き完全なリバースプロキシ設定
server {
    listen 443 ssl;
    server_name app.example.com;

    ssl_certificate /etc/letsencrypt/live/app.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/app.example.com/privkey.pem;

    location / {
        proxy_pass http://app_backends;

        # オリジナルクライアント情報を転送
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-Host $host;
        proxy_set_header X-Forwarded-Port $server_port;

        # WebSocket サポート（必要な場合）
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

# バックエンドアプリケーション：プロキシヘッダーを信頼するよう設定
$ sudo a2enmod remoteip