Apache als Reverse Proxy mit mod_proxy unter Ubuntu konfigurieren

Der Apache HTTP Server stellt mit der Modulfamilie mod_proxy ein flexibles Framework für Reverse Proxys bereit. Mit einer passenden Konfiguration kann Apache vor einer oder mehreren Backend-Anwendungen arbeiten, Client-Anfragen weiterleiten, SSL-/TLS-Verbindungen terminieren, den Datenverkehr auf mehrere Server verteilen und eine zusätzliche Sicherheits- und Kontrollschicht zwischen Benutzern und der Anwendungsinfrastruktur bilden.

In diesem Tutorial erfährst du, wie Apache unter Ubuntu mit der Modulfamilie mod_proxy als Reverse Proxy eingerichtet wird. Dabei installierst du Apache, aktivierst die erforderlichen Proxy-Module, richtest die grundlegende Weiterleitung mit ProxyPass und ProxyPassReverse ein, bewahrst Client-Informationen mithilfe weitergeleiteter Header, verteilst Anfragen mit mod_proxy_balancer auf mehrere Backend-Systeme, konfigurierst die SSL-Terminierung auf Proxy-Ebene, härtest die Konfiguration ab und untersuchst typische mod_proxy-Probleme in Produktionsumgebungen.

Wichtige Erkenntnisse

• Mit der Apache-Modulfamilie mod_proxy kann der Apache HTTP Server als Reverse Proxy eingesetzt werden, Anfragen an Backend-Anwendungen weiterleiten, SSL-/TLS-Verbindungen terminieren, Datenverkehr auf mehrere Server verteilen und die Verarbeitung von Anfragen über eine zentrale Frontend-Schicht bündeln.
• Ein Reverse Proxy befindet sich zwischen Clients und Backend-Anwendungsservern. Dadurch kann Apache einen einzigen öffentlich erreichbaren Endpunkt bereitstellen, während interne Dienste, Ports und Infrastruktur nicht direkt über das Internet zugänglich sein müssen.
• Apache-Reverse-Proxy-Konfigurationen werden häufig eingesetzt, um Node.js-, Python-, Java- oder PHP-Anwendungen hinter einem stabilen Frontend-Server zu betreiben, der HTTPS, Routing, Protokollierung und Zugriffskontrolle für die Backend-Dienste übernimmt.
• Die Direktiven ProxyPass und ProxyPassReverse bilden die Grundlage einer Apache-Reverse-Proxy-Konfiguration. Sie leiten Anfragen an Backend-Dienste weiter und sorgen dafür, dass Weiterleitungen und bestimmte Antwort-Header der Backend-Anwendungen korrekt angepasst werden.
• Weitergeleitete Header wie X-Forwarded-For, X-Forwarded-Host und X-Forwarded-Proto helfen Backend-Anwendungen dabei, Informationen über die ursprüngliche Client-IP-Adresse, den angeforderten Hostnamen und das verwendete Verbindungsprotokoll zu behalten, nachdem der Datenverkehr Apache passiert hat.
• Apache verteilt seine Reverse-Proxy-Funktionen auf Module wie mod_proxy_http, mod_proxy_balancer, mod_proxy_wstunnel und mod_proxy_fcgi. Dadurch lassen sich nur die Funktionen aktivieren, die für die jeweilige Umgebung tatsächlich benötigt werden.
• Das Modul mod_proxy_balancer verteilt Anfragen auf mehrere Backend-Server. Dadurch können Skalierbarkeit und Verfügbarkeit verbessert werden. Gleichzeitig werden verschiedene Balancing-Algorithmen und Sticky Sessions für zustandsbehaftete Anwendungen unterstützt.
• Eine SSL-Terminierung auf der Apache-Proxy-Ebene vereinfacht die Zertifikatsverwaltung, weil Apache verschlüsselte HTTPS-Verbindungen von Clients verwalten und die Anfragen anschließend per HTTP oder HTTPS an Backend-Anwendungen weiterleiten kann.
• Reverse Proxys sollten sorgfältig abgesichert werden. Zu den wichtigen Maßnahmen gehören das Deaktivieren der Forward-Proxy-Funktion mit ProxyRequests Off, der Schutz administrativer Schnittstellen, eine möglichst geringe Offenlegung von Serverinformationen und sinnvoll gewählte Timeout-Werte.
• Typische mod_proxy-Probleme wie 502 Bad Gateway, 503 Service Unavailable, SSL-Verifizierungsfehler oder fehlende Module lassen sich in vielen Fällen mithilfe der Apache-Protokolle, direkter Verbindungstests zum Backend und einer Konfigurationsprüfung mit apache2ctl configtest untersuchen.

Voraussetzungen

Bevor du beginnst, solltest du über einen Ubuntu-Server mit einer aktuell unterstützten Version wie Ubuntu 22.04 oder Ubuntu 24.04 verfügen. Außerdem sollte ein Benutzerkonto ohne Root-Anmeldung mit sudo-Berechtigungen vorhanden und eine Firewall aktiviert sein.

Falls der Server noch nicht vorbereitet wurde, richte zunächst einen administrativen Benutzer ohne direkte Root-Anmeldung mit sudo-Rechten ein und aktiviere eine geeignete Firewall. Wenn du mit der Apache-Verwaltung unter Ubuntu noch nicht vertraut bist, ist es außerdem hilfreich, den üblichen Ablauf für Installation und Dienstverwaltung von Apache zu kennen.

Was ist ein Reverse Proxy und warum wird mod_proxy verwendet?

Ein Reverse Proxy ist ein Server, der zwischen Clients und einem oder mehreren Backend-Anwendungsservern steht. Fordert ein Client eine Ressource an, erreicht die Verbindung zunächst den Reverse Proxy. Apache wertet anschließend die konfigurierten Routing-Regeln aus, die in der Regel über ProxyPass und ProxyPassReverse innerhalb eines VirtualHost definiert werden. Danach wählt Apache das passende Backend aus, leitet die Anfrage weiter und sendet die Antwort des Backends anschließend so an den Client zurück, als hätte Apache selbst die Antwort erzeugt.

Dieses Modell unterscheidet sich von einem Forward Proxy. Ein Forward Proxy vertritt Clients beim Zugriff auf externe Internetressourcen, während ein Reverse Proxy Anwendungen gegenüber den Clients repräsentiert. Clients sehen normalerweise lediglich den Hostnamen, die IP-Adresse und das TLS-Zertifikat des Proxy-Servers. Interne Backend-Hostnamen, Ports und die physische Serverstruktur bleiben verborgen. Durch diese Trennung können Backend-Dienste ersetzt, erweitert, aktualisiert oder gepatcht werden, ohne dass Clients wissen müssen, wie die interne Infrastruktur aufgebaut ist.

Moderne Anwendungsumgebungen verwenden diese Architektur häufig, weil Anwendungsserver wie Node.js-Dienste, Python-WSGI-Anwendungen oder Java-Servlet-Container zwar auf die effiziente Verarbeitung von Anwendungstraffic ausgelegt sind, aber nicht zwangsläufig als öffentlich erreichbare Netzwerkschicht betrieben werden sollen. Apache übernimmt die öffentliche Client-Verbindung, setzt Richtlinien am Netzwerkrand durch und übergibt die eigentliche Anwendungsverarbeitung an spezialisierte Backend-Dienste.

Warum einen Reverse Proxy verwenden?

Mit einem Reverse Proxy lassen sich Funktionen zentralisieren, die andernfalls auf jeder einzelnen Anwendungsinstanz separat eingerichtet werden müssten. TLS-Einstellungen, Request-Logging, Rate Limits und Zugriffsbeschränkungen können auf der Proxy-Ebene verwaltet werden, anstatt dieselben Einstellungen in jeder Anwendung zu wiederholen. Dadurch kann die Administration vereinfacht, die Sicherheit einheitlicher umgesetzt und die Skalierung bei wachsendem Datenverkehr erleichtert werden.

Frontend- und Backend-Dienste voneinander trennen

Backend-Anwendungen werden häufig an Loopback-Adressen wie 127.0.0.1 oder an private Netzwerkschnittstellen gebunden, die nicht direkt aus dem öffentlichen Internet erreichbar sind. Das ist üblicherweise beabsichtigt. Ein Anwendungsprozess ist möglicherweise nicht ausreichend für eine direkte öffentliche Erreichbarkeit abgesichert, oder auf einem Server laufen mehrere Dienste, ohne dass jeder davon einen eigenen öffentlichen Port benötigt.

Apache verbindet beide Ebenen miteinander, indem der Webserver auf Standardports wie 80 und 443 lauscht, während Backend-Anwendungen andere Ports verwenden. Beispielsweise kann Apache öffentliche Anfragen annehmen, während eine Node.js-API lokal unter 127.0.0.1:3000 läuft. Durch pfadbasiertes Routing können Anfragen unter /api/ an diese Anwendung weitergeleitet werden, während Apache statische Inhalte direkt ausliefert. Benutzer greifen dadurch über eine einzige Domain und ein einziges Zertifikat zu, während die eigentlichen Anwendungsprozesse außerhalb des öffentlichen Netzwerks bleiben.

Eine solche Architektur kann auch Aktualisierungen vereinfachen. Eine neue Version eines Backends kann beispielsweise auf einem anderen Port bereitgestellt und anschließend nur das Proxy-Ziel geändert werden. Ebenso lässt sich ein Blue-Green-Deployment umsetzen, ohne dass Benutzer andere URLs verwenden oder DNS-Einträge geändert werden müssen. Mehrere Anwendungen können außerdem denselben öffentlichen Hostnamen verwenden und anhand von Pfaden oder Subdomains durch Apache auf unterschiedliche Backends verteilt werden.

SSL-/TLS-Terminierung

Verschlüsselte Kommunikation ist wichtig, doch einzelne Zertifikate auf jedem Backend-System zu verwalten, verursacht zusätzlichen Administrationsaufwand und erhöht das Risiko abgelaufener oder falsch konfigurierter Zertifikate. Bei einer SSL-Terminierung stellt der Client die HTTPS-Verbindung zu Apache her. Apache entschlüsselt die Verbindung mit dem für die Website konfigurierten Zertifikat und leitet die Anfrage danach an das Backend weiter.

Befinden sich die Backend-Systeme in einem vertrauenswürdigen privaten Netzwerk, kann Apache die entschlüsselte Anfrage per HTTP weiterleiten. Alternativ kann mit SSLProxyEngine On und den zugehörigen SSLProxy*-Direktiven auch eine weitere verschlüsselte Verbindung zu einem HTTPS-Backend aufgebaut werden. Unverschlüsseltes HTTP wird häufig verwendet, wenn das Backend auf demselben Host oder in einem vertrauenswürdigen Netzwerksegment läuft. HTTPS eignet sich dagegen, wenn auch die interne Kommunikation verschlüsselt bleiben muss.

