What Nginx Can Do Without Third‑Party Modules: Reverse Proxy, Load Balancing, HTTP Server, and Forward Proxy

Introduction

This article only discusses what Nginx can handle without loading third‑party modules. Because there are many third‑party modules, the coverage may be incomplete and reflects the author’s personal experience, so readers are invited to comment and share their own insights.

What Nginx Can Do

Reverse proxy

Load balancing

HTTP server (including static‑dynamic separation)

Forward proxy

The following sections describe each function in detail.

Reverse Proxy

A reverse proxy receives client requests from the Internet and forwards them to internal servers, then returns the server’s response to the client. It is the most common use of Nginx.

A simple implementation is shown below.

server {
    listen       80;
    server_name  localhost;
    client_max_body_size 1024M;

    location / {
        proxy_pass http://localhost:8080;
        proxy_set_header Host $host:$server_port;
    }
}

After saving the configuration and starting Nginx, accessing http://localhost will be equivalent to accessing http://localhost:8080 .

Load Balancing

Load balancing distributes requests across multiple backend servers, improving reliability and scalability. Nginx supports three built‑in strategies and two common third‑party strategies.

1. RR (Round‑Robin, default)

Requests are assigned to backends in order; unavailable servers are automatically removed.

Simple configuration:

upstream test {
    server localhost:8080;
    server localhost:8081;
}
server {
    listen 81;
    server_name localhost;
    client_max_body_size 1024M;

    location / {
        proxy_pass http://test;
        proxy_set_header Host $host:$server_port;
    }
}

The core upstream definition is:

upstream test {
    server localhost:8080;
    server localhost:8081;
}

Even though the second server (8081) does not exist, Nginx will automatically skip it, so requests to http://localhost are served by the healthy server (8080).

2. Weight

Assigns a weight to each server; the probability of selection is proportional to the weight, useful when backend capacities differ.

upstream test {
    server localhost:8080 weight=9;
    server localhost:8081 weight=1;
}

In ten requests, roughly nine will go to 8080 and one to 8081.

3. ip_hash

Routes each client’s requests based on the hash of its IP address, ensuring a client consistently reaches the same backend, which helps with session persistence.

upstream test {
    ip_hash;
    server localhost:8080;
    server localhost:8081;
}

4. fair (third‑party)

Distributes requests according to backend response time; faster servers receive more traffic.

upstream backend {
    fair;
    server localhost:8080;
    server localhost:8081;
}

5. url_hash (third‑party)

Hashes the request URL and routes the same URL to the same backend, which is useful for caching scenarios.

upstream backend {
    hash $request_uri;
    hash_method crc32;
    server localhost:8080;
    server localhost:8081;
}

The five strategies suit different scenarios; note that fair and url_hash require third‑party modules, which are not covered here.

HTTP Server

Nginx can also serve static resources directly. A basic static server configuration is:

server {
    listen       80;
    server_name  localhost;
    client_max_body_size 1024M;

    location / {
        root   e:\wwwroot;
        index  index.html;
    }
}

Visiting http://localhost will return e:\wwwroot\index.html . For dynamic sites, static‑dynamic separation can be configured as follows.

Static and Dynamic Separation

upstream test {
    server localhost:8080;
    server localhost:8081;
}
server {
    listen 80;
    server_name localhost;
    location / {
        root e:\wwwroot;
        index index.html;
    }
    location ~ \.(gif|jpg|jpeg|png|bmp|swf|css|js)$ {
        root e:\wwwroot;
    }
    location ~ \.(jsp|do)$ {
        proxy_pass http://test;
    }
    error_page 500 502 503 504 /50x.html;
    location = /50x.html {
        root e:\wwwroot;
    }
}

Static files (images, CSS, JS) are served directly by Nginx, while dynamic requests (e.g., JSP) are proxied to the backend server.

Forward Proxy

A forward proxy sits between the client and the origin server. Nginx can act as a forward proxy, though it does not support HTTPS out‑of‑the‑box.

resolver 114.114.114.114 8.8.8.8;
server {
    resolver_timeout 5s;
    listen 81;
    access_log  e:\wwwroot\proxy.access.log;
    error_log   e:\wwwroot\proxy.error.log;
    location / {
        proxy_pass http://$host$request_uri;
    }
}

The resolver directive sets DNS servers for the proxy, and the listen port is used by client applications to route traffic through the proxy.

Final Remarks

Nginx supports hot reload, allowing configuration changes without stopping the service. The reload command is:

nginx -s reload

On Windows the command is:

nginx.exe -s reload