Dify 1.13.3 stuck on loading after Docker restart / all console APIs return 502

[cjmadcdfsdfasf]

Self Checks

• I have searched for existing issues search for existing issues, including closed ones.
• I confirm that I am using English to submit this report (我已阅读并同意 Language Policy).
• [FOR CHINESE USERS] 请务必使用英文提交 Issue，否则会被关闭。谢谢！:)
• Please do not modify this template :) and fill in all the required fields.

Content

Hi everyone,

I’m running Dify 1.13.3 with Docker Compose on a cloud server.

This morning everything worked normally, but after restarting Docker, the Dify console became stuck on the loading spinner and never finished loading.

Environment:

• Dify version: 1.13.3
• Docker Compose deployment
• OS: CentOS
• PostgreSQL + Redis included
• Plugin disabled

Current docker compose services:

• api
• worker
• web
• postgres
• redis

All containers are running successfully.

docker compose ps:

dify-api-1 Up
dify-worker-1 Up
dify-web-1 Up
dify-postgres-1 Up (healthy)
dify-redis-1 Up

API health check works correctly:

curl http://127.0.0.1:8002/health

returns:

{"pid":9,"status":"ok","version":"1.13.3"}

However, the frontend cannot load.

Browser console shows many errors like:

GET /console/api/features 502 (Bad Gateway)
GET /console/api/workspaces 502 (Bad Gateway)
GET /console/api/account/profile 502 (Bad Gateway)

The page stays on the loading spinner forever.

My docker-compose.yaml uses:

web:
environment:
CONSOLE_API_URL: http://47.xxx.xxx.xxx:8002
APP_API_URL: http://47.xxx.xxx.xxx:8002

api:
environment:
MODE: api
INIT_DATABASE: false
CONSOLE_CORS_ALLOW_ORIGINS: "*"

I already:

• added worker service
• disabled plugin
• restarted all containers
• confirmed postgres is healthy
• confirmed API /health endpoint works

But frontend APIs still return 502.

Has anyone encountered this issue after restarting Docker on Dify 1.13.x?

Is there any required nginx/proxy configuration for 1.13.x that is missing in minimal deployments?

Thanks a lot.

[dosubot[bot]]

Hi @cjmadcdfsdfasf! I'm Dosu and I’m helping the dify team.

The issue is that your deployment is missing the nginx reverse proxy service, which is part of the standard Dify Docker Compose setup and handles routing /console/api/* requests to the API backend [1].

Here's what's happening:

1. You set CONSOLE_API_URL: http://47.xxx.xxx.xxx:8002 in the web service — this tells the browser to make API calls directly to that URL [2].
2. The browser sends requests like GET http://47.xxx.xxx.xxx:8002/console/api/features — but that's hitting the web container or nothing useful on port 8002, not the API service on port 5001.
3. Meanwhile, your /health check works because you're curling the API container directly.

Fix — Option A: Add nginx back (recommended)

Use the standard docker-compose.yaml which includes the nginx service [3]. Nginx routes /console/api/* to the API on port 5001 internally. Then set:

CONSOLE_API_URL=http://47.xxx.xxx.xxx
APP_API_URL=http://47.xxx.xxx.xxx

(pointing to whatever port nginx exposes, default 80).

Fix — Option B: Leave CONSOLE_API_URL empty

Another user resolved this exact issue on 1.14.1 by setting CONSOLE_API_URL= (empty) in .env, which causes the frontend to make API calls relative to the same host/port it's served from [4]. If your web container is the entry point, this may work if you configure it to also proxy API requests.

Fix — Option C: Expose the API directly and fix the port

If you truly want to run without nginx, make sure the API container's port 5001 is exposed as 8002:

api:
  ports:
    - "8002:5001"

And set:

CONSOLE_API_URL=http://47.xxx.xxx.xxx:8002
APP_API_URL=http://47.xxx.xxx.xxx:8002
CONSOLE_CORS_ALLOW_ORIGINS=*

The standard deployment includes nginx for a reason — it handles routing, CORS, WebSocket upgrades, and static file serving all in one place. I'd recommend adding it back from the official docker-compose.yaml.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.