TLS-Beendigung oder Durchleitung? Wahl der richtigen Webship Reverse-Proxy-Grenze

Die Wahl zwischen TLS-Termination und TLS-Pass-Through ist keine kosmetische Proxy-Einstellung. Sie entscheidet, wo die Verschlüsselung endet, welches System Sitzungsschlüssel hält, ob Webship HTTP inspizieren kann und welche Ebene die Anwendungssicherheit durchsetzen muss.

Webship ist standardmäßig auf Durchleitung eingestellt. Dadurch bleiben die Anwendungs-Plaintext-Daten und die aktiven Sitzungsschlüssel am Ursprung. Aktivieren Sie die Beendigung nur, wenn der Edge die HTTP-Anfrage verstehen und darauf reagieren muss.

Die Entscheidung in einem Satz

Verwenden Sie TLS-Pass-Through, wenn der Ursprung die TLS-Grenze besitzen muss. Verwenden Sie TLS-Termination, wenn Webship HTTP-Verkehr routen, schützen, transformieren, zwischenspeichern oder überwachen muss.

Kein Modus ist universell sicherer. Der Durchleitungsmodus reduziert das sensible Material, das am Edge verarbeitet wird, entfernt jedoch die HTTP-Sicherheitskontrollen des Edge. Der Terminierungsmodus fügt einen überprüfbaren Durchsetzungspunkt hinzu, macht aber Webship zu einem Teil der vertrauenswürdigen TLS-Grenze.

| Anliegen | TLS-Beendigung | TLS-Durchleitung | | --- | --- | --- | | TLS-Endpunkt | Webship | Ursprung | | Anwendungs-Plaintext bei Webship | Ja | Nein | | Aktive Downstream-Sitzungsschlüssel bei Webship | Ja | Nein | | Route nach HTTP-Pfad oder Methode | Ja | Nein | | WAF, API-Schutz und Körpergrenzen bei Webship | Ja | Nein | | Proxy-Cache, Umschreibungen und Weiterleitungs-Header | Ja | Nein | | TCP-Routing-Eingabe | HTTP-Authority- und Routenrichtlinie | ClientHello SNI | | HTTP/3 Routing | HTTP-Anfragedaten | Eine gemeinsame UDP-Quelle | | Ursprungsverantwortung | HTTP oder separat konfiguriertes Upstream-TLS | Vollständiges TLS, ALPN und HTTP-Stack |

Die wichtige Frage lautet daher nicht „Welcher Schalter ist schneller?“ Es ist „Welches Bauteil muss die Anfrage sehen und steuern dürfen?“

Welche Beendigung gibt Webship

Mit tls_termination = true führt Webship das Downstream-TLS durch und leitet die entschlüsselte Anfrage in seine HTTP-Reverse-Proxy-Pipeline weiter. Dadurch werden die folgenden Funktionen möglich:

• Pfad-, Host- und Methoden-bewusstes Routing;
• WAF- und API-Schutz-Inspektion;
• Grenzen für Anforderungskörper und Richtlinienzeitüberschreitungen;
• Proxy-Caching und generationssichere Ungültigmachung;
• Verwaltung von Weiterleitungs-Headern und Feldern des HTTP-Zugriffsprotokolls;
• körperbewusste ABFRAGE-Verarbeitung, Wiederholungen, wo sicher, und Circuit-Breaker-Richtlinie;
• Protokollübersetzung zwischen den clientseitigen und den Upstream-Verbindungen.

Dieser Modus ändert auch die Sicherheitsverantwortung. Der Webship-Host muss den privaten Zertifikatschlüssel, Sitzungsschlüssel, entschlüsselte Anforderungs- und Antwortdaten, Observability-Ausgaben und jede zwischengespeicherte Darstellung schützen. Wenn der nächste Hop verschlüsselt bleiben muss, konfigurieren Sie TLS für den typisierten Upstream separat; andernfalls ist der HTTP-Upstream im Klartext.

Beendigung ist die rechte Grenze, wenn Webship erwartet wird, sich als anwendungsbewusster Edge zu verhalten und nicht nur als verschlüsselter Transport-Relay.

Was Durchreichen bewahrt

