Dify 工作流运行时报 502 Bad Gateway 错误，通常是因为网关（Nginx）无法连接到后端 API 服务或 Worker 服务超时。建议优先检查 Docker 容器状态和后端日志，确认服务是否存活或是否存在资源耗尽情况。

命令速用版

以下命令用于快速检查 Dify 服务状态和日志，假设使用默认 Docker Compose 部署名称。

# 检查容器运行状态
docker ps | grep dify

# 查看 API 服务日志
docker logs -f dify-api

# 查看 Worker 服务日志
docker logs -f dify-worker

# 检查容器资源占用
docker stats dify-api dify-worker

为什么会这样

502 Bad Gateway 表示网关收到了上游服务的无效响应。在 Dify 架构中，Nginx 作为入口网关，若后端 API 或 Worker 进程崩溃、重启或响应超时，Nginx 会直接返回 502 状态码。

常见触发场景包括后端服务内存溢出（OOM）被系统杀死、工作流执行时间超过网关配置超时阈值、或容器间网络通信异常。公开资料中没有看到可靠的量化数据说明具体超时阈值，需根据实际部署配置确认。

分步处理

按顺序执行以下步骤，每步完成后记录状态再进入下一步。

步骤 1：确认容器存活状态

执行docker ps命令，查找dify-api和dify-worker容器。若状态不是Up或显示Restarting，说明服务不稳定。若容器不存在，检查是否被意外删除或部署脚本未生效。

步骤 2：排查后端日志报错

执行docker logs `--tail` 200 dify-api。重点搜索ERROR、Exception或Traceback关键字。若看到Out Of Memory或Killed字样，说明资源不足。若看到数据库连接错误，检查 PostgreSQL 容器状态。

步骤 3：检查系统资源负载

执行docker stats观察 CPU 和内存使用率。若 API 或 Worker 容器内存接近限制值，考虑增加 Docker 内存限制或服务器物理内存。若 CPU 持续 100%，可能是工作流中有高消耗节点。

步骤 4：调整超时配置（自建部署）

若是自建部署，检查 Nginx 配置中的proxy_read_timeout设置。若工作流执行时间较长，需适当调大该值。修改配置后需重启 Nginx 容器生效。注意不要无限调大，以免占用过多连接资源。

怎么验证是否生效

执行以下操作确认修复效果：

1. 重新运行之前报错的工作流，观察是否不再返回 502 页面。

2. 查看 Nginx 访问日志（通常位于容器内/var/log/nginx/access.log），确认状态码变为 200。

3. 持续观察docker stats5 分钟，确认容器没有频繁重启或资源飙升。

常见坑

1. 盲目重启服务：不查看日志直接重启容器可能掩盖根本原因，导致问题反复出现。

2. 混淆 502 与 504：502 是上游无效响应（常因崩溃），504 是网关超时（常因执行慢）。排查方向不同，504 更多需要优化工作流或增加超时时间。

3. 忽略 Sandbox 服务：若工作流包含代码执行节点，Sandbox 服务异常也可能导致上游通信失败，需同时检查dify-sandbox容器状态。

常见问题

502 错误和 504 错误有什么区别？

502 表示后端服务返回了无效响应或连接被拒绝，通常意味着服务崩溃；504 表示后端服务处理时间过长，网关主动断开了连接。

工作流简单也会报 502 吗？

会。即使工作流简单，若后端 API 服务因内存不足崩溃或数据库连接池耗尽，Nginx 依然会返回 502 错误。

修改超时配置后需要重启所有容器吗？

不需要。仅修改 Nginx 配置只需重启 Nginx 容器；若修改了 API 后端环境变量，则需重启 API 和 Worker 容器。

参考来源

1. Dify GitHub Repository, langgenius/dify, https://github.com/langgenius/dify