Socket.io: Erreur lors de la négociation WebSocket : code de réponse inattendu : 400

Je rencontre exactement le même problème en ce moment, une aide ?

J'ai également ce problème depuis que j'ai installé un certificat SSL sur mon domaine.

Voici une meilleure description du problème : http://stackoverflow.com/questions/28025073/error-during-websocket-handshake-unexpected-response-code-400-with-nginx-proxy

J'ai également un problème similaire de connexion avec l'une des bibliothèques Android. Les sockets Web ne se connecteront pas à https via HAproxy effectuant une terminaison ssl ou en laissant le nœud faire ssl directement. Les sondages longs fonctionnent bien cependant

Je le résous en changeant le domaine en la véritable adresse IP :

var socket = io.connect('http://182.92.79.215:3007');

J'ai eu le même problème, mon application est derrière nginx. Apporter ces modifications à ma configuration Nginx a supprimé l'erreur.

emplacement / {
proxy_pass http://localhost :8080;
proxy_http_version 1.1 ;
proxy_set_header Mettre à jour $http_upgrade ;
proxy_set_header Connexion "mise à niveau" ;
proxy_set_header Hôte $hôte ;
}

Ceci est à l'origine de https://chrislea.com/2013/02/23/proxying-websockets-with-nginx/

Même problème ici sur le serveur de production. Les machines de développement n'affichent pas l'erreur.

Ce qui est étrange, c'est que la connexion fonctionne. Je peux envoyer des messages via WebSockets à partir du serveur et le client les reçoit. Je peux également voir la connexion WebSocket s'établir sur le serveur.

Je reçois juste cette erreur dans les outils de développement en disant:

La connexion WebSocket à ' wss://.../socket.io/?EIO=3&transport=websocket&sid=2b_v_BXtbwzl5z2yAAAI ' a échoué : erreur lors de la négociation WebSocket : code de réponse inattendu : 400

J'utilise Apache ProxyPass pour envoyer des connexions au nœud.

Idem ici - entièrement fonctionnel mais message d'erreur dans les outils de développement. Ailleurs, j'ai lu son rapport avec la version apache - en utilisant 2.2.14 sur cette machine.

Assurez-vous que votre connexion socket.io ne passe pas par un équilibreur de charge Amazon. Ou si c'est le cas, faites ceci : http://blog.flux7.com/web-apps-websockets-with-aws-elastic-load-balancing

Même problème ici, uniquement dans un environnement de production.
Websockets semble fonctionner correctement, l'application fonctionne sans problème. Mais sur le journal de la console, je peux voir cette erreur.

J'utilise Nginx et un seul serveur pour le nœud, donc cela ne semble pas être un problème d'équilibrage de charge. J'utilisais déjà la solution suggérée par tylercb (à l'exception de "proxy_set_header Host $host;") et cela ne résout pas le problème.

aussi un problème, mais fonctionne bien....

J'ai eu ce même problème. Utilisez-vous CloudFlare ? Actuellement, seul leur plan Entreprise prend en charge WebSockets.

Résolu pour moi. Cela était dû à une mauvaise adresse socket.io dans la configuration nginx, qui ne correspondait pas au chemin utilisant le websocket.

J'ai googlé parce que j'ai eu le même problème et j'utilise aussi nginx. La solution est d'ajouter cette partie

proxy_http_version 1.1 ;
proxy_set_header Mettre à jour $http_upgrade ;
proxy_set_header Connexion "mise à niveau" ;
proxy_set_header Hôte $hôte ;

dans le fichier de configuration nginx comme tylercb mentionné.

A travaillé pour moi. Merci.

J'ai eu la même erreur en me connectant directement à mon application hébergée sur Windows Server 2008R2 (pas de proxy, pas d'IIS). Seul le matériel intermédiaire stupide entre les deux.

Fonctionne bien après avoir changé le nom d'hôte en adresse IP, c'est-à-dire 127.0.0.1:9000. peut être causé par httpd ProxyPassReverse

Dans mon cas, le problème résultait du fait que cloudfare ne prenait pas en charge les websockets sur le plan gratuit. J'ai désactivé CloudFare pour le domaine et cela a fonctionné.

J'avais juste besoin d'ajouter quelques conditions de réécriture Apache pour gérer les websockets, plus d'infos ici :
http://stackoverflow.com/a/27534443/2044993

Je sais que c'est un vieux problème, mais comme il est élevé dans les résultats de recherche Google, cela pourrait aider les gens :

La raison pour laquelle la connexion fonctionne toujours même avec cette erreur est que socket.io revient à AJAX, ce qui n'est pas optimal et vous devez corriger la configuration de votre serveur.

Au fait, ce problème devrait rester fermé, ce n'est pas un problème socket.io.

@arosenfeld-mentel Je continue à lire les messages au-dessus de votre commentaire selon lesquels "ce n'est pas un problème socket.io" mais je ne vois pas où quelqu'un dit QUEL est réellement le problème. Je le vois moi-même bien que, comme vous le dites, la connexion semble toujours fonctionner. Tous les conseils seraient très appréciés. Merci!

Le problème peut être n'importe quoi, vous devez déboguer toute votre configuration. Pour moi, c'était NGINX, qui, en tant que proxy inverse, a besoin des paramètres de configuration supplémentaires publiés ci-dessus à plusieurs reprises. Car tu pourrais être autre chose.

Commencez par déboguer la connexion locale, faites-la fonctionner sans avertissement, puis passez au serveur de production et assurez-vous que les pare-feu, les serveurs frontaux et les proxys coopèrent avec WebSockets.

Ce n'est pas un problème socket.io, mais c'est un problème WebSockets, alors assurez-vous que le serveur et le client fonctionnent bien avec WebSockets.

Merci pour la réponse. Tout fonctionne localement ou via notre VPN, mais une fois notre pare-feu impliqué, les messages apparaissent. Je suppose que le pare-feu interfère d'une manière ou d'une autre et nous devrons apprendre à déboguer ce problème au lieu de blâmer socket.io. Merci encore.

Ayant exactement le même problème. J'ai également créer une question stackoverflow (http://stackoverflow.com/questions/34439546/socket-io-with-apache-proxy), mais les choses suggérées là-bas n'ont pas encore fonctionné pour moi.

j'ai mis ces en-têtes dans nginx mais j'obtiens toujours la même chose, mais pas dans le navigateur mais dans https://toolbox.seositecheckup.com

Avait également ce problème, il semble que mon hôte virtuel (via nginx) n'ait pas été configuré correctement pour accepter l'en-tête de mise à niveau. Le correctif de @tylercb d'il y a environ un an l'a corrigé ^

@tylercb a travaillé pour moi.

+1
Cette erreur s'est produite sur l'environnement openshift

J'ai pensé qu'il pourrait être utile de documenter exactement ce que j'ai fait pour résoudre le problème. Il s'agit simplement d'une combinaison des différents messages ci-dessus mis dans un message simple afin que toute autre personne trouvant ce problème puisse facilement obtenir une solution potentielle. Je ne prends aucun crédit pour le travail acharné.

Nous courons

