Der Pool ist down: wie Sie erkennen, dass das Problem nicht an Ihrem ASIC liegt, und was in der ersten Stunde zu tun ist

*Last updated: 09.09.2026. POOL BTC.*

TL;DR

Wenn die Hashrate im Pool-Dashboard auf null fällt, ist nicht immer der Pool schuld. In den meisten Fällen liegt die Ursache zwischen Ihrem ASIC und dem Stratum-Server: Router, Provider, Stromversorgung, ein überhitztes Board, eine frisch aufgespielte Firmware. Das eine vom anderen zu unterscheiden dauert fünf Minuten, ohne vom Laptop aufzustehen: nachsehen, was der Miner selbst anzeigt, prüfen, ob der Pool auch bei anderen Minern liegt, und die lokale Hashrate mit der im Pool vergleichen. Die erste Stunde sollte nicht in Panik oder in einen Poolwechsel fließen, sondern in eine geordnete Diagnose und in das Aktivieren des Ersatz-Stratums, das längst in der Konfiguration hätte stehen sollen.

POOL BTC ist kein Pool, sondern eine unabhängige Vergleichsseite für Pools. Ausfälle schreiben wir hier keinem konkreten Pool zu: unten steht eine Methode, keine Aufarbeitung fremder Störungen.

Wie unterscheidet man einen Poolausfall von einem Problem auf der eigenen Seite?

Das Hauptmerkmal eines Poolausfalls: der Miner läuft, die Hashrate am Gerät ist normal, aber die Verbindung zum Stratum bricht ab oder die Shares gehen ohne Antwort raus. Wenn dagegen im Dashboard des ASIC selbst die Hashrate eingebrochen ist, Chips ausgefallen sind oder das Gerät in Dauerschleife neu startet, hat der Pool nichts damit zu tun, dann liegt das Problem an der Hardware, an der Stromversorgung oder am Netz bis zum Provider.

Gehen wir es nach Symptomen durch. Man muss zwei Stellen gleichzeitig ansehen: das Dashboard des Miners (lokale Hashrate) und die Kontostatistik im Pool (Hashrate im Pool).

Ein Sonderfall, der am häufigsten mit einem Poolausfall verwechselt wird: eine frische Einrichtung. Wenn die Hashrate im Pool nie aufgetaucht ist, ist das kein Ausfall, sondern ein Tippfehler im Workernamen oder ein geschlossener Port. Ein Ausfall sieht anders aus: es lief tagelang und hörte auf einen Schlag auf.

Was zeigt das Dashboard des Miners bei einem Verbindungsabbruch und was bedeuten accepted, rejected, stale?

Im Dashboard des ASIC gibt es drei Zähler pro Pool: accepted (Shares angenommen), rejected (abgelehnt), stale (zu spät gekommen, die Arbeit ist nicht mehr aktuell). Bei einem Abbruch der Stratum-Verbindung wechselt der Poolstatus auf dead oder disconnected, der Zähler accepted bleibt stehen, und der Miner beginnt, sich mit dem nächsten Pool aus der Liste zu verbinden, sofern dort einer eingetragen ist.

Was hinter den Begriffen steckt:

• Accepted. Der Pool hat Ihren Share angenommen und in die Statistik aufgenommen. Das ist der einzige Zähler, der sich in Geld verwandelt.
• Rejected. Der Pool hat den Share erhalten, aber nicht angerechnet. Die Gründe sind unterschiedlich: die Arbeit ist veraltet, ein Duplikat, zu niedrige Difficulty, ein Autorisierungsfehler.
• Stale. Ein Sonderfall der Ablehnung: der Share wurde für eine Aufgabe berechnet, die der Pool bereits verworfen hat, weil im Netz ein neuer Block gefunden wurde. Je größer die Latenz zum Server, desto häufiger passiert das.
• Difficulty accepted. In manchen Firmwares steht in einer eigenen Zeile die Summe der Difficulty der angenommenen Shares. Sie ist aussagekräftiger als der Stückzähler, denn bei vardiff sagt die reine Anzahl der Shares für sich genommen nichts aus.

Noch eine Zeile, auf die man achten sollte: die Zeit des letzten angenommenen Shares (last share). Wenn sie wächst und bei stabiler Hashrate bereits mehrere Minuten überschritten hat, ist die Verbindung faktisch tot, auch wenn der Poolstatus noch grün ist.

