Running Dify Behind Corporate Proxy (with SSL Certificate)

[Byn11]

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.

1. Is this request related to a challenge you're experiencing? Tell me about your story.

Hello Dify Team,

I am trying to run Dify in a corporate environment that requires an HTTP/HTTPS proxy with SSL inspection.

I have attempted several solutions found online, including editing docker-compose.yaml and setting proxy-related environment variables, but none of them worked with the current version.

In our environment, the proxy uses a custom/internal CA certificate. It seems that the Docker containers may not trust this certificate, which could be causing the network access issues.

Additionally, I am running Dify using Docker under WSL (Windows Subsystem for Linux).

Could you please advise if there is a recommended or officially supported way to run Dify behind a corporate proxy with custom certificates in the current version?
Any guidance or example configuration would be greatly appreciated.

Thank you very much for your help.

2. Additional context or comments

No response

[dosubot[bot]]

Hi @Byn11! I'm Dosu and I’m helping the dify team.

Running Dify behind a corporate proxy with SSL inspection and a custom CA certificate in Docker/WSL is tricky due to how some components handle certificate trust.

For most Python-based services, you can inject your custom CA by mounting it into the container and setting environment variables like REQUESTS_CA_BUNDLE or SSL_CERT_FILE. For HTTP request nodes, you can try setting HTTP_REQUEST_NODE_SSL_VERIFY=False in your .env file to disable SSL verification, but this is only recommended in trusted environments and may not always work without patching and rebuilding the Docker image. Sometimes, you’ll need to patch api/core/helper/ssrf_proxy.py to ensure the verify parameter is set according to your environment variable, then rebuild and restart the container. More details are in this thread.

The main blocker is the Go-based plugin_daemon. Even if you add your CA to the container’s trust store or build a custom image, the Go app may still ignore it and fail SSL verification behind your proxy. There’s currently no environment variable or documented method to make plugin_daemon trust a custom CA—this is a known limitation in Dify’s current version see discussion.

For Docker/WSL networking, enabling networkingMode=mirrored and autoProxy=true in your .wslconfig and setting your Windows system proxy will let WSL2 and Docker inherit proxy settings automatically. Make sure you’re on the latest Dify version, as recent updates have improved proxy handling in these setups see details.

If you need to use a proxy for SSRF protection, Dify provides a Squid proxy container and related environment variables (SSRF_PROXY_HTTP_URL, SSRF_PROXY_HTTPS_URL) in .env.example. You can point these at your internal proxy and adjust the Squid config as needed.

In summary: Python-based services can be configured to trust your CA with some workarounds, but the Go-based plugin_daemon currently cannot. Disabling SSL verification is possible but risky. Keep Dify updated and monitor for future fixes or official support for custom CA injection in all components.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}