Help:Dify 1.13.3 Failed to add MCP service, SSRF Proxy blocks requests with 403 Forbidden

[jokeryhehe]

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.

When adding a new MCP service in Dify version 1.13.3, a persistent error occurs. Here are the core phenomena and root cause:
Core phenomena: The API service requests the MCP service interface and returns 403 Forbidden, and the MCP authentication interface proxied by Nginx returns 400 Bad Request;
Root cause: Dify's built-in SSRF Proxy security proxy actively intercepts and denies network requests to the internal MCP service (TCP_DENIED/403 in logs), blocking the creation and connection process of the MCP service.

2. Additional context or comments

api-1 | 2026-04-15 08:34:50.674 INFO [ThreadPoolExecutor-2_0] [_client.py:1025] - HTTP Request: POST http://127.1.4.9:80/mcp/server/O3145y9lvnInZom0/mcp "HTTP/1.1 403 Forbidden"
nginx-1 | 10.0.2.105 - - [15/Apr/2026:16:34:50 +0800] "POST /console/api/workspaces/current/tool-provider/mcp/auth HTTP/1.1" 400 313 "http://127.1.4.9:80/tools?category=mcp" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 Safari/537.36" "-"
plugin_daemon-1 | 2026-04-15T08:34:50.739184378Z INFO dify-plugin-daemon middleware.go:83 trace_id=3a520edc70d68259f936c2ef24cefc40 tenant_id=f8a804a2-14e5-4fc2-883e-53862bf41ba5 HTTP request method=GET path=/plugin/f8a804a2-14e5-4fc2-883e-53862bf41ba5/management/tools?page=1&page_size=256 status=200 latency_ms=0 client_ip=172.23.0.9
api-1 | 2026-04-15 08:34:50.739 INFO [Dummy-70] [_client.py:1025] 4970df7c02fe5c59bc0d3699a337c708 - HTTP Request: GET http://plugin_daemon:5002/plugin/f8a804a2-14e5-4fc2-883e-53862bf41ba5/management/tools?page=1&page_size=256 "HTTP/1.1 200 OK"
nginx-1 | 10.0.2.105 - - [15/Apr/2026:16:34:50 +0800] "GET /console/api/workspaces/current/tool-providers HTTP/1.1" 200 4502 "http://127.1.4.9:80/tools?category=mcp" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 Safari/537.36" "-"
ssrf_proxy-1 | 1776242090.674 0 172.23.0.9 TCP_DENIED/403 3460 POST http://127.1.4.9:80/mcp/server/O3145y9lvnInZom0/mcp - HIER_NONE/- text/html
sandbox-1 | [GIN] 2026/04/15 - 16:35:05 | 200 | 31.564µs | ::1 | GET "/health"
worker_beat-1 | 2026-04-15 08:35:34.921 INFO [MainThread] [beat.py:280] - Scheduler: Sending due task trigger_provider_refresh (schedule.trigger_provider_refresh_task.trigger_provider_refresh)
worker_beat-1 | 2026-04-15 08:35:34.938 INFO [MainThread] [beat.py:280] - Scheduler: Sending due task workflow_schedule_task (schedule.workflow_schedule_task.poll_workflow_schedules)
worker-1 | 2026-04-15 08:35:34.940 INFO [MainThread] [strategy.py:161] - Task schedule.workflow_schedule_task.poll_workflow_schedules[1255e880-8ee3-483c-8059-827bca687d71] received
worker_beat-1 | 2026-04-15 08:35:34.941 INFO [MainThread] [beat.py:280] - Scheduler: Sending due task human_input_form_timeout (human_input_form_timeout.check_and_resume)
worker-1 | 2026-04-15 08:35:34.963 INFO [Dummy-42] [trace.py:128] f28e2476df2e55b590e2ed0d607e676d - Task schedule.workflow_schedule_task.poll_workflow_schedules[1255e880-8ee3-493c-3232-83ssssdfs1] succeeded in 0.022334534534532:None

[dosubot[bot]]

This is a known problem — Dify's built-in SSRF proxy (Squid) blocks all private/localhost IP ranges by default, and MCP service requests are routed through this proxy [1]. The TCP_DENIED/403 you see is Squid denying the request to 127.1.4.9 because it falls within the blocked RFC 1122 localhost range defined in the Squid config template.

Here are a few ways to fix this, from least to most invasive:

Option 1: Modify Squid ACLs to allow local networks
Edit docker/ssrf_proxy/squid.conf.template and add http_access allow localnet before the http_access deny all line [2] [3]. The localnet ACL already covers private IP ranges. Then restart the SSRF proxy container.

Option 2: Custom Squid config via the include directory
The Squid config has an include /etc/squid/conf.d/*.conf directive [4]. Create a file like custom-acls.conf:

acl mcp_service dst 127.1.4.9
http_access allow mcp_service

Then mount it in docker-compose.yaml:

ssrf_proxy:
  volumes:
    - ./custom-acls.conf:/etc/squid/conf.d/custom-acls.conf:ro

Option 3: Use Docker service names instead of IPs
If the MCP server URL is configurable on your end, try using the Docker service name (e.g., http://api:5001/mcp/server/O3145y9lvnInZom0/mcp) instead of the IP address. Docker service names resolve within the container network and may avoid the Squid block [5] [6].

⚠️ Options 1 and 2 reduce SSRF protection, so only use them if your environment is trusted. After any changes, restart the SSRF proxy container (docker compose restart ssrf_proxy).

To reply, just mention @dosu.

---

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