websocket error

该报错通常出现在 Dify 自托管（Source 方式）部署中，由协作模式（Collaboration Mode）的 WebSocket 连接异常触发，常见原因包括 `api` 与 `api_websocket` 容器使用不同的 `SECRET_KEY`，以及 Socket.IO 的 Redis p

快速结论：该报错通常出现在 Dify 自托管（Source 方式）部署中，由协作模式（Collaboration Mode）的 WebSocket 连接异常触发，常见原因包括 `api` 与 `api_websocket` 容器使用不同的 `SECRET_KEY`，以及 Socket.IO 的 Redis pub/sub 监听超时。优先检查 `.env` 中是否显式设置了统一的 `SECRET_KEY`，并确认 `api_websocket` 服务是否正确挂载共享存储卷。

适用环境：Dify `latest` 版本（Issue 记录时为 latest），Self Hosted (Source) 部署方式；涉及 `api` 与 `api_websocket` 容器、Socket.IO/Redis pub-sub 通信链路。Issue 未提供 Python、CUDA、显卡等环境数据。

最快修复方案：在 `.env` 中设置 `ENABLE_COLLABORATION_MODE=false` 后重启服务（该操作已被多位用户验证可立即绕开报错）。但注意这属于“绕过”而非修复，若需要保留协作模式，请继续执行下方解决步骤修复根因。

注意事项：禁用协作模式会关闭 Dify 中依赖 WebSocket 的多人协作能力，可能影响相关页面实时同步功能。`SECRET_KEY` 修改后需要同步重启 `api` 和 `api_websocket` 两个服务，且应使用同一个持久化配置（例如写入 `.env`），避免容器重启后再次自动生成随机值。

问题场景

用户通过自托管源码方式部署 Dify，在未修改任何配置的情况下，前端持续出现 websocket error 提示，导致协作相关功能不可用。Issue 中附带了报错截图，但未说明具体操作界面。

报错原文

websocket error

原因分析

该问题指向 Dify 协作/WebSocket 子系统，已确认存在两个可能触发点：

  • 原因一（已确认）：api 与 api_websocket 两个容器各自自动生成了不同的 SECRET_KEY。当你未在 .env 显式设置 SECRET_KEY 时，每个容器都会在启动时生成独立密钥，导致 WebSocket 连接携带的 JWT 无法通过另一侧验证，抛出 InvalidSignatureError。相关修复见 PR #39424。
  • 原因二（已确认）：Socket.IO 使用的 Redis pub/sub 监听继承了 socket_timeout 配置（默认 5 秒），导致阻塞式 pubsub.listen() 循环反复出现 TimeoutError，伴随日志 "Cannot receive from redis... retrying in 1 secs"。相关修复见 PR #39587。

环境排查

标签
celebrityanime
celebrityanime
文章: 18303

相关文章

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注