Socket.io: Error durante el protocolo de enlace de WebSocket: código de respuesta inesperado: 400

Estoy experimentando exactamente el mismo problema en este momento, ¿alguna ayuda?

También tengo este problema desde que instalé un certificado SSL en mi dominio.

Aquí hay una mejor descripción del problema: http://stackoverflow.com/questions/28025073/error-while-websocket-handshake-unexpected-response-code-400-with-nginx-proxy

También tengo un problema similar al conectarme con una de las bibliotecas de Android. Los sockets web no se conectarán a https a través de HAproxy haciendo terminación ssl o permitiendo que el nodo haga ssl directamente. Sin embargo, el sondeo largo funciona bien

Lo resuelvo cambiando el dominio a la verdadera dirección IP:

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

Tuve el mismo problema, mi aplicación está detrás de nginx. Hacer estos cambios en mi configuración de Nginx eliminó el error.

ubicación / {
proxy_pass http://localhost :8080;
proxy_http_versión 1.1;
proxy_set_header Actualizar $http_upgrade;
proxy_set_header Conexión "actualizar";
proxy_set_header Anfitrión $anfitrión;
}

Esto es originalmente de https://chrislea.com/2013/02/23/proxying-websockets-with-nginx/

Mismo problema aquí en el servidor de producción. Las máquinas de desarrollo no muestran el error.

Lo extraño es que la conexión está funcionando. Puedo enviar mensajes a través de WebSockets desde el servidor y el cliente los recibe. También puedo ver que se establece la conexión WebSocket en el servidor.

Acabo de recibir este error en las herramientas de desarrollo que dice:

La conexión de WebSocket a ' wss://.../socket.io/?EIO=3&transport=websocket&sid=2b_v_BXtbwzl5z2yAAAI ' falló: Error durante el protocolo de enlace de WebSocket: Código de respuesta inesperado: 400

Estoy usando Apache ProxyPass para enviar conexiones a node.

Lo mismo aquí: funcional completo pero mensaje de error en las herramientas de desarrollo. En otro lugar, leí que está relacionado con la versión de apache, usando 2.2.14 en esta máquina.

Asegúrese de que su conexión socket.io no esté pasando por un Amazon Load Balancer. O si es así, haga esto: http://blog.flux7.com/web-apps-websockets-with-aws-elastic-load-balancing

El mismo problema aquí, solo en el entorno de producción.
Websockets parece funcionar correctamente, la aplicación funciona sin problemas. Pero en el registro de la consola puedo ver este error.

Estoy usando Nginx y solo un servidor para el nodo, por lo que parece que no hay un problema de equilibrio de carga. Ya estaba usando la solución sugerida por tylercb (con la excepción de "proxy_set_header Host $host;") y no está resolviendo el problema.

También tengo problemas, pero funcionan bien...

Tuve el mismo problema. ¿Estás usando CloudFlare? Actualmente, solo su plan Enterprise es compatible con WebSockets.

Resuelto para mí. Se debió a una dirección incorrecta de socket.io en la configuración de nginx, que no coincidía con la ruta usando el websocket.

Busqué en Google porque tengo el mismo problema y también uso nginx. La solución es agregar esta parte.

proxy_http_versión 1.1;
proxy_set_header Actualizar $http_upgrade;
proxy_set_header Conexión "actualizar";
proxy_set_header Anfitrión $anfitrión;

en el archivo de configuración nginx como tylercb mencionado.

Trabajó para mi. Gracias.

Obtuve el mismo error al conectarme directamente a mi aplicación alojada en Windows Server 2008R2 (sin proxy, sin IIS). Solo hardware intermedio tonto en el medio.

Funciona bien después de cambiar el nombre de host a la dirección IP, es decir, 127.0.0.1:9000. puede ser causado por httpd ProxyPassReverse

En mi caso, el problema se debió a que Cloudfare no admitía websockets en el plan gratuito. Apagué CloudFare para el dominio y funcionó.

Solo necesitaba agregar algunas condiciones de reescritura de Apache para manejar los websockets, más información aquí:
http://stackoverflow.com/a/27534443/2044993

Sé que este es un problema antiguo, pero dado que ocupa un lugar destacado en los resultados de búsqueda de Google, esto podría ayudar a las personas:

La razón por la que la conexión aún funciona incluso con este error es que socket.io está recurriendo a AJAX, que no es óptimo y debe corregir la configuración de su servidor.

Por cierto, este problema debería permanecer cerrado, no es un problema de socket.io.

@arosenfeld-mentel Sigo leyendo las publicaciones sobre su comentario de que "este no es un problema de socket.io", pero no veo dónde alguien dice CUÁL es realmente el problema. Lo veo yo mismo aunque, como dices, la conexión todavía parece funcionar. Cualquier consejo sería recibido con mucha gratitud. ¡Gracias!

El problema podría ser cualquier cosa realmente, necesita depurar toda su configuración. Para mí fue NGINX, que como proxy inverso necesita los ajustes de configuración adicionales publicados anteriormente muchas veces. Porque tú podrías ser otra cosa.

