Failed to fetch 不一定是 ComfyUI 崩了：先找到失败的请求

先记录“什么操作失败”，再记录报错

本文建议先保留按钮或动作、发生时间、页面地址和当时后端是否还在运行。Failed to fetch 本身不足以说明哪个组件需要重装。

Chrome 官方文档介绍了 Network 面板的请求状态、发起者及响应查看；ComfyUI 官方 API 文档则列出了原生服务路由。12 这两个信息源用于定位请求，而不是替某一次故障直接判因。原生 fetch() 对请求失败会拒绝，但收到 401、403、404 等 HTTP 错误状态时仍会得到响应；应用自身也可能把两种情况都显示成笼统的失败提示。3

一次只复现一个动作

打开开发者工具中的“网络（Network）”，清空旧记录后，重做一次失败动作。记录失败请求的主机、路径、方法、状态和响应类型。日志里可能含 Cookie、令牌和提示词，导出或分享前先脱敏，不上传整份未检查的 HAR。

根据对象继续排查

如果没有可用的 HTTP 响应，先比较页面来源和后端地址，再看浏览器 Console 中是否有 CORS、TLS、混合内容或请求被拦截的线索，不要直接改代理。4 若收到 401 或 403，检查作出响应的服务的授权上下文；该 HTTP 状态本身不是原生 fetch() 拒绝。如果 JSON 接口返回 HTML，检查登录跳转或代理路径；若只有日志或节点列表失败，不把它自动扩大为生成后端全部不可用。

检查结果怎样表达

我们的建议是记录“此请求恢复”和“原业务恢复”两项。某个健康检查返回成功，并不能替代工作流保存或任务提交成功。不要先清浏览器全部存储；有未保存工作流时，先保留可导出的副本。

相关排查

• 工作流保存失败：先保住画布，再查保存请求
• Manager 获取节点列表失败：先查目录请求，不急着重装节点
• 把 ComfyUI 接入自己的应用：优先划清服务接口，不直接塞进 main.py

资料与语言审查日期：2026-09-26。本站未复现网络请求、执行工作流或进行 GPU 测试；上述分支是排障建议，并非对具体故障的确认诊断。