Description

After upgrading to OpenClaw v2026.4.29, both Telegram and QQBot plugins fail to connect on cloud servers that lack global IPv6 reachability. The underlying issue is that undici (the HTTP client bundled with plugin-runtime-deps, v8.1.0) defaults to a happy-eyeballs IPv6-first connection strategy, which blocks the event loop on servers where IPv6 resolves but cannot connect.

Environment

• OpenClaw Version: v2026.4.29 (upgrade from v2026.4.27)
• OS: Tencent Cloud Linux (OpenCloudOS 9, kernel 6.6)
• Node.js: v22.22.0
• Server has no global IPv6 reachability, but api.telegram.org resolves both A and AAAA records

Symptoms

1. Connectivity probe fails - gateway status shows Connectivity probe: failed
2. Event loop blocked - logs show eventLoopDelayP99Ms=31356.6 (31 seconds)
3. Telegram fetch timeout - fetch timeout reached; aborting operation (getMe, elapsedMs: 18167)
4. QQBot native approvals timeout - connect ETIMEDOUT 127.0.0.1:XXXXX, gateway event loop readiness timeout
5. Both Telegram and QQBot channels become unresponsive

Root Cause

The plugin-runtime-deps bundles undici@8.1.0. Node.js default DNS resolution order returns both IPv4 and IPv6 addresses. undici tries IPv6 first in its happy-eyeballs implementation. On servers where IPv6 resolves but has no global route, each outgoing request to api.telegram.org waits for IPv6 connection timeout before falling back to IPv4. These sequential delays stack up and block the event loop, causing the gateway readiness probe to timeout.

Workarounds

Workaround 1 - Force IPv4-first DNS resolution:
Set NODE_OPTIONS=--dns-result-order=ipv4first in the gateway service environment.

Systemd override example:

# /etc/systemd/system/openclaw-gateway.service.d/override.conf
[Service]
Environment="NODE_OPTIONS=--dns-result-order=ipv4first"

Workaround 2 - Downgrade to v2026.4.27:

npm install -g openclaw@2026.4.27 --force

Expected Behavior

The HTTP client should either:

1. Respect the system routing and Node.js dns order setting, or
2. Fail fast on IPv6 and fall back to IPv4 without a multi-second timeout that blocks the event loop

Additional Context

• v2026.4.27 worked without issues because its HTTP client (likely using Node.js built-in fetch) handled IPv6 fallback properly and respected --dns-result-order=ipv4first
• The plugin-runtime-deps staging mechanism installs undici under ~/.openclaw/plugin-runtime-deps/, bypassing Node.js built-in fetch
• This affects any server without global IPv6, which is common for cloud VPS providers