AI nodes timeout after 5m

快速结论：该报错通常发生在 n8n 的 AI 节点调用本地大模型（如 Ollama）时，模型响应耗时接近或超过约 5 分钟，导致请求以 AI nodes timeout after 5m 相关错误中断。优先排查 n8n 与 Ollama 的版本组合、是否多分片并发请求，以及节点请求超时设置。

适用环境：Issue 中已确认的环境包括：n8n 1.68.0、1.103.2、1.104.1；Node.js 18.16；数据库为 SQLite（默认）；执行模式为 main（默认）；操作系统提及 Ubuntu 24.04、Ubuntu 20.04.6 LTS、Alpine Linux 3.22、Windows；本地模型侧涉及 Ollama 0.9.6、0.10.0-rc0（另有用户使用 Docker 运行 n8n 与 Ollama）。

最快修复方案：暂无确认的一步修复方案。Issue 中可优先尝试的做法是：将 n8n 与 Ollama 升级到较新版本后再重试（有用户升级至 n8n 1.103.2 + Ollama 0.9.6 后，单次约 14 分钟的请求成功完成），但该结果未在其他环境中复现。

注意事项：设置 EXECUTIONS_TIMEOUT 仅供尝试，并非 Issue 中确认的通用修复方案，且有用户反馈无效；升级版本后仍有人继续遇到超时，因此升级不能保证解决。多分片工作流会同时挂起多个请求，可能放大超时问题；Ollama 侧日志出现 aborting completion request due to client closing the connection 时，更像是 n8n 主动关闭了连接，需要结合版本与并发情况判断。

问题场景

用户在 n8n 中使用 AI 节点（如 Basic LLM 节点、Ollama 相关节点、OpenAI Chat 节点指向 Ollama 的 Base URL Override）连接本地模型。当模型生成响应较慢，请求等待时间超过约 5 分钟时，n8n 发起 HTTP 请求所用的 fetch 被触发超时，节点执行失败。

该问题更常见于本地模型，但按 Issue 讨论，只要上游服务响应时间超过该阈值，也可能在远端模型上复现。使用网页抓取并总结类的多分片工作流时，多个分片会各自维持连接，超时现象更明显。

报错原文

{
  "name": "HeadersTimeoutError",
  "code": "UND_ERR_HEADERS_TIMEOUT",
  "message": "Headers Timeout Error"
}

部分用户还报告出现：

fetch failed
Headers Timeout Error

Ollama 侧可能记录：

aborting completion request due to client closing the connection

原因分析

最可能的原因是：n8n 内部通过 fetch 向模型提供方发起请求，而该请求存在硬编码的 headers 超时（约 300 秒，即 5 分钟）。当本地模型超过这个时间才开始返回响应头时，请求被判定为超时。

Issue 讨论中提出的可能原因包括：

AI 节点未暴露可配置的请求超时参数，用户无法按本地模型的实际推理时长调整；
Ollama 节点未传递 ollamaOptions，使部分可配置项不可用（讨论中提出将 ollamaOptions 加入节点属性并传给 Ollama，但该改动是否已合入、是否直接解决超时，Issue 中没有明确验证结论）；
多分片工作流会为每个分片建立独立连接，多个慢请求同时处于等待状态，更容易在 5 分钟处被中断；
版本差异可能影响连接保持行为。有用户升级 n8n 与 Ollama 后超时消失，但其他用户升级后仍复现，说明不能把版本问题当作唯一原因。

环境排查

确认 n8n 版本：Issue 中出现 1.68.0、1.103.2、1.104.1，较新版本下仍有人复现。
确认 Ollama 版本：Issue 中提及 0.9.6、0.10.0-rc0；有用户升级 Ollama 后长请求恢复，但未得到一致确认。
确认 n8n 部署方式：Docker 或本地运行，是否设置了 EXECUTIONS_TIMEOUT 等环境变量。
确认操作系统与运行环境：Ubuntu 24.04、Ubuntu 20.04.6 LTS、Alpine Linux 3.22、Windows 均有相关反馈。
确认 Node.js 版本：Issue 中报告为 18.16，但未证明与超时直接相关。
检查 AI 节点类型与连接方式：Basic LLM、Ollama 节点，或 OpenAI 节点配合 Base URL Override 指向 Ollama。
检查工作流是否使用分片/分块处理，多个分片是否并发向模型发起请求。
检查 Ollama 服务日志，确认是否出现客户端关闭连接导致的请求中止记录。
检查 n8n 节点设置中是否有可用的超时、Keep Alive 等参数，以及这些参数在当前版本中是否生效。

解决步骤

先复现并记录超时发生的时间点，确认是否稳定在约 5 分钟后失败，同时保存 n8n 与 Ollama 两侧的日志。
可优先尝试升级 n8n 与 Ollama 到较新版本，再运行一个长耗时请求验证。Issue 中有用户在 n8n 1.103.2 + Ollama 0.9.6 下成功完成约 14 分钟的请求，但其他用户在 1.104.1 + Ollama 0.9.6 / 0.10.0-rc0 下仍复现，因此升级属于可尝试项，不是确定修复。
在 Docker 部署环境中，可尝试设置 EXECUTIONS_TIMEOUT，例如 Issue 中提到的 EXECUTIONS_TIMEOUT=3600。有用户表示对 Ollama 场景有效，也有用户明确反馈无效，需自行验证。
检查工作流是否对长文本做了分片，并为每个分片单独调用 AI 节点。若存在这种情况，可尝试减少并发分片数量或改用串行处理，以降低多个慢请求同时挂起的概率；该做法属于基于讨论的排查方向，Issue 未给出确认结论。
若使用 Ollama 节点，检查当前版本是否提供 ollamaOptions 或类似可配置项，并确认其是否实际传递到 Ollama。Issue 中仅有用户提出修改建议，没有明确说明该方案已合入并验证。
若使用 OpenAI 节点连接本地模型，可确认是否通过 Base URL Override 指向 Ollama，并检查节点本身提供的超时参数是否可调整；Issue 中提到 OpenAI 节点支持超时设置，但未给出具体配置步骤。

验证方法

使用同一个之前会超时的 AI 节点和工作流，向本地模型发送一段预计耗时超过 5 分钟的请求，观察节点是否能持续等待并最终返回模型结果，而不是出现 HeadersTimeoutError、UND_ERR_HEADERS_TIMEOUT 或 fetch failed。同时检查 Ollama 日志，确认请求没有被客户端提前关闭。若多分片工作流仍失败，可先改为单分片或串行调用，分别验证是单个请求超时还是并发连接导致的问题。