Wird TLS zentral am Proxy verwaltet, können Zertifikatserneuerungen, Cipher-Konfigurationen und HTTP Strict Transport Security an einer einzigen Stelle gesteuert werden. Anwendungsframeworks können intern normales HTTP verwenden, ohne eine eigene TLS-Konfiguration zu benötigen. Das ist besonders bei containerisierten oder kurzlebigen Backend-Prozessen hilfreich, bei denen andernfalls Zertifikate separat verteilt werden müssten.

Load Balancing

Ein einzelnes Backend-System kann mit zunehmender Last zu einem Leistungsengpass werden. Apache kann dieses Problem mit mod_proxy_balancer lösen. Dabei wird eine Gruppe von Backend-Mitgliedern definiert und der eingehende Datenverkehr auf diese Systeme verteilt. Module wie mod_lbmethod_byrequests, mod_lbmethod_bytraffic und mod_lbmethod_bybusyness bestimmen, ob die Verteilung anhand der Anzahl von Anfragen, der übertragenen Datenmenge oder der aktuellen Auslastung der Backend-Systeme erfolgt.

Sticky Sessions können verwendet werden, wenn Sitzungsinformationen einer Anwendung lokal auf einem Backend gespeichert werden und nicht in einem gemeinsam genutzten Speicher liegen. Apache kann einen bestimmten Client während der Sitzung weiterhin demselben Backend zuordnen. Reagiert ein Backend nicht mehr oder wird als nicht verfügbar markiert, lässt sich der Datenverkehr an funktionierende Mitglieder weiterleiten. Dadurch kann die Verfügbarkeit verbessert werden, ohne dass die gesamte Anwendung ausfällt.

Proxy-basiertes Load Balancing bietet außerdem eine unkomplizierte Möglichkeit zur horizontalen Skalierung. Eine zusätzliche Instanz der Anwendung kann gestartet, als weiterer BalancerMember registriert und anschließend in die Verarbeitung eingehender Anfragen aufgenommen werden, ohne dass sich die öffentliche URL für Clients ändert.

Caching und Performance-Optimierung

Nicht jede Anfrage muss bei jedem Aufruf erneut eine Backend-Anwendung erreichen. Inhalte, die sich nur selten ändern, beispielsweise Bilder, Stylesheets oder öffentliche API-Antworten mit geeigneten Cache-Laufzeiten, können durch Apache über Module wie mod_cache und mod_cache_disk zwischengespeichert werden. Apache kann sich dabei an HTTP-Caching-Headern und administrativ festgelegten Regeln orientieren. Werden Antworten bereits auf der Frontend-Ebene aus dem Cache ausgeliefert, sinkt die CPU- und I/O-Belastung der Backends und wiederholte Anfragen können schneller beantwortet werden.

Apache ist zwar nicht in erster Linie als spezialisierter Caching-Proxy ausgelegt, Edge-Caching kann jedoch sinnvoll sein, wenn Apache ohnehin TLS-Verbindungen und statische Inhalte verarbeitet. Eine weitere Optimierung ist die Antwortkomprimierung über mod_deflate. Apache kann Antworten vor der Übertragung komprimieren und so das übertragene Datenvolumen reduzieren, ohne dass jede Backend-Anwendung selbst eine Komprimierungslogik implementieren muss.

Wie sich mod_proxy in das Apache-Modulsystem einfügt

Apache stellt Reverse-Proxy-Funktionen über eine modulare Familie bereit, deren Grundlage mod_proxy bildet. Das Kernmodul liefert gemeinsam genutzte Proxy-Infrastruktur, darunter Verbindungsverwaltung, allgemeine Direktiven und Erweiterungspunkte für protokollspezifische Module. mod_proxy muss für Reverse-Proxy-Funktionen aktiviert sein, während ergänzende Module zusätzliche Fähigkeiten bereitstellen.

Das Modul mod_proxy_http verarbeitet HTTP- und HTTPS-Verbindungen zu Backends und gehört deshalb meist zu den zuerst aktivierten Proxy-Modulen. mod_proxy_balancer ergänzt Load Balancing über BalancerMember-Direktiven und Konfigurationsblöcke wie <Proxy balancer://name>. mod_proxy_wstunnel verarbeitet WebSocket-Upgrades für Echtzeitanwendungen, während mod_proxy_fcgi Anfragen an FastCGI-Dienste wie PHP-FPM weiterleitet.

Weitere Module erweitern das Proxy-System für spezialisierte Einsatzbereiche. mod_proxy_ajp kommuniziert über das AJP-Protokoll mit Java-Anwendungsservern. mod_proxy_hcheck kann Backend-Health-Checks durchführen und nicht erreichbare Server aus der Verteilung entfernen. mod_proxy_html kann Links innerhalb von HTML-Antworten umschreiben, wenn sich interne Backend-URLs von der öffentlichen URL-Struktur unterscheiden.

Mehrere zentrale Direktiven werden von diesen Modulen gemeinsam verwendet. ProxyPass verbindet einen eingehenden URL-Pfad mit einer Backend-URL. ProxyPassReverse passt Antwort-Header so an, dass Weiterleitungen auf den öffentlichen Hostnamen und nicht auf interne Backend-Adressen verweisen. ProxyRequests Off deaktiviert die Forward-Proxy-Funktion. Wird Forward Proxying unbeabsichtigt aktiviert, kann daraus ein offener Proxy entstehen, was ein erhebliches Sicherheitsrisiko darstellt.

Da Apache die Funktionen auf mehrere Module verteilt, können Administratoren nur die Komponenten laden, die für das jeweilige System benötigt werden. Eine einzelne Apache-Installation kann TLS terminieren, REST-API-Anfragen weiterleiten, Traffic über einen Cluster verteilen und WebSocket-Verbindungen upgraden, ohne unnötige Protokollunterstützung zu laden. Unter Ubuntu und Debian werden Module mit a2enmod aktiviert. Anschließend sollte Apache neu gestartet oder neu geladen und überprüft werden, welche Proxy-Module tatsächlich aktiv sind, bevor VirtualHost-Regeln eingerichtet werden.

Die mod_proxy-Modulfamilie verstehen

Die Reverse-Proxy-Unterstützung von Apache befindet sich nicht in einem einzigen, unabhängigen Modul. Stattdessen arbeiten mehrere zusammengehörige Module zusammen, um verschiedene Protokolle, Kommunikationswege zu Backends und Proxy-Funktionen zu unterstützen. Durch diesen modularen Aufbau lässt sich Apache flexibel an unterschiedliche Webserver-Architekturen anpassen.

Die zentrale Komponente ist mod_proxy. Dieses Modul stellt das grundlegende Framework für Request-Weiterleitung, Verbindungsverwaltung und Proxy-Infrastruktur bereit. mod_proxy allein kann jedoch nicht jede Form von Anwendungstraffic verarbeiten. Die eigentliche Kommunikation zwischen Proxy und Backend-Diensten wird von protokollspezifischen Modulen übernommen.

Durch diese Trennung können nur die Komponenten aktiviert werden, die für eine konkrete Umgebung benötigt werden. Für einen einfachen HTTP-Reverse-Proxy reichen möglicherweise mod_proxy und mod_proxy_http aus. Werden dagegen WebSockets, PHP-FPM oder Load Balancing eingesetzt, können mehrere zusätzliche Module erforderlich sein.

Jedes Modul ergänzt das Apache-Proxy-Framework um eine bestimmte Funktion.

Das Kernmodul mod_proxy

Das Basismodul mod_proxy stellt die zentrale Proxy-Engine von Apache bereit. Es enthält die allgemeinen Mechanismen, die für die Weiterleitung von Anfragen zwischen Clients und Backend-Servern benötigt werden. Dazu gehören die Verwaltung von Proxy-Verbindungen, Routing, gemeinsam genutzte Direktiven, Worker-Definitionen und der Kommunikationsablauf zwischen Apache und den Backend-Systemen.

Das Kernmodul stellt außerdem wichtige Direktiven bereit, darunter:

• ProxyPass
• ProxyPassReverse
• ProxyRequests
• <Proxy>
• BalancerMember

Obwohl mod_proxy die gemeinsame Infrastruktur bereitstellt, verarbeitet das Modul normale HTTP-Proxy-Verbindungen nicht allein. Abhängig vom verwendeten Backend werden zusätzliche Protokoll-Handler benötigt.

mod_proxy_http

mod_proxy_http ist eines der am häufigsten eingesetzten Proxy-Untermodule. Es ermöglicht Apache, gewöhnlichen HTTP- und HTTPS-Datenverkehr an Anwendungsserver weiterzuleiten.

In typischen Reverse-Proxy-Umgebungen kann es unter anderem die Kommunikation zwischen Apache und folgenden Anwendungen übernehmen:

• Node.js-Anwendungen
• Python-Webframeworks
• Interne Apache- oder Nginx-Server
• Java-Anwendungsserver
• Containerisierte Webanwendungen

Wenn Apache beispielsweise Anfragen an eine Anwendung weiterleitet, die unter folgender Adresse lauscht:

http://127.0.0.1:3000

wird die Backend-Kommunikation über mod_proxy_http abgewickelt.

Das Modul unterstützt gewöhnliche HTTP-Anfragen und -Antworten, persistente Verbindungen zu Backends, Chunked Transfer Encoding, die Weiterleitung von Headern sowie die HTTP-Protokollverhandlung.

Eine häufig verwendete Konfiguration sieht beispielsweise so aus:

ProxyPass / http://127.0.0.1:3000/
ProxyPassReverse / http://127.0.0.1:3000/

Da die meisten modernen Webanwendungen HTTP oder HTTPS verwenden, ist mod_proxy_http normalerweise das erste protokollspezifische Proxy-Modul, das zusätzlich zum Kernmodul aktiviert wird.

mod_proxy_balancer

Mit mod_proxy_balancer erhält das Apache-Proxy-Framework Load-Balancing-Funktionen. Statt sämtliche Anfragen an einen einzigen Backend-Server zu senden, kann Apache den eingehenden Datenverkehr auf mehrere Backend-Knoten verteilen.

Diese Funktion ist insbesondere für Hochverfügbarkeitsumgebungen oder horizontal skalierte Architekturen sinnvoll, in denen mehrere Anwendungsinstanzen gleichzeitig Anfragen verarbeiten.

Apache unterstützt unterschiedliche Balancing-Verfahren, darunter:

• Verteilung anhand der Anfrageanzahl mit byrequests
• Verteilung anhand des Datenvolumens mit bytraffic
• Verteilung anhand ausstehender Anfragen mit bybusyness

