Pourquoi une connexion WebSocket échoue-t-elle via Nginx ?

Question

IT Interview Practice · Accepted Answer

Distinguez d'abord une négociation de connexion échouée d'une connexion qui s'ouvre puis se ferme. Ces deux symptômes conduisent à des vérifications différentes.

## Transmettre la demande d'upgrade à l'application

Pour une route WebSocket dédiée, placez ceci dans `server` :

```nginx
location /socket/ {
    proxy_pass http://127.0.0.1:3000;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
}
```

`proxy_http_version` utilise explicitement HTTP/1.1 vers le backend. `Upgrade` transmet le changement de protocole demandé par le client. `Connection` indique au backend que cette connexion demande ce changement. Ces en-têtes doivent être transmis explicitement, car les proxys ne relaient pas simplement tous les en-têtes propres à une connexion.

## Lire le résultat

Une négociation réussie renvoie `101 Switching Protocols`. Si vous recevez 404, vérifiez le chemin du backend ; si l'authentification échoue, examinez la politique applicative. La configuration proxy ne remplace ni l'authentification ni les vérifications d'origine autorisée.

Si la connexion s'ouvre mais se ferme après une période d'inactivité, examinez les délais d'inactivité de Nginx et des autres proxys. Utilisez des trames ping WebSocket envoyées par le serveur et un `proxy_read_timeout` adapté, avec une reconnexion côté client. Augmenter seulement le délai peut conserver plus longtemps des connexions mortes.

[Documentation officielle](https://nginx.org/en/docs/http/websocket.html).

Transmettre la demande d'upgrade à l'application

Lire le résultat

Questions connexes