Socket.io: WebSocketハンドシェイク中のエラー：予期しない応答コード：400

私は現在、まったく同じ問題を経験しています、何か助けはありますか？

ドメインにSSL証明書をインストールしたため、この問題も発生しています。

問題のより良い説明は次のとおりです： http ：//stackoverflow.com/questions/28025073/error-during-websocket-handshake-unexpected-response-code-400-with-nginx-proxy

Androidライブラリの1つに接続するときにも同様の問題が発生します。 Webソケットは、HAproxyがSSLターミネーションを実行するか、ノードにSSLを直接実行させることによってhttpsに接続しません。 ただし、長いポーリングは正常に機能します

ドメインを実際のIPアドレスに変更することで解決します。

var socket = io.connect（ 'http://182.92.79.215:3007'）;

同じ問題がありましたが、私のアプリはnginxの背後にあります。 Nginx構成にこれらの変更を加えると、エラーが削除されました。

位置 / {
proxy_pass http：// localhost ：8080;
proxy_http_version 1.1;
proxy_set_headerアップグレード$ http_upgrade;
proxy_set_header接続 "アップグレード";
proxy_set_headerホスト$ host;
}

これは元々 https://chrislea.com/2013/02/23/proxying-websockets-with-nginx/からのものです

ここで本番サーバーで同じ問題が発生します。 開発マシンはエラーを表示しません。

奇妙なことに、接続が機能しています。 サーバーからWebSocketを介してメッセージを送信でき、クライアントがメッセージを取得します。 サーバーでWebSocket接続が確立されていることもわかります。

開発者ツールで次のようなエラーが発生します。

' wss：//.../socket.io/？EIO = 3＆transport = websocket＆sid = 2b_v_BXtbwzl5z2yAAAI 'へのWebSocket接続に失敗しました：WebSocketハンドシェイク中のエラー：予期しない応答コード：400

ApacheProxyPassを使用してノードに接続を送信しています。

ここでも同じです-完全に機能しますが、開発ツールのエラーメッセージです。 他のどこかで、apacheバージョンに関連するものを読みました-このマシンで2.2.14を使用しています。

socket.io接続がAmazonロードバランサーを経由していないことを確認してください。 または、その場合は、次のようにします：http： //blog.flux7.com/web-apps-websockets-with-aws-elastic-load-balancing

ここでも同じ問題がありますが、実稼働環境でのみ発生します。
Websocketは正しく機能しているようで、アプリケーションは問題なく機能します。 しかし、コンソールログでこのエラーを確認できます。

Nginxとノード用のサーバーを1つだけ使用しているので、負荷分散の問題ではないようです。 私はすでにtylercbによって提案された解決策を使用していました（ "proxy_set_header Host $ host;"を除く）、そしてそれは問題を解決していません。

また、問題がありますが、うまく機能します。

私はこれと同じ問題を抱えていました。 CloudFlareを使用していますか？ 現在、WebSocketをサポートしているのはエンタープライズプランのみです。

私のために解決しました。 これは、nginx構成のsocket.ioアドレスが間違っていたためで、WebSocketを使用したパスと一致していませんでした。

同じ問題が発生し、nginxも使用しているため、グーグルで検索しました。 解決策は、この部分を追加することです

proxy_http_version 1.1;
proxy_set_headerアップグレード$ http_upgrade;
proxy_set_header接続 "アップグレード";
proxy_set_headerホスト$ host;

前述のtylercbのようなnginx構成ファイルに。

私のために働いた。 ありがとう。

Windows Server 2008R2（プロキシなし、IISなし）でホストされているアプリに直接接続すると、同じエラーが発生しました。 中間のハードウェアのみ。

ホスト名をIPアドレス、つまり127.0.0.1:9000に切り替えた後は、正常に機能します。 httpdProxyPassReverseが原因である可能性があります

私の場合、この問題は、cloudfareが無料プランでWebSocketをサポートしていないことが原因でした。 ドメインのCloudFareをオフにしたところ、機能しました。

WebSocketを処理するためにApacheの書き換え条件を追加する必要がありました。詳細については、こちらをご覧ください。
http://stackoverflow.com/a/27534443/2044993

私はこれが古い問題であることを知っています、しかしそれはグーグル検索結果で高いので、しかしこれは人々を助けるかもしれません：

このエラーがあっても接続が機能する理由は、socket.ioがAJAXにフォールバックしているためです。これは最適ではないため、サーバー構成を修正する必要があります。

ところで、この問題は解決されたままである必要があります。socket.ioの問題ではありません。

@ arosenfeld-mentel「これはsocket.ioの問題ではありません」というコメントの上の投稿を読み続けていますが、問題が実際に何であるかを誰かが言っている場所がわかりません。 あなたが言うように、接続はまだ機能しているようですが、私はこれを自分で見ています。 どんなヒントも非常にありがたく受け取られるでしょう。 ありがとう！

問題は実際には何でもかまいません。セットアップ全体をデバッグする必要があります。 私にとってはNGINXでした。これは、リバースプロキシとして、上記の追加の構成設定を何度も投稿する必要があるためです。 あなたは他の何かかもしれないからです。