Das Modul unterstützt außerdem Session-Persistenz, häufig als Sticky Sessions bezeichnet. Dadurch können aufeinanderfolgende Anfragen eines Clients weiterhin demselben Backend-Server zugeordnet werden.

Eine einfache Load-Balancing-Konfiguration kann folgendermaßen aussehen:

<Proxy "balancer://mycluster">
    BalancerMember http://10.0.0.11:8080
    BalancerMember http://10.0.0.12:8080
</Proxy>

ProxyPass / balancer://mycluster/

Intern arbeitet mod_proxy_balancer mit Protokollmodulen wie mod_proxy_http zusammen, da das Balancing-Modul selbst keine HTTP-Kommunikation implementiert.

mod_proxy_wstunnel

Viele moderne Anwendungen verwenden WebSockets für dauerhafte Echtzeitkommunikation. Das klassische HTTP-Proxy-Verhalten reicht nicht für jede WebSocket-Verbindung aus, weil die Verbindung nach dem Upgrade vom normalen HTTP-Anfrage-Antwort-Modell in eine dauerhaft bidirektionale Verbindung übergeht.

mod_proxy_wstunnel ermöglicht Apache, WebSocket-Verbindungen über die Protokolle ws:// und wss:// weiterzuleiten. Apache 2.4.47 und neuere Versionen können WebSocket-Upgrades mit entsprechenden Upgrade-Parametern auch über mod_proxy_http verarbeiten, mod_proxy_wstunnel wird jedoch weiterhin häufig eingesetzt.

Typische Einsatzbereiche für WebSockets sind:

• Echtzeit-Dashboards
• Chat-Anwendungen
• Live-Benachrichtigungssysteme
• Mehrspieler-Spielserver
• Streaming-Anwendungen

Fordert ein Client eine WebSocket-Verbindung an, erkennt Apache das Protokoll-Upgrade und tunnelt die dauerhafte Verbindung zur Backend-Anwendung.

Eine häufig verwendete WebSocket-Proxy-Konfiguration ist:

ProxyPass /socket ws://127.0.0.1:3000/socket
ProxyPassReverse /socket ws://127.0.0.1:3000/socket

Ohne geeignete Unterstützung für WebSocket-Proxying kann Apache Fehler beim Protokoll-Upgrade zurückgeben oder die WebSocket-Sitzung nicht dauerhaft offenhalten.

mod_proxy_fcgi

Mit mod_proxy_fcgi kann Apache mit FastCGI-Backend-Diensten kommunizieren. Das ist insbesondere bei PHP-Installationen relevant, die PHP-FPM anstelle des älteren eingebetteten Verarbeitungsmodells mit mod_php verwenden.

PHP-FPM wird auf modernen Linux-Systemen häufig eingesetzt, weil die PHP-Ausführung vom Apache-Prozess getrennt wird. Dadurch können Skalierbarkeit, Ressourcenisolierung und betriebliche Flexibilität verbessert werden.

Statt HTTP-Anfragen weiterzuleiten, sendet mod_proxy_fcgi FastCGI-Anfragen an entsprechende FastCGI-Worker.

Eine typische Integration mit PHP-FPM sieht so aus:

<FilesMatch \.php$>
    SetHandler "proxy:unix:/run/php/php8.3-fpm.sock|fcgi://localhost/"
</FilesMatch>

Diese Konfiguration weist Apache an, PHP-Anfragen über einen Unix-Socket an den PHP-FPM-Dienst zu senden.

mod_proxy_fcgi wird zwar normalerweise nicht für klassisches HTTP-Reverse-Proxying eingesetzt, gehört jedoch zur erweiterten mod_proxy-Familie und wird häufig in Apache-basierten PHP-Umgebungen verwendet.

Häufig verwendete mod_proxy-Untermodule im Vergleich

Die folgende Tabelle zeigt die wichtigsten Apache-Proxy-Module und ihre typischen Einsatzbereiche:

Bei vielen aktuellen Ubuntu-Reverse-Proxy-Installationen werden mindestens die folgenden Module benötigt:

mod_proxy
mod_proxy_http
mod_headers

Weitere Module können entsprechend den Anforderungen der Anwendung und der eingesetzten Architektur aktiviert werden.

Schritt 1: Apache installieren und die Verfügbarkeit von mod_proxy prüfen

Bevor Apache als Reverse Proxy konfiguriert werden kann, muss der Apache HTTP Server installiert und überprüft werden, ob die benötigten Proxy-Module verfügbar sind. Unter Ubuntu ist die Modulfamilie mod_proxy im normalen Apache-Paket enthalten, einzelne Module sind jedoch möglicherweise nicht automatisch aktiviert.

Apache unter Ubuntu installieren

Ubuntu stellt den Apache HTTP Server über das Paket apache2 bereit. Aktualisiere zunächst den Paketindex:

sudo apt update

Installiere anschließend Apache:

sudo apt install apache2

Nach der Installation startet Ubuntu den Apache-Dienst normalerweise automatisch und richtet ihn so ein, dass er auch beim Systemstart geladen wird.

Überprüfe den Status des Dienstes mit:

sudo systemctl status apache2

Wenn Apache erfolgreich gestartet wurde, sollte die Ausgabe ungefähr so aussehen:

● apache2.service - The Apache HTTP Server
     Loaded: loaded (/usr/lib/systemd/system/apache2.service; enabled; preset: enabled)
     Active: active (running) since Tue 2026-05-19 06:59:03 UTC; 16s ago
       Docs: https://httpd.apache.org/docs/2.4/
   Main PID: 3083 (apache2)
      Tasks: 55 (limit: 2318)
     Memory: 5.1M (peak: 5.3M)
        CPU: 51ms
     CGroup: /system.slice/apache2.service
             ├─3083 /usr/sbin/apache2 -k start
             ├─3086 /usr/sbin/apache2 -k start
             └─3087 /usr/sbin/apache2 -k start

Mit curl kannst du zusätzlich prüfen, ob Apache lokal antwortet:

curl http://localhost

Wenn Apache korrekt funktioniert, liefert der Befehl die standardmäßige Apache-HTML-Seite zurück.

Apache-Module unter Ubuntu verstehen

Apache ist modular aufgebaut. Funktionen werden über einzelne Module bereitgestellt und nicht vollständig in eine einzige große Server-Binärdatei integriert. Die Reverse-Proxy-Funktionalität wird über die mod_proxy-Familie bereitgestellt, die verschiedene Module für unterschiedliche Proxy-Protokolle und Funktionen enthält.

Unter Ubuntu werden Apache-Module hauptsächlich über zwei Verzeichnisse verwaltet:

/etc/apache2/mods-available/

Dieses Verzeichnis enthält die auf dem System installierten Moduldefinitionen.

Aktivierte Module werden in folgendes Verzeichnis verknüpft:

/etc/apache2/mods-enabled/

Durch diese Verzeichnisstruktur können Administratoren Apache-Funktionen aktivieren und deaktivieren, ohne die zentrale Serverkonfiguration manuell bearbeiten zu müssen.

Die meisten Proxy-Module stehen als dynamisch ladbare Shared Modules zur Verfügung. Dadurch können sie deaktiviert bleiben, solange sie nicht benötigt werden, und unnötige Funktionen müssen nicht im aktiven Apache-Prozess geladen werden.

Verfügbare Proxy-Module überprüfen

Bevor Reverse-Proxy-Funktionen aktiviert werden, solltest du prüfen, ob die benötigten Proxy-Module installiert sind.

Zeige die verfügbaren Proxy-bezogenen Module mit folgendem Befehl an:

ls /etc/apache2/mods-available/ | grep proxy

Die Ausgabe sollte Einträge enthalten, die diesen ähnlich sind:

proxy.conf
proxy.load
proxy_http.load
proxy_balancer.load
proxy_wstunnel.load
proxy_fcgi.load

Damit wird bestätigt, dass die entsprechenden Moduldateien vorhanden sind und aktiviert werden können.

Jede Datei gehört zu einem bestimmten Bereich des Apache-Proxy-Frameworks:

• proxy.load lädt das zentrale mod_proxy-Framework.
• proxy_http.load aktiviert Proxy-Verbindungen über HTTP und HTTPS.
• proxy_balancer.load stellt Load-Balancing-Funktionen bereit.
• proxy_wstunnel.load ermöglicht WebSocket-Proxy-Verbindungen.
• proxy_fcgi.load stellt FastCGI-Backend-Unterstützung einschließlich PHP-FPM bereit.

Nicht jede Installation benötigt sämtliche Module. Die Prüfung ihrer Verfügbarkeit zeigt jedoch, dass der Server die später verwendeten Konfigurationsschritte grundsätzlich unterstützen kann.

Prüfen, welche Module aktuell geladen sind

Ein Modul kann auf dem Datenträger vorhanden sein, ohne in der aktiven Apache-Konfiguration aktiviert zu sein.

Zeige alle geladenen Module mit folgendem Befehl an:

apache2ctl -M

Wenn nur Proxy-Module angezeigt werden sollen, verwende:

apache2ctl -M | grep proxy

Wenn bereits Proxy-Module aktiviert wurden, kann die Ausgabe beispielsweise so aussehen:

proxy_module (shared)
proxy_http_module (shared)

Werden keine Proxy-Module angezeigt, sind sie noch nicht aktiviert. Im nächsten Schritt werden die erforderlichen Module eingeschaltet.

Apache-Konfigurationssyntax prüfen

Bevor Apache-Konfigurationsdateien geändert werden, sollte geprüft werden, ob die aktuelle Konfiguration syntaktisch gültig ist.

Führe dazu folgenden Befehl aus:

sudo apache2ctl configtest

Wenn Apache keine Syntaxprobleme findet, erscheint:

Syntax OK

Es ist sinnvoll, configtest sowohl vor als auch nach Änderungen an der Konfiguration auszuführen, weil Apache eine ungültige Konfiguration nicht neu laden kann. Eine frühzeitige Syntaxprüfung reduziert vermeidbare Ausfallzeiten und erleichtert die Fehlersuche.

Schritt 2: mod_proxy und benötigte Untermodule aktivieren

Nachdem geprüft wurde, dass die Proxy-Module verfügbar sind, können die für den Reverse-Proxy-Betrieb benötigten Komponenten aktiviert werden. Unter Ubuntu werden Apache-Module normalerweise mit a2enmod verwaltet. Dieses Werkzeug erstellt symbolische Links von mods-available nach mods-enabled.

Da Apache Proxy-Funktionen auf mehrere Module verteilt, reicht es normalerweise nicht aus, nur das zentrale Modul mod_proxy einzuschalten. Zusätzlich müssen protokollspezifische Module aktiviert werden, damit Apache mit den jeweiligen Backend-Systemen kommunizieren kann.

