Nginx

Nginx utiliza un modelo de E/S no bloqueante y orientado a eventos. Un proceso maestro lee el archivo de configuración y genera uno o más procesos de trabajo (worker processes). Cada worker puede gestionar miles de conexiones simultáneas utilizando un conjunto reducido de descriptores de archivos. Cuando llega una solicitud HTTP, Nginx analiza la línea de solicitud, compara la URI con los bloques de ubicación (location blocks) definidos y, o bien sirve un archivo estático desde el disco, o bien reenvía la solicitud a un servidor upstream mediante la directiva proxy_pass. Posteriormente, la respuesta se devuelve al cliente. Este diseño permite que Nginx logre un alto rendimiento y baja latencia consumiendo relativamente poca memoria.

Instala Nginx desde el gestor de paquetes de tu sistema operativo o compílalo desde el código fuente. Tras la instalación, crea un bloque de servidor en /etc/nginx/sites‑available/ que especifique el nombre de dominio, el directorio raíz y cualquier regla de proxy o reescritura. Habilita el sitio creando un enlace simbólico a /etc/nginx/sites‑enabled/ y luego comprueba la configuración con nginx -t. Si la prueba es correcta, recarga Nginx usando systemctl reload nginx o envía una señal HUP al proceso maestro. Para mejorar el rendimiento, establece worker_processes al número de núcleos de la CPU, habilita las conexiones keepalive y considera añadir proxy_cache para las solicitudes repetidas.

Nginx escribe cada solicitud en el log de acceso (/var/log/nginx/access.log), registrando la IP del cliente, el método de la solicitud, el código de estado y el tamaño de la respuesta. Los errores se registran en /var/log/nginx/error.log. Puedes utilizar herramientas de benchmarking como ab (Apache Bench) o wrk para enviar solicitudes concurrentes y medir la latencia y el rendimiento (throughput). El módulo opcional nginx‑status proporciona una página web que muestra las conexiones activas, el total de solicitudes y el estado actual de lectura/escritura, lo cual es útil para el monitoreo en tiempo real.

• Omitir nginx -t antes de recargar, lo que puede causar una configuración errónea.
• Usar la directiva root por defecto sin un archivo index, lo que provoca el listado de directorios.
• Exponer el puerto de la aplicación backend directamente a internet en lugar de enrutar a través de Nginx.
• No configurar client_max_body_size para la subida de archivos, lo que provoca errores 413.
• Configurar incorrectamente proxy_pass con una barra diagonal al final, lo que cambia la URI pasada al servidor upstream.

Nginx está optimizado para la entrega de archivos estáticos y el proxy inverso, pero no es un servidor de aplicaciones de propósito general. No puede ejecutar código Python, Ruby o PHP directamente; esos lenguajes requieren un proceso separado como uWSGI, Gunicorn o PHP‑FPM. Los algoritmos de equilibrio de carga integrados se limitan a round-robin, least connections e IP hash; el enrutamiento más avanzado puede requerir herramientas externas. Además, cada proceso worker puede manejar un número finito de conexiones definido por worker_connections, por lo que una concurrencia muy alta puede requerir ajustes o workers adicionales.

server {
listen 80;
server_name example.com;
location / {
proxy_pass http://backend:8080;
}
}

El mismo término en las palabras que alguien usa al hablar con un asistente en lugar de escribir en un buscador: escrito desde la situación, y por eso cada pregunta lleva la situación de la que salió.

• Robots Exclusion Protocol (RFC 9309)
• Nginx
• Wikidata — Q306144