Un ASIC que aparece desconectado después de una interrupción de red necesita una revisión de la conexión, no un restablecimiento de fábrica inmediato. Separa tres preguntas: ¿puedes acceder al equipo desde la red local, establecer la sesión prevista con el pool y observar trabajo aceptado reciente de ese worker? Son comprobaciones distintas, no un único indicador verde o rojo.
Esta guía trata la recuperación de la conexión, no reparaciones eléctricas, instalación de firmware ni ajuste del hashrate. La secuencia siguiente es una lista editorial para gestionar incidencias: adáptala a tu red, firmware y documentación del pool. La portada utiliza una fotografía de producto aprobada como ilustración, no como evidencia de una prueba de campo.
1. Delimita la incidencia antes de cambiar ajustes
Anota cuándo empezó la interrupción, la zona horaria, el último estado correcto conocido y qué cambió. Elige un equipo afectado y, si existe, otro sin problemas para comparar. Conserva sus identificadores de activo en privado para asociar cada captura y observación al dispositivo correcto.
Comprueba si el problema afecta a una unidad, un rack o toda la instalación. Esto ayuda a elegir la siguiente investigación, pero no demuestra una causa. Una caída de todo un rack justifica revisar su ruta compartida antes de restablecer equipos individuales. Una única unidad afectada también requiere revisar su conexión local antes de concluir que su controladora está averiada.
| Observación | Primera comparación | Qué sigue sin demostrarse |
|---|---|---|
| Desaparece un minero | Su dirección registrada y conexión local frente a un vecino operativo | Una avería del hardware |
| Desaparece un rack completo | Su ruta de red frente a otro rack operativo | Que todos los mineros necesiten reconfiguración |
| Abren las páginas locales, pero no se recuperan los workers | Destino del pool previsto y evidencia de conexión | Que navegar por Internet equivalga a minar correctamente |
| La actividad vuelve de forma intermitente | Eventos con hora antes y después de cada cambio controlado | Una reparación permanente por una sola actualización correcta |
Mantén una cronología breve. Evita cambiar a la vez el router, la dirección del pool y el firmware: aunque vuelva la actividad, esa combinación deja incierta la causa real.
2. Confirma el acceso local
La guía de red de BITMAIN incluye la disponibilidad de DHCP y la capacidad del conjunto de direcciones entre las comprobaciones cuando un minero no obtiene IP. También distingue una IP asignada del acceso correcto al pool. Son puntos de partida, no un diagnóstico universal para cualquier modelo o red. Diagnóstico de red de BITMAIN.
En la ficha de la incidencia, marca la dirección registrada como confirmada, modificada o todavía desconocida. Pide al administrador de red que la contraste con la concesión actual y el registro del activo. Un marcador del navegador solo documenta una dirección anterior; una página vacía en ese marcador no constituye un diagnóstico completo.
Compara las observaciones locales antes de introducir cambios. Las decisiones sobre políticas de red deben quedar en manos del responsable de la instalación. Esta lista no requiere exponer la administración del minero a Internet, abrir puertos entrantes del router ni retirar controles de acceso generales. Conserva la configuración actual antes de cualquier ajuste aprobado.
3. Revisa la configuración prevista del pool
Consulta las instrucciones actuales para el pool y el algoritmo concretos. Evita copiar de memoria un servidor o puerto de otra guía, moneda, servicio o firmware.
La sección de conexión de Braiins Pool destaca la escritura del usuario, los espacios sobrantes, la URL correcta y las restricciones de puertos. Sus pruebas de ejemplo comprueban accesibilidad del servidor, no ingresos de minería. Esas instrucciones corresponden a Braiins Pool, no a todos los servicios. Preguntas sobre conexión de Braiins.
Compara en privado el destino configurado con las instrucciones actuales del pool. Anota si coinciden sin publicar credenciales en una consulta técnica abierta. Si el administrador prueba la ruta desde un portátil, registra también ese dispositivo y su ubicación de red. Una comprobación realizada en otro lugar no debe presentarse como si se hubiera ejecutado desde el propio minero.
Para equipos que ya utilizan Braiins OS, su documentación señala los problemas de DNS como una posible causa de que los destinos aparezcan inactivos y recuerda que los puertos varían entre pools. Sigue la documentación del firmware instalado; esto no justifica instalar otro firmware durante una interrupción todavía sin diagnosticar. Resolución de problemas de Braiins OS.
4. Introduce un único cambio controlado cada vez
Elige la comparación útil más pequeña. Registra el cambio propuesto, su responsable, el valor original y cómo se restaurará si no ayuda. Decide antes de empezar qué observación contaría como mejora.
Por ejemplo, el operador podría investigar si los equipos afectados comparten una ruta de red. Es una comparación diagnóstica propuesta, no una afirmación de que un switch o proveedor concreto haya fallado. Mantén los equipos operativos ajenos al problema fuera de la prueba, salvo que el responsable los incluya deliberadamente.
Después de cada cambio, anota el resultado y la hora. Si persiste el síntoma, evita acumular ajustes especulativos sobre el primero. Vuelve al registro y decide si corresponde restaurar la configuración original o escalar la incidencia con las pruebas reunidas.
Un cambio de firmware pertenece a un procedimiento distinto y específico del modelo. Consulta nuestra lista para descargar firmware de Antminer si existen indicios independientes que justifiquen esa intervención; la interrupción por sí sola no es esa evidencia.
5. Verifica la recuperación por worker
La etiqueta de desconectado necesita contexto. Braiins explica que su monitorización observa hashrate en lugar de vigilar directamente la conexión de red del dispositivo, y que varios equipos con el mismo worker aportan estadísticas combinadas. Revisa el sistema que realmente utilizas antes de interpretar su etiqueta. Documentación de monitorización de Braiins.
Para tu registro de aceptación, reúne evidencia reciente del minero y de la cuenta del pool prevista. Identifica el worker, la hora de observación y si continúa apareciendo actividad de trabajo aceptado. Una captura anterior al incidente no verifica la recuperación. Si los workers están agrupados, indícalo en lugar de atribuir la recuperación de una unidad al total del grupo.
Explicita el intervalo observado. Esta guía no fija una espera única que demuestre la recuperación de cualquier equipo y pool. Para comparar las cifras de rendimiento, consulta hashrate del minero frente al del pool; esa pregunta es distinta de establecer la conexión.
6. Cierra o escala con un registro útil
| Registro | Qué incluir |
|---|---|
| Alcance de la incidencia | Inicio, zona horaria y grupo de activos afectados |
| Acceso local | Estado confirmado de la dirección y lugar de la comprobación |
| Ruta al pool | Nombre del pool, destino previsto y resultado de la prueba pertinente |
| Historial de cambios | Un cambio por entrada, ajuste original, resultado y decisión de reversión |
| Evidencia de recuperación | Identidad del worker, actividad reciente e intervalo observado |
| Punto pendiente | Comprobación concreta sin resolver y próximo responsable |
Mantén contraseñas y detalles sensibles de la red en el canal privado de soporte adecuado. Nuestra lista para exportar y ocultar datos en registros de Antminer aborda la tarea separada de preparar un archivo diagnóstico.
¿Necesitas organizar una consulta sobre mineros o alojamiento? Contacta con LeedMiner indicando modelo, versión de firmware y un resumen breve del incidente. Evita enviar secretos de la cartera o contraseñas de cuentas. Un registro claro ayuda a dirigir la consulta; no garantiza resolver a distancia una avería de red.
