Empieza por confirmar qué fue lo que realmente se reinició
Un minero que parece reiniciarse repetidamente no siempre está sufriendo un reinicio completo del dispositivo. Varios eventos distintos pueden parecer similares a simple vista, y confundirlos lleva a desperdiciar esfuerzo de reparación:
- Un reinicio completo del dispositivo — la placa de control se reinicia, el tiempo de actividad del sistema vuelve a cero, y el registro muestra una nueva secuencia de arranque.
- Un evento de recuperación de una placa de hash o del proceso de minería — el dispositivo permanece accesible a través de su interfaz web mientras una placa, o el propio proceso de minería, se reinicia bajo el control del firmware.
- Una interrupción de la conexión al pool — el minero pierde su sesión Stratum y aparece como desconectado en el panel del pool, sin ningún cambio en el tiempo de actividad local.
- Un retraso en el informe después del arranque — un worker recién iniciado aún no ha enviado suficientes datos de shares para que el pool lo marque como activo.
El primer paso de diagnóstico es abrir la propia interfaz web del minero (o SSH/API si está disponible) y comprobar el tiempo de actividad del sistema directamente en el dispositivo, en lugar de confiar en una etiqueta del panel del pool. La documentación de soporte de ViaBTC señala que un worker puede mostrarse como Offline o Inactive por razones no relacionadas con un reinicio de hardware, incluyendo errores de configuración, inestabilidad de red, o un dispositivo que aún está inactivo tras un evento de energía y que todavía no ha enviado datos al pool (Centro de Ayuda de ViaBTC). Si el worker acaba de iniciarse, la documentación de ViaBTC sugiere esperar aproximadamente entre 10 y 20 minutos antes de tratar la etiqueta Offline como un fallo, ya que el retraso exacto depende del hashrate del minero y de la tasa de envío de shares.
Esta distinción importa porque el siguiente paso correcto difiere notablemente según cuál evento ocurrió realmente. Un tiempo de actividad reiniciado en la placa de control apunta hacia causas de energía, térmicas o de firmware. Un tiempo de actividad local estable con un worker desconectado del pool apunta, en cambio, hacia causas de red o de configuración del pool.
Preserva el registro antes de volver a reiniciar
Una vez confirmada una interrupción, resiste el instinto de apagar y encender la unidad inmediatamente. La documentación de soporte de BITMAIN recomienda revisar el registro del minero antes de reiniciar, ya que la secuencia de eventos que condujo al fallo suele ser la evidencia de diagnóstico más útil disponible, y se pierde en cuanto el dispositivo se reinicia de nuevo (Soporte de BITMAIN).
Antes de volver a conectar la energía, registra:
- El texto exacto del error y la marca de tiempo.
- Qué placa de hash, si alguna, se vio afectada.
- Las lecturas de temperatura y velocidad del ventilador en el momento del evento.
- Cualquier mensaje relacionado con la energía (alarmas de voltaje, fallos de la fuente de alimentación, avisos de pérdida de energía).
Una única entrada de registro, como una alarma de alta temperatura, un mensaje de chip faltante, o un aviso de pérdida de energía, apunta hacia una ruta de reparación distinta que un reinicio inexplicado sin mensaje previo. Reiniciar manualmente de forma repetida sin revisar esta información puede ocultar el desencadenante original y dificultar la reproducción o el diagnóstico del fallo.
Trabaja las causas en un orden consistente
La mayoría de los reinicios recurrentes de ASIC se remontan a un pequeño conjunto de categorías de fallos. La documentación de solución de problemas de BITMAIN para dispositivos ANTMINER las organiza en protección contra sobretemperatura, fallos de ventilador o sensor, problemas de la fuente de alimentación, fallos de la placa de hash o de la placa de control, problemas de firmware y fallos de red (Soporte de BITMAIN). Repasarlas en un orden consistente evita sustituir un componente antes de descartar una causa más sencilla.
1. Protección contra sobretemperatura
Comprueba si hay mensajes de sobretemperatura en el registro, un aumento de la temperatura de entrada o salida de aire, y señales de mal flujo de aire, como acumulación de polvo o recirculación del aire de salida de vuelta hacia la entrada. Los rangos de temperatura de funcionamiento recomendados por el fabricante varían según el modelo; la documentación de BITMAIN para la serie ANTMINER 19 cita un entorno operativo recomendado de aproximadamente 5–35 °C, pero los lectores deben confirmar el rango aplicable a su modelo específico en el manual del fabricante en lugar de asumir que esta cifra se aplica universalmente (Soporte de BITMAIN).
2. Fallos del ventilador o del sensor de temperatura
Un error de pérdida de ventilador, una lectura de RPM inusualmente baja o un sensor de temperatura ilegible pueden desencadenar el mismo comportamiento de parada o reinicio de protección que un sobrecalentamiento real, incluso en un entorno correctamente ventilado. Revise primero el cable y el conector del ventilador, ya que una conexión floja es una causa común y fácil de verificar antes de asumir que el propio ventilador ha fallado.
3. Problemas de la fuente de alimentación, cables o conectores
Busque alarmas de voltaje, mensajes de fallo de la PSU o un reinicio que coincida con el momento en que el equipo de minado alcanza la carga máxima. Cables de alimentación flojos, un conector desgastado o un circuito infradimensionado aguas arriba de la PSU pueden producir reinicios intermitentes que se asemejan a un fallo de hardware. Los problemas eléctricos más allá del propio cableado del equipo deben ser revisados por un electricista cualificado cuando el circuito o el cableado de las instalaciones estén en duda.
4. Fallos de la placa de hash o de la placa de control
Una placa ausente, chips ASIC no detectados durante la enumeración o respuestas de nonce anómalas de una placa apuntan a un problema de hardware a nivel de placa más que a uno de software. Reiniciar repetidamente un equipo de minado en este estado no constituye una reparación; puede enmascarar un fallo que empeora con el tiempo.
5. Inestabilidad del firmware o del ajuste (tuning)
Si los reinicios comenzaron inmediatamente después de una actualización de firmware o de un cambio en la frecuencia, el voltaje o los ajustes de autotuning, la nueva configuración en sí misma puede ser la causa. Revierta únicamente mediante el procedimiento de recuperación documentado por el fabricante o el proveedor del firmware, y cambie un ajuste a la vez para poder identificar el origen de la inestabilidad.
6. Problemas de red o de conexión al pool
Si el tiempo de actividad local nunca se reinicia pero el pool muestra el worker como desconectado, revise la conexión Ethernet, la estabilidad del router o el switch, la configuración de DNS y puerta de enlace, y la URL del pool, el puerto y el nombre del worker configurados. Esta es la categoría en la que un equipo de minado puede parecer "reiniciarse" desde la perspectiva del pool sin que exista ningún evento de hardware subyacente.
7. Reinicios intencionados o impulsados por políticas
Una actualización de firmware programada, una orden de reducción de carga (curtailment) o una política de gestión de flota pueden reiniciar un equipo de minado de forma deliberada. Revise el historial de eventos del firmware y de las herramientas de gestión antes de asumir un fallo de hardware, en particular en operaciones que utilicen sistemas de monitorización remota o de reducción automática de potencia.
Separar la recuperación a nivel de firmware de un reinicio completo
El firmware de minería moderno distingue cada vez más entre un reinicio completo del dispositivo y una acción de recuperación más pequeña y específica. Algunos firmwares pueden pausar o reiniciar una sola placa de hash tras un evento de alta temperatura mientras el resto del equipo de minado continúa reportando, en lugar de reiniciar toda la placa de control. Tratar cada uno de estos eventos como un reinicio completo inexplicado puede llevar a un reemplazo de hardware innecesario cuando el propio mensaje de recuperación del firmware ya identifica la causa y el alcance de la interrupción. Cuando esté disponible, consulte el estado reportado por el firmware o el código de motivo antes de escalar a una investigación de hardware.
Uso de la página de Workers del pool como ayuda de diagnóstico
Un panel del pool no puede confirmar si un dispositivo se reinició físicamente, pero puede ayudar a acotar si una interrupción está relacionada con la conexión. En la página de Workers de ViaBTC, un worker que se desconecta y se reconecta repetidamente, sin ningún cambio en el tiempo de actividad propio del equipo de minado, apunta hacia la categoría de red y conexión al pool en lugar de a un fallo de hardware. La documentación de configuración de minería de ViaBTC también recomienda configurar un punto de conexión de respaldo para que el equipo de minado pueda cambiar automáticamente si su conexión principal deja de estar disponible (Centro de Ayuda de ViaBTC). Esto reduce específicamente la interrupción causada por un fallo en la ruta de conexión; no aborda los fallos de la PSU, térmicos, del ventilador o de la placa de hash, que requieren las comprobaciones centradas en el hardware descritas anteriormente.
También vale la pena señalar, como contexto, que el objetivo de share de un pool es intencionalmente más fácil de alcanzar que el objetivo de bloque de la red Bitcoin, razón por la cual los mineros pueden enviar shares con frecuencia como prueba de trabajo a nivel de pool entre los escasos bloques que sí cumplen el objetivo completo de la red (Bitcoin Developer Guide). Una tasa de envío de shares fluctuante durante una interrupción de la conexión refleja esta capa de contabilidad del pool y no debe interpretarse como una medición del estado eléctrico o térmico del minero.
Cuándo escalar en lugar de volver a reiniciar
Deje de intentar más reinicios manuales y recurra a los canales de reparación aprobados por el fabricante cuando el registro muestre alguno de los siguientes casos:
- Señales de un posible cortocircuito.
- Detección parcial de chips ASIC que persiste a través de múltiples reinicios.
- Activación repetida de la protección térmica a pesar de contar con un flujo de aire y una temperatura ambiente adecuados confirmados.
- Daño físico en una placa, conector o cable.
Las implementaciones en climas fríos conllevan una precaución adicional: la guía de reinicio de BITMAIN recomienda no reiniciar un minero en temperaturas ambiente inferiores a -20 °C, ya que las temperaturas muy bajas pueden afectar el comportamiento de los componentes durante el arranque. Esta indicación es específica para el escenario de clima frío citado y no debe generalizarse a todos los modelos ASIC ni a todas las condiciones de operación.
Preguntas frecuentes
Mi minero aparece como Offline en el panel del pool, pero su tiempo de actividad local no se ha reiniciado. ¿Qué significa esto?
Esto apunta a un problema de red o de conexión con el pool, en lugar de a un reinicio del dispositivo. Verifique la conexión Ethernet, la estabilidad del router y la dirección de pool y el nombre del worker configurados antes de investigar causas relacionadas con el hardware.
¿Es seguro simplemente seguir reiniciando el minero hasta que permanezca en línea?
Los reinicios repetidos sin revisar la entrada de registro previa pueden ocultar la causa subyacente y, en casos que involucren detección parcial de chips o sospecha de cortocircuitos, pueden aumentar el riesgo de daños adicionales. Registre primero los detalles del log y luego aborde la categoría específica de fallo que indiquen.
¿Cuánto tiempo debo esperar antes de considerar un worker recién iniciado como un problema?
La documentación de ViaBTC sugiere dejar aproximadamente entre 10 y 20 minutos para que un worker nuevo comience a enviar datos de shares, y por separado recomienda verificar el estado de operación y las ganancias después de unos 10-15 minutos una vez que el minero se haya estabilizado. Estas son ventanas de observación para los informes del pool, no umbrales de diagnóstico para la salud del hardware.
¿Puede una actualización de firmware provocar reinicios por diseño?
Sí. Las actualizaciones de firmware programadas y ciertas políticas automatizadas de recuperación o reducción de carga pueden reiniciar intencionalmente un minero o una sola hashboard. Revisar el historial de eventos del firmware y de las herramientas de gestión puede descartar esta causa antes de asumir un fallo de hardware.
¿Puedo estimar la eficiencia energética de mi minero a partir de los datos de hashrate reportados por el pool?
No. El hashrate reportado por el pool es una estimación basada en shares dentro de la propia ventana de medición del pool, no una medición eléctrica directa, y no debe combinarse con cifras de consumo de energía para calcular la eficiencia del hardware.