langgenius/dify
1
0
Fork 0
mirror of https://github.com/langgenius/dify.git synced 2026-07-22 12:36:14 -04:00
Code Issues 775 Packages Projects Releases 10 Wiki Activity

Workflow cannot be saved #15870

New Issue
Closed
opened 2026-02-21 19:23:45 -05:00 by yindo · 8 comments
yindo commented 2026-02-21 19:23:45 -05:00
Owner
Copy Link
Copy Source

Originally created by @hutao86 on GitHub (Aug 4, 2025).

Self Checks

  • I have read the Contributing Guide and Language Policy.
  • This is only for bug report, if you would like to ask a question, please head to Discussions.
  • I have searched for existing issues search for existing issues, including closed ones.
  • I confirm that I am using English to submit this report, otherwise it will be closed.
  • 【中文用户 & Non English User】请使用英语提交，否则会被关闭 ：）
  • Please do not modify this template :) and fill in all the required fields.

Dify version

1.6.0

Cloud or Self Hosted

Self Hosted (Docker)

Steps to reproduce

When creating or editing a workflow, nodes appear to save successfully based on the UI confirmation message. However, the data is not actually persisted. Upon inspecting the browser's developer console (F12), the save request fails with a net::ERR_CONNECTION_RESET error. This issue occurs intermittently — the save operation works only in approximately 10% of attempts. No related error logs were found in any of the backend containers during the failed requests. This makes the workflow editing feature unreliable and significantly impacts usability. Further investigation into potential network, backend timeout, or race condition issues is recommended.

✔️ Expected Behavior

Users should be able to save workflows successfully every time and run them without being affected by transient network or persistence issues.

❌ Actual Behavior

No response

Originally created by @hutao86 on GitHub (Aug 4, 2025). ### Self Checks - [x] I have read the [Contributing Guide](https://github.com/langgenius/dify/blob/main/CONTRIBUTING.md) and [Language Policy](https://github.com/langgenius/dify/issues/1542). - [x] This is only for bug report, if you would like to ask a question, please head to [Discussions](https://github.com/langgenius/dify/discussions/categories/general). - [x] I have searched for existing issues [search for existing issues](https://github.com/langgenius/dify/issues), including closed ones. - [x] I confirm that I am using English to submit this report, otherwise it will be closed. - [x] 【中文用户 & Non English User】请使用英语提交，否则会被关闭 ：） - [x] Please do not modify this template :) and fill in all the required fields. ### Dify version 1.6.0 ### Cloud or Self Hosted Self Hosted (Docker) ### Steps to reproduce When creating or editing a workflow, nodes appear to save successfully based on the UI confirmation message. However, the data is not actually persisted. Upon inspecting the browser's developer console (F12), the save request fails with a net::ERR_CONNECTION_RESET error. This issue occurs intermittently — the save operation works only in approximately 10% of attempts. No related error logs were found in any of the backend containers during the failed requests. This makes the workflow editing feature unreliable and significantly impacts usability. Further investigation into potential network, backend timeout, or race condition issues is recommended. ### ✔️ Expected Behavior Users should be able to save workflows successfully every time and run them without being affected by transient network or persistence issues. ### ❌ Actual Behavior _No response_
yindo added the 🐞 bug label 2026-02-21 19:23:45 -05:00
yindo closed this issue 2026-02-21 19:23:45 -05:00
yindo commented 2026-02-21 19:23:45 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (Aug 4, 2025):

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

Intermittent net::ERR_CONNECTION_RESET errors when saving workflows in self-hosted Docker setups are usually caused by network-level issues, resource constraints, or infrastructure timeouts, rather than application logic bugs. Since you’re not seeing backend logs for failed requests, the problem likely occurs before the request reaches the Dify API code—often due to dropped connections, reverse proxy misconfiguration, or Docker resource exhaustion [source].

