RuntimeError: Reached maximum retries for URL https://open.feishu.cn/open-apis/aily/v1/apps/spring_02727bb784__c/skills/skill_69fbd527436e/start

问题场景

在 Dify 自托管环境中，用户在 HTTP 请求节点设置超时时间为 600 秒（含连接、读取、写入超时），但实际请求在约 1 分钟后就被中断，并抛出了类似 RuntimeError: Reached maximum retries for URL https://open.feishu.cn/open-apis/aily/v1/apps/spring_02727bb784__c/skills/skill_69fbd527436e/start 的错误。该问题与节点调用的目标 API 响应时间较长有关。

报错原文

RuntimeError: Reached maximum retries for URL https://open.feishu.cn/open-apis/aily/v1/apps/spring_02727bb784__c/skills/skill_69fbd527436e/start

原因分析

问题根源在于 Squid SSRF 代理的硬编码超时配置。Dify 的所有 HTTP 请求节点调用都会经过这个代理，但代理配置文件中写死了以下超时值：

connect_timeout  30 seconds
request_timeout  2 minutes
read_timeout     2 minutes

这些值没有暴露为环境变量，因此你设置的 HTTP_REQUEST_MAX_* 只作用于 Python httpx 客户端层。Squid 会先于应用层断开连接，返回 502，最终在工作流中表现为超时错误。这是 Dify 配置层面的一个缺口 —— 理想情况下，Squid 超时应支持环境变量替换，但当前版本尚未实现。

环境排查

• 确认 Dify 版本为 1.14.2（或检查当前版本是否已修复此问题）。
• 检查 Docker 部署中的 ssrf_proxy 容器状态和日志，确认是否有 502 或超时记录。
• 核对环境变量设置：HTTP_REQUEST_MAX_CONNECT_TIMEOUT、HTTP_REQUEST_MAX_READ_TIMEOUT、HTTP_REQUEST_MAX_WRITE_TIMEOUT 是否已生效（但请注意这些只影响 Python 层）。
• 同时检查 SSRF_DEFAULT_TIME_OUT、SSRF_DEFAULT_READ_TIME_OUT、SSRF_DEFAULT_WRITE_TIME_OUT 这类 SSRF 客户端超时变量。

解决步骤

1. 在 Docker 宿主机上创建自定义的 squid-common.conf.template 文件，将超时值调整为目标时长，例如：

   request_timeout 10 minutes
   read_timeout    10 minutes

2. 修改 Docker Compose 配置，将自定义模板挂载到 ssrf_proxy 容器中，替换默认的 /etc/squid/squid-common.conf.template。
3. 同步调整 SSRF 客户端的超时环境变量（可优先尝试），确保 Python httpx 层不会先于 Squid 超时：

   SSRF_DEFAULT_TIME_OUT=600
   SSRF_DEFAULT_READ_TIME_OUT=600
   SSRF_DEFAULT_WRITE_TIME_OUT=600

4. 重启 ssrf_proxy 容器，使新配置生效。

验证方法

重新运行之前超时的 HTTP 请求节点，观察请求是否能在超过 1 分钟后继续等待响应，而不是在约 1 分钟时被中断。可以同时查看 ssrf_proxy 容器的日志，确认不再出现 502 或 Squid 超时相关的记录。如果请求最终成功返回，说明问题已解决。

参考来源

langgenius/dify #41011

AI 工具推荐

想把多个 AI 模型放在一个入口？

GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。

了解 GamsGo AI

推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。