Mit tls_termination = false—dem Standard—überträgt Webship verschlüsselten TLS- oder QUIC-Verkehr, ohne die HTTP-Anfrage oder -Antwort zu entschlüsseln. Anwendungs-Plaintext und aktive Sitzungsschlüssel bleiben beim Ursprung.

Diese kleinere Vertrauensgrenze ist wertvoll, wenn Zertifikate in der Anwendungsebene verbleiben müssen, die Compliance-Richtlinie die Entschlüsselung am Edge verbietet oder eine herkunftsspezifische TLS-Identität unverändert den Client erreichen muss. Sie entfernt außerdem die HTTP-Analyse und Richtlinienarbeit aus dem Relay-Pfad.

Der Kompromiss ist strikt: Webship kann nicht das prüfen, was es nicht entschlüsseln kann. Es kann keine HTTP-WAF-Regeln anwenden, nicht nach Pfad routen, keine Header umschreiben, keine körperbewusste API-Richtlinie durchsetzen oder HTTP-Feld-Zugriffsprotokolle füllen. Der Ursprung muss all diese Kontrollen selbst bereitstellen.

Durchleitung ist daher nicht „Beendigung mit weniger Funktionen“. Es ist eine andere Architektur mit einem anderen Sicherheitsverantwortlichen.

Protokoll-spezifische Grenzen sind wichtig

Für HTTP/1.1 TLS und HTTP/2 TLS überprüft Webship das ClientHello nur so weit, dass das konfigurierte TCP-Ziel anhand von SNI ausgewählt werden kann. Jede Durchleitungs-Domain benötigt eine Catch-All-path_prefix = "/"-Route, da der tatsächliche Anforderungspfad verschlüsselt bleibt. Ein Client ohne SNI wird nur akzeptiert, wenn die Konfiguration genau eine Domain enthält.

Der Ursprung muss das ALPN des Clients aushandeln und das ausgewählte Protokoll unterstützen. Webship kann einen HTTP/2-Client nicht in einen HTTP/1.1-Ursprung umwandeln, während die TLS-Sitzung unverändert durchläuft.

HTTP/3 verwendet QUIC über UDP und hat eine engere Grenze. Pass-Through kann nicht sicher nach verschlüsselter HTTP-Authority weiterleiten, daher muss jede konfigurierte HTTP/3-Route auf denselben IP-Socket-UDP-Ursprung aufgelöst werden. Webship lehnt Unix-Sockets und mehrere HTTP/3-Pass-Through-Ursprünge während der Konfigurationsprüfung ab, anstatt stillschweigend mehrdeutig weiterzuleiten.

Klartext HTTP/1.1 und h2c sind von reverse_proxy.tls_termination nicht betroffen. Die Einstellung steuert nur das nachgelagerte HTTP/1.1 TLS, HTTP/2 TLS und HTTP/3 TLS.

Gemessene Anforderungskapazität

Der Webship 1.3.1 Debian-Kapazitätsbenchmark misst die beiden verschlüsselten Reverse-Proxy-Modi separat. Jede akzeptierte Probe erforderte keine HTTP-, Socket-, Protokoll-, Proxy-, Hauptseitenfehler- und HTTP/3 Paketverlustfehler.

| Reverse-Proxy-Modus | HTTP/1.1 TLS | HTTP/2 TLS | HTTP/3 TLS | | --- | ---: | ---: | ---: | | TLS-Beendigung | 123.344 RPS | 124.957 RPS | 131.529 RPS | | TLS-Passthrough | 203.950 RPS | 266.845 RPS | 167.010 RPS |

Small-Response-Pass-Through hat weniger Anwendungsarbeit zu erledigen: Es leitet verschlüsselte Transportdaten weiter, anstatt TLS zu beenden, HTTP zu parsen, Richtlinien zu bewerten und einen neuen nachgelagerten TLS-Stream zu erzeugen. Die höheren Pass-Through-Anforderungsraten spiegeln diese engere Aufgabe wider.

Diese Zeilen repräsentieren keine identischen Funktionssätze und sollten nicht verwendet werden, um zu behaupten, dass eine Sicherheitsarchitektur universell besser ist. Termination zahlt für HTTP-bewusste Fähigkeiten, die Pass-Through absichtlich nicht bieten kann.

Massives Streaming ändert das Ergebnis

Dasselbe Benchmark verwendete einen exakt 99.943.778-Byte-Antwortkörper für die 100-MB-Streaming-Matrix. Hier erzeugte die TLS-Beendigung einen höheren mittleren Payload-Durchsatz für alle drei Protokolle:

| Reverse-Proxy-Modus | HTTP/1.1 TLS | HTTP/2 TLS | HTTP/3 TLS | | --- | ---: | ---: | ---: | | TLS-Beendigung | 3,585.7 MiB/s | 3,355.0 MiB/s | 1,938.6 MiB/s | | TLS-Durchleitung | 2.783,2 MiB/s | 2.135,0 MiB/s | 1.748,5 MiB/s |

Warum ändert sich die Richtung? Im Terminierungsmodus sendet der Benchmark-Ursprung Klartext-HTTP an Webship, und Webship besitzt den optimierten Downstream-Bulk-Pfad. Große HTTP/1.1- und HTTP/2-Antworten können adaptive Linux-kTLS und begrenzte transportspezifische Pufferung verwenden. HTTP/3 verwendet QUIC-Pacing, DPLPMTUD und pro-Reaktor-Batch-Verarbeitung anstelle von kTLS.

Im Pass-Through-Modus besitzt der Ursprung das nachgelagerte TLS und Webship leitet den resultierenden verschlüsselten Stream oder QUIC-Pakete weiter. Das bewahrt die TLS-Grenze des Ursprungs, aber es kann nicht den HTTP-bewussten Bulk-Response-Pfad von Webship nutzen.

Die sieben Muster der HTTP/3-Qualifikation überprüften auch die Stabilität. Beendetes Streaming erreichte ein Median von 1.938,6 MiB/s mit einem Variationskoeffizienten von 2,12 %; Pass-Through erreichte 1.748,5 MiB/s mit einem Variationskoeffizienten von 1,65 %. Beide lieferten den exakten Inhalt ohne Fehler bei Client, Protokoll und Paketverlust.

Durchleitung absichtlich konfigurieren

Eine minimale Durchleitungs-Konfiguration hält die TLS-Identität bereit, sodass ein Betreiber die Beendigung später aktivieren kann, ohne die Zertifikatspfade zu ändern:

[reverse_proxy]
enabled = true
tls_termination = false

[reverse_proxy.protocols]
h1 = true
h2 = true
h3 = true

[reverse_proxy.tls]
cert = "/etc/webship/proxy-cert.pem"
key = "/etc/webship/proxy-key.pem"

[[reverse_proxy.routes]]
domain = "app.example.com"
path_prefix = "/"
upstreams = ["10.0.0.20:443"]

[[reverse_proxy.policies]]
name = "default"
path_prefixes = ["/"]
total_timeout_ms = 30000

Das gestufte Webship Zertifikat ist gültig, wird jedoch nicht von aktiven Pass-Through-Sitzungen verwendet. Der Ursprung bei 10.0.0.20:443 muss TLS beenden und das vom Client ausgehandelte Protokoll unterstützen.

Beenden aktivieren, wenn der Edge HTTP benötigt

Für einen anwendungsbewussten Edge aktivieren Sie die Terminierung und senden den resultierenden HTTP-Verkehr an den ausgewählten Ursprung:

[reverse_proxy]
enabled = true
tls_termination = true

[reverse_proxy.protocols]
h1 = true
h2 = true
h3 = true

[reverse_proxy.tls]
cert = "/etc/webship/proxy-cert.pem"
key = "/etc/webship/proxy-key.pem"

[[reverse_proxy.routes]]
domain = "app.example.com"
path_prefix = "/api"
strip_path_prefix = true
upstreams = ["10.0.0.20:8080", "10.0.0.21:8080"]

[[reverse_proxy.policies]]
name = "default"
hosts = ["app.example.com"]
path_prefixes = ["/"]
max_body_bytes = 1048576
request_body_idle_timeout_ms = 5000
upstream_header_timeout_ms = 5000
response_body_idle_timeout_ms = 5000
downstream_write_idle_timeout_ms = 5000
total_timeout_ms = 30000