1. Serveur Ubuntu 14.04 LTS,
2. Version nginx : nginx/1.4.6 (Ubuntu) en tant que proxy inverse et passerelle SSL.
3. Nous n'avons PAS du tout Apache. Il est supprimé du système.
4. Nous avons un serveur node.js exécuté derrière nginx v0.10.25. Celui-ci écoute sur le port 4001. L'accès externe se fait via le port 4000.
5. Nous exécutons ufw à l'avant et laissons simplement passer le port 4000.
6. Nous gérons nos propres serveurs et n'utilisons ni Cloudflare ni Openshift
7. Nous n'utilisons pas (encore) d'équilibreur de charge.

Nous avons eu les mêmes problèmes que d'autres personnes de

WebSocket connection to 'ws://XXXXXXXXXX?EIO=2&transport=websocket&sid=p3af7ZNfvogtq6tAAAG0' failed: Error during WebSocket handshake: Unexpected response code: 400.

Nous avons mis à jour le fichier nginx dans /etc/nginx/sites-enabled/default pour lire comme suit : (notez que nous avons retiré nos noms de domaine)

server {
        listen 4000;
        server_name XXXX.YYYY.ZZZZ;

        root html;
        index index.html index.htm;

        ssl on;
        ssl_certificate /etc/ssl/certs/SSL.crt;
        ssl_certificate_key /etc/ssl/private/server.key;

        ssl_session_timeout 5m;

        # ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2; # NOTE WE REMOVE SSLv3
        ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
        ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES1\
28-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECD\
HE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SH\
A256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SH\
A:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';

        ssl_prefer_server_ciphers on;
        ssl_dhparam /etc/ssl/private/dhparams.pem;

        location / {
                 proxy_set_header        Host $host;
                 proxy_set_header        X-Real-IP $remote_addr;
                 proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
                 proxy_set_header        X-Forwarded-Proto $scheme;

                 # Fix the “It appears that your reverse proxy set up is broken" error.
                 proxy_pass          http://127.0.0.1:4001;
                 proxy_read_timeout  90;

                 proxy_redirect      http://127.0.0.1:4001 https://XXXXX.YYYYY.ZZZZZ;

                 # These three lines added as per https://github.com/socketio/socket.io/issues/1942 to remove the error
                 # WebSocket connection to 'wss://XXXXX.YYYYY.ZZZZZ:4000/socket.io/?EIO=3&transport=websocket&sid=0hsRiXu0q9p6RHQ8AAAC' failed:\
 Error during WebSocket handshake: Unexpected response code: 400 in console.log

                 proxy_http_version 1.1;
                 proxy_set_header   Upgrade $http_upgrade;
                 proxy_set_header   Connection "upgrade";
        }
}

Il nous suffisait d'ajouter

1. proxy_http_version 1.1 ;
2. proxy_set_header Mettre à jour $http_upgrade ;
   3.proxy_set_header Connexion "mise à niveau" ;

comme nous l'avions déjà

1. proxy_set_header Hôte $hôte ;
2. proxy_pass http://127.0.0.1 :4001 ;

J'espère que cela aide, cela a fonctionné pour nous.

Merci pour l'aide,

Rob

J'ai le même problème lorsque je m'authentifie avec CAS (pas avec le formulaire classique), et que j'utilise Apache avec LetEncrypt SSL comme proxy, y a-t-il une configuration spécifique à définir ?

Tentative de déploiement de l'application Node.js sur AWS Elastic BeanStalk.
J'ai ajouté un dossier .ebextensions à la racine du serveur, et à l'intérieur j'ai ajouté le fichier nginx.config qui ressemble à ceci :

server:
  location /:
    proxy_pass http://localhost:8080;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_set_header Host $host;

J'obtiens toujours l'erreur 400, mais au moins tout le reste du socket fonctionne.

Pour référence : il s'agit de la seule solution de configuration fonctionnelle que j'ai trouvée pour socket.io 1.x et Apache 2.4 : https://github.com/meteor/meteor/issues/3339#issuecomment -165188938

ProxyPass / http://localhost:3999/
ProxyPassReverse / http://localhost:3999/

RewriteEngine on
RewriteCond %{HTTP:UPGRADE} ^WebSocket$ [NC]
RewriteCond %{HTTP:CONNECTION} ^Upgrade$ [NC]
RewriteRule .* ws://localhost:3999%{REQUEST_URI} [P]

en utilisant un autre port, cela peut fonctionner

@BlaM merci pour la configuration de travail !

Pour toute personne rencontrant ce problème dans AWS Elastic Beanstalk, ce fichier .ebextension a fonctionné pour moi :

files:
    "/etc/nginx/conf.d/01_websockets.conf" :
        mode: "000644"
        owner: root
        group: root
        content : |
            upstream nodejs {
                server 127.0.0.1:8081;
                keepalive 256;
            }

            server {
                listen 8080;

                location / {
                    proxy_pass  http://nodejs;
                    proxy_set_header Upgrade $http_upgrade;
                    proxy_set_header Connection "upgrade";
                    proxy_http_version 1.1;
                    proxy_set_header        Host            $host;
                    proxy_set_header        X-Real-IP       $remote_addr;
                    proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
                }
            }

    "/opt/elasticbeanstalk/hooks/appdeploy/enact/41_remove_eb_nginx_confg.sh":
        mode: "000755"
        owner: root
        group: root
        content : |
            mv /etc/nginx/conf.d/00_elastic_beanstalk_proxy.conf /etc/nginx/conf.d/00_elastic_beanstalk_proxy.conf.old

Selon les instructions de ce fil .

@BlaM - J'utilise un serveur apache et ELB avec Elastic Bean
Où dois-je mettre le code que vous avez fourni ?
Merci!

Je n'ai aucune idée d'Elastic Bean, mais l'extrait de code que j'ai publié va dans les fichiers hôtes d'Apache.

@tylercb Merci ! ça a marché pour moi ~

Quelqu'un n'utilisant pas nginx face au même problème?

Oui, je rencontre les mêmes problèmes en utilisant Elastic Beanstalk avec un seul serveur (nœud et nginx) sans Elastic Load Balancer.
Je ne sais pas comment passer de http/https à ssl/tls

Même problème avec HAProxy ici

A travaillé pour moi. Merci. Et vous devriez faire attention à la commande

proxy_set_header   Upgrade $http_upgrade;
proxy_set_header   Connection "upgrade";

oui cela l'a fait pour moi aussi.

Je suis également confronté à ce problème. Même avec une erreur 400, la communication websocket entre le client et le serveur est correcte. C'est dans notre environnement de développement.

Quelqu'un peut-il me dire si ce serait un problème dans l'environnement de production.

Pour votre information : la connexion à un backend sails à l'aide de socket.io hébergé sur Heroku à l'aide de l'addon postgres générera cette erreur dans votre navigateur si votre io.sails.url n'est pas https. Cas très spécifique, mais j'espère que cela aidera toute personne ayant la même pile à rechercher cela sur Google

Salut tout le monde,

Je suis également confronté au même problème sur ma machine localhost. Nous utilisons python-flask comme serveur et HTML/CSS/JS comme interface.

Dans le frontend pour se connecter à Websocket Server, nous avons utilisé
var socket = io.connect('ws://url/namespace', { 'transports': ['websocket'] });

Lorsque je lance l'application, il génère une erreur
WebSocket connection to 'ws://url/namespace/socket.io/?EIO=3&transport=websocket' failed: Error during WebSocket handshake: Unexpected response code: 400

Dites-nous si vous avez besoin de plus d'informations.

Toute aide est appréciée.
Merci de l'avoir lu.

