Tons of connection errors | Friends of the Crustacean 🦞🤝 | Page 1

cobalt plume Feb 15, 2026, 8:22 PM

#

Im new to open claw and did setup it today.
Sometimes the bot responds, but often it does not. There simple come connection errora all the time except few times not.
I can see in the openrouter API that the models i selected are called at least sometimes. I tried different out but it felt similar.

The terminal itselfs feels also very buggy, it often says no response even if there is one. Gives no exact feedback why no connection. Displays sutff in dark blue that makes it unreadable for me.

I installed open claw in a VPS (2CPUs) in Unbuntu.

How to get it to work.
What i dont understand at all why it sometimes can connect but often not.

Anyone any idea what to do?

finite muskBOT Feb 15, 2026, 8:22 PM

#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

main heartBOT Feb 15, 2026, 8:25 PM

#

Intermittent “connection errors” are almost always diagnosable from the Gateway status + logs — but we need the exact failure signature (429/rate limit, timeout, DNS, WebSocket disconnect, Discord mention-gating, etc.).

Can you paste the output of these from the VPS (they redact secrets in the --all report):

openclaw --version
node --version

openclaw status --all
openclaw gateway status
openclaw models status
openclaw channels status --probe

Then reproduce one failure and paste ~30–60 seconds of:

#

openclaw logs --follow

Things that commonly look like “it sometimes works, sometimes doesn’t”:

UI/TUI lost the WebSocket (you’ll see disconnect/reconnect; FAQ calls this out).
Provider-side throttling (e.g. HTTP 429, transient 5xx, or timeouts) — OpenRouter can succeed sometimes and fail under bursty load.
Discord group policy (message gets dropped unless you mention the bot / allowed channel) — logs often show drop guild message (mention required...).
Gateway process restarting (OOM kill / crash loop) — openclaw gateway status + logs will show it.

About the terminal colors: if the TUI colors are unreadable, try disabling ANSI colors for that session (often works with many CLIs):

NO_COLOR=1 openclaw tui
# or

#

FORCE_COLOR=0 openclaw tui

Relevant docs (the troubleshooting ladder above is straight from here):

https://docs.openclaw.ai/help/troubleshooting
https://docs.openclaw.ai/help/faq (sections: “First 60 seconds”, “Disconnected from gateway”)
https://docs.openclaw.ai/gateway/troubleshooting
https://docs.openclaw.ai/web/tui

Also: are you mainly testing via Discord, via the web dashboard, or via openclaw tui? The debug path is slightly different depending on where you expect the reply to show up.

#

Yeah — the exact error text matters a lot here.

If you can, share either:

Screenshot of the place that says “connection error” (TUI or dashboard), including the few lines above it (often shows 401/403, 429, timeout, ENOTFOUND, WS close code, etc.)

and/or (even better)

Paste these outputs from the VPS (they’re designed to be shareable; tokens get redacted in --all):

openclaw --version
openclaw status --all
openclaw gateway status
openclaw models status
openclaw channels status --probe

#

Then reproduce the failure once and paste ~30-60 seconds of:

openclaw logs --follow

Also: are you seeing the error in openclaw tui, the web Control UI/dashboard, or Discord replies? (Different “connection error” depending on where it shows up.)

cobalt plume Feb 15, 2026, 8:27 PM

#

openclaw --version
2026.2.9

main heartBOT Feb 15, 2026, 8:28 PM

#

2026.2.9 helps — that’s a bit behind current builds, and a bunch of networking/retry/TUI issues have been fixed over time. (You don’t have to update yet, but if we find it’s a known-fixed bug, updating will be the answer.)

Next: can you paste the output of these from the VPS?

openclaw status --all
openclaw gateway status
openclaw models status
openclaw channels status --probe

And then reproduce one “connection error” and paste ~40 lines around it from:

openclaw logs --follow

#

What I’m looking for in logs is the real cause string (examples: HTTP 429 rate limit, timeout, ENOTFOUND DNS, 401/403, WebSocket close code, “mention required” for Discord, etc.). The UI often just says “connection error” for all of those.

Also quick clarifier: are you seeing the error mainly in openclaw tui, the web Control UI, or in Discord message replies?

