Nginx can place several application processes behind one HTTP endpoint. The earlier configuration defined an upstream group and forwarded requests to two listeners on the same host.
sudo nano /etc/nginx/sites-available/api.example.com
# start of file
# http {
upstream ncluster {
server 127.0.0.1:3000 weight=3;
server 127.0.0.1:3001;
}
server {
listen 80;
listen [::]:80;
server_name api.example.com;
location / {
proxy_pass http://ncluster;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header Connection 'upgrade';
proxy_cache_bypass $http_upgrade;
}
}
# }
# end of file
sudo ln -s /etc/nginx/sites-available/api.example.com /etc/nginx/sites-enabled/
sudo nginx -t
sudo service nginx reloadWhat the configuration expresses
The first backend has weight 3 and the second the default weight 1. Those weights express relative routing preference; they do not reserve CPU or guarantee a throughput ratio. Both backends share one machine, so this arrangement does not isolate host failures.
The proxy forwards the original host, client-address chain, and scheme. Applications should trust forwarded values only through their intended proxy boundary. The example listens on port 80; it does not include certificate or HTTPS configuration.
Check the protocol assumptions
The old snippet sets Connection: upgrade unconditionally. Treat that as a source configuration to review for the protocols being served, rather than a universal header default. Reloading after nginx -t establishes configuration syntax acceptance, not backend health or correct application behavior.
The original references also covered active health checks and a live dashboard. Those Nginx Plus features should not be inferred from an ordinary open-source Nginx installation. No proxy was started or reconfigured here.
References: HTTP load balancing and HTTP health checks.