Nginx Server Config Generator

What This Prompt Does

This prompt generates secure, production-ready Nginx server block configurations. It configures server paths, reverse proxy parameters, HTTP headers, CORS configurations, security policies, and SSL/TLS setups.

System Prompt

You are a senior Systems Engineer. Generate a clean, secure Nginx configuration block.
Ensure the configuration covers:
1. Proper listening ports (e.g. 80 and 443 with http2).
2. Reverse proxy headers (X-Real-IP, X-Forwarded-For, X-Forwarded-Proto).
3. Secure SSL settings (Modern TLS profiles, cipher suites, HSTS headers).
4. Compression settings (Gzip buffers).
5. Clean error handling redirection directives.

User Prompt Template

Generate an Nginx configuration file for:
Domain name: {DOMAIN_NAME}

Backend target service: {BACKEND_PORT}
(e.g., "http://localhost:3000")

Security and SSL profiles: {SSL_CONFIG}
(e.g., "Let's Encrypt certbot paths, enable strict HSTS")

Example Output

server {
    listen 80;
    server_name example.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    server_name example.com;

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    location / {
        proxy_pass http://localhost:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

When to Use This

This prompt is useful when standing up a new NGINX-fronted service and you want a solid starting configuration for reverse proxying, TLS termination, or static file serving — common tasks that follow well-established patterns but are easy to get subtly wrong (missing security headers, incorrect proxy buffer settings) when writing a config from memory.

Tips for Best Results

• Specify the exact use case precisely — reverse proxy to a specific backend port, static file serving with caching headers, or load balancing across multiple upstream servers — since NGINX configuration blocks differ substantially between these scenarios.
• Always test a generated configuration with nginx -t before reloading a live server, since a syntax error in an NGINX config can take down every site it serves, not just the one being modified.
• Ask explicitly for security-hardening directives (HSTS headers, disabling server version disclosure, rate limiting) if the target service is internet-facing, since a minimal working configuration often omits these unless specifically requested.

Keeping a library of previously generated and validated configs for common patterns in your own repository saves time on future similar requests, since NGINX configuration needs tend to repeat across services within the same organization.

A staging environment that mirrors production traffic patterns is the safest place to validate a new configuration under realistic load before it ever reaches a production NGINX instance.