Für einen normalen HTTP-Reverse-Proxy werden mindestens folgende Module benötigt:

• mod_proxy
• mod_proxy_http

Abhängig von der Umgebung können weitere Module für Load Balancing, WebSockets, SSL-Proxying oder die Bearbeitung von HTTP-Headern erforderlich sein.

Die zentralen Proxy-Module aktivieren

Aktiviere das grundlegende Proxy-Framework und das HTTP-Proxy-Modul:

sudo a2enmod proxy
sudo a2enmod proxy_http

Das Modul proxy stellt die grundlegende Proxy-Infrastruktur bereit. proxy_http ermöglicht Apache dagegen, HTTP- und HTTPS-Anfragen an Anwendungsserver weiterzuleiten.

Nach Ausführung der Befehle werden symbolische Links für die aktivierten Modulkonfigurationen unter folgendem Pfad erstellt:

/etc/apache2/mods-enabled/

Prüfe, ob die Links vorhanden sind:

ls /etc/apache2/mods-enabled/ | grep proxy

Das Verzeichnis sollte jetzt Einträge enthalten, die diesen ähnlich sind:

proxy.conf
proxy.load
proxy_http.load

Weitere häufig verwendete Proxy-Module aktivieren

Viele Reverse-Proxy-Konfigurationen benötigen zusätzliche Apache-Module über die grundlegenden HTTP-Proxy-Komponenten hinaus.

mod_headers wird beispielsweise häufig verwendet, um Informationen über Clients weiterzugeben und Request-Header zu bearbeiten:

sudo a2enmod headers

Wenn Load Balancing eingesetzt werden soll, aktiviere das Balancing-Framework und die anfragebasierte Verteilung:

sudo a2enmod proxy_balancer
sudo a2enmod lbmethod_byrequests

proxy_balancer stellt das Balancing-Framework bereit, während lbmethod_byrequests den Apache-Algorithmus zur Verteilung anhand der Anzahl eingehender Anfragen aktiviert.

Für WebSocket-Unterstützung aktiviere:

sudo a2enmod proxy_wstunnel

Wenn Apache SSL-/TLS-Verbindungen terminieren oder mit HTTPS-Backends kommunizieren soll, aktiviere zusätzlich das SSL-Modul:

sudo a2enmod ssl

Module, die später ohnehin benötigt werden, bereits an dieser Stelle zu aktivieren, kann die folgenden Konfigurationsschritte vereinfachen, insbesondere in Testumgebungen.

Was a2enmod tatsächlich macht

Das Werkzeug a2enmod schreibt die zentrale Apache-Konfigurationsdatei nicht direkt um. Stattdessen aktiviert es Module, indem unter mods-enabled symbolische Links auf die entsprechenden Dateien in mods-available erstellt werden.

Wird beispielsweise mod_proxy aktiviert, entstehen Links wie:

/etc/apache2/mods-enabled/proxy.load
/etc/apache2/mods-enabled/proxy.conf

Dieser modulare Aufbau erleichtert die Apache-Verwaltung, weil einzelne Funktionen unabhängig voneinander aktiviert und deaktiviert werden können, ohne eine einzige umfangreiche Konfigurationsdatei manuell pflegen zu müssen.

Ein Modul kann später mit a2dismod deaktiviert werden:

sudo a2dismod proxy_wstunnel

Deaktiviere kein Modul, das noch in aktiven VirtualHost-Konfigurationen verwendet wird. Andernfalls kann Apache möglicherweise nicht mehr starten, weil benötigte Direktiven nicht verfügbar sind.

Geladene Module überprüfen

Nachdem die benötigten Module aktiviert wurden, solltest du kontrollieren, ob Apache sie erfolgreich lädt.

Führe dazu aus:

apache2ctl -M | grep proxy

Die Ausgabe sollte ungefähr so aussehen:

proxy_module (shared)
proxy_http_module (shared)
proxy_balancer_module (shared)
proxy_wstunnel_module (shared)

Überprüfe ebenfalls das Header-Modul:

apache2ctl -M | grep headers

Die erwartete Ausgabe lautet:

headers_module (shared)

Die Überprüfung der geladenen Module verhindert spätere Fehler, wenn Apache auf Direktiven trifft, deren zugehörige Module nicht aktiviert wurden.

Apache nach dem Aktivieren der Module neu starten

Starte Apache neu, nachdem neue Module aktiviert wurden, damit diese verfügbar werden:

sudo systemctl restart apache2

Kontrolliere anschließend, ob Apache erfolgreich neu gestartet wurde:

sudo systemctl status apache2

Wenn beim Start ein Konfigurations- oder Modulproblem auftritt, enthält der Dienststatus normalerweise eine kurze Erklärung. Ausführlichere Informationen werden in folgende Datei geschrieben:

/var/log/apache2/error.log

Prüfe vor dem Fortfahren erneut die Konfiguration:

sudo apache2ctl configtest

Bei einer gültigen Konfiguration gibt Apache Folgendes zurück:

Syntax OK

Apache ist jetzt für die Einrichtung als Reverse Proxy vorbereitet.

Schritt 3: Einen einfachen Reverse Proxy mit ProxyPass konfigurieren

Nachdem die erforderlichen Module aktiviert wurden, kann Apache als Reverse Proxy konfiguriert werden. In einer einfachen Konfiguration nimmt Apache Client-Anfragen entgegen und leitet sie an einen Anwendungsserver weiter, der entweder lokal oder auf einem anderen System im internen Netzwerk läuft.

Die wichtigsten Direktiven für dieses Verhalten sind ProxyPass und ProxyPassReverse.

In diesem Beispiel nimmt Apache öffentliche Anfragen auf Port 80 an und leitet sie an eine Backend-Anwendung unter folgender Adresse weiter:

http://127.0.0.1:3000

Dieses Konfigurationsmuster wird häufig für Anwendungen auf Basis von Node.js, Django, Flask, Express, Spring Boot und ähnlichen Frameworks verwendet, bei denen der Anwendungsserver selbst nicht direkt aus dem öffentlichen Internet erreichbar sein soll.

Den Request-Ablauf eines Reverse Proxys verstehen

Vor der eigentlichen Konfiguration ist es hilfreich zu verstehen, wie der Datenverkehr die Frontend-Schicht durchläuft.

Bei einem Reverse Proxy läuft eine Anfrage folgendermaßen ab:

1. Ein Client sendet eine Anfrage an Apache.
2. Apache nimmt die Anfrage stellvertretend für die Backend-Anwendung entgegen.
3. Apache leitet die Anfrage intern an den Backend-Server weiter.
4. Die Backend-Anwendung verarbeitet die Anfrage und erzeugt eine Antwort.
5. Apache sendet diese Antwort an den Client zurück.

Der Client stellt dabei keine direkte Verbindung zum Backend-Anwendungsserver her.

Dadurch kann Apache als stabile öffentlich erreichbare Schicht dienen, während die Backend-Dienste von einem direkten Zugriff aus dem Internet getrennt bleiben.

Forward Proxying deaktivieren

Eine der wichtigsten Sicherheitsanforderungen bei einem Reverse Proxy besteht darin, sicherzustellen, dass die Forward-Proxy-Funktion deaktiviert bleibt.

Apache kann grundsätzlich als:

• Reverse Proxy
• Forward Proxy

arbeiten. Ein Forward Proxy nimmt Anfragen von Clients entgegen und ruft beliebige externe Ressourcen für diese Clients ab. Sofern dieses Verhalten nicht ausdrücklich benötigt wird, sollte es deaktiviert bleiben, da ein uneingeschränkt zugänglicher Forward Proxy von Dritten missbraucht werden kann.

Um sicherzustellen, dass Apache ausschließlich als Reverse Proxy arbeitet, verwende:

ProxyRequests Off

Diese Direktive kann innerhalb des betreffenden VirtualHost oder in einer geeigneten Proxy-Konfigurationsdatei eingetragen werden.

Aktiviere ProxyRequests nicht, sofern nicht ausdrücklich ein kontrollierter Forward Proxy eingerichtet werden soll.

ProxyPass verstehen

Die Direktive ProxyPass teilt Apache mit, dass Anfragen für einen bestimmten Frontend-URL-Pfad an einen Backend-Server weitergeleitet werden sollen.

Die allgemeine Syntax lautet:

ProxyPass <frontend-path> <backend-url>

Zum Beispiel:

ProxyPass / http://127.0.0.1:3000/

Damit werden alle Anfragen unterhalb von / an die Anwendung auf Port 3000 weitergegeben.

Ruft ein Client beispielsweise folgende Adresse auf:

http://your-server-ip/about

leitet Apache die Anfrage intern an folgende Adresse weiter:

http://127.0.0.1:3000/about

Das Backend verarbeitet die Anfrage regulär, und Apache übermittelt die erzeugte Antwort anschließend an den Client.

Abschließende Schrägstriche in ProxyPass-Zuordnungen sind relevant, weil sie beeinflussen, wie Frontend- und Backend-Pfade zusammengesetzt werden. Uneinheitlich gesetzte Schrägstriche können deshalb zu unerwarteten URL-Zuordnungen führen.

ProxyPassReverse verstehen

ProxyPassReverse verändert bestimmte Antwort-Header, die vom Backend zurückgegeben werden, bevor Apache sie an den Client sendet.

Das ist erforderlich, weil Backend-Anwendungen Weiterleitungen oder Antwort-Header erzeugen können, die interne URLs statt der öffentlich erreichbaren Proxy-Adresse enthalten.

Ein Backend könnte beispielsweise folgende Antwort zurückgeben:

Location: http://127.0.0.1:3000/login

Ohne ProxyPassReverse könnte diese interne Backend-Adresse direkt an den Client gesendet werden. Das kann Routing-Probleme verursachen und gleichzeitig interne Infrastrukturinformationen offenlegen.

Füge deshalb hinzu:

ProxyPassReverse / http://127.0.0.1:3000/

Apache kann dadurch passende, vom Backend erzeugte Antwort-Header so umschreiben, dass Clients weiterhin die öffentlich erreichbare Proxy-Adresse verwenden.

Aus diesem Grund werden ProxyPass und ProxyPassReverse normalerweise gemeinsam konfiguriert.

Einen einfachen Reverse-Proxy-VirtualHost erstellen

Apache verwendet VirtualHost-Blöcke, um eingehenden Datenverkehr zuzuordnen. Unter Ubuntu werden Website-Konfigurationen normalerweise in folgendem Verzeichnis gespeichert:

/etc/apache2/sites-available/

Erstelle eine neue Konfigurationsdatei:

sudo nano /etc/apache2/sites-available/reverse-proxy.conf

