#Error 1006

1 messages · Page 1 of 1 (latest)

vivid gazelle
#

Hi team, how are you? Any more with the error “Disconnetc 1006 no reason” in specificn when i sent a Telegram message it start to fail

IMG_5782.jpg
primal owlBOT
# vivid gazelle Hi team, how are you? Any more with the error “Disconnetc 1006 no reason” in spe...

I can see the error: "WebSocket closed with code 1006 (no reason given)" in Telegram. This is a WebSocket abnormal closure - the connection dropped without Telegram giving a specific reason.

Common Causes & Fixes

  1. Gateway restart - Most common! If the gateway restarted while Telegram connection was active, you'll see this. Just restart the gateway again and it should reconnect.

  2. Bot token issues - Try regenerating your Telegram bot token at @BotFather and updating your config.

  3. Network/firewall - Check if your server can reach Telegram's API (port 443). Some hosts block outgoing connections.

  4. Webhook conflicts - If you have a webhook set AND long polling, they can conflict. Make sure you only use one.

Quick Debug Steps

# Check gateway status
# 
clawdbot gateway status

# If not running, restart it
clawdbot gateway restart

# Check logs for more context
clawdbot gateway logs

Most likely fix: Just restart the gateway (clawdbot gateway restart). The 1006 often happens on transient network blips or gateway updates, and reconnecting usually resolves it.

If it keeps happening repeatedly, check:

  • Is your server's IP rate-limited by Telegram?
  • Do you have a webhook configured that might be timing out?

Let me know what clawdbot gateway status shows and we can dig deeper! 🩐

vivid gazelle
#

I try restart, uninstall, disable firewall, everything but not work. I dont have rate-limit, and it start in the first message

#

Maybe i went very restrictive in security configurations, but i can’t restart from default

primal owlBOT
# vivid gazelle I try restart, uninstall, disable firewall, everything but not work. I dont have...

That narrows it down! First message failure suggests something more fundamental.

A few questions:

  1. Does it fail immediately on ANY message (even /start or a simple text), or only specific types?

  2. Bot permissions - Check what your bot can do:

    • Does it have privacy mode enabled? (/setprivacy in BotFather - try disabling it)
    • Is it admin in the group with proper permissions?

  3. Webhook vs Long Polling - Which are you using? Check your config:

    clawdbot config get

    Look for telegram section - do you have a webhookUrl set?

  4. Test the bot directly - Can you message your bot directly in Telegram? Does that work?

#
  1. Token fresh - Is this a newly created token? Some old tokens have compatibility issues.

The "first message only" pattern is odd - it suggests the connection establishes but the message handling fails. Could be:

  • Bot was added to group but lacks admin rights
  • Privacy settings blocking message delivery
  • Webhook returning non-200 before messages process

What's your telegram config look like? 🩐

near hill
vivid gazelle
#

Solved. I fix it changed communication via IPv6 to IPv4, and improve a lot.
Anyway in the new version I haven’t the same problem! GL

near hill
#

On a fresh install with the latest package I am no longer having the issue

shrewd sigil
#

I just did a fresh instal but still getting it I think modifying the json and few other tweeks is needed

#

i was close to solving it and had just disconnected no reason error

#

but been on that for two hours so will take a break and refresh my mind lol

primal owlBOT
#

That “Disconnected 1006 (no reason)” is almost always the Control UI WebSocket getting dropped because the gateway threw an error / restarted / or the connection got interrupted. Sending a Telegram message is just what triggers the underlying crash.

To narrow it down quickly, can you paste these (with tokens redacted)?

  1. Version + status
openclaw --version
openclaw status
openclaw gateway status
openclaw channels status --probe
  1. Logs at the moment it happens
openclaw logs --follow

Then send a Telegram message again and paste the stack trace / error lines that appear right when the UI disconnects.

#
  1. Also: where do you see “1006” exactly?
  • in the Dashboard/Control UI (browser tab)?
  • or in the gateway logs?

If you also want a quick sanity check on config: paste just your channels.telegram block (JSON5) with botToken removed. Most “tweak the json” situations are actually just a wrong key name or policy mismatch.

Docs refs (same steps as above):

shrewd sigil
#

also my issue is for the browser not telegram.. YES exactly my websocket closes before it opens

primal owlBOT
#

“Disconnected / 1006 / no reason” is the UI’s WebSocket dropping — the real reason is in the gateway logs right before it disconnects (often a crash/restart when the Telegram send triggers some error).

Can you grab one repro with logs?

  1. Paste these first (they’re the fastest signal, and --all redacts secrets):
openclaw --version
openclaw status --all
openclaw gateway status
openclaw channels status --probe
  1. Then tail logs, reproduce, paste the error block
openclaw logs --follow

While that’s running: send the Telegram message again → copy the lines immediately before/after the disconnect (stack trace / “FATAL” / “Unhandled” / “EADDRINUSE”, etc.).

#
  1. If it’s specifically Telegram-related, also run right after the failure:
openclaw channels logs --channel telegram

Also quick check: are you opening the UI from a bookmark? If yes, try launching it via:

openclaw dashboard

(bookmarked URLs can have stale token/URL settings and reconnect weirdly).

Once you paste the log snippet around the disconnect, we can tell if this is (a) Telegram API error, (b) gateway restart loop, (c) config mismatch, or (d) a known version-specific bug.

#

Got it — if the WebSocket closes before it even opens, that’s a Control UI ↔ Gateway connectivity/auth problem (not Telegram). The browser tool never gets a chance if the UI can’t keep the gateway WS up.

Do this minimal triage (it’ll usually reveal the exact cause):

  1. Is the gateway actually reachable over WS?
openclaw gateway status
openclaw status

You’re looking for Runtime: running and RPC probe: ok.
If it’s running but probe fails → wrong URL/port/auth, or you’re hitting the wrong gateway instance.

  1. Open the UI using the “known-good” URL
openclaw dashboard

(helps avoid stale bookmarks / wrong host / wrong token in the UI)

#
  1. Tail logs while you refresh the UI
openclaw logs --follow

Then refresh the dashboard once and paste the lines that appear at that moment (common smoking guns: unauthorized, invalid handshake, EADDRINUSE, refusing to bind 
 without auth, etc.).

  1. Double-check the UI auth input
    In the dashboard go to Control → Overview → Gateway Access and make sure you paste the token into the Gateway Token field (there are usually two auth boxes side-by-side: token + password).

If you paste just the output of openclaw gateway status + the log snippet from the refresh attempt, we can tell you exactly what to change (URL vs token vs bind vs remote/tunnel).

#

Totally fair — stepping away helps.

When you’re back, quickest way to make progress is to capture one clean repro with evidence:

  1. Paste this (safe, redacts secrets):
openclaw status --all
openclaw gateway status
openclaw channels status --probe
  1. Then run:
openclaw logs --follow

Send one Telegram message, wait for the disconnect, and paste the log lines right around the moment it drops (that’s where the real cause is).