‌Issue: Workflow Execution Timeout with net::ERR_CONNECTION_CLOSED‌

[xiaokelly]

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.

1. Is this request related to a challenge you're experiencing? Tell me about your story.

Dify version

1.11.2

Cloud or Self Hosted

Self Hosted (Docker)

Steps to reproduce

When running a Dify workflow with long-running nodes, the frontend encounters a net::ERR_CONNECTION_CLOSED error during the POST /console/api/apps/.../workflows/draft/run request. This leads to a TypeError: network error in the browser console.

POST /advanced-chat/workflows/draft/run net::ERR_CONNECTION_CLOSED 200 (OK) w @ 78639-954f132e09b0bd1d.js:1 await in w （匿名） @ page-d58e4dbb14ab6d86.js:1 await in （匿名） （匿名） @ 52965.2d46287f52e86ea3.js:1 （匿名） @ 52965.2d46287f52e86ea3.js:1 （匿名） @ 52965.2d46287f52e86ea3.js:1 onClick @ 52360-8e10f445240de61a.js:1 i8 @ 7b1f872c-c7e4e33c66cbdc9b.js:1 （匿名） @ 7b1f872c-c7e4e33c66cbdc9b.js:1 nz @ 7b1f872c-c7e4e33c66cbdc9b.js:1 sn @ 7b1f872c-c7e4e33c66cbdc9b.js:1 cc @ 7b1f872c-c7e4e33c66cbdc9b.js:1 ci @ 7b1f872c-c7e4e33c66cbdc9b.js:1 workflow:1 Uncaught (in promise) TypeError: network error

I tried to upgrade my dify version from 1.8.0 to 1.11.2, but the issue still persists. I also tried to modify the following parameters, but the problem still hasn't been resolved
proxy_connect_timeout 10m; proxy_send_timeout 10m; proxy_read_timeout 15m;

2. Additional context or comments

No response

[dosubot[bot]]

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

The connection closure during long-running workflow execution is almost always due to a timeout mismatch between the frontend, backend (Gunicorn), and nginx proxy. All these layers must have their timeouts set higher than your longest expected workflow duration, or the connection will drop even if the backend eventually completes the task (source, source, source).

Here’s what you should check and update:

1. Frontend timeout: Set TEXT_GENERATION_TIMEOUT_MS in your .env to a value (in milliseconds) at least as long as your longest workflow. This controls how long the UI waits before showing a timeout error.
2. Backend timeouts: Set WORKFLOW_MAX_EXECUTION_TIME and APP_MAX_EXECUTION_TIME (in seconds, default 1200) and GUNICORN_TIMEOUT (default 200 or 360) to values higher than your workflow duration.
3. Nginx proxy timeouts: Set NGINX_PROXY_READ_TIMEOUT and NGINX_PROXY_SEND_TIMEOUT (e.g., 3600s) in your .env and make sure your nginx config uses these values.
4. Restart everything: After changing these, fully rebuild and restart all containers (including nginx) to apply the new settings.
5. Other infrastructure: If you have any other proxies, load balancers, or network appliances, make sure their timeouts are also set high enough.
6. Logs: If the problem persists, check backend, nginx, and Docker logs at the time of the error to see which layer is closing the connection.

The /workflows/draft/run endpoint streams events but is not truly asynchronous—the HTTP connection stays open until the workflow finishes, so it’s subject to all these timeouts (source, source). If any timeout is too low, you’ll see net::ERR_CONNECTION_CLOSED or similar errors in the browser.

If you need to support especially long workflows, synchronize all these timeout values. If you still see disconnects, check for hardcoded timeouts in plugins or model providers, and monitor resource usage to ensure the backend isn’t being killed or restarted (source, source).

To reply, just mention @dosu.

---

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

   

[xiaokelly]

@dosu
According to the method you provided, I set the frontend timeout, backend timeout, and Nginx timeout to 30 minutes. However, during runtime, the frontend displays as empty, but the backend runs normally and ends. Why is this？

[dosubot[bot]]

The most likely reason the frontend stays empty while the backend completes is a timeout or event handling issue in the frontend or proxy layer. In Dify 1.11.2, there’s a hardcoded frontend HTTP client timeout of 100 seconds in web/service/fetch.ts—even if you set environment variables to 30 minutes, requests longer than 100 seconds will be cut off unless you manually edit this value and rebuild the frontend [details].

Another common cause is the SSRF proxy (Squid) timeout, which defaults to 120 seconds. You need to increase request_timeout and read_timeout in docker/ssrf_proxy/squid.conf.template and rebuild/restart the ssrf_proxy container. Alternatively, set the NO_PROXY environment variable for trusted backend addresses in your Docker Compose config to bypass the proxy for long requests [details].

If the backend finishes but the frontend is blank, check if the frontend is receiving the workflow_finished event in the browser network tab. If not, there may be a bug or race condition in event emission, or a proxy/network issue interrupting the stream [details]. Sometimes, simply refreshing the workflow run page after completion will show the correct output [details].

Also, review session/cache TTLs (SESSION_EXPIRE_HOURS, REDIS_CACHE_TTL, WORKFLOW_NODE_OUTPUT_TTL) and Docker port mapping to ensure the frontend can access backend resources [details].

If you need step-by-step help, let me know which of these you’ve already tried, and I can guide you through checking or changing the relevant config files.

To reply, just mention @dosu.

---

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