Füge folgende Konfiguration ein:

<VirtualHost *:80>
    ServerName example.com

    ProxyRequests Off

    ProxyPreserveHost On

    ProxyPass / http://127.0.0.1:3000/
    ProxyPassReverse / http://127.0.0.1:3000/

    ErrorLog ${APACHE_LOG_DIR}/reverse-proxy-error.log
    CustomLog ${APACHE_LOG_DIR}/reverse-proxy-access.log combined
</VirtualHost>

Diese Konfiguration übernimmt mehrere Aufgaben:

• Apache nimmt HTTP-Anfragen auf Port 80 entgegen.
• Die Forward-Proxy-Funktion bleibt deaktiviert.
• Eingehender Datenverkehr wird an die Backend-Anwendung weitergeleitet.
• Vom Backend erzeugte Weiterleitungen werden passend umgeschrieben.
• Für die Fehlersuche werden separate Zugriffs- und Fehlerprotokolle geführt.

Mit ProxyPreserveHost On leitet Apache den ursprünglichen Host-Header des Clients an das Backend weiter, statt ihn durch den Hostnamen des Backends zu ersetzen. Viele Anwendungen benötigen den ursprünglichen Hostwert für Routing, Weiterleitungen, Multi-Tenant-Konfigurationen oder Framework-Funktionen.

Die VirtualHost-Konfiguration aktivieren

Aktiviere nach dem Speichern der Konfiguration die neue Website:

sudo a2ensite reverse-proxy.conf

Falls die standardmäßige Apache-Website noch aktiv ist, kann sie optional deaktiviert werden, um mögliche Konflikte zu vermeiden:

sudo a2dissite 000-default.conf

Prüfe die Konfiguration, bevor Apache neu gestartet wird:

sudo apache2ctl configtest

Eine gültige Konfiguration liefert:

Syntax OK

Starte Apache neu:

sudo systemctl restart apache2

Den Reverse Proxy testen

Nachdem Apache neu gestartet wurde, kannst du die Konfiguration über folgende Adresse testen:

http://your-server-ip

oder:

http://your-domain.com

Wenn die Backend-Anwendung läuft, sollte ihr Inhalt über Apache ausgeliefert werden, anstatt direkt über den Backend-Port aufgerufen zu werden.

Der Proxy kann auch mit folgendem Befehl getestet werden:

curl -I http://your-server-ip

Die zurückgegebenen Header sollten erkennen lassen, dass Apache die Frontend-Anfrage verarbeitet hat, während der eigentliche Inhalt von der Backend-Anwendung bereitgestellt wurde.

Apache arbeitet jetzt als einfacher Reverse Proxy.

Schritt 4: Client-Informationen mit Proxy-Headern weiterleiten

In einer Reverse-Proxy-Architektur kommunizieren Backend-Anwendungen nicht direkt mit den Clients. Stattdessen erreichen Anfragen zuerst Apache und werden danach intern an den Anwendungsserver weitergegeben. Deshalb kann das Backend den Proxy-Server selbst als Quelle jeder Anfrage sehen, wenn Apache keine Informationen über den ursprünglichen Client über HTTP-Header weitergibt.

Werden diese Header nicht korrekt verarbeitet, können Backend-Anwendungen falsche Client-IP-Adressen protokollieren, fehlerhafte Weiterleitungen erzeugen, HTTPS-Verbindungen nicht erkennen oder Sicherheitsrichtlinien auf einer falschen Grundlage anwenden.

Apache kann wichtige Informationen der ursprünglichen Anfrage beibehalten, darunter:

• Die IP-Adresse des Clients
• Den vom Client angeforderten Hostnamen
• Das ursprüngliche Protokoll, also HTTP oder HTTPS
• Benutzerdefinierte Metadaten-Header

Diese Informationen werden üblicherweise als Proxy-Header oder Forwarded Headers bezeichnet.

Warum weitergeleitete Header wichtig sind

Eine typische Reverse-Proxy-Anfrage folgt diesem Pfad:

Client ---> Apache Reverse Proxy ---> Backend Application

Aus Sicht der Backend-Anwendung stammt die TCP-Verbindung von Apache und nicht direkt vom Browser des Benutzers. Ohne weitergeleitete Informationen kann das Backend daher fälschlicherweise:

• die IP-Adresse des Apache-Servers als Client-Adresse interpretieren,
• einen internen Hostnamen für den öffentlichen Hostnamen halten,
• HTTP als ursprüngliches Verbindungsprotokoll erkennen, obwohl der Benutzer HTTPS verwendet hat.

Das kann in Produktionsumgebungen zu mehreren Problemen führen.

Beispielsweise:

• können Anwendungsprotokolle nur die Adresse des Proxy-Servers enthalten,
• können Rate-Limiting-Mechanismen fehlschlagen, weil alle Anfragen scheinbar von einem einzigen System stammen,
• kann die Authentifizierungslogik den Ursprung einer Anfrage falsch bestimmen,
• können Weiterleitungen auf interne Adressen verweisen,
• können sichere Cookies fehlschlagen, wenn die Anwendung die ursprüngliche HTTPS-Verbindung nicht erkennt.

Forwarded Headers bewahren den Kontext der ursprünglichen Anfrage und ermöglichen Backend-Anwendungen ein korrektes Verhalten hinter dem Proxy.

Den ursprünglichen Host-Header beibehalten

Beim Proxying kann Apache den eingehenden Host-Header durch den Hostnamen des Backends ersetzen. Manche Anwendungen benötigen jedoch den öffentlichen Host-Wert für Domain-Routing, Multi-Tenant-Logik, Konfigurationen oder die Erzeugung von URLs.

Um den vom Client ursprünglich angeforderten Hostnamen beizubehalten, verwende:

ProxyPreserveHost On

Wenn ein Client beispielsweise folgende Adresse aufruft:

https://app.example.com

kann Apache diesen ursprünglichen Hostwert weitergeben, anstatt die interne Backend-Adresse zu verwenden:

127.0.0.1:3000

Das ist besonders wichtig für:

• Anwendungen mit Virtual-Host-Routing
• Frameworks, die absolute URLs erzeugen
• Installationen mit mehreren Domains
• OAuth- und Authentifizierungs-Callbacks
• Anwendungen hinter HTTPS-Proxys

Bei vielen modernen Reverse-Proxy-Konfigurationen ist ProxyPreserveHost On sinnvoll, sofern die Backend-Anwendung nicht ausdrücklich einen anderen Hostwert erwartet.

Die ursprüngliche Client-IP-Adresse weiterleiten

X-Forwarded-For gehört zu den am häufigsten verwendeten Proxy-Headern.

Dieser Header enthält die ursprüngliche IP-Adresse des Clients. Dadurch können Backend-Anwendungen die tatsächliche Quelle einer Anfrage vom Proxy-Server unterscheiden.

Apache kann Weiterleitungs-Header automatisch hinzufügen mit:

ProxyAddHeaders On

Diese Einstellung ist in vielen Apache-Konfigurationen standardmäßig bereits aktiviert. Eine explizite Angabe macht das gewünschte Verhalten jedoch deutlicher.

Apache kann anschließend beispielsweise folgende Header ergänzen:

X-Forwarded-For: 203.0.113.25
X-Forwarded-Host: app.example.com
X-Forwarded-Server: proxy-server

Das Backend kann X-Forwarded-For auswerten, um die ursprüngliche Client-Adresse zu bestimmen.

Läuft der Datenverkehr durch mehrere Proxys oder Content-Delivery-Schichten, kann dieser Header eine durch Kommas getrennte Liste von Adressen enthalten, die die einzelnen Proxy-Stationen abbildet.

HTTPS- und Protokollinformationen weiterleiten

Backend-Anwendungen müssen häufig erkennen können, ob der Benutzer ursprünglich über HTTP oder HTTPS verbunden war.

Diese Information beeinflusst unter anderem:

• Sichere Cookies
• Die Erzeugung von Weiterleitungen
• Authentifizierung
• CSRF-Schutz
• Die Erzeugung von URLs

Wenn Apache HTTPS terminiert und anschließend per HTTP mit dem Backend kommuniziert, sieht das Backend lediglich die interne HTTP-Verbindung, sofern das ursprüngliche Protokoll nicht separat weitergegeben wird.

Eine häufig verwendete Lösung besteht darin, X-Forwarded-Proto zu setzen:

RequestHeader set X-Forwarded-Proto "https"

Dadurch erfährt die Anwendung, dass der öffentliche Client die Verbindung über HTTPS aufgebaut hat, auch wenn die interne Proxy-Verbindung HTTP verwendet.

Der Wert kann auch dynamisch ermittelt werden:

RequestHeader set X-Forwarded-Proto expr=%{REQUEST_SCHEME}

Damit wird abhängig vom Protokoll der eingehenden Anfrage automatisch entweder http oder https weitergegeben.

Da die Direktive RequestHeader zu mod_headers gehört, muss dieses Modul aktiviert sein:

sudo a2enmod headers

Benutzerdefinierte Proxy-Header setzen

Apache unterstützt außerdem benutzerdefinierte Header, die an Backend-Dienste weitergegeben werden können.

Zum Beispiel:

RequestHeader set X-Proxy-Server "Apache-Reverse-Proxy"

Benutzerdefinierte Request-Header können beispielsweise für folgende Zwecke verwendet werden:

• Identifikation interner Dienste
• Debugging und Tracing von Anfragen
• Anwendungsspezifisches Routing
• Integration mit API-Gateways
• Sicherheitsmetadaten

Header können bei Bedarf auch entfernt werden:

RequestHeader unset X-Unwanted-Header

Damit lässt sich detailliert kontrollieren, welche Request-Informationen an Backend-Anwendungen weitergegeben werden.

Vollständiges VirtualHost-Beispiel mit Forwarded Headers

Das folgende Beispiel kombiniert mehrere häufig verwendete Reverse-Proxy-Einstellungen für Header:

<VirtualHost *:80>
    ServerName example.com

    ProxyRequests Off
    ProxyPreserveHost On
    ProxyAddHeaders On

    ProxyPass / http://127.0.0.1:3000/
    ProxyPassReverse / http://127.0.0.1:3000/

    RequestHeader set X-Forwarded-Proto expr=%{REQUEST_SCHEME}

    ErrorLog ${APACHE_LOG_DIR}/reverse-proxy-error.log
    CustomLog ${APACHE_LOG_DIR}/reverse-proxy-access.log combined
</VirtualHost>

Damit erhält die Backend-Anwendung:

• den ursprünglich vom Client angeforderten Hostnamen,
• die ursprüngliche Client-IP-Adresse,
• das ursprüngliche Request-Protokoll,
• korrekt umgeschriebene Informationen bei Weiterleitungen.

