🟩 Generador nginx.conf

Introduce host, raíz y rutas SSL y activa funciones. Genera un server block para producción con redirección HTTPS, HTTP/2, TLS moderno, HSTS, gzip / brotli, caché estática, PHP-FPM, proxy inverso, WebSocket y try_files.

100% Gratis Sin registro Solo navegador 5 idiomas Modo oscuro

🔒 Sobre la privacidad

・Toda la generación ocurre en tu navegador
・Hosts, rutas y ajustes nunca se envían al servidor
・Sin registros, sin seguimiento, sin base de datos

🎛 Preajustes

📖 Dónde se suele tropezar

Genera un nginx.conf con el bloque server para montajes como un sitio estatico, un proxy inverso o PHP-FPM, y emite ademas las directivas de SSL, gzip, cache y cabeceras de seguridad. Todo se ejecuta en el navegador. Lo que puede generar es sintaxis, no una garantia de que funcione en tu entorno: no puede verificar que exista la ruta del certificado, que el upstream sea alcanzable ni que la raiz de documentos sea la correcta. Y el tiempo que se pierde con nginx no suele irse en una directiva mal escrita, sino en una directiva cuyo significado para nginx difiere del que tenias en la cabeza.

Caso	Qué ocurre	Qué hacer
`location` no se evalua en el orden en que lo escribiste	nginx no prueba los bloques `location` de arriba abajo: elige uno segun una precedencia fija. Primero una coincidencia exacta con `=`, luego la coincidencia de prefijo mas larga (resuelta de inmediato si lleva `^~`), despues las *expresiones regulares (`~` y `~`) en el orden escrito y, si ninguna casa, la coincidencia de prefijo mas larga que quedo en reserva. De modo que mover bloques arriba y abajo a menudo no cambia nada, mientras que anadir un solo bloque con expresion regular roba en silencio peticiones que antes atendia un bloque de prefijo. El sintoma clasico es que los archivos estaticos acaben en PHP, o al reves, y ocurre cuando se malinterpreta la relacion entre `location ~ \.php$` y `location /assets/`**.	No adivines: ejecuta `nginx -T`. Imprime la configuracion final con todos los `include` expandidos, de modo que un descuido como que el mismo `location` exista tambien en otro archivo salta a la vista al momento. Como principio de diseno, resuelve primero los archivos estaticos: escribir `location ^~ /assets/` detiene ahi mismo la evaluacion de expresiones regulares. Escribe con `=` las URL que se resuelven en una sola cosa, como la portada o `favicon.ico`: es lo mas rapido y la intencion queda inequivoca. Tras cualquier cambio, pide URL concretas con `curl` y comprueba: que una configuracion se lea como correcta y que bloque elige nginx en realidad son dos preguntas distintas.
`add_header` se sustituye, no se hereda	La herencia de nginx tiene una regla contraintuitiva. Si un bloque hijo escribe aunque sea una directiva de cierta clase, se descartan todas las de esa clase del padre: se sustituyen, no se suman. El dano es peor con `add_header`: pon cinco cabeceras de seguridad en el bloque `server`, anade una sola linea de control de cache dentro de `location ~ \.php$` y las cinco cabeceras de seguridad desaparecen de las respuestas PHP. No hay error ni aviso: te enteras cuando un escaner te dice que faltan las cabeceras. La misma regla se aplica a `proxy_set_header`: anade una dentro de un `location` y desaparecen todas las cabeceras de proxy definidas mas arriba.	Empieza comprobando las cabeceras de respuesta reales con `curl -I`: lo que dice la configuracion y lo que vuelve son cosas distintas. Hay dos remedios. Mantener las cabeceras en un unico sitio y no escribir jamas `add_header` en un bloque hijo es el mas simple. Si eso no es posible, extrae el conjunto de cabeceras a un archivo aparte e `include` ese archivo en cada `location` que lo necesite: queda duplicado, pero es mucho mejor que desaparecer. Y anade `always` a tus directivas `add_header`: sin eso, las cabeceras no se adjuntan a las respuestas 4xx ni 5xx (siendo las paginas de error, muchas veces, justo lo que querias proteger). La misma precaucion vale para `proxy_set_header`.
Tras un proxy inverso, se rompen las cabeceras y los tamanos	Escribir solo `proxy_pass` deja a tu aplicacion sin saber con que nombre de host ni con que protocolo se la llamo. Si no pasas `Host` y `X-Forwarded-Proto`, la aplicacion genera URL del tipo `http://localhost:3000/...`, las redirecciones entran en bucle y los dominios de las cookies se desajustan. La barra final de `proxy_pass` tambien cambia el significado: `proxy_pass http://app;` pasa la ruta original tal cual, mientras que `proxy_pass http://app/;` retira antes el prefijo del `location`. Ese unico caracter separa funcionar de un 404. Los valores por defecto de tamano y tiempo tambien merecen atencion: el `client_max_body_size` por defecto es 1MB, y una subida mayor se rechaza con un 413 antes de llegar siquiera a tu aplicacion. Y WebSocket no conectara si no defines `Upgrade` y `Connection` de forma explicita.	En un `location` que hace de proxy, escribe al menos estas cuatro: `proxy_set_header Host $host;`, `X-Real-IP $remote_addr;`, `X-Forwarded-For $proxy_add_x_forwarded_for;` y `X-Forwarded-Proto $scheme;`. Y activa en tu aplicacion el ajuste de proxies de confianza para que las respete: un solo lado no basta. Si gestionas subidas, iguala `client_max_body_size` con el limite de tu aplicacion y, si tienes peticiones largas, sube tambien `proxy_read_timeout` (60 segundos por defecto): si cambias solo uno, el mas corto de los dos te seguira cortando. Aplica los cambios con `nginx -t && nginx -s reload` y, cuando recibas un 502, lee `error.log` y no `access.log`: la causa esta escrita casi siempre ahi.

