Dify 1.6.0 添加MCP报错怎么办？你加白名单了吗？

同样是更新Dify 1.6.0，有的用户在配置MCP时会遇到报错 “Internal Server Error” picture.image

经过排查相关容器的日志，发现该错误可能是由于 ACL 白名单配置问题。

本文将详细介绍该问题的定位过程以及最终的解决方案，希望对正在踩坑的你有所帮助！

查看前端报错

前端实际报错："500 INTERNAL SERVER ERROR" picture.image

查看api容器日志

先查看对应api容器中报错日志："httpx.ProxyError: 403 Forbidden"

# 使用容器名称查看
sudo docker logs dify-api-1

# 或使用容器id查看
# sudo docker logs ad6f044ec981

怎么查找dify的api容器？

sudo docker ps | grep api

找到包含“dify” 和 “api”的容器，就是你的dify的api容器

ad6f044ec981 langgenius/dify-api:1.6.0 "/bin/bash /entrypoi…" 13 hours ago Up 13 hours 5001/tcp dify-api-1

ad6f044ec981：容器id
dify-api-1：容器名称

查看ssrf_proxy容器日志

再查看ssrf_proxy容器中报错日志："TCP_DENIED/403 3831 CONNECT mcp.api-inference.modelscope.net:443"

# 使用容器名称查看
sudo docker logs dify-ssrf_proxy-1

查找容器方式同上

ssrf_proxy 容器日志显示了根本原因：连接魔塔mcp被拒绝

TCP_DENIED/403: 请求被拒绝，状态码为 403 Forbidden。
CONNECT mcp.api-inference.modelscope.net:443: api 服务（IP为 172.17.1.9）尝试连接的地址是魔搭社区（ModelScope）的 API 地址 mcp.api-inference.modelscope.net。

❌问题根源

问题的原因是 Dify 的 api 服务需要访问魔搭社区（ModelScope）来获取某些工具或模型信息，但这个请求被内部的 ssrf_proxy 代理服务拦截并拒绝了。ssrf_proxy 的默认配置中没有将 modelscope.net 列入白名单。

✅解决方案

我们需要修改 ssrf_proxy 的配置文件，将 ModelScope 的域名添加到其访问白名单中。

打开文件dify/docker/ssrf_proxy/squid.conf.template 修改`acl allowed_domains dstdomain .marketplace.dify.ai 为

acl allowed_domains dstdomain .marketplace.dify.ai .modelscope.net

picture.image

这一行配置的作用是定义一个名为 allowed_domains 的访问控制列表（ACL），允许代理访问 dstdomain（目标域名）为 .marketplace.dify.ai 和 .modelscope.net 的所有子域名。

功能解析

定义 ACL 规则组
- acl allowed_domains：创建一个名为 allowed_domains 的 ACL 规则组，用于集中管理允许访问的目标域名。
匹配目标域名
- dstdomain：表示该规则针对的是 目标域名（Destination Domain）。
- .marketplace.dify.ai 和 .modelscope.net：
  - 开头的 . 是通配符，表示匹配 该域名及其所有子域名。例如：
    - marketplace.dify.ai ✅
    - mcp.api-inference.modelscope.net/ ✅
    - dify.ai ❌（不匹配，因为缺少前缀）

重启ssrf_proxy服务

修改完成后，重新启动 Docker 服务

sudo docker restart dify-ssrf_proxy-1

只重启这一个服务，或者重启所有dify服务，都行。

再次添加魔塔的MCP服务，就成功授权了✅ picture.image

报错原因梳理

最后我们再来理一下，前端为什么报500的错？

sequenceDiagram
    participant U as 用户
    participant F as 前端
    participant B as 后端
    participant S as Squid 代理
    participant M as ModelScope

    Note right of U: 用户添加MCP服务

    U->>F: 1.发起请求
    F->>B: 2.转发请求到后端
    B->>S: 3.请求经过Squid代理
    S->>S: 4.执行ACL白名单检查
    alt ✅ACL白名单检查通过
        S->>M: 5a.访问ModelScope（放行）
        M-->>S: 5b.返回响应
        S->>B: 5c.代理放行响应 200
        B->>F: 5d.返回 TCP_TUNNEL/200
        F->>U: 5e.返回200 OK
    else ❌ACL拒绝访问
        S->>F: 6a.返回 TCP_DENIED/403
        F->>U: 6b.返回500 Internal Server Error
    end

🌐 整体架构角色

用户：在前端界面操作，添加 MCP 服务。
前端：接收用户交互，向后端发送 API 请求。
后端（API） ：处理业务逻辑，需调用外部服务 ModelScope。
Squid 代理（ssrf_proxy） ：拦截所有出站请求，执行安全策略（如 ACL 白名单检查）。
ModelScope ：目标第三方服务，提供 MCP 能力。

🔁流程说明：用户发起请求 → 前端 → 后端 → Squid 代理 → ACL检测（阶段1-4）

通过：访问ModelScope → 后端200 → 200（阶段5）
不通过：后端403 → 500（阶段6）

⚠️一句话总结：ssrf_proxy 的默认配置中没有将 modelscope.net 列入白名单。导致的500错误。

同理，如果遇到请求失败，可以将其相关域名添加至白名单中。

实践出真知，与君共勉