Un servidor, muchos dominios: cómo se reparte el tráfico
Publicado el 2026-09-12 por frfrand
Cómo un solo servidor con una sola dirección atiende diez sitios distintos, qué es SNI, por qué el primer bloque de nginx es especial y cómo evitar que un dominio sirva el sitio de otro.
Tenés un servidor con una sola dirección pública. Querés alojar diez sitios distintos, cada uno con su dominio y su certificado. ¿Cómo sabe el servidor cuál servir?
La respuesta es que el navegador lo dice. Antes de pedir nada, anuncia a qué nombre viene.
En HTTP es fácil
Cuando el navegador abre la conexión, manda una cabecera:
GET /precios HTTP/1.1 Host: tienda.ejemplo.com
nginx lee ese Host, lo compara con los server_name de sus bloques y elige el que corresponde. Cada sitio es un bloque server en su propio archivo, todos escuchando en el mismo puerto.
En HTTPS hay un problema de orden
Con HTTPS aparece un huevo y gallina: el certificado hay que presentarlo al principio del handshake, antes de que exista una petición HTTP donde leer el Host. ¿Qué certificado presenta el servidor si todavía no sabe qué sitio le están pidiendo?
La solución se llama SNI (Server Name Indication): el cliente incluye el nombre del dominio en el primer mensaje del handshake, en claro. El servidor lee ese nombre, elige el certificado correcto y sigue.
Es por eso que hoy un servidor puede tener veinte certificados y presentar el que corresponde. Antes de SNI hacía falta una dirección por certificado, que es parte de por qué el hosting compartido con HTTPS era caro.
Un detalle que sorprende: como el SNI viaja sin cifrar, la red puede ver a qué dominio te conectás aunque no vea el contenido.
El bloque por defecto, que es donde se rompe
Esta es la parte que causa los problemas más desconcertantes.
Si llega una petición con un nombre que no coincide con ningún server_name, nginx no devuelve un error: la entrega al primer bloque que escuche en ese puerto. Y "el primero" depende del orden alfabético de los archivos, que nadie eligió a propósito.
Síntomas típicos:
- Un dominio nuevo, al que todavía no le configuraste el bloque, muestra el sitio de otro cliente.
- Los escáneres que entran por la dirección pública ven una web real en vez de nada.
La solución son cinco líneas:
server { listen 443 ssl default_server; server_name _; ssl_reject_handshake on; return 444; }
444 es un código propio de nginx que significa "cerrá la conexión sin responder". Quien no pidió un dominio conocido, no recibe nada. Y como efecto secundario, un dominio mal configurado deja de fallar en silencio: falla de forma obvia, que es mucho mejor.
Un error que cuesta caro
El orden de los bloques importa, pero el orden de las coincidencias también. nginx prefiere la coincidencia exacta sobre el comodín. Si tenés:
server_name *.ejemplo.com; server_name app.ejemplo.com;
una petición a app.ejemplo.com va al segundo, aunque el primero esté antes en el archivo. Eso es lo que querés casi siempre, pero conviene saberlo porque explica por qué a veces "el orden no importa" y a veces sí.
Cómo se resuelve en ArduMaker
Cada dominio que agregás genera su propio bloque y su propio certificado, sin que tengas que tocar archivos ni acordarte del default_server. Y si necesitás una configuración particular, se puede editar desde el panel, con validación antes de aplicar.
La ventaja de que sea automático no es ahorrarse el trabajo de escribir veinte líneas: es que el sitio número diez queda igual de bien configurado que el primero, seis meses después y con otra persona haciéndolo.