Gemeinsam sorgen diese Einstellungen dafür, dass Anwendungen den erforderlichen Client-Kontext behalten, obwohl sie hinter Apache betrieben werden.

Konfigurationsänderungen anwenden

Prüfe nach Änderungen am VirtualHost zunächst die Apache-Konfiguration:

sudo apache2ctl configtest

Wenn die Syntax gültig ist, lade Apache neu:

sudo systemctl reload apache2

Ein Reload übernimmt die aktualisierte Konfiguration, ohne den Webserver vollständig neu zu starten.

Forwarded Headers überprüfen

Weitergeleitete Header können über die Backend-Anwendung selbst oder über einen Diagnose-Endpunkt überprüft werden, der die empfangenen Header anzeigt.

Viele Anwendungsframeworks stellen eingehende Request-Header direkt zur Verfügung. Alternativ kann vorübergehend ein einfaches Backend verwendet werden, das die empfangenen Header zurückgibt, um zu prüfen, ob Apache die erwarteten Informationen korrekt weiterleitet.

Eine korrekt weitergeleitete Anfrage kann beispielsweise folgende Header enthalten:

X-Forwarded-For: 203.0.113.25
X-Forwarded-Host: example.com
X-Forwarded-Proto: https

Der Reverse Proxy bewahrt damit den ursprünglichen Request-Kontext für die Backend-Anwendung.

Schritt 5: Load Balancing mit mod_proxy_balancer konfigurieren

Apache kann eingehenden Datenverkehr mit mod_proxy_balancer auf mehrere Backend-Server verteilen. Dadurch lassen sich Skalierbarkeit und Verfügbarkeit verbessern, während gleichzeitig verhindert wird, dass eine einzelne Anwendungsinstanz sämtliche Anfragen verarbeiten muss.

In einer Load-Balancing-Architektur befindet sich Apache vor mehreren Backend-Anwendungsinstanzen und wählt das Ziel einer Anfrage anhand eines konfigurierten Balancing-Algorithmus aus.

Load-Balancing-Module aktivieren

Aktiviere die erforderlichen Module, bevor ein Balancer eingerichtet wird:

sudo a2enmod proxy_balancer
sudo a2enmod lbmethod_byrequests

proxy_balancer stellt das zentrale Balancing-Framework bereit. lbmethod_byrequests ergänzt dagegen die Verteilung anhand der Anzahl von Anfragen.

Lade Apache neu:

sudo systemctl reload apache2

Backend-Server mit BalancerMember definieren

Apache fasst Backend-Systeme mithilfe eines <Proxy>-Blocks zu einem logischen Pool zusammen. Einzelne Server werden mit BalancerMember registriert.

Zum Beispiel:

<Proxy "balancer://mycluster">
    BalancerMember http://127.0.0.1:3001
    BalancerMember http://127.0.0.1:3002
</Proxy>

In diesem Beispiel bezeichnet balancer://mycluster den Backend-Pool. Jeder Eintrag mit BalancerMember steht für einen einzelnen Anwendungsserver.

Apache kann eingehende Anfragen anschließend automatisch auf diese Mitglieder verteilen.

Die Load-Balancing-Methode konfigurieren

Apache unterstützt mehrere Balancing-Algorithmen. Zu den häufig verwendeten Optionen gehören:

Für viele Umgebungen bietet byrequests eine einfache und praktikable Balancing-Strategie.

Die Methode kann über ProxySet konfiguriert werden:

ProxySet lbmethod=byrequests

Sticky Sessions konfigurieren

Manche Anwendungen speichern Sitzungsinformationen lokal auf einem einzelnen Backend-Server. In einer solchen Umgebung müssen wiederholte Anfragen desselben Clients weiterhin denselben Knoten erreichen. Dieses Verhalten wird als Session Persistence oder Sticky Sessions bezeichnet.

Apache unterstützt dies über die Einstellung stickysession.

Zum Beispiel:

<Proxy "balancer://mycluster">
    BalancerMember http://127.0.0.1:3001 route=node1
    BalancerMember http://127.0.0.1:3002 route=node2

    ProxySet lbmethod=byrequests stickysession=ROUTEID
</Proxy>

Jedes Backend erhält dabei eine eigene Route-Kennung. Die Anwendung muss anschließend ein Cookie mit dem dazugehörigen Route-Wert setzen, damit Apache weitere Anfragen dieses Clients weiterhin an den passenden Server senden kann.

Sticky Sessions sind besonders relevant, wenn Sitzungsdaten nicht in einem gemeinsam genutzten System gespeichert werden, auf das alle Backend-Knoten zugreifen können.

Vollständiges Beispiel für eine Load-Balancer-Konfiguration

Die folgende Konfiguration verwendet Apache als Reverse-Proxy-Load-Balancer für zwei Backend-Anwendungen:

<VirtualHost *:80>
    ServerName example.com

    ProxyRequests Off
    ProxyPreserveHost On

    <Proxy "balancer://mycluster">
        BalancerMember http://127.0.0.1:3001
        BalancerMember http://127.0.0.1:3002

        ProxySet lbmethod=byrequests
    </Proxy>

    ProxyPass / balancer://mycluster/
    ProxyPassReverse / balancer://mycluster/

    ErrorLog ${APACHE_LOG_DIR}/balancer-error.log
    CustomLog ${APACHE_LOG_DIR}/balancer-access.log combined
</VirtualHost>

Apache nimmt Anfragen auf Port 80 entgegen und verteilt sie auf die beiden Anwendungsserver.

Den Load Balancer testen

Prüfe nach dem Speichern der Konfiguration zunächst die Apache-Syntax:

sudo apache2ctl configtest

Wenn die Konfiguration gültig ist, lade Apache neu:

sudo systemctl reload apache2

Sende anschließend mehrere Anfragen an den Proxy:

curl http://your-server-ip

Wenn die Backend-Anwendungen voneinander unterscheidbare Antworten zurückgeben, sollten wiederholte Anfragen zeigen, dass Apache den Datenverkehr zwischen den Servern verteilt.

Apache kann eingehende Anfragen jetzt mit mod_proxy_balancer auf mehrere Backends verteilen.

Schritt 6: SSL-Terminierung auf der Proxy-Ebene aktivieren

In vielen Produktionsumgebungen verarbeitet Apache HTTPS direkt am Reverse Proxy, anstatt jeden Backend-Anwendungsserver mit einer eigenen SSL-/TLS-Konfiguration auszustatten. Dieses Konzept wird üblicherweise als SSL-Terminierung oder TLS-Offloading bezeichnet.

Der Client baut dabei eine verschlüsselte HTTPS-Verbindung zu Apache auf. Apache entschlüsselt den eingehenden Datenverkehr und leitet die Anfragen anschließend intern über HTTP oder HTTPS weiter.

Die zentrale Verwaltung von TLS auf Proxy-Ebene reduziert doppelte Konfigurationen, vereinfacht die Zertifikatsverwaltung und ermöglicht eine einheitliche Durchsetzung von HTTPS-Richtlinien.

Das SSL-Modul aktivieren

Bevor ein HTTPS-VirtualHost erstellt wird, muss das SSL-Modul von Apache aktiviert werden:

sudo a2enmod ssl

Lade Apache anschließend neu:

sudo systemctl reload apache2

Ein SSL-Zertifikat bereitstellen

Für HTTPS werden ein gültiges SSL-Zertifikat und der dazugehörige private Schlüssel benötigt. Für lokale Entwicklungs- oder Testumgebungen kann ein selbstsigniertes Zertifikat verwendet werden.

In Produktionsumgebungen werden normalerweise Zertifikate eingesetzt, die von Let’s Encrypt oder einer anderen vertrauenswürdigen Zertifizierungsstelle ausgestellt wurden.

Ubuntu-Installationen speichern Zertifikate häufig in Verzeichnissen wie:

/etc/ssl/certs/

Private Schlüssel befinden sich üblicherweise unter:

/etc/ssl/private/

Bei Verwendung von Let’s Encrypt und Certbot liegen die Zertifikatsdateien normalerweise unter /etc/letsencrypt/live/your-domain/.

HTTPS-Reverse-Proxying konfigurieren

Erstelle oder bearbeite die HTTPS-Website-Konfiguration:

sudo nano /etc/apache2/sites-available/reverse-proxy-ssl.conf

Füge eine Konfiguration nach folgendem Muster ein:

<VirtualHost *:443>
    ServerName example.com

    SSLEngine On
    SSLCertificateFile /etc/ssl/certs/example.com.crt
    SSLCertificateKeyFile /etc/ssl/private/example.com.key

    ProxyRequests Off
    ProxyPreserveHost On
    ProxyAddHeaders On

    ProxyPass / http://127.0.0.1:3000/
    ProxyPassReverse / http://127.0.0.1:3000/

    RequestHeader set X-Forwarded-Proto "https"

    ErrorLog ${APACHE_LOG_DIR}/ssl-proxy-error.log
    CustomLog ${APACHE_LOG_DIR}/ssl-proxy-access.log combined
</VirtualHost>

Mit dieser Konfiguration nimmt Apache HTTPS-Verbindungen auf Port 443 an, entschlüsselt sie und leitet die Anfragen an die Anwendung auf Port 3000 weiter.

X-Forwarded-Proto informiert die Backend-Anwendung darüber, dass die ursprüngliche Client-Anfrage über HTTPS erfolgt ist.

Anfragen an HTTPS-Backends weiterleiten

Einige Backend-Anwendungsserver verwenden ebenfalls HTTPS. In diesem Fall muss Apache beim Weiterleiten der Anfrage eine separate verschlüsselte Verbindung zum Backend aufbauen.

Aktiviere HTTPS-Backend-Proxying mit:

SSLProxyEngine On

Anschließend können Anfragen an ein HTTPS-Backend weitergegeben werden:

ProxyPass / https://127.0.0.1:8443/
ProxyPassReverse / https://127.0.0.1:8443/

Ohne SSLProxyEngine On baut Apache keine HTTPS-Proxy-Verbindungen zu Backend-Servern auf.

Zertifikatsprüfung für Backends konfigurieren

Bei der Kommunikation mit HTTPS-Backends kann Apache deren Zertifikate überprüfen, um Verbindungen zu nicht vertrauenswürdigen Systemen zu verhindern.

Die Zertifikatsprüfung wird über Einstellungen wie die folgenden gesteuert:

SSLProxyVerify require
SSLProxyCheckPeerName On
SSLProxyCheckPeerExpire On

Diese Direktiven weisen Apache an:

• ein vertrauenswürdiges Backend-Zertifikat zu verlangen,
• den Hostnamen des Backends zu überprüfen,
• zu kontrollieren, dass das Zertifikat nicht abgelaufen ist.

