ComfyUI Stuck on Reconnecting? 9 Causes and Fixes (2026 Guide)

If ComfyUI is stuck on “Reconnecting…”, the browser tab is not the problem. That message only means the web page lost contact with the ComfyUI server running in the background, and in almost every case the server crashed, ran out of memory, or never started. This guide shows you how to find out which one it was in under a minute, then walks through the nine causes I see most often in 2026, with the exact log lines, launch flags and settings that fix each one. It covers the Windows portable build, ComfyUI Desktop, manual installs on Linux, and remote setups behind a proxy.

What “Reconnecting” Actually Means

ComfyUI has two parts: a Python server (the backend that loads models and runs your workflow) and the web page you see in the browser (the frontend). They talk over a WebSocket connection on http://127.0.0.1:8188 by default. When that connection drops, the frontend shows a small “Reconnecting…” banner and keeps retrying.

So there are only two possibilities:

• The backend died or is frozen (about nine times out of ten). It crashed, was killed for using too much memory, or is stuck at 100% disk while swapping.
• The backend is fine, but the connection is blocked: a browser extension, VPN, firewall, or a proxy that does not forward WebSockets.

Refreshing the page or switching browsers only helps in the second case, which is why so many “fixes” online do nothing.

The One-Minute Diagnosis

1. Look at the ComfyUI console window (the black window from run_nvidia_gpu.bat, or your terminal). Is it still open?
2. If it closed, start ComfyUI from a terminal you opened yourself so the window stays open after a crash, then reproduce the problem. For the portable build:

   cd C:\ComfyUI_windows_portable
   .\python_embeded\python.exe -s ComfyUI\main.py --windows-standalone-build

3. Scroll up to the first error, not the last line. The first traceback or the line just before the console stopped tells you the cause.
4. Check Task Manager > Performance while the workflow runs. If Memory hits 95-100% just before the crash, it is a RAM problem. If GPU dedicated memory is full and the log says out of memory, it is VRAM.
5. If the console is still running happily and shows no error, open http://127.0.0.1:8188 in a private window. If that works, the problem is your browser or network path (Fix 7 or 8).

Where to Find the ComfyUI Log

On Linux, if the process vanished with no traceback, also check whether the kernel killed it for using too much memory:

dmesg -T | grep -i "killed process"

Error Message to Fix: Quick Table

Fix 1: System RAM Ran Out (Most Common)

This is the classic “console just disappears” crash. Modern image and video models are big: a full-precision 14B video model plus its 10 GB text encoder can need more than 40 GB of system RAM while ComfyUI loads and moves weights between RAM and VRAM. When Windows runs out of RAM and page file, it kills the Python process instantly, with no error message. The browser then shows “Reconnecting” forever.

How to confirm: Task Manager shows Memory at 95-100% just before the crash, often during “Requested to load…” or while a model is loading.

Fixes, in order of impact:

1. Increase the Windows page file. Open System > About > Advanced system settings > Performance Settings > Advanced > Virtual memory > Change. Untick “Automatically manage”, pick your fastest SSD, choose Custom size and set it to 32768 MB minimum and 65536 MB maximum (more for video work). Click Set, then reboot. This alone fixes most cases on 16-32 GB RAM PCs.
2. Use smaller model files. Switch to fp8 or GGUF versions of the diffusion model and text encoder. A Q4/Q5 GGUF text encoder is a fraction of the size of the full one. My GGUF quantization guide explains which file to pick.
3. Close other memory hogs: browsers with dozens of tabs, games, and other model servers such as Ollama or LM Studio that keep a model loaded.
4. On Linux or WSL, add a swap file:

   sudo fallocate -l 32G /swapfile
   sudo chmod 600 /swapfile
   sudo mkswap /swapfile
   sudo swapon /swapfile

5. Add RAM if you do video. In 2026, 32 GB is the practical minimum for current image and video models and 64 GB is comfortable.

Fix 2: GPU VRAM Ran Out

If “Reconnecting” appears right after you press Queue, and the log shows torch.OutOfMemoryError: CUDA out of memory, the GPU ran out of memory. ComfyUI normally recovers from this with an error message, but with some custom nodes, video models and VAE decodes it can bring the whole server down.

