WebSocket RPC 断开连接的原因及修复方法

直接答案：为什么 WebSocket RPC 会断开

如果你的 JSON-RPC WebSocket 连接不断断开，根本原因几乎总是以下三种之一：负载均衡器或代理强制执行的空闲超时、网络级中断（NAT、移动运营商）或服务器端策略关闭未发送定期 ping 的连接。你看到的关闭代码——1006（异常关闭）、1008（策略违规）或 1001（正在离开）——是主要的诊断线索。

解决方案有两部分：实现心跳（ping/pong）以保持连接活跃，并构建带指数退避和抖动的重连策略。本文解释了每种原因背后的机制、如何诊断你的具体情况，以及如何实现一个能够优雅应对断开的稳健客户端。

理解 RPC 场景中的 WebSocket 关闭代码

WebSocket 关闭代码在 RFC 6455 中标准化。当连接关闭时，客户端或服务器会发送带有代码的关闭帧。在 RPC 场景中，你通常会遇到：

• 1006（异常关闭）：连接在没有关闭帧的情况下关闭。这通常表示网络问题——TCP 连接被丢弃、代理超时或防火墙终止了连接。这是 RPC 断开最常见的代码。

• 1008（策略违规）：服务器因客户端违反策略而关闭连接，例如发送过多请求、使用不支持的协议或未在超时时间内响应 ping。

• 1001（正在离开）：服务器正在关闭或客户端正在导航离开。在 RPC 中，这可能在服务器维护或端点重新部署时发生。

当你看到 1006 时，它通常是一个无声的杀手：连接只是死亡，你的客户端可能直到尝试发送请求并失败时才知道。这就是心跳至关重要的原因——它们迫使客户端快速检测死连接。

• 1006：异常关闭，无关闭帧——网络/代理问题
• 1008：策略违规——服务器拒绝了你的行为
• 1001：正在离开——服务器维护或关闭

机制：空闲超时和负载均衡器

大多数 RPC 提供商（包括 OnFinality）将 WebSocket 端点置于负载均衡器和代理之后。这些组件通常会强制执行空闲超时以释放资源。例如，AWS ALB 对 WebSocket 连接的默认空闲超时为 60 秒，如果未交换数据，则会关闭连接。同样，nginx 的 proxy_read_timeout 默认值为 60 秒。

关键点是 空闲 意味着没有发送数据帧。WebSocket ping/pong 帧算作数据，因此每 30 秒（或更短）发送一次 ping 可以防止超时触发。如果没有心跳，你的连接将在空闲期后被终止，你会看到 1006 关闭代码。

另一个机制是 NAT 超时。如果你的客户端位于家庭路由器或移动运营商后面，NAT 映射可能会在一段时间不活动后过期（通常为 30-120 秒）。当映射过期时，传入帧无法到达你的客户端，连接看起来已死。心跳可以保持 NAT 映射活跃。

诊断断开：工具和命令

要诊断 WebSocket RPC 断开的原因，你需要观察关闭代码和时序。这里有两种实用方法：

1. 浏览器开发者工具（适用于 Web 应用）：打开 Network 选项卡，按 WS 过滤，然后点击 WebSocket 连接。'Messages' 选项卡显示发送和接收的帧。'Close' 事件将显示代码和原因。如果你看到 1006，请注意自最后一帧以来的时间——这就是你的空闲超时。

2. 使用 websocat 或 wscat 的命令行：安装 wscat（Node.js）或 websocat（Rust）并连接到你的 RPC 端点。发送一个 JSON-RPC 请求，然后等待。观察连接何时关闭。示例：

wscat -c wss://eth-mainnet.public.blastapi.io
# 连接后，发送：{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}
# 然后等待，看看连接是否在约 60 秒后关闭

如果连接在固定间隔后关闭，则是空闲超时。如果随机关闭，则可能是网络不稳定。你也可以使用 curl -v 查看 WebSocket 握手和关闭帧，但 curl 不会保持连接。

要进行更详细的分析，请使用 tcpdump 捕获数据包并查找 TCP FIN 或 RST 数据包。RST 表示硬重置，通常来自防火墙或代理。

wscat -c wss://eth-mainnet.public.blastapi.io
# 发送：{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}
# 观察关闭代码和时序

实现心跳和保活

标准解决方案是使用 ping/pong 帧实现 WebSocket 心跳。WebSocket 协议支持 ping 和 pong 控制帧。客户端发送 ping，服务器必须响应 pong。如果在超时时间内未收到 pong，则认为连接已死。

在 JavaScript（Node.js 或浏览器）中，ws 库提供了内置的 ping/pong 处理。以下是最小示例：

const WebSocket = require('ws');

const ws = new WebSocket('wss://your-rpc-endpoint');

let isAlive = true;

ws.on('open', () => {
  console.log('Connected');
  // 每 30 秒发送一次 ping
  const interval = setInterval(() => {
    if (isAlive) {
      ws.ping();
    } else {
      clearInterval(interval);
      ws.terminate();
    }
  }, 30000);
});

ws.on('pong', () => {
  isAlive = true;
});

ws.on('close', (code, reason) => {
  console.log(`Closed with code ${code}: ${reason}`);
  // 在此处添加重连逻辑
});

对于 Python，websockets 库有一个 ping_interval 参数。示例：

import asyncio
import websockets

async def main():
    async with websockets.connect('wss://your-rpc-endpoint', ping_interval=30, ping_timeout=10) as ws:
        # 你的 RPC 调用
        pass

asyncio.run(main())

ping_interval 每 30 秒发送一次 ping，ping_timeout 等待 pong 10 秒。如果没有 pong，连接将关闭，你可以重连。

重要：某些 RPC 提供商可能不会响应 ping，如果它们未正确实现。请与你的提供商测试。如果不支持 ping，你可以发送一个轻量级的 JSON-RPC 请求（例如 eth_blockNumber）作为保活，但这会消耗速率限制。尽可能优先使用 ping/pong。

构建稳健的重连策略

即使有心跳，连接也会断开。一个稳健的客户端必须自动重连，并使用指数退避和抖动，以避免压垮服务器。

指数退避：断开后，等待短时间（例如 1 秒），然后在每次后续失败时加倍等待（1 秒、2 秒、4 秒、8 秒……）直到最大值（例如 60 秒）。抖动 为等待时间添加随机性，以防止许多客户端同时重连时出现惊群问题。

以下是使用 ws 和简单退避的 JavaScript 实现：

function connectWithBackoff() {
  let attempt = 0;
  const maxDelay = 60000;

  function connect() {
    const ws = new WebSocket('wss://your-rpc-endpoint');
    ws.on('open', () => {
      attempt = 0;
      console.log('Connected');
      // 如上设置心跳
    });
    ws.on('close', (code, reason) => {
      console.log(`Closed: ${code} ${reason}`);
      const delay = Math.min(1000 * Math.pow(2, attempt), maxDelay) + Math.random() * 1000;
      attempt++;
      setTimeout(connect, delay);
    });
    ws.on('error', (err) => {
      console.error('WebSocket error:', err);
      ws.close();
    });
  }
  connect();
}

在 Python 中，你可以使用 backoff 库或手动实现。关键是永远不要在紧密循环中立即重连；始终至少等待一秒。

此外，考虑使用自动处理重连的库，例如 JavaScript 的 reconnecting-websocket 或 Python 的 websocket-client 自动重连。但是，要理解底层逻辑，以便进行调优。

WebSocket 与 HTTP 用于 RPC：何时使用哪种

WebSocket 非常适合实时、双向通信，例如订阅区块链事件（如 eth_subscribe）。HTTP 更简单且无状态，适合一次性请求。如果你的应用只需要偶尔查询，HTTP 更可靠且更易于扩展。如果你需要推送通知或流式传输，则必须使用 WebSocket。

权衡：WebSocket 连接是有状态的，需要保活和重连逻辑。HTTP 请求是无状态的，可以轻松重试。对于区块链 RPC，许多开发人员使用 WebSocket 进行订阅，使用 HTTP 进行常规调用。这种混合方法降低了断开影响关键操作的风险。

有关选择正确端点的更多信息，请参阅我们的 RPC 端点指南 和 多链 RPC 端点指南。

常见陷阱和提供商特定行为

陷阱 1：未正确处理 'close' 事件。 某些客户端只监听 'error' 而错过 'close' 事件。始终处理两者。

陷阱 2：过于频繁地发送 ping。 某些服务器可能会限制 ping 速率。坚持 30 秒或更长。

陷阱 3：忽略关闭代码。 如果你看到 1008，则是策略违规——检查你的请求速率和有效负载大小。如果你看到 1001，则服务器正在离开；等待更长时间再重连。

提供商特定行为：某些提供商（如 Infura 或 Alchemy）有文档化的空闲超时。例如，Infura 的 WebSocket 连接可能在 60 秒不活动后关闭。OnFinality 的 WebSocket 端点也有空闲超时；我们建议心跳间隔为 30 秒或更短。请查看提供商的文档以了解具体限制。

如果你使用公共 RPC 端点，请注意它们可能有更严格的限制。对于生产环境，请考虑通过我们的 RPC 定价页面 或 API 服务 使用专用端点。

验证修复：预期行为

实现心跳和重连后，验证连接是否长时间保持活跃。使用记录连接状态和时间戳的脚本。预期行为：

• 连接保持打开数小时，没有任何关闭事件。

• 如果发生网络中断，客户端会在 ping 超时（例如 10 秒）内检测到，并使用退避重连。

• 重连时的关闭代码通常是 1006（异常）或 1001（服务器维护），你的客户端会优雅地处理。

你可以通过断开 Wi-Fi 或使用 kill -STOP 暂停进程来模拟网络中断。观察重连行为。

后续步骤和进一步阅读

既然你了解了 WebSocket RPC 断开的原因以及如何修复，你可以将这些模式应用到自己的应用程序中。有关更多 RPC 故障排查，请参阅我们的文章 修复 RPC 超时错误 和 降低 RPC 延迟。

如果你正在以太坊或 Solana 上构建，请查看我们的网络页面：以太坊 和 Solana。有关 RPC 提供商的更广泛概述，请阅读我们的 最佳 RPC 提供商指南。

最后，考虑使用 监控 RPC 端点 等工具监控你的 WebSocket 连接，以便及早发现问题。