Cómo Alojar Múltiples Sitios Web con Bloques de Servidor Nginx (Hosts Virtuales)

Los bloques de servidor en Nginx son la forma de alojar múltiples dominios o sitios web en una sola instalación de Nginx, configurando cada uno de ellos de manera independiente. Por ejemplo, en un mismo VPS puedes definir diferentes carpetas raíz, archivos de registro, certificados SSL y configuraciones PHP para example.com, blog.example.com y segundo-sitio.com. En resumen, la solución consiste en crear una carpeta separada para cada sitio, apuntar los DNS del dominio a la IP del servidor, crear un bloque de servidor en /etc/nginx/sites-available para cada uno, enlazarlo en sites-enabled, probar la configuración y recargar Nginx.

En esta guía abordaremos cómo alojar varios sitios con bloques de servidor Nginx de forma adecuada para entornos de producción. El objetivo no es solo que funcione, sino lograr una estructura manejable, segura, rápida, fácil de respaldar y escalable. Compartiremos pasos prácticos dirigidos especialmente a agencias, desarrolladores, propietarios de tiendas online, empresas con múltiples marcas y administradores que gestionan varios proyectos en un solo servidor. Si aún no cuentas con un servidor, puedes consultar las opciones en servidor VPS y para la gestión de dominios, revisa Registro de Dominio.

¿Qué son los Bloques de Servidor en Nginx?

Los bloques de servidor en Nginx son fragmentos de configuración llamados “server” que determinan a qué sitio web se dirige una solicitud HTTP o HTTPS entrante. Son el equivalente a los VirtualHost de Apache. Cuando un visitante escribe un dominio en su navegador, el DNS traduce ese dominio a la IP del servidor. Luego, Nginx revisa el encabezado Host y ejecuta el bloque de servidor cuyo server_name coincida con el dominio solicitado.

Esto permite alojar decenas de sitios diferentes en la misma IP y en el mismo servidor físico o virtual. Cada sitio puede tener una carpeta raíz distinta, registros de acceso y error separados, reglas de redireccionamiento, certificados SSL, políticas de caché y reglas de seguridad independientes. Por ejemplo, tu sitio corporativo puede estar en /var/www/corporativo/public, tu blog en /var/www/blog/public y tu entorno de pruebas en /var/www/staging/public.

Nginx es muy eficiente en esta arquitectura gracias a su diseño basado en eventos, que maneja muchas conexiones simultáneas con bajo consumo de recursos. Por eso es popular en hosting compartido, VPS, servidores cloud y plataformas de alto tráfico. Para que la administración de múltiples sitios funcione correctamente, es crucial planificar bien desde los permisos de archivos, las configuraciones DNS, la instalación de SSL hasta la separación de logs.

¿Cuándo Usar Bloques de Servidor Nginx?

Los bloques de servidor Nginx son ideales cuando necesitas administrar varios sitios web en un mismo servidor. Esto puede ser desde dos sitios corporativos pequeños hasta decenas de proyectos de clientes, subdominios o microservicios. Lo importante es mantener una separación lógica clara entre cada proyecto.

• Si quieres alojar varios dominios en un solo VPS.
• Si quieres redirigir las versiones con y sin www a una única URL canónica.
• Si deseas vincular subdominios a carpetas o aplicaciones distintas.
• Si necesitas definir certificados SSL y políticas de seguridad diferentes por sitio.
• Si quieres monitorizar proyectos de clientes con archivos de registro separados.
• Si vas a ejecutar aplicaciones variadas como Laravel, WordPress, HTML estático o Node.js en el mismo servidor.

Por ejemplo, una agencia digital puede alojar 8 sitios corporativos con bajo tráfico en un VPS de 4 GB RAM. Pero es fundamental calcular el tráfico, uso de disco, número de procesos PHP, carga de base de datos y frecuencia de backups para cada sitio. Si el tráfico es alto o la separación de recursos es crítica, conviene optar por un VPS más potente, un servidor cloud o un hosting gestionado. En ese caso, compara opciones en Alojamiento Web y Hosting Corporativo.

Requisitos Previos