• Reduce the work: lower the resolution, the number of frames, or the batch size. Video length is the biggest lever.
• Use tiled VAE decode (the VAE Decode (Tiled) node) for large images and long videos; the decode step is a common VRAM spike.
• Leave room for Windows: launch with --reserve-vram 1 (or 2) so ComfyUI keeps 1-2 GB free for the desktop and browser.
• Force more offloading: --lowvram moves more of the model to system RAM. Use --novram only as a last resort.
• Close other GPU apps, including a second ComfyUI instance or Ollama.

For the portable build, add flags to the end of the line in run_nvidia_gpu.bat:

.\python_embeded\python.exe -s ComfyUI\main.py --windows-standalone-build --reserve-vram 1

All the memory flags are explained in my ComfyUI command line arguments guide, and model-specific limits for 16 GB cards are in my how much VRAM for ComfyUI post.

Fix 3: A Custom Node Crashed the Server

If the traceback mentions a folder inside ComfyUI/custom_nodes/, a custom node caused the crash. This is very common right after updating ComfyUI, because a node pack has not caught up with a core change.

1. Confirm it by starting without any custom nodes:

   # portable
   .\python_embeded\python.exe -s ComfyUI\main.py --windows-standalone-build --disable-all-custom-nodes
   
   # manual install
   python main.py --disable-all-custom-nodes

2. If ComfyUI now runs a basic workflow, update the node pack named in the traceback (ComfyUI-Manager > Update All, or git pull inside its folder), then restart.
3. If you cannot tell which node it is, disable half your node packs in ComfyUI-Manager, restart, and repeat until you find it.
4. Still broken? Move that node’s folder out of custom_nodes and check the node’s GitHub issues page for a fix.

Fix 4: Exit Code 3221225477 (Access Violation)

On Windows, especially with ComfyUI Desktop, you may see Python process exited with code 3221225477 or Windows fatal exception: access violation. 3221225477 is the decimal form of 0xC0000005, a native crash inside compiled code rather than a Python error. It usually comes from one of these:

• GPU driver or CUDA mismatch. Update to the latest NVIDIA Studio or Game Ready driver and reboot. RTX 50 series cards need a recent driver and a PyTorch build for CUDA 12.8 or newer.
• A compiled extension built for another PyTorch version, such as an old SageAttention, xformers, Triton or a custom node with a .pyd file. Start with --disable-all-custom-nodes; if that fixes it, reinstall the accelerated extension for your current PyTorch version.
• A corrupted Python environment after a failed update. On Desktop, use the app’s reinstall/troubleshoot option; on portable, extract a fresh copy and move your models, custom_nodes and user folders across.
• Unstable overclock or bad RAM, if it happens randomly across different models. Reset GPU and memory overclocks to stock and test again.

Fix 5: Broken Python Packages After an Update

If the server fails at startup with ModuleNotFoundError, ImportError or cannot import name, the browser will show “Reconnecting” because the backend never started. Install the requirements with the same Python that runs ComfyUI:

# portable (run inside the portable folder)
.\python_embeded\python.exe -m pip install -r ComfyUI\requirements.txt

# manual install, with your venv activated
pip install -r requirements.txt
pip check

Be careful with node packs that pin old versions of torch, numpy or transformers; installing their requirements can break ComfyUI itself. If torch was replaced by a CPU-only build, reinstall the CUDA build that matches your ComfyUI release. My ComfyUI errors and fixes list covers the most common import errors one by one.

Fix 6: Port 8188 Already in Use

If you see port 8188 is already in use or Ports 8188 to 8198 are all in use, an old ComfyUI process is still running in the background, and your browser may be talking to a dead or frozen copy.

# Windows: find and stop the process on port 8188
netstat -ano | findstr :8188
taskkill /PID <the PID from the last column> /F

# or start on another port
.\python_embeded\python.exe -s ComfyUI\main.py --windows-standalone-build --port 8189

Then open http://127.0.0.1:8189.

Fix 7: Server Is Fine, Browser Keeps Reconnecting

If the console shows no errors and keeps printing progress, the problem is between the page and the server:

• Hard-refresh with Ctrl+F5, or open http://127.0.0.1:8188 in a private window.
• Disable ad blockers, privacy and script-blocking extensions for 127.0.0.1.
• Turn off VPNs and “web protection” features in antivirus software, which can block local WebSockets.
• Use 127.0.0.1 instead of localhost if your system resolves localhost to IPv6 and ComfyUI only listens on IPv4.
• Open DevTools (F12) > Network > WS. If the /ws request fails immediately, something is blocking it.

