NGINX es un potente servidor web que tambi\u00e9n funciona como proxy inverso y balanceador de carga. Suele ser elegido por quienes buscan tiempos de carga m\u00e1s r\u00e1pidos y un manejo confiable del tr\u00e1fico. Esta gu\u00eda desglosa los conceptos b\u00e1sicos de la configuraci\u00f3n del servidor NGINX, d\u00e1ndote un mapa para alojar desde portafolios personales hasta aplicaciones de alto tr\u00e1fico.<\/p>\n\n\n\n
Ver\u00e1s c\u00f3mo configurar NGINX con directivas, bloques HTTP, bloques de servidor y bloques de ubicaci\u00f3n. Cada elemento importa a su manera. Al comprender estos elementos centrales, podr\u00e1s crear una configuraci\u00f3n de servidor NGINX bien estructurada y f\u00e1cil de mantener. Si eres nuevo en NGINX, aprender\u00e1s tambi\u00e9n buenas pr\u00e1cticas en el proceso.<\/p>\n\n\n\n
\u00bfTe preguntas c\u00f3mo servir m\u00faltiples dominios u optimizar el rendimiento? \u00bfTienes curiosidad por usar bloques de ubicaci\u00f3n para rutas o archivos espec\u00edficos? Al terminar, tendr\u00e1s una idea clara de c\u00f3mo hacer que NGINX trabaje a tu favor. Comencemos.<\/p>\n\n\n\n
\u00bfQu\u00e9 hace NGINX? NGINX es un software de c\u00f3digo abierto dise\u00f1ado para manejar un gran n\u00famero de conexiones concurrentes sin ralentizarse. Administra desde la entrega de archivos est\u00e1ticos hasta el balanceo de carga para sitios web concurridos. Muchas personas lo llaman un servidor web NGINX, pero tambi\u00e9n funciona como proxy inverso NGINX, lo que resulta \u00fatil cuando necesitas proteger los servicios de back-end del acceso p\u00fablico directo.<\/p>\n\n\n\n
Apache ha sido una opci\u00f3n tradicional para el alojamiento web, pero procesa las solicitudes de una forma m\u00e1s basada en procesos. Este enfoque puede volverse pesado cuando el tr\u00e1fico aumenta. En cambio, NGINX usa un dise\u00f1o basado en eventos para atender a m\u00e1s clientes con menos recursos. Esto suele resultar en un mejor rendimiento y menor uso de memoria.<\/p>\n\n\n\n
Lo ver\u00e1s usado por peque\u00f1as empresas, grandes marcas y quienes ejecutan servicios de streaming. \u00bfPor qu\u00e9? Porque es flexible. Por ejemplo, puedes descargar el procesamiento SSL en NGINX y pasar tr\u00e1fico sin cifrar a los servidores back-end. Tambi\u00e9n puedes distribuir las solicitudes entrantes entre varios servidores tras bambalinas.<\/p>\n\n\n\n
En esencia, \u00bfqu\u00e9 es NGINX? Es un motor que maneja la concurrencia a escala, sirve archivos est\u00e1ticos de forma eficiente y gestiona cargas de trabajo complejas sin problemas.<\/p>\n\n\n\n
NGINX se basa en directivas para hacer su trabajo. Cada directiva es como una instrucci\u00f3n que le dice al servidor c\u00f3mo comportarse. Normalmente las encontrar\u00e1s en el archivo de configuraci\u00f3n de NGINX, generalmente en Y siempre terminan con punto y coma<\/strong>.<\/p>\n\n\n\n Ver\u00e1s directivas de configuraci\u00f3n de NGINX en diferentes contextos. Algunas residen en el \u00e1mbito principal (global), que se aplica a todo el servidor. Otras pertenecen al bloque http<\/strong>, al bloque server<\/strong> o al bloque location<\/strong>. Algunas directivas globales de NGINX definen permisos de usuario o procesos de trabajo, d\u00e1ndote un marco general.<\/p>\n\n\n\n Un ejemplo sencillo:<\/p>\n\n\n\n Estas l\u00edneas aclaran qui\u00e9n ejecuta NGINX, cu\u00e1ntos procesos de trabajo deben iniciarse y d\u00f3nde almacenar el archivo PID. Debajo de estas, a menudo ver\u00e1s:<\/p>\n\n\n\n para configuraciones espec\u00edficas de HTTP.<\/p>\n\n\n\n Dentro de http<\/strong>, puedes a\u00f1adir directivas para compresi\u00f3n, cach\u00e9 o registros. Luego tendr\u00e1s server blocks<\/strong> y location blocks<\/strong> para instrucciones espec\u00edficas de dominio o de ruta. La jerarqu\u00eda importa: si colocas algo en el bloque http, se comparte entre todos los bloques de servidor a menos que se sobrescriba en un nivel inferior. Mantener un seguimiento de esta jerarqu\u00eda te ayudar\u00e1 a organizar tus archivos con menos errores.<\/p>\n\n\n\n En la mayor\u00eda de las configuraciones, el bloque HTTP de NGINX existe en el archivo principal Directivas t\u00edpicas en esta secci\u00f3n podr\u00edan establecer el tipo de contenido por defecto, gestionar tiempos de espera de conexi\u00f3n o activar la compresi\u00f3n de archivos. Por ejemplo:<\/p>\n\n\n\n Aqu\u00ed, Piensa en esto como un lienzo general<\/strong>. Cualquier configuraci\u00f3n definida en el bloque HTTP se aplica globalmente, a menos que un bloque m\u00e1s profundo o directiva la sobrescriba.<\/p>\n\n\n\n Si planeas alojar varios sitios en una sola instancia de NGINX, los bloques de servidor<\/strong> son tus aliados. Cada bloque define c\u00f3mo se comporta un sitio o dominio en particular.<\/p>\n\n\n\n Un ejemplo b\u00e1sico de bloque de servidor:<\/p>\n\n\n\n Aqu\u00ed especificas el puerto ( \u00bfSSL? No hay problema. Solo usa Los bloques de servidor mantienen cada sitio bien contenido, lo que facilita la gesti\u00f3n de m\u00faltiples dominios en el mismo servidor f\u00edsico o virtual.<\/p>\n\n\n\n Dentro de un bloque de servidor, los bloques de ubicaci\u00f3n (location)<\/strong> especifican c\u00f3mo se tratan ciertas rutas o patrones de archivo. Podr\u00edas usarlos para servir im\u00e1genes, reenviar solicitudes PHP a un proceso FastCGI o incluso negar acceso a archivos ocultos. Por ejemplo:<\/p>\n\n\n\n El primer bloque pasa todo lo que est\u00e9 bajo NGINX usa un sistema de prioridad<\/strong> para los bloques de ubicaci\u00f3n:<\/p>\n\n\n\n Primero NGINX busca coincidencias exactas. Si no existen, recuerda la coincidencia de prefijo m\u00e1s larga y luego revisa las expresiones regulares. Si una expresi\u00f3n regular coincide, NGINX usa ese bloque de ubicaci\u00f3n; de lo contrario, usa el prefijo almacenado. Comprender este sistema de prioridad ayuda a evitar comportamientos inesperados en tu configuraci\u00f3n.<\/p>\n\n\n\n \u00bfNo est\u00e1s seguro de qu\u00e9 bloque de ubicaci\u00f3n est\u00e1 en efecto? Puedes comprobar la configuraci\u00f3n general ejecutando:<\/p>\n\n\n\n y luego buscar tu dominio y ruta. Tambi\u00e9n considera usar Perfecto, contin\u00fao con toda la segunda parte completa en un solo mensaje<\/strong>, sin omitir nada, respetando la estructura original, el formato de c\u00f3digo y manteniendo la traducci\u00f3n fiel al texto original.<\/p>\n\n\n\n A veces ver\u00e1s una directiva location<\/strong> en NGINX con root<\/strong> o alias<\/strong>. Esto le indica a NGINX d\u00f3nde encontrar los archivos reales. Por ejemplo:<\/p>\n\n\n\n Cuando alguien visita tu dominio, NGINX busca en alias<\/strong> es ligeramente diferente de root<\/strong>. Con alias<\/strong>, la ruta que especificas reemplaza toda la ruta solicitada. Con root<\/strong>, NGINX agrega el URI de la solicitud a la ruta del directorio. Ambos enfoques funcionan si planificas cuidadosamente. Solo aseg\u00farate de entender c\u00f3mo se alinean los archivos, para que las solicitudes se asignen correctamente al sistema de archivos subyacente.<\/p>\n\n\n\n Esta disposici\u00f3n sencilla te ayuda a evitar dolores de cabeza. Si ves errores 404 inesperados, revisa qu\u00e9 directiva usaste y confirma que tus rutas de archivo coinciden con la realidad. Consulta las FAQs<\/strong> para m\u00e1s informaci\u00f3n.<\/p>\n\n\n\n Por defecto, NGINX escucha en el puerto 80<\/strong> para HTTP y el puerto 443<\/strong> para HTTPS. Esto se define con la directiva listen<\/strong> de NGINX. Por ejemplo:<\/p>\n\n\n\n Tambi\u00e9n puedes habilitar m\u00e1s de un puerto listen<\/strong> en NGINX:<\/p>\n\n\n\n Si tienes m\u00faltiples interfaces de red, puedes especificar una IP:<\/p>\n\n\n\n Recuerda ajustar las reglas de tu firewall para que el tr\u00e1fico hacia estos puertos no sea bloqueado. As\u00ed, los visitantes podr\u00e1n acceder a tu contenido sin importar qu\u00e9 puerto usen.<\/p>\n\n\n\n La directiva server_name<\/strong> en NGINX le dice a un bloque de servidor qu\u00e9 dominio(s) o subdominios debe manejar:<\/p>\n\n\n\n Este bloque responder\u00e1 a las solicitudes para cualquiera de los dos dominios. Tambi\u00e9n se permiten comodines:<\/p>\n\n\n\n Esto coincide con cualquier subdominio. Incluso puedes usar expresiones regulares, aunque es menos com\u00fan. Por ejemplo:<\/p>\n\n\n\n Mant\u00e9n tu configuraci\u00f3n clara. Si tienes muchos subdominios, un comod\u00edn suele simplificar las cosas. Siempre confirma que la configuraci\u00f3n de DNS dirija el tr\u00e1fico a la IP de tu servidor.<\/p>\n\n\n\n\/etc\/nginx\/nginx.conf<\/code> en muchas distribuciones Linux. La ubicaci\u00f3n exacta puede variar seg\u00fan tu distribuci\u00f3n (Ubuntu, CentOS, Arch Linux, etc.) y el m\u00e9todo de instalaci\u00f3n. Las directivas se ven as\u00ed:<\/p>\n\n\n\nnombre_de_directiva valor;<\/code><\/pre>\n\n\n\nuser nginx;\nworker_processes auto;\npid \/run\/nginx.pid;<\/code><\/pre>\n\n\n\nhttp { ... }<\/code><\/pre>\n\n\n\n
\n\n\n\nBloque HTTP<\/h2>\n\n\n\n
nginx.conf<\/code> o en un archivo que se incluye con una instrucci\u00f3n include<\/strong>. Este bloque decide c\u00f3mo se maneja el tr\u00e1fico HTTP antes de que tus bloques de servidor o de ubicaci\u00f3n refinen los detalles.<\/p>\n\n\n\nhttp {\n include mime.types;\n default_type application\/octet-stream;\n\n sendfile on;\n keepalive_timeout 65;\n}<\/code><\/pre>\n\n\n\ninclude mime.types;<\/code> ayuda a NGINX a identificar los tipos de archivo (como .html y .css). La directiva sendfile on;<\/code> usa un mecanismo del sistema operativo para optimizar las transferencias de archivos. Si quieres habilitar gzip, tambi\u00e9n lo har\u00edas aqu\u00ed.<\/p>\n\n\n\n
\n\n\n\nBloques de Servidor<\/h2>\n\n\n\n
server {\n listen 80;\n server_name example.com www.example.com;\n\n root \/var\/www\/example;\n index index.html;\n\n location \/ {\n try_files $uri $uri\/ =404;\n }\n}<\/code><\/pre>\n\n\n\nlisten 80;<\/code>) y los nombres de dominio. Tambi\u00e9n decides d\u00f3nde viven los archivos de tu sitio. Esto a menudo se llama hosting virtual<\/strong>. Puedes colocar m\u00faltiples bloques de servidor en un archivo o dividirlos en archivos separados que NGINX incluye.<\/p>\n\n\n\nlisten 443 ssl;<\/code> con tu certificado y configuraci\u00f3n de clave dentro del mismo bloque. Tambi\u00e9n tendr\u00e1s location blocks<\/strong> para diferentes URLs, lo que te permite afinar la estructura de tu sitio. Por ejemplo, podr\u00edas reenviar solicitudes a una aplicaci\u00f3n backend en \/api\/<\/code> mientras sirves archivos est\u00e1ticos en \/<\/code>.<\/p>\n\n\n\n
\n\n\n\nBloques de Ubicaci\u00f3n<\/h2>\n\n\n\n
location \/images\/ {\n alias \/var\/data\/images\/;\n}\n\nlocation ~ \\.php$ {\n fastcgi_pass unix:\/run\/php\/php7.4-fpm.sock;\n include fastcgi_params;\n}<\/code><\/pre>\n\n\n\n\/images\/<\/code> a un directorio en \/var\/data\/images\/<\/code>. El segundo usa una expresi\u00f3n regular (~ \\.php$)<\/code> para coincidir con archivos .php y pasarlos a un socket PHP-FPM.<\/p>\n\n\n\n\n
=<\/code>):location = \/path<\/code><\/li>\n\n\n\n^~<\/code>):location ^~ \/path<\/code><\/li>\n\n\n\n~<\/code>,\u00a0~*<\/code>):location ~ \\.php$<\/code><\/li>\n\n\n\nlocation \/path<\/code><\/li>\n<\/ol>\n\n\n\nnginx -T<\/code><\/pre>\n\n\n\nnginx -t<\/code> para confirmar que la sintaxis es correcta antes de recargar.<\/p>\n\n\n\n
\n\n\n\n
\n\n\n\nUso de Location Root y Index<\/h2>\n\n\n\n
location \/ {\n root \/var\/www\/mywebsite;\n index index.html index.htm;\n}<\/code><\/pre>\n\n\n\n\/var\/www\/mywebsite<\/code> los archivos index.html<\/strong> o index.htm<\/strong>. Si ninguno existe, puedes configurar una p\u00e1gina de error personalizada o usar el error 404 predeterminado.<\/p>\n\n\n\n
\n\n\n\nPuertos de Escucha<\/h2>\n\n\n\n
server {\n listen 80;\n server_name mysite.org;\n ...\n}<\/code><\/pre>\n\n\n\nlisten 80;\nlisten 8080;<\/code><\/pre>\n\n\n\nlisten 192.168.1.10:80;<\/code><\/pre>\n\n\n\n
\n\n\n\nDirectiva server_name<\/h2>\n\n\n\n
server_name example.org www.example.org;<\/code><\/pre>\n\n\n\nserver_name *.example.net;<\/code><\/pre>\n\n\n\nserver_name ~^(?<subdom>.+)\\.example\\.com$;<\/code><\/pre>\n\n\n\n
\n\n\n\nProxy Inverso en NGINX<\/h2>\n\n\n\n