Technologie

Wie kann ich NGINX so konfigurieren, dass WebSocket-Verbindungen unterstützt werden?

Melden
  1. Einleitung
  2. Grundlagen zur WebSocket-Unterstützung in NGINX
  3. Wichtige Header und Einstellungen
  4. Beispielkonfiguration
  5. Erklärung der Konfiguration
  6. Weitere Hinweise

Einleitung

WebSocket ist ein Protokoll, das eine dauerhafte, bidirektionale Kommunikation zwischen einem Client und einem Server ermöglicht. Anders als klassische HTTP-Verbindungen bleiben WebSocket-Verbindungen bestehen, bis sie explizit geschlossen werden.

NGINX wird häufig als Reverse Proxy verwendet und unterstützt WebSocket-Verbindungen, benötigt jedoch eine spezielle Konfiguration, damit die Upgrades des Protokolls korrekt verarbeitet werden.

Grundlagen zur WebSocket-Unterstützung in NGINX

WebSocket-Verbindungen beginnen als normale HTTP-Anfragen, die dann per Upgrade-Header in das WebSocket-Protokoll wechseln. Damit NGINX diese Verbindung weiterleiten kann, muss es die spezifischen Header korrekt weiterreichen und die Verbindung persistent halten.

Standardmäßig sind viele Proxies darauf ausgelegt, Verbindungen nach dem Versand einer HTTP-Antwort zu schließen, was bei WebSocket-Verbindungen hinderlich wäre.

Wichtige Header und Einstellungen

Für eine funktionierende WebSocket-Unterstützung muss NGINX die Header Connection und Upgrade an den Backend-Server weiterleiten. Dabei ist es wichtig, dass der Wert des Connection-Headers nicht statisch auf "upgrade" gesetzt wird, sondern der Wert des Client-Headers weitergegeben wird.

Zusätzlich muss die Timeout-Konfiguration beachtet werden, damit lange Verbindungen nicht fälschlicherweise getrennt werden.

Beispielkonfiguration

Hier ein typisches Beispiel, wie ein Serverblock in nginx.conf oder in einer separaten Site-Konfigurationsdatei aussehen könnte, um WebSocket zu unterstützen. Angenommen, der WebSocket-Server läuft auf localhost Port 8080.

server { listen 80; server_name beispiel.de; location /ws/ { proxy_pass http://localhost:8080/; # Weitergabe der notwendigen Header für WebSockets proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection $connection_upgrade; # Ursprung setzen, falls gewünscht proxy_set_header Host $host; # Umgehen von Cacheproblemen bei WebSockets proxy_cache_bypass $http_upgrade; # Optional: Timeout erhöhen, da WebSocket-Verbindungen lange bestehen bleiben proxy_read_timeout 86400s; proxy_send_timeout 86400s; }

# Konfiguriere den Variablenwert in http{}-Block oder direkt in der Server- oder Location-Konfiguration

map $http_upgrade $connection_upgrade { default upgrade; close; }}

# Konfiguriere den Variablenwert in http{}-Block oder direkt in der Server- oder Location-Konfiguration

Erklärung der Konfiguration

Die Direktive proxy_http_version 1.1; ist entscheidend, weil HTTP/1.0 das Upgrade-Headerfeld nicht unterstützt. Durch die Weitergabe von proxy_set_header Upgrade $http_upgrade; und proxy_set_header Connection $connection_upgrade; wird gewährleistet, dass NGINX das Upgrade auf das WebSocket-Protokoll korrekt an den Backend-Server weiterleitet.

Die Variable $connection_upgrade wird mithilfe von map definiert, um sicherzustellen, dass das Headerfeld Connection den korrekten Wert erhält: Wenn der eingehende Upgrade-Header gesetzt ist, wird "upgrade" verwendet, andernfalls "close".

Die Zeitüberschreitungen für das Lesen und Schreiben (proxy_read_timeout und proxy_send_timeout) wurden auf 86400 Sekunden (24 Stunden) erhöht, damit offene WebSocket-Verbindungen nicht vorzeitig abgebrochen werden.

Weitere Hinweise

Es ist wichtig, beim Verwenden von SSL (HTTPS) sicherzustellen, dass das Protokoll proxy_pass korrekt auf https:// verweist, wenn der Backend-WebSocket-Server SSL unterstützt. In diesem Fall können zusätzliche SSL-Einstellungen nötig sein.

Nach Änderungen an der NGINX-Konfiguration sollten Sie nginx -t ausführen, um die Syntax zu überprüfen, und anschließend den NGINX-Dienst neu starten oder neu laden, damit die Änderungen aktiv werden.

Abschließend lässt sich sagen, dass NGINX mit der beschriebenen Konfiguration zuverlässig als Reverse Proxy für WebSocket-Verbindungen fungiert und so eine stabile bidirektionale Kommunikation zwischen Client und Server ermöglicht.

0

Kommentare