Fix 8: Remote, LAN, Cloud and Reverse Proxy Setups

• Other devices on your network: start ComfyUI with --listen 0.0.0.0 and allow port 8188 in Windows Firewall. Test http://127.0.0.1:8188 on the PC itself first.
• Nginx: the WebSocket upgrade headers must be forwarded, and long-running jobs need long timeouts:

  location / {
      proxy_pass http://127.0.0.1:8188;
      proxy_http_version 1.1;
      proxy_set_header Upgrade $http_upgrade;
      proxy_set_header Connection "upgrade";
      proxy_set_header Host $host;
      proxy_read_timeout 3600s;
      proxy_send_timeout 3600s;
  }

• Cloudflare Tunnel, ngrok and cloud GPU platforms: idle WebSockets can be closed during long video renders. The job usually keeps running on the server; reload the page after it finishes, or check the output folder.

Fix 9: Reconnecting at the Same Node Every Time

If the crash always happens at the same node, the graph tells you the cause:

• At a Load Checkpoint / Load Diffusion Model / Load CLIP node: system RAM (Fix 1).
• At KSampler: VRAM (Fix 2), or an attention extension such as SageAttention crashing (Fix 4).
• At VAE Decode: VRAM spike; use tiled VAE decode or fewer frames.
• At a custom node: that node (Fix 3).
• At Save Image / Video Combine: disk full, an antivirus lock, or an ffmpeg problem in the video node.

For MiniMax H3 and other video models on 16 GB cards, my MiniMax H3 out of memory fixes have model-specific settings that avoid these crashes.

How to Stop It Happening Again

• Keep a 32-64 GB page file on an SSD and leave it there.
• Prefer fp8 or GGUF files when you are near your RAM or VRAM limit.
• Update ComfyUI and your custom nodes together, not one without the other.
• Launch from a terminal (or keep the console visible) so you always see the first error.
• Back up a working portable folder before big updates; restoring it takes a minute.
• Put your model files in the right folders so ComfyUI does not load the wrong, larger file; see my ComfyUI model folders cheat sheet.

Frequently Asked Questions

Why does ComfyUI keep saying Reconnecting?

Because the browser lost its connection to the ComfyUI server. Usually the server crashed or was killed, most often because system RAM or GPU VRAM ran out. Check the console window or log for the first error.

ComfyUI says Reconnecting and the console window closes. What happened?

Almost always Windows ran out of RAM and page file while loading a model and killed the Python process. Increase the page file to 32-64 GB on an SSD and use fp8 or GGUF model files.

Does refreshing the page fix Reconnecting?

Only if the server is still running and the browser connection dropped. If the server crashed, refreshing does nothing until you restart ComfyUI and fix the cause.

What is exit code 3221225477 in ComfyUI?

It is the Windows access violation code 0xC0000005, a native crash. Update your GPU driver, start with --disable-all-custom-nodes, and reinstall compiled extensions such as SageAttention or xformers for your current PyTorch version.

Is ComfyUI Reconnecting a network problem?

Rarely. On a local PC it is almost always the backend crashing. It is a network problem only when the server is still running and you connect through a LAN IP, VPN, tunnel or reverse proxy.

Which launch flag fixes Reconnecting?

There is no single flag. --reserve-vram 1 and --lowvram help with VRAM crashes, --disable-all-custom-nodes helps you find a broken node, and --port 8189 avoids port conflicts. RAM crashes are fixed by a larger page file, not a flag.

Final Thoughts

“Reconnecting” is a symptom, not an error. Read the first error in the console, match it to the table above, and you will usually be generating again in a few minutes. On most home PCs the winner is still the same: a bigger page file and smaller model files.

If you hit a different error along the way, check my 22 common ComfyUI errors and fixes, tune memory with the launch flags guide, and make sure your files are in the right place with the model folders cheat sheet.

Sources

• ComfyUI docs: Desktop for Windows (log and install paths)
• ComfyUI on GitHub (launch arguments)
• Comfy forum: exit code 3221225477 report
• RunAIHome: ComfyUI Reconnecting log signatures
• Wonderful Launcher: Reconnecting troubleshooting