Comience por depurar la conexión local, haga que funcione sin la advertencia, luego muévase al servidor de producción y asegúrese de obtener firewalls, servidores frontales y proxy para cooperar con WebSockets.

No es un problema de socket.io, pero es un problema de WebSockets, así que asegúrese de que el servidor y el cliente funcionen bien con WebSockets.

Gracias por la respuesta. Todo funciona localmente o a través de nuestra VPN, pero una vez que interviene nuestro firewall, aparecen los mensajes. Supongo que el firewall está interfiriendo de alguna manera y tendremos que aprender a depurar ese problema en lugar de culpar a socket.io. Gracias de nuevo.

Teniendo exactamente el mismo problema. También he creado una pregunta de stackoverflow (http://stackoverflow.com/questions/34439546/socket-io-with-apache-proxy), pero las cosas sugeridas no me han funcionado todavía.

Puse estos encabezados en nginx pero sigo obteniendo lo mismo, pero no en el navegador sino en https://toolbox.seositecheckup.com

También tuve este problema, parece que mi host virtual (a través de nginx) no estaba configurado correctamente para aceptar el encabezado de actualización. La solución de @tylercb de hace aproximadamente un año lo arregló^

@tylercb funcionó para mí.

+1
Este error ocurrió en el entorno de turno abierto

Pensé que podría ser útil si documentaba exactamente lo que hice para resolver el problema. Esto es simplemente una combinación de las diversas publicaciones anteriores puestas en una publicación simple para que cualquier otra persona que encuentre este problema pueda obtener una posible solución fácilmente. No tomo ningún crédito por el trabajo duro.

Estamos corriendo

1. Servidor Ubuntu 14.04 LTS,
2. Versión de nginx: nginx/1.4.6 (Ubuntu) como proxy inverso y puerta de enlace SSL.
3. NO tenemos Apache en absoluto. Se elimina del sistema.
4. Tenemos un servidor node.js ejecutándose detrás de nginx v0.10.25. Este escucha en el puerto 4001. El acceso externo es a través del puerto 4000.
5. Ejecutamos ufw en el frente y simplemente dejamos pasar el puerto 4000.
6. Administramos nuestros propios servidores y no usamos Cloudflare ni Openshift
7. No usamos ningún balanceador de carga (todavía).

Tuvimos los mismos problemas que otras personas de

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

Actualizamos el archivo nginx en /etc/nginx/sites-enabled/default para que diga lo siguiente: (tenga en cuenta que hemos sacado nuestros nombres de dominio)

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";
        }
}

Solo necesitábamos agregar

1. proxy_http_versión 1.1;
2. proxy_set_header Actualizar $http_upgrade;
   3.proxy_set_header Conexión "actualizar";

como ya teniamos

1. proxy_set_header Anfitrión $anfitrión;
2. contraseña_proxy http://127.0.0.1 :4001;

Espero que esto ayude, funcionó para nosotros.

Gracias por la ayuda,

Robar

Tengo el mismo problema cuando me autentico con CAS (no con la forma clásica), y estoy usando Apache con LetEncrypt SSL como proxy, ¿hay alguna configuración específica para establecer?

Intentando implementar la aplicación Node.js en AWS Elastic BeanStalk.
Agregué la carpeta .ebextensions a la raíz del servidor, y adentro agregué el archivo nginx.config que se ve así:

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;

Sigo recibiendo el error 400, pero al menos todo el resto del zócalo funciona.

Para referencia: esta es la única solución de configuración funcional que encontré para socket.io 1.x y 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]

usando otro puerto, puede funcionar

@BlaM gracias por la configuración de trabajo!

Para cualquier persona que experimente este problema en AWS Elastic Beanstalk, este archivo .ebextension funcionó para mí:

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

Según las instrucciones de este hilo .

@BlaM : estoy usando un servidor apache y ELB con Elastic Bean
¿Dónde debo poner el código que proporcionaste?
¡Gracias!

No tengo ni idea sobre Elastic Bean, pero el fragmento de código que publiqué va a los archivos de host de Apache.

@tylercb ¡Gracias! a mi me funciono~

¿Alguien que no use nginx enfrente el mismo problema?

Sí, tengo los mismos problemas al usar Elastic Beanstalk con un solo servidor (nodo y nginx) sin Elastic Load Balancer.
No se como cambiar de http/https a ssl/tls

Mismo problema con HAProxy aquí

Trabajó para mi. Gracias. Y debes prestar atención al pedido.

proxy_set_header   Upgrade $http_upgrade;
proxy_set_header   Connection "upgrade";

sí esto lo hizo para mí también.

También estoy enfrentando este problema. Incluso con el error 400, la comunicación websocket entre el cliente y el servidor está bien. Esto está en nuestro entorno de desarrollo.

¿Alguien puede decirme si esto sería un problema en el entorno de producción?

FYI: conectarse a un backend de Sails usando socket.io alojado en Heroku usando el complemento postgres arrojará este error en su navegador si su io.sails.url no es https. Caso muy específico, pero espero que esto ayude a cualquier persona con la misma pila que busque esto en Google

Hola a todos,

También estoy enfrentando el mismo problema en mi máquina localhost. Estamos usando python-flask como servidor y HTML/CSS/JS como interfaz.

