ComfyUI Failed to fetch: identify the request before reinstalling

Start with the action that failed

Record the UI action, timestamp, page origin and backend state. The words Failed to fetch alone do not identify a component to reinstall.

Chrome documents request status, initiators and responses in the Network panel; ComfyUI documents its server routes.12 Use them to locate the failure, not to infer a cause from a toast message. Native fetch() rejects on request failures, but an HTTP error status such as 401, 403 or 404 still produces a response; an application can label either situation with a generic failure message.3

Clear old network entries and reproduce one action. Note the host, path, method, status and response type. Review exports before sharing: HAR files and request headers can contain credentials and private content.

Our suggested branches depend on what was requested. With no usable HTTP response, compare the page origin and backend address, then inspect the browser Console for CORS, TLS, mixed-content or request-blocking details before changing a proxy.4 If there is a 401 or 403 response, check that service's authorization context; the HTTP status itself is not a native fetch() rejection. HTML returned to a JSON client suggests inspecting redirects or proxy behavior. Failure to retrieve logs or a node list does not automatically mean generation is unavailable.

Record both request recovery and task recovery. A successful health check is not a successful workflow save. Preserve unsaved work before clearing browser storage or resetting the frontend.

Related checks

• ComfyUI workflow save failed: preserve the canvas before troubleshooting
• Manager cannot load the node list: investigate retrieval before reinstalling nodes
• Integrating ComfyUI into an app: prefer an explicit service boundary

Source and language review: 2026-09-26. No site-run request reproduction, workflow test or GPU test is claimed. The diagnostic branches are editorial guidance, not a confirmed diagnosis.