In internen Testumgebungen mit selbstsignierten Zertifikaten wird die Prüfung gelegentlich vorübergehend deaktiviert:

SSLProxyVerify none
SSLProxyCheckPeerName Off

Das Deaktivieren der Zertifikatsprüfung reduziert die Sicherheit der Verbindung und sollte in Produktionsumgebungen grundsätzlich vermieden werden.

HTTP-Datenverkehr auf HTTPS umleiten

Reverse Proxys in Produktionsumgebungen leiten normalen HTTP-Datenverkehr häufig vollständig auf HTTPS um.

Ein separater HTTP-VirtualHost kann diese Weiterleitung übernehmen:

<VirtualHost *:80>
    ServerName example.com

    Redirect permanent / https://example.com/
</VirtualHost>

Damit wird sichergestellt, dass Clients verschlüsselte HTTPS-Verbindungen verwenden.

Die HTTPS-Website aktivieren

Aktiviere die HTTPS-Konfiguration:

sudo a2ensite reverse-proxy-ssl.conf

Prüfe die Konfiguration:

sudo apache2ctl configtest

Wenn die Syntax gültig ist, lade Apache neu:

sudo systemctl reload apache2

HTTPS-Proxying testen

Teste den HTTPS-Reverse-Proxy über folgende Adresse:

https://your-domain.com

Die SSL-Verbindung kann außerdem mit folgendem Befehl geprüft werden:

curl -I https://your-domain.com

Wenn die Konfiguration korrekt ist, terminiert Apache die HTTPS-Verbindung des Clients und leitet die Anfrage erfolgreich an das Backend weiter.

Apache verarbeitet damit verschlüsselte Client-Verbindungen auf der Reverse-Proxy-Ebene.

Schritt 7: Sicherheits-Härtung der Proxy-Konfiguration

Nachdem Apache als Reverse Proxy eingerichtet wurde, sollte die Proxy-Ebene sorgfältig abgesichert werden. Eine fehlerhafte Konfiguration kann interne Systeme offenlegen, unbeabsichtigtes Proxy-Verhalten ermöglichen oder die Angriffsfläche unnötig vergrößern.

Sicherstellen, dass Forward Proxying deaktiviert ist

Das Deaktivieren des Forward-Proxy-Betriebs gehört zu den wichtigsten Sicherheitsanforderungen.

Stelle immer sicher, dass folgende Direktive konfiguriert ist:

ProxyRequests Off

Wird Forward Proxying unbeabsichtigt aktiviert, können externe Benutzer möglicherweise beliebigen Datenverkehr über den Server weiterleiten. Offene Proxys werden häufig für Spam, schädliches Routing und Anonymisierungszwecke missbraucht.

Bei normalen Reverse-Proxy-Installationen sollte ProxyRequests Off entweder global oder innerhalb jedes Proxy-fähigen VirtualHost definiert werden.

Proxy-Zugriffe mit <Proxy>-Blöcken einschränken

Apache unterstützt Zugriffskontrollen für Proxy-Ressourcen über <Proxy>– und <ProxyMatch>-Container.

Zum Beispiel:

<Proxy "*">
    Require all denied
</Proxy>

Diese Konfiguration blockiert den Zugriff auf Forward-Proxy-Ziele, sofern diese nicht ausdrücklich erlaubt wurden.

Auch der Zugriff auf bestimmte Backend-Pfade oder interne Dienste kann eingeschränkt werden:

<Proxy "http://127.0.0.1:3000/admin">
    Require ip 192.168.1.0/24
</Proxy>

Solche Einschränkungen sind besonders wichtig, wenn ein Reverse Proxy interne Anwendungsfunktionen nach außen verfügbar macht.

Backend- und Serverinformationen verbergen

Apache und Backend-Anwendungen können über Header unnötige technische Informationen offenlegen, beispielsweise:

Server: Apache/2.4.58
X-Powered-By: Express

Solche Header können Softwareversionen oder verwendete Backend-Technologien verraten und dadurch bei der Aufklärung einer Infrastruktur hilfreich sein.

Die Menge öffentlich sichtbarer Serverinformationen kann mit folgenden Einstellungen reduziert werden:

ServerTokens Prod
ServerSignature Off

Backend-spezifische Header lassen sich zusätzlich mit mod_headers entfernen:

Header unset X-Powered-By

ServerTokens Prod
ServerSignature Off

Header, die direkt vom Backend erzeugt werden, benötigen möglicherweise zusätzliche Einstellungen innerhalb der jeweiligen Anwendung.

Durch das Reduzieren dieser Informationen werden weniger Details über die Infrastruktur öffentlich sichtbar.

Timeouts sorgfältig konfigurieren

Ungeeignete Timeout-Werte können dazu führen, dass Apache-Ressourcen durch hängende Backend-Verbindungen blockiert werden oder Probleme durch Ressourcenerschöpfung entstehen.

Relevante Einstellungen sind beispielsweise:

ProxyTimeout 30
Timeout 60

ProxyTimeout legt fest, wie lange Apache auf Antworten von Backend-Servern wartet. Timeout beeinflusst dagegen die allgemeine Verarbeitung von Anfragen.

Sinnvolle Werte verhindern, dass nicht reagierende Backend-Verbindungen Worker-Ressourcen unbegrenzt belegen.

Bei Bedarf Rate Limiting einsetzen

Öffentlich erreichbare Reverse Proxys können von Rate Limiting profitieren, um missbräuchlichen Datenverkehr und Denial-of-Service-Versuche zu reduzieren.

Apache stellt mehrere Module zur Traffic-Kontrolle bereit, darunter:

• mod_ratelimit
• mod_evasive
• mod_qos

mod_ratelimit kann beispielsweise die Antwortbandbreite für ausgewählte Pfade oder Inhaltstypen begrenzen.

Eine erweiterte Rate-Limiting-Konfiguration ist ein eigenes Thema. Für öffentlich erreichbare Dienste kann eine Form der Request-Drosselung jedoch sinnvoll sein.

Zugriff auf administrative Schnittstellen einschränken

Administrative Endpunkte wie der Balancer Manager sollten niemals ohne Zugriffsbeschränkung öffentlich erreichbar sein.

Zum Beispiel:

<Location "/balancer-manager">
    SetHandler balancer-manager
    Require local
</Location>

Wenn ein administrativer Zugriff aus der Ferne benötigt wird, sollte er über IP-basierte Regeln oder eine Authentifizierung eingeschränkt werden.

Eine uneingeschränkt zugängliche Verwaltungsschnittstelle kann Details über die Backend-Infrastruktur offenlegen und Zugriff auf Balancing-Funktionen ermöglichen.

Auf Open-Proxy-Verhalten testen

Nachdem der Reverse Proxy eingerichtet wurde, sollte geprüft werden, dass Apache nicht unbeabsichtigt als Forward Proxy arbeitet.

Ein einfacher Test kann mit folgendem Befehl durchgeführt werden:

curl -x http://your-server-ip:80 http://example.com

Wenn Apache die Anfrage ablehnt, arbeitet der Server nicht als offener Proxy.

Falls die Anfrage unerwartet erfolgreich ist, prüfe sofort:

• ob ProxyRequests Off gesetzt ist,
• ob keine zu großzügigen <Proxy>-Regeln vorhanden sind,
• ob keine unbeabsichtigte Forward-Proxy-Konfiguration aktiv ist.

Apache und Module aktuell halten

Da ein Reverse Proxy normalerweise direkt am Netzwerkrand betrieben wird, ist es wichtig, Apache und seine Module aktuell zu halten.

Aktualisiere installierte Pakete regelmäßig mit:

sudo apt update
sudo apt upgrade

Sicherheitsupdates können unter anderem Probleme in folgenden Bereichen beheben:

• HTTP-Request-Parsing
• TLS-Schwachstellen
• Request Smuggling
• Denial-of-Service-Schwachstellen
• Modulspezifische Sicherheitslücken

Eine zeitnahe Installation von Sicherheitsupdates reduziert die Gefährdung durch öffentlich dokumentierte Schwachstellen.

Konfigurationsänderungen validieren

Prüfe nach sicherheitsrelevanten Änderungen die Apache-Syntax:

sudo apache2ctl configtest

Wenn die Syntax gültig ist, lade Apache neu:

sudo systemctl reload apache2

Die Reverse-Proxy-Konfiguration ist damit besser geschützt und für den Einsatz in einer Produktionsumgebung geeigneter.

Häufige mod_proxy-Fehler beheben

Bereits kleine Konfigurationsfehler können dazu führen, dass Apache nicht korrekt mit Backend-Anwendungen kommuniziert. Falsche Backend-Adressen, nicht verfügbare Module, Probleme bei der SSL-Verifizierung oder fehlerhaft konfigurierte Header können Proxy-Fehler verursachen.

Bei Problemen mit einem Apache-Reverse-Proxy solltest du zunächst das Fehlerprotokoll prüfen:

/var/log/apache2/error.log

Die Datei kann in Echtzeit überwacht werden mit:

sudo tail -f /var/log/apache2/error.log

Vor einem erneuten Laden von Apache sollte außerdem die Konfiguration geprüft werden:

sudo apache2ctl configtest

Wenn Apache Folgendes zurückgibt:

Syntax OK

ist die Konfiguration syntaktisch gültig.

Die folgenden Abschnitte beschreiben mehrere häufig auftretende Probleme mit mod_proxy.

502 Bad Gateway

Eine Antwort mit 502 Bad Gateway bedeutet normalerweise, dass Apache nicht erfolgreich mit dem konfigurierten Backend-Anwendungsserver kommunizieren konnte.

Häufige Ursachen sind:

• Die Backend-Anwendung wurde gestoppt.
• Das Backend lauscht auf einem anderen Port.
• Eine Firewall blockiert die Verbindung.
• Das in ProxyPass konfigurierte Ziel ist falsch.
• Das Backend stürzt ab oder überschreitet einen Timeout.

Wenn Apache beispielsweise Anfragen an folgendes Ziel weiterleitet:

ProxyPass / http://127.0.0.1:3000/

aber kein Dienst auf Port 3000 lauscht, gibt Apache eine 502-Antwort zurück.

Prüfe zunächst, ob ein Dienst auf diesem Port lauscht:

sudo ss -tulpn | grep 3000

Teste das Backend anschließend direkt:

curl http://127.0.0.1:3000

Wenn das Backend auch lokal nicht antwortet, liegt das Problem bei der Anwendung oder ihrer Konfiguration und nicht beim Apache-Proxy.

Das Apache-Protokoll kann einen Eintrag wie den folgenden enthalten:

AH01114: HTTP: failed to make connection to backend