Salutations
Ajay

J'ai la même erreur sur l'exemple d'application webrtc. Côté serveur, le code est

var serveur = require('http').Server(app);
var io = require('socket.io')(serveur);
var WebRTC = require('../../');
app.use(express.static(__dirname));
var io = require('socket.io')(serveur);

Après avoir commenté le deuxième "require('socket.io')", le message d'erreur 400 disparaît.

Besoin de creuser plus loin pour savoir pourquoi ... mais vous pouvez vérifier si votre application essaie d'établir la même connexion deux fois.

Salut les gars, je sais que cette discussion dure depuis un certain temps et je voulais publier une ressource qui a résolu ce problème pour moi en utilisant AWS EBS avec Application Load Balancer.

https://mixmax.com/blog/deploying-meteor-to-elastic-beanstalk-1

J'espère que cela aide.

Travis

J'ai le même problème lorsque j'utilise etherpad-lite.
J'ai trouvé une approche pour résoudre le problème Apache ProxyPass.
J'utilise Apache http 2.2 utilise backprot du module http 2.4 wstunnel donc je pense que cela peut aussi réparer la v.2.4.

J'ai d'abord modifié socket.io-client/socket.io.js
recherchez WS.prototype.uri = fonction()
return schema + '://' + (ipv6 ? '[' + this.hostname + ']' : this.hostname) + port + this.path + query;
puis changez pour :

return schema + '://' + (ipv6 ? '[' + this.hostname + ']' : this.hostname) + port + this.path +'ws/'+ query;
enregistrez-le et redémarrez le nœud.

Deuxièmement, modifiez vhost.conf ou ssl.conf
ajoutez ce qui suit à VirtualHost :

        ProxyPass "/etherpad/socket.io/ws/" "ws://localhost:9001/socket.io/"
        ProxyPassReverse "/etherpad/socket.io/ws/" "ws://localhost:9001/socket.io/"

        ProxyPass "/etherpad/socket.io/" "http://localhost:9001/socket.io/"
        ProxyPassReverse "/etherpad/socket.io/" "http://localhost:9001/socket.io/"


        ProxyPass /etherpad/ http://localhost:9001/
        ProxyPassReverse /etherpad/ http://localhost:9001/
        CacheDisable *

        ProxyPreserveHost on
        <Proxy *>
                Options FollowSymLinks MultiViews
                AllowOverride All
                Order allow,deny
                allow from all
        </Proxy>