Die Mechanik der Shares und warum ihre Anzahl nicht dem Ertrag entspricht, ist ausführlicher im Artikel über die Auszahlungsschemata FPPS und PPLNS beschrieben.

Welcher Anteil an Rejects gilt als normal und welcher ist schon ein Signal?

Eine allgemeingültige Zahl gibt es nicht: der Anteil abgelehnter Shares hängt von der Entfernung zum Stratum-Server ab, von der Leitungsqualität, von der Firmware und von den vardiff-Einstellungen. Orientieren sollte man sich nicht am absoluten Wert, sondern an der eigenen Baseline: notieren Sie Ihren üblichen Prozentsatz an einem ruhigen Tag und werten Sie alles als Abweichung, was deutlich darüber liegt und dort bleibt.

Ein praktischer Ansatz statt einer magischen Zahl:

1. Nehmen Sie den Anteil an rejected über einen Tag normalen Betriebs. Das ist Ihre Null.
2. Verfolgen Sie nicht den Momentanwert, sondern den Stundendurchschnitt. Einzelne Ausschläge beim Blockwechsel sind normal und kein Ausfall.
3. Ein steigender Anteil bei unveränderter lokaler Hashrate bedeutet ein Problem mit der Leitung oder mit dem Pool, nicht mit der Hardware.
4. Ein steigender Anteil bei gleichzeitig fallender lokaler Hashrate bedeutet Hardware.

Eigene Richtwerte nennen drei Pools, und sie widersprechen einander stärker als die in Chats streitenden Miner. AntPool schreibt im Hilfecenter, dass ein Anteil abgelehnter Shares unter 1 Prozent als normal gilt und veraltete Shares bei etwa 0,5 Prozent und darunter. ViaBTC nennt Ablehnungen im Rahmen von 3 Prozent einen normalen Bereich. F2Pool hält einen Anteil verspäteter Shares von rund 2 Prozent für vernünftig. Die Spanne von 0,5 bis 3 Prozent zwischen drei großen Pools ist genau die Antwort auf die Frage nach der Norm: eine gemeinsame Norm gibt es nicht, es gibt die Einstellungen eines konkreten Pools.

Ein Vorbehalt zur Quelle: die Supportseiten dieser Pools sind für die automatische Prüfung gesperrt, und die obigen Formulierungen haben wir aus ihren öffentlichen Suchsnippets festgehalten, nicht aus dem vollständigen Seitentext. Bevor Sie sich auf eine konkrete Zahl stützen, öffnen Sie das Hilfecenter Ihres Pools und gleichen Sie die aktuelle Fassung ab.

Eine Schwelle, ab der die Verluste spürbar werden, veröffentlicht niemand, und man muss sie sich auch nicht ausdenken: die Rechnung geht im Kopf. Ein abgelehnter Share wird nicht bezahlt, also entspricht der Anteil der Ablehnungen ungefähr dem Anteil des entgangenen Ertrags. Ein Prozent Rejects sind ungefähr ein Prozent Ertrag an der Kasse vorbei, drei Prozent sind drei. Ob sich dafür ein Umbau der Farm lohnt, hängt von ihrer Größe ab und nicht von der Empfehlung eines Fremden.

Was ganz sicher nicht normal ist und keine Statistik braucht: ein Anteil abgelehnter Shares nahe hundert Prozent. Das ist fast immer eine falsche Difficulty, eine defekte Firmware oder eine von einem Zwischenglied blockierte Verbindung, und keine Überlastung des Pools.

Wohin schauen, um einen Poolausfall zu bestätigen?

Die Bestätigung eines Ausfalls ist immer eine zweite unabhängige Quelle. Das eigene Dashboard allein reicht nicht: es zeigt einen Poolausfall und einen Abbruch bei Ihrem Provider gleich an. Die Prüfreihenfolge vom Schnellsten zum Langsamsten dauert etwa fünf Minuten und liefert fast immer eine eindeutige Antwort.

