Deribit FIX Logon 后连接为何立即断开？

结论

优先检查 Deribit Logon 认证数据的格式。当前代码将时间戳和 Base64 nonce 拼成 timestamp.nonce，用这个字符串计算 Password (554)，并将其作为 RawData (96) 发送。这与 Deribit FIX 文档描述的认证格式不一致，很可能导致认证失败并断开连接。

Deribit 文档要求，RawData (96) 使用随机 nonce 的 Base64 编码，Password (554) 则为 base64(sha256(nonce ++ access_secret))。认证失败时，服务端会发送 Logout (5)，然后关闭连接。Deribit FIX API 文档

调整认证数据

将生成的随机字节保留为签名输入，并把 Base64 编码后的 nonce 放入 RawData。不要在 nonce 前拼接时间戳：

nonce = os.urandom(32)
raw_data = base64.b64encode(nonce).decode("ascii")

signature_input = nonce + self.client_secret.encode("utf-8")
signature_hash = hashlib.sha256(signature_input).digest()
signature_b64 = base64.b64encode(signature_hash).decode("ascii")

message.setField(fix.Username(self.client_id))  # tag 553
message.setField(fix.Password(signature_b64))    # tag 554
message.setField(fix.RawDataLength(len(raw_data.encode("ascii"))))  # tag 95
message.setField(fix.RawData(raw_data))          # tag 96

RawDataLength (95) 应与实际发送的 RawData (96) 字节长度一致。Base64 字符串是 ASCII，因此长度按其编码后的字节数计算。每次连接都要重新生成随机 nonce，不能重复使用。

查看断开原因

现有输出只有 QuickFIX 的连接停止提示，没有服务端消息或 Logout 原因，因此无法仅凭这段终端日志确定断开的具体原因。调整认证字段后，检查 QuickFIX 的事件日志和消息日志，重点核对以下内容：

• 发出的 Logon (A) 是否包含预期的 553、554、95 和 96 字段。核对消息时不要公开实际凭据或签名。
• 是否收到服务端的 Logout (5)，以及其中 Text (58) 的内容。代码中的 fromAdmin 已尝试记录 Logout 原因。
• 是否收到服务端回显的 Logon (A)。Deribit 文档说明，成功登录后服务端会回显 Logon。
• QuickFIX 会话配置是否与所连接的 Deribit 环境及 FIX 会话参数匹配。如果日志显示会话层错误，再根据对应的拒绝原因排查。

保护凭据

示例会记录 Client Secret 片段、nonce 和完整 FIX 消息。应移除这些日志，避免 API secret、认证数据或其他敏感字段写入终端、日志文件或日志收集系统。优先记录消息类型、会话状态和脱敏后的错误原因。

备注：内容仅供参考。