NGINX Load Balancing – TCP and UDP Load Balancer
Configuring Reverse Proxy
For UDP traffic, also include the udp parameter. TCP is the default protocol for the stream context, so there is no tcp parameter to the listen directive
Optionally, you can tune the size of two in‑memory buffers where NGINX can put data from both the client and upstream connections.
stream { server { listen 12345; #TCP traffic will be forwarded to the "stream_backend" upstream group proxy_pass stream_backend; } server { listen 12346; #TCP traffic will be forwarded to the specified server proxy_pass backend.example.com:12346; proxy_buffer_size 16k; } server { listen 53 udp; #UDP traffic will be forwarded to the "dns_servers" upstream group proxy_pass dns_servers; } # ... }
Configuring TCP or UDP Load Balancing
Note that you do not define the protocol for each server, because that is defined for the entire upstream group by the parameter you include on the listen directive in the server block, which you have created earlier.
The health_check directive enables the health‑check functionality, while the health_check_timeout directive overrides the proxy_timeout value for health checks, as for health checks this timeout needs to be significantly shorter.
To enable health checks for UDP traffic, in the health_check directive specify the udp parameter and optionally the match parameter with the name of a corresponding match block of tests for verifying server responses (see Fine‑Tuning UDP Health Checks):
server { listen 5053; proxy_pass dns_servers; health_check udp match=dns; health_check_timeout 5s; }
Fine‑Tuning Health Checks
By default, NGINX Plus tries to connect to each server in an upstream server group every 5 seconds. If the connection cannot be established, NGINX Plus considers the health check failed, marks the server as unhealthy, and stops forwarding client connections to the server.
To change the default behavior, include these parameters to the health_check directive:
interval– How often (in seconds) NGINX Plus sends health check requests (default is 5 seconds)passes– Number of consecutive health checks the server must respond to to be considered healthy (default is 1)fails– Number of consecutive health checks the server must fail to respond to to be considered unhealthy (default is 1)
server { listen 12345; proxy_pass stream_backend; health_check interval=10 passes=2 fails=3; }
Fine‑Tuning Health Checks with the match Configuration Block
You can verify server responses to health checks by configuring a number of tests. These tests are defined with the match configuration block placed in the stream context. Specify the match block and set its name (here, tcp_test):
The conditions or tests under which a health check succeeds are set with send and expect parameters:
send– The text string or hexadecimal literals (/xfollowed by two hex digits) to send to the serverexpect– Literal string or regular expression that the data returned by the server needs to match
If both the send and expect parameters are specified, then the string from the send parameter must match the regular expression from the expect parameter:
stream { upstream stream_backend { zone upstream_backend 64k; server backend1.example.com:12345; } match http { send "GET / HTTP/1.0 Host: localhost "; expect ~* "200 OK"; } server { listen 12345; health_check match=http; proxy_pass stream_backend; } }
Fine-Tuning UDP Health Checks
To fine‑tune health checks for UDP, specify both send and expect parameters:
Example for DNS:
match dns { send x00x2ax00x00x00x01x00x00x00x00x00x00x03x73x74x6cx04x75x6dx73x6cx03x65x64x75x00x00x01x00x01; expect ~* "health.is.good"; }
On-the-Fly Configuration
Upstream server groups can be easily reconfigured on-the-fly using NGINX Plus REST API. Using this interface, you can view all servers in an upstream group or a particular server, modify server parameters, and add or remove upstream servers.
TODO: