Lire les Statistiques de Vos Workers — Diagnostiquer Faible Hashrate, Taux de Rejet Élevé et Déconnexions Stratum

Votre page de stats worker est l’écran le plus important en solo mining. Elle vous indique si votre hashrate atteint le pool, si les shares sont acceptées, si votre mineur est sain, et à quel point vous êtes proche de trouver un bloc. La lire correctement — et agir sur ce qu’elle dit — fait la différence entre miner 24h/24 avec de bonnes chances et perdre silencieusement de la capacité pendant des semaines sans s’en rendre compte.

Ce guide parcourt chaque métrique sur la page de stats miner SoloFury, ce à quoi chaque chiffre devrait ressembler, quoi faire quand quelque chose ne va pas, et comment trier les problèmes par symptôme.

1. Où Trouver Vos Stats Worker

SoloFury expose les stats worker en trois endroits, chacun avec des forces différentes :

Dashboard miner en direct à /miner/?addr=<votre_wallet>&coin=<bch|btc|bc2|bch2|xec> Le moyen le plus rapide de voir tous les workers attachés à votre wallet sur un coin spécifique. Se met à jour toutes les ~24 secondes. Affiche hashrate, comptages de shares, meilleure share et santé du worker.

Détail par worker — cliquez sur n’importe quel nom de worker sur le dashboard pour voir l’historique, le graphique de hashrate, et les stats individuelles dans le temps.

Bot Telegram (@SoloFuryBot) — abonnez-vous à votre wallet pour des notifications proactives. Reçoit des messages quand des workers se déconnectent, quand des shares arrêtent d’arriver, et quand vous trouvez un bloc.

2. Les Métriques Fondamentales — Ce Que Signifie Chaque Chiffre

Hashrate

Trois valeurs de hashrate apparaissent sur le dashboard :

Libellé	Signification	Délai typique
1m	Hashrate moyen sur la dernière 1 minute	Temps réel mais bruyant
5m	Hashrate moyen sur les 5 dernières minutes	Stable, meilleur pour “est-ce que ça marche maintenant”
1h	Hashrate moyen sur la dernière 1 heure	Lisse, meilleur pour la tendance long terme

Pour le solo mining, le hashrate 5m est le chiffre unique le plus utile. Le 1m est trop bruyant (la variance est énorme sur de courtes fenêtres), et le 1h prend trop de temps à refléter une panne.

Shares Acceptées

Chaque share valide que votre mineur soumet est comptée. Le nombre qui monte est le signal “tout fonctionne” le plus basique. Un worker montrant zéro shares acceptées pendant plus de 10 minutes est défaillant du point de vue du pool, quelle que soit ce que dit son interface locale.

Shares Rejetées (et Taux de Rejet %)

Les shares rejetées sont des soumissions que le pool a refusées pour l’une de plusieurs raisons :

• La share avait déjà été soumise par un autre mineur (“doublon”)
• Difficulté de la share trop basse pour la cible vardiff actuelle
• Le job stratum a expiré avant que la share n’arrive
• Erreur hardware dans les données de la share

Taux de rejet sain : sous 0,5 %. Acceptable : 0,5-2 %. Problématique : au-dessus de 2 %. Un taux de rejet de 5%+ gaspille du vrai hashrate et nécessite une investigation immédiate.

Shares Périmées

Les stales sont une forme spéciale de share rejetée où votre mineur a soumis du travail basé sur un bloc qui a déjà été miné (le pool est passé à un nouveau modèle de bloc). Un taux élevé de stales signifie que votre mineur reçoit les nouveaux travaux trop lentement — presque toujours un problème de latence réseau.

Taux de stales sain : sous 1 %. Au-dessus de 2 % signifie que vous devriez passer à une région SoloFury plus proche.

Meilleure Share

La share de difficulté la plus haute que vous ayez jamais soumise, divisée par la difficulté réseau. C’est une métrique de vanité et un indicateur de “presque gagné” : une “meilleure share” de 0,5 signifie que vous avez soumis une share à 50 % de la difficulté réseau — proche d’un vrai bloc.

En solo lottery mining, chaque share essaie d’être un bloc. La meilleure share n’est que la plus proche à laquelle vous êtes arrivé jusqu’ici. Une meilleure share élevée ne change pas vos chances futures, mais c’est une façon amusante de suivre votre chance.

Dernière Vue

Quand le pool a reçu une share pour la dernière fois de ce worker. Sain : sous 5 minutes. Préoccupant : au-dessus de 15 minutes. Mort : au-dessus de 1 heure. Si un worker montre “Dernière vue : 6h ago”, vous avez un problème à investiguer.

Ping (Latence vers le Pool)

Temps de round-trip de votre ASIC au serveur stratum du pool. Sous 50ms : excellent. 50-150ms : bon. 150-300ms : utilisable mais sous-optimal. Au-dessus de 300ms : passez à une région plus proche.

Un ping élevé cause directement des shares périmées (votre mineur reçoit les nouveaux travaux trop tard). C’est la principale cause de perte de revenus réparable.

3. Symptôme : Hashrate Faible (Affiché En Dessous du Prévu)

Si votre S21+ devrait afficher 235 TH/s mais que le dashboard SoloFury montre 180 TH/s, quelque chose ne va pas. Triez dans cet ordre :

Étape 1 : L’interface locale de l’ASIC montre-t-elle le même chiffre ?

Connectez-vous à l’interface web de votre ASIC et vérifiez sa propre lecture de hashrate. Si l’interface de l’ASIC montre aussi 180 TH/s, le problème est physique : défaillance de puce, throttling thermique, undervolting, ou problème d’alimentation. Si l’ASIC montre 235 TH/s localement mais seulement 180 TH/s atteignent SoloFury, le problème est réseau ou stratum.

Étape 2 : Causes physiques (l’interface locale de l’ASIC montre aussi une valeur basse)

Cause	Diagnostic	Correction
Défaillance de hashboard	L’interface ASIC montre un ou plusieurs chips à 0 GH/s ou des chaînes en échec	Remplacez le hashboard, contactez la garantie si couverte
Throttling thermique	Température au-dessus de 85°C, ventilateurs à 100 %	Améliorez la ventilation, réduisez la temp ambiante, undervoltez
Undervolting trop agressif	Firmware personnalisé montrant efficacité >18 J/TH mais perte de hashrate	Augmentez la tension, revenez plus près du stock
Alimentation insuffisante	PSU à 100 % de capacité, chutes de tension sous charge	Améliorez le PSU, vérifiez le câblage 220V AWG
Bug firmware	Une mise à jour firmware récente a précédé le problème	Revertissez le firmware vers la version stable précédente

Étape 3 : Causes réseau/stratum (l’interface locale de l’ASIC est correcte, le pool montre une valeur basse)

Cause	Diagnostic	Correction
Déconnexions stratum	Le worker montre des reconnexions dans le log	Voir Section 5 sur les déconnexions
Taux de rejet élevé	Taux de rejet au-dessus de 2 % dans les stats du pool	Voir Section 4 sur les rejets
Taux de stales élevé	Taux de stales au-dessus de 2 %	Passez à la région SoloFury la plus proche
Vardiff non stabilisé	Nouveau worker, hashrate dashboard qui monte lentement	Attendez 30 minutes que vardiff se stabilise

4. Symptôme : Taux de Rejet Élevé

Un taux de rejet au-dessus de 2 % est un problème sérieux. Les causes se divisent en deux catégories :

Rejet lié à la latence (le plus courant)

Votre mineur soumet les shares après que le job stratum a expiré. Causes :

• Ping élevé vers le serveur de pool (au-dessus de 150ms)
• Perte de paquets entre vous et le pool
• Wi-Fi instable (pour les Bitaxe/NerdQAxe en Wi-Fi)

Corrections :

• Passez à la région SoloFury la plus proche (eu-*.solofury.com pour l’Europe, asia-*.solofury.com pour l’Asie)
• Passez de Wi-Fi à Ethernet câblé
• Vérifiez la qualité de la connexion avec ping <coin>.solofury.com et notez le jitter

Rejet lié à la difficulté vardiff

Vardiff ajuste la difficulté des shares pour correspondre au hashrate de votre worker. Si votre worker soumet des shares trop lentement (faible hashrate) ou si vardiff n’a pas eu le temps de s’ajuster, des shares peuvent être rejetées pour difficulté trop basse.