ローカル接続をデバッグすることから始めて、警告なしで動作させてから、運用サーバーに移動し、ファイアウォール、前面サーバー、およびプロキシがWebSocketと連携するようにします。

これはsocket.ioの問題ではありませんが、WebSocketの問題であるため、サーバーとクライアントがWebSocketで正常に動作することを確認してください。

返信いただきありがとうございます。 すべてがローカルまたはVPNを介して機能しますが、ファイアウォールが関与すると、メッセージが表示されます。 ファイアウォールが何らかの形で干渉していると思います。socket.ioを非難するのではなく、その問題をデバッグする方法を学ぶ必要があります。 再度、感謝します。

まったく同じ問題があります。 私はstackoverflow（http://stackoverflow.com/questions/34439546/socket-io-with-apache-proxy）の質問も作成しましたが、そこに示唆されたものはまだ私のために働いていません。

私はこれらのヘッダーをnginxに配置しましたが、それでも同じようになりましたが、ブラウザーではなくhttps://toolbox.seositecheckup.comにあります

この問題もありましたが、私の仮想ホスト（nginx経由）がUpgradeヘッダーを受け入れるように適切に設定されていなかったようです。 @tylercbの約1年前の修正で修正されました^

@tylercbは私のために働いた。

+1
このエラーはOpenShift環境で発生しました

問題を解決するために私がしたことを正確に文書化すると役立つかもしれないと思いました。 これは、上記のさまざまな投稿を単純な投稿に組み合わせたものであるため、この問題を見つけた他の人は簡単に解決策を見つけることができます。 私はその努力を信用しません。

私たちは走っています

1. Ubuntu 14.04 LTSサーバー、
2. nginxバージョン：リバースプロキシおよびSSLゲートウェイとしてのnginx / 1.4.6（Ubuntu）。
3. Apacheはまったくありません。 システムから削除されました。
4. nginxv0.10.25の背後で実行されているnode.jsサーバーがあります。 これはポート4001でリッスンします。外部アクセスはポート4000を介して行われます。
5. フロントでufwを実行し、ポート4000を通過させました。
6. 私たちは独自のサーバーを管理しており、CloudflareやOpenshiftを使用していません
7. ロードバランサーは（まだ）使用していません。

私たちは他の人と同じ問題を抱えていました

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

/ etc / nginx / sites-enabled / defaultのnginxファイルを次のように更新しました:(ドメイン名を削除したことに注意してください）

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

追加するだけで済みました

1. proxy_http_version 1.1;
2. proxy_set_headerアップグレード$ http_upgrade;
   3.proxy_set_header接続 "アップグレード";

私たちがすでに持っていたように

1. proxy_set_headerホスト$ host;
2. proxy_pass http://127.0.0.1：4001 ;

これがお役に立てば幸いです、それは私たちのために働きました。

助けてくれてありがとう、

ロブ

CAS（従来の形式ではない）で認証するときに同じ問題が発生し、LetEncrypt SSLをプロキシとして使用するApacheを使用していますが、設定する特定の構成はありますか？

Node.jsアプリをAWSElasticBeanStalkにデプロイしようとしています。
サーバーのルートにフォルダー.ebextensionsを追加し、その中に次のようなファイルnginx.configを追加しました。

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;

それでも400エラーが発生しますが、少なくとも残りのソケットはすべて機能します。

参考：これは、socket.io1.xおよびApache2.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]

別のポートを使用すると、動作する可能性があります

@BlaM作業構成に感謝します！

AWS Elastic Beanstalkでこの問題が発生した場合、この.ebextensionファイルは私のために機能しました。

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

このスレッドの指示に従って。

@ BlaM -ElasticBeanでApacheサーバーとELBを使用しています
提供したコードはどこに置くべきですか？
ありがとう！

Elastic Beanについてはわかりませんが、投稿したコードスニペットはApacheホストファイルに入ります。

@tylercbありがとう！ それは私のために働いた〜

同じ問題に直面しているnginxを使用していない人はいますか？

はい、Elastic Load Balancerを使用せずに単一のサーバー（ノードとnginx）でElasticBeanstalkを使用しても同じ問題に直面しています。
http / httpsからssl / tlsに変更する方法がわかりません

ここでHAProxyと同じ問題

私のために働いた。 ありがとう。 そして、あなたは注文に注意を払う必要があります

proxy_set_header   Upgrade $http_upgrade;
proxy_set_header   Connection "upgrade";

はい、これは私にとってもそれをしました。

私もこの問題に直面しています。 400エラーが発生した場合でも、クライアントとサーバー間のWebSocket通信は正常です。 これは私たちの開発環境にあります。

これが本番環境で問題になるかどうか誰かに教えてもらえますか？

参考：postgresアドオンを使用してHerokuでホストされているsocket.ioを使用してsailsバックエンドに接続すると、io.sails.urlがhttpsでない場合、ブラウザでこのエラーがスローされます。 非常に特殊なケースですが、うまくいけば、これは同じスタックを持つ人がグーグルでこれを検索するのに役立ちます

みなさん、こんにちは

