Guía de Solución: Error de Conexión de Telegram (ETIMEDOUT/ENETUNREACH) en OpenClaw#

Paso 2.1: Revisar los Registros#

El primer paso fue consultar los registros de OpenClaw para buscar errores relacionados con Telegram.

1
# Comando para ver los últimos 20 registros relacionados con "telegram"
2
grep -i "telegram" /tmp/openclaw/openclaw-$(date +%F).log | tail -n 20

Resultado: Se encontró un error recurrente de tipo WARN (advertencia):

1
fetch fallback: enabling sticky IPv4-only dispatcher (codes=ETIMEDOUT,ENETUNREACH)

• ETIMEDOUT: La conexión expiró por tiempo de espera.
• ENETUNREACH: La red de destino era inalcanzable.

Esto apuntaba a un problema de red o de resolución de DNS.

Paso 2.2: Descartar un Fallo de Red General#

Para confirmar que no era un problema de la conexión a internet de la máquina, se realizó una prueba de conexión directa a la API de Telegram usando curl.

1
# Se obtuvo el Bot Token del archivo de configuración ~/.openclaw/openclaw.json
2
curl -v https://api.telegram.org/bot<TU_BOT_TOKEN_AQUI>/getMe

Resultado: El comando curl funcionó perfectamente, devolviendo un HTTP/2 200 OK y una respuesta JSON válida.

Conclusión clave: La máquina SÍ tenía conexión a internet y podía alcanzar los servidores de Telegram. Por lo tanto, el problema estaba aislado al entorno de software de OpenClaw/Node.js.

Paso 2.3: Investigar la Configuración DNS del Sistema#

La hipótesis se centró en un problema de resolución de DNS específico de Node.js, probablemente relacionado con un mal manejo de registros IPv6. Para investigarlo, se revisó la configuración de DNS del sistema.

1
cat /etc/resolv.conf

Resultado: El servidor de nombres era 127.0.0.53. Esto indicó que el sistema estaba usando un intermediario local para las consultas DNS: el servicio systemd-resolved.

Paso 2.4: Identificar al Culpable#

Para ver qué servidores DNS estaba usando realmente systemd-resolved, se ejecutó el siguiente comando:

1
resolvectl status

Resultado: Se confirmó que systemd-resolved estaba activo y que utilizaba servidores DNS públicos y válidos (ej. 8.8.8.8).

Conclusión Final del Diagnóstico: El único punto de fallo restante era el propio servicio systemd-resolved, que actuaba como un intermediario defectuoso entre Node.js y los servidores DNS funcionales, causando los timeouts.

Paso 3.1: Reconfigurar el DNS del Sistema#

Estos comandos requieren permisos de administrador (sudo).

1. Eliminar el archivo resolv.conf dinámico (que es un enlace simbólico):

   1
   sudo rm /etc/resolv.conf
   

2. Crear un nuevo archivo resolv.conf estático apuntando a un DNS público (ej. Google):

   1
   echo "nameserver 8.8.8.8" | sudo tee /etc/resolv.conf
   

Paso 3.2: Deshabilitar el Servicio systemd-resolved#

Para asegurar que el intermediario no vuelva a activarse.

1. Deshabilitar el servicio para que no inicie en el arranque:

   1
   sudo systemctl disable systemd-resolved.service
   

2. Detener el servicio activo:

   1
   sudo systemctl stop systemd-resolved.service
   

Paso 3.3: Reiniciar los Servicios#

Para que todo el sistema adopte la nueva configuración de red.

1. Reiniciar el servicio de red principal (el nombre puede variar):

   1
   # Para sistemas modernos como Ubuntu 20.04+
   2
   sudo systemctl restart NetworkManager.service
   3
   
   4
   # Para sistemas más antiguos (ej. Debian)
   5
   # sudo systemctl restart networking.service
   

2. Reiniciar el gateway de OpenClaw para que corra en segundo plano con la nueva configuración:

   1
   openclaw gateway restart