Detailed explanation of nginx upstream configuration and function

Configuration Example

upstream backend {
  server backend1.example.com weight=5;
  server backend2.example.com:8080;
  server unix:/tmp/backend3;

  server backup1.example.com:8080 backup;
  server backup2.example.com:8080 backup;
}

server {
  location / {
    proxy_pass http://backend;
  }
}

instruction

Defines a group of servers. These servers can listen on different ports. Furthermore, servers listening on TCP and UNIX domain sockets can be mixed.

example:

upstream backend {
  server backend1.example.com weight=5;
  server 127.0.0.1:8080 max_fails=3 fail_timeout=30s;
  server unix:/tmp/backend3;
}

By default, nginx distributes requests to servers in a weighted round-robin manner. In the above example, every 7 requests will be distributed in the following way: 5 requests to backend1.example.com, 1 request to the second server, and 1 request to the third server. When communicating with a server, if an error occurs, the request is passed to the next server until all available servers have been tried. If all servers return failure, the client will get the (failure) response result of the last server communicated with.

Define the server address address and other parameters parameters. The address can be a domain name or IP address, and the port is optional, or the path to a UNIX domain socket specified with a "unix:" prefix. If no port is specified, port 80 is used. If a domain name resolves to multiple IP addresses, multiple servers are essentially defined.

You can define the following parameters: weight=number sets the weight of the server, the default is 1. max_fails=number sets the number of failed attempts by Nginx to communicate with the server. If the number of failures reaches this value within the time period defined by the fail_timeout parameter, Nginx considers the server unavailable. The server will not be tried again during the next fail_timeout period. The default number of failed attempts is 1. If set to 0, it will stop counting attempts and assume that the server is always available. You can configure what counts as a failed attempt via the proxy_next_upstream, fastcgi_next_upstream, and memcached_next_upstream directives. By default, the http_404 status is not considered a failed attempt. fail_timeout=time setting

• The time period for counting failed attempts. If the server fails the specified number of attempts during this time, the server is considered unavailable.
• The period of time during which the server is considered unavailable.

By default, the timeout is 10 seconds. backup marks the server as a backup server. When the primary server is unavailable, requests will be transferred to these servers. down marks the server as permanently unavailable and can be used together with the ip_hash directive.

Example:

upstream backend {
  server backend1.example.com weight=5;
  server 127.0.0.1:8080 max_fails=3 fail_timeout=30s;
  server unix:/tmp/backend3;

  server backup1.example.com:8080 backup;
}

Specifies the load balancing method for the server group. Requests are distributed among the servers based on the client's IP address. The first three bytes of the IPv4 address, or the entire address for IPv6, are used as a hash key. This method ensures that requests from the same client will be sent to the same server. Except when a server is considered unavailable, these client requests will be forwarded to other servers, and most likely the same server.

IPv6 addresses are supported starting from versions 1.3.2 and 1.2.2.

If one of the servers is to be temporarily removed, the down parameter should be added. This preserves the current client IP address hash distribution.

example:

upstream backend {
  ip_hash;

  server backend1.example.com;
  server backend2.example.com;
  server backend3.example.com down;
  server backend4.example.com;
}

Starting from versions 1.3.1 and 1.2.2, the ip_hash load balancing method supports setting server weight values.

This directive appeared in version 1.1.4.

Activates caching of connections to upstream servers.

The connections parameter sets the maximum number of connections that each worker process maintains with the backend server. These maintained connections are cached. If the number of connections is greater than this value, the longest unused connection will be closed.

It is important to note that the keepalive directive does not limit the total number of connections that the Nginx process can make to the upstream servers. New connections are always created as needed. The connections parameter should be set slightly lower so that the upstream server can handle the additional incoming connections.

Example of configuring memcached upstream server connection keepalive:

upstream memcached_backend {
  server 127.0.0.1:11211;
  server 10.0.0.2:11211;

  keepalive 32;
}

server {
  ...

  location /memcached/ {
    set $memcached_key $uri;
    memcached_pass memcached_backend;
  }

}

For HTTP proxies, the proxy_http_version directive should be set to "1.1" and the value of the "Connection" header should be cleared.

upstream http_backend {
  server 127.0.0.1:8080;

  keepalive 16;
}

server {
  ...

  location /http/ {
    proxy_pass http://http_backend;
    proxy_http_version 1.1;
    proxy_set_header Connection "";
    ...
  }
}

Alternatively, HTTP/1.0 protocol persistent connections can also be achieved by sending a "Connection: Keep-Alive" header. However, this is not recommended.

For FastCGI servers, you need to set the fastcgi_keep_conn directive to make the connection keepalive work:

upstream fastcgi_backend {
  server 127.0.0.1:9000;

  keepalive 8;
}

server {
  ...

  location /fastcgi/ {
    fastcgi_pass fastcgi_backend;
    fastcgi_keep_conn on;
    ...
  }
}

When using a load balancing method other than the default round-robin method, it must be configured before the keepalive directive.

There is no plan to implement keepalive connections for the SCGI and uwsgi protocols.

This directive appeared in versions 1.3.1 and 1.2.2.

Specifies the load balancing method for the server group. The request is sent to the server with the least active connections according to its weight value. If there are multiple such servers, try using a weighted round-robin method.

Embedded variables

The ngx_http_upstream_module module supports the following embedded variables:

$upstream_addr holds the server's IP address and port or the path to a UNIX domain socket. During the request processing, if multiple servers are tried, their addresses will be concatenated and separated by commas, for example: "192.168.1.1:80, 192.168.1.2:80, unix:/tmp/sock". If there are internal redirects between servers via the "X-Accel-Redirect" header or error_page, then these server groups will be separated by colons, for example: "192.168.1.1:80, 192.168.1.2:80, unix:/tmp/sock : 192.168.10.1:80, 192.168.10.2:80". $upstream_response_time holds the server response time with millisecond precision, (output) in seconds. When multiple responses appear, they are also separated by commas and colons. $upstream_status holds the server's response code. When multiple responses appear, they are also separated by commas and colons. $upstream_http_... holds the value of the server's response header. For example, the value of the "Server" response header can be obtained through the $upstream_http_server variable. Note that only the headers of the last response are preserved.

The above is the full content of this article. I hope it will be helpful for everyone’s study. I also hope that everyone will support 123WORDPRESS.COM.