Understanding and Troubleshooting "Reconnecting" in ComfyUI Load Diffusion Models

When a pop-up window displays "reconnecting" in ComfyUI during a load diffusion model workflow and then closes automatically, the process often halts and requires intervention to resume tasks. This article consolidates practical explanations and actionable steps drawn from common scenarios and the provided notes, focusing on diagnosing why reconnections occur and how to restore stable operation.

What the "reconnecting" window typically indicates

Normally this message means your ComfyUI is restarting. As for the reason why it restarted, you need to take a closer look at the ComfyUI log file. On the top right of the RunComfy ComfyUI page there is a “Log” button. The log contains clues about the restart cause and subsequent steps.

Common causes and fixes

  • OOM (Out of Memory) situations - either GPU VRAM or system RAM are exhausted. Common symptoms include abrupt restarts or failures during heavy load tasks like high-resolution image or video processing.
  • Crash due to coding error - the log may reveal an exception or stack trace. This typically requires updating components, patching a faulty script, or reverting recent changes.
  • Loss of connection between the ComfyUI webpage and the backend server - in some cases the reconnection is automatic and the page comes back online without user intervention.

Step-by-step troubleshooting workflow

  1. Open the log file by clicking the “Log” button on the RunComfyUI page. Inspect recent entries around the time of the reconnection to identify the root cause.
  2. Check resource usage to determine whether an OOM condition occurred. Monitor GPU VRAM and RAM usage and compare against the running model’s requirements.
  3. Reduce workload or upgrade hardware if memory limits are reached. Options include lowering image/video resolution, lowering batch size, or selecting lighter models.
  4. Verify code stability by reviewing recent changes or updates that could introduce a crash. Look for error call stacks and tracebacks in the log to pinpoint problematic modules.
  5. Test connectivity if the issue appears to be a transient network problem. Ensure the backend server remains reachable and that the frontend can reliably reconnect when needed.
  6. Restart and retest after applying fixes. If the problem persists, consider isolating components (e.g., run with a minimal workflow) to determine which part triggers the reconnection.

Practical recommendations for stable runs

  • Prefer smaller image or video resolutions during development or testing to minimize memory usage.
  • Run the backend and frontend on the same stable network to reduce unexpected disconnects.
  • Keep the ComfyUI and dependencies up to date to benefit from bug fixes and improved stability.
  • Utilize the log to diagnose whether reconnection is followed by a full restart or a seamless rejoin; this distinction guides the corrective action.

When to escalate

If the log consistently shows a recurring error call stack or repeated OOM events that cannot be mitigated by configuration changes, consider increasing hardware capacity or migrating to a more capable machine. Persistent coding errors reflected in the log warrant a review of installed scripts or requesting updates from maintainers.

illustration of ComfyUI log screen and reconnection

tags: #comfyui #load #diffusion #model #reconnecting