GardenCloud & systems

Reviewing a small Nginx proxy configuration

A reverse-proxy example whose invalid upstream address and mismatched enable path need correction before reuse.

This older note combined an Nginx virtual host, a backend port, WebSocket headers, and the commands used to enable the site:

sudo nano /etc/nginx/sites-available/proxy.example.com

# Content

server {
  listen 80;
  # The host name to respond to
  server_name proxy.example.com;

  location / {
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header Host $host;

    proxy_pass http://192.168.1.345:8765;

    # enable WebSockets
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
  }
}

# Make alias and apply
sudo ln -s /etc/nginx/sites-available/other.example.com /etc/nginx/sites-enabled/
sudo nginx -t
sudo service nginx reload

Two details to catch before reuse

The upstream 192.168.1.345 is not a valid IPv4 address: its last octet exceeds the valid range. The enable command also names a different site file from the one edited at the top. The generic hostnames preserve that mismatch so it remains visible.

The routing idea is straightforward, but the original listing is not runnable unchanged. Validate the intended upstream and enabled configuration, then inspect nginx -t before a reload. No server configuration was applied for this revision.

← Back to the garden