ComfyUI "Failed to Fetch"：先判斷是哪條連線失敗
ComfyUI 顯示 Failed to Fetch 只代表瀏覽器沒有收到可用回應。修改安裝前，先區分失敗來自後端、Manager、Registry、WebSocket、工作流草稿還是代理。
Failed to fetch 本身不能說明 ComfyUI 的真正問題。
它只表示瀏覽器發出了請求，但沒有收到可用回應。失敗請求可能屬於 ComfyUI 本體、ComfyUI Manager、ComfyRegistry、工作流草稿儲存、server logs 或 WebSocket 連線。
不要立刻重裝 ComfyUI。
先判斷 介面原本想 fetch 的是什麼。
30 秒檢查
使用 ComfyUI 啟動日誌裡顯示的地址。預設本地安裝通常是 http://127.0.0.1:8188。先確認後端仍在運行，再在新分頁打開同一個地址，然後根據觸發 Failed to fetch 的操作選擇對應分支。
先選對分支
| 失敗的是什麼 | 最可能的層級 | 下一步 |
|---|---|---|
| 整個 ComfyUI 頁面都不回應 | 後端停止，或地址變了 | 先確認後端是否還活著 |
| 只有 server logs 無法載入 | server-log API、前後端版本不匹配，或本地請求被攔截 | Failed to Fetch Server Logs |
| Manager 無法載入 custom-node list | Manager、Registry、GitHub、快取、代理或 DNS | Failed to Get Custom Node List |
頁面反覆顯示 Reconnecting... | WebSocket 或後端連線 | ComfyUI Reconnecting Error |
| 工作流草稿儲存失敗 | draft-save 請求或後端連線 | Failed to Save Workflow Draft |
| 只在 VPN、代理、隧道或公司網路下失敗 | 請求被攔截或 endpoint 被阻斷 | 看下面的代理和防火牆分支 |
| ComfyUI Desktop 能打開，但 UI 連不上後端 | Desktop 管理的後端或端口不一致 | 看下面的 Desktop 分支 |
先確認後端是否還活著
查看啟動 ComfyUI 的終端、PowerShell、命令列窗口、launcher 日誌或 Desktop 日誌。
健康的後端通常會繼續運行，並顯示前端應該訪問的地址。
例如：
To see the GUI go to: http://127.0.0.1:8188使用 你自己日誌裡的 host 和 port。不要假設所有安裝都使用 8188 端口。
後端可能還在運行，如果
- 終端沒有關閉。
- 日誌末尾沒有 traceback。
- 打開日誌裡的地址可以載入 ComfyUI。
- Queue 和 History 請求仍然正常。
- 只有一個 Manager 或前端功能失敗。
這種情況下，問題通常局限在某個請求、瀏覽器路徑、網路層或擴展。
後端可能已經停止，如果
- 終端關閉了。
- fetch error 之前出現了 Python traceback。
- 原來的地址打不開。
- 介面所有部分同時失敗。
- 重啟後使用了不同端口。
瀏覽器裡的 Failed to fetch 不能解釋後端為什麼停止。請讀取最後的終端錯誤；如果服務器無法啟動，用 ComfyUI Startup Failed 排查。
如果只有 server logs 無法載入
如果 ComfyUI 主介面還能用，但 server-log 面板顯示 Failed to fetch，不要把它當作完整的 ComfyUI 崩潰。
失敗可能僅限於：
- server-log endpoint；
- 前端和後端版本不匹配；
- 過期的瀏覽器 bundle；
- 沒有轉發該 endpoint 的反向代理；
- Desktop 或打包環境使用了不同的後端 route。
繼續看 ComfyUI "Failed to Fetch Server Logs"。這個父頁只負責分流，不重複 endpoint 專項步驟。
如果 Manager 無法載入 custom-node list
Manager 失敗不等於 ComfyUI 本體壞了。
ComfyUI Manager 可能需要訪問：
- ComfyRegistry；
- GitHub；
- raw GitHub content；
- 快取的 node list；
- Manager 專用 API endpoints。
先檢查普通 ComfyUI 生成是否仍然正常。
如果只有 Manager 顯示：
Failed to get custom node list或：
Failed to find the following ComfyRegistry list繼續看 ComfyUI-Manager "Failed to Get Custom Node List"。
在確認 Manager 請求前，不要重裝所有 custom nodes。
如果介面一直 Reconnecting
Reconnecting 通常表示前端失去了與 ComfyUI 後端的即時連線。
這和一個可選 Manager 請求失敗不是一回事。
可能的層級包括：
- ComfyUI 進程停止；
- 後端正在重啟；
- WebSocket 連線被阻止；
- 反向代理沒有轉發 WebSocket 流量；
- 瀏覽器仍在使用舊端口；
- 電腦休眠或網路變化。
繼續看 ComfyUI Reconnecting Error。
如果頁面能重新連線且生成仍然正常，不要做完整依賴重裝。
如果儲存工作流草稿失敗
工作流草稿失敗更緊急，因為目前 graph 可能只存在於打開的瀏覽器分頁裡。
最安全的第一步是：重新整理或關閉分頁前，先使用目前可用的 Save 或 Export 選項。
這個錯誤表示自動 draft-save 請求失敗了，不一定表示工作流已經消失。
在儲存或匯出前，避免：
- 重新整理頁面；
- 關閉瀏覽器分頁；
- 清除瀏覽器站點資料；
- 未儲存可見 graph 就重啟 ComfyUI。
繼續看 ComfyUI "Failed to Save Workflow Draft"。
如果只是普通工作流備份和恢復，而不是正在出錯，暫時使用同一頁面裡的工作流儲存章節。
如果涉及 VPN、代理、防火牆或公司網路
某個請求可能能到達 ComfyUI 主頁面，但另一個 endpoint 被阻斷。
常見場景：
- 透過反向代理訪問 ComfyUI；
- 瀏覽器代理擴展已開啟；
- VPN 改變了本地路由；
- 安全軟體過濾 localhost 流量；
- 公司網路阻斷 GitHub 或 Registry 請求；
- HTTP 和 HTTPS 混用；
- WebSocket 轉發缺失。
不要第一步就停用所有安全控制。
先比較：
- 暫時繞過 VPN 或代理後的同一操作。
- ComfyUI 主頁面和具體失敗功能。
- 本地訪問和反向代理訪問。
- 普通瀏覽器窗口和無擴展的隱私窗口。
如果只在繞過某個網路層後恢復，請檢查該層規則，而不是修改 ComfyUI Python 環境。
如果你使用 ComfyUI Desktop
ComfyUI Desktop 管理啟動環境的方式不同於 manual 或 Portable 安裝。
不要假設：
- 後端一定使用預設端口；
- Python 環境等同於系統 Python；
- Portable 修復命令適用於 Desktop；
- 重啟後瀏覽器地址保持不變。
在 Desktop app 或日誌裡確認：
- 目前 backend address；
- startup failure messages；
- frontend/backend version information；
- backend 是否重啟；
- extension loading errors。
Desktop 管理路徑和恢復操作可能隨版本變化。套用 manual 或 Portable 命令前，請先查看目前 app UI 或官方 Desktop 文檔。
用瀏覽器開發者工具定位失敗請求
如果提示仍然太模糊，瀏覽器可以顯示具體失敗的請求。
在 Chromium 系瀏覽器中：
- 打開 Developer Tools。
- 選擇 Network。
- 重複觸發
Failed to fetch的操作。 - 找到失敗的 request。
- 記錄 request name、URL、status 和 error。
| 你看到的內容 | 可能說明 |
|---|---|
| 請求指向 Manager 或 Registry route | Manager 或外部服務問題 |
| 請求指向 server logs | server-log endpoint 問題 |
| WebSocket connection 關閉 | 後端或代理連線問題 |
| 請求使用了錯誤端口 | 前端地址過期或後端重啟 |
| request 被 client blocked | 瀏覽器擴展或過濾軟體 |
| connection refused | 該地址沒有 backend 在 listening |
| 主頁面可用但某個 endpoint 報錯 | 特定功能的後端失敗 |
分享 Network 面板截圖時，不要公開 cookies、authorization headers、私有 workflow data、本地使用者名稱或 API keys。
不要先做這些
避免把這些當萬能修復：
- 重裝 ComfyUI；
- 刪除所有 custom nodes；
- 升級所有 Python packages；
- 在系統 Python 裡運行
pip install； - 匯出 workflow 前清除瀏覽器資料；
- 永久關閉防火牆；
- 因為一個 HTTP 請求失敗就改 CUDA 或 PyTorch；
- 認為所有安裝都必須使用
8188端口。
這些操作可能在沒找到失敗請求前製造第二個問題。
如何確認已經修好
重複最初觸發 Failed to fetch 的同一個動作。
成功修復應滿足對應條件：
- 同一個 panel 現在能載入；
- Manager 能取回列表；
- 頁面不再 reconnecting；
- workflow draft 能儲存；
- failed request 返回可用回應；
- ComfyUI 在啟動日誌顯示的地址上持續可用。
如果原始失敗涉及具體的 Manager、log、draft 或 WebSocket request，不要只用「頁面打開過一次」作為驗收。
Wonderful Launcher 如何幫忙
Wonderful Launcher 最適合在你知道失敗層級之後使用。它可以幫助你更有序地管理 ComfyUI 環境、模型資料夾和 custom node setup，避免把每個連線提示都當作完整重裝。
如果失敗請求指向缺失模型、損壞 custom nodes 或本地環境損壞，先使用上面的具體指南，再在需要更清晰地管理恢復工作時 下載 Wonderful Launcher。
相關 ComfyUI 連線錯誤
- Failed to Fetch Server Logs
- Failed to Get Custom Node List
- ComfyUI Reconnecting Error
- Failed to Save Workflow Draft
- ComfyUI Startup Failed
- ComfyUI Workflow Has Missing Nodes
來源參考
先按上面的步驟定位根因。還卡住時，可以下載 Wonderful Launcher 檢查目前機器；啟動器原生修復、任務日誌和執行階段檢查會集中在一起。credits 只用於圖片生成和按量工具。
下載 Wonderful Launcher查看 credits 方案這篇文件解決了你的問題嗎？
你的回饋會幫助我們優先補強真實 ComfyUI 排障文件。