Diese Meldung weist normalerweise auf einen Verbindungsfehler zwischen Apache und dem Backend-Dienst hin.

503 Service Unavailable

Ein Fehler mit 503 Service Unavailable tritt häufig in Umgebungen auf, die mod_proxy_balancer verwenden.

Er bedeutet in der Regel, dass Apache alle konfigurierten Worker derzeit als nicht verfügbar betrachtet.

Mögliche Ursachen sind:

• Alle Backend-Server sind offline.
• Health Checks schlagen fehl.
• BalancerMember-Definitionen sind falsch.
• Backend-Anfragen überschreiten Timeouts.
• Die DNS-Auflösung schlägt fehl.

Zum Beispiel:

<Proxy "balancer://mycluster">
    BalancerMember http://127.0.0.1:3001
    BalancerMember http://127.0.0.1:3002
</Proxy>

Teste jedes Backend direkt:

curl http://127.0.0.1:3001
curl http://127.0.0.1:3002

Wenn ein Backend nicht erreichbar ist, kann Apache dieses vorübergehend als nicht nutzbar markieren, bis es wieder verfügbar ist.

Das Fehlerprotokoll kann folgende Meldung enthalten:

AH01170: balancer://mycluster: All workers are in error state

Diese Meldung zeigt an, dass Apache für die Anfrage keinen verwendbaren Backend-Server finden konnte.

SSL-Handshake-Fehler bei HTTPS-Backends

Wenn Apache Anfragen an HTTPS-Backends weiterleitet, kann die TLS-Aushandlung fehlschlagen.

Häufige Ursachen sind:

• Ungültige oder abgelaufene Backend-Zertifikate
• Selbstsignierte Zertifikate
• Nicht übereinstimmende Hostnamen
• Fehlendes SSLProxyEngine On
• Fehler bei der Zertifikatsprüfung

Zum Beispiel:

SSLProxyEngine On

ProxyPass / https://127.0.0.1:8443/

Wenn die Zertifikatsprüfung fehlschlägt, kann Apache einen Fehler wie diesen protokollieren:

AH02039: Certificate Verification: Error

Für vorübergehende interne Tests mit selbstsignierten Zertifikaten wird die Überprüfung gelegentlich deaktiviert:

SSLProxyVerify none
SSLProxyCheckPeerName Off

In Produktionsumgebungen sollte die Zertifikatsprüfung nach Möglichkeit aktiviert bleiben.

Teste das HTTPS-Backend direkt mit:

curl -k https://127.0.0.1:8443

Header-Weiterleitung funktioniert nicht korrekt

Backend-Anwendungen können die ursprüngliche Client-Adresse, den Hostnamen oder den HTTPS-Status möglicherweise nicht erkennen, wenn Forwarded Headers fehlen oder falsch konfiguriert sind.

Typische Symptome sind:

• Die Anwendung protokolliert die Proxy-Adresse statt der Client-Adresse.
• Weiterleitungs-URLs sind falsch.
• Sichere Cookies funktionieren nicht wie erwartet.
• Die Anwendung erkennt HTTPS nicht.

Prüfe, ob die erforderlichen Direktiven gesetzt sind:

ProxyPreserveHost On
ProxyAddHeaders On
RequestHeader set X-Forwarded-Proto expr=%{REQUEST_SCHEME}

Stelle außerdem sicher, dass mod_headers aktiviert ist:

sudo a2enmod headers

Die weitergegebenen Werte können über die Backend-Anwendung oder einen Diagnose-Endpunkt kontrolliert werden, der Request-Header anzeigt.

Modul nicht gefunden oder unbekannte Direktive

Apache meldet Fehler bei Direktiven, wenn das Modul, das eine bestimmte Konfigurationsdirektive bereitstellt, nicht aktiviert wurde.

Ein häufiges Beispiel ist:

Invalid command 'ProxyPass'

oder:

Invalid command 'RequestHeader'

Diese Meldungen bedeuten üblicherweise, dass das entsprechende Proxy- oder Header-Modul deaktiviert ist.

Aktiviere die benötigten Module:

sudo a2enmod proxy
sudo a2enmod proxy_http
sudo a2enmod headers

Lade Apache anschließend neu:

sudo systemctl reload apache2

Die geladenen Module können mit folgendem Befehl geprüft werden:

apache2ctl -M

Verbindungsprobleme zum Backend diagnostizieren

Wenn Apache keine Verbindung zu einem Backend herstellen kann, überprüfe:

• ob der Backend-Dienst läuft,
• ob die konfigurierte IP-Adresse und der Port korrekt sind,
• ob keine Firewall-Regel die benötigte Verbindung blockiert,
• ob das Backend auf der erwarteten Netzwerkschnittstelle lauscht.

Nützliche Diagnosebefehle sind:

ss -tulpn
curl http://127.0.0.1:3000

Ein direkter Test des Backends ohne Proxy hilft dabei festzustellen, ob das Problem bei Apache oder bei der Backend-Anwendung selbst liegt.

Apache nach Konfigurationsänderungen neu laden

Nachdem Konfigurationsprobleme behoben wurden, validiere die Konfiguration und lade Apache neu:

sudo apache2ctl configtest
sudo systemctl reload apache2

Mit reload statt eines vollständigen restart werden Konfigurationsänderungen übernommen, ohne aktive Verbindungen vollständig zu unterbrechen.

Apache ist nun über die Modulfamilie mod_proxy als Reverse Proxy eingerichtet und unterstützt weitergeleitete Header, Load Balancing, SSL-Terminierung, WebSocket-Proxying und grundlegende Sicherheits-Härtung.

Häufig gestellte Fragen

1. Was ist der Unterschied zwischen ProxyPass und ProxyPassReverse?

ProxyPass ordnet eingehende Frontend-Request-URLs einer Backend-URL zu. ProxyPassReverse passt Antwort-Header wie Location, Content-Location und URI so an, dass vom Backend erzeugte Weiterleitungen auf die öffentliche Frontend-URL verweisen, anstatt die interne Backend-Adresse offenzulegen.

2. Benötige ich ProxyRequests On, um Apache als Reverse Proxy zu verwenden?

Nein. ProxyRequests On aktiviert die Forward-Proxy-Funktion und ermöglicht Clients, beliebige externe Anfragen über Apache weiterzuleiten. Ein Reverse Proxy sollte normalerweise ProxyRequests Off verwenden und konkrete Backend-Zuordnungen über ProxyPass definieren. Wird ProxyRequests On ohne geeignete Einschränkungen aktiviert, kann ein offener Proxy entstehen.

3. Welches mod_proxy-Untermodul wird für HTTP- und HTTPS-Backend-Verbindungen benötigt?

mod_proxy_http wird benötigt, um HTTP- und HTTPS-Anwendungstraffic weiterzuleiten. Das zentrale Modul mod_proxy allein reicht dafür nicht aus. Wenn Apache eine Verbindung zu einem HTTPS-Backend aufbaut, werden zusätzlich mod_ssl und SSLProxyEngine On benötigt.

4. Wie aktiviere ich mod_proxy unter Ubuntu oder Debian?

Führe sudo a2enmod proxy proxy_http aus und starte Apache anschließend mit sudo systemctl restart apache2 neu. Für Load Balancing müssen zusätzlich proxy_balancer und ein Balancing-Modul wie lbmethod_byrequests aktiviert werden.

5. Wie unterscheidet sich Apache mod_proxy von Nginx als Reverse Proxy?

Apache mod_proxy integriert sich direkt in vorhandene Apache-Konfigurationen und profitiert vom umfangreichen Apache-Modulsystem. Nginx verwendet eine ereignisgesteuerte, nicht blockierende Architektur und wird häufig für Reverse-Proxy-Umgebungen mit sehr hoher Parallelität eingesetzt. Auf Systemen, auf denen Apache bereits verwendet wird, stellt mod_proxy Reverse-Proxy-Funktionen bereit, ohne dass ein zusätzlicher Webserver-Prozess eingeführt werden muss.

6. Kann Apache mod_proxy WebSocket-Verbindungen verarbeiten?

Ja. Das Modul mod_proxy_wstunnel unterstützt WebSocket-Proxying. ProxyPass-Direktiven können die Protokolle ws:// oder wss:// verwenden, um WebSocket-Traffic an Backend-Anwendungen weiterzugeben. Die erforderlichen Proxy-Module müssen für diese Konfiguration aktiviert sein.

7. Was verursacht einen 502-Bad-Gateway-Fehler bei der Verwendung von mod_proxy?

Eine 502-Antwort bedeutet normalerweise, dass Apache nicht erfolgreich mit der Backend-Anwendung kommunizieren konnte oder eine ungültige Antwort vom Backend erhalten hat. Häufige Ursachen sind ein gestoppter Backend-Prozess, ein falscher Backend-Port in ProxyPass, Firewall-Beschränkungen zwischen Apache und Backend oder ein Timeout. Prüfe das Apache-error.log und teste das Backend direkt mit Werkzeugen wie curl oder nc.

8. Wie übergebe ich die ursprüngliche Client-IP-Adresse an das Backend?

Aktiviere ProxyAddHeaders On und ProxyPreserveHost On innerhalb des entsprechenden VirtualHost. Apache kann dann Header wie X-Forwarded-For und X-Forwarded-Host hinzufügen. Wenn TLS durch Apache terminiert wird, sollte zusätzlich X-Forwarded-Proto über RequestHeader gesetzt werden, damit das Backend die ursprüngliche HTTPS-Verbindung erkennen kann.

Fazit

In diesem Tutorial wurde gezeigt, wie Apache unter Ubuntu mit der Modulfamilie mod_proxy als Reverse Proxy eingerichtet wird. Apache wurde installiert und die erforderlichen Proxy-Module wurden aktiviert. Die Weiterleitung von Anfragen wurde mit ProxyPass und ProxyPassReverse konfiguriert, ursprüngliche Client-Informationen wurden mithilfe weitergeleiteter Header beibehalten, der Datenverkehr wurde mit mod_proxy_balancer auf mehrere Anwendungsserver verteilt und die SSL-Terminierung auf der Frontend-Proxy-Ebene eingerichtet. Zusätzlich wurden Maßnahmen zur Sicherheits-Härtung und typische Vorgehensweisen zur Diagnose von mod_proxy-Fehlern behandelt.

Auf dieser Grundlage kann die Reverse-Proxy-Konfiguration um fortgeschrittene Szenarien erweitert werden. Dazu gehören pfadbasiertes Routing auf mehrere Anwendungen, WebSocket-Proxying mit mod_proxy_wstunnel und Backend-Health-Checks über mod_proxy_hcheck. Weitere technische Informationen sind in der Apache-mod_proxy-Dokumentation verfügbar.