[Telegram] Recurring UND_ERR_CONNECT_TIMEOUT on multi-account setup — known issue?

[jaunty spade]

Hey all — running into recurring [telegram] fetch fallback UND_ERR_CONNECT_TIMEOUT errors and wanted to check if this is a known issue before I dig deeper.

Setup:

• OpenClaw 2026.3.24
• Mac Mini, hardwired ethernet (no Wi-Fi, no Tailscale)
• 5 separate Telegram bots configured under accounts
• Errors firing roughly every 10–15 minutes throughout the day

Questions:

1. Is this a known issue with multi-account Telegram setups, or does it show up on single-bot configs too?
2. Is there a config key to increase the fetch/polling timeout or add retry backoff?
3. Could 5 concurrent bots be hitting a Telegram rate limit on polling?

Happy to share gateway logs if useful. Thanks 🦞

[zinc cipher]

I dug through the Telegram docs and current channel code a bit.

Short version:

1. This does not look multi-account-only.
   UND_ERR_CONNECT_TIMEOUT is treated as a recoverable network/connect error in the Telegram polling path, so it can happen on single-bot setups too.
   Having 5 bots mostly increases the odds of seeing it, because you have 5 independent long-poll loops.

2. There is a timeout knob, but not a polling-backoff knob.

   • channels.telegram.timeoutSeconds exists.
   • channels.telegram.retry also exists, but it applies to outbound send helpers/tools/actions, not the inbound getUpdates poller.
   • Polling already has built-in retry/restart behavior in code, but I do not see a user config key for tuning that backoff directly.

3. 5 concurrent bots are unlikely to be a Telegram rate-limit problem by themselves.
   A rate-limit case would usually look like 429 / Too Many Requests / retry_after.
   UND_ERR_CONNECT_TIMEOUT is a connect-layer timeout, so it is usually network path / DNS / IPv6 / proxy / TLS reachability, not Telegram rejecting you.

A couple details from code/docs that matter:

• Long polling is the default.
• Polling currently uses a 30s getUpdates timeout, and OpenClaw also has recover/restart logic around polling failures.
• Docs explicitly call out Telegram instability cases around:
  • broken IPv6 egress
  • DNS / HTTPS reachability to api.telegram.org
  • fetch/proxy transport issues

Docs:

• https://docs.openclaw.ai/channels/telegram
• https://docs.openclaw.ai/channels/troubleshooting
• https://docs.openclaw.ai/gateway/configuration

What would help most next:

• output of openclaw channels status --probe

• ~20 to 40 log lines around one failure from openclaw logs --follow
• your redacted channels.telegram block, especially:
  • defaultAccount
  • network.autoSelectFamily
  • network.dnsResultOrder
  • proxy
  • whether each bot token is only running in one OpenClaw process

If you want, paste that and I can help narrow it down pretty fast.

[jaunty spade]

Log lines: single clean error every 10-15 min:
2026-04-14T20:02:23 [telegram] fetch fallback: enabling sticky IPv4-only dispatcher (codes=UND_ERR_CONNECT_TIMEOUT)

Config:

• network: {} (empty)
• proxy: not set
• 5 accounts (default, ruby, forge, minslow, sentinel), unique tokens, single gateway process

[zinc cipher]

That log is actually pretty informative.

fetch fallback: enabling sticky IPv4-only dispatcher (codes=UND_ERR_CONNECT_TIMEOUT)

That points much more to IPv6 / dual-stack connect flakiness than to Telegram rate limiting.

So, based on what you shared:

• not likely a multi-account-only bug
• not likely a 5-bot polling rate limit
• much more likely your host/network path to api.telegram.org occasionally times out on the first connect path, then OpenClaw recovers by pinning that bot to IPv4

A few concrete takeaways:

1. This is a known class of issue
   The docs/code explicitly call out intermittent Telegram failures on hosts where IPv6 egress is flaky.

2. channels.telegram.retry will not help here
   That setting is for outbound send helpers, not the inbound long-poll loop.

3. There is no exposed polling backoff knob I can see
   Polling already retries internally.

What I’d try first is forcing the Telegram network path away from the default dual-stack behavior:

{
  channels: {
    telegram: {
      defaultAccount: "default",
      network: {
        autoSelectFamily: false,
        dnsResultOrder: "ipv4first",

      },
    },
  },
}

Since base Telegram settings apply to all accounts, that should cover all 5 unless you override per-account.

One nuance: if this is the only log line and messages are still flowing fine, it may just be a noisy self-healing fallback, not a real outage. If you’re also seeing missed/delayed replies, then I’d definitely treat it as worth fixing.

If you want, next useful data point is just:

• did forcing autoSelectFamily: false reduce/stop the log?
• are you seeing any actual missed Telegram updates, or just the fallback line?

Docs:

• https://docs.openclaw.ai/channels/telegram
• https://docs.openclaw.ai/channels/troubleshooting
• https://docs.openclaw.ai/gateway/configuration

[jaunty spade]

Thanks Krill — that makes sense. Messages have been flowing fine so it's likely just the noisy fallback. I've added autoSelectFamily: false to the network block and restarted. Will monitor and report back if the errors continue. Appreciate the quick turnaround 🦞

[zinc cipher]

Nice, that sounds like the right test.

If it stays quiet after that restart, I’d treat it as harmless dual-stack noise we’ve now sidestepped.

If it still pops up, next things I’d try are:

• dnsResultOrder: "ipv4first"
• a Telegram proxy
• webhook mode, if you want to avoid long polling entirely

If it settles down, please come back and say so, it’ll be useful for the next person who hits the same log line 🦐

[jaunty spade]

One more thing — is there a way to get my bot added to this server so it can monitor threads and respond directly? Bot client ID: 1485271938128412692. Happy to keep it read-only if that's preferred.