Unable to connect Openclaw to Telegram

[quaint olive]

My ISP blocks IPv4 connections to api.telegram.org
curl connects fine via IPv6
OpenClaw hardcodes dnsResultOrder=ipv4first in the Telegram provider, preventing any workaround
The fix needed is either a config option to prefer IPv6, or removing the hardcoded IPv4 override

Any ideas?

[long locust]

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

[crisp fulcrum]

You don’t have to patch code for this (on current builds) — Telegram has a network override now.

Try forcing DNS ordering away from ipv4first:

{
  channels: {
    telegram: {
      network: {
        dnsResultOrder: "verbatim", // (allowed: "ipv4first" | "verbatim")
        // and keep/enable happy-eyeballs style fallback:
        autoSelectFamily: true,
      },
    },
  },
}

There are also env overrides if you want to test without touching config:

• OPENCLAW_TELEGRAM_DNS_RESULT_ORDER=verbatim
• OPENCLAW_TELEGRAM_ENABLE_AUTO_SELECT_FAMILY=1

Docs (see “Polling or network instability”): https://docs.openclaw.ai/channels/telegram

Two quick sanity checks that help narrow it down:

1. What does openclaw --version show? (older versions did effectively behave “hardcoded” here)
2. Does your host return AAAA first if you do a Node lookup (order matters if autoSelectFamily is off)? e.g. dig +short api.telegram.org AAAA

If verbatim still returns IPv4 first on your OS and IPv4 is blackholed (not RST), then yeah: adding explicit ipv6first support (or widening the allowed enum) would be the right fix — that’d be a good GitHub issue with your ISP + dig A/AAAA output.

[quaint olive]

IPv6 is available (dig AAAA returns 2001:67c:4e8:f004::9) but verbatim still connects via IPv4 first, which is blackholed by the ISP. Requesting ipv6first as an allowed value for dnsResultOrder, or a way to pass a custom DNS lookup order. OpenClaw version 2026.3.8.

[crisp fulcrum]

Yeah — with 2026.3.8 you’ve basically hit the ceiling of what the current knob can do:

• channels.telegram.network.dnsResultOrder only allows ipv4first or verbatim
• verbatim means “whatever order your OS resolver gives me”, and on your box that still comes back A-first, so you still get the blackholed IPv4 attempt.

Things to try right now (no code changes)

1. Force happy-eyeballs on (if it isn’t actually being applied)
   Even if DNS returns IPv4 first, autoSelectFamily=true should quickly race IPv6.
   Set it explicitly + via env to remove ambiguity:

{
  channels: {
    telegram: {
      network: { autoSelectFamily: true, dnsResultOrder: "verbatim" },

    },
  },
}

Env (temporary):

• OPENCLAW_TELEGRAM_ENABLE_AUTO_SELECT_FAMILY=1
• OPENCLAW_TELEGRAM_DNS_RESULT_ORDER=verbatim

If it still hangs on IPv4 only, that’s a strong hint the underlying Telegram HTTP path isn’t getting autoSelectFamily applied the way we expect.

2. Use a proxy (boring but works)
   If you can reach anything over IPv6, run a SOCKS/HTTP proxy on a VPS (or anywhere not blocking TG IPv4) and set:

• channels.telegram.proxy: "socks5://user:pass@host:1080"
  Docs mention this as the standard escape hatch.