openclaw - 💡(How to fix) Fix [Bug]: Telegram network config (dnsResultOrder, autoSelectFamily) not applied to grammy/undici — requests timeout on IPv6-only resolve [1 comments, 2 participants]

Bug type

Behavior bug (incorrect output/state without crash)

Summary

On hosts where IPv6 is unreachable (curl -6 api.telegram.org fails with "Network is unreachable") but IPv4 works, Telegram API calls timeout despite correctly configured channels.telegram.network settings. The config is read and acknowledged in logs but not applied to the actual HTTP client (grammy + undici).

This appears to be a regression or oversight where the Telegram HTTP dispatcher is initialized before config is applied, or the network config isn't passed to undici.request() / fetch() calls.

Steps to reproduce

1. Deploy OpenClaw on a host with IPv6 disabled or unreachable:

   curl -6 https://api.telegram.org
   # curl: (7) Couldn't connect to server (Network is unreachable)
   
   curl -4 https://api.telegram.org
   # HTTP 302 (success)

2. Configure Telegram channel with IPv4-first settings:

   {
     "channels": {
       "telegram": {
         "network": {
           "autoSelectFamily": false,
           "dnsResultOrder": "ipv4first"
         }
       }
     }
   }

3. Verify config is applied:

   openclaw config get channels.telegram.network
   # {"autoSelectFamily":false,"dnsResultOrder":"ipv4first"}

4. Start gateway and send a message to the bot

5. Observe: Telegram API calls timeout despite config being correct

Expected behavior

The network.dnsResultOrder and network.autoSelectFamily config should force IPv4 for Telegram API calls, matching the documented behavior.

Actual behavior

• Config values are read correctly (openclaw config get shows them)
• Gateway logs may show autoSelectFamily=false and dnsResultOrder=ipv4first
• But Telegram API requests still attempt IPv6 first and timeout
• Only workaround that works: manually adding api.telegram.org to /etc/hosts with IPv4 address

OpenClaw version

2026.4.29

Operating system

Ubuntu 20.04.6 LTS on Oracle Cloud (ARM64/aarch64)

Install method

npm global install

Node.js version

v24.13.0

Logs, screenshots, and evidence

Network diagnostics showing the problem:

# IPv6 fails
curl -6 https://api.telegram.org
# curl: (7) Couldn't connect to server

# IPv4 works  
curl -4 https://api.telegram.org
# HTTP 302 OK

# Node fetch fails (uses IPv6)
node -e "fetch('https://api.telegram.org').then(r=>console.log('ok',r.status)).catch(e=>console.error(e.cause?.code,e.message))"
# ETIMEDOUT / UND_ERR_CONNECT_TIMEOUT

Config verification:

openclaw config get channels.telegram.network
# {"autoSelectFamily":false,"dnsResultOrder":"ipv4first"}

Also tried (no effect):

# systemd environment override
NODE_OPTIONS=--dns-result-order=ipv4first

Only workaround that works:

# /etc/hosts
149.154.166.110 api.telegram.org

Impact and severity

• Affected channel: Telegram
• Severity: High — blocks workflow
• Frequency: Always reproducible on IPv6-broken hosts
• Consequence: Telegram channel timeouts or completely non-functional without /etc/hosts workaround

Additional information

Root cause hypothesis

The grammy/undici HTTP client appears to be initialized before the channel config is applied, or the network config object isn't being passed through to the actual fetch() / undici.request() calls.

Evidence:

1. Config is stored correctly (verified via openclaw config get)
2. Code paths for autoSelectFamily and dnsResultOrder exist (verified via grep in 2026.4.29 source)
3. But the config has no runtime effect — requests still try IPv6 first

Related issues

• #28835 — Same symptoms on Ubuntu 24.04
• #53686 — Windows 11 with same workarounds failing
• #25676 — 2026.2.23 regression discussion
• #41671 — Inverse case (IPv6 works, IPv4 broken)

Suggested investigation

Check where the Telegram channel creates its HTTP dispatcher/agent. The network config needs to be passed to undici's Agent constructor or fetch() options at initialization time, not just logged.