backend?upstream backend {
server 192.168.1.10 weight=3;
server 192.168.1.11 weight=1;
}
server {
listen 80;
location / {
proxy_pass http://backend;
}
}The weight parameter in an nginx upstream block controls how many requests each server receives relative to others. Here, 192.168.1.10 has weight 3 and 192.168.1.11 has weight 1, so 3 out of 4 requests (75%) go to the first server, and 1 out of 4 (25%) to the second.
upstream backend {
server 192.168.1.10:8080;
server 192.168.1.11:8080 max_fails=3 fail_timeout=30s;
server 192.168.1.12:8080 max_fails=two fail_timeout=30s;
}
server {
listen 80;
location / {
proxy_pass http://backend;
}
}The max_fails parameter expects a numeric value. Using the word 'two' instead of a number causes a syntax error, preventing nginx from starting.
The ip_hash; directive in an nginx upstream block ensures that requests from the same client IP address are always sent to the same backend server, enabling session persistence.
Option A uses hash $remote_addr which is valid for consistent hashing on IP but ip_hash is the specific directive for IP hash method. Option A uses sticky which requires a third-party module and is not standard. Option A uses least_conn which balances based on least connections, not IP.
The down parameter marks a server as unavailable. Nginx will not send requests to it but keeps the configuration intact. This is useful for temporary maintenance.
Commenting out or removing the server line requires config changes and reloads. Setting weight to zero also excludes the server from load balancing but down is more explicit and the recommended parameter for this purpose.
The safe workflow is to first edit the config, then test it with nginx -t to catch errors. If the test passes, reload nginx to apply changes without dropping connections. Finally, verify traffic flows to new backends.