`

Redémarrez apache httpd, profitez ~

Pour Apache, suivez la réponse @cpres , cela fonctionne. Ma conférence

<VirtualHost *:80>
    ServerAdmin [email protected]
    ServerName reservation.tinker.press

    DocumentRoot /var/www/html/node-js-order-socket-demo
    <Directory />
        Options -Indexes +FollowSymLinks
        AllowOverride None
        Require all granted
    </Directory>

    RewriteEngine on
    RewriteCond %{HTTP:UPGRADE} ^WebSocket$ [NC]
    RewriteCond %{HTTP:CONNECTION} ^Upgrade$ [NC]
    RewriteRule .* ws://127.0.0.1:3001%{REQUEST_URI} [P]

    ProxyRequests Off
    ProxyPreserveHost On
    ProxyVia Full
    <Proxy *>
        Require all granted
    </Proxy>

    ProxyPass / "http://127.0.0.1:3001/"
    ProxyPassReverse / "http://127.0.0.1:3001/"

    ErrorLog ${APACHE_LOG_DIR}/error.log

    # Possible values include: debug, info, notice, warn, error, crit,
    # alert, emerg.
    LogLevel warn

    CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

J'ai également dû ajuster mon équilibreur de charge élastique pour utiliser TCP sur le port 80 au lieu de HTTP sur le port 80.

Est-il possible d'utiliser la directive ProxyPass avec plusieurs nœuds ? J'ai fini par utiliser RewriteRule pour https://github.com/socketio/socket.io/pull/2819 :

Header add Set-Cookie "SERVERID=sticky.%{BALANCER_WORKER_ROUTE}e; path=/" env=BALANCER_ROUTE_CHANGED

<Proxy "balancer://nodes_polling">
    BalancerMember "http://server-john:3000"    route=john
    BalancerMember "http://server-paul:3000"    route=paul
    BalancerMember "http://server-george:3000"  route=george
    BalancerMember "http://server-ringo:3000"   route=ringo
    ProxySet stickysession=SERVERID
</Proxy>

<Proxy "balancer://nodes_ws">
    BalancerMember "ws://server-john:3000"    route=john
    BalancerMember "ws://server-paul:3000"    route=paul
    BalancerMember "ws://server-george:3000"  route=george
    BalancerMember "ws://server-ringo:3000"   route=ringo
    ProxySet stickysession=SERVERID
</Proxy>

RewriteEngine On
RewriteCond %{HTTP:Upgrade} =websocket [NC]
RewriteRule /(.*) balancer://nodes_ws/$1 [P,L]
RewriteCond %{HTTP:Upgrade} !=websocket [NC]
RewriteRule /(.*) balancer://nodes_polling/$1 [P,L]

@darrachequesne Ça a très bien fonctionné ! Merci

Merci!

Pour toute personne qui a encore un problème avec AWS Application Load Balancer, essayez de mettre à jour votre politique de sécurité, j'ai rencontré le même problème même si cela fonctionnait parfaitement bien dans la configuration exacte d'un autre site Web, mais j'ai remarqué que la politique de sécurité avait environ 1 an de retard. La mise à jour vers une version plus récente semble avoir résolu le problème.

Après avoir configuré nginx et le client, j'avais encore du mal à trouver la solution exacte.
Mais @visibleajay a fait ce commentaire et j'ai réalisé que je n'avais pas utilisé la partie { 'transports': ['websocket']} dans la commande io.connect.

Donc, pour tous ceux qui pourraient avoir le même problème,
var socket = io.connect('https://server.com/socket.io-path-here', { 'transports': ['websocket'] });

a fait le travail, avec les bonnes configurations nginx.

@fott1 , sachez que l'utilisation { 'transports': ['websocket'] } signifie qu'il n'y a pas de retour à l'interrogation longue lorsque la connexion Websocket ne peut pas être établie.

Exemple complet avec nginx : https://github.com/socketio/socket.io/tree/master/examples/cluster-nginx

@darrachequesne je crois que vous avez raison, et si j'inclus dans le tableau avec 'websocket' le 'polling', ou 'xhr-polling'? Merci pour l'exemple fourni.

@fott1 la valeur par défaut est en effet ['polling', 'websocket'] ( ref ).

Mais vous devrez utiliser la configuration nginx correcte, car le transport polling (contrairement à websocket ) nécessite que chaque requête soit acheminée vers le même serveur socket.io.

@darrachequesne autrement dit. si j'ai plusieurs instances de serveur, chaque demande doit être acheminée vers la même instance ? Corrigez-moi si je me trompe. Merci pour le tuyau.

@ fott1 oui , c'est vrai. L'explication est ici : https://socket.io/docs/using-multiple-nodes/

FWIW - Je recevais ceci sur mon local (pas de nginx, pas de proxy). Il s'avère qu'avec socket.io, vous devez spécifier explicitement les transports en tant que premier websocket, puis l'interrogation - à la fois dans le client et le serveur. Aucune idée pourquoi ce ne serait pas simplement la valeur par défaut. Ou peut-être que je le fais mal.

Notre problème initial était que nous avions interrogé avant Websocket, sans réaliser que l'ordre était important.

Configuration d'origine :
serveur:
io.set('transports', ['polling', 'websocket']);
client:
var socket = io.connect(server, { reconnect: true });

Nous avons réalisé que notre client interrogeait, nous avons donc supprimé cette option. Ensuite, tout a commencé à échouer et nous avons reçu les 400 mauvaises demandes.

Donc, finalement, nous avons compris que vous deviez spécifier l'ordre à la fois dans le client et le serveur, et si vous ne le faites pas, le client ira directement à l'interrogation, ce qui n'a pas de sens pour moi. Vous penseriez que ce serait par défaut sur websocket en premier.

Réparer:
serveur:
io.set('transports', ['websocket', 'polling']);
client:
var socket = io.connect(server, { reconnect: true, transports: ['websocket', 'polling'] });

Encore une fois, sachez que l'utilisation { 'transports': ['websocket', 'polling'] } signifie qu'il n'y a pas de retour à l'interrogation longue lorsque la connexion Websocket ne peut pas être établie.

Fermons ce problème, veuillez le rouvrir si nécessaire.

J'ai adopté l'approche consistant à "étendre" la configuration nginx par défaut d'Elastic Beanstalk avec des paramètres d'emplacement similaires à certaines suggestions précédentes. Créez une structure de répertoire comme ceci :

 ~/workspace/mon-application/
 |-- .ebextensions
 | `-- nginx
 | `-- conf.d
 | `-- maconf.conf
 `-- web.jar

où myconf.conf , dont le nom est arbitraire tant qu'il se termine par .conf contient ce qui suit :

 serveur {
 emplacement / {
 proxy_pass http://127.0.0.1:5000 ;
 proxy_http_version 1.1 ;
 proxy_set_header Mettre à jour $http_upgrade ;
 proxy_set_header Connexion "mise à niveau" ;
 proxy_set_header Hôte $hôte ;
 }
 }

Assurez-vous d'adapter le numéro de port à vos besoins.

J'ai résolu ce problème en ajoutant uniquement { transports: ['polling'] } .

_

var socket = io.connect(server, {transports : ['polling']});

_

@ hyewon330 À première vue, si vous ne l'avez pas vraiment _résolu_ 😉 Vous avez simplement configuré socket.io pour ne même pas essayer d'utiliser les websockets en premier lieu. Bien sûr, le message d'erreur a disparu, mais maintenant vous forcez socket.io à utiliser l'interrogation même si la connexion entre le client et le serveur prend en charge les websockets. Je ne sais pas si c'est essentiel pour votre application, je voulais juste m'assurer que vous le savez 👌

Pour tous ceux qui utilisent Nginx , la solution @tylercb fonctionne parfaitement.

Cette solution a résolu mon problème avec les applications brillantes. préfet.

@tylercb @rudolfschmidt @juanjoLenero @rwillett @cpres bonjour, j'utilise votre méthode mais elle ne fonctionne pas pour moi. J'en doute parce que j'utilise un autre port plutôt que 8080. Par exemple, mon application est placée dans la machine A avec l'IP 170.8.8.8 surveillant le port 5000, et je mets nginx dans la machine B avec l'IP 170.8.8.2 surveillant également le port 5000. Donc je voulez visiter IP:5000 en B qui passe à IP:5000 en A. Voici ma configuration nginx sur la machine B :

upstream cuitccol.com{ #the name of server cluster
        server 170.8.8.8:5000 max_fails=5 fail_timeout=50s; #for the first web server
        }

    server {
        listen       5000;
        server_name  localhost;

        #charset koi8-r;

        #access_log  logs/host.access.log  main;

        location / {
            proxy_pass http://cuitccol.com;
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection "upgrade";
            proxy_set_header Host $host;
        } 

Je ne sais pas où va mal. Pouvez-vous donner quelques conseils?
merci beaucoup ~
Dans l'attente de votre réponse

Je suis confronté à ce problème depuis un moment maintenant dans tous les environnements, y compris local. @darrachequesne Faites-moi savoir si je dois fournir plus d'informations :

J'ai un node js avec express et le code ci-dessous, qui suit exactement la section socket.io "Comment utiliser":

var app = require('express')();
var server = require('http').createServer(app);
var io = require('socket.io')(server);
io.on('connection', function(){ /* … */ });
server.listen(3000);

Et j'ai mis en place un client très simple, avec juste le code ci-dessous, qui suit exactement la section "Comment utiliser" de socket.io-client :

<script src="/socket.io/socket.io.js"></script>
<script>
  var socket = io('http://localhost:3000');
  socket.on('connect', function(){});
  socket.on('event', function(data){});
  socket.on('disconnect', function(){});
</script>

Malgré une connexion réussie, j'obtiens toujours la même erreur :

La connexion WebSocket à 'ws:// localhost:3000/socket.io/?EIO=3&transport=websocket&sid=EWl2jAgb5dOGXwScAAAB ' a échoué : erreur lors de la négociation WebSocket : code de réponse inattendu : 400

Lorsque vous regardez la console du navigateur, l'erreur pointe vers la ligne 112 de websocket.js, qui indique :

try {
    this.ws = this.usingBrowserWebSocket ? (protocols ? new WebSocket(uri, protocols) : new WebSocket(uri)) : new WebSocket(uri, protocols, opts);
  } catch (err) {
    return this.emit('error', err);
  }

Appréciez toutes les idées...

@rafapetter Vérifiez que vous n'avez pas requis socket.io deux fois, je déplaçais la configuration de socket.io dans www/bin vers app.js et j'ai accidentellement laissé un socket.io requis dans le bac qui provoquait cette erreur.

Il suffit d'ajouter l'option {transports: ['websocket']} au client Socket.io.

ressemble à ca.

import io from 'socket.io-client'
const socket = io('http://localhost:5000', {transports: ['websocket']})

@spookyUnknownUser sur le serveur, le socket.io n'est requis qu'une seule fois.

@prapansak le client est un simple fichier javascript, à l'intérieur d'une fonction window.onload , aucune importation ES6 autorisée. Mais je suis la section Comment utiliser :
<script src="/socket.io/socket.io.js"></script>

Et lors de l'appel du socket comme vous l'avez suggéré:
const socket = io('http://localhost:5000', {transports: ['websocket']})

J'obtiens cette erreur : la connexion WebSocket à 'ws:// localhost:1337/socket.io/?EIO=3&transport=websocket ' a échoué : en-tête de trame non valide

Merci les gars, si vous avez une autre idée, faites le moi savoir et je vais l'essayer ici.

Ok, enfin résolu !

@spookyUnknownUser votre idée m'encourage à chercher plus loin les doublons. Et il s'avère que sur le serveur juste après server.listen je faisais ceci :

io.attach(server, {
  pingInterval: 40000,
  pingTimeout: 25000,
});

Ce qui, d'une certaine manière, je suppose, attache le serveur une deuxième fois. Je l'ai donc supprimé et dès le début, lorsque j'ai besoin de socket.io, j'ai changé pour :

var io = require('socket.io')(server, {
    'pingInterval': 40000,
    'pingTimeout': 25000
});

Maintenant, aucun problème n'est affiché et tout fonctionne bien.

Merci encore pour les éclaircissements les gars

J'ai mon serveur de socket sur EBS (AWS Elastic Beanstalk). J'ai rencontré un problème similaire dans l'environnement de production, mais j'ai pu résoudre le problème sans migrer vers l'équilibreur de charge d'application et sans modifier les configurations ngnix ou apache.

Modifications que j'ai apportées pour résoudre ce problème : au lieu de https, j'ai autorisé ssl sur 443 à mon port d'application et ouvert le port 443 sur mon groupe de sécurité

Pour ceux sur AWS : utilisez l'équilibreur de charge d'application et assurez-vous que la permanence est activée sur le groupe cible.

Il s'avère que cela se produisait par intermittence sur notre serveur lorsqu'il était surchargé et pendant les heures de pointe.

Autoriser les paramètres par défaut pendant que io.connect se déclenche crée des requêtes XHR et une requête WS peu de temps après (comme mentionné ci-dessus). Toutes ces requêtes XHR surchargeaient le serveur et renvoyaient donc les 400 erreurs. En utilisant les suggestions ci-dessus d'ajout de transports: ['websocket']} au code client, le problème a été résolu. Publiera une mise à jour si les 400 erreurs persistent mais cela semble solide pour le moment.

ont le même problème, aucune des modifications suggérées ci-dessus côté serveur ne l'a résolu. Du côté client, j'ai socket = io.connect(); dans le module de réaction et il est capable de déterminer à quel serveur je me connecte.
Fournir le paramètre server pour se connecter est un peu compliqué, mais sans lui, comment puis-je spécifier { reconnect: true, transports: ['websocket', 'polling'] } ? On dirait qu'un paramètre facultatif est le n ° 1, mais le crucial est le n ° 2

J'ai ajouté ceci ci-dessous, et cela a fonctionné pour moi.
emplacement / {
proxy_pass http://localhost :8080;
proxy_http_version 1.1 ;
proxy_set_header Mettre à jour $http_upgrade ;
proxy_set_header Connexion "mise à niveau" ;
proxy_set_header Hôte $hôte ;
}
https://chrislea.com/2013/02/23/proxying-websockets-with-nginx/

J'ai malheureusement le même problème, même avec le bon jeu d'en-têtes.. J'ai créé un stackoverflow avec ma config..

https://stackoverflow.com/questions/50431587/proxy-socket-io-fails-to-connect-with-nginx-node-on-docker

Notez les guillemets doubles ici :

proxy_set_header Connexion "mise à niveau" ;

J'ai reçu ce message en utilisant des guillemets simples, mais l'utilisation de guillemets doubles l'a résolu.

Après environ une heure de dépannage, il semble qu'une configuration supplémentaire soit nécessaire si vous exécutez votre point de terminaison en tant que cluster.

voir ici

la solution tylercb a fonctionné pour moi (NgInx). Merci!

La clé pour nous était le proxy_http_version 1.1; dans la solution de @tylercb

J'ai modifié la configuration NginX sur mon serveur en fonction de ces nombreux commentaires.
Mais cela fonctionne partiellement. Au début, après le redémarrage du serveur, cela fonctionne mal. Principalement avec hard-refresh. Plus tard, cela fonctionne mieux, juste parfois besoin d'un rafraîchissement dur.
Localement avec sails lift ça marche
Mais si j'utilise localement sails lift --prod , j'obtiens la même chose, cette prise ne peut pas se connecter et 400 mauvaises réponses. Mais après quelques essais, il est à nouveau stable.

Cela ne semble toujours pas résolu - aucune solution finale n'a été trouvée pourquoi nous avons cela.

J'ai ajouté les différentes configurations dans la documentation : https://socket.io/docs/using-multiple-nodes/

Toute suggestion d'amélioration est la bienvenue ! => https://github.com/socketio/socket.io-website

Je viens de faire face à ce problème et j'ai toujours une erreur, même désactiver mon nginx. Enfin, le problème à cause du middleware express-status-monitor sur express, cela fait échouer l'appel HTTP lors de la première poignée de main (demande) de WebSocket.

J'essaie de désactiver ce middleware et le WebSocket fonctionne bien

Il y a plusieurs raisons pour lesquelles vous obtiendriez 400 lors de la poignée de main. Voici quelques choses qui pourraient être essayées

1. Activer les pare-feu 443 dans (ufw/Autre) ainsi que les paramètres de la console (AWS/Google cloud/Autre)
2. N'activez pas TLS dans le serveur nodejs. Faites-le via nginx.
3. Utilisez la configuration nginx suivante
   Remarque : Cela ne fonctionne que si votre connexion socket.io fonctionne déjà mais utilise une interrogation longue au lieu de websockets. Ajoutez le code ci-dessous et il commencera à utiliser websocket.

        location /{
            proxy_pass http://127.0.0.1:5000/;
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection "upgrade";
            proxy_set_header Host $host;
        }

Peut-être qu'il sera utile à quelqu'un. J'ai eu cette erreur lors de la création de deux instances de socket.io dans mon application. J'ai appelé io = socketio(server) et j'ai eu l'erreur 400. C'est une sorte d'erreur stupide mais... c'était la mienne.

Assurez-vous d'activer les sessions Sticky dans votre équilibreur de charge d'application (n'utilisez pas l'équilibreur de charge classique). Si vous n'utilisez pas de sessions persistantes, vous obtiendrez probablement les 400 erreurs au hasard.

En effet, lorsque la mise à niveau de l'interrogation vers le websocket est tentée, il est possible que l'équilibreur de charge équilibre la demande de mise à niveau vers un serveur qui n'a jamais rencontré cet identifiant de socket et génère l'erreur 400. Plus de détails ici : https://socket.io/docs/using-multiple-nodes/

De plus, si vous utilisez Elastic Beanstalk, ajoutez le fichier websocket.config suivant dans le dossier .ebextensions pour prendre en charge la mise à niveau de Nginx vers Websockets :

container_commands:
  enable_websockets:
    command: |
     sed -i '/\s*proxy_set_header\s*Connection/c \
              proxy_set_header Upgrade $http_upgrade;\
              proxy_set_header Connection "upgrade";\
      ' /tmp/deployment/config/#etc#nginx#conf.d#00_elastic_beanstalk_proxy.conf

J'ai googlé parce que j'ai eu le même problème et j'utilise aussi nginx. La solution est d'ajouter cette partie

proxy_http_version 1.1 ;
proxy_set_header Mettre à jour $http_upgrade ;
proxy_set_header Connexion "mise à niveau" ;
proxy_set_header Hôte $hôte ;

dans le fichier de configuration nginx comme tylercb mentionné.

Donc au moins cela fonctionne lorsque vous utilisez nginx comme proxy inverse, voici l'explication

WebSocket proxying
To turn a connection between a client and server from HTTP/1.1 into WebSocket, the protocol switch mechanism available in HTTP/1.1 is used.

There is one subtlety however: since the “Upgrade” is a hop-by-hop header, it is not passed from a client to proxied server. With forward proxying, clients may use the CONNECT method to circumvent this issue. This does not work with reverse proxying however, since clients are not aware of any proxy servers, and special processing on a proxy server is required.

Since version 1.3.13, nginx implements special mode of operation that allows setting up a tunnel between a client and proxied server if the proxied server returned a response with the code 101 (Switching Protocols), and the client asked for a protocol switch via the “Upgrade” header in a request.

As noted above, hop-by-hop headers including “Upgrade” and “Connection” are not passed from a client to proxied server, therefore in order for the proxied server to know about the client’s intention to switch a protocol to WebSocket, these headers have to be passed explicitly:

location /chat/ {
    proxy_pass http://backend;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
}
A more sophisticated example in which a value of the “Connection” header field in a request to the proxied server depends on the presence of the “Upgrade” field in the client request header:

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

    server {
        ...

        location /chat/ {
            proxy_pass http://backend;
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection $connection_upgrade;
        }
    }
By default, the connection will be closed if the proxied server does not transmit any data within 60 seconds. This timeout can be increased with the proxy_read_timeout directive. Alternatively, the proxied server can be configured to periodically send WebSocket ping frames to reset the timeout and check if the connection is still alive.

Des news sur ce sujet ? Je l'ai référencé ici https://stackoverflow.com/questions/49575350/websocket-connection-to-wss-error-during-websocket-handshake-unexpected-re

De nombreux utilisateurs ont ce problème à cause de la configuration nginx et sur des serveurs dédiés, vous pouvez le résoudre en utilisant les idées ci-dessus (configuration nginx, etc.), de nombreux utilisateurs n'ont pas accès à ces paramètres, il serait donc formidable d'avoir une sorte de correction de sockets.io à ce sujet...

Personne?

@deemeetree
Si vous utilisez plusieurs nœuds, ce qui me semble possible en raison du message d'erreur sur votre site "Session ID unknown", vous devriez jeter un œil à ma réponse sur StackOverflow (https://stackoverflow.com/a/53163917/6271092) .

Pour faire court, socket.io comme ils disent sur leur site (https://socket.io/docs/using-multiple-nodes/) ,

Si vous envisagez de répartir la charge des connexions entre différents processus ou machines, vous devez vous assurer que les requêtes associées à un identifiant de session particulier se connectent au processus qui les a émises.

Cela est dû au fait que certains transports comme XHR Polling ou JSONP Polling reposent sur le lancement de plusieurs requêtes pendant la durée de vie du "socket". Ne pas activer l'équilibrage persistant entraînera le redoutable :

Error during WebSocket handshake: Unexpected response code: 400

Vous ne pouvez donc pas avoir plusieurs sockets qui fonctionnent sur différents nœuds. Reconfigurez votre serveur comme il est indiqué. Et pour votre Express, configurez votre port comme ceci,
parseInt(your_port) + parseInt(process.env.NODE_APP_INSTANCE);

J'espère que ça aide.

J'ai eu la même erreur en me connectant directement à mon application hébergée sur Windows Server 2008R2 (pas de proxy, pas d'IIS). Seul le matériel intermédiaire stupide entre les deux.

Je suis confronté au même problème sur le serveur Windows 2016, veuillez mentionner votre correctif. Merci

Je suis confronté à ce problème depuis un certain temps. Si quelqu'un a des informations merci de m'aider. J'utilise le serveur apache.

Un indice ? Fonctionne très bien sur dev mais même problème sur SSL.

Utilisation du mode cluster de nœuds PM2 : 4 x 1

Utilisation du proxy apache, toujours aucune idée

Pour ceux qui sont sur httpd2/apache2, j'ai une solution qui semble fonctionner :

    ProxyRequests Off
    <Location />
        ProxyPass http://127.0.0.1:1337/
        ProxyPassReverse http://127.0.0.1:1337/

        RewriteEngine On
        RewriteCond %{HTTP:UPGRADE} ^WebSocket$ [NC]
        RewriteCond %{HTTP:CONNECTION} Upgrade$ [NC]
        RewriteRule /socket.io/(.*) ws://127.0.0.1:1337/socket.io/$1 [P]
    </Location>

Hey @ZeldaZach est-ce pour le fichier .htaccess ? Merci!

Cette configuration se trouve dans mon fichier sites-enabled/site.conf, mais elle devrait également fonctionner dans htaccess.

Tout ce que je peux dire, SSL est le coupable ici :) désactivez le mode SSL flexible cloudflare et passez en mode FULL (STRICT). Bien sûr, cela résoudra le problème,
Si non,

Utilisez localhost:port dans la configuration du proxy inverse.

Pour tous ceux qui utilisent Nginx et React Express (MERN). J'ai eu le même problème parce que je n'ai que la ligne proxy_pass http://localhost:3000; . J'ai ajouté les lignes suivantes basées sur la réponse de @tylercb ci-dessus dans ce fil :

"J'ai eu le même problème, mon application est derrière nginx. Apporter ces modifications à ma configuration Nginx a supprimé l'erreur.

location / {
proxy_pass http://localhost:3000;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_set_header Host $host;
}

Ceci est à l'origine de https://chrislea.com/2013/02/23/proxying-websockets-with-nginx/ "

Si quelqu'un a encore des problèmes avec Nodejs + Express, peut-être que votre problème pourrait être express-status-monitor , comme @slaveofcode l'a mentionné. Comme indiqué dans sa documentation NPM , ce module génère sa propre instance socket.io, vous devez donc remplir le paramètre websocket avec votre instance socket.io principale, ainsi que le paramètre port :

const io = require('socket.io')(server);
const expressStatusMonitor = require('express-status-monitor');
app.use(expressStatusMonitor({
  websocket: io,
  port: app.get('port')
}));

Ceci est ma configuration Apache, notez qu'elle utilise un préfixe de chemin /ws/ , mais sinon cela fonctionne bien.

    ProxyRequests Off
    <Proxy *>
        Order deny,allow
        Allow from all
    </Proxy>

    RewriteEngine On
    RewriteCond %{REQUEST_URI}  ^/ws/socket.io         [NC]
    RewriteCond %{QUERY_STRING} transport=websocket    [NC]
    RewriteRule /ws/(.*)           ws://localhost:6001/$1 [P,L]
    ProxyPass /ws http://127.0.0.1:6001
    ProxyPassReverse /ws http://127.0.0.1:6001

Actuellement confronté à ce problème avec l'exposition du tableau de bord Linkerd (service mesh) pour notre cluster EKS. nous utilisons nginx, donc nous ne savons pas exactement comment nous en sortir pour le moment.

@andrzj OMG mec, tu viens de me sauver.

J'ai eu le même problème, mon application est derrière nginx. Apporter ces modifications à ma configuration Nginx a supprimé l'erreur.

emplacement / {
proxy_pass http://localhost :8080;
proxy_http_version 1.1 ;
proxy_set_header Mettre à jour $http_upgrade ;
proxy_set_header Connexion "mise à niveau" ;
proxy_set_header Hôte $hôte ;
}

Ceci est à l'origine de https://chrislea.com/2013/02/23/proxying-websockets-with-nginx/

Ça marche.

Merci pour le gang d'aide! Si quelqu'un essaie de faire fonctionner cela à côté du trafic HTTPS normal, cela fonctionne maintenant sur Elastic Beanstalk pour moi avec les paramètres suivants :

• Sur Elastic Beanstalk : nginx désactivé (pour l'instant, je n'ai pas encore essayé la configuration ci-dessus).
• Sur Elastic Beanstalk : chargez l'équilibreur comme suit :
• Sur Node/Express : const io = require('socket.io')(3030)
• Sur le client en nommant simplement let connection = io(https://www.myurl.com:3030)

Si vous rencontrez toujours ce problème et que vous avez défini l'origine autorisée dans le serveur de socket en tant que tableau ou origines au lieu de la fonction de rappel pour filtrer les origines, cette erreur se produirait.

Error during WebSocket handshake: Unexpected response code: 400

Dans mon cas, la mise à jour de cette logique

io.origins(['https://foo.example.com:443']);

à ceci

io.origins((origin, callback) => {  
     if (origin !== 'https://foo.example.com') {    
         return callback('origin not allowed', false);  
     }  
    callback(null, true);
});

A travaillé sans aucune erreur lancée.

Obtenir cette même erreur, mais j'ai ajouté dans les configurations pour NGINX et je reçois toujours la même erreur de prise de contact 400. Cependant, j'utilise un équilibreur de charge d'application dans AWS et je l'ai défini sur un groupe cible : 80 et un écouteur 443 qui transmet au groupe cible.

Fichier de configuration NGINX :

`serveur {

listen [::]:80;
listen 80;

server_name <domain_name>;
access_log  /var/log/nginx/access.log;

location / {
    proxy_pass http://127.0.0.1:8000;
    include proxy_params;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_set_header Host $host;
}

location /socket.io {
    include proxy_params;
    proxy_http_version 1.1;
    proxy_cache_bypass $http_upgrade;
    proxy_buffering off;
    proxy_set_header Host $host;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_pass http://127.0.0.1:8000;
}

}`

Et dans mon fichier js j'ai une connexion pour socket.io qui ressemble à ceci :
var socket = io()

Créer une instance manuelle (sans instance express app ) et attribuer un port différent

const io = require('socket.io')(3001, {
  path: '/',
  serveClient: false,
  // below are engine.IO options
  pingInterval: 10000,
  pingTimeout: 5000,
  cookie: false
})

J'ai eu le même problème, mon application est derrière nginx. Apporter ces modifications à ma configuration Nginx a supprimé l'erreur.

emplacement / {
proxy_pass http://localhost :8080;
proxy_http_version 1.1 ;
proxy_set_header Mettre à jour $http_upgrade ;
proxy_set_header Connexion "mise à niveau" ;
proxy_set_header Hôte $hôte ;
}

Ceci est à l'origine de https://chrislea.com/2013/02/23/proxying-websockets-with-nginx/

Il me manquait proxy_set_header Connection "upgrade";

J'ai passé une nuit entière à résoudre ce problème lorsque je commence à utiliser https ou wss ou ssl . Il indique toujours connection stopped before establish avec le code d'erreur 400 .

Il y a quelques minutes, j'ai trouvé une solution pour cela:

0. Flare des nuages

Dans l'onglet SSL/TLS :

• Si vous avez votre propre cert ou SSL ou HTTPS : réglez-le sur Full . (Les 123 étapes suivantes supposent que vous avez votre propre certification https)

• Si vous n'avez qu'un http server : réglez-le sur Flexible . (Le Cloudflare ajoutera automatiquement https ou ssl à votre site Web.)

• Après cela, allez dans l'onglet DNS, définissez Proxied .

Si vous n'êtes pas sûr de ce que vous faites, allez simplement dans l'onglet DNS, définissez DNS only

1. Assurez-vous d'avoir une bonne configuration de proxy.

server {
    listen 80;
    server_name ai-tools-online.xyz;
    return 301 https://ai-tools-online.xyz$request_uri;
}

server {
    listen 443 ssl http2;

    ssl_certificate       /data/v2ray.crt;
    ssl_certificate_key   /data/v2ray.key;
    ssl_protocols         TLSv1.2 TLSv1.3;
    #ssl_ciphers           3DES:RSA+3DES:!MD5;
    server_name ai-tools-online.xyz;

    location / {
        proxy_pass http://127.0.0.1:5000;
    }

    location /socket.io {
        proxy_http_version 1.1;
        proxy_buffering off;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "Upgrade";
        proxy_pass http://127.0.0.1:5000/socket.io;
    }
}

ai-tools-online.xyz est votre domaine, http://127.0.0.1:5000 est votre serveur socket.

2. Assurez-vous que votre serveur Cross-Origin Controls est réglé sur '*' pour autoriser Cross-Origin Access

Pour flask-socketio , il faut utiliser flask_socketio.SocketIO(app, cors_allowed_origins = '*')

3. Vous devez redémarrer le nginx pour que la nouvelle configuration fonctionne

systemctl restart nginx

4. Pour plus de détails sur la façon de définir caddy , consultez les liens suivants :

https://github.com/yingshaoxo/Web-Math-Chat#reverse-proxy-configuration-for-https
https://caddy.community/t/using-caddy-0-9-1-with-socket-io-and-flask-socket-io/508/6
https://www.nginx.com/blog/nginx-nodejs-websockets-socketio/

J'ai googlé parce que j'ai eu le même problème et j'utilise aussi nginx. La solution est d'ajouter cette partie

proxy_http_version 1.1 ;
proxy_set_header Mettre à jour $http_upgrade ;
proxy_set_header Connexion "mise à niveau" ;
proxy_set_header Hôte $hôte ;

dans le fichier de configuration nginx comme tylercb mentionné.

a bien fonctionné pour moi merci!

Si vous utilisez Elastic Beanstalk comme moi pour créer un serveur de nœud,
Lors de la création de l'environnement, on nous demande dans les configurations d'utiliser quel serveur proxy. Dans lequel nginx est pré-rempli ou défini par défaut.
J'ai défini ce serveur proxy sur aucun, puis j'ai continué à créer mon serveur. J'utilisais Elastic Beanstalk pour créer un serveur de nœud dans lequel mon serveur proxy était défini par défaut sur nginx.
Comme il s'agit d'une erreur de configuration du serveur proxy. Après avoir supprimé tout serveur proxy, l'erreur a disparu.

J'ai cherché sur Google pendant des heures et aucune des solutions ci-dessus ne s'appliquait à nous puisque nous n'avions qu'une application nodejs et pas de nginx.

La façon dont nous avons résolu ce problème consistait simplement à désactiver nginx à partir du conteneur -> paramètres de l'équilibreur de charge pour transmettre tout le trafic directement au nœud.

J'ai cherché sur Google pendant des heures et aucune des solutions ci-dessus ne s'appliquait à nous puisque nous n'avions qu'une application nodejs et pas de nginx.

La façon dont nous avons résolu ce problème consistait simplement à désactiver nginx à partir du conteneur -> paramètres de l'équilibreur de charge pour transmettre tout le trafic directement au nœud.

comment as-tu fais ça?

Si vous accédez à Configuration > Équilibreur de charge, vous pouvez trouver une liste déroulante pour le serveur proxy, vous pouvez utiliser nginx, Apache ou le définir sur "aucun" pour passer par toutes les connexions à l'application de nœud.

Cela n'apparaît que si vous créez un environnement avec un équilibreur de charge, ne fonctionne pas pour les instances uniques

Edit : mon commentaire d'origine faisait référence à Elastic Beanstalk

J'ai eu le même problème, mon application est derrière nginx. Apporter ces modifications à ma configuration Nginx a supprimé l'erreur.

emplacement / {
proxy_pass http://localhost :8080;
proxy_http_version 1.1 ;
proxy_set_header Mettre à jour $http_upgrade ;
proxy_set_header Connexion "mise à niveau" ;
proxy_set_header Hôte $hôte ;
}

Ceci est à l'origine de https://chrislea.com/2013/02/23/proxying-websockets-with-nginx/

Alors merci.

Ce document est destiné à ceux qui utilisent laravel-echo-server & Nginx & socket.io & Redis-server avec le serveur séparé entre le projet client et Redis-server.

Veuillez suivre le lien ici .

Merci

J'ai eu ce problème. La mise à jour de ma configuration nginx n'a pas aidé, mais la solution de @ santhosh77h l'a corrigé pour moi. Pour une raison quelconque, passer le tableau des origines autorisées ne fonctionne pas, mais utiliser le rappel fonctionne.

J'utilise les websockets Nest.js (juste un wrapper autour de Socket.io) et j'ai ajouté ce qui suit à ma passerelle :

afterInit(server: Server): any {
    const origins = getOrigins(); // returns an array of origin strings
    server.origins((origin, cb) => {
      if (origins.includes(origin)) {
        cb(null, true)
      } else {
        cb('Invalid origin', false);
      }
    });
  }

J'ai eu le même problème avec NUXT.js avec Node.js / Express exécuté sur AWS Elastic Beanstalk (proxy Nginx) . Il m'a fallu quelques jours pour comprendre cela. Je partage mes points de lecture. Peut-être que quelqu'un le trouvera utile.

Mon environnement est sur Application Load Balancer avec deux ports 80 pour https et 443 pour https avec SSL.

Dans la combinaison de la réponse ci-dessus, un grand merci à @tylercb et à la documentation officielle d' AWS et à la documentation socket.io, j'ai créé un fichier de configuration Nginx qui semble résoudre le problème.

Je vais rapidement décrire les étapes:

Dans mon fichier Node index.js :

const express = require('express')
const app = express()
const server = http.createServer(app)
const io = require('socket.io')(server)
const host = process.env.HOST || '127.0.0.1'
const port = process.env.PORT || 8081

Sur le front-end (un de mes composants):
import io from 'socket.io-client';
dans mes données Vue() :
socket: io()

Enfin, à la racine de l'application, j'ai créé un dossier .ebextensions
Juste à l'intérieur, j'ai créé un fichier 01-proxy.config avec le contenu suivant :

files:
  /etc/nginx/conf.d/01-proxy.conf:
     mode: "000644"
     owner: root
     group: root
     content: |
        upstream nodejs {
          server 127.0.0.1:8081;
          keepalive 256;
        }
        server {
          listen 8080;
          server_name yourdomain.com;

          if ($time_iso8601 ~ "^(\d{4})-(\d{2})-(\d{2})T(\d{2})") {
            set $year $1;
            set $month $2;
            set $day $3;
            set $hour $4;
          }
          access_log /var/log/nginx/healthd/application.log.$year-$month-$day-$hour healthd;
          access_log  /var/log/nginx/access.log  main;

          location / {
              proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
              proxy_set_header Host $host;

              proxy_pass http://nodejs;

              proxy_http_version 1.1;
              proxy_set_header Upgrade $http_upgrade;
              proxy_set_header Connection "upgrade";
          }

          gzip on;
          gzip_comp_level 4;
          gzip_types text/html text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript;

          location /static {
              alias /var/app/current/static;
          }

        }

  /opt/elasticbeanstalk/hooks/configdeploy/post/99_kill_default_nginx.sh:
    mode: "000755"
    owner: root
    group: root
    content: |
      #!/bin/bash -xe
      rm -f /etc/nginx/conf.d/00_elastic_beanstalk_proxy.conf
      service nginx stop 
      service nginx start

container_commands:
  removeconfig:
    command: "rm -f /tmp/deployment/config/#etc#nginx#conf.d#00_elastic_beanstalk_proxy.conf /etc/nginx/conf.d/00_elastic_beanstalk_proxy.conf"

Lectures complémentaires :
configuration nginx

C'est ça. Assez long. Mes excuses et bonne chance.

travaillant pour moi ci-dessous changement dans le serveur ubuntu et ngnix pour le noyau angulaire .net

emplacement / {
proxy_pass http://localhost :8080;
proxy_http_version 1.1 ;
proxy_set_header Mettre à jour $http_upgrade ;
proxy_set_header Connexion "mise à niveau" ;
proxy_set_header Hôte $hôte ;
}

Si quelqu'un a encore des problèmes avec Nodejs + Express, peut-être que votre problème pourrait être express-status-monitor , comme @slaveofcode l'a mentionné. Comme indiqué dans sa documentation NPM , ce module génère sa propre instance socket.io, vous devez donc remplir le paramètre websocket avec votre instance socket.io principale, ainsi que le paramètre port :

const io = require('socket.io')(server);
const expressStatusMonitor = require('express-status-monitor');
app.use(expressStatusMonitor({
  websocket: io,
  port: app.get('port')
}));

Cette info m'a aidé

Assurez-vous que votre connexion socket.io ne passe pas par un équilibreur de charge Amazon. Ou si c'est le cas, faites ceci : http://blog.flux7.com/web-apps-websockets-with-aws-elastic-load-balancing

Si quelqu'un d'autre a eu ce problème en utilisant l'équilibreur de charge AWS, l'article mentionné ne dit pas qu'il est également possible d'utiliser SSL comme protocole d'équilibreur de charge et de continuer à utiliser votre certificat sur cette configuration, en dehors de votre niveau de serveur d'application.

Voici à quoi ressemblent mes auditeurs LB

A bien fonctionné pour moi!

J'ai eu le même problème, mon application est derrière nginx. Apporter ces modifications à ma configuration Nginx a supprimé l'erreur.

emplacement / {
proxy_pass http://localhost :8080;
proxy_http_version 1.1 ;
proxy_set_header Mettre à jour $http_upgrade ;
proxy_set_header Connexion "mise à niveau" ;
proxy_set_header Hôte $hôte ;
}

Ceci est à l'origine de https://chrislea.com/2013/02/23/proxying-websockets-with-nginx/

Oui. Cela a été utile et a fonctionné pour moi aussi.

Assurez-vous que votre connexion socket.io ne passe pas par un équilibreur de charge Amazon. Ou si c'est le cas, faites ceci : http://blog.flux7.com/web-apps-websockets-with-aws-elastic-load-balancing

Si quelqu'un d'autre a eu ce problème en utilisant l'équilibreur de charge AWS, l'article mentionné ne dit pas qu'il est également possible d'utiliser SSL comme protocole d'équilibreur de charge et de continuer à utiliser votre certificat sur cette configuration, en dehors de votre niveau de serveur d'application.

Voici à quoi ressemblent mes auditeurs LB

A bien fonctionné pour moi!

Bravo, ça a marché.

Assurez-vous que votre connexion socket.io ne passe pas par un équilibreur de charge Amazon. Ou si c'est le cas, faites ceci : http://blog.flux7.com/web-apps-websockets-with-aws-elastic-load-balancing

Si quelqu'un d'autre a eu ce problème en utilisant l'équilibreur de charge AWS, l'article mentionné ne dit pas qu'il est également possible d'utiliser SSL comme protocole d'équilibreur de charge et de continuer à utiliser votre certificat sur cette configuration, en dehors de votre niveau de serveur d'application.

Voici à quoi ressemblent mes auditeurs LB

A bien fonctionné pour moi!

dans ce cas votre application tourne sur 80 ?