Quicknode stellt Fehlerprotokolle für Ihre RPC-Endpunkte bereit. Sie können Probleme ganz einfach identifizieren und beheben, indem Sie detaillierte Fehlerinformationen direkt über Ihr Dashboard einsehen.

HTTP-Fehlercodes

Schauen wir uns einmal die gängigen HTTP-Fehlercodes an, die auftreten können, was sie bedeuten und was Sie tun können, um sie zu vermeiden.

400Ungültige Anfrage

Falscher HTTP-Anfragetyp (z. B. Verwendung von GET statt POST) oder ungültige Zeichen

401Nicht autorisiert

Dies kann passieren, wenn eine oder mehrere Sicherheitsanforderungen nicht erfüllt sind, z. B. bei einer fehlerhaften Token-Authentifizierung, einer IP-Adresse, die nicht auf der Whitelist steht, einem ungültigen JWT usw.

403Zugriff verweigert

Endgerät deaktiviert (Ein Grund hierfür könnte eine überfällige Zahlung sein)

403Zugriff verweigert – benutzerdefinierte Ablaufverfolgung nicht gefunden

Benutzerdefinierter Trace-Code ist nicht in der Whitelist aufgeführt (Reichen Sie ein Ticket ein, um den Genehmigungsprozess zu durchlaufen)

404Nicht gefunden

Falsche URL oder falsche Methode

413Inhalt zu groß

Der Hauptteil der Anfrage ist zu groß

413Anfrage-Entität zu groß

eth_getLogs und eth_newFilter sind auf einen Bereich von 10.000 Blöcken beschränkt. Bei der Abfrage von Protokollen und Ereignissen wenden wir eine Begrenzung auf 10.000 Blockbereiche an.

429Zu viele Anfragen

Die Anzahl der Anfragen pro Sekunde (RPS) liegt über dem in Ihrem Tarif zulässigen Limit. Weitere Informationen zu den 429-Fehlern finden Sie in unserer Support-Dokumentation.

500Interner Serverfehler

Reichen Sie ein Ticket ein, damit sich das Support-Team so schnell wie möglich die Fehler ansieht.

503Dienst nicht verfügbar

Reichen Sie ein Ticket ein, damit sich das Support-Team so schnell wie möglich die Fehler ansieht.

Beispiel für einen HTTP-Fehlercode

Der folgende Codeausschnitt ist ein Beispiel für den Fehlercode 429.

{
	"jsonrpc": "2.0",
	"error": {
		"code": 429,
		"message": "The requests per second (RPS) of your requests are higher than your plan allows."
	},
	"id": 1
}

Bitcoin RPC Error Codes

Let's look at the common Bitcoin RPC Error Codes you can encounter, what they mean and what you can do to prevent them.

-32700Parsing-Fehler

Invalid JSON was received by the server; check JSON syntax and formatting

-32600Invalid Request

The JSON sent is not a valid Request object; verify the request structure matches JSON-RPC 2.0 specification

-32601Methode nicht gefunden

The method does not exist or is not available; verify method name spelling or check if the method requires a specific marketplace add-on (e.g., Blockbook methods like bb_gettx require the Blockbook add-on to be enabled)

-32602Invalid params

Invalid method parameter(s); double check parameter types, values, and order against Bitcoin Core documentation

-32603Internal error

Internal JSON-RPC error; this typically indicates an issue with the Bitcoin node itself

-1Miscellaneous error

General error that doesn't fit other categories; check error message for specific details

-2Forbidden by safe mode

Server is in safe mode, and command is not allowed in safe mode

-3Type error

Unexpected type was passed as parameter; ensure parameter types match expected values

-4Wallet error

Unspecified problem with wallet (key not found etc.)

-5Invalid address or key

Invalid Bitcoin address or key format; verify address/key format and network (mainnet vs testnet)

-6Insufficient funds

Not enough funds in wallet or account

-7Out of memory

Ran out of memory during operation

-8Invalid parameter

Invalid, missing or duplicate parameter

-9Client not connected

Bitcoin is not connected

-10Client in initial download

Still downloading initial blocks

-11Invalid account name

Invalid account name

-12Keypool ran out

Keypool ran out, call keypoolrefill first

-13Wallet unlock needed

Enter the wallet passphrase with walletpassphrase first

-14Wallet passphrase incorrect

The wallet passphrase entered was incorrect

-15Wrong encryption state

Command given in wrong wallet encryption state (encrypting an encrypted wallet etc.)

-16Wallet encryption failed

Failed to encrypt the wallet

-17Wallet already unlocked

Wallet is already unlocked

-18Wallet not found

Invalid wallet specified

-19Wallet not specified

No wallet specified (error when there are multiple wallets loaded)

-20Database error

Database read/write error; this may indicate corruption or disk issues

-22Deserialization error

Error parsing or validating structure in raw format; verify the raw transaction or block hex is properly formatted

-23Node already added

Node is already added

-24Node not added

Node has not been added before

-25Verify error

General error during transaction or block submission

-26Verify rejected

Transaction or block was rejected by network rules

-27Verify already in chain

Transaction already in chain

-28Client in warmup

Client still warming up

-29Node not connected

Node to disconnect not found in connected nodes

-30Invalid IP or subnet

Invalid IP/Subnet

-31P2P disabled

No valid connection manager instance found

Bitcoin RPC Error Code Example

Der folgende Codeausschnitt ist ein Beispiel für den Fehlercode -32601.

{
  "jsonrpc": "2.0",
  "error": {
    "code": -32601,
    "message": "Method not found"
  },
  "id": 1
}

Endpunktprotokolle

Quicknode stellt Protokolle für Ihre RPC-Endpunkte bereit, um Ihnen bei der Fehlerbehebung zu helfen. Sie können die Protokolle direkt in Ihrem Quicknode-Dashboard einsehen, indem Sie zu folgender Seite navigieren:

1. Endpunkte in der Seitenleiste
2. Auswahl Ihres Endpunkts
3. Die Registerkarte „Protokolle “ öffnen

Sie können die Protokolle nach Zeitfenster, Antworttyp, Methode und Netzwerk filtern.

Was wird protokolliert?

Endpunktanfragen
An Ihren Endpunkt gerichtete Anfragen, einschließlich HTTP-Status, Anfragemethode, RPC-Methode oder -Pfad sowie Zeitstempel.

Fehlerdetails
Sofern verfügbar, enthalten fehlgeschlagene Anfragen Fehlerdetails wie RPC-Fehlercodes, Anfrage- und Antwortinhalte sowie Links zu weiterführender Dokumentation.

Einschränkungen bei der Protokollierung

Die Verfügbarkeit von Protokollen kann je nach Methode, Antworttyp, Netzwerk und Tarif variieren. Um eine optimale Endpunktleistung zu gewährleisten, erfolgt die Protokollierung nach dem „Best-Effort“-Prinzip. In Zeiten mit hohem Datenverkehr können einige Protokolle verworfen werden, um eine geringe Latenz zu gewährleisten.

Aufbewahrung und Zugriff

Die „Build“- und „Scale“-Tarife umfassen den Zugriff auf das Dashboard mit standardmäßiger Protokollaufbewahrung. Die „Enterprise“-Tarife bieten verlängerte Aufbewahrungsfristen und programmgesteuerten API-Zugriff zum Abrufen von Protokollen.

Sollten bei Ihnen andere Fehlercodes auftreten, teilen Sie uns dies bitte über ein Ticket mit. Wir helfen Ihnen gerne weiter.