En las arquitecturas ADC y de proxy inverso tradicionales, cada nuevo dominio suele significar un nuevo listener, un nuevo servicio virtual, una nueva dirección IP o un conjunto complejo de reglas de enrutamiento. A pequeña escala esto es manejable, pero una vez que el número de dominios llega a docenas, los tenants alcanzan cientos o se requiere separación multi-entorno, la superficie operacional se desmorona rápidamente.
En el lado TLS el problema es más agudo. La cabecera Host HTTP no es visible hasta que se termina TLS, por lo que enrutar el tráfico TLS al servicio correcto requiere una decisión a nivel SNI — antes de que se complete la negociación. Sin una separación SNI adecuada, los dominios que comparten la misma IP se mezclan, se sirve el certificado equivocado o el tráfico llega al backend incorrecto.
La gestión de dominios wildcard añade una carga adicional. Patrones como `*.tenant.app` son comunes en escenarios SaaS y MSP, pero definir manualmente cada subdominio no es sostenible. El wildcard debe convertirse en la regex correcta, correctamente escapada y restringida para que no coincida con dominios no deseados.
La semántica HTTP/2 y TLS moderna hace que el manejo de dominios no coincidentes sea aún más sensible. Cuando SNI y la cabecera Host no coinciden, el cliente espera un comportamiento bien definido; si la plataforma no puede producirlo, las conexiones aterrizan en el pool incorrecto o los controles de seguridad se eluden.
TR7 ADC trata los hosts virtuales como una relación dominio + coincidencia + pool. Separa los dominios en la misma IP y puerto mediante SNI o cabecera Host, gestiona los dominios wildcard automáticamente y vincula cada dominio a su propia política de servicio.
TR7 elimina la duplicación manual de listeners de la gestión de hosts virtuales y gestiona el enrutamiento basado en dominios mediante un modelo de objetos, generación automática de coincidencias y un proceso de recarga sin tiempo de inactividad.
Para el tráfico TLS la decisión se toma sobre el valor SNI; para el tráfico HTTP se utiliza la cabecera Host. Tanto los escenarios de separación temprana TLS como los escenarios clásicos de proxy inverso HTTP se gestionan bajo el mismo modelo de host virtual.
Las entradas wildcard como `*.example.com` se convierten automáticamente en patrones de coincidencia seguros. Los operadores no escriben regex a mano. Una única definición wildcard enruta subdominios ilimitados al pool correcto.
Cada dominio que comparte una VIP puede apuntar a un pool diferente. Esto significa que un dominio puede llevar un perfil WAAP, otro mTLS, otro un perfil de caché o log personalizado. La separación de dominios no es solo enrutamiento — es separación de políticas.
TR7 genera la configuración de hosts virtuales en un orden ordenado y determinista. Dado que la misma entrada siempre produce la misma salida, se evitan recargas innecesarias. Una recarga suave se aplica solo cuando se detecta un cambio real, preservando las conexiones activas.
Los Hosts Virtuales proporcionan separación basada en dominios, gestión de wildcards, vinculación de certificados, aislamiento de tenants y actualizaciones sin tiempo de inactividad en la misma IP y puerto.
En el tráfico TLS el valor SNI presentado por el cliente se lee y el dominio coincidente se dirige al pool correcto. Esto permite la separación de dominios en la fase más temprana de la conexión TLS. Es el mecanismo central para ejecutar múltiples servicios TLS en un único puerto 443.
En modo HTTP TR7 utiliza el valor de la cabecera `Host` para la coincidencia de hosts virtuales. Se logra el comportamiento clásico de vhost para HTTP plano y para el tráfico HTTP tras la terminación TLS. Los diferentes dominios en la misma IP y puerto se reenvían a pools de servicio distintos.
Los nombres wildcard como `*.example.com` se convierten automáticamente en reglas de coincidencia. Los operadores no escriben una regla separada para cada subdominio. Esto es especialmente potente para dominios de tenants SaaS, subdominios de clientes y separación multi-entorno.
Cada dominio virtual se vincula a un ID de pool. `shop.example.com`, `api.example.com` y `admin.example.com` en la misma VIP pueden apuntar a backends diferentes. Cada pool gestiona su propia lista de backends, health checks, WAAP y reglas de tráfico de forma independiente.
Un host virtual no es solo una decisión de enrutamiento — las políticas de seguridad y operacionales también divergen a través del pool al que está vinculado cada dominio. Un dominio puede aplicar un perfil WAAP estricto mientras otro se acelera con un perfil de caché. El formato de log y los informes pueden configurarse por dominio y pool.
Cuando se utilizan múltiples certificados en la misma IP y puerto, TR7 ejecuta la cadena correcta de certificado y pool basándose en el valor SNI. Los certificados wildcard y los vhosts wildcard pueden usarse juntos, simplificando las operaciones TLS multi-dominio.
La capa de host virtual admite el reenvío de información de contexto de cliente y geográfico a las capas posteriores durante el enrutamiento de tráfico. Los pools de backend, el registro, las decisiones geográficas y las cadenas de políticas pueden por tanto continuar usando el contexto requerido después de la separación de dominios.
La capa de host virtual reenvía el tráfico al pool relevante a través de una conexión interna aislada. Esta arquitectura realiza la separación de dominios en un punto central mientras mantiene el espacio de trabajo de cada pool aislado. El tráfico de un portal, AAM u otro pool puede gestionarse con el mismo modelo.
En despliegues multi-tenant cada zona gestiona su propia lista de hosts virtuales. La lista de dominios de un tenant no se mezcla con los dominios de otro tenant. Los conflictos de dominio, los límites de permisos y la visibilidad se mantienen dentro de los límites del tenant.
Los grupos de hosts virtuales se mantienen en espacios de trabajo separados para altos recuentos de conexiones. El tráfico multi-dominio se gestiona de forma centralizada sin restringir la capacidad de conexiones. Los cambios operacionales en un grupo de dominios no afectan innecesariamente a otros grupos.
Cuando cambia un dominio, pool o certificado, TR7 detecta la diferencia de configuración. Solo el componente afectado se actualiza mediante recarga suave. Las conexiones existentes se drenan mientras el nuevo tráfico se acepta bajo la configuración actualizada.
Los valores de Host o SNI no definidos pueden dirigirse a un backend predeterminado, una respuesta de error o una política de seguridad. Esto proporciona un comportamiento controlado en escenarios de secuestro de subdominios y acceso a dominios inesperados.
La capacidad de Hosts Virtuales aborda no solo la coincidencia de dominios sino también la estrategia de recarga, la separación de tenants, la normalización de wildcards y la operación con altos recuentos de conexiones.
Los hosts virtuales que comparten la misma IP, puerto y tipo de operación se tratan como un grupo. Las asignaciones de dominios dentro del grupo se generan en un orden ordenado y determinista. Esta estructura evita diferencias de configuración espurias.
Los valores de dominio exactos se gestionan con coincidencia directa de cadena; los dominios wildcard se gestionan con coincidencia de patrón automática. Dado que los operadores no escriben regex manualmente, el riesgo de errores se reduce. Los caracteres de dominio se escapan de forma segura.
En modo TLS la decisión se toma sobre el valor SNI; en modo HTTP sobre la cabecera Host. Esta separación es automática. Los operadores no necesitan escribir una lógica de enrutamiento diferente para cada escenario.
TR7 compara la configuración actual con la configuración que debe generarse. Se toma una decisión de recarga o reinicio solo si existe una diferencia real. Si nada ha cambiado, no se toma ninguna acción.
Una recarga suave se aplica solo cuando la configuración del proxy en ejecución ha cambiado. Esto evita la interrupción innecesaria de las conexiones activas. Si se requiere un cambio más profundo en el espacio de trabajo, se realiza un reinicio controlado.
Cada zona ve su propia configuración de dominios y vhosts. La gestión de dominios está separada en despliegues multi-cliente o multi-departamento. Este enfoque mejora tanto la seguridad operacional como la simplicidad de gestión.
El enrutamiento de hosts virtuales solo es significativo cuando el pool relevante está activo y en buen estado. Los health checks del pool, el estado del backend, los certificados y el perfil WAAP determinan la cadena de decisión final para el tráfico del dominio.
En clientes modernos, una discrepancia entre SNI y la cabecera Host puede hacer que el tráfico llegue al backend incorrecto. TR7 hace que tales situaciones sean controlables a través de la cadena de host virtual y perfil de seguridad.
`tenant1.app.com`, `tenant2.app.com` y `tenant3.app.com` comparten la misma VIP. Una regla de dominio wildcard captura todos los subdominios de tenants bajo una única entrada; cada tenant se enruta a su propio pool y perfil WAAP.
`shop.example.com` va al pool de tienda pública; `admin.example.com` va a un pool de gestión con mTLS y una política de acceso más estricta. Se utiliza un único puerto 443 y las políticas de seguridad se separan a nivel de dominio.
`api.example.com` se enruta al pool de nueva API mientras `api-v2.example.com` va al pool legado. Durante la transición ambos servicios comparten la misma IP; la arquitectura de DNS y firewall permanece sin cambios.
La capa de host virtual separa el dominio; la capa de pool posterior aplica diferentes reglas de tráfico o perfiles de seguridad basándose en información geográfica. Una cadena de decisiones por dominio y ubicación opera de extremo a extremo.
Las solicitudes de subdominios no definidos o inesperados se colocan bajo un comportamiento de seguridad predeterminado. Incluso cuando se utiliza un certificado wildcard, los backends no controlados no pueden ser alcanzados por subdominios inesperados.
`portal.example.com` está abierto a los usuarios de internet mientras `partner-api.example.com` solo es accesible con mTLS y una allowlist de IP. Ambos servicios comparten la misma IP y puerto, cada uno bajo su propia capa de seguridad.
Separación por SNI y cabecera Host, soporte de dominios wildcard, WAAP por dominio y recarga sin tiempo de inactividad. Permítanos guiarle por una configuración en vivo en su propia infraestructura.