Socket.io: Erro durante o handshake do WebSocket: código de resposta inesperado: 400

Estou enfrentando exatamente o mesmo problema no momento, alguma ajuda?

Também estou tendo esse problema desde que instalei um certificado SSL no meu domínio.

Aqui está uma descrição melhor do problema: http://stackoverflow.com/questions/28025073/error-during-websocket-handshake-unexpected-response-code-400-with-nginx-proxy

Também estou tendo um problema semelhante ao conectar com uma das bibliotecas do Android. Os soquetes da Web não se conectarão a https por meio de HAproxy fazendo terminação SSL ou deixando o nó fazer SSL diretamente. A sondagem longa funciona bem, no entanto

Eu resolvo isso alterando o domínio para o endereço IP verdadeiro:

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

Tive o mesmo problema, meu aplicativo está atrás do nginx. Fazer essas alterações na minha configuração do Nginx removeu o erro.

local / {
proxy_pass http://localhost :8080;
proxy_http_versão 1.1;
proxy_set_header Atualização $http_upgrade;
proxy_set_header Conexão "atualização";
proxy_set_header Host $host;
}

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

Mesmo problema aqui no servidor de produção. Máquinas de desenvolvimento não mostram o erro.

O estranho é que a conexão está funcionando. Eu posso enviar mensagens via WebSockets do servidor e o cliente as recebe. Também posso ver a conexão WebSocket sendo estabelecida no servidor.

Acabei de receber este erro nas ferramentas do desenvolvedor dizendo:

Falha na conexão do WebSocket com ' wss://.../socket.io/?EIO=3&transport=websocket&sid=2b_v_BXtbwzl5z2yAAAI ': Erro durante o handshake do WebSocket: Código de resposta inesperado: 400

Estou usando o Apache ProxyPass para enviar conexões para node.

O mesmo aqui - funcional completo, mas mensagem de erro nas ferramentas de desenvolvimento. Em outro lugar eu li que está relacionado à versão do apache - usando 2.2.14 nesta máquina.

Verifique se a conexão do socket.io não está passando por um Amazon Load Balancer. Ou se sim, faça isso: http://blog.flux7.com/web-apps-websockets-with-aws-elastic-load-balancing

Mesmo problema aqui, apenas no ambiente de produção.
Websockets parece funcionar corretamente, o aplicativo funciona sem problemas. Mas no log do console, posso ver esse erro.

Estou usando o Nginx e apenas um servidor para nó, então parece não ser um problema de balanceamento de carga. Eu já estava usando a solução sugerida pelo tylercb (com exceção de "proxy_set_header Host $host;") e não está resolvendo o problema.

também tem problema, mas funciona bem....

Eu tive esse mesmo problema. Você está usando CloudFlare? Atualmente, apenas o plano Enterprise oferece suporte a WebSockets.

Resolvido para mim. Foi devido ao endereço socket.io errado na configuração do nginx, que não correspondia ao caminho usando o websocket.

Eu pesquisei porque tive o mesmo problema e também uso o nginx. A solução é adicionar esta parte

proxy_http_versão 1.1;
proxy_set_header Atualização $http_upgrade;
proxy_set_header Conexão "atualização";
proxy_set_header Host $host;

no arquivo de configuração nginx como tylercb mencionado.

Trabalhou para mim. Obrigado.

Obteve o mesmo erro conectando-se diretamente ao meu aplicativo hospedado no Windows Server 2008R2 (sem proxy, sem IIS). Apenas hardware intermediário burro no meio.

Funciona bem depois de mudar o nome do host para o endereço IP, ou seja, 127.0.0.1:9000. pode ser causado por httpd ProxyPassReverse

No meu caso, o problema foi resultado do cloudfare não suportar websockets no plano gratuito. Desativei o CloudFare para o domínio e funcionou.

Eu só precisava adicionar algumas condições de reescrita do Apache para lidar com os websockets, mais informações aqui:
http://stackoverflow.com/a/27534443/2044993

Eu sei que esse é um problema antigo, mas como está no topo dos resultados de pesquisa do Google, isso pode ajudar as pessoas:

A razão pela qual a conexão ainda funciona mesmo com esse erro é que o socket.io está voltando para o AJAX, o que não é o ideal e você deve corrigir a configuração do seu servidor.

Aliás, esse problema deve permanecer fechado, não é um problema do socket.io.

@arosenfeld-mentel Continuo lendo as postagens acima do seu comentário de que "este não é um problema do socket.io", mas não vejo onde alguém diga QUAL é o problema. Eu mesmo vejo isso, embora, como você disse, a conexão ainda pareça funcionar. Quaisquer dicas seriam muito bem recebidas. Obrigado!

O problema pode ser qualquer coisa, você precisa depurar toda a sua configuração. Para mim, foi o NGINX, que, como proxy reverso, precisa das configurações adicionais postadas acima muitas vezes. Pois você poderia ser outra coisa.