Asumiremos un servidor Linux basado en Ubuntu o Debian. Los comandos pueden variar ligeramente según la distribución, pero la lógica es la misma. Antes de hacer cambios en producción, haz siempre una copia de seguridad. Un error en la configuración de Nginx puede dejar inaccesibles todos los sitios temporalmente.

Preparación técnica necesaria

• Cuenta de usuario Linux con permisos root o sudo.
• Servicio Nginx instalado y funcionando.
• Al menos un dominio apuntando a la IP del servidor.
• Puertos 80 y 443 abiertos en el firewall.
• Estructura ordenada de carpetas para los sitios.
• Certificado SSL válido o uso de Let’s Encrypt gratuito.
• PHP-FPM instalado para aplicaciones PHP.

En DNS, el registro A dirige el dominio principal a la IP IPv4, y el AAAA a IPv6 si existe. Para subdominios como www, se usan registros CNAME o A. La propagación DNS tarda desde minutos hasta 24 horas. Es recomendable preparar los DNS antes de configurar los bloques en Nginx para agilizar el proceso.

Estructura de Carpetas Recomendada

Un error común al alojar múltiples sitios es mezclar todos los archivos en una sola carpeta. Aunque parece más sencillo a corto plazo, complica el mantenimiento, las copias de seguridad y la resolución de problemas. La mejor práctica es crear una carpeta principal para cada dominio y dentro de ella subcarpetas como public, logs y backups.

Por ejemplo, puedes organizar así: /var/www/sitio1.com/public, /var/www/sitio1.com/logs, /var/www/sitio2.com/public, /var/www/sitio2.com/logs. La directiva root de Nginx debe apuntar directamente a la carpeta public. Así, archivos sensibles como .env o backups no estarán accesibles desde la web.

Para verificar la configuración, coloca un simple index.html en cada carpeta con el nombre del sitio para confirmar qué bloque de servidor responde. En producción, la propiedad de las carpetas suele asignarse al usuario www-data o al usuario que despliega el código. Los permisos recomendados son 755 para carpetas y 644 para archivos en escenarios estáticos. Para aplicaciones como WordPress, las carpetas de uploads u otras que requieran escritura deben configurarse aparte.

Creación Paso a Paso de un Bloque de Servidor Nginx

A continuación describimos el proceso usando como ejemplo el dominio sitio1.com. Puedes repetir los mismos pasos para sitios adicionales. Lo clave es usar valores únicos en server_name, root y archivos de log para cada sitio.

1. Crear la carpeta del sitio

Primero, crea la carpeta donde residirán los archivos web. Por ejemplo: sudo mkdir -p /var/www/sitio1.com/public. Luego, crea un archivo simple de prueba en /var/www/sitio1.com/public/index.html con un texto identificativo como “Esta es la página de prueba de sitio1.com”.

Para ajustar la propiedad, ejecuta sudo chown -R www-data:www-data /var/www/sitio1.com. Si usas otro usuario para despliegues, ajusta los permisos del grupo. Evita permisos 777, ya que facilitan ataques al directorio de carga.

2. Crear el archivo del bloque de servidor

Lo habitual es guardar las configuraciones inactivas en /etc/nginx/sites-available y activar las deseadas enlazándolas simbólicamente en sites-enabled. Por ejemplo, crea /etc/nginx/sites-available/sitio1.com.

Un bloque básico para HTTP sería:

server {
    listen 80;
    server_name sitio1.com www.sitio1.com;
    root /var/www/sitio1.com/public;
    index index.html index.htm;
    access_log /var/log/nginx/sitio1.com.access.log;
    error_log /var/log/nginx/sitio1.com.error.log;
    location / {
        try_files $uri $uri/ =404;
    }
}

Esta configuración escucha tráfico HTTP en el puerto 80, define qué dominios corresponden al bloque, apunta la raíz web, indica los archivos índice y maneja errores 404 si no encuentra el recurso. Es suficiente para sitios estáticos.

3. Activar el sitio

Para activar el bloque, crea un enlace simbólico con:

sudo ln -s /etc/nginx/sites-available/sitio1.com /etc/nginx/sites-enabled/sitio1.com

