Reconexión automática en MT4: la guía definitiva para programadores

La forma fiable de lograr reconexión automática en MT4 consiste en comprobar IsConnected() y coordinar los reintentos desde OnTimer en lugar de usar Sleep(), refrescando los datos con RefreshRates() y validando el estado del terminal antes de enviar cualquier orden. Este enfoque reduce el tiempo de inactividad del asesor experto y evita operaciones basadas en datos desincronizados tras una caída de red.

En resumen:

• La función IsConnected() solo verifica la conexión con el servidor, por lo que debe complementarse con comprobaciones de sincronización de series y datos del terminal.
• Es preferible usar OnTimer en lugar de Sleep() para gestionar reintentos de reconexión sin bloquear la reacción del asesor a eventos y ticks en tiempo real.
• El patrón más seguro combina reintentos con backoff exponencial, límites en el número de intentos y la actualización de precios con RefreshRates() tras recuperar la conexión.
• Antes de automatizar reintentos, se recomienda revisar parámetros de red, servidores y configuraciones de proxy para solucionar problemas básicos de conexión.
• Para gestionar varias cuentas o mantener sincronización en múltiples terminales, existen soluciones externas que trabajan en la máquina local, minimizando latencias y facilitando la gestión centralizada.

Tabla de contenidos

• Cómo detectar la pérdida de conexión con IsConnected
• Por qué evitar Sleep() en asesores expertos y usar OnTimer
• Patrones de reconexión: intervalos, reintentos y backoff
• Plantilla de código para implementar la reconexión paso a paso
• Ajustes del terminal y la red que resuelven la mayoría de los cortes
• Cómo probar y validar que la reconexión funciona de verdad
• Cuándo conviene una herramienta local además del código de reconexión
• Automatizar sin perder el control sobre el riesgo
• Una alternativa para quien gestiona varias cuentas: copia local de operaciones
• Preguntas frecuentes
• Fuentes

Cómo detectar la pérdida de conexión con IsConnected

La función IsConnected() devuelve true cuando el terminal mantiene conexión activa con el servidor de trading, y conviene comprobarla antes de ejecutar cualquier lógica que dependa de precios en tiempo real. Un uso mínimo es tan simple como preguntar por el estado y salir de la función si no hay enlace:

if(!IsConnected())
  {
   Print("No connection!");
   return(0);
  }

Esta comprobación responde a una pregunta concreta: ¿hay enlace con el servidor? No responde a otra, igual de importante: ¿están sincronizadas las series de precios que el asesor va a usar? Un terminal puede mostrar conexión activa mientras el historial de velas todavía no se ha actualizado tras una reconexión, y operar en ese instante expone a decisiones basadas en datos obsoletos.

Para cubrir ese vacío conviene añadir comprobaciones complementarias:

• Verificar SymbolIsSynchronized() antes de leer precios o abrir posiciones tras una reconexión.
• Consultar SeriesInfoInteger() para confirmar que la cantidad de barras disponibles coincide con lo esperado.
• Revisar TerminalInfoInteger(TERMINAL_CONNECTED) como capa adicional de diagnóstico junto a IsConnected().

A nivel de infraestructura, también ayuda vigilar métricas del propio terminal. Las propiedades de conectividad de MQL5 permiten leer valores como TERMINAL_RETRANSMISSION, que indica el porcentaje de paquetes reenviados por problemas de red. Un valor elevado suele anticipar desconexiones intermitentes antes de que IsConnected() llegue a devolver false.

IsConnected() confirma el enlace con el servidor, no la sincronización de los datos: combinarla con comprobaciones de series evita que un asesor opere con información incompleta justo después de recuperar la conexión.

Por qué evitar Sleep() en asesores expertos y usar OnTimer

Sleep() detiene por completo la ejecución del programa MQL4 durante el intervalo indicado, y ese bloqueo puede frenar la cola de eventos del terminal mientras el asesor espera. En un entorno donde cada tick y cada evento de temporizador compiten por procesarse, introducir pausas bloqueantes dentro de la lógica de reconexión es contraproducente: el EA deja de reaccionar a nuevos ticks, a cambios de gráfico o a otros eventos mientras dura la pausa.

La alternativa recomendada es OnTimer, un controlador de eventos que se ejecuta a intervalos fijos sin bloquear el resto del programa. Configurarlo es sencillo:

