如何解决Kraken私有HTTP API的nonce错误问题？

针对多来源共享同一API密钥导致的nonce冲突问题，以下是经过验证的可行方案：

核心问题本质 #

Kraken的nonce是绑定API密钥的全局递增计数器，而非单请求/单来源的局部值。当多个来源独立生成nonce时，必然会出现局部nonce小于全局已使用值、或不同来源生成重复nonce的情况，触发无效错误。

可行解决方案 #

1. 搭建中心化Nonce分发服务 #

这是最彻底的解决方式：

• 部署一个简单服务（比如基于Node.js+Redis），用Redis的INCR原子命令维护全局计数器，所有请求发起前必须先向该服务获取当前计数器值作为nonce。
• 确保所有来源的nonce都从同一处获取，从根源保证全局唯一且严格递增。

2. 改用全局同步的Nonce生成逻辑 #

如果不想单独搭服务，可基于共享存储实现分布式计数器：

• 用Redis的INCRBY或GETSET命令，每次请求前原子性获取并递增计数器，将其与时间戳结合（比如timestamp * 10000 + global_counter）作为nonce，既保证递增属性，又保留时间维度的有效性。

3. 优化错误重试策略 #

替换固定延迟重试为基于最新nonce的智能重试：

• 当收到EAPI:Invalid nonce错误时，先从中心化服务或共享存储获取当前最新的有效nonce值，用该值重新签名请求后再发起重试，避免用旧的无效nonce重复尝试。

4. 全局请求队列化 #

将所有来源的API请求统一加入一个全局队列，按顺序处理：

• 每个请求必须等待前一个请求完成后，再用前一个请求的nonce+1生成新nonce并发送，确保请求顺序与nonce递增严格一致，彻底杜绝乱序导致的错误。

为什么之前的方法无效？ #

• 延长nonce窗口：仅放宽了时间范围，但无法解决多来源nonce的全局冲突问题。
• 本地限流/重试：仅控制单来源的请求顺序，跨来源的请求依然会出现nonce交叉或重复。
• 多API密钥：若无法将不同来源与不同密钥绑定，本质还是同一密钥下的多来源冲突，无法解决问题。

内容的提问来源于stack exchange，提问作者serlingpa