Apache2 Workshop Reverse Proxy mit Websockets: Unterschied zwischen den Versionen
(Die Seite wurde neu angelegt: „= Apache2 Workshop Reverse Proxy mit Websockets = == Grundlagen == '''Reverse Proxy''': Apache2 kann als Vermittler zwischen einem Client und einem internen…“) |
|||
| Zeile 23: | Zeile 23: | ||
</pre> | </pre> | ||
| − | == Beispielkonfiguration für Websockets == | + | == Beispielkonfiguration mit TLS für Websockets == |
| − | '''Ziel''': Weiterleitung von | + | '''Ziel''': Weiterleitung von HTTPS und Websocket (wss://) auf einen internen Server unter Port 3000 |
<pre> | <pre> | ||
| − | <VirtualHost *: | + | <VirtualHost *:443> |
ServerName chat.example.org | ServerName chat.example.org | ||
| + | |||
| + | SSLEngine on | ||
| + | SSLCertificateFile /etc/ssl/certs/chat.crt | ||
| + | SSLCertificateKeyFile /etc/ssl/private/chat.key | ||
ProxyPreserveHost On | ProxyPreserveHost On | ||
| Zeile 35: | Zeile 39: | ||
ProxyPassReverse / 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 | ProxyPass /socket ws://127.0.0.1:3000/socket | ||
ProxyPassReverse /socket ws://127.0.0.1:3000/socket | ProxyPassReverse /socket ws://127.0.0.1:3000/socket | ||
| + | </VirtualHost> | ||
| + | </pre> | ||
| + | |||
| + | '''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: | ||
| + | |||
| + | <pre> | ||
| + | <VirtualHost *:80> | ||
| + | ServerName chat.example.org | ||
| + | Redirect permanent / https://chat.example.org/ | ||
</VirtualHost> | </VirtualHost> | ||
</pre> | </pre> | ||
Aktuelle Version vom 23. März 2025, 15:18 Uhr
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.