What does exactly ssrf-proxy do in the default docker-compose.yaml file?

[sbkkalex]

Hi, I am trying to deploy dify on cloud services, and I am quiet confused with the default settings of ssrf-proxy server.
On the default parameters, even stop the ssrf-proxy server won't bring down the dify service, including python code execute function.

Questions:

1. What does exactly these environment parameters HTTP_PROXY, HTTPS_PROXY in sandbox, and SSRF_PROXY_HTTP_URL, SSRF_PROXY_HTTPS_URL in api do? It seems no effect even when I remove these parameters.
2. About the settings of ssrf_proxy. Do I need to set up an other proxy server and uncomment the cache_peer part to let the ssrf defend work?

################################## Proxy Server ################################
http_port 3128
coredump_dir /var/spool/squid
refresh_pattern ^ftp:		1440	20%	10080
refresh_pattern ^gopher:	1440	0%	1440
refresh_pattern -i (/cgi-bin/|\?) 0	0%	0
refresh_pattern \/(Packages|Sources)(|\.bz2|\.gz|\.xz)$ 0 0% 0 refresh-ims
refresh_pattern \/Release(|\.gpg)$ 0 0% 0 refresh-ims
refresh_pattern \/InRelease$ 0 0% 0 refresh-ims
refresh_pattern \/(Translation-.*)(|\.bz2|\.gz|\.xz)$ 0 0% 0 refresh-ims
refresh_pattern .		0	20%	4320
logfile_rotate 0

# upstream proxy, set to your own upstream proxy IP to avoid SSRF attacks
# cache_peer 172.1.1.1 parent 3128 0 no-query no-digest no-netdb-exchange default 

3. Also about settings of ssrf_proxy. Does this mean in order to use the reverse proxy, I need to change the CODE_EXECUTION_ENDPOINT of api to http://ssrf_proxy:8194 to make this work? Why is this reverse proxy needed here?

################################## Reverse Proxy To Sandbox ################################
http_port 8194 accel vhost
cache_peer sandbox parent 8194 0 no-query originserver
acl all src all
http_access allow all

[patryk20120]

Maybe this will help somehow https://docs.dify.ai/getting-started/install-self-hosted/install-faq#id-16.-why-is-ssrf_proxy-needed

[patryk20120]

There is still default network that docker is using.

[sbkkalex]

In fact I tried stopped the ssrf_proxy container and let the HTTP_PROXY, HTTPS_PROXY in sandbox, and SSRF_PROXY_HTTP_URL, SSRF_PROXY_HTTPS_URL to defaut value: http://ssrf-proxy:3128. And the dify still worked correctly.

In this case I think the http://ssrf-proxy:3128 dose not exist any more, no matter in which network.

[yuichiromukaiyama]

@sbkkalex

In normal usage, requests that violate the ACL are unlikely to occur. In other words, it's obvious that blocking them wouldn't cause any operational issues, isn't it?

https://github.com/langgenius/dify/blob/5986841e276b9af85d86c24e93963f582e7c3397/docker/volumes/ssrf_proxy/squid.conf

[ajaman190]

I am trying to deploy dify on cloud services...

Hello @sbkkalex, which cloud platform you were trying to deploying the Dify? I am also trying to deploy is on GCP but facing some issues.

[sbkkalex]

@ajaman190
I deployed Dify on Azure with azure container apps.

[sbkkalex]

After some digging, I find out what exact ssrf-proxy is used in dify.

It is used mainly in the following situations:

• When using a API-Based Extension (I think this function is now deprecated)
• When a network request start from sandbox (Use requests.get in Python code, for example)
• pip install on the sandbox start if additional library is configured
• Check the installed additional library list of sandbox

So, if you don't use API-Based extension and don't add additional http request library in sandbox, it is safe to delete the ssrf-proxy.

Also, despite a reverse server to sandbox is configured in squid, the default setting does not use the reverse server but connect directly to sandbox.

[xjiaqing]

It seems the correct link is: https://docs.dify.ai/learn-more/faq/install-faq#id-18.-why-is-ssrf_proxy-needed