Em arquiteturas tradicionais de ADC e proxy reverso, cada novo domínio geralmente significa um novo listener, um novo serviço virtual, um novo endereço IP ou um conjunto complexo de regras de roteamento. Em pequena escala isso é gerenciável, mas assim que o número de domínios atinge dezenas, os tenants chegam às centenas ou é necessária separação de múltiplos ambientes, a superfície operacional se desintegra rapidamente.
No lado do TLS o problema é mais agudo. O Host header HTTP é invisível até que o TLS seja terminado, portanto rotear tráfego TLS para o serviço correto requer uma decisão no nível SNI — antes que o handshake seja concluído. Sem separação adequada de SNI, domínios que compartilham o mesmo IP se cruzam, o certificado errado é servido ou o tráfego chega no backend errado.
O gerenciamento de domínio wildcard adiciona um ônus adicional. Padrões como `*.tenant.app` são comuns em cenários SaaS e MSP, mas definir manualmente cada subdomínio não é sustentável. O wildcard deve ser convertido no regex correto, adequadamente escapado e restringido para não corresponder a domínios não intencionais.
HTTP/2 e semântica TLS modernas tornam o tratamento de domínios incompatíveis ainda mais sensível. Quando SNI e o Host header divergem, o cliente espera um comportamento bem definido; se a plataforma não consegue produzi-lo, as conexões ou chegam no pool errado ou os controles de segurança são contornados.
O TR7 ADC trata virtual hosts como um relacionamento domínio + matcher + pool. Ele separa domínios no mesmo IP e porta via SNI ou Host header, lida com domínios wildcard automaticamente e vincula cada domínio à sua própria política de serviço.
O TR7 remove a duplicação manual de listeners do gerenciamento de virtual hosts e lida com o roteamento baseado em domínio por meio de um modelo de objeto, geração automática de matcher e um processo de reload sem downtime.
Para tráfego TLS a decisão é feita no valor SNI; para tráfego HTTP o Host header é usado. Tanto cenários de separação precoce TLS quanto cenários clássicos de proxy reverso HTTP são tratados no mesmo modelo de virtual host.
Entradas wildcard como `*.example.com` são automaticamente convertidas em padrões de correspondência seguros. Os operadores não escrevem regex manualmente. Uma única definição wildcard roteia subdomínios ilimitados para o pool correto.
Cada domínio que compartilha um VIP pode ter como destino um pool diferente. Isso significa que um domínio pode carregar um perfil WAAP, outro mTLS, outro um cache ou perfil de log personalizado. A separação de domínio não é apenas roteamento — é separação de política.
O TR7 gera a configuração de virtual host em uma ordem classificada e determinística. Como a mesma entrada sempre produz a mesma saída, reloads desnecessários são evitados. Um soft reload é aplicado apenas quando uma mudança real é detectada, preservando as conexões ativas.
O Virtual Hosts fornece separação baseada em domínio, gerenciamento de wildcard, vinculação de certificados, isolamento de tenant e atualizações sem downtime no mesmo IP e porta.
No tráfego TLS o valor SNI apresentado pelo cliente é lido e o domínio correspondente é direcionado para o pool correto. Isso permite a separação de domínio no estágio mais precoce da conexão TLS. É o mecanismo central para executar múltiplos serviços TLS em uma única porta 443.
No modo HTTP o TR7 usa o valor do header `Host` para a correspondência de virtual host. O comportamento clássico de vhost é alcançado para HTTP simples e para tráfego HTTP após a terminação TLS. Domínios diferentes no mesmo IP e porta são encaminhados para pools de serviço distintos.
Nomes wildcard como `*.example.com` são automaticamente convertidos em regras de correspondência. Os operadores não escrevem uma regra separada para cada subdomínio. Isso é especialmente poderoso para domínios de tenant SaaS, subdomínios de clientes e separação de múltiplos ambientes.
Cada domínio virtual é vinculado a um ID de pool. `shop.example.com`, `api.example.com` e `admin.example.com` no mesmo VIP podem ter como destino backends diferentes. Cada pool gerencia sua própria lista de backends, verificações de saúde, WAAP e regras de tráfego de forma independente.
Um virtual host não é apenas uma decisão de roteamento — as políticas de segurança e operacionais também divergem por meio do pool ao qual cada domínio está vinculado. Um domínio pode aplicar um perfil WAAP rigoroso enquanto outro é acelerado com um perfil de cache. O formato de log e os relatórios podem ser configurados por domínio e pool.
Quando múltiplos certificados estão em uso no mesmo IP e porta, o TR7 executa a cadeia correta de certificado e pool com base no valor SNI. Certificados wildcard e vhosts wildcard podem ser usados juntos, simplificando as operações TLS multi-domínio.
A camada de virtual host suporta o encaminhamento de informações de contexto geográfico e do cliente para as camadas downstream durante o roteamento de tráfego. Pools de backend, logging, decisões baseadas em geo e cadeias de política podem, portanto, continuar usando o contexto necessário após a separação de domínio.
A camada de virtual host encaminha o tráfego para o pool relevante por meio de uma conexão interna isolada. Essa arquitetura realiza a separação de domínio em um ponto central enquanto mantém o espaço de trabalho de cada pool isolado. O tráfego de um portal, AAM ou outro pool pode ser tratado com o mesmo modelo.
Em implantações multi-tenant, cada zona gerencia sua própria lista de virtual hosts. A lista de domínios de um tenant não se mistura com os domínios de outro tenant. Conflitos de domínio, limites de permissão e visibilidade são mantidos dentro dos limites do tenant.
Os grupos de virtual hosts são mantidos em espaços de trabalho separados para altos números de conexão. O tráfego multi-domínio é gerenciado centralmente sem restringir a capacidade de conexão. Mudanças operacionais em um grupo de domínio não afetam desnecessariamente outros grupos.
Quando um domínio, pool ou certificado muda, o TR7 detecta a diferença de configuração. Apenas o componente afetado é atualizado via soft reload. As conexões existentes são drenadas enquanto o novo tráfego é aceito sob a configuração atualizada.
Valores de Host ou SNI indefinidos podem ser direcionados para um backend padrão, uma resposta de erro ou uma política de segurança. Isso fornece comportamento controlado em cenários de hijacking de subdomínio e acesso a domínio inesperado.
A capacidade de Virtual Hosts aborda não apenas a correspondência de domínio, mas também estratégia de reload, separação de tenant, normalização de wildcard e operação de alto número de conexão juntos.
Virtual hosts que compartilham o mesmo IP, porta e tipo operacional são tratados como um grupo. Os mapeamentos de domínio dentro do grupo são gerados em uma ordem classificada e determinística. Essa estrutura evita diffs de configuração espúrios.
Valores de domínio exatos são tratados com correspondência direta de string; domínios wildcard são tratados com correspondência automática de padrão. Como os operadores não escrevem regex manualmente, o risco de erros é reduzido. Os caracteres de domínio são escapados com segurança.
No modo TLS a decisão é feita no valor SNI; no modo HTTP no Host header. Essa separação é automática. Os operadores não precisam escrever lógica de roteamento diferente para cada cenário.
O TR7 compara a configuração atual com a configuração que deve ser gerada. Uma decisão de reload ou restart é tomada apenas se existir uma diferença real. Se nada mudou, nenhuma ação é tomada.
Um soft reload é aplicado apenas quando a configuração do proxy em execução mudou. Isso evita a interrupção desnecessária de conexões ativas. Se uma mudança mais profunda no espaço de trabalho for necessária, um restart controlado é realizado.
Cada zona vê sua própria configuração de domínio e vhost. O gerenciamento de domínio é separado em implantações multi-cliente ou multi-departamento. Essa abordagem melhora tanto a segurança operacional quanto a simplicidade de gerenciamento.
O roteamento de virtual host só é significativo quando o pool relevante está ativo e saudável. As verificações de saúde do pool, o status do backend, os certificados e o perfil WAAP determinam a cadeia de decisão final para o tráfego de domínio.
Em clientes modernos, uma incompatibilidade entre SNI e o Host header pode fazer com que o tráfego chegue ao backend errado. O TR7 torna tais situações controláveis por meio da cadeia de virtual host e perfil de segurança.
`tenant1.app.com`, `tenant2.app.com` e `tenant3.app.com` compartilham o mesmo VIP. Uma regra de domínio wildcard captura todos os subdomínios de tenant em uma única entrada; cada tenant é roteado para seu próprio pool e perfil WAAP.
`shop.example.com` vai para o pool da loja pública; `admin.example.com` vai para um pool de gerenciamento com mTLS e política de acesso mais rigorosa. Uma única porta 443 é usada e as políticas de segurança são separadas no nível de domínio.
`api.example.com` é roteado para o novo pool de API enquanto `api-v2.example.com` vai para o pool legado. Durante a transição, ambos os serviços compartilham o mesmo IP; a arquitetura de DNS e firewall permanece inalterada.
A camada de virtual host separa o domínio; a camada de pool downstream aplica regras de tráfego ou perfis de segurança diferentes com base em informações geográficas. Uma cadeia de decisão de domínio e localização opera de ponta a ponta.
Requisições de subdomínio indefinidas ou inesperadas são colocadas sob um comportamento de segurança padrão. Mesmo quando um certificado wildcard está em uso, backends não controlados não podem ser alcançados por subdomínios inesperados.
`portal.example.com` está aberto a usuários da internet enquanto `partner-api.example.com` é acessível apenas com mTLS e uma lista de permissões de IP. Ambos os serviços compartilham o mesmo IP e porta, cada um sob sua própria camada de segurança.
Separação SNI e Host header, suporte a domínio wildcard, WAAP por domínio e reload sem downtime. Deixe-nos guiá-lo por uma configuração ao vivo na sua própria infraestrutura.