How to increase LLM API connection timeout (DeepSeek) in Docker deployment?

[sharpdima]

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

Hello Dify Team,

We are currently self-hosting Dify via Docker and utilizing the DeepSeek-Chat model for our workflows. Recently, we've been experiencing intermittent timeout issues due to high traffic on the provider's end. The system throws the following error:

Run failed: [models] Server Unavailable Error, HTTPSConnectionPool(host='api.deepseek.com', port=443): Max retries exceeded with url: /chat/completions (Caused by ConnectTimeoutError(<HTTPSConnection(host='api.deepseek.com', ... at port="443)">, 'Connection to api.deepseek.com timed out. (connect timeout=10)'))

I noticed the default connection timeout is set to 10 seconds. I would like to increase this to allow more time for the initial handshake, but I couldn't find specific variables like HTTP_REQUEST_NODE_TIMEOUT or CLIENT_API_TIMEOUT in the default .env template.

Could you please clarify:

What is the exact environment variable I need to add/modify in the .env file to override this 10-second timeout for LLM API connections?

What optimal value do you recommend setting it to for achieving the best stability without causing system hang-ups?

Thank you in advance for your support.

Best regards

[dosubot[bot]]

The 10-second connect timeout you're hitting is controlled by the DIFY_AGENT_PLUGIN_DAEMON_CONNECT_TIMEOUT environment variable, which defaults to 10.0 seconds [1]. In Dify's current architecture, LLM provider API calls (including DeepSeek) are routed through the plugin daemon's HTTP client [2].

To increase it, add/modify this in the environment configuration for your dify-agent service (e.g., in your docker-compose.yaml or .env file):

DIFY_AGENT_PLUGIN_DAEMON_CONNECT_TIMEOUT=30

There are also related timeout variables you may want to adjust:

Variable	Default	Purpose
DIFY_AGENT_PLUGIN_DAEMON_CONNECT_TIMEOUT	10.0	TCP connection establishment timeout
DIFY_AGENT_PLUGIN_DAEMON_READ_TIMEOUT	600.0	Waiting for response data (already generous)
DIFY_AGENT_PLUGIN_DAEMON_WRITE_TIMEOUT	30.0	Sending request data
DIFY_AGENT_PLUGIN_DAEMON_POOL_TIMEOUT	10.0	Waiting for a free connection from the pool

[3]

Recommended value: Setting DIFY_AGENT_PLUGIN_DAEMON_CONNECT_TIMEOUT to 30 seconds should give enough headroom for DeepSeek's intermittent slowness without risking system hang-ups. You could also bump DIFY_AGENT_PLUGIN_DAEMON_POOL_TIMEOUT to 30 if you're seeing pool exhaustion under load. Going much higher than 60 seconds for a connect timeout is generally not advisable — if a connection can't be established in that time, the endpoint is likely truly unreachable.

Note: These variables configure the connection between the Dify Agent Server and the plugin daemon. The actual timeout for the outbound call to api.deepseek.com may also be configured within the DeepSeek plugin itself. If adjusting the above doesn't resolve the issue, you may need to check if the plugin has its own timeout settings.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[richardchen874-sys]

This is a very relevant issue for self-hosted Dify + DeepSeek workflows.

Increasing the connection timeout may help with slow handshakes, but if the timeout is caused by provider-side traffic or intermittent API availability, a longer timeout alone may not fully solve it. It can also make workflow runs hang longer under load.

For production usage, I’d usually look at three layers:

1. Increase the LLM request/connect timeout if Dify exposes the setting.
2. Add retry/backoff for transient DeepSeek API failures.
3. Add a fallback model/provider path so workflows don’t fail completely when one endpoint is slow or unavailable.

Curious — are you seeing this mostly during high-traffic periods, or does it happen even with low request volume?