Comece depurando a conexão local, faça-a funcionar sem o aviso, depois vá para o servidor de produção e certifique-se de obter firewalls, servidores frontais e proxys para cooperar com WebSockets.

Não é um problema do socket.io, mas é um problema do WebSockets, portanto, certifique-se de que o servidor e o cliente funcionem bem com o WebSockets.

Obrigado pela resposta. Tudo funciona localmente ou através de nossa VPN, mas uma vez que nosso firewall está envolvido, as mensagens aparecem. Acho que o firewall está interferindo de alguma forma e teremos que aprender a depurar esse problema em vez de culpar o socket.io. Obrigado novamente.

Tendo exatamente o mesmo problema. Eu criei stackoverflow (http://stackoverflow.com/questions/34439546/socket-io-with-apache-proxy) também, mas as coisas sugeridas ainda não funcionaram para mim.

eu coloquei esses cabeçalhos no nginx, mas ainda está recebendo o mesmo, mas não no navegador, mas em https://toolbox.seositecheckup.com

Também tive esse problema, parece que meu host virtual (através do nginx) não foi configurado corretamente para aceitar o cabeçalho Upgrade. A correção do @tylercb de cerca de um ano atrás corrigiu ^

@tylercb funcionou para mim.

+1
Este erro ocorreu no ambiente openshift

Achei que poderia ser útil documentar exatamente o que fiz para resolver o problema. Esta é simplesmente uma combinação das várias postagens acima colocadas em uma postagem simples, para que qualquer outra pessoa que encontre esse problema possa obter uma solução em potencial facilmente. Não tomo nenhum crédito pelo trabalho duro.

Nós estamos correndo

1. Servidor Ubuntu 14.04 LTS,
2. Versão do nginx: nginx/1.4.6 (Ubuntu) como proxy reverso e gateway SSL.
3. Nós NÃO temos Apache em tudo. É deletado do sistema.
4. Temos um servidor node.js rodando atrás do nginx v0.10.25. Este escuta na porta 4001. O acesso externo é através da porta 4000.
5. Executamos o ufw na frente e simplesmente permitimos a porta 4000.
6. Gerenciamos nossos próprios servidores e não estamos usando Cloudflare ou Openshift
7. Não usamos nenhum balanceador de carga (ainda).

Tivemos os mesmos problemas que outras pessoas de

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

Atualizamos o arquivo nginx em /etc/nginx/sites-enabled/default para ler da seguinte forma: (observe que retiramos nossos nomes de domínio)

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

Só precisávamos adicionar

1. proxy_http_versão 1.1;
2. proxy_set_header Atualização $http_upgrade;
   3.proxy_set_header Conexão "upgrade";

como já tínhamos

1. proxy_set_header Host $host;
2. proxy_pass http://127.0.0.1 :4001;

Espero ter ajudado, funcionou para nós.

Obrigado pela ajuda,

Roubar

Eu tenho o mesmo problema quando me autentico com CAS (não com o formulário clássico), e estou usando o Apache com LetEncrypt SSL como proxy, existe uma configuração específica para definir?

Tentando implantar o aplicativo Node.js no AWS Elastic BeanStalk.
Eu adicionei a pasta .ebextensions à raiz do servidor, e dentro eu adicionei o arquivo nginx.config que se parece com isso:

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;

Ainda recebo o erro 400, mas pelo menos todo o resto do soquete funciona.

Para referência: Esta é a única solução de configuração de trabalho que encontrei para socket.io 1.xe 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 outra porta, pode funcionar

@BlaM obrigado pela configuração de trabalho!

Para quem está enfrentando esse problema no AWS Elastic Beanstalk, este arquivo .ebextension funcionou para mim:

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

De acordo com as instruções neste tópico .

@BlaM - Estou usando um servidor apache e ELB com Elastic Bean
Onde devo colocar o código que você forneceu?
Obrigado!

Não tenho ideia sobre o Elastic Bean, mas o trecho de código que postei vai para os arquivos do host do Apache.

@tylercb Obrigado! funcionou para mim~

Alguém que não usa nginx está enfrentando o mesmo problema?

Sim, estou enfrentando os mesmos problemas usando o Elastic Beanstalk com um único servidor (nó e nginx) sem o Elastic Load Balancer.
Não sei como mudar de http/https para ssl/tls

Mesmo problema com HAProxy aqui

Trabalhou para mim. Obrigado. E você deve prestar atenção ao pedido

proxy_set_header   Upgrade $http_upgrade;
proxy_set_header   Connection "upgrade";

sim isso fez isso para mim também.

Também estou enfrentando esse problema. Mesmo com erro 400, a comunicação websocket entre cliente e servidor está boa. Isso está em nosso ambiente de desenvolvimento.

Alguém pode me dizer se isso seria um problema no ambiente de produção.

FYI: conectar-se a um backend de velas usando socket.io hospedado no Heroku usando o complemento postgres lançará esse erro no seu navegador se o seu io.sails.url não for https. Caso muito específico, mas espero que isso ajude alguém com a mesma pilha procurando isso no google

Ei todo mundo,

Também estou enfrentando o mesmo problema na minha máquina localhost. Estamos usando python-flask como servidor e HTML/CSS/JS como frontend.

No Frontend para conectar com o Websocket Server usamos
var socket = io.connect('ws://url/namespace', { 'transports': ['websocket'] });

Quando executo o aplicativo, ele gera um erro
WebSocket connection to 'ws://url/namespace/socket.io/?EIO=3&transport=websocket' failed: Error during WebSocket handshake: Unexpected response code: 400

Diga-nos se precisar de mais informações.

Qualquer ajuda é apreciada.
Obrigado por lê-lo.

Cumprimentos
Ajay

Recebi o mesmo erro no aplicativo de amostra webrtc. No lado do servidor, o código é

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

Depois de comentar o segundo "require('socket.io')", a mensagem de erro 400 desaparece.

Precisa pesquisar mais sobre o motivo... mas você pode verificar se seu aplicativo tenta fazer a mesma conexão duas vezes.

Olá pessoal, eu sei que essa discussão já dura um tempo e queria postar um recurso que resolvesse esse problema para mim usando AWS EBS com Application Load Balancer.

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

Espera que isso ajude.

Travis

Eu tenho o mesmo problema quando uso o etherpad-lite.
Encontrei uma abordagem para corrigir o problema do Apache ProxyPass.
Estou usando o Apache http 2.2 usa backprot do módulo http 2.4 wstunnel, então acho que pode corrigir v.2.4 também.

Primeiro eu modifiquei socket.io-client/socket.io.js
procure por WS.prototype.uri = function()
return schema + '://' + (ipv6 ? '[' + this.hostname + ']' : this.hostname) + port + this.path + query;
então mude para:

return schema + '://' + (ipv6 ? '[' + this.hostname + ']' : this.hostname) + port + this.path +'ws/'+ query;
salve-o e reinicie o node.

Segundo, modifique vhost.conf ou ssl.conf
adicione o seguinte ao 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 o apache httpd, aproveite~

Para o Apache, siga a resposta @cpres , funciona. Minha conf

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

Também tive que ajustar meu balanceador de carga elástico para usar TCP na porta 80 em vez de HTTP na porta 80.

É possível usar a diretiva ProxyPass com vários nós? Acabei 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 Funcionou muito bem! obrigado

Obrigado!

Para quem ainda está tendo problemas com o AWS Application Load Balancer, tente atualizar sua política de segurança, encontrei o mesmo problema, embora estivesse funcionando perfeitamente bem na configuração exata de outro site, mas notei que a política de segurança estava cerca de 1 ano atrasada. Atualizá-lo para um mais recente parece ter resolvido o problema.

Tendo configurado o nginx e o cliente, eu ainda estava lutando para encontrar a solução exata.
Mas @visibleajay fez esse comentário e percebi que não usei a parte { 'transports': ['websocket'] } no comando io.connect.

Então, para quem pode estar no mesmo problema,
var socket = io.connect('https://server.com/socket.io-path-here', { 'transports': ['websocket'] });

fez o trabalho, juntamente com as configurações corretas do nginx.

@fott1 , por favor, esteja ciente de que usar { 'transports': ['websocket'] } significa que não há retorno para sondagem longa quando a conexão websocket não pode ser estabelecida.

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

@darrachequesne , acredito que você esteja certo, e se eu incluir no array junto com 'websocket' o 'polling' ou 'xhr-polling'? Obrigado pelo exemplo fornecido.

@fott1 o padrão é de fato ['polling', 'websocket'] ( ref ).

Mas você precisará usar a configuração correta do nginx, já que o transporte polling (diferente websocket ) requer que cada solicitação seja roteada para o mesmo servidor socket.io.

@darrachequesne em outras palavras. se eu tiver várias instâncias de servidor, cada solicitação deve ser roteada para a mesma instância? Corrija-me se eu estiver enganado. Obrigado pela dica.

@fott1 sim, isso mesmo. A explicação está aqui: https://socket.io/docs/using-multiple-nodes/

FWIW - Eu estava recebendo isso no meu local (sem nginx, sem proxies). Acontece que com o socket.io você tem que especificar explicitamente os transportes como primeiro websocket, depois polling - tanto no cliente quanto no servidor. Não faço ideia de por que isso não seria apenas o padrão. Ou talvez eu esteja fazendo errado.

Nosso problema original era que tínhamos polling antes do websocket, sem perceber que a ordem importa.

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

Percebemos que nosso cliente estava pesquisando, então removemos isso como uma opção. Então tudo começou a falhar e recebemos o pedido ruim de 400.

Então, finalmente, descobrimos que você precisa especificar a ordem no cliente e no servidor, e se não fizer isso, o cliente irá direto para a pesquisa, o que faz pouco sentido para mim. Você pensaria que o padrão seria o websocket primeiro.

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

Novamente, esteja ciente de que usar { 'transports': ['websocket', 'polling'] } significa que não há retorno para sondagem longa quando a conexão websocket não pode ser estabelecida.

Vamos encerrar esse problema, reabra se necessário.

Adotei a abordagem de "estender" a configuração nginx padrão do Elastic Beanstalk com as configurações de local semelhantes a algumas sugestões anteriores. Crie uma estrutura de diretórios assim:

 ~/workspace/my-app/
 |-- .ebextensions
 | `-- nginx
 | `-- conf.d
 | `-- myconf.conf
 `-- web.jar

onde myconf.conf , cujo nome é arbitrário desde que termine em .conf contenha o seguinte:

 servidor {
 local / {
 proxy_pass http://127.0.0.1:5000;
 proxy_http_versão 1.1;
 proxy_set_header Atualização $http_upgrade;
 proxy_set_header Conexão "atualização";
 proxy_set_header Host $host;
 }
 }

Certifique-se de ajustar o número da porta às suas necessidades.

Resolvi esse problema adicionando apenas { transports: ['polling'] } .

_

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

_

@hyewon330 Pela aparência, se você realmente não _resolveu_ 😉 Você simplesmente configurou o socket.io para nem tentar usar websockets em primeiro lugar. Claro, a mensagem de erro desapareceu, mas agora você está forçando o socket.io a usar polling mesmo se a conexão entre cliente e servidor _deveria_ suportar websockets. Não tenho certeza se isso é crítico para sua aplicação, só queria ter certeza de que você sabe 👌

Para quem usa Nginx , a solução @tylercb funciona perfeitamente.

Esta solução corrigiu meu problema com aplicativos brilhantes. prefeito.

@tylercb @rudolfschmidt @juanjoLenero @rwillett @cpres Olá, eu uso seu método, mas não funciona para mim. Eu duvido porque eu uso outra porta ao invés de 8080. Por exemplo, meu aplicativo é colocado na máquina A com IP 170.8.8.8 monitorando a porta 5000, e eu coloco o nginx na máquina B com IP 170.8.8.2 também monitorando a porta 5000. Então eu quero visitar IP:5000 em B que pula para IP:5000 em A. Abaixo está minha configuração do nginx na 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;
        } 

