LLM Node Hangs / 504 Timeout in RAG Workflow despite successful raw curl tests (OpenAI Compatible Provider)General Discussion

[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 team, I am experiencing a highly frustrating issue with my self-hosted Dify instance (Docker Compose on Ubuntu).
In my Chatflow/Workflow, the Knowledge Retrieval node works perfectly (citations appear instantly), but the LLM node hangs indefinitely (spinning) and eventually throws a red exclamation mark or 504 Gateway Time-out.

I am using a 3rd-party OpenAI-API-compatible provider.

Troubleshooting steps I have already taken (which prove the external API is NOT the issue):

Raw cURL Success: I ran a raw curl request to the exact same API endpoint using the same model (gpt-4.1-mini) directly from the Ubuntu host terminal. It responded perfectly in ~500ms.

Container Network Success: I ran the exact same curl command from inside the Dify api and worker Docker containers. It also worked perfectly and instantly.

Bypassed SSRF Proxy: I added NO_PROXY=localhost,127.0.0.1,api.avalai.ir (my provider's domain) to the .env file and updated the docker-compose.yaml to pass NO_PROXY to the containers.

Payload Reduction: I reduced the Top-K retrieval to 2 and disabled "Thinking Mode" in the model credentials to ensure the payload isn't too large.

The Problem:
Despite the external API being blazing fast and fully reachable from inside the Docker containers, Dify's internal HTTP client hangs when trying to process the LLM node in the workflow.

My Question:
Why is Dify's internal request handling timing out on the LLM node when the API is clearly reachable? Is there a hidden timeout, a bug with the SSRF proxy intercepting the request despite NO_PROXY, or an issue with how context chunks are formatted and sent to OpenAI-compatible endpoints?

Any guidance would be highly appreciated

[dosubot[bot]]

@sharpdima This is a well-documented pain point in Dify's architecture. The key insight is: Dify does NOT use standard NO_PROXY/HTTP_PROXY environment variables for LLM API calls. It uses its own SSRF_PROXY_* variables, so your NO_PROXY setting is being ignored [1].

The root cause is Dify's multi-layered timeout architecture — even if the external API responds in 500ms, the request passes through several independent timeout layers internally, and the defaults are very aggressive [2].

Why Knowledge Retrieval works but LLM node doesn't: They use different code paths and access control mechanisms. The LLM node goes through the plugin daemon architecture with additional timeout layers that Knowledge Retrieval likely doesn't hit [3].

Fix — Option A (recommended): Increase all timeout layers

In your .env file, add:

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

Also edit docker/ssrf_proxy/squid.conf.template and add/modify:

read_timeout 10 minutes
request_timeout 10 minutes
client_lifetime 30 minutes

Then restart all containers.

Fix — Option B: Bypass SSRF proxy entirely for your provider

Set these in your .env:

SSRF_PROXY_HTTP_URL=
SSRF_PROXY_HTTPS_URL=

⚠️ This disables SSRF protection entirely, which reduces security [4].

Fix — Option C: Whitelist your domain in Squid

Add a custom config file in /etc/squid/conf.d/ inside the ssrf_proxy container [5]:

acl custom_allowed dstdomain .avalai.ir
http_access allow custom_allowed

Also check: Make sure DNS resolution works inside the Squid proxy. Docker DNS doesn't automatically propagate to Squid — you may need to add dns_nameservers 8.8.8.8 8.8.4.4 in squid.conf.template [4].

I'd recommend starting with Option A since it preserves security while addressing the timeout issue.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.