Dify 在 Windows 11 + Docker 环境下工作流 404 / 启动 502 问题及解决思路_dify页面502

本文基于 Dify 在 Windows 11 (通常通过 WSL2) + Docker Compose 环境下部署的常见问题，特别是修改默认访问端口后引发的配置连锁反应。

问题现象：

1. Dify 部署完成后，访问正常，但在运行工作流时提示“应用不可用” (通常伴随浏览器开发者工具中的 404 Not Found 错误)。

2. 修改 Dify 的访问端口（如将 80/443 改为 8080/8443）后，可能出现无法启动或直接提示 502 Bad Gateway。

3. 浏览器开发者工具（F12 -> Network）显示对 /v1/api/... 或 /console/api/... 等 API 路径的请求返回 404 Not Found 或 502 Bad Gateway。

核心原理回顾：

• Docker 内部通信： Docker Compose 会为服务创建一个内部虚拟网络，服务之间可以通过服务名称（如 api, web, redis, db 等）互相访问，使用其容器内部监听的端口。

• Docker 端口映射： docker-compose.yaml 中的 ports 配置 (宿主机端口:容器内部端口) 将容器内部的服务端口暴露到 Windows 宿主机上，供外部浏览器访问。

• Nginx 反向代理 (web 服务)： Dify 的 web 容器通常运行 Nginx，它负责接收来自外部浏览器对 XXX.XXX.XXX.XXX:YYYY 的请求，并根据请求路径（如 /v1/, /console/api/, /）将请求代理转发到 Docker 内部对应的服务和端口（如 api:5001, web:3000, plugin_daemon:5002）。

• Nginx proxy_pass 与路径转发： proxy_pass 指令负责定义请求转发的目标地址。proxy_pass http://upstream_address:port; (末尾无斜杠) 和 proxy_pass http://upstream_address:port/; (末尾有斜杠) 会导致不同的路径转发行为。

• 服务实际监听端口： Dify 各服务（API, Web/Next.js, Plugin Daemon 等）在容器内部实际监听的端口可能与默认值或配置中预期的不同（例如 API 实际监听 5001 而非 5000，Web/Next.js 实际监听 3000 而非 80）。

问题诊断流程：

1. 确认服务运行状态：

• 打开终端，进入 Dify Docker 部署目录。

• 运行 docker compose ps，确保所有核心容器（api, web, redis, db, worker, sandbox 等）状态为 running。