Here’s a focused checklist to help isolate and resolve the issue:

  • Check Docker resource limits (CPU/memory) and monitor for container restarts or OOM kills, as resource constraints can cause intermittent failures [source].
  • Review your reverse proxy (e.g., Nginx, Traefik) and firewall settings for aggressive timeouts or dropped connections. Make sure proxy timeouts are set higher than your expected workflow save duration.
  • Inspect logs from all relevant containers, especially the API container (docker-compose logs api). If logs are missing, increase logging verbosity with LOG_LEVEL=DEBUG and enable request logging with ENABLE_REQUEST_LOGGING=True in your environment [source].
  • Review .env settings for timeouts: HTTP_REQUEST_MAX_READ_TIMEOUT, HTTP_REQUEST_MAX_WRITE_TIMEOUT, WORKFLOW_MAX_EXECUTION_STEPS, and WORKFLOW_MAX_EXECUTION_TIME. Increase these if your workflows are large or slow to save [source].
  • If you use SSRF proxy settings, try disabling them or increasing their timeouts, as misconfigured SSRF proxies have caused similar connection reset issues for other users [source].
  • Avoid using localhost for inter-container communication; use the host IP or Docker network aliases instead [source].
  • For rare cases, SQLAlchemy session management errors (like DetachedInstanceError) can cause save failures. Setting expire_on_commit=False in your SQLAlchemy config can help, though this is less likely if you see no backend logs [source].

If the problem persists after these checks, try to capture network traces (e.g., with tcpdump or Wireshark) during a failed save to see where the connection is being reset. This can help pinpoint whether the issue is at the Docker, proxy, or host network layer.

To reply, just mention @dosu.

How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other  Chat with Dosu Join Discord Share on X

@dosubot[bot] commented on GitHub (Aug 4, 2025): <!-- Greeting --> Hi @hutao86! I'm [Dosu](https://go.dosu.dev/dosubot) and I’m helping the dify team. <!-- Answer --> Intermittent `net::ERR_CONNECTION_RESET` errors when saving workflows in self-hosted Docker setups are usually caused by network-level issues, resource constraints, or infrastructure timeouts, rather than application logic bugs. Since you’re not seeing backend logs for failed requests, the problem likely occurs before the request reaches the Dify API code—often due to dropped connections, reverse proxy misconfiguration, or Docker resource exhaustion [[source](https://github.com/langgenius/dify/issues/12098)]. Here’s a focused checklist to help isolate and resolve the issue: - Check Docker resource limits (CPU/memory) and monitor for container restarts or OOM kills, as resource constraints can cause intermittent failures [[source](https://github.com/langgenius/dify/issues/20984)]. - Review your reverse proxy (e.g., Nginx, Traefik) and firewall settings for aggressive timeouts or dropped connections. Make sure proxy timeouts are set higher than your expected workflow save duration. - Inspect logs from all relevant containers, especially the API container (`docker-compose logs api`). If logs are missing, increase logging verbosity with `LOG_LEVEL=DEBUG` and enable request logging with `ENABLE_REQUEST_LOGGING=True` in your environment [[source](https://github.com/langgenius/dify/issues/20246)]. - Review `.env` settings for timeouts: `HTTP_REQUEST_MAX_READ_TIMEOUT`, `HTTP_REQUEST_MAX_WRITE_TIMEOUT`, `WORKFLOW_MAX_EXECUTION_STEPS`, and `WORKFLOW_MAX_EXECUTION_TIME`. Increase these if your workflows are large or slow to save [[source](https://github.com/langgenius/dify/issues/14445)]. - If you use SSRF proxy settings, try disabling them or increasing their timeouts, as misconfigured SSRF proxies have caused similar connection reset issues for other users [[source](https://github.com/langgenius/dify/issues/12098)]. - Avoid using `localhost` for inter-container communication; use the host IP or Docker network aliases instead [[source](https://github.com/langgenius/dify/issues/14151)]. - For rare cases, SQLAlchemy session management errors (like `DetachedInstanceError`) can cause save failures. Setting `expire_on_commit=False` in your SQLAlchemy config can help, though this is less likely if you see no backend logs [[source](https://github.com/langgenius/dify/issues/14571)]. If the problem persists after these checks, try to capture network traces (e.g., with `tcpdump` or Wireshark) during a failed save to see where the connection is being reset. This can help pinpoint whether the issue is at the Docker, proxy, or host network layer. <!-- Dosu Comment Footer --> *To reply, just mention [@dosu](https://go.dosu.dev/dosubot).* --- <sup>How did I do? [Good](https://app.dosu.dev/response-feedback/bdca5218-585e-4790-aa2f-4e6ebc85e691?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/bdca5218-585e-4790-aa2f-4e6ebc85e691?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/bdca5218-585e-4790-aa2f-4e6ebc85e691?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/bdca5218-585e-4790-aa2f-4e6ebc85e691?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/bdca5218-585e-4790-aa2f-4e6ebc85e691?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/bdca5218-585e-4790-aa2f-4e6ebc85e691?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/bdca5218-585e-4790-aa2f-4e6ebc85e691?feedback_type=other)</sup>&nbsp;&nbsp;[![Chat with Dosu](https://dosu.dev/dosu-chat-badge.svg)](https://app.dosu.dev/6088a4f4-073a-43f3-b3d4-4f06fb0c05a0/ask?utm_source=github)&nbsp;[![Join Discord](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&label=)](https://go.dosu.dev/discord-bot)&nbsp;[![Share on X](https://img.shields.io/badge/X-share-black)](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/langgenius/dify/issues/23381)
yindo commented 2026-02-21 19:23:45 -05:00
Author
Owner
Copy Link
Copy Source

@hutao86 commented on GitHub (Aug 4, 2025):

Image
@hutao86 commented on GitHub (Aug 4, 2025): <img width="1528" height="503" alt="Image" src="https://github.com/user-attachments/assets/542035cc-4954-456c-9d7f-1c16f08b26ac" />
yindo commented 2026-02-21 19:23:46 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (Aug 4, 2025):

The net::ERR_CONNECTION_REFUSED error in your screenshot means the frontend can't reach the backend API container that serves the 'draft' endpoint—usually because the service is down, not listening, or unreachable on port 5001. This is different from net::ERR_CONNECTION_RESET, which often points to network instability or timeouts; connection refused is more fundamental and means nothing is accepting connections at that address.

Here’s what to check next:

  • Make sure the API container is running and healthy: run docker-compose ps and docker-compose logs api to check for crashes or restarts.
  • Confirm your .env has correct API URLs (CONSOLE_API_URL, SERVICE_API_URL, APP_API_URL), DIFY_BIND_ADDRESS is set to 0.0.0.0, and port settings (EXPOSE_NGINX_PORT, EXPOSE_NGINX_SSL_PORT) match your intended setup. If you change API URL env vars, you must rebuild the frontend image for changes to take effect, since these are baked in at build time [source].
  • Check Docker network and port mappings—ensure nothing else is using port 5001 and that the frontend can reach the backend container.
  • Verify middleware containers (Postgres, Redis, Weaviate) are running and healthy; if they’re restarting or unhealthy, the API may not start or may crash [source].
  • Make sure no firewall or host network policy is blocking access to ports 80, 443, or 5001.

If you’ve recently changed environment variables or moved the deployment, rebuild and restart all containers. Some users have resolved similar issues by deploying an Nginx proxy with HTTPS in front of Dify, or by redeploying on a different server/environment [source].

If you share the output of docker-compose ps and docker-compose logs api, I can help interpret what’s going wrong.

To reply, just mention @dosu.

How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other  Chat with Dosu Join Discord Share on X

