[Bug]: 502

[lhxxrds]

Self Checks

• [x] I have searched for existing issues search for existing issues, including closed ones.
• [x] I confirm that I am using English to submit this report (Language Policy).
• [x] Non-english title submitions will be closed directly ( 非英文标题的提交将会被直接关闭 ) (Language Policy).
• [x] Please do not modify this template :) and fill in all the required fields.

RAGFlow workspace code commit ID

34567

RAGFlow image version

0.22.1

Other environment information

After deploying the server locally using Docker Compose, the frontend page continuously displays:

"The request failed with error 502: undefined

Bad Gateway."

Actual behavior

After deploying the server locally using Docker Compose, the frontend page continuously displays:

"The request failed with error 502: undefined

Bad Gateway."

Expected behavior

After deploying the server locally using Docker Compose, the frontend page continuously displays:

"The request failed with error 502: undefined

Bad Gateway."

Steps to reproduce

After deploying the server locally using Docker Compose, the frontend page continuously displays:

"The request failed with error 502: undefined

Bad Gateway."

Additional information

After deploying the server locally using Docker Compose, the frontend page continuously displays:

"The request failed with error 502: undefined

Bad Gateway."

[dosubot[bot]]

A persistent 502 Bad Gateway error after deploying RAGFlow with Docker Compose usually means the frontend (nginx) can't reach the backend API inside the container. The most common causes are: the backend service isn't running or is unhealthy (often due to MySQL or other dependencies not being ready), port conflicts, permission issues with mounted config files (like service_conf.yaml), or misconfigured environment variables in .env files. Sometimes, it's just a normal delay during the first startup while the database initializes—this should resolve itself after a few minutes, but if it doesn't, there's likely a deeper issue (source, source, source).

Here's a quick troubleshooting checklist:

1. Run docker compose ps and docker compose logs to check if all containers are healthy and look for errors in the backend or MySQL logs.
2. Make sure ports 80, 443, 9380, and 9381 are not in use by other services on your host.
3. Check that your .env file is complete and matches the expected variables for your image version.
4. If you mount service_conf.yaml or other config files, ensure they have the correct permissions (chmod 644 or 666) and, if using SELinux, add :z to the volume mount.
5. If you're on ARM64 hardware, make sure you're using a compatible image (source).
6. Try restarting Docker Compose and, if needed, your host's network manager (source).

If the error persists after these checks, please share the output of docker compose ps and the logs from the backend and MySQL containers—these will help pinpoint the root cause.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[lhxxrds]

ragflow-gpu-1 | 2025-11-24 16:23:35,393 WARNING 22 DB is not ready yet: (1146, "Table 'rag_flow.sync_logs' doesn't exist") ntion @dosu.

[dosubot[bot]]

The warning about the missing rag_flow.sync_logs table means the backend can't start because the database isn't fully initialized, which is causing the persistent 502 error. RAGFlow is designed to auto-create missing tables like sync_logs at startup, but this can fail if the MySQL user doesn't have permission to create tables, if the database schema is corrupted, or if there's a mismatch between your code, Docker image, and entrypoint script versions. This often leads to a loop where the backend keeps restarting and never becomes ready (source).

To fix this, check that your MySQL user has full privileges on the rag_flow database, make sure your code, Docker image, and entrypoint.sh script all match the same release, and consider using the latest official Docker image to avoid packaging issues (source). If you suspect your MySQL data directory is corrupted or incomplete, try removing the existing data volume and restarting the MySQL container so it can reinitialize (source). Also, ensure your system has enough memory, as resource constraints can cause backend processes to be killed and exacerbate startup failures.

Once these issues are resolved, restart the service and the backend should create the missing tables and start normally. If the backend is still stuck in a restart loop, check the backend and MySQL logs for permission errors or resource kills.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[lhxxrds]

ragflow-gpu-1 | 2025-11-24 16:41:27,721 WARNING 24 DB is not ready yet: (1146, "Table 'rag_flow.sync_logs' doesn't exist") @tion @dosu.

[dosubot[bot]]

The repeated warning about the missing rag_flow.sync_logs table means the backend can't start because the database isn't fully initialized, which is causing the persistent 502 error. RAGFlow should auto-create missing tables at startup, but this fails if the MySQL user doesn't have permission to create tables, if the database volume is corrupted or incomplete, or if there's a mismatch between your code, Docker image, and entrypoint script versions (details, code reference).

Here’s what to check next:

1. Make sure your MySQL user has full privileges to create tables in the rag_flow database.
2. Inspect the MySQL container logs for permission errors or signs of corruption.
3. If you’re using Docker volumes, try clearing the MySQL data volume (docker compose down -v) and redeploying.
4. Confirm your code, Docker image, and entrypoint script are all from the same release.
5. Check for resource constraints (memory, disk) that might be killing backend processes.
6. If you suspect permission issues, add privileged: true to the MySQL service in your docker-compose.yml.

If the database is still initializing, sometimes waiting a few minutes is enough. If the error persists after these steps, please share the backend and MySQL logs to help pinpoint the root cause (example, discussion).

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[lhxxrds]

Previously, I deployed version v0.21.0, but I didn't clean up the content in the corresponding mysql. Is this related to this? How should I do it? How can I delete the previous one and I am currently deploying version v0.22.1ion @dosu.

[KevinHuSh]

This is probably caused by that backend server is not up.

[lhxxrds]

How can this be solved? Is it a problem with ragflow itself or with the deployment on our client's side? @KevinHuSh

[lhxxrds]

@KevinHuSh May I ask how long it will take to fix this problem approximately? How can this be solved? Is it a problem with ragflow itself or with the deployment on our client's side? on @dosu.