What the “Reconnecting” Overlay Actually Means
If you have used ComfyUI for more than a few days, you have almost certainly seen it: a small overlay in the corner of the canvas scrolling the word “Reconnecting” while the graph refuses to run. It can last a second, or it can sit there indefinitely. Either way, it means the same thing — the browser tab has lost its live connection to the ComfyUI server that is rendering your workflow.
The ComfyUI frontend is not a static web page. The moment the server starts, it exposes a WebSocket endpoint (by default ws://127.0.0.1:8188/ws) that the browser opens alongside the normal HTTP page. This socket is what pushes live progress updates, node execution status, preview images, and error messages back to the canvas in real time. When that socket drops, the frontend has no way to know that a generation is still running, so it shows the “Reconnecting” indicator while it repeatedly tries to re-establish the link.
The key thing to understand is that “Reconnecting” is a symptom, not a root cause. It tells you that the client lost the backend, but it does not tell you why. The distinction matters, because the fix for a crashed server is completely different from the fix for an overloaded browser tab, and mixing them up will send you in circles.
For a broader look at how the ComfyUI frontend and its HTTP API fit together, see our earlier breakdown of the open-source video generation stack on consumer hardware.
The Three Most Common Root Causes
When you strip away the noise, a persistent “Reconnecting” state almost always traces back to one of three things. Diagnosing which one you are dealing with should be your first step, before you change a single setting.
1. The Backend Process Actually Crashed
The most serious cause is the simplest to confirm. If the Python process running ComfyUI dies — from an out-of-memory kill, a custom node that raises an unhandled exception, or a hardware reset — the WebSocket closes instantly and the browser will spin “Reconnecting” forever, because there is nothing left to reconnect to.
Look at the terminal window where you launched ComfyUI. If it shows a traceback, a Killed message, or simply returned to the shell prompt, the server is down. This is common on 16GB-class cards when a video model like the Wan2.2 series pushes memory past the limit and the OS OOM killer steps in. The overlay is not the problem — the crash is.
2. A Long-Running or Blocking Operation on the Main Thread
ComfyUI executes prompt turns on the main event loop in many configurations. While a workflow is running — especially a heavy video generation or a node that does a lot of CPU-bound preprocessing — the server may not respond to the WebSocket heartbeat quickly enough. The browser interprets the silence as a dropped connection and flips to “Reconnecting,” even though the generation is still chugging along fine.
This is why the overlay often appears and disappears on its own without you touching anything. The socket reconnects, the frontend catches up on progress, and everything continues. It looks alarming but is frequently harmless.
3. Custom Nodes or a Slow Start Blocking Server Readiness
A related but distinct cause shows up at startup, not during generation. Every custom node package in your custom_nodes directory is imported when the server boots. Some of these packages — particularly larger ones or ones with heavy dependencies — take a long time to import. While imports are still running, the HTTP server may accept the page request but the WebSocket handler is not yet ready, so the first thing you see is “Reconnecting.”
Community reports on the ComfyUI desktop issue tracker describe exactly this: a desktop install that takes minutes to reach the UI, driven by a handful of slow custom node packs competing for import time. Disabling the offender in the Manager and restarting is usually enough to confirm it.
A Step-by-Step Diagnostic Path
Work through these in order. Each one either fixes the problem or narrows down where it lives, and none of them require guessing.
Step 1 — Confirm whether the server is still alive. Navigate to http://127.0.0.1:8188/ in a fresh tab. If the page loads but the graph never connects, check the terminal for a traceback. If the terminal shows a clean running state, the backend is up and the problem is on the connection side.
Step 2 — Watch the terminal during the “Reconnecting” episode. Trigger a generation and keep an eye on the console. If you see progress logs continuing while the overlay spins, you are looking at cause #2 (a blocking operation) and the connection will recover. If the logs stop dead, you are looking at cause #1.
Step 3 — Test the WebSocket in isolation. The browser’s own developer console (F12 → Network → WS) will show the WebSocket frames and any error. A clean 1006-style abnormal closure points at the server or an intermediary; a series of failed name resolutions points at the address being wrong (for example, accessing localhost from a different machine).
Step 4 — Isolate custom nodes. If the overlay appears mainly at startup or when a specific node runs, launch ComfyUI with custom nodes temporarily disabled and start re-enabling them one batch at a time. This is the fastest way to pin a single pathological package.
Step 5 — Check the transport, not the server. If you are reaching ComfyUI through a reverse proxy, running it in a container, or accessing it from another machine, the WebSocket is the first thing that breaks. Confirm that your proxy forwards the /ws upgrade correctly, and that you are using the same hostname the browser used to load the page.
Common Pitfalls That Keep the Error Around
A few failure modes look like the reconnect problem but are actually misdiagnosed, and they will keep throwing you off until you recognize them.
Accessing localhost from a remote browser. ComfyUI binds to 127.0.0.1 by default. If you open the UI from another machine using localhost:8188, you are pointing at your own machine, not the server. Use the server’s actual IP or hostname, and add --listen to the launch command if you need it to accept non-local connections.
VPNs, VPN kill-switches, and Tailscale. The WebSocket is a long-lived connection. If your VPN re-keys or a Tailscale interface flaps mid-generation, the socket drops and the overlay appears even though both the browser and server are healthy. This matches multiple community reports where the error only happens on certain network paths.
RAM/VRAM exhaustion rather than a real crash. On consumer hardware, a video model bumping into the VRAM ceiling can stall the process long enough to trigger the overlay without actually terminating it. If your “Reconnecting” correlates with heavy Wan2.2 or similar workloads, check your memory situation first — the fix may be a smaller resolution or a different set of VRAM launch flags rather than anything network-related.
Windows kernel timer resolution. Some Windows users report that the overlay is far more frequent when the system timer is at a coarse resolution, which delays WebSocket heartbeats. Running ComfyUI on a power plan that keeps the CPU at full clock, or disabling aggressive sleep, has resolved intermittent reconnects for a subset of reports on the official ComfyUI GitHub discussions.
How to Verify the Fix Actually Worked
You should not declare victory just because the overlay stopped flashing for a minute. A real fix survives a repeatable test.
1. Run a known-good workflow end to end. After applying any change, submit a simple generation and confirm the progress bar updates continuously from start to finish with no overlay flicker.
2. Stress the socket with a long task. The blocking-operation cause only shows up on long generations. Run a heavier workflow — a multi-step upscale or a short video clip — and watch for the overlay during the longest step. A healthy connection should stay silent the whole time.
3. Check the terminal for a clean close. When you stop ComfyUI, the process should exit without a traceback. A stack trace on shutdown is a sign that a custom node is still misbehaving and will likely bite you again.
4. Confirm network stability for remote setups. If you access ComfyUI remotely, run a couple of generations back to back and watch for the overlay appearing at regular intervals. Periodic drops on a fixed cadence almost always point to the transport (proxy, VPN, or Wi-Fi), not the server.
Conclusion
The “Reconnecting” overlay is ComfyUI’s way of telling you the live socket between browser and backend has gone quiet. On its own it is harmless — it often clears the moment the server catches up. But when it sticks, it is a signal that something specific is wrong: the backend crashed, the main thread is blocked, a custom node is delaying startup, or the network transport between you and the server is flapping.
The fastest path to a stable connection is to stop treating it as one generic error and instead pin down which of those categories you are in, using the diagnostic order above. Confirm the server is alive, isolate custom nodes, check the WebSocket transport, and only then worry about deeper memory or system-tuning issues. Do that, and the overlay goes from a recurring source of dread to a one-line signal you can read in seconds.
For the full context on how ComfyUI’s frontend, WebSocket, and HTTP API work together — including how to drive them programmatically — see our guide to automating ComfyUI over its API. For current, version-specific details on the interface and its configuration, refer to the official ComfyUI documentation.
Leave a Reply