问题复现：当 n8n 工作流突然“卡死”
作为 N8N大学 的首席主编，我见过太多这样的场景：你精心搭建的自动化流程跑得好好的，突然有一天，某个 HTTP 节点开始报错。
控制台里最刺眼的莫过于那行红色的错误信息：**`Error: Gateway Time-out`** 或者 **`Error: connect ETIMEDOUT`**。这通常发生在 n8n 尝试连接外部 API、拉取数据或通过 Webhook 发送请求时。
这种超时不是 n8n 程序本身的 bug，而是 n8n 在“询问”外部服务时，对方没有在规定时间内给出回应。这就像你打电话给朋友，拨通了却一直没人接，最后只能挂断。
原因分析：为什么 n8n 连不上？
用大白话讲，n8n API 超时通常由三个核心因素导致：**网络不通**、**防火墙拦截**、**请求/响应超时设置不合理**。
首先，**网络连通性**是基础。如果你的 n8n 运行在 Docker 容器内，而目标 API 在公网，容器网络是否配置正确？DNS 解析是否正常？这些都是隐形杀手。
其次，**防火墙与安全组**。云服务器（如 AWS、阿里云）通常有严格的入站和出站规则。如果目标 API 的端口被云厂商的防火墙，或者目标服务器自身的防火墙（如 UFW、iptables）屏蔽，连接自然会超时。
最后，**超时设置**。n8n 的 HTTP Request 节点默认超时时间通常较短（默认为 3000ms 或 10000ms，视版本和配置而定）。如果目标 API 处理逻辑复杂、响应慢，或者网络延迟高，默认时间根本来不及。
解决方案：三步排查法实战记录
面对超时，不要盲目重启 n8n。笔者建议按照从易到难的顺序，按以下步骤进行排查。
第一步：基础网络连通性测试
在动手修改 n8n 配置前，先确认你的 n8n 服务器到底能不能“看见”目标 API。
假设你的 n8n 部署在 Docker 中，首先进入容器内部：
docker exec -it n8n bash
在容器内执行以下命令（以 `api.example.com` 为例）：
- DNS 解析测试：
nslookup api.example.com或ping api.example.com。如果连 IP 都解析不出来，检查容器的 DNS 配置（通常是 `/etc/resolv.conf`）。 - 端口连通测试： 使用 `curl` 或 `telnet`。例如测试 443 端口：
curl -v https://api.example.com。如果卡在 `Connected to ...`，说明端口不通或被墙。
如果这一步就失败了，问题不在 n8n，而在网络基础设施。
第二步：检查防火墙与代理设置
网络通但依然超时？大概率是防火墙在捣乱。
1. 云服务器安全组： 登录你的云控制台，检查安全组规则。出站规则（Egress） 必须允许访问目标 API 的端口（通常是 80 或 443）。很多新手只设置了入站，忽略了出站限制。
2. 容器网络隔离： 如果使用 Docker，确保 n8n 容器运行在 `bridge` 或 `host` 模式下。如果使用了自定义网络，确保网络与外部是互通的。
3. 系统防火墙： 在宿主机上执行 ufw status 或 iptables -L，确认没有阻止 Docker 的流量转发。
4. 代理问题： 如果你在 n8n 中配置了全局代理（HTTP_PROXY/HTTPS_PROXY），请确认代理服务器本身是否存活。一个失效的代理节点会导致所有请求挂起。
第三步：调整 n8n 超时参数（硬核操作）
如果网络和防火墙都没问题，那么目标 API 确实响应较慢，我们需要给 n8n 更多的“耐心”。
n8n 的 HTTP Request 节点默认有超时限制。如果目标 API 响应时间超过 30 秒，你需要手动调整。
方法 A：在 HTTP Request 节点中调整（推荐）
在你的工作流中，点击报错的 HTTP Request 节点，在参数设置中找到 Timeout 选项。默认可能是空的（使用默认值），你需要手动填写一个更大的值，单位是毫秒（ms）。
- 例如，如果你期望 API 在 60 秒内响应，输入
60000。 - 如果 API 非常慢，甚至可以设置为
120000（2分钟）。
方法 B：修改 n8n 环境变量（全局生效）
如果你是通过 Docker 或 PM2 部署的 n8n，可以通过环境变量调整 n8n 底层的 HTTP 客户端超时时间。
在 docker-compose.yml 或启动命令中添加：
N8N_HTTP_TIMEOUT=120000
这将把 n8n 所有内部 HTTP 请求的默认超时时间设置为 120 秒。修改后记得重启 n8n 服务。
避坑指南：实战中的“血泪”总结
在 N8N大学 的实战案例中，有两个细节经常被忽略，导致超时问题反复出现：
1. IPv6 的陷阱： 某些云服务器的 IPv6 网络配置不完整，但 DNS 解析优先返回了 IPv6 地址。这会导致连接尝试失败并超时。如果你的 n8n 不需要 IPv6，可以在 Docker 启动命令中禁用它，或者在 /etc/gai.conf 中调整优先级。
2. 目标 API 的限流： 有时候超时不是因为慢，而是因为请求太频繁被目标 API 拒绝了（虽然通常会返回 429，但也有些 API 直接丢弃包导致超时）。如果你正在做爬虫或高频轮询，务必在 HTTP Request 节点前加入 Wait 节点进行限流。
3. 大数据量处理： 如果 API 返回的数据量极大（例如几十 MB 的 JSON），n8n 在解析时可能会消耗大量 CPU，导致处理超时。此时建议开启 HTTP Request 节点的 **"Response as File"** 选项，以流式方式处理大文件。
FAQ：关于 n8n API 超时的常见问题
Q1：为什么我的 n8n 在本地运行正常，部署到服务器就超时？
A：这通常是云服务器安全组（防火墙）配置导致的。检查服务器的出站规则是否允许访问目标 API。另外，本地网络环境通常比云服务器更宽松。
Q2：n8n 的 HTTP Request 节点最大支持多少秒的超时？
A：技术上没有硬性上限，但建议不要设置得过长（如超过 5 分钟）。如果 API 需要这么长时间，强烈建议改用异步轮询或 Webhook 回调机制，而不是让工作流一直挂起等待。
Q3：如何判断是网络问题还是 API 服务端的问题？
A：使用 curl 命令在 n8n 服务器上直接请求 API。如果 curl 也超时，就是网络/服务器问题；如果 curl 秒回但 n8n 报错，检查 n8n 的代理配置或节点参数。
总结与资源
排查 n8n API 超时，本质上是一次网络全链路诊断。记住我们的口号：**先通网，再调参**。
大多数情况下，调整 HTTP Request 节点的 Timeout 参数就能解决 80% 的问题。剩下的 20%，则需要你细心检查防火墙和网络路由。
如果你在排查过程中遇到了具体的报错代码，欢迎前往 N8N大学 (n8ndx.com) 的社区板块发帖，我们有超过 8 年经验的工程师会为你提供一对一的诊断。