Esto es mejor que copiar archivos porque mantiene todo centralizado y los cambios se reflejan automáticamente. Si no quieres que la página por defecto de Nginx interfiera, puedes desactivar el sitio default con:

sudo rm /etc/nginx/sites-enabled/default

Pero asegúrate de que tu bloque personalizado funciona bien antes de hacerlo.

4. Probar la configuración y recargar Nginx

Tras cada cambio, ejecuta:

sudo nginx -t

para verificar la sintaxis. Si pasa, recarga sin interrumpir el servicio con:

sudo systemctl reload nginx

El comando reload es más seguro que restart porque no corta las conexiones activas abruptamente.

Si nginx -t falla, revisa el mensaje que indica archivo y línea con error. Los problemas más comunes son punto y coma faltante, llaves mal cerradas, rutas incorrectas o server_name duplicados. No recargues hasta corregirlos.

Agregar un Segundo o Tercer Sitio

El beneficio de alojar múltiples sitios es que, una vez que haces la configuración inicial correctamente, se vuelve un proceso repetible. Para sitio2.com creas /var/www/sitio2.com/public, un archivo de configuración en /etc/nginx/sites-available/sitio2.com, ajustas root y logs, creas el enlace simbólico y pruebas la configuración.

El bloque básico sería:

server {
    listen 80;
    server_name sitio2.com www.sitio2.com;
    root /var/www/sitio2.com/public;
    index index.html;
    access_log /var/log/nginx/sitio2.com.access.log;
    error_log /var/log/nginx/sitio2.com.error.log;
    location / {
        try_files $uri $uri/ =404;
    }
}

Tener logs separados es muy valioso en la práctica. Por ejemplo, un sitio puede tener muchos errores 404 mientras otro no tiene problemas. Así puedes identificar rápidamente dónde está el fallo. También facilita el análisis de tráfico, ataques de bots, enlaces rotos y problemas de rendimiento por sitio.

Configuración SSL y HTTPS

Para 2026, HTTPS es un estándar no solo por seguridad, sino porque mejora la confianza del usuario y la calidad técnica ante motores de búsqueda. Los navegadores marcan HTTP como no seguro, y sitios con pagos, formularios o paneles requieren SSL obligatorio. Al alojar varios sitios, cada dominio debe tener su certificado. Consulta las opciones en Hostragons en certificados SSL.

Si usas Let’s Encrypt, Certbot puede obtener certificados para cada dominio con:

certbot --nginx -d sitio1.com -d www.sitio1.com

Certbot detecta la configuración de Nginx y añade el bloque HTTPS automáticamente. Sin embargo, es recomendable revisar el archivo tras la edición para evitar redirecciones erróneas o bloques duplicados.

Normalmente, todo el tráfico en el puerto 80 se redirige permanentemente al 443 vía 301, lo que es bueno para SEO. Decide si usarás www o no y unifica todas las variantes en la URL canónica. Por ejemplo, si eliges https://sitio1.com, redirige también https://www.sitio1.com hacia esa URL para evitar contenido duplicado.

Bloques de Servidor Nginx para PHP y WordPress

Los sitios estáticos son sencillos, pero para WordPress, Laravel o apps PHP es necesario integrar PHP-FPM. Se define index.php y las peticiones PHP se redirigen al socket adecuado. Por ejemplo, en Ubuntu con PHP 8.3 el socket puede ser /run/php/php8.3-fpm.sock, aunque depende de la versión instalada.

Ejemplo básico:

server {
    listen 80;
    server_name wordpress-sitio.com www.wordpress-sitio.com;
    root /var/www/wordpress-sitio.com/public;
    index index.php index.html;
    location / {
        try_files $uri $uri/ /index.php?$args;
    }
    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php8.3-fpm.sock;
    }
}

Para que los enlaces permanentes de WordPress funcionen, la directiva try_files con /index.php?$args es imprescindible. También se recomienda limitar acceso a xmlrpc.php, wp-login.php, y bloquear ejecución PHP en la carpeta uploads por seguridad. Si alojas múltiples WordPress en un VPS, usa base de datos y usuarios separados para cada uno y mantén una política de actualizaciones regular. Para un hosting optimizado para WordPress puedes consultar Alojamiento WordPress.

