ComfyUI Stuck on "Reconnecting"? It's Not Your Network — Read the Terminal (2026)

By RunAIHome Team · 11 min read
comfyuitroubleshootingstable-diffusionvramlocal-aioom

TL;DR: The red “Reconnecting…” banner in ComfyUI means the browser lost its WebSocket link to the Python backend — and the backend almost always crashed before the banner appeared. It is not a network problem and refreshing the browser won’t fix it. The real diagnosis is sitting in the terminal window that launched ComfyUI. Read that, and the fix is usually obvious in under a minute: out of VRAM/RAM (the #1 cause), a broken custom node (#2), or a port conflict (#3).

What you’ll be able to do after this guide:

  • Tell in 10 seconds whether the backend crashed, got killed by the OS, or is genuinely a connection issue
  • Fix VRAM and system-RAM out-of-memory crashes with the right ComfyUI flags instead of guessing
  • Isolate the one custom node that’s taking the server down on every run

Honest take: Stop refreshing the browser and stop reinstalling ComfyUI. Switch to the terminal that ComfyUI is running in and read the last 20 lines. The banner is the symptom; the terminal has the cause, and 90% of the time it’s memory.

Step 1: Understand what “Reconnecting” actually means

ComfyUI is two programs. The backend is a Python server you started from a terminal (or the Desktop app), and it does all the real work — loading models, running the sampler, decoding the VAE. The frontend is the graph you see in your browser at http://127.0.0.1:8188. The two talk over a WebSocket — a persistent connection at ws://127.0.0.1:8188/ws?clientId=<id> that streams progress, previews, and the “done” signal back to your browser (ComfyUI WebSocket API docs).

When that WebSocket drops, the frontend shows “Reconnecting…” and starts retrying. There are only two reasons the line goes dead:

  1. The backend process stopped or crashed (the overwhelming majority of cases). Python died mid-run, so there’s nothing on the other end to answer.
  2. Something between the browser and the server broke the connection — a proxy that kills idle sockets, a reverse proxy without WebSocket upgrade headers, or aggressive security software.

The mistake almost everyone makes is treating it as case #2 — clearing cache, switching browsers, restarting the router — when it’s nearly always case #1. So the very first move is to look at the right place.

Step 2: Read the terminal, not the browser

Switch to the terminal window where you launched ComfyUI (python main.py, the .bat file on Windows portable, or the Desktop app’s log). What you see there decides everything:

  • The process exited and you’re back at a shell prompt → the backend crashed. Scroll up to the last lines before it died.
  • A Python traceback printed, then it quit → a code-level error (often a custom node). The error name on the traceback is your fix.
  • The single word Killed (Linux/WSL) → the OS out-of-memory killer terminated ComfyUI. This is a system RAM problem, not VRAM. More on this below.
  • torch.OutOfMemoryError: CUDA out of memory or Allocation on device → you ran out of VRAM.
  • The terminal is still alive and printing normally → now, and only now, is it worth suspecting an actual network/proxy issue.

If you run ComfyUI as a service or inside Docker and don’t have a visible terminal, capture the log instead. On a systemd setup that’s journalctl -u comfyui -e; in Docker it’s docker logs <container>. The point is the same: the backend’s own output is the source of truth.

Cause #1: Out of memory — the reason most “Reconnecting” loops happen

Memory exhaustion is the number-one cause of the reconnecting banner, and it comes in two flavors that people constantly confuse.

VRAM exhaustion (GPU memory)

Heavy workflows — SDXL or FLUX at high resolution, big batch sizes, video models like Wan or LTX, upscalers — can ask for more VRAM than your card has. When the allocation fails hard, the backend can crash and take the WebSocket with it. ComfyUI’s logs are explicit when it’s juggling memory; in issue #10630 the server printed loaded partially; 6968.65 MB usable, 6968.65 MB loaded, 7807.76 MB offloaded right before dying on a combined VLM + diffusion pipeline that didn’t fit.

Fixes, in the order I’d try them:

  1. Lower the load. Drop resolution (generate at 1024×1024, upscale after), set batch size to 1, and reduce the number of models loaded in one graph.
  2. Tell ComfyUI to use less VRAM. Launch with --lowvram (offloads the text encoder and parts of the model to system RAM) or, on very small cards, --novram. These trade speed for fit.
  3. Reserve headroom for the OS. --reserve-vram 2 keeps 2 GB free so the desktop compositor and browser don’t get squeezed into the same pool ComfyUI is fighting for (command-line arguments reference).
  4. Decode the VAE on CPU. --cpu-vae moves the single most VRAM-spiky step off the GPU — often enough to stop a crash at the very end of a run.

If you’re on an 8 GB card running modern FLUX or video workflows, no flag fully fixes the physics — you’re a few GB short. The durable answer is a card with more headroom, like a used RTX 3090 with 24 GB, or — if you only need the VRAM occasionally — renting a bigger GPU by the hour on RunPod instead of buying. For the full VRAM-error playbook across every tool, see our CUDA out of memory fixes guide.

System RAM exhaustion (the Killed case)

This one fools people because their VRAM looks fine. ComfyUI is RAM-heavy during model loading — it stages weights in system memory before moving them to the GPU, and it can commit far more virtual memory than it actually uses on high-RAM machines (issue #8298). When system RAM runs out, the Linux kernel’s OOM-killer terminates the biggest process — ComfyUI — and you see nothing but Killed in the terminal and “Reconnecting” in the browser.

Confirm it’s the OOM-killer:

dmesg -T | grep -i 'killed process'

If you see a line naming a Python process, that’s your culprit (issue #5177). Fixes:

  • Add swap. On Linux/WSL, a 16–32 GB swap file gives the kernel somewhere to spill instead of killing the process. It’s slow, but it stops the crash.
  • Close memory hogs. Browsers with 40 tabs and other models loaded (Ollama, LM Studio) compete for the same RAM.
  • Use a smaller checkpoint or a quantized model. A GGUF or fp8 build of the same model loads with a smaller RAM footprint.
  • 16 GB of system RAM is the practical floor for FLUX-class work; 32 GB is where it stops being a daily annoyance.

Cause #2: A broken custom node taking the server down

Custom nodes are the second most common cause. A node can throw an unhandled exception mid-execution, or — worse — segfault a native library it depends on, which kills the whole Python process instantly and triggers the reconnect loop. Some nodes even break the server’s ability to restart cleanly: issue #12108 documents the SeedVR2 nodes leaving the server in a state where it won’t stop and the reconnecting popup stops appearing at all.

How to isolate it:

  1. Read the traceback. If a Python error printed before the crash, the file path in the traceback points straight at the offending node (custom_nodes/<node-name>/...).
  2. Bisect by disabling nodes. Use ComfyUI-Manager to disable half your custom nodes, restart the server, and re-run. Narrow down by halves until one node is the difference between crash and success.
  3. Watch the timing. If it crashes only when a specific node executes (not at startup), that node is the suspect. If it dies during startup, that’s an import failure — different problem, covered in our IMPORT FAILED guide.
  4. Update or remove. A git pull inside the node’s folder often fixes a stale-version crash; if not, remove the node and report the bug.

A clean, all-black output instead of a crash is a different failure mode — see ComfyUI black image output fixes. And if nodes won’t even import at boot, the Torch not compiled with CUDA enabled fix covers the most common root cause.

Cause #3: Port conflicts and the genuine connection cases

Only after you’ve ruled out a backend crash should you look at the connection itself.

Port already in use. ComfyUI defaults to port 8188. If another process (a leftover ComfyUI, another app) holds it, startup fails — and ComfyUI will try the next ports up to 8198 before giving up with Error starting the server: Ports 8188 to 8198 are all in use (issue #3450). Kill the stale process, or launch on a clean port with --port 8189 and point your browser there.

Reverse proxy without WebSocket upgrade. If you access ComfyUI through Nginx, Caddy, or a tunnel, the proxy must forward the Upgrade and Connection headers, or the /ws channel never establishes and you sit in a permanent reconnect. Our Linux production setup guide shows the exact Caddy config that handles this correctly.

Idle-timeout proxies. Cloud tunnels and some corporate proxies close sockets that go quiet. During a long sampling run with no progress messages, the WebSocket looks idle and gets cut. A reverse proxy with a generous read timeout fixes it.

Security software / firewall. Aggressive antivirus or firewall rules occasionally block localhost WebSocket traffic. Confirm by temporarily allowing the ComfyUI port — but this is rare, and worth checking only after the terminal shows the backend is healthy.

The 60-second diagnostic order

  1. Look at the terminal. Did the process exit?
  2. Killed → system RAM OOM. Add swap, close apps, use a smaller model.
  3. CUDA out of memory / partial-load logs → VRAM OOM. --lowvram, --reserve-vram 2, --cpu-vae, lower resolution.
  4. Python traceback → custom node. Read the path, bisect with Manager, update or remove.
  5. Ports … in use → kill the stale process or --port 8189.
  6. Terminal still alive and healthy → now check the proxy, port, and firewall.

A note on ComfyUI Desktop: it accepts a different set of flags than the portable/main.py build. Passing a flag the Desktop launcher doesn’t recognize — like the old --normalvram — crashes it on startup with unrecognized arguments (fix writeup). Check which build you’re on before adding flags.

FAQ

Does refreshing the browser ever fix the Reconnecting error? Only when the backend was briefly busy and recovers on its own. If the Python process actually crashed, no amount of refreshing helps — the server has to be restarted. Refreshing also won’t tell you why it dropped, which is the part that matters.

Why does my VRAM look fine in Task Manager but ComfyUI still crashes with OOM? Two reasons. First, the spike that kills it (often VAE decode) is brief and you miss it on a 1-second-refresh monitor. Second, your crash may be system RAM, not VRAM — check for Killed in the terminal and run dmesg -T | grep -i 'killed process'.

Is --lowvram or --cpu better for a low-memory card? --lowvram keeps the GPU doing the heavy compute and only offloads what it must, so it’s much faster than --cpu (which runs everything on the processor and is painfully slow). Use --novram only if --lowvram still can’t fit. Reach for --cpu solely to confirm a workflow is otherwise correct.

I restarted and it loaded — will it just crash again? If the cause was a one-off memory spike, maybe not. But a workflow that exhausts memory once will do it again under the same settings. Apply the actual fix (lower the load, add a flag, add swap) rather than relying on the restart.

Does this apply to ComfyUI running on RunPod or a cloud GPU? Yes — the architecture is identical. The difference is you read the pod’s terminal/log instead of a local one, and cloud tunnels add the idle-timeout proxy case from Cause #3. Renting a larger GPU also sidesteps the VRAM-OOM case entirely for one-off heavy jobs.

Sources

Last updated June 30, 2026. ComfyUI flags and behavior change between releases; verify against your build’s --help output before relying on a flag.

Was this article helpful?