1. Die Hashrate-Statistik des Kontos im Pool. Wenn sich das Webinterface öffnet und für Ihren Worker null zeigt, lebt der Server, und es kommen genau Ihre Shares nicht bei ihm an. Wenn sich das Interface überhaupt nicht lädt, ist das Problem größer.
2. Die Statusseite des Pools. Ein Teil der Pools hat eine eigene Seite zum Zustand der Dienste. Ihre Adresse sollte man vorher heraussuchen und in den Lesezeichen halten und nicht erst im Moment des Ausfalls suchen.
3. Fremde Monitore und Explorer. Öffentliche Beobachter der Hashrate-Verteilung zeigen, ob der Pool gerade jetzt Blöcke findet. Eine lange Pause bei einem großen Pool ist ein indirektes, aber starkes Indiz.
4. Soziale Netze und Chats des Pools. Der offizielle Account und der Telegram-Kanal erfahren von einem Ausfall meist schneller, als die Statusseite aktualisiert wird. Dort sieht man auch, ob sich andere Miner beschweren.
5. Prüfung der Route von der eigenen Seite. Ein einfaches telnet oder nc auf Adresse und Port des Stratums von irgendeinem Rechner im selben Netz trennt einen Poolausfall in zehn Sekunden von einer Sperre beim Provider.

Wenn sich das Poolinterface öffnet, Blöcke gefunden werden, im Chat Ruhe herrscht und Ihre Shares nicht angenommen werden, dann liegt die Störung bei Ihnen und nicht beim Pool.

Wozu braucht man einen backup pool und wie trägt man das Ersatz-Stratum richtig ein?

Der Ersatzpool ist eine Zeile in der Konfiguration des Miners, auf die das Gerät von selbst umschaltet, wenn das Haupt-Stratum nicht antwortet. Ohne sie dreht der ASIC bei einem Verbindungsabbruch einfach die Lüfter und verdient bis zu Ihrem Eingreifen gar nichts. Mit ihr schrumpft der Stillstand auf die Zeit der Neuverbindung, und die misst sich in Sekunden und nicht in Stunden Ihres Schlafs.

Wie das in der Konfiguration aussieht. Firmwares unterscheiden sich in Details, aber das Prinzip ist eines: eine Liste von Pools nach Priorität, der Miner geht von oben nach unten.

\`\`\`

pool1: stratum+tcp://[ADRESSE DES HAUPTPOOLS]:[PORT] worker: konto.worker

pool2: stratum+tcp://[ADRESSE DES ERSATZPOOLS]:[PORT] worker: konto2.worker

pool3: stratum+tcp://[ADRESSE DES DRITTEN POOLS]:[PORT] worker: konto3.worker

\`\`\`

Regeln, ohne die der Ersatz nicht greift:

1. Der zweite Pool ist ein anderer Pool und nicht ein anderer Port desselben. Eine Ersatzadresse innerhalb derselben Infrastruktur rettet nicht vor dem Ausfall genau dieser Infrastruktur. Den Ersatzport des Hauptpools setzen Sie in die dritte Zeile, nicht in die zweite.
2. Das Konto im Ersatzpool muss vorher angelegt und geprüft sein. Eine Registrierung im Moment des Ausfalls frisst genau diese erste Stunde.
3. Die Auszahlungsadresse im Ersatzpool muss ausgefüllt sein. Sonst hängt das Geschürfte auf einem Guthaben, zu dem Sie erst in einem Monat zurückkehren.
4. Testen Sie das Umschalten von Hand. Deaktivieren Sie den Hauptpool im Interface für ein paar Minuten und überzeugen Sie sich, dass die Shares zum Ersatz gewandert sind und dass der Miner nach der Rückkehr wieder zurückgewechselt ist.
5. Berücksichtigen Sie das Auszahlungsschema. Ein Hin und Her zwischen PPLNS-Pools setzt die Ansammlung im Fenster zweimal auf null, deshalb ist als Ersatz ein Pool mit einfacherem Schema sinnvoller. Der Unterschied der Mechaniken ist im Vergleich von FPPS und PPLNS beschrieben.

Die Zahl der verfügbaren Zugangspunkte ist bei den Pools unterschiedlich, und sie geht aus ihrer eigenen Dokumentation hervor. Wir haben die eindeutigen Stratum-Hosts für BTC auf den Verbindungsseiten von sechs Pools gezählt.

Wichtig ist hier nicht, dass ein Pool acht Hosts hat und ein anderer einen. Wichtig ist, dass all diese Adressen in eine einzige Infrastruktur führen: sie retten vor dem Ausfall einer Region, aber nicht vor dem Ausfall des Pools. Genau deshalb muss die zweite Zeile in der Konfiguration nach außen zeigen.

Wie viel Geld verliert ein Miner pro Stunde Stillstand wirklich und wie rechnet man das selbst aus?

Der Verlust pro Stunde Stillstand ist in einer Zeile berechnet: der Tagesertrag Ihrer Ausrüstung, geteilt durch 24, multipliziert mit dem Anteil des Stillstands. Komplizierte Modelle braucht es hier nicht, denn der Ertrag im Pool ist linear zur Hashrate. Wichtig ist nur, den aktuellen Hashprice zu nehmen und nicht eine Zahl aus einem halbjahresalten Artikel, sonst liegt der Fehler um ein Vielfaches daneben.

Die Formel:

\`\`\`

Verlust = (Hashrate in TH/s × Hashprice in USD pro TH/s und Tag) / 24 × Stunden Stillstand

\`\`\`

Der Hashprice ist der Ertrag pro Terahash und Tag vor Abzug des Stroms. Er ändert sich täglich mit Kurs und Difficulty, setzen Sie deshalb einen frischen Wert ein.

Den Hashprice legen wir im Text bewusst nicht als Zahl fest. Er ändert sich täglich mit Kurs und Difficulty, und ein Wert aus einem einen Monat alten Artikel ergibt einen Fehler um ein Vielfaches und nicht um Prozente. Setzen Sie den frischen Wert vom Tag der Berechnung ein: öffentliche Hashprice-Indizes und unser Rechner zeigen ihn an.

Was man beim Rechnen nicht vergessen sollte:

• Strom wird während des Stillstands teilweise weiter verbraucht. Wenn der Miner eingeschaltet ist, aber keine Shares senden kann, verbraucht er trotzdem. Der reale Verlust pro Stunde liegt um die Kosten dieses Verbrauchs über dem reinen Ertragsausfall.
• PPLNS bestraft Stillstand doppelt. In kumulativen Schemata haben Sie in dieser Stunde nicht nur nichts verdient, sondern auch Ihre Position im Fenster verloren, und die stellt sich nicht sofort wieder her. In PPS-artigen Schemata entspricht der Verlust genau der Formel.
• Rechnen Sie über die gesamte Farm und nicht über eine Maschine. Eine Stunde Stillstand von zehn Geräten kostet zehnmal so viel, und bei dieser Zahl trifft sich die Entscheidung über den Ersatzpool von selbst.

Den Ertrag für Ihre Hashrate und die aktuellen Netzparameter rechnet man bequemer im Rechner aus als im Kopf.

Was in der ersten Stunde zu tun ist: Checkliste Schritt für Schritt

1. Minute 0-2. Sehen Sie sich die lokale Hashrate im Dashboard des Miners an. Ist sie zusammen mit der Pool-Hashrate eingebrochen, ist es die Hardware, und weiter durch diese Liste muss man nicht gehen.
2. Minute 2-5. Prüfen Sie den Status der Pools und die Zeit des letzten angenommenen Shares. Status dead und eine wachsende Zeit bestätigen den Verbindungsabbruch.
3. Minute 5-10. Öffnen Sie das Poolinterface und die Statusseite. Öffnet sich gar nichts, auch andere Seiten nicht, dann liegt es an Ihrer Leitung.
4. Minute 10-15. Prüfen Sie die Erreichbarkeit des Stratums von einem anderen Gerät im selben Netz und danach über mobiles Internet. Der Unterschied im Ergebnis weist auf den Provider oder den Router hin.
5. Minute 15-20. Schauen Sie in den Chat und die sozialen Netze des Pools. Massenhafte Beschwerden in den letzten Minuten klären die Frage.
6. Minute 20-30. Überzeugen Sie sich, dass der Ersatz gegriffen hat. Steht kein Ersatzpool in der Konfiguration, tragen Sie ihn jetzt ein, das ist die einzige Handlung, die genau jetzt Ertrag zurückholt.
7. Minute 30-45. Fassen Sie nichts weiter an. Ein Massen-Reboot der Farm, ein Firmwarewechsel und eine Änderung der Difficulty während eines fremden Ausfalls verschaffen Ihnen eine zweite Störung obendrauf.
8. Minute 45-60. Halten Sie die Fakten fest. Startzeit, Screenshot des Dashboards, Zeit des letzten Shares, Antwort des Pools. Ohne das wird aus dem Gespräch über eine Entschädigung ein Streit über Erinnerungen.

Wann ist ein Stillstand ein Grund für einen Poolwechsel und wann nicht?

Ein einzelner Ausfall ist kein Grund umzuziehen. Infrastruktur fällt bei allen aus, und die Kosten eines Poolwechsels übersteigen oft den Verlust aus einigen Stunden Stillstand. Der Grund entsteht dann, wenn sich die Ausfälle wiederholen, lange dauern und nicht von verständlicher Kommunikation begleitet werden: das Schweigen des Pools während eines Ausfalls kostet mehr als der Ausfall selbst.

Rechnen Sie vor dem Umzug den Preis des Umzugs selbst aus: das Nullsetzen des Fensters bei PPLNS, das Warten auf die neue Auszahlungsschwelle, die Zeit für die Neukonfiguration. Wenn Sie zum SOLO-Mining neigen, um die Abhängigkeit von fremder Infrastruktur loszuwerden, sehen Sie sich zuerst den Vergleich von SOLO und Pool an, dort ändert dieselbe Abhängigkeit einfach ihre Form.

Warum fast kein Pool seine Uptime veröffentlicht und wie man Zuverlässigkeit indirekt bewertet

Eine öffentliche Uptime-Seite ist eine Verpflichtung, die zu übernehmen sich nicht lohnt: jede Zahl wird zum Anlass für Ansprüche und Vergleiche, und ehrlich messen muss man sie von außen. Deshalb beschränken sich die meisten Pools auf die Statistik gefundener Blöcke und der Hashrate. Zuverlässigkeit muss man indirekt bewerten, an beobachtbaren Merkmalen und nicht an behaupteten Prozenten.

Worauf man achtet, wenn es keine Uptime-Zahl gibt:

• Die Regelmäßigkeit gefundener Blöcke. Bei einem großen Pool sind die Pausen anhand seines Netzanteils vorhersagbar. Eine ungewöhnlich lange Stille sieht man in jedem öffentlichen Explorer.
• Das Vorhandensein einer Statusseite und einer Störungshistorie. Allein die Tatsache, dass ein Pool ein öffentliches Störungsprotokoll führt, sagt mehr als eine schöne Zahl von 99,9.
• Tempo und Substanz der Kommunikation. Eine Nachricht im Chat in den ersten Minuten des Ausfalls ist mehr wert als ein Entschuldigungspost am nächsten Tag.
• Die Zahl unabhängiger Zugangspunkte. Verschiedene Regionen, verschiedene Stratum-Adressen, Unterstützung mehrerer Ports. Das senkt die Chance, dass Sie die Verbindung komplett verlieren.
• Erfahrungsberichte von Minern zu früheren Störungen. Nicht darüber, ob es Störungen gab, sondern darüber, ob die Statistik danach gestimmt hat.

Wir haben die öffentlichen Materialien von acht Pools am 09.09.2026 geprüft. Eine vollwertige Statusseite mit Störungshistorie und Uptime-Zahlen fand sich bei einem: Luxor veröffentlicht sie auf uptime.luxor.tech, aufgeschlüsselt nach Diensten (Poolinterface 99,766 Prozent, Statistikverarbeitung 99,956 Prozent, ein Teil der Dienste 100 Prozent) und mit einem Protokoll über drei Monate. Foundry hat status.foundry.ac, aber das ist der Status der Unternehmensdienste von Foundry Digital und keine eigene Seite des Mining-Pools. F2Pool führt einen Ankündigungsbereich mit Beiträgen zu Störungen, aber das ist keine Statusseite. Bei ViaBTC begegnet die Zahl 99,99 Prozent in Marketingmaterialien, und eine Seite, auf der man sie prüfen könnte, haben wir nicht gefunden. Bei AntPool, Braiins Pool, Binance Pool und Ocean wurde per Suche keine öffentliche Statusseite entdeckt. Letzteres bedeutet genau «im Rahmen der Prüfung nicht gefunden» und keine garantierte Abwesenheit.

Prüfung der öffentlichen Poolseiten, 09.09.2026.

Die zusammengefassten Parameter der Pools, inklusive Auszahlungsschemata, Gebühren und Schwellen, sind in den Poolkarten gesammelt. Uptime-Daten gibt es dort genau aus dem oben genannten Grund nicht: es gibt nichts zu vergleichen, solange die Pools sie nicht veröffentlichen.

Kurz gefasst

Der Pool ist seltener down, als es in der ersten Minute scheint. Die Reihenfolge der Schritte ist immer dieselbe: zuerst die eigene Hardware vom fremden Server trennen, dann den Ausfall mit einer zweiten Quelle bestätigen, dann sicherstellen, dass das Ersatz-Stratum die Last übernommen hat. Ein Ersatzpool in der Konfiguration kostet nichts und spart Stunden an Ertrag, und eintragen muss man ihn an einem ruhigen Tag und nicht an einem Ausfalltag.