[BUG] Sporadic errors - "ComfyUI server (127.0.0.1:8188) not reachable after multiple retries."

[HaimBendanan]

Describe the bug

When running ComfyUI on RunPod using the runpod/worker-comfyui Docker image, the ComfyUI server intermittently becomes unreachable and return errors.

From the worker side I sometime get:

ComfyUI server (127.0.0.1:8188) not reachable after multiple retries.

The issue appears sporadically during normal operation: it may persist for a few minutes and then resolve on its own, only to reappear later. It is not tied to a specific workflow and has occurred across multiple template versions.

Repro MVP

On RunPod, start a pod based on the ComfyUI template, using a custom Dockerfile:

FROM runpod/worker-comfyui:5.6.0-base
# (customizations for my use case; custom nodes/workflows/scripts)

Then:

Start the pod.

Trigger ComfyUI workflows via the worker.

After some time under normal usage (multiple workflows execution over time), observe that:

Some requests fail with

ComfyUI server (127.0.0.1:8188) not reachable after multiple retries.

After a few minutes, the error may disappear without any manual intervention.

At a later point, the same issue can reappear.

This behavior reproduces on different GPU types (currently running on RTX 5090) and across multiple versions of this template (not just 5.6.0).

Expected behavior

We should be able to reliably execute ComfyUI workflows.

No recurring intermittent periods where the ComfyUI server is unreachable.

If ComfyUI crashes or restarts, it should either:

Be restarted in a controlled way, or

Surface a clearer error/log indicating why the server is not listening.

Screenshots

See errors in metrics:

Versions (please complete the following information):

Docker base image: runpod/worker-comfyui:5.6.0-base

Template version (RunPod): 5.6.0 (issue also reproduced on earlier template versions)

ComfyUI version inside the image: [not sure – whatever is bundled with 5.6.0 template]

Host environment: RunPod GPU cloud

GPU types tried:

RTX 5090 (currently in use)

Other GPU types on RunPod (same issue)

Additional context

I am using the RunPod ComfyUI worker template as a base and extending it via Docker (FROM runpod/worker-comfyui:5.6.0-base).

The error:

• Appears sporadically during normal operation.
• Sometimes resolves by itself after a few minutes without restarting the pod.
• Has occurred across multiple versions of this template.

I tried:

• Changing GPU types → no improvement.
• Updating to the latest available template version → issue persists.

I would appreciate guidance on:

• How to restart or recover it gracefully from inside the container or via the worker logic.
• Any known issues or recommended configuration for long-running RunPod ComfyUI workers to avoid this intermittent “server not reachable” behavior.

[HaimBendanan]

@TimPietrusky @TimPietruskyRunPod your help on this would be greatly appreciated 🙏

[vectris-dev]

Having the same issue

[hlktrkn]

Same here

[dburenok]

Having this issue as well—on and off during the last few weeks. Tried the following to no avail:

• Limiting CUDA versions to 12.6, 12.7, 12.8
• Deleting problematic workers
• Contacting support multiple times with clear logs and description of error

Would really appreciate some help on this @TimPietrusky @TimPietruskyRunPod :)

[dburenok]

The following block of code may be of use to those of us having the error. Looks like the default timeout is 15 seconds which may be insufficient for large Comfy jobs. However, I'm not entirely certain this will resolve the issue.

# NOTE: more attempts and diagnostics improve debuggability whenever ComfyUI crashes mid-job.
#   • WEBSOCKET_RECONNECT_ATTEMPTS sets how many times we will try to reconnect.
#   • WEBSOCKET_RECONNECT_DELAY_S sets the sleep in seconds between attempts.
#
# If the respective env-vars are not supplied we fall back to sensible defaults ("5" and "3").
WEBSOCKET_RECONNECT_ATTEMPTS = int(os.environ.get("WEBSOCKET_RECONNECT_ATTEMPTS", 5))
WEBSOCKET_RECONNECT_DELAY_S = int(os.environ.get("WEBSOCKET_RECONNECT_DELAY_S", 3))

Source: https://github.com/runpod-workers/worker-comfyui/blob/main/handler.py

[dburenok]

In addition to the above, I believe the issue could be resolved by increasing COMFY_API_AVAILABLE_INTERVAL_MS environment variable to 100 or even greater from the default of 50.

After carefully analyzing the failed worker logs I noticed that the first job that comes in exceeded the 25 second timeout (500 * 50ms - source) due to what appears to be Comfy still loading the large checkpoints. Hence this returns the error "ComfyUI server (127.0.0.1:8188) not reachable after multiple retries." When a second job comes in from Runpod, it takes advantage of the loaded checkpoints on the server and the connection is established ("worker-comfyui - API is reachable").

I will continue to monitor the situation as I have no proof that this actually resolves the issue.