Summary

When the host hits a kernel-side local socket allocation failure (EADDRNOTAVAIL on connect()), the gateway logs:

[telegram] fetch fallback: DNS-resolved IP unreachable; trying alternative Telegram API IP (codes=none, reason=probe timeout/network error)

Two problems:

1. Misleading message

EADDRNOTAVAIL is a local allocation failure — the kernel can't assign a source address/port for the new socket. DNS resolved fine, and the remote IP isn't unreachable (ICMP works to other destinations). The message points triage at the remote ("Telegram is down") when the actual symptom is local socket resource exhaustion or a network-extension policy wedge.

2. Fallback logic is dead code for this errno class

The fallback retries an alternative Telegram API IP. But changing the remote IP cannot fix a local source-address-assignment failure. Every retry will hit the same errno. This wastes time and produces more misleading log noise during an incident.

Real-world impact

Hit this on 2026-06-18 during a host-wide TCP outage. The misleading log sent initial triage toward Telegram availability checks before discovering plain nc -vz 127.0.0.1 18789 was also failing with Can't assign requested address — i.e. a kernel-layer issue affecting all destinations including loopback.

Suggested fix

• Detect EADDRNOTAVAIL (errno 49 on macOS, 99 on Linux) at the undici/fetch boundary.
• On that specific errno: log it accurately ("local socket allocation failure — check ephemeral ports / mbuf zones / network extensions; remote IP rotation will not help") and skip the IP-rotation retry.
• For other errnos where remote rotation might help (ETIMEDOUT, ECONNREFUSED to a specific IP), keep current behavior.

Repro

Trigger any condition that causes connect() to fail with EADDRNOTAVAIL (e.g. exhaust ephemeral ports, wedge a Network Extension). Watch the gateway log the misleading fallback and uselessly try the alternative IP.

Environment

• OpenClaw 2026.5.27 (27ae826)
• macOS, Node 22
• LaunchAgent-managed gateway on loopback:18789