Apache2 Workshop Reverse Proxy mit Websockets

Apache2 Workshop Reverse Proxy mit Websockets

Grundlagen

Reverse Proxy: Apache2 kann als Vermittler zwischen einem Client und einem internen Backendserver (z. B. Node.js, Python, PHP-FPM) agieren. Dazu wird meist mod_proxy verwendet.

Websockets: Eine dauerhafte bidirektionale Verbindung, die nach einem HTTP-Handshake mit Upgrade-Header aufgebaut wird. Damit das funktioniert, muss Apache die Verbindung korrekt weiterleiten.

Benötigte Module

Folgende Module müssen aktiviert sein:

a2enmod proxy
a2enmod proxy_http
a2enmod proxy_wstunnel

Danach:

systemctl reload apache2

Beispielkonfiguration für Websockets

Ziel: Weiterleitung von HTTP und Websocket auf einen internen Server unter Port 3000

<VirtualHost *:80>
    ServerName chat.example.org

    ProxyPreserveHost On
    ProxyPass / http://127.0.0.1:3000/
    ProxyPassReverse / http://127.0.0.1:3000/

    # Websocket-Weiterleitung (Upgrade-Header)
    ProxyPass /socket ws://127.0.0.1:3000/socket
    ProxyPassReverse /socket ws://127.0.0.1:3000/socket
</VirtualHost>

Besonderheiten bei Websockets

Upgrade-Header: Apache muss den Upgrade-Mechanismus explizit unterstützen. Das übernimmt mod_proxy_wstunnel.

Pfadgenauigkeit: Websockets laufen oft unter einem eigenen Pfad (z. B. /socket.io/). Dieser muss gesondert als ws:// weitergeleitet werden.

Fehlersuche: Wenn Websockets nicht funktionieren: – Chrome-Devtools oder Firefox-Netzwerkanalyse verwenden – Auf 101 Switching Protocols achten – Apache-Errorlog prüfen

Sicherheitshinweise

Timeouts: Längere Verbindungen benötigen ggf. angepasste Timeouts:

ProxyTimeout 3600

Zugriffsschutz: Auch Websockets können Authentifizierungen und Zugriffskontrollen benötigen – ggf. Absicherung mit Tokens, IP-Whitelist oder Auth-Header.

Fazit

Apache2 kann Websockets problemlos als Reverse Proxy weiterleiten, wenn mod_proxy_wstunnel aktiv ist und die Pfade korrekt gesetzt sind. Wichtig ist die exakte Unterscheidung von HTTP- und WS-Verbindungen.