Nginx reverse proxy setup with proxy_pass upstreams load balancing and SSL

If you want a single public face for multiple backend webservers without sacrificing your sanity this guide will get you there. We keep the facts straight and the jokes lightly grim. Topics covered include installing Nginx, creating server blocks, proxy_pass configuration, upstreams for load balancing, SSL with Let s Encrypt and common troubleshooting tips.

Install Nginx and confirm the webserver is alive

On Debian or Ubuntu run the usual package manager dance and start the service. For Red Hat derivatives use the equivalent yum or dnf commands. Then check that port 80 responds and that Nginx is not sulking.

sudo apt update
sudo apt install nginx
sudo systemctl enable nginx
sudo systemctl start nginx
sudo nginx -t

nginx -t validates configuration before you reload. That one command will save you from the small panic attack that comes from reloading broken config on a production box.

Create a server block for the public domain

Place a server block file under /etc/nginx/sites-available and symlink it into /etc/nginx/sites-enabled if your distro uses that layout. Give the server_name the domain that clients will visit. That domain is the mask while your backend apps hide in the basement.

• Use a clear server_name that matches your DNS records
• Keep each site in its own file to avoid accidental chaos
• Remember that Nginx directives in the config need a trailing semicolon when you edit the actual file

Configure proxy settings and preserve client context

Inside the server block add a location that forwards requests to an upstream group or directly to a backend. Use proxy_pass to send traffic along. Preserve useful headers so backend apps can still see client IPs and host values.

• Set headers like X-Real-IP and X-Forwarded-For and pass the original Host header
• Use proxy_set_header to forward those headers so your apps do not think every request is a polite bot

Do not forget that proxy_pass and other directives require the correct syntax in the config file. If it helps sleep at night test the file with nginx -t before reloading.

Why use an upstream block

An upstream block lets you name a backend pool and reference it from many server blocks. That makes load balancing, maintenance and clarity less painful.

• List backend hosts in the upstream group
• Choose a basic balancing method such as round robin for starters
• Keep health checks and session affinity in mind as you scale

Test connectivity like a professional or a very curious person

Use curl or an equivalent HTTP client to request the site and confirm the content comes from the intended backend. Inspect response headers to ensure forwarding worked and check status codes for the usual suspects.

curl -I example.com

If you get the wrong content check that the server block points to the right upstream name and that the backend host and port match what the app actually listens on.

Enable SSL with Let s Encrypt and make browsers happier

Automated certificate issuance is your friend. Use certbot or another ACME client to request a certificate for the public domain. Configure Nginx to listen on 443 and reference the certificate files. Redirect plain HTTP to HTTPS so users do not complain in capital letters.

sudo certbot --nginx -d example.com -d www.example.com

Certbot can edit your Nginx configuration for you or provide snippets to paste. Either way make sure the HTTPS server block includes the proxy configuration so encrypted requests are forwarded correctly.

Reload, enable on boot and practice your ritual

Validate config with nginx -t then reload the service. Enable the service so reboots do not result in awkward downtime during a caffeine deprived morning.

sudo nginx -t
sudo systemctl reload nginx
sudo systemctl enable nginx

Check logs and common troubleshooting steps

• Look at the access log and error log to see what Nginx and the backend are saying
• Check firewall rules if connections are being politely blocked
• Validate DNS so that the public domain points at the proxy IP
• Use curl from another host to test end to end

Typical errors include typos in backend hostnames ports that do not match the app and forgetting to include required headers. The logs tell you the truth even when your team does not.

Quick checklist for the tired sysadmin

1. Install Nginx and confirm service is running
2. Create server block with the correct server_name
3. Configure location and proxy_pass to point to upstream or backend
4. Preserve client headers such as X-Real-IP and X-Forwarded-For
5. Obtain SSL from Let s Encrypt and enable HTTPS
6. Validate configuration then reload Nginx
7. Watch logs and fix the tiny errors that ruin lives

There you go. You have a reverse proxy that routes traffic to backend services handles SSL and can grow into a load balancer. If something breaks turn to the logs first and then to a calming beverage second.