Eine separate IP und einen separaten Listener für jede Domain zu verwalten skaliert nicht.
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.
Unser Ansatz
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.
Zwei Matching-Modi: SNI und Host-Header
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-Domains werden automatisch in Matching-Regeln konvertiert
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 ist an ihren eigenen Pool und ihre eigene Richtlinienkette gebunden
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.
Deterministische Konfiguration und idempotenter Reload
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.
Fähigkeiten
Virtual Hosts bietet domainbasierte Trennung, Wildcard-Management, Zertifikatsbindung, Tenant-Isolation und Zero-Downtime-Updates auf derselben IP und demselben Port.
SNI-basiertes Virtual-Host-Routing
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.
Host-Header-basiertes HTTP-Routing
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-Domain-Unterstützung
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.
Domainspezifische Pool-Bindung
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.
Domainspezifisches WAAP-, Cache- und Log-Profil
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.
Zertifikats- und SNI-Ausrichtung
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.
Proxy-Metadatenkette wird bewahrt
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.
Pool-Tunnel-Socket-Architektur
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.
Zonen-bewusstes Multi-Tenant-vhost-Management
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.
Betriebsmodell für hohe Verbindungsanzahlen geeignet
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.
Zero-Downtime-Updates mit Soft-Reload
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.
Undefiniertes Domain-Verhalten ist kontrollierbar
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.
Operative Tiefe
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.
Gruppenlogik
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.
Matcher-Generierung
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.
SNI/Host-Trennung
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.
Konfigurationsdifferenzanalyse
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.
Soft-Reload-Verhalten
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.
Tenant-Sichtbarkeit
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.
Pool-Abhängigkeit
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.
HTTP/2 und Misdirected-Request-Verhalten
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.
Wann einsetzen
Multi-Tenant-SaaS-Subdomain-Management
`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.
E-Commerce und Admin-Panel auf derselben IP trennen
`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-Versionen mit Domains aufteilen
`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.
Arbeit mit einer geografischen Richtlinienkette
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.
Subdomain-Hijacking-Risiko reduzieren
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.
Öffentliches Portal und private API auf einer einzigen VIP
`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.
Häufig gestellte Fragen
Was ist der Unterschied zwischen SNI-basiertem und Host-Header-basiertem Routing?
Wie werden Wildcard-Domains behandelt?
Wie viele Domains können auf derselben VIP betrieben werden?
Werden Verbindungen unterbrochen, wenn eine Domain geändert wird?
Kann ein separates WAAP- oder Cache-Profil pro Domain verwendet werden?
Was passiert, wenn eine Anfrage für eine undefinierte Domain eintrifft?
Alle Ihre Domains über eine einzige VIP verwalten
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.