En el Frontend para conectar con Websocket Server hemos utilizado
var socket = io.connect('ws://url/namespace', { 'transports': ['websocket'] });

Cuando ejecuto la aplicación me arroja un error
WebSocket connection to 'ws://url/namespace/socket.io/?EIO=3&transport=websocket' failed: Error during WebSocket handshake: Unexpected response code: 400

Díganos si necesita más información.

Cualquier ayuda es apreciada.
Gracias por leerlo.

Saludos
Ajay

Recibí el mismo error en la aplicación de muestra webrtc. En el lado del servidor, el código es

servidor var = require('http').Servidor(aplicación);
var io = require('socket.io')(servidor);
var WebRTC = require('../../');
app.use(express.static(__dirname));
var io = require('socket.io')(servidor);

Después de comentar el segundo "requerir ('socket.io')", el mensaje de error 400 desaparece.

Necesito profundizar más para saber por qué ... pero puede verificar si su aplicación intenta hacer la misma conexión dos veces.

Hola chicos, sé que esta discusión ha durado un tiempo y quería publicar un recurso que resolvió este problema para mí usando AWS EBS con Application Load Balancer.

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

Espera que esto ayude.

Travis

Tengo el mismo problema cuando uso etherpad-lite.
Encontré un enfoque para solucionar el problema de Apache ProxyPass.
Estoy usando Apache http 2.2 usa backprot del módulo wstunnel de http 2.4, así que creo que eso también puede arreglar v.2.4.

Primero he modificado socket.io-client/socket.io.js
busque WS.prototype.uri = function()
return schema + '://' + (ipv6 ? '[' + this.hostname + ']' : this.hostname) + port + this.path + query;
luego cambia a:

return schema + '://' + (ipv6 ? '[' + this.hostname + ']' : this.hostname) + port + this.path +'ws/'+ query;
guárdelo y reinicie el nodo.

Segundo, modifique vhost.conf o ssl.conf
agregue lo siguiente a 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>

