Generador de configuración nginx — HTTP/3, WebSocket, seguridad

¿Qué hace el generador de configuración nginx?

El generador es un editor para server blocks de nginx. Elija entre ocho tipos de bloque (alojamiento estático, fallback SPA, reverse-proxy, PHP-FPM, load-balancer, redirección sola, stream TCP, stream UDP), ajuste campos como server_name, root y upstream, y el generador compone todas las directivas necesarias en el orden correcto. También puede pegar un .htaccess existente — el generador traduce redirecciones, rewrites, cabeceras y ErrorDocuments en directivas nginx. Todo sucede en el navegador. Sin subida, sin cuenta, sin banner de cookies.

Los seis presets cubren los stacks más frecuentes:

• SPA — alojamiento estático — single-page app con Astro/SvelteKit/Vite, long-cache para assets con hash, fallback a index.html, HTTP/3 activo.
• Node.js — reverse-proxy — servidor Node/Bun tras nginx con upgrade WebSocket correctamente cableado.
• Python — Uvicorn/ASGI — FastAPI o Starlette vía Uvicorn, rate-limit «API».
• WordPress — PHP-FPM — PHP-FPM por socket Unix, wp-config.php y .env bloqueados.
• HTTPS estricto — Audit-A — afinado para una A en Mozilla Observatory, TLS 1.3, COOP/COEP/CORP.
• Load-balancer — least_conn — nginx delante de tres nodos backend, failover de salud con max_fails.

¿Qué tipos de server block incorpora?

Ocho tipos, agrupados por caso:

• Alojamiento estático — try_files $uri $uri/ =404;. Clásico para Hugo, 11ty, HTML puro.
• Fallback SPA — try_files $uri $uri/ /index.html; más long-cache para assets con hash. Estándar para cualquier app con enrutado en cliente.
• Reverse-proxy — proxy_pass hacia un upstream, con todas las cabeceras X-Forwarded-* usuales. Upgrade WebSocket opcional.
• PHP-FPM — fastcgi_pass a un socket Unix, con permalinks try_files y reglas deny para wp-config.php, .env, .git.
• Load-balancer — proxy_pass http://backend_pool; más la plantilla upstream correspondiente (comentada porque upstream {} vive fuera de server {}).
• Redirección sola — return 301 https://www.example.com$request_uri;. Para canonicalización www y migraciones de dominio.
• Stream TCP — para el ámbito stream {}, p. ej. proxying Postgres/Redis. El bloque comenta el cambio de ámbito.
• Stream UDP — análogo para DNS o QUIC-forward.

¿Cómo funciona el soporte HTTP/3 y QUIC?

HTTP/3 sustituye a HTTP/2 y usa QUIC en lugar de TCP como transporte. QUIC se basa en UDP, integra TLS en la configuración de conexión y elimina el head-of-line blocking de HTTP/2. nginx incluye QUIC en la build oficial desde la versión 1.25 (antes solo en la rama nginx-quic). El generador emite cuatro directivas al activar HTTP/3:

listen 443 quic reuseport;
listen [::]:443 quic reuseport;
http3 on;
ssl_early_data on;
add_header Alt-Svc 'h3=":443"; ma=86400' always;

La cabecera Alt-Svc indica a los navegadores que HTTP/3 está disponible en el puerto 443; ma=86400 cachea esa información durante 24 horas. Los navegadores sin HTTP/3 ignoran la cabecera y permanecen en HTTP/2.

¿Por qué importa la corrección del upgrade WebSocket?

El reverse-proxying WebSocket falla en la mayoría de las configs nginx ingenuas porque falta el upgrade de conexión. El patrón correcto consta de cuatro partes:

1. Directiva map en el ámbito http {} — traduce la cabecera Upgrade enviada por el cliente a un valor Connection apto:

   map $http_upgrade $connection_upgrade {
     default upgrade;
     ''      close;
   }

2. proxy_set_header Upgrade $http_upgrade; — pasa la señal de upgrade al backend.
3. proxy_set_header Connection $connection_upgrade; — sobreescribe el Connection: close por defecto que nginx coloca en reverse-proxy.
4. proxy_read_timeout 86400s; — pone el read-timeout a 24 horas para que los WebSockets inactivos no se corten a los 60 segundos (default de nginx).

El generador despliega las cuatro automáticamente al marcar WebSocket en un bloque reverse-proxy o load-balancer. Es el dolor n.º 1 de los setups WebSocket — y la causa principal de los «mi conexión se corta sin parar» en los foros.

¿Qué cabeceras de seguridad se emiten?

Seis cabeceras pertenecen a todo bloque nginx moderno (véase Mozilla Web Security Guidelines):

• Strict-Transport-Security — HSTS con max-age=31536000; includeSubDomains; preload. Preload activo por defecto, con interruptor para desactivarlo en subdominios sin HTTP.
• Content-Security-Policy — valor de partida con default-src 'self', frame-ancestors 'none'. Interruptor de modo report-only para el despliegue.
• Permissions-Policy — todo desactivado por defecto (camera=(), microphone=(), geolocation=(), payment=(), usb=(), interest-cohort=(), browsing-topics=()).
• Cross-Origin-Opener-Policy — same-origin contra ataques con window.opener.
• Cross-Origin-Embedder-Policy — opcional require-corp para casos de SharedArrayBuffer.
• Cross-Origin-Resource-Policy — same-origin bloquea incrustaciones cross-origin de sus propios assets.

