Forward Proxy und Reverse Proxy im Vergleich — xinux.net
Ein Forward Proxy steht auf der Seite des Clients. Der Client kennt den Proxy und ist explizit dafür konfiguriert — im Browser, im Betriebssystem oder per Umgebungsvariable. Jede Anfrage geht zuerst an den Proxy, nie direkt an das eigentliche Ziel.
Der Zielserver bekommt nie die IP-Adresse des Clients zu sehen, sondern nur die des Proxys. Typischer Einsatzzweck: zentrale Kontrolle des ausgehenden Verkehrs eines Netzes — Filterung, Protokollierung, Caching, Virenscan (siehe SSL-Bump/ICAP-Variante).
Der Client konfiguriert den Proxy selbst und kennt ihn. Der Webserver antwortet immer an den Proxy — auf der Strecke Proxy → Webserver taucht die Client-IP nie auf.
Ein Reverse Proxy steht auf der Seite des Servers. Der Client konfiguriert nichts — er kennt nur eine Adresse (z. B. www.example.com) und hält diese für den eigentlichen Server. In Wirklichkeit landet die Anfrage beim Reverse Proxy, der sie an einen oder mehrere Backend-Server im internen Netz weiterreicht.
Der Client sieht nie die IP des Backends — für ihn ist der Reverse Proxy der Server. Typischer Einsatzzweck: mehrere interne Server hinter einer öffentlichen Adresse verbergen, zentrale Verschlüsselung, spätere Erweiterung um Lastverteilung oder WAF.
Der Client kennt nur den Reverse Proxy und hält ihn für den Server. Welcher Backend-Server die Anfrage am Ende beantwortet, entscheidet allein der Reverse Proxy — der Client bekommt davon nichts mit.
Ein Application Proxy (z. B. ein HTTP-Proxy) versteht das Protokoll, das er weiterreicht. Er parst die Anfrage — Methode, URL, Header — und kann anhand des Inhalts Entscheidungen treffen: URL sperren, Dateityp blockieren, Antwort cachen, Header umschreiben.
Der Preis dafür: Für jedes Protokoll (HTTP, FTP, SMTP, …) braucht es eine eigene Implementierung, die genau dieses Protokoll versteht. Ein HTTP-Proxy kann kein FTP.
Der Application Proxy kennt Methode, URL und Header der Anfrage und kann deshalb inhaltlich entscheiden — filtern, cachen, umschreiben. Das funktioniert nur, weil er das konkrete Protokoll (hier HTTP) versteht.
Ein Circuit Level Proxy (z. B. SOCKS) versteht das übertragene Protokoll nicht. Der Client teilt ihm nur mit, zu welcher Ziel-IP und welchem Port eine Verbindung aufgebaut werden soll — danach reicht der Proxy jedes weitere Byte unverändert und uninterpretiert durch.
Vorteil: Er funktioniert mit jedem TCP-basierten Protokoll — HTTP, FTP, SMTP, TLS, egal was. Nachteil: Er kann nicht nach Inhalt filtern oder cachen, sondern nur nach Ziel-IP/Port entscheiden.
Der Circuit Level Proxy baut nur einen Kanal zwischen Client und Ziel auf und leitet danach jedes Byte durch, ohne es zu verstehen. Er weiß, wohin die Daten sollen — aber nicht, was in ihnen steht.
Damit der Proxy verschlüsselten HTTPS-Verkehr auf Viren prüfen kann, muss er die TLS-Verbindung aufbrechen: Er terminiert die TLS-Sitzung des Clients selbst und baut eine zweite, getrennte TLS-Sitzung zum Webserver auf. Dazwischen liegt der Inhalt kurz entschlüsselt vor und wird per ICAP an c-icap + SquidClamAV zum Scannen übergeben.
Voraussetzung: Der Client muss dem Proxy vertrauen — die Root-CA des Proxys ist auf dem Client als vertrauenswürdig importiert. Nur so akzeptiert der Browser das vom Proxy für jede Verbindung neu generierte Zertifikat, ohne eine Zertifikatswarnung anzuzeigen.
Zwei getrennte TLS-Sitzungen treffen sich am Proxy: Client ↔ Proxy (Proxy-Zertifikat, vom Client per importierter Proxy-CA akzeptiert) und Proxy ↔ Webserver (Original-Zertifikat). Nur weil der Proxy beide Seiten selbst terminiert, kann er den Inhalt dazwischen entschlüsselt an ICAP/ClamAV zum Scannen übergeben.