Self Checks

• I have read the Contributing Guide and Language Policy.
• 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.
• 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's Docker Compose deployment currently routes API, worker, sandbox, and related network features through the bundled Squid-based ssrf_proxy. The intended goal is to make network features work out of the box while reducing SSRF risk.

However, the current Squid configuration includes the Ubuntu Squid image's default /etc/squid/conf.d/*.conf. That packaged configuration allows localnet clients. In Docker Compose, Dify services connect from Docker private-network source addresses, so this effectively allows the proxy clients to reach arbitrary destinations, including loopback, RFC1918 private networks, link-local addresses, and cloud metadata endpoints.

This creates recurring SSRF concerns for community self-hosted deployments. At the same time, switching to a strict domain allowlist would break the expected out-of-the-box behavior for HTTP nodes, remote file ingestion, crawlers, tools, and other user-configured public network calls.

The proposed behavior is:

• Keep public outbound access working by default.
• Block loopback, private, CGN, link-local, ULA, multicast/reserved, and cloud metadata target networks by default.
• Preserve the existing sandbox reverse proxy path.
• Provide explicit opt-in allowlists for trusted private-network deployments that intentionally need private egress.

A draft implementation is available in #36332.

2. Additional context or comments

This proposal should be coordinated with #36397 before #36332 is moved forward.

The hardening in #36332 intentionally blocks private-network targets. That can regress local Docker deployments when a Dify-signed /files/... URL is passed back into Dify as a remote URL, because FILES_URL or INTERNAL_FILES_URL may resolve to localhost, a Docker-internal hostname, or another private address.

#36397 should centralize handling for Dify-owned signed file URLs so they are verified and resolved through an internal file/storage path instead of being treated as arbitrary external remote URLs through the SSRF proxy. After that path is in place, the SSRF proxy hardening can proceed without breaking local signed-file flows.

Related PR: #36332 Blocked by: #36397

3. Can you help us with this feature?

• I am interested in contributing to this feature.