Editar el archivo por si solo no cambia nada. nginx lee su configuracion al arrancar y luego la conserva, de modo que guardar el archivo no altera ningun comportamiento hasta que recargues: cuando creas que lo arreglaste y sigue roto, comprueba primero si recargaste. El orden es siempre nginx -t para comprobar la sintaxis y despues reload: reiniciar sin comprobar significa que, si la configuracion esta mal, nginx no arranca y el sitio cae por completo (mientras que un reload sigue sirviendo con la configuracion anterior cuando la nueva es invalida). Una nota sobre certificados: apunta ssl_certificate a fullchain.pem, no a cert.pem: si falta el certificado intermedio, en el navegador se ve bien mientras curl, las aplicaciones moviles y los entornos antiguos fallan al validar. Como ese fallo no se reproduce en tu propio entorno, no puedes notarlo hasta que alguien lo reporta. Por ultimo, manten los archivos de configuracion bajo control de versiones: un cambio editado directamente en el servidor de produccion desaparece en silencio en el siguiente despliegue.

📖 Cómo usar

1

Elige un preajuste

Elige Static, WordPress, Laravel o Next.js para auto-marcar las opciones recomendadas.
2

Configura host y rutas SSL

Indica server_name, raíz y rutas Lets Encrypt fullchain.pem / privkey.pem.
3

Copia o descarga

Usa los botones para copiar o descargar como .conf.
4

Coloca en nginx y recarga

Colócalo en /etc/nginx/sites-available/, enlaza a sites-enabled, ejecuta nginx -t y systemctl reload nginx.

❓ Preguntas frecuentes

¿Y si aún no tengo certificado SSL?

Usa certbot de Lets Encrypt para emitir un certificado gratis. Activa HSTS solo cuando HTTPS funcione del todo.

nginx -t reporta un error

Suele ser un error en la ruta SSL o socket PHP-FPM. Revisa el número de línea y journalctl -u nginx.

¿Puedo usar .htaccess de Apache en nginx?

No. nginx no lee .htaccess. Para Apache, usa nuestro generador de .htaccess.

🔗 Herramientas relacionadas

🐛 ¿Encontró un problema con esta herramienta?

Gratis, sin registro. Incluso solo los pasos para reproducir ayudan. Los informes van directamente al operador y se usan para corregir.