`

Reinicie apache httpd, disfrute ~

Para Apache, siga la respuesta de @cpres , funciona. mi conferencia

<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>

También tuve que ajustar mi balanceador de carga elástico para usar TCP sobre el puerto 80 en lugar de HTTP sobre el puerto 80.

¿Es posible usar la directiva ProxyPass con varios nodos? Terminé usando RewriteRule para 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 ¡Funcionó muy bien! Gracias

¡Gracias!

Para cualquiera que todavía tenga un problema con AWS Application Load Balancer, intente actualizar su política de seguridad. Me encontré con el mismo problema a pesar de que funcionaba perfectamente bien en la configuración exacta para otro sitio web, pero noté que la política de seguridad estaba atrasada aproximadamente 1 año. Actualizarlo a uno más nuevo parece haber resuelto el problema.

Habiendo configurado nginx y el cliente, todavía estaba luchando por encontrar la solución exacta.
Pero @visibleajay hizo ese comentario y me di cuenta de que no usé la parte { 'transports': ['websocket'] } en el comando io.connect.

Entonces, para cualquiera que pueda estar en el mismo problema,
var socket = io.connect('https://server.com/socket.io-path-here', { 'transports': ['websocket'] });

hizo el trabajo, junto con las configuraciones correctas de nginx.

@ fott1 , tenga en cuenta que el uso { 'transports': ['websocket'] } significa que no hay respaldo para el sondeo largo cuando no se puede establecer la conexión websocket.

Ejemplo completo con nginx: https://github.com/socketio/socket.io/tree/master/examples/cluster-nginx

@darrachequesne creo que tiene razón, ¿qué pasa si incluyo en la matriz junto con 'websocket' el 'sondeo' o 'xhr-polling'? Gracias por el ejemplo proporcionado.

@fott1 el valor predeterminado es de hecho ['polling', 'websocket'] ( ref ).

Pero deberá usar la configuración nginx correcta, ya que el transporte polling (a diferencia websocket ) requiere que cada solicitud se enrute al mismo servidor socket.io.

@darrachequesne en otras palabras. si tengo varias instancias de servidor, ¿cada solicitud debe enrutarse a la misma instancia? Corrígeme si estoy equivocado. Gracias por el consejo.

@ fott1 sí, así es. La explicación está aquí: https://socket.io/docs/using-multiple-nodes/

FWIW: estaba obteniendo esto en mi local (sin nginx, sin proxies). Resulta que con socket.io debe especificar explícitamente los transportes como primer websocket, luego sondeo, tanto en el cliente como en el servidor. No tengo idea de por qué eso no sería solo el valor predeterminado. O tal vez lo estoy haciendo mal.

Nuestro problema original era que teníamos encuestas antes de websocket, sin darnos cuenta de que el orden importa.

Configuración original:
servidor:
io.set('transports', ['polling', 'websocket']);
cliente:
var socket = io.connect(server, { reconnect: true });

Nos dimos cuenta de que nuestro cliente estaba encuestando, así que lo eliminamos como una opción. Luego, todo comenzó a fallar y recibimos la solicitud incorrecta 400.

Finalmente, descubrimos que debe especificar el orden tanto en el cliente como en el servidor, y si no lo hace, el cliente irá directamente a la encuesta, lo que no tiene mucho sentido para mí. Uno pensaría que sería predeterminado a websocket primero.

Arreglar:
servidor:
io.set('transports', ['websocket', 'polling']);
cliente:
var socket = io.connect(server, { reconnect: true, transports: ['websocket', 'polling'] });

Nuevamente, tenga en cuenta que el uso { 'transports': ['websocket', 'polling'] } significa que no hay respaldo para el sondeo largo cuando no se puede establecer la conexión websocket.

Cerremos ese problema, vuelva a abrirlo si es necesario.

Tomé el enfoque de "extender" la configuración nginx predeterminada de Elastic Beanstalk con la configuración de ubicación similar a algunas sugerencias anteriores. Crea una estructura de directorios así:

 ~/espacio de trabajo/mi-aplicación/
 |-- extensiones .eb
 | `--nginx
 | `-- conf.d
 | `-- miconf.conf
 `-- web.jar

donde myconf.conf , cuyo nombre es arbitrario siempre que termine en .conf contiene lo siguiente:

 servidor {
 ubicación / {
 contraseña_proxy http://127.0.0.1:5000;
 proxy_http_versión 1.1;
 proxy_set_header Actualizar $http_upgrade;
 proxy_set_header Conexión "actualizar";
 proxy_set_header Anfitrión $anfitrión;
 }
 }

Asegúrese de ajustar el número de puerto a sus necesidades.

Resolví este problema agregando solo {transports: ['polling'] } .

_

var socket = io.connect(servidor, {transportes: ['sondeo']});

_

@ hyewon330 Aparentemente , si realmente no lo _resolvió_ 😉 Simplemente configuró socket.io para que ni siquiera intentara usar websockets en primer lugar. Claro, el mensaje de error desapareció, pero ahora está obligando a socket.io a usar el sondeo incluso si la conexión entre el cliente y el servidor _sería_ compatible con websockets. No estoy seguro de si eso es crítico para su aplicación, solo quería asegurarme de que lo sabe 👌

Para cualquiera que use Nginx , la solución @tylercb funciona perfectamente.

Esta solución solucionó mi problema con aplicaciones brillantes. prefecto.

@tylercb @rudolfschmidt @juanjoLenero @rwillett @cpres hola, uso tu método pero no me funciona. Dudo si porque uso otro puerto en lugar de 8080. Por ejemplo, mi aplicación se coloca en la máquina A con IP 170.8.8.8 monitoreando el puerto 5000, y coloco nginx en la máquina B con IP 170.8.8.2 también monitoreando el puerto 5000. Entonces yo quiero visitar IP: 5000 en B que salta a IP: 5000 en A. La siguiente es mi configuración nginx en la máquina 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;
        } 

No sé dónde falla. ¿Puedes dar algunos consejos?
muchas gracias ~
Esperamos su respuesta

Me enfrento a este problema desde hace un tiempo en todos los entornos, incluido el local. @darrachequesne Avíseme si necesito proporcionar más información:

Tengo un nodo js con express y el siguiente código, que sigue exactamente la sección "Cómo usar" de socket.io:

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

Y configuré un cliente muy simple, con solo el código a continuación, que sigue exactamente la sección "Cómo usar" 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>

A pesar de conectarme con éxito, sigo recibiendo este mismo error:

La conexión de WebSocket a 'ws:// localhost:3000/socket.io/?EIO=3&transport=websocket&sid=EWl2jAgb5dOGXwScAAAB ' falló: Error durante el protocolo de enlace de WebSocket: Código de respuesta inesperado: 400

Al mirar la consola del navegador, el error apunta a la línea 112 de websocket.js, que dice:

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);
  }

Agradezco cualquier idea...

@rafapetter Verifique que no haya requerido socket.io dos veces, estaba moviendo la configuración de socket.io en www/bin a app.js y accidentalmente dejé un socket requerido en el contenedor que estaba causando este error.

Simplemente agregando la opción {transports: ['websocket']} al cliente Socket.io.

se parece a esto.

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

@spookyUnknownUser en el servidor, solo se requiere socket.io una vez.

@prapansak el cliente es un archivo javascript simple, dentro de una función window.onload , no se permite la importación de ES6. Pero sigo la sección Cómo usar:
<script src="/socket.io/socket.io.js"></script>

Y al llamar al socket como lo sugirió:
const socket = io('http://localhost:5000', {transports: ['websocket']})

Recibo este error: la conexión de WebSocket a 'ws:// localhost:1337/socket.io/?EIO=3&transport=websocket ' falló: encabezado de marco no válido

Gracias chicos, si tienen alguna otra idea, háganmelo saber y lo pruebo aquí.

Ok, finalmente lo resolví!

@spookyUnknownUser tu idea me anima a buscar más duplicaciones. Y resulta que, en el servidor justo después de server.listen , estaba haciendo esto:

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

Lo cual, en cierto modo, supongo que está conectando el servidor por segunda vez. Así que lo eliminé y justo al principio, cuando requería socket.io, cambié a:

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

Ahora, no se muestran problemas y todo funciona bien.

Gracias de nuevo por las ideas chicos

Tengo mi servidor de socket en EBS (AWS Elastic beanstalk). Enfrenté un problema similar en el entorno de producción, pero pude solucionar el problema sin migrar al balanceador de carga de la aplicación y sin cambiar las configuraciones de ngnix o apache.

Cambios que hice para resolver este problema: en lugar de https, permití SSL en 443 en el puerto de mi aplicación y abrí el puerto 443 en mi grupo de seguridad

Para aquellos en AWS: use el balanceador de carga de aplicaciones y asegúrese de tener la permanencia habilitada en el grupo objetivo.

Resulta que esto sucedía de manera intermitente en nuestro servidor cuando estaba sobrecargado y dentro del tiempo de uso máximo.

Permitir la configuración predeterminada mientras io.connect se dispara crea solicitudes XHR y una solicitud WS poco después (como se mencionó anteriormente). Todas estas solicitudes XHR sobrecargaban el servidor y, por lo tanto, devolvían los errores 400. Al usar las sugerencias anteriores de agregar transports: ['websocket']} al código del cliente, el problema se resolvió. Publicaré una actualización si persisten los 400 errores, pero parece sólido por ahora.

tiene el mismo problema, ninguno de los cambios sugeridos en el lado del servidor lo resolvió. En el lado del cliente, tengo socket = io.connect(); en el módulo de reacción y puede averiguar a qué servidor me estoy conectando.
Proporcionar el parámetro server para conectar es un poco complicado, pero sin él, ¿cómo puedo especificar { reconnect: true, transports: ['websocket', 'polling'] } ? Parece que un parámetro opcional es el n. ° 1, pero el crucial es el n. ° 2

Agregué esto a continuación, y funcionó para mí.
ubicación / {
proxy_pass http://localhost :8080;
proxy_http_versión 1.1;
proxy_set_header Actualizar $http_upgrade;
proxy_set_header Conexión "actualizar";
proxy_set_header Anfitrión $anfitrión;
}
https://chrislea.com/2013/02/23/proxying-websockets-with-nginx/

Desafortunadamente, tengo el mismo problema, incluso con los buenos encabezados establecidos. Creé un desbordamiento de pila con mi configuración.

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

Tome nota de las comillas dobles aquí:

proxy_set_header Conexión "actualizar";

Recibí este mensaje usando comillas simples pero usando comillas dobles lo resolví.

Después de aproximadamente una hora de resolución de problemas, parece que se necesita alguna configuración adicional si está ejecutando su punto final como un clúster.

ver aquí

La solución tylercb funcionó para mí (NgInx). ¡Gracias!

La clave para nosotros fue el proxy_http_version 1.1; en la solución de @tylercb

Edité la configuración de NginX en mi servidor de acuerdo con esos muchos comentarios.
Pero funciona parcialmente. Al principio, después de reiniciar el servidor, funciona mal. Principalmente con hard-refresh. Más tarde funciona mejor, solo que a veces necesita una actualización completa.
Localmente con sails lift funciona
Pero si estoy usando localmente sails lift --prod entonces obtengo lo mismo, ese socket no puede conectarse y 400 mala respuesta. Pero después de algunos intentos vuelve a estar estable.

Parece que aún no se ha resuelto: no se encontró una solución final por la que tenemos esto.

Agregué las diversas configuraciones en la documentación: https://socket.io/docs/using-multiple-nodes/

Cualquier sugerencia de mejora es bienvenida! => https://github.com/socketio/socket.io-sitio web

Acabo de enfrentar este problema y todavía tengo un error, incluso desactivo mi nginx. Finalmente, el problema debido al middleware express-status-monitor en Express, hace que la llamada HTTP en el primer protocolo de enlace (solicitud) de WebSocket falle.

Trato de deshabilitar ese middleware y el WebSocket funciona bien

Hay varias razones por las que obtendrías 400 durante el apretón de manos. Las siguientes son algunas cosas que podrían intentarse

1. Habilite 443 en (ufw/Otro) cortafuegos, así como la configuración de la consola (AWS/Google cloud/Otro)
2. No habilite TLS en el servidor nodejs. Hazlo a través de nginx.
3. Use la siguiente configuración de nginx
   Nota: Esto solo funciona si su conexión socket.io ya está funcionando pero usa un sondeo largo en lugar de websockets. Agregue el código a continuación y comenzará a usar 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;
        }

Tal vez sea de ayuda para alguien. Recibí este error cuando creé dos instancias de socket.io en mi aplicación. Llamé a io = socketio(server) twise y obtuve el error 400. Eso es algún tipo de error estúpido pero... eso fue mío.

Asegúrese de habilitar las sesiones Sticky en el balanceador de carga de su aplicación (no use el balanceador de carga clásico). Si no usa sesiones pegajosas, probablemente obtendrá los 400 errores al azar.

Esto se debe a que cuando se intenta la actualización de sondeo a websocket, es posible que el balanceador de carga equilibre la solicitud de actualización a un servidor que nunca encontró esta identificación de socket y arroja el error 400. Más detalles aquí: https://socket.io/docs/using-multiple-nodes/

Además, si usa beanstalk elásticos, agregue el siguiente archivo websocket.config en la carpeta .ebextensions para admitir la actualización de Nginx a 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

Busqué en Google porque tengo el mismo problema y también uso nginx. La solución es agregar esta parte.

proxy_http_versión 1.1;
proxy_set_header Actualizar $http_upgrade;
proxy_set_header Conexión "actualizar";
proxy_set_header Anfitrión $anfitrión;

en el archivo de configuración nginx como tylercb mencionado.

Entonces, al menos esto funciona cuando usa nginx como proxy inverso, aquí está la explicación

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.

¿Alguna novedad sobre este asunto? Lo mencioné aquí https://stackoverflow.com/questions/49575350/websocket-connection-to-wss-error-durante-websocket-handshake-unexpected-re

Muchos usuarios tienen este problema debido a la configuración de nginx y, mientras que en servidores dedicados, puede solucionarlo usando las ideas anteriores (configuración de nginx, etc.) muchos usuarios no tienen acceso a esta configuración, por lo que sería genial tener algún tipo de corrección de sockets.io en esto...

¿Nadie?

@deemeetree
Si usa varios nodos, lo que me parece posible debido al mensaje de error en su sitio "ID de sesión desconocido", debe consultar mi respuesta en StackOverflow (https://stackoverflow.com/a/53163917/6271092) .

Para ser breve, socket.io como dicen en su sitio (https://socket.io/docs/using-multiple-nodes/) ,

Si planea distribuir la carga de conexiones entre diferentes procesos o máquinas, debe asegurarse de que las solicitudes asociadas con una identificación de sesión en particular se conecten al proceso que las originó.

Esto se debe a que ciertos transportes como XHR Polling o JSONP Polling dependen de disparar varias solicitudes durante la vida útil del "socket". Si no se habilita el equilibrio persistente, se producirá lo temido:

Error during WebSocket handshake: Unexpected response code: 400

Por lo tanto, no puede tener múltiples sockets que funcionen en diferentes nodos. Reconfigure su servidor como dice. Y para su Express, configure su puerto así,
parseInt(your_port) + parseInt(process.env.NODE_APP_INSTANCE);

Espero eso ayude.

Obtuve el mismo error al conectarme directamente a mi aplicación alojada en Windows Server 2008R2 (sin proxy, sin IIS). Solo hardware intermedio tonto en el medio.

Estoy enfrentando el mismo problema en el servidor de Windows 2016, mencione su solución. Gracias

He estado enfrentando este problema durante bastante tiempo. Si alguien tiene alguna información por favor ayuda. Estoy usando el servidor apache.

¿Cualquier pista? Funciona muy bien en desarrollo pero el mismo problema en SSL.

Uso del modo de clúster de nodos PM2: 4 x 1

Usando el proxy apache, todavía no tengo idea

Para aquellos que están en httpd2/apache2, tengo una solución que parece funcionar:

    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>

Oye , @ZeldaZach , ¿eso es para el archivo .htaccess? ¡Gracias!

Esta configuración está en mi archivo sites-enabled/site.conf, pero también debería funcionar en htaccess.

Todo lo que puedo decir es que SSL es el culpable aquí :) deshabilite el modo SSL flexible de cloudflare y cambie al modo COMPLETO (ESTRICTO). Seguro que esto solucionará el problema,
Que no,

Utilice localhost:port en la configuración de proxy inverso.

Para cualquiera aquí que use Nginx y React Express (MERN). Tuve el mismo problema porque solo tenía la línea proxy_pass http://localhost:3000; . Agregué las siguientes líneas basadas en la respuesta @tylercb de arriba en este hilo:

"Tuve el mismo problema, mi aplicación está detrás de nginx. Hacer estos cambios en mi configuración de Nginx eliminó el error.

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;
}

Esto es originalmente de https://chrislea.com/2013/02/23/proxying-websockets-with-nginx/ "

Si alguien todavía tiene problemas para usar Nodejs + Express, tal vez su problema podría ser express-status-monitor , como mencionó @slaveofcode . Como se indica en su documentación de NPM , este módulo genera su propia instancia de socket.io, por lo que debe completar el parámetro websocket con su instancia principal de socket.io, así como el parámetro de puerto:

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

Esta es mi configuración de Apache, observe que está usando un prefijo de ruta /ws/ , pero por lo demás funciona 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

Actualmente enfrenta este problema al exponer el tablero de Linkerd (malla de servicio) para nuestro clúster EKS. usamos nginx, por lo que no estoy exactamente seguro de cómo salir de ese en este momento.

@andrzj Dios mío , acabas de salvarme.

Tuve el mismo problema, mi aplicación está detrás de nginx. Hacer estos cambios en mi configuración de Nginx eliminó el error.

ubicación / {
proxy_pass http://localhost :8080;
proxy_http_versión 1.1;
proxy_set_header Actualizar $http_upgrade;
proxy_set_header Conexión "actualizar";
proxy_set_header Anfitrión $anfitrión;
}

Esto es originalmente de https://chrislea.com/2013/02/23/proxying-websockets-with-nginx/

funciona.

¡Gracias por la ayuda pandilla! Si alguien está tratando de hacer que esto funcione junto con el tráfico HTTPS normal, ahora está funcionando en Elastic Beanstalk para mí con la siguiente configuración:

• En Elastic Beanstalk: nginx desactivado (por ahora, aún no he probado la configuración anterior).
• En Elastic Beanstalk: cargue el balanceador de la siguiente manera:
• En Nodo/Express: const io = require('socket.io')(3030)
• En el cliente simplemente nombrando let connection = io(https://www.myurl.com:3030)

Si todavía tienen este problema y han establecido el origen permitido en el servidor de socket como matriz u orígenes en lugar de la función de devolución de llamada para filtrar los orígenes, arrojaría este error.

Error during WebSocket handshake: Unexpected response code: 400

En mi caso actualizando esta lógica.

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

a esto

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

Funcionó sin ningún error arrojado.

Obtuve este mismo error, pero agregué las configuraciones para NGINX y sigo recibiendo el mismo error de protocolo de enlace 400. Sin embargo, estoy usando un balanceador de carga de aplicaciones en AWS y lo tengo configurado en un grupo objetivo: 80 y un oyente 443 que reenvía al grupo objetivo.

Archivo de configuración NGINX:

`servidor {

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;
}

}`

Y dentro de mi archivo js tengo una conexión para socket.io que se ve así:
var socket = io()

Cree una instancia manual (sin una instancia express app ) y asigne un puerto diferente

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

Tuve el mismo problema, mi aplicación está detrás de nginx. Hacer estos cambios en mi configuración de Nginx eliminó el error.

ubicación / {
proxy_pass http://localhost :8080;
proxy_http_versión 1.1;
proxy_set_header Actualizar $http_upgrade;
proxy_set_header Conexión "actualizar";
proxy_set_header Anfitrión $anfitrión;
}

Esto es originalmente de https://chrislea.com/2013/02/23/proxying-websockets-with-nginx/

me faltaba proxy_set_header Connection "upgrade";

He pasado toda una noche para resolver este problema cuando empiezo a usar https o wss o ssl . Siempre dice connection stopped before establish con código de error 400 .

Hace solo unos minutos, encontré una solución para eso:

0. Llamarada de la nube

En la pestaña SSL/TLS:

• Si tiene su propio cert o SSL o HTTPS : configúrelo en Full . (Los siguientes 123 pasos asumen que tiene su propia certificación https)

• Si solo tiene un http server : configúrelo en Flexible . (Cloudflare agregará https o ssl a su sitio web automáticamente).

• Después de eso, vaya a la pestaña DNS, establezca Proxied .

Si no está seguro de lo que está haciendo, simplemente vaya a la pestaña DNS, configure DNS only

1. Asegúrese de tener una configuración de proxy correcta.

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 es su dominio, http://127.0.0.1:5000 es su servidor de socket.

2. Asegúrese de que su servidor Cross-Origin Controls esté configurado en '*' para permitir Cross-Origin Access

Para flask-socketio , es usar flask_socketio.SocketIO(app, cors_allowed_origins = '*')

3. Debe reiniciar nginx para que la nueva configuración funcione

systemctl restart nginx

4. Para obtener más detalles sobre cómo configurar caddy , consulte los siguientes enlaces:

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/

Busqué en Google porque tengo el mismo problema y también uso nginx. La solución es agregar esta parte.

proxy_http_versión 1.1;
proxy_set_header Actualizar $http_upgrade;
proxy_set_header Conexión "actualizar";
proxy_set_header Anfitrión $anfitrión;

en el archivo de configuración nginx como tylercb mencionado.

me funciono bien gracias!

Si está utilizando Elastic Beanstalk como yo para crear un servidor de nodos,
Mientras creamos el entorno, se nos pregunta en las configuraciones qué servidor proxy usar. En el que nginx se rellena previamente o se establece de forma predeterminada.
Configuré ese servidor proxy en ninguno y luego continué creando mi servidor. Estaba usando Elastic Beanstalk para crear un servidor de nodo en el que mi servidor proxy estaba configurado de forma predeterminada en nginx.
Como es un error de configuración del servidor proxy. Después de eliminar cualquier servidor proxy, el error desapareció.

Estuve buscando en Google durante horas y ninguna de las soluciones anteriores se aplicaba a nosotros, ya que solo teníamos una aplicación nodejs y no nginx.

La forma en que resolvimos esto fue simplemente deshabilitar nginx desde el contenedor -> configuración del balanceador de carga para pasar todo el tráfico directamente al nodo.

Estuve buscando en Google durante horas y ninguna de las soluciones anteriores se aplicaba a nosotros, ya que solo teníamos una aplicación nodejs y no nginx.

La forma en que resolvimos esto fue simplemente deshabilitar nginx desde el contenedor -> configuración del balanceador de carga para pasar todo el tráfico directamente al nodo.

¿cómo hiciste eso?

Si va a Configuración > Equilibrador de carga, puede encontrar un menú desplegable para el servidor proxy, puede usar nginx, Apache o establecerlo en "ninguno" para pasar todas las conexiones a la aplicación del nodo.

Esto solo aparece si crea un entorno con un balanceador de carga, no funciona para instancias individuales

Editar: mi comentario original se refería a Elastic Beanstalk

Tuve el mismo problema, mi aplicación está detrás de nginx. Hacer estos cambios en mi configuración de Nginx eliminó el error.

ubicación / {
proxy_pass http://localhost :8080;
proxy_http_versión 1.1;
proxy_set_header Actualizar $http_upgrade;
proxy_set_header Conexión "actualizar";
proxy_set_header Anfitrión $anfitrión;
}

Esto es originalmente de https://chrislea.com/2013/02/23/proxying-websockets-with-nginx/

Así que gracias.

Este documento es para aquellos que usan laravel-echo-server & Nginx & socket.io & Redis-server con el servidor separado entre el proyecto del cliente y el servidor Redis.

Por favor, siga el enlace aquí .

Gracias

Tuve este problema. Actualizar mi configuración de nginx no ayudó, pero la solución de @santhosh77h me lo arregló. Por alguna razón, pasar la matriz de orígenes permitidos no funciona, pero usar la devolución de llamada sí.

Uso los websockets de Nest.js (solo un envoltorio alrededor de Socket.io) y agregué lo siguiente a mi puerta de enlace:

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);
      }
    });
  }

Tuve el mismo problema con NUXT.js con Node.js/Express ejecutándose en AWS Elastic Beanstalk (proxy Nginx) . Me tomó unos días darme cuenta de esto. Compartiré mis puntos de lectura. Tal vez alguien lo encuentre útil.

Mi entorno está en Application Load Balancer con dos puertos 80 para https y 443 para https con SSL.

En la combinación de la respuesta anterior, muchas gracias a @tylercb y la documentación oficial de AWS y la documentación de socket.io . Creé un archivo de configuración de Nginx que parece estar solucionando el problema.

Voy a esbozar rápidamente los pasos:

En mi archivo de nodo 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

En el front-end (uno de mis componentes):
import io from 'socket.io-client';
en mis datos de Vue():
socket: io()

Finalmente, en la raíz de la aplicación, creé una carpeta .ebextensions
Justo adentro, creé un archivo 01-proxy.config con el siguiente contenido:

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"

Lecturas adicionales:
configuración de nginx

Eso es. Bastante largo. Mis disculpas y buena suerte.

trabajando para mí debajo del cambio en el servidor ubuntu y ngnix para angular .net core

ubicación / {
proxy_pass http://localhost :8080;
proxy_http_versión 1.1;
proxy_set_header Actualizar $http_upgrade;
proxy_set_header Conexión "actualizar";
proxy_set_header Anfitrión $anfitrión;
}

Si alguien todavía tiene problemas para usar Nodejs + Express, tal vez su problema podría ser express-status-monitor , como mencionó @slaveofcode . Como se indica en su documentación de NPM , este módulo genera su propia instancia de socket.io, por lo que debe completar el parámetro websocket con su instancia principal de socket.io, así como el parámetro de puerto:

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

esta informacion me ayudo

Asegúrese de que su conexión socket.io no esté pasando por un Amazon Load Balancer. O si es así, haga esto: http://blog.flux7.com/web-apps-websockets-with-aws-elastic-load-balancing

Si alguien más tuvo este problema al usar el balanceador de carga de AWS, el artículo mencionado no dice que también es posible usar SSL como protocolo de balanceador de carga y seguir usando su certificado en esta configuración, fuera del nivel del servidor de su aplicación.

Así es como se ven mis oyentes de LB

¡Funcionó bien para mí!

Tuve el mismo problema, mi aplicación está detrás de nginx. Hacer estos cambios en mi configuración de Nginx eliminó el error.

ubicación / {
proxy_pass http://localhost :8080;
proxy_http_versión 1.1;
proxy_set_header Actualizar $http_upgrade;
proxy_set_header Conexión "actualizar";
proxy_set_header Anfitrión $anfitrión;
}

Esto es originalmente de https://chrislea.com/2013/02/23/proxying-websockets-with-nginx/

Si. Esto fue útil y funcionó para mí también.

Asegúrese de que su conexión socket.io no esté pasando por un Amazon Load Balancer. O si es así, haga esto: http://blog.flux7.com/web-apps-websockets-with-aws-elastic-load-balancing

Si alguien más tuvo este problema al usar el balanceador de carga de AWS, el artículo mencionado no dice que también es posible usar SSL como protocolo de balanceador de carga y seguir usando su certificado en esta configuración, fuera del nivel del servidor de su aplicación.

Así es como se ven mis oyentes de LB

¡Funcionó bien para mí!

Bien, funcionó.

Asegúrese de que su conexión socket.io no esté pasando por un Amazon Load Balancer. O si es así, haga esto: http://blog.flux7.com/web-apps-websockets-with-aws-elastic-load-balancing

Si alguien más tuvo este problema al usar el balanceador de carga de AWS, el artículo mencionado no dice que también es posible usar SSL como protocolo de balanceador de carga y seguir usando su certificado en esta configuración, fuera del nivel del servidor de su aplicación.

Así es como se ven mis oyentes de LB

¡Funcionó bien para mí!

en este caso, su aplicación se ejecuta en 80?