Fundamentos de Nginx como servidor web

¿Qué hace Nginx en la entrega de contenido web?

Nginx es un servidor web y proxy que recibe solicitudes HTTP/HTTPS y devuelve respuestas (archivos estáticos, contenido generado por una app aguas arriba, o errores controlados). En un escenario básico de “servir una web estática”, Nginx se encarga de: aceptar conexiones, interpretar la solicitud (método, ruta, cabeceras), decidir qué bloque de configuración aplica, localizar el recurso en disco y responder con el contenido y cabeceras correctas (por ejemplo, Content-Type según el tipo MIME).

Flujo de una solicitud HTTP: del cliente a la respuesta

• 1) Cliente: el navegador solicita GET / a un dominio o IP.
• 2) Resolución y conexión: DNS resuelve el dominio a una IP; el cliente abre una conexión TCP (y TLS si es HTTPS).
• 3) Nginx acepta la conexión: un proceso de Nginx acepta el socket y gestiona la lectura/escritura.
• 4) Selección de configuración: Nginx elige el server adecuado (por IP:puerto y server_name) y luego el location que mejor coincide con la URI.
• 5) Resolución del recurso: si es estático, combina root (o alias) con la ruta solicitada y aplica index si procede.
• 6) Respuesta: envía código de estado (200/404/301…), cabeceras (incluyendo tipo MIME) y el cuerpo (HTML, CSS, imagen…).
• 7) Conexión: puede mantenerse abierta (keep-alive) para más solicitudes o cerrarse.

Arquitectura: eventos y procesos de trabajo

Nginx está diseñado para manejar muchas conexiones concurrentes con un modelo orientado a eventos. En lugar de crear un hilo por conexión (modelo típico “thread-per-connection”), Nginx usa un conjunto pequeño de procesos que atienden múltiples conexiones de forma no bloqueante.

Procesos principales: master y workers

• Master process: lee la configuración, abre sockets de escucha (por ejemplo, :80), gestiona el ciclo de vida de los workers y coordina recargas/actualizaciones.
• Worker processes: procesan conexiones y solicitudes. Cada worker puede manejar miles de conexiones simultáneas usando un bucle de eventos.

Modelo orientado a eventos (event loop)

Los workers usan mecanismos del sistema operativo (por ejemplo, epoll en Linux) para recibir notificaciones cuando un socket está listo para leer o escribir. Esto permite que un worker “salte” entre conexiones activas sin quedarse bloqueado esperando I/O.

Concurrencia: cómo Nginx maneja muchas conexiones

La concurrencia en Nginx se apoya en dos ideas: multiproceso (varios workers) y eventos no bloqueantes (cada worker atiende muchas conexiones). Dos directivas típicas relacionadas con capacidad son:

• worker_processes: cuántos workers se lanzan (a menudo se ajusta a núcleos de CPU).
• worker_connections: cuántas conexiones simultáneas puede manejar cada worker.

Capacidad teórica aproximada: worker_processes × worker_connections (hay límites adicionales: descriptores de archivo del sistema, memoria, etc.).

Continúa en nuestra aplicación.

• Escuche el audio con la pantalla apagada.
• Obtenga un certificado al finalizar.
• ¡Más de 5000 cursos para que explores!

O continúa leyendo más abajo...

Descargar la aplicación

Estructura de configuración: directivas y bloques

La configuración de Nginx se compone de directivas (instrucciones) y bloques (contextos) que agrupan directivas. La lectura es jerárquica: lo definido en un contexto superior puede heredarse o sobrescribirse en uno inferior.

Contextos comunes

• main: nivel superior (fuera de cualquier bloque).
• events { ... }: parámetros del motor de eventos.
• http { ... }: configuración para HTTP (servidores, tipos MIME, logs, etc.).
• server { ... }: un “sitio” o servidor virtual (por puerto/IP y nombre).
• location { ... }: reglas para rutas específicas dentro de un server.

Ejemplo mínimo comentado

events { worker_connections 1024; } http { include       mime.types; default_type  application/octet-stream; server { listen 80; server_name ejemplo.local; root /var/www/ejemplo; index index.html; location / { try_files $uri $uri/ =404; } } }

Ideas clave del ejemplo:

• include mime.types; carga el mapa de extensiones a tipos MIME (por ejemplo, .html → text/html).
• default_type se usa si no se puede determinar el tipo MIME.
• root define el directorio base para resolver rutas.
• index define el archivo por defecto cuando se pide un directorio (por ejemplo, /).
• location / aplica a todas las rutas bajo /.
• try_files intenta servir el archivo exacto; si no existe, devuelve 404.

Ciclo de arranque y recarga de configuración

Arranque: qué ocurre cuando Nginx inicia

• Lee y parsea la configuración.
• Abre puertos de escucha definidos en listen.
• Lanza el master y los workers.
• Empieza a aceptar conexiones.

Validar cambios antes de aplicarlos (sin interrumpir)

Antes de recargar, valida sintaxis y coherencia:

nginx -t

Si tu sistema usa rutas no estándar o múltiples archivos, también puedes indicar el archivo principal:

nginx -t -c /etc/nginx/nginx.conf

Para ver la configuración efectiva (útil cuando hay includes):

nginx -T

Recarga “en caliente” (reload) sin cortar el servicio

Una recarga correcta permite aplicar cambios sin tumbar conexiones activas: el master re-lee la configuración, lanza nuevos workers con la configuración actualizada y va retirando los workers antiguos de forma ordenada.

nginx -s reload

En sistemas con systemd, también es común:

systemctl reload nginx

Guía práctica segura para cambios de configuración

1. Edita el archivo del sitio (por ejemplo, en /etc/nginx/conf.d/ o /etc/nginx/sites-available/ según la distribución).

2. Valida la configuración:

   nginx -t

3. Recarga sin interrupción:

   nginx -s reload

4. Verifica desde el cliente:

   curl -i http://TU_HOST/

Mapa conceptual de términos clave

Primer objetivo práctico: servir una página estática

Paso 1: crear el directorio del sitio y un archivo HTML

sudo mkdir -p /var/www/primer-sitio sudo tee /var/www/primer-sitio/index.html > /dev/null <<'HTML' <!doctype html> <html lang="es"> <head>   <meta charset="utf-8">   <title>Mi primer sitio con Nginx</title> </head> <body>   <h1>Hola desde Nginx</h1>   <p>Página estática servida correctamente.</p> </body> </html> HTML

Paso 2: definir un server block

Crea un archivo de configuración para el sitio. La ruta exacta depende de tu distribución; dos opciones habituales son /etc/nginx/conf.d/ o el esquema sites-available/sites-enabled. Ejemplo genérico usando conf.d:

sudo tee /etc/nginx/conf.d/primer-sitio.conf > /dev/null <<'NGINX' server {     listen 80;     server_name _;     root /var/www/primer-sitio;     index index.html;     location / {         try_files $uri $uri/ =404;     } } NGINX

Nota: server_name _; hace que este bloque actúe como comodín. En entornos con varios sitios, conviene usar un nombre de dominio específico.

Paso 3: validar y recargar

sudo nginx -t sudo nginx -s reload

Paso 4: probar desde el cliente

curl -i http://127.0.0.1/

Debes ver un HTTP/1.1 200 OK y un Content-Type coherente (por ejemplo, text/html). Si obtienes 404, revisa root, el nombre del archivo index.html y que el bloque server esté siendo seleccionado (puerto y server_name).