El pool se cayó: cómo saber que el problema no está en tu ASIC y qué hacer en la primera hora

*Last updated: 09.09.2026. POOL BTC.*

TL;DR

Cuando el hashrate en el panel del pool cae a cero, la culpa no siempre es del pool. En la mayoría de los casos la causa está entre tu ASIC y el servidor stratum: el router, el proveedor de internet, la alimentación, una placa recalentada, un firmware recién instalado. Distinguir una cosa de la otra se puede hacer en cinco minutos sin levantarse del portátil: mirar qué muestra el propio minero, comprobar si el pool está caído para otros mineros y comparar el hashrate local con el del pool. La primera hora conviene gastarla no en el pánico ni en cambiar de pool, sino en un diagnóstico ordenado y en activar el stratum de respaldo que debería haber estado en la configuración desde antes.

POOL BTC no es un pool, sino un sitio independiente de comparación de pools. Aquí no le atribuimos caídas a ningún pool concreto: abajo hay un método, no el análisis de la avería de nadie.

¿Cómo distinguir una caída del pool de un problema en tu propio lado?

La señal principal de una caída del pool: el minero funciona, el hashrate en el equipo es normal, pero la conexión con el stratum se corta o los shares se van sin respuesta. Si en cambio en el panel del propio ASIC el hashrate ha bajado, se han caído chips o el equipo se reinicia en bucle, el pool no tiene nada que ver: el problema está en el hardware, en la alimentación o en la red hasta el proveedor.

Vamos por síntomas. Hay que mirar dos sitios a la vez: el panel del minero (hashrate local) y las estadísticas de la cuenta en el pool (hashrate del pool).

Hay un caso aparte que se confunde con una caída del pool más que ningún otro: la configuración recién hecha. Si el hashrate nunca llegó a aparecer en el pool, no es una avería, es una errata en el nombre del worker o un puerto cerrado. Una avería se ve distinta: funcionó durante días y dejó de funcionar de golpe.

¿Qué muestra el panel del minero cuando se corta la conexión y qué significan accepted, rejected y stale?

En el panel del ASIC hay tres contadores por cada pool: accepted (shares aceptados), rejected (rechazados), stale (llegaron tarde, el trabajo ya no vale). Cuando se corta la conexión con el stratum, el estado del pool cambia a dead o disconnected, el contador de accepted se congela y el minero empieza a intentar conectarse al siguiente pool de la lista, si es que hay alguno.

Qué hay detrás de cada palabra:

• Accepted. El pool aceptó tu share y lo contó en las estadísticas. Es el único contador que se convierte en dinero.
• Rejected. El pool recibió el share pero no lo contó. Las causas varían: el trabajo caducó, es un duplicado, la dificultad es demasiado baja, hubo un error de autorización.
• Stale. Un caso concreto de rechazo: el share se calculó para un trabajo que el pool ya había cancelado porque en la red se encontró un bloque nuevo. Cuanto mayor es la latencia hasta el servidor, más a menudo pasa.
• Difficulty accepted. En algunos firmwares aparece en una línea aparte la suma de dificultad de los shares aceptados. Es más informativa que el contador de unidades, porque con vardiff la cantidad de shares por sí sola no dice nada.

Otra línea que conviene mirar: el tiempo del último share aceptado (last share). Si crece y ya pasa de varios minutos con el hashrate estable, la conexión está muerta de hecho, aunque el estado del pool siga en verde.

La mecánica de los shares y por qué su cantidad no equivale a los ingresos está explicada con más detalle en el artículo sobre los esquemas de pago FPPS y PPLNS.

¿Qué porcentaje de rechazos se considera normal y cuál ya es una señal?

No hay una cifra universal: la proporción de shares rechazados depende de la distancia hasta el servidor stratum, de la calidad del canal, del firmware y de los ajustes de vardiff. Hay que guiarse no por el valor absoluto, sino por tu propia línea base: anota tu porcentaje habitual en un día tranquilo y considera desviación todo lo que se aleje notablemente hacia arriba y se mantenga.

Un enfoque práctico en lugar de una cifra mágica:

1. Toma la proporción de rejected durante un día de funcionamiento normal. Ese es tu cero.
2. No sigas el valor instantáneo, sino la media de una hora. Los picos puntuales al cambiar de bloque son normales, no una avería.
3. Que la proporción suba sin que cambie el hashrate local significa un problema con el canal o con el pool, no con el hardware.
4. Que la proporción suba a la vez que baja el hashrate local significa hardware.

Tres pools dan sus propias referencias, y se contradicen entre sí más que los mineros que discuten en los chats. AntPool escribe en su centro de ayuda que se considera normal una proporción de rechazados por debajo del 1 por ciento y de shares obsoletos en torno al 0,5 por ciento o menos. ViaBTC llama rango normal a los rechazos dentro del 3 por ciento. F2Pool considera razonable una proporción de shares retrasados de alrededor del 2 por ciento. Esa dispersión del 0,5 al 3 por ciento entre tres pools grandes es la respuesta a la pregunta sobre la norma: no existe una norma común, existen los ajustes de un pool concreto.

Una salvedad sobre la fuente: las páginas de soporte de estos pools están cerradas a la comprobación automática, y las formulaciones de arriba las registramos a partir de sus fragmentos públicos de búsqueda, no del texto completo de las páginas. Antes de apoyarte en una cifra concreta, abre el centro de ayuda de tu pool y verifica la redacción actual.

El umbral a partir del cual las pérdidas se vuelven perceptibles no lo publica nadie, y no hace falta inventarlo: la mecánica se calcula de cabeza. Un share rechazado no se paga, así que la proporción de rechazos equivale más o menos a la proporción de ingresos que dejas de recibir. Un uno por ciento de rechazos es aproximadamente un uno por ciento de ingresos que se va por el desagüe, un tres por ciento son tres. Si merece la pena reconfigurar la granja por eso depende de su tamaño, no de la recomendación de otro.

Lo que seguro que no es normal y no necesita estadísticas: una proporción de rechazados cercana al cien por cien. Eso casi siempre es una dificultad incorrecta, un firmware corrupto o un intermediario bloqueando la conexión, no una saturación del pool.

¿Dónde mirar para confirmar una caída del pool?

Confirmar una caída siempre es una segunda fuente independiente. Con tu panel solo no basta: muestra igual una avería del pool que un corte en tu proveedor. El orden de comprobación, del más rápido al más lento, lleva unos cinco minutos y casi siempre da una respuesta clara.

1. Las estadísticas de hashrate de la cuenta en el pool. Si el panel web abre y muestra cero para tu worker, el servidor está vivo y lo que no llega hasta él son precisamente tus shares. Si el panel no carga en absoluto, el problema es más amplio.
2. La página de estado del pool. Una parte de los pools tiene una página aparte con el estado de los servicios. Su dirección conviene encontrarla de antemano y tenerla en marcadores, no buscarla en plena avería.
3. Monitores y exploradores de terceros. Los observadores públicos de la distribución del hashrate muestran si el pool está encontrando bloques ahora mismo. Una pausa larga en un pool grande es una señal indirecta, pero fuerte.
4. Redes sociales y chats del pool. La cuenta oficial y el canal de Telegram suelen enterarse de la avería antes de que se actualice la página de estado. Ahí también se ve si otros mineros se están quejando.
5. Comprobación de la ruta desde tu lado. Un simple telnet o nc a la dirección y el puerto del stratum desde cualquier ordenador de la misma red separa una caída del pool de un bloqueo del proveedor en diez segundos.

Si el panel del pool abre, se encuentran bloques, en el chat hay silencio y tus shares no se aceptan, entonces la avería es tuya, no del pool.

¿Para qué sirve un backup pool y cómo configurar bien el stratum de respaldo?

El pool de respaldo es una línea en la configuración del minero a la que el equipo cambia por sí solo cuando el stratum principal no responde. Sin ella, el ASIC al perder la conexión simplemente hace girar los ventiladores y no gana nada hasta que tú intervienes. Con ella, la parada se reduce al tiempo de reconexión, que se mide en segundos y no en las horas que tú duermes.

Cómo se ve en la configuración. Los firmwares se diferencian en los detalles, pero el principio es el mismo: una lista de pools por prioridad, el minero va de arriba abajo.

\`\`\`

pool1: stratum+tcp://[DIRECCIÓN DEL POOL PRINCIPAL]:[PUERTO] worker: cuenta.worker

pool2: stratum+tcp://[DIRECCIÓN DEL POOL DE RESPALDO]:[PUERTO] worker: cuenta2.worker

pool3: stratum+tcp://[DIRECCIÓN DEL TERCER POOL]:[PUERTO] worker: cuenta3.worker

\`\`\`

Reglas sin las cuales el respaldo no va a funcionar:

1. El segundo pool es otro pool, no otro puerto del mismo. Una dirección de respaldo dentro de la misma infraestructura no te salva de que se caiga esa infraestructura. El puerto alternativo del pool principal ponlo en la tercera línea, no en la segunda.
2. La cuenta en el pool de respaldo debe estar creada y comprobada de antemano. Registrarse en plena avería se come justamente esa primera hora.
3. La dirección de pago en el pool de respaldo debe estar rellenada. Si no, lo minado se quedará colgado en un saldo al que volverás dentro de un mes.
4. Comprueba el cambio a mano. Desactiva el pool principal en la interfaz un par de minutos y asegúrate de que los shares se fueron al de respaldo y de que, al volver, el minero regresó al principal.
5. Ten en cuenta el esquema de pago. Mudarse de ida y vuelta entre pools PPLNS pone a cero la acumulación en la ventana dos veces, así que como respaldo es más razonable poner un pool con un esquema más simple. La diferencia de mecánicas está explicada en la comparación de FPPS y PPLNS.

El número de puntos de entrada disponibles varía entre pools, y se ve en su propia documentación. Contamos los hosts stratum únicos para BTC en las páginas de conexión de seis pools.

Aquí lo importante no es que un pool tenga ocho hosts y otro uno. Lo importante es que todas esas direcciones llevan a una misma infraestructura: salvan de la caída de una región, pero no de la caída del pool. Justo por eso la segunda línea de la configuración debe apuntar hacia fuera.

¿Cuánto dinero pierde realmente un minero por cada hora de parada y cómo calcularlo uno mismo?

La pérdida por una hora de parada se calcula en una línea: los ingresos diarios de tu equipo, divididos entre 24, multiplicados por la fracción de parada. Aquí no hacen falta modelos complicados, porque los ingresos en el pool son lineales respecto al hashrate. Lo único importante es tomar el hashprice actual y no una cifra de un artículo de hace medio año, porque si no el error será de varias veces.

La fórmula:

\`\`\`

pérdida = (hashrate en TH/s × hashprice en USD por TH/s al día) / 24 × horas de parada

\`\`\`

El hashprice son los ingresos por un terahash al día antes de descontar la electricidad. Cambia cada día junto con la cotización y la dificultad, así que sustituye siempre el valor más reciente.

El hashprice no lo fijamos en el texto con una cifra a propósito. Cambia cada día junto con la cotización y la dificultad, y un valor de un artículo de hace un mes da un error de varias veces, no de un porcentaje. Sustituye el valor fresco del día del cálculo: lo muestran los índices públicos de hashprice y nuestra calculadora.

Qué es importante no olvidar al calcular:

• La electricidad durante la parada se gasta en parte. Si el minero está encendido pero no puede enviar shares, igualmente consume. La pérdida real por hora es mayor que los ingresos netos no obtenidos, en el coste de ese consumo.
• PPLNS castiga la parada dos veces. En los esquemas acumulativos no solo no ganaste durante esa hora, sino que además perdiste posición en la ventana, y eso no se recupera al instante. En los esquemas tipo PPS la pérdida es exactamente igual a la fórmula.
• Calcula por toda la granja, no por una sola máquina. Una hora de parada de diez equipos cuesta diez veces más, y con esa cifra la decisión sobre el pool de respaldo se toma sola.

Calcular los ingresos para tu hashrate y los parámetros actuales de la red es más cómodo en la calculadora que de cabeza.

Qué hacer en la primera hora: lista de comprobación paso a paso

1. Minutos 0-2. Mira el hashrate local en el panel del minero. Si bajó junto con el del pool, es hardware, y no hace falta seguir con esta lista.
2. Minutos 2-5. Comprueba el estado de los pools y el tiempo del último share aceptado. El estado dead y un tiempo que crece confirman el corte de conexión.
3. Minutos 5-10. Abre el panel del pool y la página de estado. Si no abre nada, incluidas otras webs, entonces la cosa está en tu canal.
4. Minutos 10-15. Comprueba el acceso al stratum desde otro dispositivo de la misma red y después desde internet móvil. La diferencia en el resultado señala al proveedor o al router.
5. Minutos 15-20. Asómate al chat y a las redes sociales del pool. Quejas masivas en los últimos minutos cierran la cuestión.
6. Minutos 20-30. Asegúrate de que el respaldo entró en juego. Si no hay pool de respaldo en la configuración, escríbelo ahora: es la única acción que ahora mismo devuelve ingresos.
7. Minutos 30-45. No toques nada más. Un reinicio masivo de la granja, un reflasheo y un cambio de dificultad durante la avería de otro te añaden una segunda avería encima de la primera.
8. Minutos 45-60. Deja constancia de los hechos. Hora de inicio, captura del panel, hora del último share, respuesta del pool. Sin eso, la conversación sobre una compensación se convierte en una discusión sobre la memoria.

¿Cuándo una parada es motivo para cambiar de pool y cuándo no?

Una avería no es motivo de mudanza. La infraestructura se cae en todas partes, y el coste de cambiar de pool a menudo supera la pérdida de unas pocas horas de parada. El motivo aparece cuando las paradas se repiten, duran mucho y no van acompañadas de una comunicación clara: el silencio del pool durante una avería sale más caro que la avería misma.

Antes de mudarte calcula el precio de la mudanza misma: la puesta a cero de la ventana en PPLNS, la espera hasta el nuevo umbral de pago, el tiempo de reconfiguración. Si te inclinas por el minado SOLO como forma de dejar de depender de la infraestructura ajena, mira primero la comparación de SOLO y pool: ahí esa misma dependencia solo cambia de forma.

¿Por qué casi ningún pool publica su uptime y cómo evaluar la fiabilidad de forma indirecta?

Una página pública de uptime es un compromiso que no interesa asumir: cualquier cifra se convertirá en motivo de reclamaciones y comparaciones, y para medirla con honestidad hay que hacerlo desde fuera. Por eso la mayoría de los pools se limita a las estadísticas de bloques encontrados y de hashrate. La fiabilidad hay que evaluarla de forma indirecta, por señales observables y no por porcentajes declarados.

Qué mirar cuando no hay cifra de uptime:

• La regularidad de los bloques encontrados. En un pool grande las pausas son previsibles según su cuota en la red. Un silencio anormalmente largo se ve en cualquier explorador público.
• La existencia de una página de estado y de un historial de incidentes. El simple hecho de que un pool mantenga un registro público de fallos dice más que una cifra bonita de 99,9.
• La rapidez y el contenido de la comunicación. Un mensaje en el chat en los primeros minutos de la avería vale más que una publicación de disculpa al día siguiente.
• La cantidad de puntos de entrada independientes. Regiones distintas, direcciones stratum distintas, soporte de varios puertos. Eso reduce la probabilidad de que pierdas la conexión por completo.
• Las opiniones de los mineros sobre fallos pasados. No sobre si hubo fallos, sino sobre si las estadísticas cuadraron después de ellos.

Revisamos los materiales públicos de ocho pools el 09.09.2026. Una página de estado completa con historial de incidentes y cifras de uptime la encontramos en uno: Luxor la publica en uptime.luxor.tech, con desglose por servicios (interfaz del pool 99,766 por ciento, procesamiento de estadísticas 99,956 por ciento, parte de los servicios 100 por ciento) y con un registro de tres meses. Foundry tiene status.foundry.ac, pero es el estado de los servicios corporativos de Foundry Digital y no una página aparte del pool de minería. F2Pool mantiene una sección de anuncios con publicaciones sobre incidentes, pero eso no es una página de estado. En ViaBTC la cifra del 99,99 por ciento aparece en materiales de marketing, y la página donde poder verificarla no la encontramos. En AntPool, Braiins Pool, Binance Pool y Ocean no se detectó por búsqueda ninguna página pública de estado. Esto último significa exactamente «no encontrado dentro de esta revisión» y no una ausencia garantizada.

Revisión de las páginas públicas de los pools, 09.09.2026.

Los parámetros resumidos de los pools, incluidos los esquemas de pago, las comisiones y los umbrales, están recogidos en las fichas de pools. Datos de uptime allí no hay, exactamente por el motivo de arriba: no hay nada que comparar mientras los pools no lo publiquen.

En resumen

El pool se cae menos a menudo de lo que parece en el primer minuto. El orden de actuación es siempre el mismo: primero separar tu hardware del servidor ajeno, después confirmar la parada con una segunda fuente, después asegurarte de que el stratum de respaldo asumió la carga. Un pool de respaldo en la configuración cuesta cero y ahorra horas de ingresos, y hay que escribirlo en un día tranquilo, no en uno de avería.