Putting Reverse Proxying into Practice with Nginx | Reverse Proxying and Load Balancing | Mastering Nginx: A Beginner's Guide to High-Performance Web Servers

Now that we've grasped the concepts of reverse proxying and load balancing, it's time to get our hands dirty and implement these powerful features with Nginx. This section will guide you through practical examples, showing you how to configure Nginx to act as a reverse proxy, forwarding requests to your backend applications and distributing traffic efficiently.

Our primary goal is to create an Nginx configuration that listens for incoming client requests and directs them to one or more backend servers. This not only enhances performance and scalability but also provides a single point of access, simplifying management and security.

Let's start with a basic reverse proxy setup. Imagine you have a web application running on a local server, say at http://localhost:8080. We want Nginx to listen on the standard HTTP port (80) and forward all requests to this backend application. This is particularly useful if your application server doesn't handle SSL termination or if you want to leverage Nginx's performance optimizations.

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

        location / {
            proxy_pass http://localhost: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;
        }
    }
}

Let's break down this configuration:

listen 80;: Nginx will listen for incoming connections on port 80.

server_name example.com;: This directive specifies the domain name(s) for which this server block is responsible. Replace example.com with your actual domain.

location / { ... }: This block handles all requests that match the root path (/).

proxy_pass http://localhost:8080;: This is the core of our reverse proxy. It tells Nginx to forward all requests within this location to the specified backend server.

proxy_set_header ...;: These directives are crucial for passing important information from the original client request to the backend server. Without them, your backend application might not know the original IP address, hostname, or protocol of the request, which can break functionality and logging.

Now, let's visualize this basic reverse proxy flow.

graph TD;
    Client --> Nginx;
    Nginx --> BackendApp;
    BackendApp --> Nginx;
    Nginx --> Client;

Moving on to load balancing, the concept is to distribute incoming traffic across multiple backend servers. This is achieved by defining an upstream block where you list your backend servers.

http {
    upstream backend_servers {
        server app1.example.com:8080;
        server app2.example.com:8080;
        server app3.example.com:8080;
    }

    server {
        listen 80;
        server_name example.com;

        location / {
            proxy_pass http://backend_servers;
            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;
        }
    }
}

In this enhanced configuration:

upstream backend_servers { ... }: We define a group of backend servers named backend_servers. You can list multiple server directives within this block, each representing a backend instance.

proxy_pass http://backend_servers;: Instead of a single backend address, we now point proxy_pass to the name of our upstream group. Nginx will then automatically distribute requests among the servers listed in backend_servers using a default load balancing algorithm (round-robin).

Nginx offers various load balancing methods. The default is round-robin, but you can also specify others like least-connected, IP hash, and more within the upstream block.

Round Robin (Default): Requests are distributed sequentially to each server in the list. This is suitable for most scenarios.

Least-Connected: The request is sent to the server with the fewest active connections. This can be more efficient for uneven request durations.

upstream backend_servers {
    least_conn;
    server app1.example.com:8080;
    server app2.example.com:8080;
    server app3.example.com:8080;
}

IP Hash: The request is distributed based on the client's IP address. This ensures that requests from the same client are always sent to the same server, which is useful for applications that rely on session affinity.

upstream backend_servers {
    ip_hash;
    server app1.example.com:8080;
    server app2.example.com:8080;
    server app3.example.com:8080;
}

Here's a visual representation of our load balancing setup with multiple backend servers.

graph TD;
    Client --> Nginx;
    Nginx -- Request 1 --> Backend1;
    Nginx -- Request 2 --> Backend2;
    Nginx -- Request 3 --> Backend3;
    Backend1 --> Nginx;
    Backend2 --> Nginx;
    Backend3 --> Nginx;
    Nginx --> Client;

To make your load balancing robust, it's essential to implement health checks. Nginx can automatically detect unhealthy servers and stop sending traffic to them. This is done using the down parameter for manual marking or by leveraging Nginx Plus's built-in health checking capabilities. For open-source Nginx, you can achieve a form of health checking by periodically requesting a health endpoint from your backend servers and then manually or programmatically updating the upstream configuration if a server becomes unresponsive.

By mastering these configurations, you've taken a significant step towards building a high-performance and resilient web infrastructure with Nginx.

http { server { listen 80; server_name example.com; location / { proxy_pass http://localhost: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; } } }

http { upstream backend_servers { server app1.example.com:8080; server app2.example.com:8080; server app3.example.com:8080; } server { listen 80; server_name example.com; location / { proxy_pass http://backend_servers; 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; } } }

graph TD; Client --> Nginx; Nginx -- Request 1 --> Backend1; Nginx -- Request 2 --> Backend2; Nginx -- Request 3 --> Backend3; Backend1 --> Nginx; Backend2 --> Nginx; Backend3 --> Nginx; Nginx --> Client;