Eine Wallet aktualisiert nicht mehr, eine Anwendung hängt im Ladekreis, und irgendwo dahinter steht, dass das Ratenlimit überschritten wurde. Mit deinen Schlüsseln, deinem Guthaben und der Chain ist nichts falsch. Ein Betreiber hat entschieden, dass du in einem gegebenen Fenster mehr Fragen gestellt hast, als dein Tarif erlaubt, und weist alles ab, was über dieser Linie ankommt.
Was ein Ratenlimit-Fehler tatsächlich meldet
Ein RPC-Knoten ist eine Maschine, die Fragen zur Chain für Wallets und Anwendungen beantwortet, die keinen eigenen Knoten betreiben. Wer diese Maschine betreibt, entscheidet auch, wie viele Fragen jeder Aufrufer stellen darf, und setzt das durch, indem er alles oberhalb der Obergrenze abweist.
RFC 6585 gibt dieser Abweisung einen eigenen Statuscode. Dort steht, dass der Statuscode 429 anzeigt, dass der Nutzer in einer gegebenen Zeitspanne zu viele Anfragen gesendet hat, und der Abschnitt selbst nennt diesen Zustand Ratenbegrenzung; ergänzt wird, dass die Antwortrepräsentationen SHOULD Details enthalten, die den Zustand erklären, und MAY einen Retry-After-Header enthalten, der angibt, wie lange vor einer neuen Anfrage zu warten ist.
Daraus folgen zwei Dinge, die man vor einem kaputten Bildschirm leicht übersieht. Die Abweisung betrifft den Aufrufer und nicht den einzelnen Aufruf, dieselbe Anfrage wäre einen Moment früher durchgegangen. Und die Obergrenze ist die Richtlinie eines Betreibers, keine Eigenschaft des Netzwerks, weshalb ein zweiter Endpunkt mit anderer Richtlinie dieselbe Anfrage anstandslos beantwortet.
Die Abweisung kommt in mehr als einem Umschlag
Nicht jeder gedrosselte Aufruf kommt als HTTP-Status zurück. JSON-RPC 2.0 trägt Fehler im Antwortkörper, und die Spezifikation reserviert die Codes -32000 bis -32099 für implementierungsdefinierte Serverfehler, und genau dort kann die Drosselungsmeldung eines Anbieters sitzen. Die HTTP-Ebene meldet dann einen gewöhnlichen Erfolg.
| Wo die Abweisung landet | Wie sie aussieht | Warum sie übersehen wird |
|---|---|---|
| HTTP-Status | Eine 429-Antwort, manchmal mit Retry-After-Header | Unsichtbar für einen Client, der nur prüft, ob die Verbindung stand |
| JSON-RPC-Körper | Ein error-Objekt mit implementierungsdefiniertem Serverfehlercode | Der HTTP-Status ist ein Erfolg, also lässt ihn eine Statusprüfung durch |
| Formulierung im Client | Ein veraltetes Guthaben, ein Ladekreis oder ein allgemeiner Netzwerkfehler | Der Text ist für Menschen geschrieben und benennt die abweisende Ebene nicht |
Die Diagnose beginnt also mit der Frage, welcher der drei Fälle vorliegt. Eine Wallet, die nur sagt, sie könne nicht verbinden, belegt nicht, dass keine Abweisung stattfand, sondern nur, dass die Wallet keine gezeigt hat.
Limits werden nicht immer in Anfragen gezählt
Eine in Aufrufen pro Sekunde ausgedrückte Obergrenze ist nur eine Form, die ein Limit annehmen kann. Wo ein Betreiber Aufrufe gewichtet, statt sie zu zählen, zieht eine schwere Methode mehr aus demselben Budget als eine leichte, und das Budget leert sich schneller, als die Aufrufzahl vermuten lässt.
Deshalb können eine Handvoll Aufrufe und ein überschrittenes Limit beide zutreffende Beschreibungen derselben Minute sein. Eine Log-Abfrage über einen weiten Blockbereich ist ein Aufruf nach Anzahl und eine große Abhebung nach Gewicht. Die eigene Beschreibung des Betreibers zu lesen, was sein Budget zählt, klärt das schneller als ein Versuch dagegen.
Woher das Anfragevolumen wirklich kommt
Volumen sammelt sich an, es wird nicht gewählt. Es entsteht aus Schleifen, die niemand für Schleifen hält: ein Bildschirm, der ein Guthaben nach Timer neu liest, eine Komponente, die bei jedem Rendern neu lädt, ein Beobachter im Hintergrund, der fragt, ob eine Transaktion schon gelandet ist.
Die Rechnung ist unerbittlich, weil das Intervall klein und die Sitzung lang ist. Ein Bildschirm, der ein Guthaben einmal pro Sekunde aktualisiert, erzeugt in einer zwölfstündigen Sitzung von sich aus 43.200 Aufrufe, bevor irgendeine Nutzeraktion gezählt ist. Gegen einen Tarif, der 100.000 Aufrufe pro Tag erlaubt, hat ein einziger offener Tab bereits einen großen Teil des Tages verbraucht.
Wiederholungen sind die zweite Quelle, und sie verstärken die erste. Ein Client, der jede Abweisung mit erneutem Senden beantwortet, macht aus einer überschrittenen Obergrenze einen Strom davon, und zwar genau in dem Moment, in dem der Betreiber ihn am wenigsten bedienen will.
Wiederholen, ohne die Abweisung zu verschlimmern
Im selben Intervall erneut zu senden, das die Abweisung ausgelöst hat, reproduziert die Abweisung. Die Korrektur besteht darin, nach jedem Fehlschlag länger zu warten statt gleich lang, sodass das Intervall wächst, während die Obergrenze bleibt, und nach einer begrenzten Zahl von Versuchen aufzuhören statt endlos weiterzumachen.
Füge diesem Warten Zufall hinzu. Clients, die im selben Augenblick abgewiesen wurden und nach derselben Regel zurückweichen, kehren auch im selben Augenblick zurück, und die Erholung kommt als nächster Ausschlag. Ein zufälliger Versatz verteilt das Warten und bricht diesen Gleichtakt, und er kostet nichts.
Wo ein Retry-After-Header vorliegt, ersetzt er die Schätzung. Der Betreiber hat gesagt, wie lange zu warten ist, und diesen Wert einzuhalten ist schneller als ein selbst erfundener Zeitplan und wird dir seltener angerechnet.
Anfragen reduzieren statt die Obergrenze anheben
Bündelung ist die erste Reduktion, und sie gehört zum Protokoll, nicht zu einem einzelnen Anbieter. JSON-RPC 2.0 hält fest, dass ein Client MAY ein mit Request-Objekten gefülltes Array senden, um mehrere Request-Objekte gleichzeitig zu schicken, und dass der Server mit einem Array antworten sollte, das die entsprechenden Response-Objekte enthält, nachdem alle Request-Objekte des Bündels verarbeitet wurden. Zehn Aufrufe in ein Array zu falten, macht aus jener Sitzung mit 43.200 Aufrufen 4.320 Anfragen.
Zwischenspeichern ist die zweite. Werte, die sich zwischen Blöcken nicht ändern, müssen zwischen Blöcken nicht neu gelesen werden: die Nachkommastellen eines Tokens, eine Vertragsadresse, die Quittung einer bereits abgeschlossenen Transaktion. Alles Endgültige lässt sich unbegrenzt zwischenspeichern, und es erneut zu lesen ist reine Ausgabe.
Abonnements sind die dritte, sofern der Endpunkt sie anbietet. Polling fragt immer wieder, ob sich etwas geändert hat; ein Abonnement fragt einmal und wird benachrichtigt, wenn sich die Antwort ändert. Beide tragen dieselbe Information und kosten sehr unterschiedlich viel Budget.
| Was du beobachtest | Wo die Obergrenze wirklich liegt | Was daran etwas ändert |
|---|---|---|
| Abweisungen bei geringer Nutzung | Ein gewichtetes Budget, von schweren Methoden verbraucht | Blockbereiche verengen und die Abfrage aufteilen |
| Abweisungen häufen sich nach der ersten | Wiederholungen laufen in dieselbe Obergrenze | Mit wachsendem, zufällig versetztem Warten zurückweichen |
| Abweisungen aus einem einzigen ungenutzten Tab | Eine Polling-Schleife auf einem Timer | Bündeln, zwischenspeichern oder abonnieren statt pollen |
| Abweisungen nur in einem Netzwerk | Eine an diesen Endpunkt gebundene Richtlinie | Einen zweiten Endpunkt für dieses Netzwerk hinzufügen |
Wann eine Wiederholung nicht sicher ist
Lesen und Schreiben lassen sich nicht gleich gut wiederholen. Ein Guthaben zweimal abzufragen kostet einen zusätzlichen Aufruf und sonst nichts. Eine signierte Transaktion zweimal zu senden ist ein anderes Ereignis, und eine Abweisung am Endpunkt sagt dir nicht, auf welcher Seite dieser Grenze die Transaktion stehen geblieben ist.
Bevor du erneut sendest, stelle fest, ob der erste Versuch den Mempool erreicht hat. Eine Transaktion, die das Netzwerk schon hält, und eine neue Transaktion mit derselben Absicht sind nicht austauschbar, und beide als eine zu behandeln ist der Weg zu einer doppelten Übertragung. Auf Solana macht der Frischebezug das Timing sichtbar: eine durch langes Zurückweichen verzögerte Einreichung kann auf einen abgelaufenen Blockhash treffen und muss neu gebaut statt erneut gesendet werden.
Dieselbe Vorsicht gilt für das, was dein Client danach glaubt. Eine Wallet, deren Leseanfragen abgewiesen werden, vergleicht ihren eigenen Zählstand gesendeter Transaktionen mit einer Sicht, die sie nicht auffrischen konnte, und das ist einer der Wege zur Meldung Nonce zu hoch. Der Zähler irrt nicht; es fehlt das Bild, mit dem er verglichen wurde.
Ein Endpunktwechsel behebt eine Ursache, nicht die anderen
Gehört die Obergrenze dem Betreiber, bringt dich der Wechsel zu einem anderen Betreiber unter eine andere Obergrenze, und ein Endpunktwechsel ist genau dafür die übliche Reparatur. Prüfe die Chain-ID des neuen Eintrags, bevor du irgendetwas darüber leitest, und behalte den Eintrag, der schon funktioniert hat. Was ein Wechsel nicht erreicht, ist alles, was die Chain bereits festgehalten hat: eine Transaktion, die lief und zurückgerollt wurde, ist reverted, und jeder ehrliche Endpunkt meldet diese Quittung gleich.
Gehört das Volumen dir, kauft der Wechsel Zeit und sonst nichts. Dieselbe Polling-Schleife trifft die Obergrenze des nächsten Betreibers nach demselben Zeitplan, und zwischen Endpunkten zu rotieren, um unter mehreren Obergrenzen zugleich zu bleiben, versteckt die Schleife, statt sie zu beheben.
Ein dritter Fall gehört von beiden getrennt. Ein dedizierter Endpunkt mit deinem eigenen Schlüssel ist nicht einfach ein größeres Kontingent; er trennt dich auch von anderen Aufrufern, die sich einen öffentlichen geteilt haben, sodass eine danach erhaltene Abweisung wirklich deine ist.
Fazit
Ein Ratenlimit-Fehler sagt etwas darüber, wie viel du verlangt hast, nicht darüber, ob du fragen durftest. Er benennt ein Budget, ein Fenster und einen Betreiber, und eine brauchbare Reaktion beginnt damit, welches der drei gerade bindet.
Lies die Abweisung dort, wo sie landet, halte Retry-After ein, wenn er angeboten wird, und weiche mit wachsendem, zufällig versetztem Warten zurück, statt nach dem alten Zeitplan erneut zu senden. Reduziere dann das Volumen, statt einer größeren Obergrenze nachzujagen: bündle, was zusammen reisen kann, speichere zwischen, was sich nicht ändert, und abonniere statt zu pollen. Ein doppelt so großes Kontingent, von derselben Schleife verbraucht, ist an demselben Nachmittag aufgebraucht. Um die Grundlagen weiter zu lernen, folge weiteren Beiträgen der Bitbase Academy.
Weiterführende Artikel
Weitere Bitbase-Artikel zu diesem Thema:
- Wie du RPC-Endpunkte sicher wechselst
- Maximale Transaktionsgebühr überschritten: Was diese Wallet-Warnung bedeutet
- Seed Phrase vs Passphrase: der Unterschied und warum er zählt
- Was ist Blockchain-Finalität?
Haftungsausschluss: Dieser Artikel ist Bildungsinhalt der Bitbase Academy, nur zu Informationszwecken. Er ist keine Anlage-, Handels-, Steuer- oder Finanzberatung. Krypto-Assets sind volatil — schätze dein Risiko selbst ein. Stand September 2026; maßgeblich sind die aktuellen offiziellen Informationen.
Quellen
[1] M. Nottingham, R. Fielding, Additional HTTP Status Codes, RFC 6585, IETF, April 2012 rfc-editor.org
[2] JSON-RPC 2.0 Specification, JSON-RPC Working Group, Stand 4. Januar 2013 jsonrpc.org
