解决连接问题

常见/已知问题：

• socket 无法连接
• socket 断开连接
• socket 卡在 HTTP 长轮询中

问题：socket无法连接

可能的解释：

• 您正在尝试访问普通的 WebSocket 服务器
• 服务器无法访问
• 客户端与服务器版本不兼容
• 服务器未发送必要的 CORS 标头
• 您没有启用粘性会话（在多服务器设置中）

您正在尝试访问普通的 WebSocket 服务器

如“Socket.IO 不是什么”部分所述，Socket.IO 客户端不是 WebSocket 实现，因此无法与 WebSocket 服务器建立连接，即使transports: ["websocket"]：

const socket = io("ws://echo.websocket.org", {
  transports: ["websocket"]
});

服务器无法访问

请确保 Socket.IO 服务器实际上可以通过给定的 URL 访问。您可以使用以下方法对其进行测试：

curl "<the server URL>/socket.io/?EIO=4&transport=polling"

它应该返回如下内容：

0{"sid":"Lbo5JLzTotvW3g2LAAAA","upgrades":["websocket"],"pingInterval":25000,"pingTimeout":20000}

如果不是这种情况，请检查 Socket.IO 服务器是否正在运行，并且两者之间没有任何东西阻止连接。

客户端与服务器版本不兼容

这是JS 客户端的兼容性表：

[1] 使用allowEIO3: true

以下是Java 客户端的兼容性表：

[1] 使用allowEIO3: true

这是Swift 客户端的兼容性表：

[1] 使用 allowEIO3: true（服务器）和.connectParams(["EIO": "3"])（客户端）：

SocketManager(socketURL: URL(string:"http://localhost:8087/")!, config: [.connectParams(["EIO": "3"])])

[2] 使用 allowEIO3: true（服务器）

[3] 使用 .version(.two)（客户端）：

SocketManager(socketURL: URL(string:"http://localhost:8087/")!, config: [.version(.two)])

服务器未发送必要的 CORS 标头

如果您在控制台中看到以下错误：

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at ...

大概意思是：

• 要么你实际上没有到达 Socket.IO 服务器（见上文）
• 或者您没有在服务器端启用跨域资源共享(CORS)。

请在此处查看文档。

您没有启用粘性会话（在多服务器设置中）

当扩展到多个 Socket.IO 服务器时，您需要确保给定 Socket.IO 会话的所有请求都到达同一个 Socket.IO 服务器。解释可以在这里找到。

否则将导致 HTTP 400 响应代码：{"code":1,"message":"Session ID unknown"}

请在此处查看文档。

问题: socket 断开连接

首先，请注意，即使在稳定的 Internet 连接上，断开连接也很常见并且是意料之中的：

• 用户和 Socket.IO 服务器之间的任何事情都可能遇到临时故障或重新启动
• 作为自动缩放策略的一部分，服务器本身可能会被终止
• 如果使用移动浏览器，用户可能会失去连接或从 WiFi 切换到 4G
• 浏览器本身可能会冻结非活动选项卡

话虽如此，除非另有明确说明，否则Socket.IO 客户端将始终尝试重新连接。

断开连接的可能解释：

• 浏览器选项卡最小化，心跳失败
• 客户端与服务器版本不兼容
• 你正试图发送一个巨大的有效载荷

浏览器选项卡最小化，心跳失败

当浏览器选项卡不在焦点上时，某些浏览器（如Chrome）会限制 JavaScript 计时器，这可能会通过Socket.IO v2 中的 ping 超时导致断开连接，因为心跳机制依赖于setTimeout客户端的功能。

作为一种解决方法，您可以增加pingTimeout服务器端的值：

const io = new Server({
  pingTimeout: 60000
});

请注意，升级到 Socket.IO v4（至少socket.io-client@4.1.3，由于这个原因）应该可以防止此类问题，因为心跳机制已被反转（服务器现在发送 PING 数据包）。

客户端与服务器版本不兼容

由于通过 WebSocket 传输发送的数据包格式在 v2 和 v3/v4 中相似，因此您可能能够连接不兼容的客户端（见上文），但连接最终会在给定延迟后关闭。

因此，如果您在 30 秒后遇到定期断开连接（这是Socket.IO v2 中pingTimeout 和 pingInterval值的总和），这肯定是由于版本不兼容。

你正试图发送一个巨大的有效载荷

如果您在发送大量有效负载时断开连接，这可能意味着您已达到maxHttpBufferSize默认值为 1 MB 的值。请根据您的需要进行调整：

const io = require("socket.io")(httpServer, {
  maxHttpBufferSize: 1e8
});

上传时间超过pingTimeout选项值的巨大负载也可能触发断开连接（因为在上传期间heartbeat mechanism失败）。请根据您的需要进行调整：

const io = require("socket.io")(httpServer, {
  pingTimeout: 60000
});

问题: socket 卡在 HTTP 长轮询中

在大多数情况下，您应该会看到如下内容：

1. Engine.IO 握手（包含会话 ID — 此处 zBjrh...AAAK — 用于后续请求）
2. tSocket.IO 握手请求（包含auth选项的值）
3. Socket.IO 握手响应（包含Socket#id）
4. WebSocket 连接
5. 第一个 HTTP 长轮询请求，一旦建立 WebSocket 连接就关闭

如果您没有看到第四个请求的HTTP 101 Switching Protocols响应，这意味着服务器和浏览器之间的某些东西阻止了 WebSocket 连接。

请注意，这不一定是阻塞的，因为连接仍然是通过 HTTP 长轮询建立的，但效率较低。

您可以通过以下方式获取当前传输的名称：

客户端

socket.on("connect", () => {
  const transport = socket.io.engine.transport.name; // 在大多数情况下, "polling"
  socket.io.engine.on("upgrade", () => {
    const upgradedTransport = socket.io.engine.transport.name; // 在大多数情况下, "websocket"
  });
});

服务器

io.on("connection", (socket) => {
  const transport = socket.conn.transport.name; // 在大多数情况下, "polling"
  socket.conn.on("upgrade", () => {
    const upgradedTransport = socket.conn.transport.name; // 在大多数情况下, "websocket"
  });
});

可能的解释：

• 服务器前面的代理不接受 WebSocket 连接

服务器前面的代理不接受 WebSocket 连接

请在此处查看文档。