ローカルホストマシンでも同じ問題に直面しています。 サーバーとしてpython-flaskを使用し、フロントエンドとしてHTML / CSS / JSを使用しています。

フロントエンドでWebsocketサーバーに接続するために使用しました
var socket = io.connect('ws://url/namespace', { 'transports': ['websocket'] });

アプリケーションを実行すると、エラーがスローされます
WebSocket connection to 'ws://url/namespace/socket.io/?EIO=3&transport=websocket' failed: Error during WebSocket handshake: Unexpected response code: 400

さらに情報が必要な場合はお知らせください。

どんな助けでも大歓迎です。
読んでくれてありがとう。

よろしく
アジェイ

webrtcサンプルアプリで同じエラーが発生しました。 サーバー側では、コードは

var server = require（ 'http'）。Server（app）;
var io = require（ 'socket.io'）（server）;
var WebRTC = require（ '../../'）;
app.use（express.static（__ dirname））;
var io = require（ 'socket.io'）（server）;

2番目の「require（ 'socket.io'）」をコメントアウトすると、400エラーメッセージが消えます。

理由をさらに掘り下げる必要があります...しかし、アプリが同じ接続を2回試行するかどうかを確認できます。

このディスカッションがしばらく続いていることを知っている皆さん、AWSEBSとApplicationLoadBalancerを使用してこの問題を解決するリソースを投稿したいと思いました。

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

これがお役に立てば幸いです。

トラヴィス

etherpad-liteを使用しても同じ問題が発生します。
ApacheProxyPassの問題を修正する方法を見つけました。
私はApachehttp2.2を使用しています。http2.4wstunnelモジュールのbackprotを使用しているので、v.2.4も修正できると思います。

まず、socket.io-client /socket.io.jsを変更しました
WS.prototype.uri = function（）を探します
return schema + '://' + (ipv6 ? '[' + this.hostname + ']' : this.hostname) + port + this.path + query;
次に、次のように変更します。

return schema + '://' + (ipv6 ? '[' + this.hostname + ']' : this.hostname) + port + this.path +'ws/'+ query;
保存してノードを再起動します。

次に、vhost.confまたはssl.confを変更します
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>

