POST /prompt 返回 400：先读 error，再看 node_errors

现象与适用范围

原生 ComfyUI API 拒绝提交工作流。HTTP 400 只说明这次请求不符合要求，具体原因应从 error 与 node_errors 中提取，不能一律当成网络不稳定重试。

检索用原文或片段（具体编号、数值和文件名随环境变化）：

prompt_outputs_failed_validation
node_errors
HTTP 400

已核对的依据

官方路由说明 /prompt 会先校验，成功才返回 prompt_id 与队列信息。固定版本的路由在校验 400 时返回顶层 error 和 node_errors，但缺少顶层 prompt 时节点错误表为空；核心校验在缺技术类或输出节点时也可返回空表。先读 error.type 与详情，有节点级 reasons 时再逐项处理。路由 服务端 校验

需要区分的情况

1. 请求体不是正确的 API 工作流结构，或顶层 prompt 包装错误。

2. 节点缺失、模型选项不存在、输入连线/数值不合法，尚未进入模型运算。

3. 请求被代理或其他服务拒绝，返回的其实不是 ComfyUI JSON。

建议的操作顺序

以下顺序是基于上述资料整理的诊断方案，不代表上游已经为你的环境确认了原因。

第 1 步。 保存 HTTP 状态、Content-Type 和经过脱敏的 JSON 响应，先确认回答来自目标服务。

第 2 步。 用原生 UI 导出的最小 API 工作流提交，排除自己构造图的转换问题。

第 3 步。 先读取顶层 error.type、message 和 details；若 node_errors 中有带 errors 数组的节点，再按错误类型逐项处理。node_errors 为空不表示这次 400 请求通过校验。

第 4 步。 校验成功后才开始等待执行事件；对不可重试的输入错误直接反馈给调用者，避免无限重试占用队列。

如何判断处理有效

获得有效 prompt_id，并能在对应队列或历史中追踪这次任务。最终成功仍需后续执行结果确认。

注意事项与尚未确认的部分

历史中的 traceback、提示词和文件路径可能含隐私。公开日志应脱敏，接口重试不能默默重复有成本的任务。

资料与代码复核日期：2026-09-26。本站未提交 API 请求，未进行 GPU、最低显存或耗时测试。

原始资料

• D09 · ComfyUI Server API routes。核对：2026-09-26。
• ComfyUI v0.37.0 prompt route。核对：2026-09-26。
• C01 · ComfyUI v0.37.0 prompt validation。核对：2026-09-26。

相关排查与操作

• Node has no class_type：区分错误导出与真正缺少节点
• Value not in list：模型已经下载，为什么下拉框仍找不到
• Required input is missing：定位缺失输入，而不是反复点运行