dify - 💡(How to fix) Fix MCP server connection fails with 403 — request never leaves Dify (SSRF proxy suspected)

Self Checks

• I have read the Contributing Guide and Language Policy.
• This is only for bug report, if you would like to ask a question, please head to Discussions.
• 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.
• 【中文用户 & Non English User】请使用英语提交，否则会被关闭 ：）
• Please do not modify this template :) and fill in all the required fields.

Dify version

1.14.2

Cloud or Self Hosted

Cloud

Steps to reproduce

I'm hitting a 403 when adding/recreating an MCP (Streamable HTTP / SSE) server connection on Dify Cloud, and I've narrowed it down to something on Dify's side — the outbound request never reaches my server.

Setup

• Environment: Dify Cloud (not self-hosted, so I have no access to the SSRF proxy / squid config).
• MCP server URL: https://dev.trustflow-ai.com/api/mcp/v1
• Transport: Streamable HTTP (SSE), strict — server requires Accept: text/event-stream.
• Auth: static Bearer token (no OAuth, no Dynamic Client Registration).

What happens

• When I add/recreate the MCP connection in Dify, it fails with "403 client forbidden".
• This started after I rotated the Bearer token on the server. The old connection in Dify worked fine until then; recreating it with the new token fails.

What I've verified (server is healthy)

• Direct curl with the new token returns HTTP/2 200, content-type: text/event-stream: curl -i https://dev.trustflow-ai.com/api/mcp/v1 -H "Authorization: Bearer <token>" -H "Accept: text/event-stream"
• Without the token, the server correctly returns 401 (mcpAuthRejected:missing_bearer); with a wrong Accept header it returns 406 (must accept text/event-stream). So auth and transport are correct.
• The same server connects successfully from Mistral Studio (re-setup with the new token worked immediately) and from MCP Inspector.

Key diagnostic

• I checked the logs on my server side (Cloudflare + Heroku). When Dify fails with the 403, NO request arrives at my server at all. This means the request never leaves Dify — the 403 is generated internally, before any real outbound connection.
• This strongly points to the Dify Cloud SSRF / egress proxy rejecting the URL upstream (similar to GitHub issues #23024 and #25162: ProxyError 403 raised at the proxy layer, while the MCP server itself responds fine to other clients).

What I need

• Could you whitelist / allow outbound connections to dev.trustflow-ai.com in the Dify Cloud SSRF proxy, or tell me which rule is blocking the egress?
• Since I'm on Cloud, I can't edit squid.conf or restart the ssrf_proxy container, which is the documented workaround for self-hosted.

Reference request IDs (from my server, for the successful direct calls / failed Dify attempts):

• x-request-id: 2571ba03-0abf-44a8-b2f1-bf5e58be1c00 (direct 200)
• (I can provide the Dify-side request ID / timestamp of the 403 if you tell me where to find it.)

Happy to provide any additional logs. Thanks for your help.

✔️ Expected Behavior

able to reconnect my MCP

❌ Actual Behavior

I'm hitting a 403 when adding/recreating an MCP (Streamable HTTP / SSE) server connection on Dify Cloud, and I've narrowed it down to something on Dify's side — the outbound request never reaches my server.