Corrections :

• Attendez 30 minutes que vardiff se stabilise sur un nouveau worker
• Si le hashrate est bien en dessous de la spec, résolvez d’abord le problème de hashrate

Rejet généré par le hardware

Les puces de votre ASIC calculent des shares invalides. Indique du silicium défaillant.

Corrections :

• Inspectez les températures des puces (cherchez les outliers chauds ou froids)
• Réduisez l’undervolting / augmentez la tension
• Remplacez le hashboard concerné si persistant

5. Symptôme : Déconnexions Stratum (Le Worker Garde Se Reconnecter)

Un worker qui continue de tomber et de se reconnecter gaspille quelques secondes de hachage chaque cycle. Les causes sont généralement côté réseau.

Causes communes

Cause	Diagnostic	Correction
TCP keepalive échoue sur FAI flottant	mtr montre >0,5 % de perte de paquets	Utilisez le relay régional HAProxy plus proche (déjà activé sur les endpoints SoloFury EU/Asia)
Maintenance / redémarrage du pool	Plusieurs workers se déconnectent simultanément sur tout le pool	Attendez — la reconnexion automatique devrait intervenir en quelques secondes
Timeout Firewall / NAT	Déconnexion toutes les ~5 minutes précisément	Configurez le routeur pour un TCP keepalive plus long (>10 min), ou fiez-vous à la boucle de reconnexion du mineur
Mauvais câble ethernet ou injecteur PoE	Déconnexions aléatoires, possiblement corrélées avec les cycles d’alimentation du mineur	Remplacez le câble, vérifiez la santé PoE
Conflit IP ASIC	DHCP retourne la même IP à deux appareils	Réservez des IPs statiques dans votre routeur pour chaque ASIC
FAI DPI / mise en forme	Les déconnexions corrèlent avec les heures de pointe	Essayez un port stratum différent ou un tunnel VPN

Comment les relays HAProxy de SoloFury aident

Les endpoints EU et Asia de SoloFury (eu-*.solofury.com et asia-*.solofury.com) sont des relays HAProxy avec des timeouts TCP de 24h et keepalive de connexion activé. Ils maintiennent votre worker connecté pendant les redémarrages côté pool et les coupures FAI qui vous déconnecteraient autrement. Préférez toujours un relay régional plutôt que le primaire Atlanta si vous n’êtes pas en Amérique du Nord.

6. Symptôme : Aucune Share du Tout (Worker Montre “Dernière Vue : Jamais” ou Il y a Des Heures)

Le worker est complètement hors ligne du point de vue du pool.

Séquence de diagnostic

1. Pouvez-vous atteindre l’interface locale de l’ASIC sur son IP ? Si non → alimentation, réseau ou hardware ASIC. Si oui → continuer.
2. L’interface locale de l’ASIC le montre-t-il en train de miner ? Si non → vérifiez la config du pool dans l’ASIC, redémarrez, vérifiez le firmware. Si oui → continuer.
3. Quelle URL de pool est configurée dans l’ASIC ? Doit être une parmi : bch.solofury.com:7070, btc.solofury.com:7070, bc2.solofury.com:7070, bch2.solofury.com:7070, xec.solofury.com:7070, ou leurs équivalents régionaux eu- / asia-.
4. Quel est le nom de worker ? Doit être <adresse_wallet>.<nom_worker>. L’adresse wallet doit être valide pour le coin (BCH CashAddr pour BCH/BCH2, P2PKH/Bech32 pour BTC, eCash pour XEC, etc.).
5. Depuis l’ASIC, pouvez-vous atteindre le pool ? Utilisez les outils de diagnostic de l’ASIC ou ping/telnet depuis une autre machine sur le même sous-réseau.

Cause profonde la plus courante : mauvais format de wallet

Chaque coin SoloFury requiert un wallet dans son format natif :

Coin	Format	Exemple
BTC	Bech32 ou P2PKH	bc1q... ou 1...
BCH	CashAddr (avec préfixe)	bitcoincash:qq...
BC2	Compatible BTC	bc1q... ou 1...
BCH2	CashAddr (avec préfixe)	bitcoincash:qq...
XEC	eCash (avec préfixe)	ecash:qq...

