Proxy Setup

You are a DevOps engineer or system administrator. The user wants to set up a reverse proxy configuration to route incoming traffic to backend services.

What to check first

• Verify your proxy server is installed: nginx -v or apache2 -v
• Check which ports are available: netstat -tuln | grep LISTEN
• Confirm backend services are running and accessible: curl http://localhost:3000 (or your backend port)

Steps

1. Open your nginx configuration file at /etc/nginx/sites-available/default or /etc/nginx/nginx.conf
2. Create an upstream block that defines your backend server(s) with their IP address and port
3. Inside the server block listening on port 80 (or 443 for HTTPS), add a location / directive
4. Set proxy_pass to point to your upstream group using the syntax http://upstream_name
5. Configure essential proxy headers: proxy_set_header Host $host to preserve the original host
6. Add proxy_set_header X-Real-IP $remote_addr to pass the client's real IP to backends
7. Add proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for for load balancer compatibility
8. Test your configuration syntax with nginx -t
9. Reload nginx: sudo systemctl reload nginx (or sudo service nginx reload)
10. Verify traffic flows correctly: curl -I http://localhost and check backend access logs

Code

# /etc/nginx/sites-available/default

upstream backend_servers {
    server 192.168.1.10:3000;
    server 192.168.1.11:3000;
    server 192.168.1.12:3000;
}

server {
    listen 80;
    server_name example.com www.example.com;

    client_max_body_size 100M;

    location / {
        proxy_pass http://backend_servers;
        
        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_connect_timeout 60s;
        proxy_send_timeout 60s;
        proxy_read_timeout 60s;
        
        proxy_buffering on;
        proxy_buffer_size 4k;
        proxy_buffers 8 4k;
    }

    location /static/ {
        alias /var/www/static/;
        expires 30d;
    }

    location /health {
        access_log off;
        return 200 "healthy\n";
        add_header Content-Type text/plain;
    }
}

Pit

Common Pitfalls

• Treating this skill as a one-shot solution — most workflows need iteration and verification
• Skipping the verification steps — you don't know it worked until you measure
• Applying this skill without understanding the underlying problem — read the related docs first

When NOT to Use This Skill

• When a simpler manual approach would take less than 10 minutes
• On critical production systems without testing in staging first
• When you don't have permission or authorization to make these changes

How to Verify It Worked

• Run the verification steps documented above
• Compare the output against your expected baseline
• Check logs for any warnings or errors — silent failures are the worst kind

Production Considerations

• Test in staging before deploying to production
• Have a rollback plan — every change should be reversible
• Monitor the affected systems for at least 24 hours after the change