`

Apache httpdを再起動し、お楽しみください〜

Apacheの場合、 @ cpresの回答に従ってください。機能します。 私の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>

また、ポート80を介したHTTPではなくポート80を介したTCPを使用するように、エラスティックロードバランサーを調整する必要がありました。

複数のノードでProxyPassディレクティブを使用することは可能ですか？ https://github.com/socketio/socket.io/pull/2819にRewriteRuleを使用することになりました：

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うまくいきました！ ありがとう

ありがとう！

AWS Application Load Balancerでまだ問題が発生している場合は、セキュリティポリシーを更新してみてください。別のウェブサイトの正確なセットアップでは完全に正常に機能していましたが、セキュリティポリシーが約1年遅れていることに気付きました。 新しいものに更新することで問題は解決したようです。

nginxとクライアントを構成した後も、正確な解決策を見つけるのに苦労していました。
しかし、 @ visibleajayがそのコメントをし、私は{'transports'：['websocket']}の部分をio.connectコマンドに使用していないことに気付きました。

したがって、同じ問題に直面する可能性のある人にとっては、
var socket = io.connect('https://server.com/socket.io-path-here', { 'transports': ['websocket'] });

正しいnginx構成と一緒に仕事をしました。

@ fott1 { 'transports': ['websocket'] }を使用すると、WebSocket接続を確立できない場合にロングポーリングへのフォールバックがないことに注意してください。

nginxを使用した完全な例： https ：//github.com/socketio/socket.io/tree/master/examples/cluster-nginx

@darrachequesne私はあなたが正しいと信じています、「websocket」、「polling」、または「xhr-polling」と一緒に配列に含めるとどうなりますか？ 提供された例をありがとう。

@ fott1のデフォルトは、実際には['polling', 'websocket'] （ ref ）です。

ただし、 polling （ websocketとは異なり）トランスポートではすべてのリクエストが同じsocket.ioサーバーにルーティングされる必要があるため、正しいnginx構成を使用する必要があります。

言い換えれば、 @ darrachequesne 。 複数のサーバーインスタンスがある場合、すべてのリクエストを同じインスタンスにルーティングする必要がありますか？ 私が間違っている場合は私を訂正してください。 ヒントありがとうございます。

@ fott1うん、そうだね。 説明はここにあります： https ：//socket.io/docs/using-multiple-nodes/

FWIW-私はこれを私のローカルで取得していました（nginx、プロキシなし）。 socket.ioを使用すると、トランスポートを最初のWebSocketとして明示的に指定してから、クライアントとサーバーの両方でポーリングする必要があります。 なぜそれがデフォルトではないのか分かりません。 または多分私はそれを間違っています。

私たちの元々の問題は、順序が重要であることに気づかずに、WebSocketの前にポーリングを行っていたことでした。

元の設定：
サーバ：
io.set('transports', ['polling', 'websocket']);
クライアント：
var socket = io.connect(server, { reconnect: true });

クライアントがポーリングしていることに気付いたので、オプションとしてそれを削除しました。 その後、すべてが失敗し始め、400の悪いリクエストを受け取りました。

したがって、最終的に、クライアントとサーバーの両方で順序を指定する必要があることがわかりました。指定しない場合、クライアントは直接ポーリングに進みますが、これは私にはほとんど意味がありません。 最初にデフォルトでwebsocketに設定されると思います。

修理：
サーバ：
io.set('transports', ['websocket', 'polling']);
クライアント：
var socket = io.connect(server, { reconnect: true, transports: ['websocket', 'polling'] });

繰り返しになりますが、 { 'transports': ['websocket', 'polling'] }を使用すると、WebSocket接続を確立できない場合にロングポーリングへのフォールバックがないことに注意してください。

その問題を閉じましょう。必要に応じて再度開いてください。

以前の提案と同様の場所設定を使用して、 ElasticBeanstalkのデフォルトのnginx構成を「拡張」するアプローチを採用しました。 次のようなディレクトリ構造を作成します。

 〜/ worksheet / my-app /
 | -.ebextensions
 | `-nginx
 | `-conf.d
 | `-myconf.conf
 `-web.jar

ここで、 myconf.confは、 .confで終わる限り、名前は任意です。次の内容が含まれます。

サーバー{
 位置 / {
 proxy_pass http://127.0.0.1:5000;
 proxy_http_version 1.1;
 proxy_set_headerアップグレード$ http_upgrade;
 proxy_set_header接続 "アップグレード";
 proxy_set_headerホスト$ host;
 }
 }

必要に応じてポート番号を調整してください。

{トランスポート：['polling']}のみを追加することで、この問題を解決しました。

_

var socket = io.connect（server、{transports：['polling']}）;

_

@ hyewon330見た目では、実際には解決しなかった場合は😉そもそもWebSocketを使用しないようにsocket.ioを構成しただけです。 確かに、エラーメッセージは消えましたが、クライアントとサーバー間の接続がWebSocketをサポートしている場合でも、socket.ioにポーリングの使用を強制しています。 それがアプリケーションにとって重要かどうかわからない、ただあなたが知っていることを確認したかっただけです👌

Nginxを使用している人にとって、 @ tylercbソリューションは完全に機能します。

この解決策は、光沢のあるアプリに関する私の問題を修正しました。 知事。

@tylercb @rudolfschmidt @juanjoLenero @rwillett @cpresこんにちは、私はあなたの方法を使用しますが、それは私には機能しません。 8080ではなく他のポートを使用しているためかどうかは疑問です。たとえば、アプリはIP 170.8.8.8監視ポート5000のマシンAに配置され、nginxはIP170.8.8.2も監視ポート5000のマシンBに配置されています。 BのIP：5000にアクセスし、AのIP：5000にスキップします。以下は、マシンBのnginx構成です。

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

どこが悪いのかわかりません。 アドバイスをいただけますか？
どうもありがとうございました〜
お返事を楽しみにしています

私はしばらくの間、ローカルを含むすべての環境でこの問題に直面しています。 @darrachequesneさらに情報を提供する必要があるかどうか教えてください：

私は、expressと以下のコードを備えたノードjsを持っています。これは、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);

そして、私は非常に単純なクライアントをセットアップしました。以下のコードだけで、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>

接続に成功したにもかかわらず、同じエラーが発生し続けます。

'ws：// localhost：3000 / socket.io /？EIO = 3＆transport = websocket＆sid = EWl2jAgb5dOGXwScAAAB 'へのWebSocket接続に失敗しました：WebSocketハンドシェイク中のエラー：予期しない応答コード：400

ブラウザコンソールを見ると、エラーはwebsocket.jsの112行目を指しています。

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

アイデアに感謝します...

@rafapetter socket.ioが2回必要ないことを確認します。私は、www / binのsocket.ioの設定をapp.jsに移動し、誤ってrequiresocket.ioをビンに残してこのエラーを引き起こしていました。

Socket.ioクライアントに{transports: ['websocket']}オプションを追加するだけです。

このように見える。

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

サーバー上の@spookyUnknownUserは、socket.ioが1回だけ必要です。

@prapansakクライアントは、 window.onload関数内の単純なjavascriptファイルであり、ES6のインポートは許可されていません。 しかし、私は使用方法のセクションに従います：
<script src="/socket.io/socket.io.js"></script>

そして、あなたが提案したようにソケットを呼び出すとき：
const socket = io('http://localhost:5000', {transports: ['websocket']})

このエラーが発生します： 'ws：// localhost：1337 / socket.io /？EIO = 3＆transport = websocket 'へのWebSocket接続に失敗しました：無効なフレームヘッダー

みんなありがとう、他に何かアイデアがあれば教えてください。ここで試してみます。

さて、ようやく解決しました！

@spookyUnknownUserあなたのアイデアは、重複をさらに探すように私を促します。 そして、結局のところ、 server.listenの直後のサーバーで私はこれを行っていました：

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

ある意味で、サーバーをもう一度接続することだと思います。 だから私はそれを削除し、socket.ioが必要なときに最初に次のように変更しました：

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

これで、問題は表示されず、すべてが正常に機能します。

洞察力をありがとう

EBS（AWS Elastic Beanstalk）にソケットサーバーがあります。 実稼働環境でも同様の問題に直面しましたが、アプリケーションロードバランサーに移行せず、ngnixまたはapacheの構成を変更せずに問題を修正できました。

この問題を解決するために行った変更：httpsの代わりに、443のSSLをアプリケーションポートに許可し、セキュリティグループのポート443を開きました

AWSの場合：Application Load Balancerを使用し、ターゲットグループでスティッキネスが有効になっていることを確認します。

これは、サーバーが過負荷でピーク使用時間内にサーバー上で断続的に発生していたことが判明しました。

io.connectの起動中にデフォルト設定を許可すると、直後にXHRリクエストとWSリクエストが作成されます（前述のとおり）。 これらのXHRリクエストはすべてサーバーに過負荷をかけているため、400エラーが返されていました。 クライアントコードにtransports: ['websocket']}を追加するという上記の提案を使用することで、問題は解決されました。 400エラーが続く場合は更新を投稿しますが、今のところは確実に見えます。

同じ問題がありますが、上記のサーバー側の変更で解決されたものはありません。 クライアント側では、reactモジュールにsocket = io.connect();があり、接続しているサーバーを特定できます。
接続するためのserverパラメータを提供するのはちょっと面倒ですが、それなしで{ reconnect: true, transports: ['websocket', 'polling'] }を指定するにはどうすればよいですか？ オプションのパラメータは＃1のように聞こえますが、重要なパラメータは＃2です。

私はこれを以下に追加しました、そしてそれは私のために働きました。
位置 / {
proxy_pass http：// localhost ：8080;
proxy_http_version 1.1;
proxy_set_headerアップグレード$ http_upgrade;
proxy_set_header接続 "アップグレード";
proxy_set_headerホスト$ host;
}
https://chrislea.com/2013/02/23/proxying-websockets-with-nginx/

残念ながら、適切なヘッダーが設定されていても、同じ問題が発生します。構成を使用してスタックオーバーフローを作成しました。

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

ここで二重引用符をメモしてください：

proxy_set_header接続 "アップグレード";

一重引用符を使用してこのメ​​ッセージを受け取りましたが、二重引用符を使用すると解決しました。

約1時間のトラブルシューティングの後、エンドポイントをクラスターとして実行している場合は、追加の構成が必要になる可能性があります。

ここを参照してください

tylercbソリューションは私のために働いた（NgInx）。 ありがとう！

私たちにとっての鍵は、 @ tylercbのソリューションのproxy_http_version 1.1;た

これらの多くのコメントに従って、サーバー上のNginX構成を編集しました。
しかし、それは部分的に機能します。 最初は、サーバーの再起動後、正常に動作しません。 主にハードリフレッシュを使用します。 後でそれはより良く機能しますが、時々ハードリフレッシュが必要になります。
ローカルでsails liftを使用すると機能します
しかし、ローカルでsails lift --prodを使用している場合、同じことがわかります。そのソケットは接続できず、400の応答が悪くなります。 しかし、いくつかの試行の後、それは再び安定しています。

これはまだ解決されていないようです-なぜこれがあるのか​​、最終的な解決策は見つかりませんでした。

ドキュメントにさまざまな構成を追加しました： https ：//socket.io/docs/using-multiple-nodes/

改善のための提案は大歓迎です！ => https://github.com/socketio/socket.io-website

私はこの問題に直面しましたが、nginxを無効にしてもエラーが発生しました。 最後に、Expressのexpress-status-monitorミドルウェアが原因で問題が発生します。これにより、WebSocketの最初の（要求）ハンドシェイクでHTTP呼び出しが失敗します。

そのミドルウェアとWebSocketがうまく機能するのを無効にしようとしています

ハンドシェイク中に400を取得する理由はいくつかあります。 以下は、試すことができるいくつかのことです

1. （ufw /その他）ファイアウォールと（AWS / Googleクラウド/その他）コンソールの設定で443を有効にする
2. nodejsサーバーでTLSを有効にしないでください。 nginxを介してそれを行います。
3. 次のnginx構成を使用します
   注：これは、socket.io接続がすでに機能しているが、WebSocketの代わりに長いポーリングを使用している場合にのみ機能します。 以下のコードを追加すると、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;
        }

多分それは誰かの助けになるでしょう。 アプリでsocket.ioのインスタンスを2つ作成すると、このエラーが発生しました。 io = socketio(server)をtwiseと呼んで、エラー400が発生しました。これはある種の愚かなエラーですが...それは私のものでした。

アプリケーションロードバランサーでスティッキーセッションを有効にしていることを確認してください（従来のロードバランサーは使用しないでください）。 スティッキーセッションを使用しない場合、400エラーがランダムに発生する可能性があります。

これは、ポーリングからWebSocketへのアップグレードが試行されたときに、ロードバランサーがこのソケットIDに遭遇したことのないサーバーへのアップグレード要求のバランスを取り、400エラーをスローする可能性があるためです。 詳細はこちら： https ：//socket.io/docs/using-multiple-nodes/

また、Elastic Beanstalkを使用している場合は、.ebextensionsフォルダーに次のwebsocket.configファイルを追加して、NginxのWebsocketへのアップグレードをサポートします。

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

同じ問題が発生し、nginxも使用しているため、グーグルで検索しました。 解決策は、この部分を追加することです

proxy_http_version 1.1;
proxy_set_headerアップグレード$ http_upgrade;
proxy_set_header接続 "アップグレード";
proxy_set_headerホスト$ host;

前述のtylercbのようなnginx構成ファイルに。

したがって、少なくともこれは、nginxをリバースプロキシとして使用する場合に機能します。ここに説明があります

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.

この問題に関するニュースはありますか？ ここで参照しましたhttps://stackoverflow.com/questions/49575350/websocket-connection-to-wss-error-during-websocket-handshake-unexpected-re

多くのユーザーはnginx構成のためにこの問題を抱えており、専用サーバーでは上記のアイデア（nginx構成など）を使用して修正できます。多くのユーザーはこれらの設定にアクセスできないため、何らかの種類の設定があると便利です。これに関するsockets.ioからの修正...

誰でもない？

@deemeetree
サイトの「セッションIDが不明です」というエラーメッセージが原因で可能と思われる複数のノードを使用している場合は、StackOverflow （https://stackoverflow.com/a/53163917/6271092）の私の回答を参照してください。

簡単に言うと、彼らのサイト（https://socket.io/docs/using-multiple-nodes/）で言うようにsocket.io、

異なるプロセスまたはマシン間で接続の負荷を分散することを計画している場合は、特定のセッションIDに関連付けられた要求が、それらを発信したプロセスに接続していることを確認する必要があります。

これは、XHRポーリングやJSONPポーリングなどの特定のトランスポートが、「ソケット」の存続期間中に複数のリクエストを実行することに依存しているためです。 スティッキーバランシングを有効にしないと、恐ろしい結果になります。

Error during WebSocket handshake: Unexpected response code: 400

したがって、異なるノードで機能する複数のソケットを持つことはできません。 それが言うようにあなたのサーバーを再構成してください。 Expressの場合は、次のようにポートを構成します。
parseInt(your_port) + parseInt(process.env.NODE_APP_INSTANCE);

それが役に立てば幸い。

Windows Server 2008R2（プロキシなし、IISなし）でホストされているアプリに直接接続すると、同じエラーが発生しました。 中間のハードウェアのみ。

私はウィンドウサーバー2016で同じ問題に直面しています。あなたの修正について言及してください。 ありがとう

私はかなり長い間この問題に直面してきました。 誰かが何か情報を持っているなら助けてください。 Apacheサーバーを使用しています。

どんな手掛かり？ 開発ではうまく機能しますが、SSLでも同じ問題が発生します。

PM2ノードクラスターモードの使用：4 x 1

Apacheプロキシを使用しても、手がかりはありません

httpd2 / apache2を使用している場合は、機能しているように見えるソリューションがあります。

    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>

ねえ@ZeldaZachは.htaccessファイル用ですか？ ありがとう！

この設定は私のsites-enabled / site.confファイルにありますが、htaccessでも機能するはずです。

私が言えることは、SSLがここでの原因です:)無効にし、cloudflareの柔軟なSSLモードを使用して、FULL（STRICT）モードに移行します。 確かにこれで問題は解決しますが、
そうでない場合は、

リバースプロキシ構成でlocalhost：portを使用します。

ここでNginxとReactExpress（MERN）を使用している人のために。 proxy_pass http://localhost:3000;行しかないので、同じ問題が発生しました。 このスレッドで、上記の@tylercbの回答に基づいて次の行を追加しました。

「同じ問題がありましたが、私のアプリはnginxの背後にあります。Nginx構成にこれらの変更を加えると、エラーが削除されました。

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

これは元々 https://chrislea.com/2013/02/23/proxying-websockets-with-nginx/からのものです "

それでもNodejs + Expressの使用に問題がある場合は、 @ slaveofcodeが述べているように、問題はexpress-status-monitorである可能性があります。 NPMのドキュメントに記載されているように、このモジュールは独自のsocket.ioインスタンスを生成するため、websocketパラメーターにメインのsocket.ioインスタンスとポートパラメーターを入力する必要があります。

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

これは私のApache構成です/ws/パスプレフィックスを使用していることに注意してください。それ以外の場合は正常に機能します。

    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

現在、EKSクラスターのLinkerdダッシュボード（サービスメッシュ）を公開することでこの問題に直面しています。 私たちはnginxを使用しているので、現時点でそのnginxから抜け出す方法が正確にはわかりません。

@andrzj OMG男、あなたは私を救った。

同じ問題がありましたが、私のアプリはnginxの背後にあります。 Nginx構成にこれらの変更を加えると、エラーが削除されました。

位置 / {
proxy_pass http：// localhost ：8080;
proxy_http_version 1.1;
proxy_set_headerアップグレード$ http_upgrade;
proxy_set_header接続 "アップグレード";
proxy_set_headerホスト$ host;
}

これは元々 https://chrislea.com/2013/02/23/proxying-websockets-with-nginx/からのものです

できます。

ヘルプギャングをありがとう！ 誰かがこれを通常のHTTPSトラフィックの隣で機能させようとしている場合、次の設定でElasticBeanstalkで機能しています。

• Elastic Beanstalkの場合：nginxがオフになっています（現時点では、上記の構成を試すことにまだ慣れていません）。
• Elastic Beanstalkの場合：次のようにバランサーをロードします。
• Node / Expressの場合： const io = require('socket.io')(3030)
• クライアントでは、単にlet connection = io(https://www.myurl.com:3030)という名前を付けます

皆さんがまだこの問題を抱えていて、ソケットサーバーで許可されたオリジンを配列またはオリジンとして設定した場合、コールバック関数の代わりにオリジンをフィルタリングすると、このエラーがスローされます

Error during WebSocket handshake: Unexpected response code: 400

私の場合、このロジックを更新します

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

これに

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

エラーがスローされることなく動作しました。

これと同じエラーが発生しますが、NGINXの構成を追加しても、同じ400ハンドシェイクエラーが発生します。 ただし、AWSでApplication Load Balancerを使用しており、ターゲットグループに転送する：80ターゲットグループと443リスナーに設定しています。

NGINX confファイル：

`サーバー{

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

} `

そして、私のjsファイル内に、次のようなsocket.ioへの接続があります。
var socket = io()

手動インスタンスを作成し（エクスプレスappインスタンスなし）、別のポートを割り当てます

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

同じ問題がありましたが、私のアプリはnginxの背後にあります。 Nginx構成にこれらの変更を加えると、エラーが削除されました。

位置 / {
proxy_pass http：// localhost ：8080;
proxy_http_version 1.1;
proxy_set_headerアップグレード$ http_upgrade;
proxy_set_header接続 "アップグレード";
proxy_set_headerホスト$ host;
}

これは元々 https://chrislea.com/2013/02/23/proxying-websockets-with-nginx/からのものです

proxy_set_header Connection "upgrade";が足りませんでした

httpsまたはwssまたはsslを使い始めたとき、私はこの問題を解決するために一晩を費やしてきました。 常にconnection stopped before establishと400エラーコードが表示されます。

ほんの数分前、私はその解決策を見つけました：

0.Cloudflare

[SSL / TLS]タブ：

• 独自のcertまたはSSLまたはHTTPSがある場合： Fullに設定します。 （次の123の手順は、独自のhttps認定を取得していることを前提としています）

• http serverしかない場合： Flexibleに設定します。 （Cloudflareはあなたのウェブサイトにhttpsまたはsslを自動的に追加します。）

• その後、[DNS]タブに移動し、 Proxiedを設定します。

何をしているのかわからない場合は、[DNS]タブに移動し、 DNS onlyを設定してください。

1.正しいプロキシ構成になっていることを確認します。

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はドメイン、 http://127.0.0.1:5000はソケットサーバーです。

2.サーバーCross-Origin Controlsが'*'に設定されていることを確認して、 Cross-Origin Access $を許可します

flask-socketioの場合、 flask_socketio.SocketIO(app, cors_allowed_origins = '*')を使用します

3.新しい構成を機能させるには、nginxを再起動する必要があります

systemctl restart nginx

4. caddyの設定方法の詳細については、次のリンクを参照してください。

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/

同じ問題が発生し、nginxも使用しているため、グーグルで検索しました。 解決策は、この部分を追加することです

proxy_http_version 1.1;
proxy_set_headerアップグレード$ http_upgrade;
proxy_set_header接続 "アップグレード";
proxy_set_headerホスト$ host;

前述のtylercbのようなnginx構成ファイルに。

私のために働いてくれてありがとう！

私のようにElasticBeanstalkを使用してノードサーバーを作成している場合は、
環境の作成中に、どのプロキシサーバーを使用するかを構成で求められます。 どのnginxが事前入力されているか、デフォルトで設定されています。
そのプロキシサーバーをnoneに設定してから、サーバーの作成を続行しました。 Elastic Beanstalkを使用して、プロキシサーバーがデフォルトでnginxに設定されているノードサーバーを作成していました。
プロキシサーバーの設定エラーですので。 プロキシサーバーを削除した後、エラーは消えました。

nodejsアプリがあり、nginxがないため、何時間もグーグルしていて、上記のソリューションはどれも適用されませんでした。

これを解決する方法は、コンテナ->ロードバランサー設定からnginxを無効にして、すべてのトラフィックをノードに直接渡すことでした。

nodejsアプリがあり、nginxがないため、何時間もグーグルしていて、上記のソリューションはどれも適用されませんでした。

これを解決する方法は、コンテナ->ロードバランサー設定からnginxを無効にして、すべてのトラフィックをノードに直接渡すことでした。

どうやったの？

[構成]> [ロードバランサー]に移動すると、プロキシサーバーのドロップダウンが表示されます。nginx、Apacheを使用するか、「none」に設定して、ノードアプリへのすべての接続を通過させることができます。

これは、ロードバランサーを使用して環境を作成した場合にのみ表示され、単一のインスタンスでは機能しません

編集：私の元のコメントはElasticBeanstalkに言及されていました

同じ問題がありましたが、私のアプリはnginxの背後にあります。 Nginx構成にこれらの変更を加えると、エラーが削除されました。

位置 / {
proxy_pass http：// localhost ：8080;
proxy_http_version 1.1;
proxy_set_headerアップグレード$ http_upgrade;
proxy_set_header接続 "アップグレード";
proxy_set_headerホスト$ host;
}

これは元々 https://chrislea.com/2013/02/23/proxying-websockets-with-nginx/からのものです

だから、ありがとうございます。

このドキュメントは、laravel-echo-server＆Nginx＆socket.io＆Redis-serverを、クライアントプロジェクトとRedis-serverの間に分離されたサーバーで使用するユーザーを対象としています。

こちらのリンクをたどってください。

ありがとう

この問題が発生しました。 nginx構成を更新しても効果はありませんでしたが、 @ santhosh77hのソリューションで修正されました。 何らかの理由で、許可されたオリジンの配列を渡すことは機能しませんが、コールバックを使用することは機能します。

Nest.js WebSocket（Socket.ioのラッパー）を使用して、ゲートウェイに以下を追加しました。

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

AWS Elastic Beanstalk（Nginxプロキシ）で実行されているNode.js / Expressを使用したNUXT.jsでも同じ問題が発生しました。 これを理解するのに数日かかりました。 私の読書ポイントを共有します。 多分誰かがそれが役に立つと思うでしょう。

私の環境は、SSLを使用するhttps用に80、https用に443の2つのポートを備えたApplication LoadBalancer上にあります。

上記の回答を組み合わせて、 @ tylercbとAWSの公式ドキュメントおよびsocket.ioドキュメントに感謝します。この問題を修正しているように見える、Nginx構成ファイルを作成しました。

手順の概要を簡単に説明します。

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

フロントエンド（私のコンポーネントの1つ）：
import io from 'socket.io-client';
私のVuedata（）で：
socket: io()

最後に、アプリケーションルートに.ebextensionsフォルダーを作成しました
その中に、次の内容のファイル01-proxy.configを作成しました。

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"

追加の読み物：
nginx構成

それでおしまい。 かなり長いです。 私の謝罪と幸運。

角度のある.netコアのubuntuとngnixサーバーの変更の下で私のために働いています

位置 / {
proxy_pass http：// localhost ：8080;
proxy_http_version 1.1;
proxy_set_headerアップグレード$ http_upgrade;
proxy_set_header接続 "アップグレード";
proxy_set_headerホスト$ host;
}

それでもNodejs + Expressの使用に問題がある場合は、 @ slaveofcodeが述べているように、問題はexpress-status-monitorである可能性があります。 NPMのドキュメントに記載されているように、このモジュールは独自のsocket.ioインスタンスを生成するため、websocketパラメーターにメインのsocket.ioインスタンスとポートパラメーターを入力する必要があります。

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

この情報は私を助けました

socket.io接続がAmazonロードバランサーを経由していないことを確認してください。 または、その場合は、次のようにします：http： //blog.flux7.com/web-apps-websockets-with-aws-elastic-load-balancing

他の誰かがAWSロードバランサーを使用してこの問題を抱えていた場合、この記事では、SSLをロードバランサープロトコルとして使用し、アプリサーバーレベル以外でこの構成で証明書を使用し続けることが可能であるとは述べていません。

これは私のLBリスナーがどのように見えるかです

私のためにうまくいった！

同じ問題がありましたが、私のアプリはnginxの背後にあります。 Nginx構成にこれらの変更を加えると、エラーが削除されました。

位置 / {
proxy_pass http：// localhost ：8080;
proxy_http_version 1.1;
proxy_set_headerアップグレード$ http_upgrade;
proxy_set_header接続 "アップグレード";
proxy_set_headerホスト$ host;
}

これは元々 https://chrislea.com/2013/02/23/proxying-websockets-with-nginx/からのものです

はい。 これは役に立ち、私にも役立ちました。

socket.io接続がAmazonロードバランサーを経由していないことを確認してください。 または、その場合は、次のようにします：http： //blog.flux7.com/web-apps-websockets-with-aws-elastic-load-balancing

他の誰かがAWSロードバランサーを使用してこの問題を抱えていた場合、この記事では、SSLをロードバランサープロトコルとして使用し、アプリサーバーレベル以外でこの構成で証明書を使用し続けることが可能であるとは述べていません。

これは私のLBリスナーがどのように見えるかです

私のためにうまくいった！

いいですね、うまくいきました。

socket.io接続がAmazonロードバランサーを経由していないことを確認してください。 または、その場合は、次のようにします：http： //blog.flux7.com/web-apps-websockets-with-aws-elastic-load-balancing

他の誰かがAWSロードバランサーを使用してこの問題を抱えていた場合、この記事では、SSLをロードバランサープロトコルとして使用し、アプリサーバーレベル以外でこの構成で証明書を使用し続けることが可能であるとは述べていません。

これは私のLBリスナーがどのように見えるかです

私のためにうまくいった！

この場合、アプリケーションは80で実行されていますか？