Comparativa entre Bloques de Servidor Nginx y VirtualHost de Apache

Nginx y Apache logran alojar múltiples sitios con arquitecturas diferentes. La elección depende de las necesidades, preferencias y rendimiento esperado.

Si dependes mucho de reglas .htaccess, Apache puede ser más sencillo. Pero para tráfico elevado, proxy inverso, caché y despliegues modernos, Nginx suele ser la mejor opción. En algunas infraestructuras se combinan: Nginx como proxy frontal y Apache para el backend.

Buenas Prácticas de Seguridad

Alojar varios sitios en un mismo servidor reduce costos pero aumenta la responsabilidad en seguridad. Para evitar que una vulnerabilidad impacte en otros sitios, aplica aislamiento y el principio de mínimos privilegios.

• Crea bases de datos y usuarios separados para cada sitio.
• Limita la raíz web solo a la carpeta public.
• No expongas backups, archivos .env, .git, configuraciones ni SQL al acceso web.
• Renueva certificados SSL con regularidad y obliga a usar HTTPS.
• Usa firewall (como UFW) y abre solo los puertos necesarios.
• Mantén Nginx y el sistema operativo actualizados.
• Registra logs de acceso y error separados por sitio.
• Restringe acceso a paneles de administración por IP o autenticación adicional.
• Evita permisos 777 en archivos y carpetas.

También es recomendable añadir cabeceras de seguridad como X-Frame-Options, X-Content-Type-Options, Referrer-Policy y Content-Security-Policy según el proyecto. Esta última puede bloquear scripts y estilos si no se configura bien, por lo que debe probarse primero en entornos de desarrollo. Para más detalles, consulta Seguridad de sitios web.

Aspectos a Considerar para Rendimiento y SEO

Los bloques de servidor no solo afectan la publicación, sino también la velocidad y posicionamiento SEO. Redireccionamientos incorrectos, URLs canónicas mal definidas, ausencia de compresión gzip o brotli, logs muy grandes y configuraciones de caché deficientes pueden ralentizar el sitio. Google prioriza una experiencia rápida, segura y estable.

Define una única versión canónica por dominio: HTTP a HTTPS, www a sin www o viceversa, con redirección 301 directa. Evita cadenas largas como http://sitio.com → http://www.sitio.com → https://www.sitio.com → https://sitio.com. Mejor un solo paso 301 directo al destino final.

Configura cache-control para archivos estáticos: imágenes, CSS y JS pueden almacenarse en navegador un tiempo. Para archivos que cambian seguido, usa versionado de nombre o query strings. La compresión gzip reduce el ancho de banda en archivos de texto (HTML, CSS, JS, JSON). En sitios con mucho tráfico evalúa usar microcache de Nginx, caché FastCGI o CDN. Para CDN y acceso global, revisa ¿Qué es CDN?.

Gestión y Monitoreo de Logs

En un entorno con múltiples sitios, la gestión de logs es clave para resolver problemas. Archivos separados indican claramente en qué sitio ocurrió cada error. access_log registra las solicitudes, error_log los problemas de configuración, permisos o recursos no encontrados. Por ejemplo, 502 Bad Gateway suele relacionarse con PHP-FPM o backend, 403 Forbidden con permisos o ausencia de archivo índice, y 404 Not Found con rutas erróneas o configuraciones DNS.

Controla el crecimiento de logs con logrotate. En proyectos pequeños, rotar diarios o semanales es suficiente. En sitios con mucho tráfico, considera sistemas centralizados de recolección de logs, monitoreo y alertas. El llenado del disco puede impedir que Nginx escriba logs o que la base de datos funcione, causando caídas. Por eso establece límites de uso de disco.

Errores Comunes y Soluciones Rápidas

Al trabajar con bloques de servidor Nginx, ciertos errores son frecuentes y reconocerlos acelera la solución.

• Se abre el sitio incorrecto: revisa conflictos en server_name y el bloque server por defecto.
• Error 403 Forbidden: verifica la carpeta root, permisos y existencia del archivo índice.
• Error 404 Not Found: revisa la ruta root y la directiva try_files.
• Error 502 Bad Gateway: confirma que PHP-FPM esté activo y el socket correcto.
• Certificado SSL asignado al sitio equivocado: comprueba server_name y rutas de certificados en el bloque 443.
• Bucle de redirección: simplifica reglas de HTTP-HTTPS y redirección www.
• No se recarga Nginx: corrige errores de sintaxis que indica nginx -t.

