In traditional ADC and reverse-proxy architectures, every new domain usually means a new listener, a new virtual service, a new IP address or a complex set of routing rules. At small scale this is manageable, but once the domain count reaches dozens, tenants reach hundreds or multi-environment separation is required, the operational surface falls apart quickly.
On the TLS side the problem is sharper. The HTTP Host header is invisible until TLS is terminated, so routing TLS traffic to the correct service requires a decision at the SNI level — before the handshake completes. Without proper SNI separation, domains sharing the same IP cross paths, the wrong certificate is served or traffic lands on the wrong backend.
Wildcard domain management adds a further burden. Patterns like `*.tenant.app` are common in SaaS and MSP scenarios, yet manually defining every subdomain is not sustainable. The wildcard must be converted into the correct regex, properly escaped and constrained so it does not match unintended domains.
HTTP/2 and modern TLS semantics make mismatched domain handling even more sensitive. When SNI and the Host header disagree, the client expects well-defined behavior; if the platform cannot produce it, connections either land on the wrong pool or security controls are bypassed.
TR7 ADC treats virtual hosts as a domain + matcher + pool relationship. It separates domains on the same IP and port via SNI or Host header, handles wildcard domains automatically and binds each domain to its own service policy.
TR7 removes manual listener duplication from virtual host management and handles domain-based routing through an object model, automatic matcher generation and a zero-downtime reload process.
For TLS traffic the decision is made on the SNI value; for HTTP traffic the Host header is used. Both TLS early-separation scenarios and classic HTTP reverse-proxy scenarios are handled under the same virtual host model.
Wildcard entries such as `*.example.com` are automatically converted to safe matching patterns. Operators do not write regex by hand. A single wildcard definition routes unlimited subdomains to the correct pool.
Every domain sharing a VIP can target a different pool. This means one domain can carry a WAAP profile, another mTLS, another a cache or custom log profile. Domain separation is not just routing — it is policy separation.
TR7 generates virtual host configuration in a sorted, deterministic order. Because the same input always yields the same output, unnecessary reloads are avoided. A soft reload is applied only when a real change is detected, preserving live connections.
Virtual Hosts provides domain-based separation, wildcard management, certificate binding, tenant isolation and zero-downtime updates on the same IP and port.
In TLS traffic the SNI value presented by the client is read and the matching domain is directed to the correct pool. This allows domain separation at the earliest stage of the TLS connection. It is the core mechanism for running multiple TLS services on a single port 443.
In HTTP mode TR7 uses the `Host` header value for virtual host matching. Classic vhost behavior is achieved for plain HTTP and for HTTP traffic after TLS termination. Different domains on the same IP and port are forwarded to distinct service pools.
Wildcard names such as `*.example.com` are automatically converted into matching rules. Operators do not write a separate rule for every subdomain. This is especially powerful for SaaS tenant domains, customer subdomains and multi-environment separation.
Each virtual domain is bound to a pool ID. `shop.example.com`, `api.example.com` and `admin.example.com` on the same VIP can target different backends. Each pool manages its own backend list, health checks, WAAP and traffic rules independently.
A virtual host is not just a routing decision — security and operational policies also diverge through the pool each domain is bound to. One domain can enforce a strict WAAP profile while another is accelerated with a cache profile. Log format and reporting can be configured per domain and pool.
When multiple certificates are in use on the same IP and port, TR7 runs the correct certificate-and-pool chain based on the SNI value. Wildcard certificates and wildcard vhosts can be used together, simplifying multi-domain TLS operations.
The virtual host layer supports forwarding client and geographic context information to downstream layers during traffic routing. Backend pools, logging, geo-based decisions and policy chains can therefore continue to use the required context after domain separation.
The virtual host layer forwards traffic to the relevant pool over an isolated internal connection. This architecture performs domain separation at a central point while keeping each pool's workspace isolated. Traffic from a portal, AAM or another pool can be handled with the same model.
In multi-tenant deployments each zone manages its own virtual host list. One tenant's domain list does not mix with another tenant's domains. Domain conflicts, permission boundaries and visibility are kept within tenant boundaries.
Virtual host groups are kept in separate workspaces for high connection counts. Multi-domain traffic is managed centrally without constraining connection capacity. Operational changes in one domain group do not unnecessarily affect other groups.
When a domain, pool or certificate changes, TR7 detects the configuration difference. Only the affected component is refreshed via soft reload. Existing connections are drained while new traffic is accepted under the updated configuration.
Undefined Host or SNI values can be directed to a default backend, an error response or a security policy. This provides controlled behavior in subdomain hijacking and unexpected domain access scenarios.
The Virtual Hosts capability addresses not only domain matching but also reload strategy, tenant separation, wildcard normalization and high-connection operation together.
Virtual hosts sharing the same IP, port and operating type are treated as a group. Domain mappings inside the group are generated in a sorted, deterministic order. This structure prevents spurious configuration diffs.
Exact domain values are handled with direct string matching; wildcard domains are handled with automatic pattern matching. Because operators do not write regex manually, the risk of errors is reduced. Domain characters are safely escaped.
In TLS mode the decision is made on the SNI value; in HTTP mode on the Host header. This separation is automatic. Operators do not need to write different routing logic for each scenario.
TR7 compares the current configuration with the configuration that should be generated. A reload or restart decision is made only if a real difference exists. If nothing has changed, no action is taken.
A soft reload is applied only when the running proxy configuration has changed. This prevents unnecessary interruption of active connections. If a deeper workspace change is required, a controlled restart is performed.
Each zone sees its own domain and vhost configuration. Domain management is separated in multi-customer or multi-department deployments. This approach improves both operational security and management simplicity.
Virtual host routing is meaningful only when the relevant pool is active and healthy. Pool health checks, backend status, certificates and the WAAP profile determine the final decision chain for domain traffic.
In modern clients, a mismatch between SNI and the Host header can cause traffic to reach the wrong backend. TR7 makes such situations controllable through the virtual host and security profile chain.
`tenant1.app.com`, `tenant2.app.com` and `tenant3.app.com` all share the same VIP. A wildcard domain rule captures all tenant subdomains under a single entry; each tenant is routed to its own pool and WAAP profile.
`shop.example.com` goes to the public store pool; `admin.example.com` goes to a management pool with mTLS and stricter access policy. A single port 443 is used and security policies are separated at the domain level.
`api.example.com` is routed to the new API pool while `api-v2.example.com` goes to the legacy pool. During the transition both services share the same IP; DNS and firewall architecture remain unchanged.
The virtual host layer separates the domain; the downstream pool layer applies different traffic rules or security profiles based on geographic information. A domain-and-location decision chain operates end-to-end.
Undefined or unexpected subdomain requests are placed under a default security behavior. Even when a wildcard certificate is in use, uncontrolled backends cannot be reached by unexpected subdomains.
`portal.example.com` is open to internet users while `partner-api.example.com` is accessible only with mTLS and an IP allowlist. Both services share the same IP and port, each under its own security layer.
SNI and Host header separation, wildcard domain support, per-domain WAAP and zero-downtime reload. Let us walk you through a live setup on your own infrastructure.