Nginx como servidor web

Un servidor web es un programa que se queda escuchando en un puerto (el 80 para HTTP, el 443 para HTTPS). Cuando llega una petición, la lee (método, ruta, cabeceras), decide qué hacer con ella y devuelve una respuesta con su código de estado, sus cabeceras y su contenido.

Para un archivo estático, el trabajo es buscarlo en el disco y enviarlo con el tipo correcto (Content-Type). Para lo dinámico, se lo pasa a tu aplicación (Node.js, Python, PHP…) y reenvía su respuesta. Por el camino suele ocuparse de HTTPS, la compresión, la caché y los registros de acceso.

Al arrancar, Nginx crea un proceso maestro que lee la configuración, abre los puertos y lanza varios procesos worker, normalmente uno por núcleo de CPU. El maestro no atiende peticiones: solo vigila a los workers y los sustituye si hace falta.

Cada worker atiende miles de conexiones con un bucle de eventos y E/S no bloqueante: en lugar de quedarse esperando a que un cliente lento termine de enviar datos, el sistema operativo (con epoll en Linux o kqueue en BSD y macOS) le avisa cuando una conexión tiene algo listo, y mientras tanto atiende otras. El modelo clásico de Apache, en cambio, dedicaba un proceso o un hilo a cada conexión, que consume mucha más memoria con miles de clientes a la vez.

Un bloque server es un servidor virtual: con listen dices el puerto y con server_name, los dominios. Así, una sola máquina puede servir muchas webs distintas. Nginx elige el bloque comparando la cabecera Host de la petición con los server_name de los bloques que escuchan en ese puerto.

Si ninguno coincide, se usa el servidor por defecto de ese puerto: el primero que aparece o el que marques con listen 80 default_server.

Dentro de un server, cada location aplica una configuración a las rutas que encajan con él. Hay cuatro tipos: = para una ruta exacta, un prefijo normal como /api/, ^~ para un prefijo que gana a las expresiones regulares, y ~ o ~* para expresiones regulares (la segunda sin distinguir mayúsculas).

El orden de elección no es el del archivo: primero se busca una coincidencia exacta; si no la hay, Nginx recuerda el prefijo más largo que encaja. Si ese prefijo lleva ^~, lo usa; si no, prueba las expresiones regulares en orden y se queda con la primera que encaje. Solo si ninguna lo hace usa el prefijo recordado.

root indica la carpeta base: con root /var/www/tienda, una petición a /css/app.css se busca en /var/www/tienda/css/app.css. Es decir, Nginx añade la ruta de la petición a la carpeta.

try_files prueba varias opciones en orden y usa la primera que exista. La variable $uri es la ruta pedida; $uri/ prueba si es una carpeta con un index.html dentro. El último parámetro es el plan B: un código de error como =404 o una ruta a la que redirigir internamente.

En una SPA hecha con React, Vue o Angular, la ruta /productos/42 no existe como archivo: la crea el router de JavaScript en el navegador. Si el usuario recarga en esa página o la abre desde un enlace, el navegador pide /productos/42 al servidor y, sin más configuración, recibe un 404.

La solución es que, cuando no exista ningún archivo, Nginx devuelva index.html con un 200. El navegador carga la app, el router lee la URL y pinta la vista de ese producto. Es una sola línea: try_files $uri $uri/ /index.html;.

El navegador anuncia qué compresiones entiende con la cabecera Accept-Encoding. Con gzip on, Nginx comprime la respuesta al vuelo y responde con Content-Encoding: gzip. Los formatos de texto como HTML, CSS, JavaScript, JSON o SVG suelen quedarse en una fracción de su tamaño original.

Para no comprimir en cada petición, tu build puede generar versiones ya comprimidas (app.js.gz) y gzip_static on las sirve directamente. Brotli comprime algo más que gzip, pero en el Nginx de código abierto requiere un módulo adicional.

Con Cache-Control: max-age=31536000 (un año en segundos), el navegador reutiliza el archivo sin preguntar al servidor. En Nginx lo pones con expires 1y o con add_header Cache-Control …. Además, Nginx acompaña cada archivo estático de un ETag y un Last-Modified: cuando la copia caduca, el navegador pregunta «¿ha cambiado?» y, si no, recibe un 304 Not Modified sin contenido.

La estrategia habitual combina dos reglas. Los archivos con un hash en el nombre (app.3f9a1c.js), que generan los bundlers, nunca cambian: si cambia el contenido, cambia el nombre. Se cachean un año con immutable. El index.html, que es el que apunta a esos nombres, se sirve con no-cache para que el navegador compruebe siempre si hay una versión nueva.

TLS es el protocolo que cifra la conexión en HTTPS. «Terminar» TLS significa que Nginx tiene el certificado y la clave privada, negocia el cifrado con el navegador y descifra las peticiones. Después las pasa a tu app por HTTP normal, dentro de la máquina o de la red privada.

Así, tu aplicación no tiene que saber nada de certificados, y los renuevas en un solo sitio. Let's Encrypt emite certificados gratuitos y herramientas como Certbot los renuevan automáticamente.

Aunque tu web vaya por HTTPS, mucha gente escribe la dirección sin protocolo y el navegador puede probar primero con http://. Un bloque server en el puerto 80 que solo hace return 301 https://$host$request_uri; los manda a la versión segura conservando el dominio y la ruta.

Para que el navegador ni siquiera intente la versión insegura en las siguientes visitas, se añade la cabecera HSTS (Strict-Transport-Security): le dice que, durante un tiempo, use siempre HTTPS para ese dominio.