devopsClaude

Nginx Configuration Prompt (Claude)

Nginx configurations are easy to get almost right but dangerously wrong in security details. This prompt generates configurations with security headers, modern TLS settings, and rate limiting by default — the settings that are most often missing from hand-written configs. The test command and tuning parameters make the config immediately operational. This variant is formatted for Claude: Optimised for Claude 3.5 Sonnet and Claude 3 Opus. Uses XML tags for structured input and output.

Prompt Template
<role>You are an expert AI assistant with deep knowledge in this domain.</role>

<task>
You are a senior systems engineer specialising in nginx configuration.

Generate a production-ready nginx configuration for the following setup:

Use case: {{use_case}}
Backend servers: {{backend}}
Domain(s): {{domains}}
SSL: {{ssl_setup}}
Caching requirements: {{caching}}
Rate limiting: {{rate_limiting}}
Additional requirements: {{additional_requirements}}

The configuration must include:
1. Main server block with HTTPS redirect from HTTP
2. SSL configuration using modern TLS 1.2/1.3 only
3. Security headers (HSTS, X-Frame-Options, X-Content-Type-Options, CSP)
4. Gzip compression for text assets
5. Request rate limiting
6. Upstream health checks (if applicable)
7. Access and error log configuration

After the config, provide:
- How to test the configuration: `nginx -t`
- Key tuning parameters to adjust based on server resources
- Security recommendations specific to this setup
</task>

<instructions>Structure your response clearly with headers and concrete examples.</instructions>

Variables

{{use_case}}What nginx is doing, e.g., "reverse proxy to Node.js API", "static file server", "load balancer for 3 app servers"
{{backend}}Backend server(s), e.g., "localhost:3000", "app1:8080, app2:8080, app3:8080"
{{domains}}Domain name(s), e.g., "api.example.com, www.example.com"
{{ssl_setup}}SSL approach: "Let's Encrypt with certbot", "self-signed for dev", "existing cert at /path/to/cert"
{{caching}}Caching needs, e.g., "cache static assets for 1 year, no caching for API routes", or "None"
{{rate_limiting}}Rate limit requirements, e.g., "100 req/min per IP for API", or "None"
{{additional_requirements}}Extra requirements, or "None"

Example

Input
use_case: Reverse proxy to Node.js API
backend: localhost:3000
domains: api.example.com
ssl_setup: Let's Encrypt with certbot
caching: No caching for API routes
rate_limiting: 60 req/min per IP
additional_requirements: Add CORS headers for https://app.example.com
Output
upstream nodejs_backend {
    server localhost:3000;
    keepalive 32;
}

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

server {
    listen 443 ssl http2;
    server_name api.example.com;
    ssl_certificate /etc/letsencrypt/live/api.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/api.example.com/privkey.pem;
    ssl_protocols TLSv1.2 TLSv1.3;
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
    ...
}

Related Tools

FAQ

How do I reload nginx without downtime?
Use `nginx -s reload` which sends a SIGHUP to reload the configuration without dropping existing connections. Always run `nginx -t` first to validate the configuration before reloading.
How do I configure nginx for WebSocket proxying?
Add "Support WebSocket upgrades" to additional_requirements. The AI will add the necessary Upgrade and Connection headers and a longer proxy_read_timeout for persistent connections.
What is the difference between proxy_pass and upstream?
proxy_pass with a direct address is simpler for single backends. upstream blocks are needed for load balancing multiple servers or configuring keepalive connections. Always use upstream blocks in production for flexibility.

Related Prompts