Signal-CLI-REST-API 设备注册问题深度解析

问题背景

在使用 Signal-CLI-REST-API 项目时，用户遇到了一个常见但令人困惑的问题：当尝试通过 REST API 发送消息时，系统返回"400 Bad Request"错误，提示"User is not registered"。这个问题尤其出现在使用链接设备(Linked Device)而非主注册设备的情况下。

核心问题分析

经过深入调查，我们发现问题的根源在于 Signal 服务对设备类型的严格区分。Signal 服务将设备分为两类：

1. 主注册设备：通过手机号码直接注册的设备，通常是用手机上的 Signal 应用
2. 链接设备：通过主设备授权连接的附属设备，如桌面应用或其他终端

关键点在于：Signal-CLI-REST-API 的 REST 接口仅支持通过主注册设备发送消息，而不支持链接设备。这与直接在容器内使用 signal-cli 命令行工具的行为不同，因为命令行工具可以同时支持两种设备类型。

解决方案

要解决这个问题，用户需要：

1. 确保 Signal-CLI-REST-API 使用的是主注册设备而非链接设备
2. 正确配置持久化存储，防止设备注册信息丢失
3. 验证配置目录是否正确挂载

持久化存储配置要点

许多用户遇到设备注册信息丢失的问题，这通常是由于 Docker 容器重启后配置未正确持久化导致的。正确的配置应包括：

volumes:
  - "./signal-cli-config:/home/.local/share/signal-cli"

而不是错误的：

volumes:
  - "./signal-cli-config:/opt/dcc/signalcli/signal-cli-config/"

技术原理深入

Signal 服务的安全模型要求 API 调用必须来自已验证的主设备。当使用 REST API 时，Signal-CLI-REST-API 内部会强制执行这一安全策略，而直接使用命令行工具时则相对宽松。这种设计差异导致了表面上的不一致行为。

最佳实践建议

1. 始终为主设备而非链接设备配置 Signal-CLI-REST-API
2. 定期检查持久化存储中的配置文件完整性
3. 使用 debug 模式排查问题时，注意比较 REST API 和命令行工具的参数差异
4. 考虑设置自动接收消息的定时任务，保持设备活跃状态

总结

理解 Signal 服务的设备类型区分机制是解决此类问题的关键。通过正确配置主设备和持久化存储，可以确保 Signal-CLI-REST-API 的稳定运行。这一案例也提醒我们，在集成不同系统时，需要深入理解各组件的工作原理和安全模型。