What Does Upstream Mean in Nginx?

In Nginx, the term "upstream" refers to a group of backend servers that Nginx proxies requests to. These backend servers can be anything from a web application server to a database or any other service that handles client requests. The concept of upstream servers is integral to Nginx’s functionality as a reverse proxy and load balancer.

Understanding Upstream in Nginx

1. Definition and Usage

• Upstream Block: Defines a group of backend servers that Nginx can proxy requests to. It’s used to simplify and centralize the configuration of multiple backend servers.

  Example:

   

  Copied!

  upstream myapp {
      server backend1.example.com;
      server backend2.example.com;
  }
  
  

  In this example, myapp is an upstream group containing two backend servers.

• Proxying Requests: The upstream block is referenced in proxy_pass directives within location blocks to distribute incoming requests among the defined servers.

  Example:

   

  Copied!

  server {
      listen 80;
      server_name example.com;
  
      location / {
          proxy_pass <http://myapp>;
      }
  }
  
  

  In this example, requests to the root (/) are forwarded to one of the servers defined in the myapp upstream block.

2. Load Balancing

Nginx can distribute incoming requests among the servers in an upstream group using various load balancing algorithms:

• Round-Robin (default): Distributes requests evenly across all servers in the upstream group.
• Least Connections: Sends requests to the server with the fewest active connections.

• IP Hash: Routes requests from the same client IP address to the same server, which can be useful for session persistence.

  Example with Load Balancing Configuration:

   

  Copied!

  upstream myapp {
      least_conn;  # Use least connections algorithm
      server backend1.example.com;
      server backend2.example.com;
  }
  
  

3. Health Checks

Nginx doesn’t perform health checks natively on upstream servers (this feature is available in Nginx Plus). For basic health checks and failover, you might need to rely on external tools or scripts.

4. Sticky Sessions

For scenarios requiring session persistence (sticky sessions), where requests from the same client are always routed to the same backend server, you need to use additional configurations or modules (e.g., Nginx Plus or third-party modules).

Example with Sticky Sessions (Nginx Plus):

upstream myapp {
    sticky;
    server backend1.example.com;
    server backend2.example.com;
}

5. Caching

Nginx can cache responses from upstream servers to reduce load and improve performance. Caching is controlled through directives in the proxy_cache configuration.

Example with Caching Configuration:

upstream myapp {
    server backend1.example.com;
    server backend2.example.com;
}

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass <http://myapp>;
        proxy_cache my_cache;
        proxy_cache_valid 200 1h;
        proxy_cache_valid 404 1m;
    }
}

proxy_cache_path /var/cache/nginx/my_cache levels=1:2 keys_zone=my_cache:10m max_size=1g inactive=60m use_temp_path=off;

Summary

• Upstream Block: Defines backend servers that Nginx proxies requests to.
• Load Balancing: Distributes requests among backend servers using algorithms like round-robin, least connections, or IP hash.
• Health Checks: Basic health checks require external tools (native in Nginx Plus).
• Sticky Sessions: Configurable for session persistence (Nginx Plus or third-party modules).
• Caching: Configurable to cache responses from upstream servers.

The concept of upstream servers allows Nginx to act as a powerful reverse proxy and load balancer, efficiently managing and distributing client requests among backend services.

Got an article suggestion? Let us know

Explore more

Apache

This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.