Persistent 60s latency in LLM node despite successful host-level cURL tests and SSRF proxy bypass

[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

Hi Dify team, I am struggling with a persistent ~60s delay in the LLM node of my Chatflow. The delay occurs even when bypassing the SSRF proxy and using a simple query without any Context/RAG.

Technical Setup:

Self-hosted Dify (Docker Compose) on Ubuntu.

OpenAI-compatible API provider (fast, ~500ms response time).

Issue: Even with a simple "Hello" prompt, the LLM node hangs for ~60s before generating text.

Troubleshooting performed:

Host/Container reachability: curl tests for the LLM API from the host and from inside the api and worker containers return successful responses in <600ms.

SSRF Proxy: I have set SSRF_PROXY_HTTP_URL and SSRF_PROXY_HTTPS_URL to empty in .env to bypass the proxy entirely. The delay persists.

Internal Logic: The delay happens even when the Knowledge Retrieval node is disconnected from the LLM node.

Embedding Model: I am using an embedding model, but the delay occurs even when performing direct LLM node execution.

My Observations:
The 60s hang is consistent and exactly matches the default network timeout behavior often seen in Python/async environments when resolving IPv6 routes or hitting aggressive internal timeouts.

Questions:

Is there an internal, hard-coded timeout or an asynchronous "health check" logic for LLM API calls in the api/worker code that is not affected by SSRF_PROXY settings?

Why would the LLM node hang when the underlying API is reachable and fast from within the container?

Could this be related to the plugin_daemon or the specific way Dify handles streaming requests for 3rd-party OpenAI-compatible providers?

Any insight into the internal execution path of the LLM node would be appreciated.

[dosubot[bot]]

@sharpdima — This is a well-known pain point in Dify's multi-layered timeout architecture. The critical insight is that setting SSRF_PROXY_HTTP_URL and SSRF_PROXY_HTTPS_URL to empty does bypass the Squid proxy, but it does NOT eliminate all internal timeout layers. Dify has several independent timeout/connection stages, and your ~60s hang likely comes from one of these:

Most likely culprits for a consistent 60s delay:

1. Plugin Daemon communication — LLM calls in a Chatflow go through the plugin daemon (port 5002), not directly from the api container. Even though curl works from inside api/worker, the plugin daemon has its own network path and DNS resolution. A 60s hang strongly suggests a DNS resolution timeout (e.g., IPv6 AAAA lookup timing out before falling back to IPv4) happening inside the plugin daemon container [1].

2. Squid proxy still in the path — Even with empty SSRF_PROXY_* vars, the plugin daemon itself may still route through Squid depending on your docker-compose.yaml networking. Check if the plugin_daemon service has proxy env vars set independently [2].

3. Hardcoded 60s timeouts in extension/SSE code paths — There's a hardcoded 60-second timeout in the APIBasedExtensionRequestor and a 60-second SSE read timeout that are not configurable via .env.

Recommended debugging steps:

1. Test from inside the plugin_daemon container (not just api/worker):

   docker exec -it docker-plugin_daemon-1 sh
   # Then curl your LLM endpoint from here

   If this is slow, the issue is DNS or network at the plugin daemon level.

2. Add DNS nameservers to Squid config — Edit docker/ssrf_proxy/squid.conf.template and add:

   dns_nameservers 8.8.8.8 8.8.4.4
   

3. Increase all timeout layers in your .env:

   SSRF_DEFAULT_TIME_OUT=600
   SSRF_DEFAULT_READ_TIME_OUT=600
   SSRF_DEFAULT_CONNECT_TIME_OUT=30
   PLUGIN_DAEMON_TIMEOUT=600
   PLUGIN_MAX_EXECUTION_TIMEOUT=600

4. Disable IPv6 in Docker if your provider doesn't support it — the exact 60s pattern is a classic IPv6-to-IPv4 fallback timeout. You can add to your docker-compose.yaml for the relevant services:

   sysctls:
     - net.ipv6.conf.all.disable_ipv6=1

To answer your specific questions:

• Yes, the plugin daemon is an independent process with its own HTTP client and timeout stack — it's not affected by your host-level or api container SSRF settings [3].
• The LLM node execution path is: api → plugin_daemon (port 5002) → LLM provider plugin (e.g., langgenius/openai) → your API endpoint. The 60s hang is almost certainly in the last hop as seen from inside the plugin daemon [4].

This matches what was discussed in your earlier thread as well [5].

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.