Arbitrum 的最佳 WSS 端点 (2026)

简短回答 — 在 Arbitrum 上，“最佳 WSS 端点”实际上是两个问题。 对于读取（相当于内存池的可见性），正确的订阅是 Arbitrum 排序器提要，它在进入已确认的块之前通过 WebSocket 广播每个已接受的交易 - 这取代了此处不存在的公共内存池概念。 对于写入（发送您自己的交易），您需要一个低延迟的 JSON-RPC 端点，理想情况下是一个商业私有 RPC（QuickNode、Alchemy、Chainstack），距离您的部署区域大约 50 毫秒 p95，或者是一个位于排序器附近的自托管 Nitro 节点，以实现大容量。将它们混合起来——或者尝试针对公共 RPC 运行正常的 eth_subscribe('newPendingTransactions')——会造成无法恢复的延迟。本指南涵盖了两部分。

精通之路

• Arbitrum 剧本：私人捆绑包
• Arbitrum MEV 延迟和路由
• WSS 端点指南（当前）
• 最佳以太坊私有 RPC

为什么 Arbitrum 的 WSS 格局与众​​不同

在以太坊主网上，通过 eth_subscribe('newPendingTransactions') 对任何节点进行内存池订阅都会为您提供相同的视图（模对等连接）。在 Arbitrum 上，公共内存池并不作为点对点广播层存在——交易直接进入集中式排序器。所以：

• 读取： 规范的低延迟源是 sequencer feed，这是一个发布已接受交易的 Arbitrum 特定 WebSocket。大多数商业提供商“不”直接公开这一点。您可以通过官方端点订阅它，也可以运行您自己的 Nitro 节点并在本地提取提要。
• 写入： WSS 上的标准 JSON-RPC 按预期工作。写入端点的延迟很重要，因为定序器在每个窗口内按先来的原则接受。

将链视为以太坊主网（并在商业 RPC 上追逐待处理的交易子）是 Arbitrum WSS 最常见的错误。您会看到一些东西 - 但不是您需要回滚的实时信号，因为您看到的大多数待处理交易已经已经被排序。

读取端：测序仪提要提供者

官方提要是免费的；瓶颈是您的订阅者所在的区域。 us-east-2（排序器基础设施当前所在位置）中的 feed 订阅者的延迟为个位数毫秒；从 ap-southeast-1 开始有数十到数百。协同定位在这里比在以太坊上更重要。

写入端：JSON-RPC 提供者

为了将交易发送回网络，传统的商业 RPC 提供商都可以工作。 2026 年的现实定位：

（层名称和确切的延迟数字因区域、合同和时间而异 — 在提交之前使用 WSS 延迟测试 针对您的实际部署区域进行基准测试。）

具体在 Arbitrum 上衡量什么

通用的“p50/p95 延迟”很重要，但两个特定于 Arbitrum 的信号更能预测真实的交易结果：

1. 从 Feed 事件到排序区块的时间。 如果您的 Feed 订阅者看到一笔交易，那么该交易需要多长时间才会出现在已确认的区块中？稳态时间为亚秒级；如果它在拖动，则序列器会降级，并且您的模拟在您签名时可能已经过时。
2. 针对写入端点的 eth_chainId 上的往返。 这是最便宜的 RPC 调用。如果它很慢，那么您进行的所有其他调用也会很慢 - 并且 eth_chainId 缓慢通常与提供商的超额订阅容量相关。

每天对两者进行 30 秒的采样并记录时间戳，足以在会话花费时间之前发现回归。

轮换政策

• 在平静时期为您的终点集设置基线。记录每个地区每个提供商的 p50/p95。
• 当当前 p95 超过基线 50% 以上并持续 5 分钟以上时发出警报。这是退化，而不是噪音。
• 在轮换时，将读取和写入端点切换到备用端点 - 大多数操作员会忘记读取端，并最终得到一个快速写入端点，该端点回滚陈旧的数据。
• 让轮出端点在低 rps 下保持温暖 30 分钟，因此快速回滚的成本较低。

Arbitrum WSS 常见错误

• 订阅 newPendingTransactions 而不是定序器提要。 您会得到一个“技术上”包含交易的提要，但它是过时的衍生品 - 定序器已经接受了它们。
• 使用免费层写入进行时间敏感的发送。 免费层在波动期间会大幅限制。前 50 次发送看起来不错；第 51 个位于队列中，直到速率窗口重置。
• **跨区域回退会悄悄地使延迟加倍。**从 us-east-2 回退到 eu-west-1 每个方向会增加约 80 毫秒。如果您的策略需要低于 50 毫秒，则故障转移状态是无利可图的。针对延迟发出警报，而不仅仅是针对硬故障发出警报。
• 出站带宽饱和。 风暴期间，跨 4 个端点的反向运行扇出可能会导致小型 VPS 上的出站带宽激增。在依赖配置之前在合成负载下进行测试。

2026 年工作配置

适合认真操作员的现实 Arbitrum-MEV 端点堆栈：

• 阅读： 自托管 Nitro 节点位于 us-east-2，在本地订阅官方定序器提要。
• **主要写入：**同一区域的 Tier-1 商业 RPC（低于 50 毫秒 p95）。
• **二次写入：**同一地区的不同商业提供商进行扇出/轮换。
• 第三级写入： 不同的云区域以对冲区域中断。可接受较低级别；这是为了“保持活力”，而不是“保持快速”。

对于较低容量的运营商（低于约 5000 美元/天的 MEV），放弃自托管节点并运行两个 2 层商业 RPC。在数量有意义之前，边际成本与边缘数学并不能证明硬件的合理性。

常见问题解答

问：我可以使用相同的端点进行读取和写入吗？ 大多数商业 RPC 都提供这两种功能 - 但对于 Arbitrum 读取，您特别需要定序器提要订阅，而不是 eth_subscribe('newPendingTransactions')。在将 Arbitrum 定序器提要提交到生产读取端工作流程之前，请确认您的提供商明确公开了该提要。

问：我应该多久对我的端点进行一次基准测试？ 在活动会话期间每天运行 60 秒延迟示例并保存结果。每日测量足以检测随着时间的推移逐渐退化；实时监控每个单独的呼叫通常是不必要的开销，除非您的操作量很大，其中 10 毫秒的回归会导致可衡量的盈亏 (PnL)。

问：我应该部署在哪个区域？ 对于 Arbitrum 定序器，us-east-2（AWS 美国东部）是定序器基础设施当前所在的位置。将订阅者置于同一区域可将读取延迟降低至个位数毫秒。如果您的主要部署位于另一个区域，请在上线之前对跨区域延迟进行基准测试 - 对于您正在运行的策略来说，这可能是可以接受的，也可能不是。

问：我什么时候应该运行自己的 Nitro 节点，而不是使用商业 RPC？ 当您的每日归属 MEV 量足够大，边际延迟改进（写入 10-25 毫秒，商业版 25-50 毫秒）转化为有意义的额外包含率时，自托管 Nitro 值得支付基础设施成本。对于大多数低于 5,000 美元/天的 MEV 运营商来说，两个二级商业 RPC 可以满足需求，而无需运营开销。

参考

• Arbitrum 排序器提要格式和 WebSocket 订阅
• Arbitrum Nitro 节点运营商文档
• WSS 延迟测试工具