In klassischen ADC- und Reverse-Proxy-Architekturen bedeutet jede neue Domain in der Regel einen neuen Listener, einen neuen virtuellen Dienst, eine neue IP-Adresse oder einen komplexen Satz von Routing-Regeln. Bei kleiner Skalierung ist das handhabbar, aber sobald die Domain-Anzahl Dutzende, Tenants Hunderte erreicht oder eine Multi-Umgebungs-Trennung erforderlich ist, bricht die operative Oberfläche schnell zusammen.
Auf der TLS-Seite ist das Problem schärfer. Der HTTP-Host-Header ist unsichtbar, bis TLS terminiert ist, daher erfordert das Routing von TLS-Traffic zum richtigen Dienst eine Entscheidung auf SNI-Ebene — bevor der Handshake abgeschlossen ist. Ohne ordnungsgemäße SNI-Trennung kreuzen sich Domains, die dieselbe IP teilen, das falsche Zertifikat wird bereitgestellt oder Traffic landet im falschen Backend.
Wildcard-Domain-Management fügt eine weitere Last hinzu. Muster wie `*.tenant.app` sind in SaaS- und MSP-Szenarien üblich, doch jede Subdomain manuell zu definieren ist nicht nachhaltig. Das Wildcard muss in die korrekte Regex konvertiert, ordnungsgemäß escaped und eingeschränkt werden, sodass es keine unbeabsichtigten Domains matched.
HTTP/2 und moderne TLS-Semantik machen fehlangepasstes Domain-Handling noch sensitiver. Wenn SNI und Host-Header nicht übereinstimmen, erwartet der Client ein wohldefiniertes Verhalten; wenn die Plattform es nicht liefern kann, landen Verbindungen entweder im falschen Pool oder Sicherheitskontrollen werden umgangen.
TR7 ADC behandelt Virtual Hosts als Domain-+-Matcher-+-Pool-Beziehung. Es trennt Domains auf derselben IP und demselben Port via SNI oder Host-Header, behandelt Wildcard-Domains automatisch und bindet jede Domain an ihre eigene Dienstrichtlinie.
TR7 entfernt die manuelle Listener-Duplizierung aus dem Virtual-Host-Management und behandelt domainbasiertes Routing durch ein Objektmodell, automatische Matcher-Generierung und einen Zero-Downtime-Reload-Prozess.
Für TLS-Traffic wird die Entscheidung anhand des SNI-Werts getroffen; für HTTP-Traffic wird der Host-Header verwendet. Sowohl TLS-Early-Separation-Szenarien als auch klassische HTTP-Reverse-Proxy-Szenarien werden unter demselben Virtual-Host-Modell behandelt.
Wildcard-Einträge wie `*.example.com` werden automatisch in sichere Matching-Muster konvertiert. Operatoren schreiben keine Regex von Hand. Eine einzige Wildcard-Definition routet unbegrenzte Subdomains zum richtigen Pool.
Jede Domain, die eine VIP teilt, kann auf einen anderen Pool abzielen. Das bedeutet, dass eine Domain ein WAAP-Profil tragen kann, eine andere mTLS, wieder eine andere ein Cache- oder benutzerdefiniertes Log-Profil. Domain-Trennung ist nicht nur Routing — es ist Richtlinientrennung.
TR7 generiert Virtual-Host-Konfiguration in sortierter, deterministischer Reihenfolge. Da dieselbe Eingabe immer dieselbe Ausgabe ergibt, werden unnötige Reloads vermieden. Ein Soft-Reload wird nur dann angewendet, wenn eine echte Änderung erkannt wird, und bewahrt Live-Verbindungen.
Virtual Hosts bietet domainbasierte Trennung, Wildcard-Management, Zertifikatsbindung, Tenant-Isolation und Zero-Downtime-Updates auf derselben IP und demselben Port.
Im TLS-Traffic wird der vom Client präsentierte SNI-Wert gelesen und die passende Domain zum richtigen Pool geleitet. Dies ermöglicht die Domain-Trennung in der frühesten Phase der TLS-Verbindung. Es ist der Kernmechanismus für den Betrieb mehrerer TLS-Dienste auf einem einzigen Port 443.
Im HTTP-Modus verwendet TR7 den `Host`-Header-Wert für Virtual-Host-Matching. Klassisches vhost-Verhalten wird für reines HTTP und für HTTP-Traffic nach TLS-Terminierung erreicht. Verschiedene Domains auf derselben IP und demselben Port werden zu verschiedenen Service-Pools weitergeleitet.
Wildcard-Namen wie `*.example.com` werden automatisch in Matching-Regeln konvertiert. Operatoren schreiben keine separate Regel für jede Subdomain. Dies ist besonders mächtig für SaaS-Tenant-Domains, Kunden-Subdomains und Multi-Umgebungs-Trennung.
Jede virtuelle Domain ist an eine Pool-ID gebunden. `shop.example.com`, `api.example.com` und `admin.example.com` auf derselben VIP können verschiedene Backends anvisieren. Jeder Pool verwaltet seine eigene Backend-Liste, Health-Checks, WAAP und Traffic-Regeln unabhängig.
Ein Virtual Host ist nicht nur eine Routing-Entscheidung — Sicherheits- und Betriebsrichtlinien divergieren auch durch den Pool, an den jede Domain gebunden ist. Eine Domain kann ein striktes WAAP-Profil durchsetzen, während eine andere mit einem Cache-Profil beschleunigt wird. Log-Format und Berichterstellung können pro Domain und Pool konfiguriert werden.
Wenn mehrere Zertifikate auf derselben IP und demselben Port im Einsatz sind, führt TR7 die korrekte Zertifikats-und-Pool-Kette basierend auf dem SNI-Wert aus. Wildcard-Zertifikate und Wildcard-vhosts können zusammen verwendet werden, was Multi-Domain-TLS-Operationen vereinfacht.
Die Virtual-Host-Schicht unterstützt die Weiterleitung von Client- und geografischen Kontextinformationen an nachgelagerte Schichten während des Traffic-Routings. Backend-Pools, Logging, geographische Entscheidungen und Richtlinienketten können daher nach der Domain-Trennung weiterhin den erforderlichen Kontext nutzen.
Die Virtual-Host-Schicht leitet Traffic über eine isolierte interne Verbindung an den relevanten Pool weiter. Diese Architektur führt die Domain-Trennung an einem zentralen Punkt durch, während der Arbeitsbereich jedes Pools isoliert bleibt. Traffic von einem Portal, AAM oder einem anderen Pool kann mit demselben Modell behandelt werden.
In Multi-Tenant-Bereitstellungen verwaltet jede Zone ihre eigene Virtual-Host-Liste. Die Domain-Liste eines Tenants vermischt sich nicht mit den Domains eines anderen Tenants. Domain-Konflikte, Berechtigungsgrenzen und Sichtbarkeit werden innerhalb der Tenant-Grenzen gehalten.
Virtual-Host-Gruppen werden in separaten Arbeitsbereichen für hohe Verbindungsanzahlen gehalten. Multi-Domain-Traffic wird zentral verwaltet, ohne die Verbindungskapazität einzuschränken. Betriebliche Änderungen in einer Domain-Gruppe beeinflussen andere Gruppen nicht unnötig.
Wenn sich eine Domain, ein Pool oder ein Zertifikat ändert, erkennt TR7 den Konfigurationsunterschied. Nur die betroffene Komponente wird via Soft-Reload aktualisiert. Bestehende Verbindungen werden drainiert, während neuer Traffic unter der aktualisierten Konfiguration akzeptiert wird.
Undefinierte Host- oder SNI-Werte können zu einem Standard-Backend, einer Fehlerantwort oder einer Sicherheitsrichtlinie geleitet werden. Dies bietet kontrolliertes Verhalten bei Subdomain-Hijacking- und unerwarteten Domain-Zugriffsszenarien.
Die Virtual-Hosts-Fähigkeit befasst sich nicht nur mit Domain-Matching, sondern auch mit Reload-Strategie, Tenant-Trennung, Wildcard-Normalisierung und Hochverbindungs-Betrieb zusammen.
Virtual Hosts, die dieselbe IP, denselben Port und denselben Betriebstyp teilen, werden als Gruppe behandelt. Domain-Mappings innerhalb der Gruppe werden in sortierter, deterministischer Reihenfolge generiert. Diese Struktur verhindert unerwünschte Konfigurationsunterschiede.
Exakte Domain-Werte werden mit direktem String-Matching behandelt; Wildcard-Domains werden mit automatischem Pattern-Matching behandelt. Da Operatoren keine Regex manuell schreiben, wird das Fehlerrisiko reduziert. Domain-Zeichen werden sicher escaped.
Im TLS-Modus wird die Entscheidung anhand des SNI-Werts getroffen; im HTTP-Modus anhand des Host-Headers. Diese Trennung ist automatisch. Operatoren müssen keine unterschiedliche Routing-Logik für jedes Szenario schreiben.
TR7 vergleicht die aktuelle Konfiguration mit der zu generierenden Konfiguration. Eine Reload- oder Restart-Entscheidung wird nur getroffen, wenn ein echter Unterschied besteht. Wenn sich nichts geändert hat, wird keine Aktion ausgeführt.
Ein Soft-Reload wird nur dann angewendet, wenn sich die laufende Proxy-Konfiguration geändert hat. Dies verhindert unnötige Unterbrechung aktiver Verbindungen. Wenn eine tiefere Arbeitsbereichsänderung erforderlich ist, wird ein kontrollierter Neustart durchgeführt.
Jede Zone sieht ihre eigene Domain- und vhost-Konfiguration. Domain-Management ist bei Multi-Kunden- oder Multi-Abteilungs-Bereitstellungen getrennt. Dieser Ansatz verbessert sowohl die Betriebssicherheit als auch die Verwaltungssimplizität.
Virtual-Host-Routing ist nur dann sinnvoll, wenn der relevante Pool aktiv und gesund ist. Pool-Health-Checks, Backend-Status, Zertifikate und das WAAP-Profil bestimmen die endgültige Entscheidungskette für Domain-Traffic.
Bei modernen Clients kann eine Diskrepanz zwischen SNI und Host-Header dazu führen, dass Traffic das falsche Backend erreicht. TR7 macht solche Situationen durch die Virtual-Host- und Sicherheitsprofil-Kette kontrollierbar.
`tenant1.app.com`, `tenant2.app.com` und `tenant3.app.com` teilen alle dieselbe VIP. Eine Wildcard-Domain-Regel erfasst alle Tenant-Subdomains unter einem einzigen Eintrag; jeder Tenant wird zu seinem eigenen Pool und WAAP-Profil geleitet.
`shop.example.com` geht zum öffentlichen Store-Pool; `admin.example.com` geht zu einem Management-Pool mit mTLS und strengerer Zugriffsrichtlinie. Ein einziger Port 443 wird verwendet und Sicherheitsrichtlinien werden auf Domain-Ebene getrennt.
`api.example.com` wird zum neuen API-Pool geleitet, während `api-v2.example.com` zum Legacy-Pool geht. Während des Übergangs teilen beide Dienste dieselbe IP; DNS- und Firewall-Architektur bleiben unverändert.
Die Virtual-Host-Schicht trennt die Domain; die nachgelagerte Pool-Schicht wendet unterschiedliche Traffic-Regeln oder Sicherheitsprofile basierend auf geografischen Informationen an. Eine Domain-und-Standort-Entscheidungskette arbeitet von Anfang bis Ende.
Undefinierte oder unerwartete Subdomain-Anfragen werden unter ein Standard-Sicherheitsverhalten gestellt. Selbst wenn ein Wildcard-Zertifikat im Einsatz ist, können unerwartete Subdomains keine unkontrollierten Backends erreichen.
`portal.example.com` ist für Internetbenutzer offen, während `partner-api.example.com` nur mit mTLS und einer IP-Allowlist zugänglich ist. Beide Dienste teilen dieselbe IP und denselben Port, jeder unter seiner eigenen Sicherheitsschicht.
SNI- und Host-Header-Trennung, Wildcard-Domain-Unterstützung, domainspezifisches WAAP und Zero-Downtime-Reload. Lassen Sie uns ein Live-Setup auf Ihrer eigenen Infrastruktur durchgehen.