当api返回429且x-ratelimit-remaining为0或retry-after存在时，需配置指数退避：http节点启用最大2次重试（延迟1s、2s），或用代码节点读取retry-after动态休眠；同步设置连接/读取超时分别为2s/3s，并为每个路由分配≥20连接。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
当扣子工作流调用外部API频繁返回429状态码、X-RateLimit-Remaining为0或Retry-After头存在时，说明请求已被平台主动限频，必须配置退避算法而非简单重试，否则会加剧失败率。
识别限频是否真实触发
打开最近一次失败的HTTP节点运行日志→点击「详情」→在错误信息中搜索【429】或【Too Many Requests】；若命中，再检查响应头字段：X-RateLimit-Remaining值为0且X-RateLimit-Reset时间戳晚于当前时间，即确认限频已生效。
若X-RateLimit-Remaining仍大于0，问题大概率出在鉴权失效、参数格式错误或DNS解析异常，此时不应启用退避，而应先修复凭证或请求体。
在HTTP节点内启用原生指数退避
方法一：适合低复杂度场景，无需额外节点
进入HTTP节点编辑页→展开「高级设置」→勾选「启用重试」→设置最大重试次数为【2】；首次重试延迟设为1秒，第二次延迟设为2秒；仅对状态码429和503触发重试，其他错误类型不参与该退避路径。
注意：不要将最大重试次数设为3以上，否则单次请求总耗时可能突破8秒，用户端感知明显卡顿，且平台可能已在此期间重置配额窗口。
用代码节点实现自定义退避逻辑
方法二：推荐用于生产环境，支持读取Retry-After头并动态调整等待时间
第一步：在HTTP节点后接一个「代码节点」，输入以下Python逻辑：
import time, random
retry_count = input.get("retry_count", 0)
if retry_count == 0:
wait_time = 1
elif retry_count == 1:
wait_time = 2
else:
wait_time = 4
headers = input.get("response_headers", {})
retry_after = headers.get("Retry-After")
if retry_after and retry_after.isdigit():
wait_time = max(wait_time, int(retry_after))
time.sleep(wait_time)
return {"retry": True, "retry_count": retry_count + 1}
第二步：将该代码节点的【错误分支】回连至原HTTP节点输入端，形成闭环；【漏掉return {"retry": False}会导致流程永远不终止】
第三步：在HTTP节点自身设置「最大重试次数=2」，与代码节点协同控制总重试上限，防止无限循环。
配合连接池与超时参数防雪崩
单纯退避不能解决底层连接资源耗尽问题。必须同步优化HTTP客户端行为：
① 连接超时强制设为【2000毫秒】：DNS解析+TCP握手超2秒即判定链路异常，避免线程卡死；
② 套接字读取超时设为【3000毫秒】：扣子API正常响应集中在600–1200ms，设3秒可覆盖边缘延迟，又不至于拖垮整条流水线；
③ 每个路由（如api.coze.com）单独分配至少20个连接，最大总连接数不低于50——高并发下若复用率低，频繁建连会直接触发TCP连接耗尽，报错显示为connection reset而非429。