Una lista de chequeo útil para administradores es: ¿DNS apunta bien? ¿Configuración Nginx está activa? ¿Existe la carpeta root? ¿Permisos correctos? ¿Prueba de configuración exitosa? ¿Qué dicen los logs? Seguir este orden ayuda a resolver sin entrar en pánico.

Lista de Verificación para Producción

Antes de lanzar un sitio en vivo, valida lo siguiente para cada dominio. En proyectos con clientes, documentar esto demuestra profesionalismo:

• Los registros A o AAAA apuntan a la IP correcta.
• Se eligió una versión canónica entre www y sin www.
• El tráfico HTTP redirige a HTTPS con código 301.
• El certificado SSL está vigente y la renovación automática está activa.
• Cada sitio tiene su root y archivos de log separados.
• La configuración pasó la prueba con sudo nginx -t.
• Existe un plan de backups y pruebas de restauración.
• Los permisos cumplen con el principio de mínimo privilegio.
• El firewall solo permite los puertos necesarios.
• Se monitorean logs de error al menos 15 minutos tras el lanzamiento.

Aunque parezca sencillo, esta lista reduce mucho riesgos de caídas. En especial, la renovación SSL, comprobación DNS y supervisión de logs detectan errores invisibles a simple vista.

Conclusión

Los bloques de servidor Nginx son una herramienta fundamental para alojar múltiples sitios en un solo servidor de forma ordenada, segura y eficiente. Con una estructura adecuada de carpetas, archivos de configuración separados, reglas claras de redireccionamiento, uso de HTTPS, separación de logs y pruebas constantes, la gestión de múltiples sitios se vuelve muy ágil. Estos principios aplican desde un pequeño portafolio hasta grandes proyectos con varios clientes.

Si vas a lanzar un nuevo proyecto, define claramente el dominio, recursos del servidor y necesidades SSL antes de comenzar. Luego sigue la lista de verificación y configura Nginx paso a paso. Si buscas una infraestructura más manejable, revisa las opciones de Paquetes de Hosting, servidor VPS y certificados SSL de Hostragons para elegir el punto de partida ideal para tu proyecto.

Preguntas Frecuentes

¿Cuántos sitios se pueden alojar con bloques de servidor Nginx?

Técnicamente, Nginx puede alojar una gran cantidad de sitios en un solo servidor; el límite depende del CPU, RAM, disco, tráfico, carga de base de datos y capacidad de PHP-FPM. En sitios estáticos con poco tráfico se pueden tener decenas, pero en proyectos intensivos como WordPress o e-commerce, es mejor limitar el número para evitar problemas.

¿Se necesita un certificado SSL distinto para cada sitio?

Sí, cada dominio o subdominio que se publique vía HTTPS debe tener su certificado. Puedes usar certificados individuales o certificados SAN y wildcard. Lo importante es que en el bloque 443 de Nginx se asignen los archivos de certificado correctos para cada dominio.

¿Se pueden publicar subdominios con bloques de servidor?

Claro, puedes definir server_name para subdominios como blog.sitio.com o panel.sitio.com y apuntarlos a carpetas o aplicaciones diferentes. Solo asegúrate de crear en DNS el registro A o CNAME correspondiente para el subdominio.

¿Cuál es la diferencia entre sites-available y sites-enabled?

sites-available contiene las configuraciones disponibles pero no activas; sites-enabled incluye las configuraciones activas mediante enlaces simbólicos. Esta separación facilita activar o desactivar sitios sin eliminar archivos.

¿Por qué se abre el sitio incorrecto?

Las causas más comunes son DNS apuntando a la IP equivocada, server_name mal configurado, que el bloque por defecto de Nginx capture la petición o que el bloque SSL 443 sea incorrecto. Revisa primero los registros DNS, luego ejecuta nginx -t, verifica los enlaces en sites-enabled y analiza los logs de acceso para diagnosticar.