Answered
by
dosubot
Bot
Return to top
Self Checks
1. Is this request related to a challenge you're experiencing? Tell me about your story.I am deploying in an offline docker compose environment, when upgrading the version from dify 1.10.1-fix.1 to 1.15.0, an error occurred, please guide me on how to resolve this? The originally normal workflow doesn't work: 2. Additional context or commentsNo response |
Answered by
dosubot[bot]
Jun 28, 2026
Replies: 2 comments 3 replies
|
This is caused by a security hardening change introduced between 1.10.x and 1.15.0. The SSRF proxy (Squid) now uses a deny-by-default model — only To fix this, add your domain to the SSRF proxy allowlist. Edit the file Add your domain: Then restart the ssrf_proxy service: docker compose restart ssrf_proxyAlternatively, if your target domain resolves to a private/internal IP, you can use the environment variable approach in your Then You can verify the fix by checking the ssrf_proxy logs for any remaining To reply, just mention @dosu. Share context across your team and agents. Try Dosu.
|
3 replies
|
@dosu 
|
|
Glad the domain issue is resolved! For private IP addresses (like Add this to your If you need to allow multiple IPs or a range, you can use comma-separated values with CIDR notation: Then restart the services: docker compose down
docker compose up -dThe entrypoint script converts these values into Squid ACL rules that are evaluated before the default deny rule for private networks [2], so your IP will be allowed through. To reply, just mention @dosu. Share context across your team and agents. Try Dosu.
|
|
Thank you for your guidance. The problem has been perfectly solved |
Answer selected by
yanpx169
|
The nginx Please identify node Useful checks: # find the failing node in exported workflow DSL
grep -n "1780304217677" workflow.yml
# check plugin daemon errors around the execution time
docker compose logs --since "2026-06-28T05:30:00" api worker plugin_daemon | grep -iE "1780304217677|403|forbidden|json_process|plugin" |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This is caused by a security hardening change introduced between 1.10.x and 1.15.0. The SSRF proxy (Squid) now uses a deny-by-default model — only
.marketplace.dify.aiis whitelisted out of the box [1]. Your domainibot.zx.xxx.com.cnis being blocked at the proxy layer before any outbound connection is made, which is exactly what theTCP_DENIED/403lines in your logs confirm.To fix this, add your domain to the SSRF proxy allowlist. Edit the file
docker/ssrf_proxy/squid.conf.templateand find this line:Add your domain:
Then restart the ssrf_proxy service: