Apache2 Workshop Reverse Proxy mit Websockets

Aus Xinux Wiki
Version vom 23. März 2025, 15:18 Uhr von Thomas.will (Diskussion | Beiträge) (→‎Beispielkonfiguration für Websockets)
(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)
Zur Navigation springen Zur Suche springen

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 mit TLS für Websockets

Ziel: Weiterleitung von HTTPS und Websocket (wss://) auf einen internen Server unter Port 3000

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

    SSLEngine on
    SSLCertificateFile /etc/ssl/certs/chat.crt
    SSLCertificateKeyFile /etc/ssl/private/chat.key

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

    # WebSocket-Weiterleitung über TLS
    ProxyPass /socket ws://127.0.0.1:3000/socket
    ProxyPassReverse /socket ws://127.0.0.1:3000/socket
</VirtualHost>

Hinweis: Auch wenn die Client-Verbindung per wss:// erfolgt, wird zum Backend intern meist unverschlüsselt per ws:// oder http:// weitergeleitet, da beide Dienste auf demselben System laufen.

Wichtige Ergänzung

Falls du auch auf Port 80 lauscht, solltest du HTTP auf HTTPS umleiten:

<VirtualHost *:80>
    ServerName chat.example.org
    Redirect permanent / https://chat.example.org/
</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.