Diese Konfiguration kann HTTP weiterleiten und inspizieren. Fügen Sie Upstream-TLS hinzu, wenn das Netzwerk zwischen Webship und dem Ursprung nicht bereits vertraut oder isoliert ist.

Wechseln Sie die Modi, ohne Webship neu zu starten

Webship kann tls_termination durch ein Konfigurationsdatei-Reload oder das versionsgeprüfte webship.reverse_proxy.apply_config MCP-Tool ändern. Lesen Sie das aktuelle Objekt und die Version mit webship.reverse_proxy.get_config, ändern Sie nur das beabsichtigte Feld im vollständig zurückgegebenen Objekt und übermitteln Sie es mit dem passenden expected_version_id.

Neue TCP-Verbindungen verwenden den neuen Modus. HTTP/3-Clients stellen die Verbindung zum ersetzten UDP-Transport wieder her. Änderungen an Zertifikat- und Schlüsselpfaden bleiben prozessgebunden und erfordern einen Neustart, daher halten Sie eine gültige Beendigungsidentität bereit, bevor Sie auf einen Live-Wechsel umstellen.

Die Versionsprüfung verhindert, dass ein Bediener eine gleichzeitige Konfigurationsänderung überschreibt. Eine abgelehnte Aktualisierung lässt die aktive Laufzeit und die gespeicherte Konfiguration unverändert.

Eine praktische Auswahlliste

Wählen Sie Durchleitung, wenn alle diese zutreffen:

1. Der Ursprung muss die Zertifikatsgrenze und die Sitzungsschlüssel beibehalten.
2. SNI-Ebene TCP-Routing – oder ein gemeinsamer HTTP/3 UDP-Ursprung – ist ausreichend.
3. Die Quelle stellt die erforderliche WAF, Autorisierung, Protokollierung, Inhaltsgrenzen und Missbrauchskontrollen bereit.
4. Es ist kein Edge-Cache, keine Pfadumschreibung, keine Weiterleitungs-Header-Richtlinie oder HTTP-Protokollübersetzung erforderlich.

Wählen Sie die Beendigung, wenn eine dieser Anforderungen bei Webship erforderlich ist:

1. Route nach Host, Pfad oder Methode.
2. Überprüfen Sie Anfragen mit WAF oder API Shield.
3. Durchsetzen von Körpergrenzen, HTTP-Zeitüberschreitungen oder Edge-Authentifizierung.
4. Antworten zwischenspeichern oder HTTP-Header umschreiben.
5. Zwischen abwärtsgerichteten und aufwärtsgerichteten HTTP-Protokollen übersetzen.
6. Beobachten Sie HTTP-Felder an der Proxy-Grenze.

Unabhängig davon, welchen Modus Sie auswählen, testen Sie SNI, ALPN, Zertifikatsidentität, Abbruch durch den Client, halbe Schließung durch den Upstream und die genaue Integrität der Antwort. Messen Sie die Anforderungskapazität und den Streaming-Durchsatz separat: Der schnellste Modus für eine kleine Antwort ist nicht unbedingt der schnellste Modus für einen 100-MB-Body.

Webship macht Pass-Through zur Standardeinstellung, weil ein Proxy seine Vertrauensgrenzen nicht stillschweigend erweitern sollte. Die Beendigung bleibt eine aktive, explizite operative Entscheidung, wenn HTTP-bewusstes Edge-Verhalten diese Verantwortung wert ist.

Lesen Sie die vollständige [Reverse-Proxy-Dokumentation](/docs/1.3.1), vergleichen Sie die akzeptierte [Benchmark-Matrix](/benchmarks) oder laden Sie Webship von [Downloads](/downloads) herunter.

Quellen- und Inhaltsmethode

Leistungswerte sind akzeptierte Mediane aus dem Webship 1.3.1 einheitlichen Debian-Kapazitätsbenchmark vom 11. September 2026; seine Akzeptanzkriterien erfordern null Client-, HTTP-, Socket-, Protokoll-, Proxy-, Major-Page-Fault- und HTTP/3 Paketverlustfehler.