我需要為 websocket 通信啟用壓縮（使用 socketio）。我通過將 設定為perMessageDeflate在true我的開發環境和登臺服務器上運行良好（使用 Wireshark 驗證）來做到這一點。但是，在我們的生產服務器上，websocket 連接失敗，socketio (v4.4.1) 退回到輪詢。兩者都使用 nginx 作為反向代理，配置相同。Chromium 控制臺顯示
WebSocket 連接到“wss://***/ws-test/socket.io/?EIO=4&transport=websocket&sid=9P4EelJhF0CcxvwNAAAE”失敗：WebSocket 握手期間出錯：意外回應代碼：400
我創建了一個顯示相同行為的最小示例。服務器上的 Nodejs 應用程式：
const express = require('express');
const app = express();
const http = require('http');
const server = http.createServer(app);
const { Server } = require("socket.io");
const io = new Server(server, {
perMessageDeflate: true
});
app.get('/', (req, res) => {
res.sendFile(__dirname '/index.html');
});
server.listen(3001, () => {
console.log('listening on *:3001');
});
客戶：
...
<script src="socket.io/socket.io.js"></script>
<script>
var socketio_path = window.location.pathname 'socket.io';
var socket = io( { path: socketio_path } );
</script>
</body>
錯誤 400 似乎來自 nodejs 服務器，而不是來自 nginx。我啟用了各種日志記錄，但找不到任何相關訊息。軟體版本也相當接近和最新：nginx 1.18.0（暫存和生產），nodejs 14.19.0/14.18.1（暫存/生產）。你有什么想法可以幫助在生產服務器上完成這項作業嗎？
uj5u.com熱心網友回復：
事實證明，問題在于生產服務器上使用的 Azure 應用程式網關。當它被繞過時，websocket 連接（perMessageDeflate啟用）作業正常。
切換到更新版本的 Azure 應用程式網關（v2 而不是 v1）最終解決了這個問題。
轉載請註明出處，本文鏈接：https://www.uj5u.com/qiye/450986.html