int OnInit()
  {
   EventSetTimer(5);
   return(INIT_SUCCEEDED);
  }

void OnTimer()
  {
   if(!IsConnected())
     {
      // lógica de reintento aquí
     }
  }

void OnDeinit(const int reason)
  {
   EventKillTimer();
  }

Con EventSetTimer(5) el terminal invoca OnTimer() cada cinco segundos, momento ideal para comprobar el estado de conexión sin interferir con OnTick. Esta separación de responsabilidades es la ventaja central: OnTick sigue reaccionando a cada movimiento de precio, mientras OnTimer se encarga exclusivamente de la vigilancia de red y los reintentos.

Cuando ambos controladores necesitan compartir información (por ejemplo, para que OnTick sepa que hay una reconexión en curso y evite operar), conviene usar una variable global de tipo bandera:

• Declarar un booleano como bool reconectando a nivel de programa.
• Activarlo desde OnTimer cuando se detecta pérdida de conexión.
• Comprobarlo al inicio de OnTick para bloquear el envío de órdenes mientras la bandera esté activa.
• Desactivarlo solo después de confirmar que IsConnected() y la sincronización de series son correctas.

Consejo profesional: reserva OnTimer solo para tareas de vigilancia y mantenimiento; nunca para lógica de entrada o salida de operaciones, que debe seguir viviendo en OnTick.

Patrones de reconexión: intervalos, reintentos y backoff

Un bucle de reintentos sin límites ni pausas crecientes puede saturar la conexión justo cuando el bróker intenta restablecerla, además de arriesgar duplicar órdenes si el EA reacciona varias veces al mismo evento. Un patrón más seguro combina backoff exponencial con un techo de reintentos:

1. Al detectar !IsConnected(), iniciar un contador de reintentos en cero.
2. Esperar un intervalo inicial corto (por ejemplo, cinco segundos) antes del primer reintento, gestionado siempre desde OnTimer.
3. Si la conexión sigue caída, duplicar el intervalo de espera en cada ciclo hasta un máximo razonable (por ejemplo, sesenta segundos).
4. Tras un número máximo de intentos (diez o quince, según la volatilidad del bróker), detener los reintentos automáticos y registrar una alerta para revisión manual.
5. Al recuperar la conexión, llamar a RefreshRates() antes de permitir cualquier operación nueva.

RefreshRates() actualiza las variables de precio y las series que el asesor usa internamente, y resulta especialmente útil justo después de un reintento exitoso, cuando el terminal puede tardar unos instantes en reflejar los precios correctos. Forzar esta actualización antes de operar evita decisiones basadas en cotizaciones congeladas.

Para prevenir efectos secundarios no deseados durante los reintentos conviene aplicar varias salvaguardas:

• Usar una bandera de bloqueo que impida el envío de nuevas órdenes mientras el proceso de reconexión está activo.
• Validar que el número de ticks recibidos tras la reconexión es coherente antes de operar.
• Revisar GetLastError() después de cada intento fallido para distinguir errores de red de errores de validación de orden.
• Evitar reiniciar el EA completo como primera respuesta. Reiniciar el terminal entero es un recurso de último nivel, no el primer paso.

La referencia sobre ejecución de programas en MQL4 recomienda incorporar exactamente este tipo de bandera de control antes de reabrir operaciones, precisamente para evitar duplicados cuando la sincronización de series todavía no se ha verificado.

Plantilla de código para implementar la reconexión paso a paso

Una estructura reproducible organiza la lógica en cuatro bloques: inicialización, temporizador, verificación en cada tick y limpieza al cerrar el programa.

int   intentos = 0;
bool  reconectando = false;

int OnInit()
  {
   EventSetTimer(5);
   return(INIT_SUCCEEDED);
  }

void OnTimer()
  {
   if(!IsConnected())
     {
      reconectando = true;
      intentos++;
      Print("Intento de reconexión número: ", intentos);
     }
   else
     {
      if(reconectando)
        {
         RefreshRates();
         reconectando = false;
         intentos = 0;
         Print("Conexión restablecida y datos actualizados.");
        }
     }
  }

void OnTick()
  {
   if(reconectando) return;
   // lógica normal de trading
  }

void OnDeinit(const int reason)
  {
   EventKillTimer();
  }