Eu não sei onde dá errado. Você pode dar alguns conselhos?
muito obrigado~
ansioso por sua resposta

Estou enfrentando esse problema há algum tempo em todos os env, incluindo local. @darrachequesne Deixe-me saber se eu precisar fornecer mais informações:

Tenho um node js com express e o código abaixo, que segue exatamente a seção "How to use" do 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);

E eu configurei um cliente bem simples, apenas com o código abaixo, que segue exatamente a seção socket.io-client "Como usar":

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

Apesar de conectar com sucesso, continuo recebendo este mesmo erro:

A conexão do WebSocket com 'ws:// localhost:3000/socket.io/?EIO=3&transport=websocket&sid=EWl2jAgb5dOGXwScAAAB ' falhou: Erro durante o handshake do WebSocket: Código de resposta inesperado: 400

Ao olhar para o console do navegador, o erro está apontando para a linha 112 do websocket.js, que afirma:

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

Aprecie qualquer ideia...

@rafapetter Verifique se você não exigiu o socket.io duas vezes, eu estava movendo a configuração do socket.io em www/bin para app.js e acidentalmente deixei um require socket.io no bin que estava causando esse erro.

Apenas adicionando a opção {transports: ['websocket']} ao cliente Socket.io.

parece com isso.

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

@spookyUnknownUser no servidor o socket.io é necessário apenas uma vez.

@prapansak o cliente é um arquivo javascript simples, dentro de uma função window.onload , nenhuma importação ES6 permitida. Mas eu sigo a seção Como usar:
<script src="/socket.io/socket.io.js"></script>

E ao chamar o soquete como você sugeriu:
const socket = io('http://localhost:5000', {transports: ['websocket']})

Recebo este erro: Conexão WebSocket para 'ws:// localhost:1337/socket.io/?EIO=3&transport=websocket ' falhou: cabeçalho de quadro inválido

Obrigado pessoal, se você tiver alguma outra idéia me avise e eu vou tentar aqui.

Pronto, finalmente resolvi!

@spookyUnknownUser sua ideia me incentiva a procurar mais por duplicações. E como se vê, no servidor logo após server.listen eu estava fazendo isso:

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

O que, de certa forma, acho que é anexar o servidor uma segunda vez. Então eu removi e logo no início, ao exigir socket.io, mudei para:

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

Agora, nenhum problema é mostrado e tudo funciona bem.

Obrigado mais uma vez pelos insights galera

Eu tenho meu servidor de soquete no EBS (AWS Elastic beanstalk). Eu enfrentei um problema semelhante no ambiente de produção, mas consegui corrigir o problema sem migrar para o balanceador de carga do aplicativo e sem alterar as configurações do ngnix ou do apache.

Alterações que fiz para resolver esse problema: Em vez de https, permiti o ssl em 443 na porta do meu aplicativo e abri a porta 443 no meu grupo de segurança

Para aqueles na AWS: use o Application Load Balancer e certifique-se de ter a aderência habilitada no grupo-alvo.

Acontece que isso estava acontecendo de forma intermitente em nosso servidor quando estava sobrecarregado e dentro do horário de pico de uso.

Permitir as configurações padrão enquanto io.connect dispara cria solicitações XHR e uma solicitação WS logo após (como mencionado acima). Todas essas requisições XHR estavam sobrecarregando o servidor e assim retornando os erros 400. Usando as sugestões acima de adicionar transports: ['websocket']} ao código do cliente, o problema foi resolvido. Publicará uma atualização se os 400 erros persistirem, mas parece sólido por enquanto.

têm o mesmo problema, nenhuma das alterações sugeridas acima do lado do servidor o resolveram. No lado do cliente, tenho socket = io.connect(); no módulo react e é capaz de descobrir em qual servidor estou me conectando.
Fornecer o parâmetro server para conectar é meio complicado, mas sem ele, como posso especificar { reconnect: true, transports: ['websocket', 'polling'] } ? Parece que um parâmetro opcional é o nº 1, mas o crucial é o nº 2

eu adicionei isso abaixo, e funcionou para mim.
local / {
proxy_pass http://localhost :8080;
proxy_http_versão 1.1;
proxy_set_header Atualização $http_upgrade;
proxy_set_header Conexão "atualização";
proxy_set_header Host $host;
}
https://chrislea.com/2013/02/23/proxying-websockets-with-nginx/

Infelizmente tenho o mesmo problema, mesmo com os bons headers definidos.. Criei um stackoverflow com minha configuração..

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

Anote as aspas duplas aqui:

proxy_set_header Conexão "atualização";

Recebi esta mensagem usando aspas simples, mas usando aspas duplas resolveu.

Após cerca de uma hora de solução de problemas, parece que pode haver alguma configuração adicional necessária se você estiver executando seu endpoint como um cluster.

veja aqui

solução tylercb funcionou para mim (NgInx). Obrigado!

A chave para nós foi o proxy_http_version 1.1; na solução do @tylercb

Eu editei a configuração do NginX no meu servidor de acordo com esses muitos comentários.
Mas funciona parcialmente. No início, após a reinicialização do servidor, funciona mal. Principalmente com hard-refresh. Mais tarde, funciona melhor, apenas às vezes precisa de uma atualização difícil.
Localmente com sails lift funciona
Mas se eu estiver usando localmente sails lift --prod , recebo a mesma coisa, esse soquete não pode se conectar e 400 resposta ruim. Mas depois de algumas tentativas, está novamente estável.

Isso parece ainda não resolvido - nenhuma solução final encontrada por que temos isso ..

Adicionei as várias configurações na documentação: https://socket.io/docs/using-multiple-nodes/

Qualquer sugestão de melhoria é bem vinda! => https://github.com/socketio/socket.io-website

Acabei de enfrentar esse problema e ainda recebi um erro, mesmo desabilitando meu nginx. Finalmente o problema por causa do middleware express-status-monitor no express, isso faz com que a chamada HTTP no primeiro handshake (solicitação) do WebSocket falhe.

Eu tento desabilitar esse middleware e o WebSocket funcionando bem

Existem várias razões pelas quais você receberia 400 durante o aperto de mão. A seguir estão algumas coisas que podem ser tentadas

1. Habilite firewalls 443 in (ufw/Other), bem como configurações do console (AWS/Google cloud/Other)
2. Não habilite o TLS no servidor nodejs. Faça isso através do nginx.
3. Use a seguinte configuração do nginx
   Nota: Isso só funciona se sua conexão socket.io já estiver funcionando, mas usando sondagem longa em vez de websockets. Adicione o código abaixo e ele começará a usar o 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;
        }

Talvez ajude alguém. Eu recebi esse erro quando criei duas instâncias do socket.io no meu aplicativo. Liguei para io = socketio(server) twise e obtive o erro 400. Isso é algum tipo de erro estúpido, mas... esse foi o meu.

Certifique-se de habilitar sessões fixas no balanceador de carga do aplicativo (não use o balanceador de carga clássico). Se você não usar sessões fixas, provavelmente receberá os 400 erros aleatoriamente.

Isso ocorre porque quando a atualização de polling para websocket é tentada, é possível que o balanceador de carga balanceie a solicitação de atualização para um servidor que nunca encontrou esse id de soquete e gere o erro 400. Mais detalhes aqui: https://socket.io/docs/using-multiple-nodes/

Além disso, se você estiver usando o elastic beanstalk, adicione o seguinte arquivo websocket.config na pasta .ebextensions para dar suporte à atualização do Nginx para 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

Eu pesquisei porque tive o mesmo problema e também uso o nginx. A solução é adicionar esta parte

proxy_http_versão 1.1;
proxy_set_header Atualização $http_upgrade;
proxy_set_header Conexão "atualização";
proxy_set_header Host $host;

no arquivo de configuração nginx como tylercb mencionado.

Então, pelo menos isso funciona quando você usa o nginx como proxy reverso, aqui está a explicação

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.

Alguma novidade sobre este assunto? Eu fiz referência aqui https://stackoverflow.com/questions/49575350/websocket-connection-to-wss-error-during-websocket-handshake-unexpected-re

Muitos usuários têm esse problema por causa da configuração do nginx e enquanto em servidores dedicados você pode corrigi-lo usando as idéias acima (configuração do nginx, etc) muitos usuários não têm acesso a essas configurações, então seria ótimo ter algum tipo de correção de sockets.io sobre isso ...

Ninguém?

@deemeetree
Se você usa vários nós, o que me parece possível devido à mensagem de erro no seu site "Session ID unknown", você deve dar uma olhada na minha resposta no StackOverflow (https://stackoverflow.com/a/53163917/6271092) .

Para ser breve, socket.io como eles dizem em seu site (https://socket.io/docs/using-multiple-nodes/) ,

Se você planeja distribuir a carga de conexões entre diferentes processos ou máquinas, deve certificar-se de que as solicitações associadas a um determinado ID de sessão se conectem ao processo que as originou.

Isso se deve a certos transportes, como XHR Polling ou JSONP Polling, que dependem do disparo de várias solicitações durante a vida útil do “soquete”. A falha em habilitar o balanceamento rígido resultará no temido:

Error during WebSocket handshake: Unexpected response code: 400

Portanto, você não pode ter vários soquetes que funcionem em nós diferentes. Reconfigure seu servidor como ele diz. E para o seu Express, configure sua porta assim,
parseInt(your_port) + parseInt(process.env.NODE_APP_INSTANCE);

Espero que ajude.

Obteve o mesmo erro conectando-se diretamente ao meu aplicativo hospedado no Windows Server 2008R2 (sem proxy, sem IIS). Apenas hardware intermediário burro no meio.

Estou enfrentando o mesmo problema no Windows Server 2016, por favor mencione sua correção. Obrigado

Estou enfrentando esse problema há algum tempo. Se alguém tiver alguma informação por favor ajude. Estou usando o servidor apache.

Qualquer pista? Funciona muito bem no dev, mas o mesmo problema no SSL.

Usando o modo de cluster de nós PM2: 4 x 1

Usando o proxy apache, ainda não há pistas

Para quem está no httpd2/apache2, tenho uma solução 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>

Ei @ZeldaZach isso é para o arquivo .htaccess? obrigado!

Esta configuração está no meu arquivo sites-enabled/site.conf, mas deve funcionar no htaccess também afaik

Tudo o que posso dizer, o SSL é o culpado aqui :) desative, o modo SSL flexível da cloudflare e mude para o modo FULL (STRICT). Claro que isso resolverá o problema,
Se não,

Use localhost:port na configuração de proxy reverso.

Para qualquer um aqui usando Nginx e React Express (MERN). Eu tive o mesmo problema porque eu só a linha proxy_pass http://localhost:3000; . Eu adicionei as seguintes linhas com base na resposta @tylercb acima neste tópico:

"Tive o mesmo problema, meu aplicativo está atrás do nginx. Fazer essas alterações na minha configuração do Nginx removeu o erro.

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

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

Se alguém ainda tiver problemas usando o Nodejs + Express, talvez seu problema possa ser express-status-monitor , como @slaveofcode mencionou. Conforme informado em sua documentação do NPM , este módulo gera sua própria instância socket.io, então você deve preencher o parâmetro websocket com sua instância principal do socket.io, bem como o parâmetro port:

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

Esta é a minha configuração do Apache, observe que está usando um prefixo de caminho /ws/ , mas, caso contrário, funciona bem.

    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

Atualmente enfrentando esse problema ao expor o painel do Linkerd (malha de serviço) para nosso cluster EKS. usamos nginx, então não tenho certeza de como sair disso neste momento.

@andrzj OMG cara, você acabou de me salvar.

Tive o mesmo problema, meu aplicativo está atrás do nginx. Fazer essas alterações na minha configuração do Nginx removeu o erro.

local / {
proxy_pass http://localhost :8080;
proxy_http_versão 1.1;
proxy_set_header Atualização $http_upgrade;
proxy_set_header Conexão "atualização";
proxy_set_header Host $host;
}

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

funciona.

Obrigado pela ajuda galera! Se alguém está tentando fazer isso funcionar próximo ao tráfego HTTPS normal, agora está funcionando no Elastic Beanstalk para mim com as seguintes configurações:

• No Elastic Beanstalk: nginx desativado (por enquanto, ainda não tentei a configuração acima).
• No Elastic Beanstalk: balanceador de carga da seguinte forma:
• No Node/Express: const io = require('socket.io')(3030)
• No cliente simplesmente nomeando let connection = io(https://www.myurl.com:3030)

Se vocês ainda estão tendo esse problema e definiram a origem permitida no servidor de soquete como matriz ou origens, em vez da função de retorno de chamada para filtrar origens, esse erro seria lançado

Error during WebSocket handshake: Unexpected response code: 400

No meu caso atualizando essa lógica

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

para isso

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

Funcionou sem nenhum erro lançado.

Obtendo esse mesmo erro, mas adicionei as configurações do NGINX e ainda estou recebendo o mesmo erro de handshake 400. No entanto, estou usando um Application Load Balancer na AWS e o defini como um grupo de destino :80 e um ouvinte 443 que encaminha para o grupo de destino.

Arquivo conf do 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;
}

}`

E dentro do meu arquivo js eu tenho uma conexão para socket.io que se parece com isso:
var socket = io()

Crie instância manual (sem instância expressa app ) e atribua uma porta diferente

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

Tive o mesmo problema, meu aplicativo está atrás do nginx. Fazer essas alterações na minha configuração do Nginx removeu o erro.

local / {
proxy_pass http://localhost :8080;
proxy_http_versão 1.1;
proxy_set_header Atualização $http_upgrade;
proxy_set_header Conexão "atualização";
proxy_set_header Host $host;
}

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

faltou proxy_set_header Connection "upgrade";

Estou gastando uma noite inteira para resolver esse problema quando começo a usar https ou wss ou ssl . Ele sempre diz connection stopped before establish com o código de erro 400 .

Apenas alguns minutos atrás, encontrei uma solução para isso:

0. Cloudflare

Na guia SSL/TLS:

• Se você tiver seu próprio cert ou SSL ou HTTPS : defina-o Full . (As 123 etapas a seguir pressupõem que você tenha sua própria certificação https)

• Se você tiver apenas http server : defina-o Flexible . (O Cloudflare adicionará https ou ssl ao seu site automaticamente.)

• Depois disso, vá para a guia DNS, defina Proxied .

Se você não tem certeza do que está fazendo, vá para a aba DNS, defina DNS only

1. Certifique-se de ter uma configuração de proxy correta.

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 é seu domínio, http://127.0.0.1:5000 é seu servidor de soquete.

2. Certifique-se de que seu servidor Cross-Origin Controls esteja definido como '*' para permitir Cross-Origin Access

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

3. Você deve reiniciar o nginx para permitir que a nova configuração funcione

systemctl restart nginx

4. Para obter mais detalhes sobre como definir caddy , consulte os seguintes links:

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/

Eu pesquisei porque tive o mesmo problema e também uso o nginx. A solução é adicionar esta parte

proxy_http_versão 1.1;
proxy_set_header Atualização $http_upgrade;
proxy_set_header Conexão "atualização";
proxy_set_header Host $host;

no arquivo de configuração nginx como tylercb mencionado.

funcionou para mim bem obrigado!

Se você estiver usando o Elastic Beanstalk assim como eu para criar o node-server,
Ao criar o ambiente estamos sendo solicitados nas configurações para usar qual servidor proxy. Em que o nginx é pré-preenchido ou definido como padrão.
Configurei esse servidor proxy para none e continuei a criar meu servidor. Eu estava usando o Elastic Beanstalk para criar um servidor de nó no qual meu servidor proxy estava definido como nginx.
Como é um erro de configuração do servidor proxy. Depois de remover qualquer servidor proxy, o erro desapareceu.

Estive pesquisando por horas e nenhuma das soluções acima se aplicava a nós, pois tínhamos apenas um aplicativo nodejs e nenhum nginx.

A maneira como resolvemos isso foi apenas desabilitar o nginx do contêiner -> configurações do balanceador de carga para passar todo o tráfego diretamente para o nó.

Estive pesquisando por horas e nenhuma das soluções acima se aplicava a nós, pois tínhamos apenas um aplicativo nodejs e nenhum nginx.

A maneira como resolvemos isso foi apenas desabilitar o nginx do contêiner -> configurações do balanceador de carga para passar todo o tráfego diretamente para o nó.

como você fez isso?

Se você for para Configuration > Load balancer, poderá encontrar uma lista suspensa para o servidor proxy, poderá usar nginx, Apache ou defini-lo como "none" para passar por todas as conexões para o aplicativo do nó.

Isso só aparece se você criar um ambiente com um balanceador de carga, não funciona para instâncias únicas

Edit: meu comentário original foi referido ao Elastic Beanstalk

Tive o mesmo problema, meu aplicativo está atrás do nginx. Fazer essas alterações na minha configuração do Nginx removeu o erro.

local / {
proxy_pass http://localhost :8080;
proxy_http_versão 1.1;
proxy_set_header Atualização $http_upgrade;
proxy_set_header Conexão "atualização";
proxy_set_header Host $host;
}

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

Então, muito obrigado.

Este documento é para aqueles que usam laravel-echo-server & Nginx & socket.io & Redis-server com o servidor separado entre o projeto cliente e o Redis-server.

Por favor, siga o link aqui .

Obrigado

Eu tive esse problema. Atualizar minha configuração do nginx não ajudou, mas a solução do @santhosh77h corrigiu isso para mim. Por algum motivo, passar a matriz de origens permitidas não funciona, mas usar o retorno de chamada sim.

Eu uso websockets Nest.js (apenas um wrapper em torno do Socket.io) e adicionei o seguinte ao meu gateway:

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

Eu tive o mesmo problema com NUXT.js com Node.js/Express rodando no AWS Elastic Beanstalk (proxy Nginx) . Levei alguns dias para descobrir isso. Vou compartilhar meus pontos de leitura. Talvez alguém ache útil.

Meu ambiente está no Application Load Balancer com duas portas 80 para https e 443 para https com SSL.

Na combinação da resposta acima, muito obrigado a @tylercb e documentação oficial da AWS e documentação do socket.io, criei um arquivo de configuração Nginx que parece estar corrigindo o problema.

Vou descrever rapidamente os passos:

No meu arquivo de nó 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

No front-end (um dos meus componentes):
import io from 'socket.io-client';
nos meus dados Vue():
socket: io()

Por fim, na raiz do aplicativo, criei uma pasta .ebextensions
Logo dentro criei um arquivo 01-proxy.config com o seguinte conteúdo:

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"

Leituras adicionais:
configuração do nginx

É isso. Bastante demorado. Minhas desculpas e boa sorte.

trabalhando para mim abaixo da mudança no servidor ubuntu e ngnix para angular .net core

local / {
proxy_pass http://localhost :8080;
proxy_http_versão 1.1;
proxy_set_header Atualização $http_upgrade;
proxy_set_header Conexão "atualização";
proxy_set_header Host $host;
}

Se alguém ainda tiver problemas usando o Nodejs + Express, talvez seu problema possa ser express-status-monitor , como @slaveofcode mencionou. Conforme informado em sua documentação do NPM , este módulo gera sua própria instância socket.io, então você deve preencher o parâmetro websocket com sua instância principal do socket.io, bem como o parâmetro port:

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

Essa informação me ajudou

Verifique se a conexão do socket.io não está passando por um Amazon Load Balancer. Ou se sim, faça isso: http://blog.flux7.com/web-apps-websockets-with-aws-elastic-load-balancing

Se mais alguém teve esse problema usando o balanceador de carga da AWS, o artigo mencionado não diz que é possível também usar SSL como protocolo de balanceador de carga e continuar usando seu certificado nesta configuração, fora do seu nível de servidor de aplicativos.

É assim que meus ouvintes LB se parecem

Funcionou bem para mim!

Tive o mesmo problema, meu aplicativo está atrás do nginx. Fazer essas alterações na minha configuração do Nginx removeu o erro.

local / {
proxy_pass http://localhost :8080;
proxy_http_versão 1.1;
proxy_set_header Atualização $http_upgrade;
proxy_set_header Conexão "atualização";
proxy_set_header Host $host;
}

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

sim. Isso foi útil e funcionou para mim também.

Verifique se a conexão do socket.io não está passando por um Amazon Load Balancer. Ou se sim, faça isso: http://blog.flux7.com/web-apps-websockets-with-aws-elastic-load-balancing

Se mais alguém teve esse problema usando o balanceador de carga da AWS, o artigo mencionado não diz que é possível também usar SSL como protocolo de balanceador de carga e continuar usando seu certificado nesta configuração, fora do seu nível de servidor de aplicativos.

É assim que meus ouvintes LB se parecem

Funcionou bem para mim!

Legal, funcionou.

Verifique se a conexão do socket.io não está passando por um Amazon Load Balancer. Ou se sim, faça isso: http://blog.flux7.com/web-apps-websockets-with-aws-elastic-load-balancing

Se mais alguém teve esse problema usando o balanceador de carga da AWS, o artigo mencionado não diz que é possível também usar SSL como protocolo de balanceador de carga e continuar usando seu certificado nesta configuração, fora do seu nível de servidor de aplicativos.

É assim que meus ouvintes LB se parecem

Funcionou bem para mim!

neste caso seu aplicativo está rodando em 80?