7. Symptôme : Meilleure Share Stuck Basse (Inquiet de Ne Pas Trouver de Bloc)

Si votre meilleure share est quelque chose comme 0,001 de la difficulté réseau après des semaines de mining, cela ne signifie pas que vous avez de la malchance ou que vos chances sont mauvaises. La meilleure share est une statistique de maximum-ever ; dans un processus de Poisson, la plupart des shares sont petites, et le maximum augmente lentement avec la racine cubique du travail total effectué. Une faible meilleure share est statistiquement normale.

Ce qui compte pour la probabilité de trouver un bloc est le hashrate-temps cumulatif total, pas la meilleure share. Si votre hashrate est bon et votre taux de rejet est bas, vous achetez des tickets de loterie correctement — la variance prend juste du temps à s’exprimer.

Pour les maths derrière la variance du solo mining et ce à quoi s’attendre réalistement à différents niveaux de hashrate, voir l’article Solo Mining Lottery Math.

8. Référence Rapide : Symptôme → Cause la Plus Probable

Symptôme	Première chose à vérifier	Cause la plus commune
Hashrate 20%+ en dessous du prévu (stable)	Interface locale ASIC	Problème de hashboard ou thermique
Hashrate fluctue sauvagement minute à minute	C’est normal pour les petits workers	Variance, attendez la moyenne 1h
Taux de rejet au-dessus de 2 %	Ping vers le pool	Latence — changez de région
Taux de stales au-dessus de 2 %	Ping vers le pool	Latence — changez de région
Worker hors ligne (“Dernière vue : il y a des heures”)	Alimentation & réseau ASIC	Panne d’alimentation ou erreur config stratum
Déconnexions fréquentes	Routeur/NAT, FAI	Utilisez l’endpoint régional HAProxy
Meilleure share très basse après des semaines	C’est statistique	Normal, continuez à miner
Hashrate qui monte lentement après le démarrage	Vardiff converge	Attendez 30 minutes, comportement normal

9. Choisir la Bonne Région SoloFury

La latence du pool est le facteur le plus contrôlable pour la qualité des shares. SoloFury opère trois régions :

Région	Modèle d’endpoint	Meilleur pour
Atlanta (primaire)	<coin>.solofury.com	Amérique du Nord, Caraïbes, Amérique du Sud côte est
Frankfurt (relay EU)	eu-<coin>.solofury.com	Europe, Moyen-Orient, Afrique
Singapore (relay Asie)	asia-<coin>.solofury.com	Asie, Océanie, Inde

Testez votre latence en remplaçant <coin> dans chaque endpoint et en faisant un ping depuis votre réseau. Choisissez le plus bas. Si deux sont proches, préférez celui avec le jitter le plus bas (variance dans les temps de ping), pas seulement la moyenne la plus basse.

10. Quand Contacter le Support

Si votre worker montre l’un de ces symptômes après avoir suivi ce guide :

• Plusieurs workers tombent tous simultanément, uniquement sur SoloFury (pas sur d’autres pools)
• Tous les workers montrent zéro shares malgré la confirmation par l’interface ASIC qu’il hache
• Bloc trouvé dans le Hall of Fame mais la récompense n’a jamais atteint votre wallet

…contactez le support SoloFury via le bot Telegram ou @SoloFuryPool sur X. Fournissez :

1. Votre adresse wallet (pour que le support puisse consulter l’historique de vos workers)
2. Le coin que vous minez (BTC/BCH/BC2/BCH2/XEC)
3. Le nom du worker montrant le symptôme
4. L’URL d’endpoint configurée dans votre ASIC

La plupart des problèmes se résolvent en moins de 30 minutes une fois que le support a le nom du worker.

Prochaines Étapes

• Lancez le guide Miner Health Check pour un walkthrough diagnostique complet d’un ASIC défaillant
• Si vous configurez un nouveau mineur, voir le Guide de Configuration Antminer S21+ ou le Guide de Configuration Antminer S19 & Whatsminer M-series
• Pour les différences diagnostiques du hashrate loué, voir le guide NiceHash Solo Mining
• Pour le contexte sur les maths de difficulté des shares, lisez l’article Solo Mining Variance
• Pour le statut en temps réel du pool, consultez la page System Status