El punto que marca la diferencia no es detectar la caída, sino impedir que OnTick siga operando mientras la bandera de reconexión está activa.

Cada bloque cumple una función concreta: OnInit arranca el temporizador, OnTimer concentra toda la vigilancia y el conteo de intentos, OnTick se limita a comprobar la bandera antes de actuar, y OnDeinit libera el temporizador al cerrar el EA para evitar procesos huérfanos.

Antes de llevar esta plantilla a una cuenta real conviene ajustar algunos parámetros:

• Fijar el intervalo de EventSetTimer según la volatilidad típica del bróker, no un valor genérico copiado de otro proyecto.
• Probar el comportamiento desconectando manualmente el cable de red o el wifi durante unos minutos en una cuenta demo.
• Revisar los registros del terminal tras cada prueba para confirmar que GetLastError() no reporta códigos inesperados.

Ajustes del terminal y la red que resuelven la mayoría de los cortes

Antes de automatizar cualquier lógica de reconexión conviene descartar causas más simples. La guía de configuración de servidor de MetaTrader 4 señala que buena parte de los mensajes de «sin conexión» proceden de una dirección de servidor mal configurada o de parámetros de proxy incorrectos, no de un fallo real del EA.

Antes de tocar una sola línea de código, conviene revisar:

• Que la dirección del servidor sigue el formato IP:puerto indicado por el bróker y que no se ha quedado desactualizada tras una migración de infraestructura.
• Los parámetros de proxy en las opciones de servidor del terminal, especialmente si el equipo cambió de red recientemente.
• Que el terminal se ejecuta como administrador en Windows, algo que evita que el programa quede bloqueado al intentar sobrescribir archivos de configuración tras un cierre inesperado, según señalan guías de resolución de errores comunes.
• Las reglas del cortafuegos y del antivirus, que a veces bloquean silenciosamente el tráfico del terminal sin mostrar ningún aviso visible.
• La opción de reescanear servidores disponibles, útil cuando el bróker ha añadido nuevos nodos y el terminal sigue intentando conectar al antiguo.

Un artículo técnico sobre resolución de errores de conexión en MT4 coincide en que validar la lista de servidores y la configuración de proxy suele resolver la mayoría de estos casos antes de necesitar ninguna automatización adicional. Saltarse esta revisión y lanzar directamente lógica de reintentos sobre un problema de configuración de red es perder tiempo depurando algo que no es un bug.

Cómo probar y validar que la reconexión funciona de verdad

Verificar el comportamiento antes de confiarle una cuenta real exige escenarios de prueba deliberados, no solo confiar en que «funcionó una vez».

1. Simular una desconexión real desactivando temporalmente la red del equipo o VPS mientras el EA está en marcha.
2. Forzar un cambio de servidor desde el terminal para comprobar que la lógica de reintento también cubre ese caso, no solo la caída total de red.
3. Provocar una pérdida de ticks dejando el gráfico sin actividad varios minutos y comprobar que RefreshRates() actualiza correctamente al reanudar.

Durante cada prueba conviene registrar la tasa de reintentos, la marca de tiempo exacta de cada reconexión y cualquier código devuelto por GetLastError(), de forma que un fallo intermitente deje rastro identificable en los registros del terminal en lugar de desaparecer sin explicación.

Toda esta validación debe hacerse primero en cuenta demo y, preferiblemente, en el mismo VPS donde correrá en producción: las condiciones de red de un VPS difieren de las de un equipo doméstico, y un patrón de reconexión que funciona en casa puede comportarse distinto bajo la latencia de un centro de datos.

Consejo profesional: añade una alerta por correo o notificación push cuando el contador de reintentos supere el máximo configurado, así te enteras del problema antes que tu bróker.

Cuándo conviene una herramienta local además del código de reconexión

Programar una reconexión robusta resuelve la continuidad de un único asesor experto, pero quien gestiona varias cuentas simultáneamente enfrenta un problema distinto: mantener sincronizadas las operaciones entre una cuenta maestra y varias cuentas cliente cuando cualquiera de los terminales sufre un corte. En el mercado existen utilidades como Stable Helper, que monitorizan la conexión a intervalos regulares y reintentan reconectar automáticamente, una muestra de que este patrón ya se resuelve como producto independiente y no solo como fragmento de código.

Una solución instalada localmente en el propio PC o VPS aporta ventajas concretas en estos escenarios:

• Reduce la latencia al eliminar el salto a un servidor en la nube intermedio.
• Mantiene todo el tráfico bajo una sola dirección IP, algo relevante para cuentas de firmas propietarias sensibles a la detección de ejecución remota.
• Facilita gestionar reconexión y replicación de operaciones como un único problema de infraestructura, no dos sistemas separados.

Quien evalúe este tipo de herramienta debería pedir al proveedor datos concretos: tiempo de ejecución local, antigüedad del producto en el mercado y volumen de usuarios activos, no solo una lista de funciones.

Automatizar sin perder el control sobre el riesgo

La reconexión automática resuelve un problema técnico, pero introduce uno nuevo si se diseña sin límites: un EA que reabre posiciones apenas detecta señal, sin validar que los datos están completos, puede operar sobre precios erróneos justo en el peor momento. La automatización bien hecha no es la que reacciona más rápido, sino la que sabe cuándo abstenerse.

Preferimos un modo de reconexión conservador que bloquee nuevas entradas hasta confirmar la sincronización de series, y documentar cada cambio en la lógica de reintentos con pruebas periódicas, no solo con una prueba inicial que luego nadie repite.

— Rimantas

Una alternativa para quien gestiona varias cuentas: copia local de operaciones

Si tu problema no es solo mantener un EA conectado, sino replicar operaciones entre varias cuentas MT4, MT5 o DXTrade sin depender de servidores en la nube, trabajamos con un enfoque distinto: todo el software corre en tu propio PC o VPS, con ejecución local por debajo de 0,5 segundos y sin enrutamiento externo.

Esto resulta útil en escenarios muy concretos:

• Gestores de cuentas que replican una estrategia desde una maestra hacia varios clientes con tamaños de lote distintos.
• Traders de firmas propietarias que necesitan mantener la ejecución en una sola máquina para evitar riesgos de detección por IP en la nube.
• Usuarios de un mismo EA licenciado que operan en varias cuentas personales a la vez.

Puedes revisar los detalles de cada plan en nuestra página de precios y probar la configuración con una prueba gratuita de siete días antes de decidir.

Preguntas frecuentes

¿Qué hace exactamente IsConnected en MT4?

IsConnected() comprueba si el terminal mantiene conexión activa con el servidor del bróker y devuelve true o false según ese estado. No confirma que las series de precios estén sincronizadas, por lo que conviene combinarla con otras verificaciones antes de operar.

¿Por qué no debo usar Sleep() dentro de un asesor experto?

Sleep() detiene la ejecución completa del programa durante el tiempo indicado y puede bloquear la cola de eventos del terminal mientras dura la pausa. OnTimer cumple la misma función de forma periódica sin frenar la reacción del EA a nuevos ticks.

¿Cada cuánto debería reintentar la reconexión mi EA?

No existe un intervalo universal porque depende de la estabilidad de cada bróker, pero un patrón habitual empieza con pausas cortas de unos cinco segundos y las va duplicando hasta un máximo de alrededor de un minuto. Superado un número razonable de intentos conviene detener los reintentos automáticos y generar una alerta.

¿Sirve RefreshRates para solucionar errores de conexión?

RefreshRates() actualiza las variables y series de precios del EA, pero no restablece la conexión por sí sola: su utilidad está en forzar datos actualizados justo después de que la conexión ya se haya recuperado.

¿Una herramienta local como la que ofrecemos sustituye la lógica de reconexión de un EA?

No sustituye la vigilancia de conexión propia de cada asesor experto, pero sí resuelve un problema distinto: mantener sincronizadas varias cuentas MT4, MT5 o DXTrade desde una sola máquina local sin depender de servidores externos. Conviene evaluarla cuando el reto no es un solo EA desconectado, sino coordinar operaciones entre varias cuentas a la vez.

Fuentes

• IsConnected – Checkup – MQL4 Reference
• Server – Client Terminal Settings – Guía de ayuda de MetaTrader 4

Recomendaciones

• Configuración de Copia Inversa de Operaciones: Una Guía Práctica para MetaTrader
• Dimensionamiento automático de lote en MT4: Fórmula, configuración y pasos de seguridad
• Detener operaciones duplicadas en MT4 en 5 minutos para usuarios y autores de EA
• Cómo configurar un copiador de Asesor Experto MT4