@dosubot[bot] commented on GitHub (Aug 4, 2025): <!-- Answer --> The net::ERR_CONNECTION_REFUSED error in your screenshot means the frontend can't reach the backend API container that serves the 'draft' endpoint—usually because the service is down, not listening, or unreachable on port 5001. This is different from net::ERR_CONNECTION_RESET, which often points to network instability or timeouts; connection refused is more fundamental and means nothing is accepting connections at that address. Here’s what to check next: - Make sure the API container is running and healthy: run `docker-compose ps` and `docker-compose logs api` to check for crashes or restarts. - Confirm your .env has correct API URLs (CONSOLE_API_URL, SERVICE_API_URL, APP_API_URL), DIFY_BIND_ADDRESS is set to 0.0.0.0, and port settings (EXPOSE_NGINX_PORT, EXPOSE_NGINX_SSL_PORT) match your intended setup. If you change API URL env vars, you must rebuild the frontend image for changes to take effect, since these are baked in at build time [[source]](https://github.com/langgenius/dify/issues/20879). - Check Docker network and port mappings—ensure nothing else is using port 5001 and that the frontend can reach the backend container. - Verify middleware containers (Postgres, Redis, Weaviate) are running and healthy; if they’re restarting or unhealthy, the API may not start or may crash [[source]](https://github.com/langgenius/dify/issues/16410). - Make sure no firewall or host network policy is blocking access to ports 80, 443, or 5001. If you’ve recently changed environment variables or moved the deployment, rebuild and restart all containers. Some users have resolved similar issues by deploying an Nginx proxy with HTTPS in front of Dify, or by redeploying on a different server/environment [[source]](https://github.com/langgenius/dify/issues/13507). If you share the output of `docker-compose ps` and `docker-compose logs api`, I can help interpret what’s going wrong. <!-- Dosu Comment Footer --> *To reply, just mention [@dosu](https://go.dosu.dev/dosubot).* --- <sup>How did I do? [Good](https://app.dosu.dev/response-feedback/206bb70a-f179-4649-bddb-0413a9c3cfa3?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/206bb70a-f179-4649-bddb-0413a9c3cfa3?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/206bb70a-f179-4649-bddb-0413a9c3cfa3?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/206bb70a-f179-4649-bddb-0413a9c3cfa3?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/206bb70a-f179-4649-bddb-0413a9c3cfa3?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/206bb70a-f179-4649-bddb-0413a9c3cfa3?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/206bb70a-f179-4649-bddb-0413a9c3cfa3?feedback_type=other)</sup>&nbsp;&nbsp;[![Chat with Dosu](https://dosu.dev/dosu-chat-badge.svg)](https://app.dosu.dev/6088a4f4-073a-43f3-b3d4-4f06fb0c05a0/ask?utm_source=github)&nbsp;[![Join Discord](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&label=)](https://go.dosu.dev/discord-bot)&nbsp;[![Share on X](https://img.shields.io/badge/X-share-black)](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/langgenius/dify/issues/23381)
yindo commented 2026-02-21 19:23:46 -05:00
Author
Owner
Copy Link
Copy Source

@hutao86 commented on GitHub (Aug 4, 2025):

Image Image Image Image
@hutao86 commented on GitHub (Aug 4, 2025): <img width="1695" height="632" alt="Image" src="https://github.com/user-attachments/assets/cf6ec66d-792b-4212-9172-eb5a102a5bd4" /> <img width="1688" height="658" alt="Image" src="https://github.com/user-attachments/assets/c6dbf1dc-0d2f-4073-9518-c4d3a1ac5cb5" /> <img width="1704" height="791" alt="Image" src="https://github.com/user-attachments/assets/13ca4f54-2477-48c8-8da4-4d98c787212f" /> <img width="1437" height="411" alt="Image" src="https://github.com/user-attachments/assets/ec2cd6b0-8b10-4552-8060-97c728f6b5b8" />
yindo commented 2026-02-21 19:23:46 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (Aug 4, 2025):

Your error (gevent.exceptions.BlockingSwitchOutError during SQLAlchemy rollback) is a known issue in Dify 1.6.0 Docker deployments using gevent. This happens when a blocking DB operation is attempted inside gevent’s async event loop, often due to concurrency model mismatches or improper session handling. There’s no explicit workaround in the codebase—Dify relies on early gevent monkey patching and psycogreen for async DB support, but this isn’t always enough to prevent these errors, especially under load or with thread-heavy tasks like embedding or parallel workflows [source].

Best practices to reduce these errors: use context-managed SQLAlchemy sessions (with Session(db.engine, expire_on_commit=False) as session:) for all DB writes, especially inside loops or parallel nodes; avoid using the global db.session in long-running or concurrent code; and close sessions promptly after use [source]. For thread-heavy workloads, switch SERVER_WORKER_CLASS from gevent to uvicorn or another async-friendly worker—this is the most effective workaround for thread contention and deadlocks in Docker [source].

There’s no official Dify documentation warning about gevent’s incompatibility with thread-heavy workloads, but several issues confirm that using gevent with ThreadPoolExecutor or synchronous HTTP calls can cause blocking and concurrency errors. If you still see this error after making these changes, try to capture logs immediately before the BlockingSwitchOutError for more clues, and consider running a minimal reproducible example to isolate the problem.

To reply, just mention @dosu.

How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other  Chat with Dosu Join Discord Share on X