languid bramble Feb 15, 2026, 8:28 PM

#

cobalt plume openclaw --version 2026.2.9

Can you share a screenshot of the error you received

main heartBOT Feb 15, 2026, 8:29 PM

#

Yep — please do.

Best is a screenshot that includes the full TUI window (or dashboard page), so we can see:

the exact error text
the URL/token mode it’s trying to use (often visible in the header/footer)
the status line (connecting/running/error) around the time it fails

Just make sure no secrets are visible:

If it shows a #token=... URL (dashboard) or any API keys, blur/crop that part.

If you can also paste the text output (usually even more useful than a screenshot):

openclaw status --all
openclaw gateway status

#

openclaw models status
openclaw channels status --probe

And when it happens, grab ~30-60 seconds of:

openclaw logs --follow

The logs will tell us why it’s “connection error” (429/rate limit vs timeout vs DNS vs unauthorized vs WS disconnect, etc.).

languid bramble Feb 15, 2026, 8:30 PM

#

languid bramble Can you share a screenshot of the error you received

@cobalt plume

cobalt plume Feb 15, 2026, 8:30 PM

#

Bot says: Let me migrate soul.json → soul.toml right now:

Connection error.

can you check the logs why you get that many connection errors?

terminated

Connection error.

────────────────────────────────────

main heartBOT Feb 15, 2026, 8:30 PM

#

No need to ping anyone here—just upload the screenshot directly in this thread.

If you can, please share one screenshot of the “connection error” that shows:

the error message
the TUI/dashboard header/footer (URL/connection state)

Please blur/crop any tokens (anything like #token=..., API keys, etc.).

Even better than a screenshot: paste this output from the VPS (safe to share; it redacts secrets):

openclaw status --all
openclaw gateway status
openclaw models status
openclaw channels status --probe

#

And when it errors, paste ~30–60 seconds of:

openclaw logs --follow

cobalt plume Feb 15, 2026, 8:32 PM

#

it just says connection error without any further error message. nothing. Maybe good to update the bot first

main heartBOT Feb 15, 2026, 8:32 PM

#

Those Connection error. lines aren’t the TUI being “confused” — that string usually comes from the model provider HTTP call failing (DNS failure, timeout, connection reset, upstream outage), and the UI just shows the generic message.

I can’t see your VPS logs from here, but you can grab the exact reason in ~30 seconds:

1) Tail the Gateway logs while reproducing

Run this on the VPS, then send one message that triggers the error:

openclaw logs --follow

When you get “Connection error.”, copy/paste the log lines around the failure (you’ll usually see something like ETIMEDOUT, ECONNRESET, ENOTFOUND, 429, 502, etc.). That tells us what’s actually happening.

2) Share a quick health snapshot

Also paste:

openclaw gateway status

#

openclaw gateway probe
openclaw models status
openclaw status --all

Common root causes (based on “works sometimes”)

Intermittent DNS / broken IPv6 on VPS → you’ll see ENOTFOUND or connect timeouts.
OpenRouter / upstream transient errors → you’ll see 5xx or resets/timeouts in logs.
Rate limiting → shows as HTTP 429 (not usually “connection error”, but worth checking).

Post the log snippet + the outputs above and we can tell you the next fix step (and whether it’s a “your VPS networking” thing vs an OpenRouter/upstream thing).

#

Yeah, updating first is a good move — you’re on 2026.2.9, and a bunch of provider/network retry + TUI stuff has been improved since then.

1) Update (on the VPS)

Run:

openclaw update status
openclaw update --channel stable
# (it will usually restart the Gateway for you; if not:)
openclaw gateway restart
openclaw doctor

After that, re-test in the TUI.

2) “Connection error.” is generic — the real reason is in Gateway logs

The TUI often only shows the SDK’s generic Connection error.. To see the actual cause (timeout/DNS/reset/429/etc), do this:

#

Terminal A

openclaw logs --follow

Terminal B

openclaw tui

Send one message that triggers the issue, then copy/paste the log lines around the failure from Terminal A.

3) If the TUI colors are unreadable

Try:

#