Cada cabecera lleva el flag always. Sin always, nginx descarta cabeceras en respuestas 4xx/5xx — lo que muchas herramientas de auditoría (Mozilla Observatory, securityheaders.com) puntúan como infracción A. Antes del despliegue, valide su CSP en el evaluador CSP externo.

¿Cómo funciona el perfil de rate-limit?

El rate-limiting nginx combina dos directivas:

• limit_req_zone en el ámbito http {} — reserva memoria compartida y define la tasa.
• limit_req zone=<nombre> burst=<n> nodelay; en el bloque location — referencia la zona.

Error frecuente en generadores en línea públicos: la zona se emite pero falta la referencia en location — la zona queda totalmente sin uso (véase el issue abierto en el generador en línea más popular). El generador emite ambas juntas e inyecta la referencia en el primer location del server block. Tres perfiles:

• Gentle — 30 r/s, burst 50, limit_conn 100. Para sitios web con tráfico de usuarios real.
• API — 10 r/s, burst 20, limit_conn 50. Para APIs REST/GraphQL con throttling por token.
• Strict — 5 r/s, burst 10, limit_conn 20. Para endpoints de login, receptores de webhooks, rutas críticas.

burst define cuántas peticiones por encima de la tasa se aceptan antes de devolver 429. nodelay significa que las peticiones en burst se procesan al instante, sin temporización por la tasa. Sin nodelay, nginx retrasaría artificialmente una petición en burst — no el comportamiento deseado en la práctica.

¿Qué hace el convertidor .htaccess a nginx?

Apache y nginx tienen modelos de configuración distintos: Apache relee .htaccess en cada petición (costoso pero flexible), nginx analiza su configuración una vez al reload (rápido pero sin override por petición). No hay conversión 1:1 completa, pero las directivas clave son mapeables:

Apache	nginx
Redirect 301 /old /new	rewrite ^/old$ /new permanent;
Redirect 302 /a /b	rewrite ^/a$ /b redirect;
RewriteRule ^foo$ /bar [L]	rewrite ^foo$ /bar last;
RewriteRule … [R=301,L]	rewrite … permanent;
Header always set X-Frame-Options DENY	add_header X-Frame-Options "DENY" always;
ErrorDocument 404 /404.html	error_page 404 /404.html;
Options -Indexes	autoindex off;
Require ip 192.168.1.1	allow 192.168.1.1;
Deny from 203.0.113.4	deny 203.0.113.4;
<IfModule>	comentado en plano (nginx no tiene condicional por módulo)

Las directivas no mapeables vuelven como comentario # TODO (could not convert): …. El convertidor es determinista — la misma entrada produce siempre la misma salida, sin rate-limit de IA, sin ida y vuelta a la nube. La nota de cabecera («pegar dentro de su bloque server { ... }») es lectura obligatoria — las directivas emitidas deben ir al ámbito correcto.

¿Qué pain-points evita el generador?

Cuatro clásicos que aparecen una y otra vez en tutoriales nginx — y que el generador esquiva:

1. WebSocket corta a los 60 segundos — la causa más frecuente es la falta de proxy_read_timeout 86400s; más cabeceras de upgrade incorrectas. El generador pone ambas automáticamente.
2. Zona de rate-limit sin referencia — la limit_req_zone se emite pero limit_req en el bloque location falta. Efecto: cero. El generador emite ambas juntas.
3. Cabeceras de seguridad desaparecen en páginas de error — sin always, nginx descarta cabeceras en 4xx/5xx. El generador pone always en cada add_header.
4. HTTP/3 mal configurado — falta reuseport, falta ssl_early_data, sin cabecera Alt-Svc. El generador emite las cuatro directivas al activar HTTP/3.

¿Cómo se gestiona la privacidad?

100 % en el cliente. El generador corre por completo en el navegador. No hay endpoint de servidor para validar la configuración, ni llamada de telemetría, ni cookie, ni cuenta. Si cierra la pestaña, sus ajustes desaparecen — el generador no persiste nada. Para conservar un historial, descargue la nginx.conf tras cada edición y versiónela en el repositorio.

Lo que deliberadamente no se construye

• Sin validación en directo con nginx -t — exigiría una ida y vuelta al servidor o un porte WebAssembly de nginx. En su lugar, la cabecera del generador y la pista de UI remiten a sudo nginx -t tras el despliegue.
• Sin emisión automática de Let’s Encrypt — el generador solo emite el snippet webroot de Certbot. La activación del certificado requiere acceso al servidor y queda fuera del navegador.
• Sin modo GUI Nginx Proxy Manager — para un flujo GUI-first use directamente Nginx Proxy Manager. Este generador es para devs que mantienen la config como código.
• Sin reglas ngx_mod_security — el ajuste WAF es una herramienta aparte (demasiado especializada, demasiado dependiente del ruleset).
• Sin variante Apache 2.2 — .htaccess 2.2 lo cubre la herramienta hermana htaccess-generator.
• Sin editor de perfil de caching — los defaults gzip y la regla long-cache del bloque SPA bastan para el 90 % de los casos.

¿Dónde encuentro más detalles?

• Documentación de nginx — referencia oficial de directivas
• nginx en Wikipedia — historia, arquitectura, usos
• Mozilla SSL Configuration Generator — referencia de perfiles TLS
• hstspreload.org — lista de envío para dominios HSTS-preload
• CSP Evaluator — validador externo de Content-Security-Policy
• RFC 9114 (HTTP/3) — especificación HTTP/3
• Cloudflare Learning Center — WebSocket — fundamentos del protocolo WebSocket