Toonflow 接入模型供应商一直报 502，该先改客户端配置、网关超时还是查供应商限流？

Toonflow 里出现 502，基本可以判定为请求已经过了某一层网关，但那一层没从上游模型供应商拿到有效响应，问题出在接入链路而不是 Toonflow 本身。这个判断成立的条件是：界面能打开、登录正常、素材库和项目列表能加载，只有生成或对话动作报 502；如果整个页面打不开或登录就失败，那是前端部署或账号问题，不在本文讨论范围。 502 不属于模型供应商原生的业务错误码，所以拿着它去换模型通常无效。OpenAI 兼容接口在业务层的返回一般是 400、401、403、404、429、500、503，而 502 Bad Gateway 主要来自反向代理、CDN 或 API 中转这一层。先数清请求链路上有几层转发，比反复更换供应商有价值得多。 排查顺序应当是客户端配置、网关、供应商三段，从前往后逐段排查。先看 base URL 是否多写或少写了 /v1、结尾是否多了一个斜杠、Key 复制时有没有带上换行或首尾空格；再看网关的错误日志；最后才怀疑上游服务。在 Toonflow 里把地址补成 /v1/v1 或 Key 里混入不可见字符，这类“配置写错、被网关统一判成 502”的情况占比不低。 短提示词能出结果、长提示词必定 502，这是最典型的网关读超时。多数反向代理默认的读取超时是 60 秒，而 Toonflow 提交分镜脚本、整段剧情续写这类任务时，非流式请求很容易超过这个阈值，网关等不到首字节就直接断开。处理方式二选一：在 Toonflow 侧把请求切换成流式输出，或者把网关的读取超时调到 300 秒以上。 自建 Nginx 做反向代理的场景，要同时改三处，否则只调超时仍然会失败。开启 HTTP/1.1 并清空 Connection 头，否则长连接会被降级；关闭 proxy_buffering，否则 SSE 流式内容会卡在缓冲区；补上 proxy_read_timeout 与 proxy_send_timeout。另外别忘转发 Host 头，部分供应商按域名做路由，Host 不对会直接返回错误页，再由代理包装成 502。 带参考图或角色设定的任务要额外关注请求体积，这是 Toonflow 类工具比纯文本对话更容易遇到的问题。图片转成 base64 塞进 JSON 后，单个请求体可能膨胀到几 MB 甚至几十 MB，一旦超过网关的 client_max_body_size 或 CDN 的上传限制，浏览器侧看到的往往就是 502 或 413。做法是调大该限制，或者改用图片 URL 传参而不是内联 base64。 用 curl 绕过 Toonflow 直连一次，是整条排查链上性价比最高的分界点。用完全相同的 base URL、同一个 Key、同一个模型名，发一个不带图片的最大请求体：命令行能通说明问题在 Toonflow 的请求构造或中间的代理配置；命令行同样 502，说明故障在网关到供应商那一段。测试时务必用最小请求体，否则会同时引入体积因素。 拿到 502 后不要只看状态码，响应头和响应体里的信息量更大。响应头出现 cf-ray 说明请求到了 CDN 层，出现 nginx 或 openresty 说明是自建网关，带 request id 的直接拿这个 id 找供应商查上游日志，通常几分钟就能定位。响应体如果是 HTML 而不是 JSON，说明请求根本没到达模型接口，而是在代理层就被拦下了。 多个 Key 轮询或并发较高的场景，502 有可能只是限流的另一种表现形式。供应商侧某个 Key 额度耗尽、并发超过套餐上限时返回 429 或 503，部分中转层为了统一格式会把它包装成 502。把 Toonflow 的并发降到 1、逐个 Key 单独测试，成功率立刻恢复的就是限流问题，与网络和配置无关。 模型名与任务类型不匹配也会伪装成 502，这一点在同时使用文本和视觉模型的工具里最容易被忽略。把视觉模型当作文本模型调用、传入供应商不支持的 tools 或 response_format、上下文长度超过模型上限，上游返回的是 400 或 422，但部分网关的异常处理会把非预期响应统一转成 502。核对供应商文档里的准确模型 ID，去掉用不上的可选参数，就能排除这一类。 部署在境内、供应商在境外时，TLS 握手阶段被中断同样会呈现 502，特征是时好时坏而不是稳定失败。判断依据是同一请求重试几次能通过、成功率随时间段波动、错误日志里出现握手超时或连接重置。这种情况换模型没有意义，要么就近接入，要么让请求走一条国内可达的中转链路。 把 502 变成可恢复错误，比追求一次都不出现更现实。Toonflow 侧配置一个备用供应商做故障转移，对幂等请求做 2 到 3 次有限重试，把超长的生成任务拆成多段小请求分次提交，这三件事能把 502 的实际影响压到很低。重试次数必须设上限，否则在上游持续异常时会成倍放大调用量，账单也一起翻倍。