@dosubot[bot] commented on GitHub (Aug 4, 2025): <!-- Answer --> Your error (`gevent.exceptions.BlockingSwitchOutError` during SQLAlchemy rollback) is a known issue in Dify 1.6.0 Docker deployments using gevent. This happens when a blocking DB operation is attempted inside gevent’s async event loop, often due to concurrency model mismatches or improper session handling. There’s no explicit workaround in the codebase—Dify relies on early gevent monkey patching and psycogreen for async DB support, but this isn’t always enough to prevent these errors, especially under load or with thread-heavy tasks like embedding or parallel workflows [[source]](https://github.com/langgenius/dify/issues/22430). Best practices to reduce these errors: use context-managed SQLAlchemy sessions (`with Session(db.engine, expire_on_commit=False) as session:`) for all DB writes, especially inside loops or parallel nodes; avoid using the global `db.session` in long-running or concurrent code; and close sessions promptly after use [[source]](https://github.com/langgenius/dify/issues/22929). For thread-heavy workloads, switch `SERVER_WORKER_CLASS` from `gevent` to `uvicorn` or another async-friendly worker—this is the most effective workaround for thread contention and deadlocks in Docker [[source]](https://github.com/langgenius/dify/issues/23223). There’s no official Dify documentation warning about gevent’s incompatibility with thread-heavy workloads, but several issues confirm that using gevent with ThreadPoolExecutor or synchronous HTTP calls can cause blocking and concurrency errors. If you still see this error after making these changes, try to capture logs immediately before the BlockingSwitchOutError for more clues, and consider running a minimal reproducible example to isolate the problem. <!-- Dosu Comment Footer --> *To reply, just mention [@dosu](https://go.dosu.dev/dosubot).* --- <sup>How did I do? [Good](https://app.dosu.dev/response-feedback/f975839c-6c4a-4b4a-b95b-342d7d0f4e8d?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/f975839c-6c4a-4b4a-b95b-342d7d0f4e8d?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/f975839c-6c4a-4b4a-b95b-342d7d0f4e8d?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/f975839c-6c4a-4b4a-b95b-342d7d0f4e8d?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/f975839c-6c4a-4b4a-b95b-342d7d0f4e8d?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/f975839c-6c4a-4b4a-b95b-342d7d0f4e8d?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/f975839c-6c4a-4b4a-b95b-342d7d0f4e8d?feedback_type=other)</sup>&nbsp;&nbsp;[![Chat with Dosu](https://dosu.dev/dosu-chat-badge.svg)](https://app.dosu.dev/6088a4f4-073a-43f3-b3d4-4f06fb0c05a0/ask?utm_source=github)&nbsp;[![Join Discord](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&label=)](https://go.dosu.dev/discord-bot)&nbsp;[![Share on X](https://img.shields.io/badge/X-share-black)](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/langgenius/dify/issues/23381)
yindo commented 2026-02-21 19:23:46 -05:00
Author
Owner
Copy Link
Copy Source

@hutao86 commented on GitHub (Aug 4, 2025):

Both saving and running workflows exhibit the same issue in the browser: the HTTP request initially shows as "Pending" in the Network tab, and eventually fails with net::ERR_CONNECTION_RESET. This behavior occurs almost consistently — nearly every attempt to publish or execute a workflow is affected.

Image Image Image

容器日志如下
docker logs -f dify-160-db-1

Image

docker logs -f dify-160-api-1

Image

docker logs -f dify-160-sandbox-1

Image

docker logs -f dify-160-ssrf_proxy-1

Image
@hutao86 commented on GitHub (Aug 4, 2025): Both saving and running workflows exhibit the same issue in the browser: the HTTP request initially shows as "Pending" in the Network tab, and eventually fails with net::ERR_CONNECTION_RESET. This behavior occurs almost consistently — nearly every attempt to publish or execute a workflow is affected. <img width="1716" height="578" alt="Image" src="https://github.com/user-attachments/assets/d967b857-da04-420e-9908-1bd8526a354b" /> <img width="1524" height="329" alt="Image" src="https://github.com/user-attachments/assets/90156c64-3662-467d-a9f8-09498f98b566" /> <img width="1517" height="553" alt="Image" src="https://github.com/user-attachments/assets/423e8280-322a-4c42-ad69-1d25bd4a8f43" /> 容器日志如下 docker logs -f dify-160-db-1 <img width="1506" height="256" alt="Image" src="https://github.com/user-attachments/assets/5c836e1c-b3d3-4b4b-a2d4-42547957b8d5" /> docker logs -f dify-160-api-1 <img width="1500" height="397" alt="Image" src="https://github.com/user-attachments/assets/0e1f5e98-67b9-47aa-94ed-7a1029046aab" /> docker logs -f dify-160-sandbox-1 <img width="931" height="700" alt="Image" src="https://github.com/user-attachments/assets/94e8d9d5-0cc1-44b6-9ecc-70738a8d6402" /> docker logs -f dify-160-ssrf_proxy-1 <img width="1175" height="552" alt="Image" src="https://github.com/user-attachments/assets/4c1465a5-5394-461e-8dfb-bce3111329c6" />
yindo commented 2026-02-21 19:23:46 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (Aug 4, 2025):

Your persistent net::ERR_CONNECTION_RESET and net::ERR_CONNECTION_REFUSED errors almost always point to infrastructure or network issues in self-hosted Docker deployments, not Dify application bugs. The most common causes are: API container crashes or restarts, Docker resource exhaustion (CPU/memory), reverse proxy or firewall timeouts, SSRF proxy misconfiguration, or unhealthy middleware containers (Postgres, Redis, Weaviate). These issues can cause the frontend to lose connection to the backend, resulting in pending requests that eventually fail reference.

Here’s a focused checklist to help you isolate the problem:

  1. Check that all containers are running and healthy (docker-compose ps). Look for restarts or stopped containers.
  2. Review API container logs (docker-compose logs api) for errors or crashes. If logs are missing, set LOG_LEVEL=DEBUG and ENABLE_REQUEST_LOGGING=True in your .env and restart.
  3. Make sure your .env has correct API URLs (CONSOLE_API_URL, SERVICE_API_URL, APP_API_URL), DIFY_BIND_ADDRESS=0.0.0.0, and that port mappings (EXPOSE_NGINX_PORT, EXPOSE_NGINX_SSL_PORT) match your setup. If you change API URL env vars, rebuild the frontend image.
  4. Check Docker resource limits and monitor for OOM kills or high CPU/memory usage.
  5. If you use a reverse proxy (Nginx, Traefik), increase proxy timeouts to be higher than your longest workflow save/run.
  6. If SSRF proxy is enabled, try disabling it or increasing its timeouts—misconfigured SSRF proxies are a known cause of connection resets reference.
  7. Avoid using localhost for inter-container communication; use Docker network aliases or the host IP.
  8. Make sure no firewall or host network policy is blocking required ports (80, 443, 5001).

If you still see the issue, please share the output of docker-compose ps and docker-compose logs api right after a failed request. This will help pinpoint whether the API is crashing, being killed, or unreachable due to network/proxy issues.

Note: The gevent BlockingSwitchOutError you saw in logs is a known concurrency issue in Dify 1.6.0 Docker setups. If you have thread-heavy workloads, switching SERVER_WORKER_CLASS from gevent to uvicorn in your .env is the most effective workaround reference.

Application-level fixes are unlikely to help until these infrastructure/network issues are ruled out. Dify’s workflow engine is sensitive to Docker resource limits, proxy timeouts, and concurrency model mismatches, so resolving these is key to stable workflow save/run operations reference.

To reply, just mention @dosu.

How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other  Chat with Dosu Join Discord Share on X

@dosubot[bot] commented on GitHub (Aug 4, 2025): <!-- Answer --> Your persistent net::ERR_CONNECTION_RESET and net::ERR_CONNECTION_REFUSED errors almost always point to infrastructure or network issues in self-hosted Docker deployments, not Dify application bugs. The most common causes are: API container crashes or restarts, Docker resource exhaustion (CPU/memory), reverse proxy or firewall timeouts, SSRF proxy misconfiguration, or unhealthy middleware containers (Postgres, Redis, Weaviate). These issues can cause the frontend to lose connection to the backend, resulting in pending requests that eventually fail [reference](https://github.com/langgenius/dify/issues/23381). Here’s a focused checklist to help you isolate the problem: 1. Check that all containers are running and healthy (`docker-compose ps`). Look for restarts or stopped containers. 2. Review API container logs (`docker-compose logs api`) for errors or crashes. If logs are missing, set `LOG_LEVEL=DEBUG` and `ENABLE_REQUEST_LOGGING=True` in your `.env` and restart. 3. Make sure your `.env` has correct API URLs (CONSOLE_API_URL, SERVICE_API_URL, APP_API_URL), `DIFY_BIND_ADDRESS=0.0.0.0`, and that port mappings (EXPOSE_NGINX_PORT, EXPOSE_NGINX_SSL_PORT) match your setup. If you change API URL env vars, rebuild the frontend image. 4. Check Docker resource limits and monitor for OOM kills or high CPU/memory usage. 5. If you use a reverse proxy (Nginx, Traefik), increase proxy timeouts to be higher than your longest workflow save/run. 6. If SSRF proxy is enabled, try disabling it or increasing its timeouts—misconfigured SSRF proxies are a known cause of connection resets [reference](https://github.com/langgenius/dify/issues/12098). 7. Avoid using `localhost` for inter-container communication; use Docker network aliases or the host IP. 8. Make sure no firewall or host network policy is blocking required ports (80, 443, 5001). If you still see the issue, please share the output of `docker-compose ps` and `docker-compose logs api` right after a failed request. This will help pinpoint whether the API is crashing, being killed, or unreachable due to network/proxy issues. Note: The gevent BlockingSwitchOutError you saw in logs is a known concurrency issue in Dify 1.6.0 Docker setups. If you have thread-heavy workloads, switching `SERVER_WORKER_CLASS` from `gevent` to `uvicorn` in your `.env` is the most effective workaround [reference](https://github.com/langgenius/dify/issues/22430). Application-level fixes are unlikely to help until these infrastructure/network issues are ruled out. Dify’s workflow engine is sensitive to Docker resource limits, proxy timeouts, and concurrency model mismatches, so resolving these is key to stable workflow save/run operations [reference](https://github.com/langgenius/dify/issues/21862). <!-- Dosu Comment Footer --> *To reply, just mention [@dosu](https://go.dosu.dev/dosubot).* --- <sup>How did I do? [Good](https://app.dosu.dev/response-feedback/50a95f3f-5218-4b27-bfb5-284c2a876916?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/50a95f3f-5218-4b27-bfb5-284c2a876916?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/50a95f3f-5218-4b27-bfb5-284c2a876916?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/50a95f3f-5218-4b27-bfb5-284c2a876916?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/50a95f3f-5218-4b27-bfb5-284c2a876916?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/50a95f3f-5218-4b27-bfb5-284c2a876916?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/50a95f3f-5218-4b27-bfb5-284c2a876916?feedback_type=other)</sup>&nbsp;&nbsp;[![Chat with Dosu](https://dosu.dev/dosu-chat-badge.svg)](https://app.dosu.dev/6088a4f4-073a-43f3-b3d4-4f06fb0c05a0/ask?utm_source=github)&nbsp;[![Join Discord](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&label=)](https://go.dosu.dev/discord-bot)&nbsp;[![Share on X](https://img.shields.io/badge/X-share-black)](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/langgenius/dify/issues/23381)
yindo commented 2026-02-21 19:23:46 -05:00
Author
Owner
Copy Link
Copy Source

@onestardao commented on GitHub (Aug 13, 2025):

It seems the problem here is #23381, where workflow saving intermittently fails due to transient network or persistence issues. The net::ERR_CONNECTION_RESET error indicates that the backend connection is being dropped mid-request. You may want to check for:

Network reliability or proxy configuration issues

Docker resource constraints (CPU/memory) if self-hosted

Backend request timeout or reverse proxy limits

If you can provide environment details (deployment type, network setup, relevant logs), it will help narrow down the cause.

@onestardao commented on GitHub (Aug 13, 2025): It seems the problem here is #23381, where workflow saving intermittently fails due to transient network or persistence issues. The net::ERR_CONNECTION_RESET error indicates that the backend connection is being dropped mid-request. You may want to check for: Network reliability or proxy configuration issues Docker resource constraints (CPU/memory) if self-hosted Backend request timeout or reverse proxy limits If you can provide environment details (deployment type, network setup, relevant logs), it will help narrow down the cause.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Knowledge Pipeline
Proposal
WIP
cloud
dependencies
feat:webapp
good first issue
outdated
performance
pull-request
Mirrored from GitHub Pull Request
 python:uv
refactor
size:L
stale
status: accepting prs
status: blocked
status: in discussion
stt & tts
vulnerablity
web
wont-fix
🌊 feat:workflow
🌚 invalid
🐞 bug
👻 feat:rag
💪 enhancement
📚 documentation
🔨 feat:tools
🙋‍♂️ question
🙏 help wanted
🤔 cant-reproduce
🤖 feat:agent
No Label 🐞 bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: langgenius/dify#15870
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?