NO_COLOR=1 openclaw tui

If after updating the logs still don’t show anything useful, paste openclaw status --all too and we’ll go from there.

cobalt plume Feb 15, 2026, 8:48 PM

#

end: runId=309691ba-6db5-43cc-802e-1a8b2146cab8 sessionId=d1e50377-3953-487e-a0e3-4aa77feece76 durationMs=51505
20:43:38 debug diagnostic {"subsystem":"diagnostic"} session state: sessionId=d1e50377-3953-487e-a0e3-4aa77feece76 sessionKey=unknown prev=processing new=idle reason="run_completed" queueDepth=0
20:43:38 debug diagnostic {"subsystem":"diagnostic"} run cleared: sessionId=d1e50377-3953-487e-a0e3-4aa77feece76 totalActive=0
20:43:38 debug agent/embedded {"subsystem":"agent/embedded"} embedded run done: runId=309691ba-6db5-43cc-802e-1a8b2146cab8 sessionId=d1e50377-3953-487e-a0e3-4aa77feece76 durationMs=51579 aborted=false
20:43:38 debug diagnostic {"subsystem":"diagnostic"} lane task done: lane=main durationMs=51589 active=0 queued=0
20:43:38 debug diagnostic {"subsystem":"diagnostic"} lane task done: lane=session:agent:main:main durationMs=51601 active=0 queued=0
20:44:01 debug plugins {"subsystem":"plugins"} plugin CLI register skipped (memory-core): command already registered (memory)
20:45:18 warn [openclaw] Non-fatal unhandled rejection (continuing): TypeError: fetch failed
at node:internal/deps/undici/undici:14902:13
at processTicksAndRejections (node:internal/process/task_queues:105:5)
20:46:40 debug plugins {"subsystem":"plugins"} plugin CLI register skipped (memory-core): command already registered (memory)

main heartBOT Feb 15, 2026, 8:49 PM

#

That log snippet is only the start of the run — it shows:

OpenRouter headers applied
run started (new=processing)

…but it doesn’t include the part where it fails, so we still can’t tell why you’re getting “Connection error.” (timeout vs DNS vs reset vs 429/5xx, etc.).

Can you paste the next ~50–100 lines after that, up to the first line that contains error / warn / run_finished / run_failed?

A reliable way to capture it on the VPS:

Option A (follow + reproduce)

In one terminal:

openclaw logs --follow

Trigger one message that fails

#

Copy/paste everything from run_started until you see the error / finish.

Option B (grab the raw file log – often more detailed)

If openclaw logs doesn’t show the juicy part, tail the actual file:

tail -n 200 "$(ls -t /tmp/openclaw/openclaw-*.log | head -1)"

Also run an explicit provider probe (this often prints the real network error)

openclaw models status --probe --probe-provider openrouter --plain

That output (and the missing log lines) will usually reveal the exact cause (e.g. ETIMEDOUT, ENOTFOUND, ECONNRESET, etc.), and then we can give you the specific fix.

If you haven’t updated yet, do that first and re-test:

#

openclaw update --channel stable
openclaw --version

#

That log line is the smoking gun:

Non-fatal unhandled rejection (continuing): TypeError: fetch failed
    at node:internal/deps/undici/...

So this isn’t “the TUI randomly saying connection error” — the Gateway is failing an outbound HTTP request (Undici = Node’s HTTP client). Most commonly that’s your OpenRouter call failing due to DNS / IPv6 / timeout / connection reset.

A few concrete next steps:

1) Update first (recommended)

You’re on 2026.2.9 — update to stable and restart:

openclaw update --channel stable

#

openclaw --version
openclaw gateway restart

(Then try again and see if the unhandled rejection is gone.)

2) Get the real error (cause code)

fetch failed usually has a cause like ENOTFOUND, ETIMEDOUT, ECONNRESET, etc. Your current log print didn’t include it.

Please run:

openclaw models status --probe --probe-provider openrouter --plain

…and paste the result. That often prints the actual network error.

#

3) VPS networking check (especially IPv6)

On many VPSes, IPv6 DNS resolves, but IPv6 connectivity is flaky → intermittent “connection error”.