OTOthoTools
Language
enen-AUen-GBen-CAdede-CHithipt-BRnlno
⌁

RPC-Statusprüfer

JSON-RPC-Endpunkte aus dem Browser prüfen
Ergebnis0 Befunde

    Anfragen gehen direkt von diesem Browser an den Endpunkt

    Einführung

    Der RPC-Statusprüfer testet JSON-RPC-Endpunkte von Ethereum (EVM), Solana und Cosmos (CometBFT) und meldet Latenz, Chain-ID, Höhe, Sync-Status und Peer-Anzahl. Er ist nützlich, bevor eine Anwendung, ein Indexer oder eine Wallet einen neuen Endpunkt nutzt, und zum Vergleich zweier Endpunkte desselben Netzwerks.

    Jede Anfrage geht direkt von Ihrem Browser an den Endpunkt. Es gibt keinen Proxy und keinen Serveraufruf: Das Werkzeug baut die JSON-RPC-Payloads lokal, misst die Antwortzeit und bewertet das Ergebnis. Blockiert der Endpunkt den Browser per CORS, erklärt das Werkzeug den Grund und zeigt einen gleichwertigen curl-Befehl, den Sie selbst ausführen können.

    Ziel

    • Die Endpunkt-URL validieren und unsichere Schemata ablehnen (file:, javascript:, data:, ftp:).
    • Die Standard-Health-Methoden für Ethereum, Solana oder Cosmos abfragen und die Latenz messen.
    • Den Endpunkt als gesund, synchronisierend, zurückliegend, nicht erreichbar oder unklar einstufen.
    • Optional zwei Endpunkte desselben Netzwerks auf Höhenabstand, Chain-ID-Divergenz und Versionsunterschiede vergleichen.
    • Nie behaupten, ein Endpunkt sei nur deshalb vertrauenswürdig, weil er geantwortet hat.

    Eingaben

    • Eine oder zwei Endpunkt-URLs (https:// bevorzugt).
    • Der Kettentyp: Ethereum (EVM), Solana oder Cosmos (CometBFT).
    • Nichts wird gespeichert, protokolliert oder an den OthoTools-Server gesendet.

    So funktioniert es

    Die URL wird geparst und validiert: Nur http(s) ist zulässig, https wird bevorzugt; Userinfo oder tokenartige Query-Parameter werden erkannt und vor der Anzeige maskiert. HTTP auf einem öffentlichen Host wird abgelehnt, weil Browser es als Mixed Content blockieren.

    Für Ethereum ruft das Werkzeug web3_clientVersion, eth_chainId, eth_blockNumber, eth_syncing und net_peerCount auf. Für Solana getHealth, getSlot, getVersion und getIdentity. Für Cosmos die REST-Endpunkte /status und /net_info.

    Jeder Aufruf wird zeitlich gemessen. Die Ergebnisse werden zu einem Ergebnis normalisiert (Höhe, Chain-ID, Version, Peers, Sync-Status, Latenz) und klassifiziert: gesund, wenn der Knoten mit aktueller Höhe antwortet und nicht synchronisiert; synchronisierend bei Aufhol-Fortschritt; zurückliegend, wenn ein Vergleich einen grossen Höhenabstand zeigt; nicht erreichbar bei Fehler oder JSON-RPC-Fehler; unklar bei unerwarteter Antwortstruktur.

    Bei zwei Endpunkten werden Höhen, Chain-IDs, Versionen und Latenzen verglichen und Unterschiede als Befunde gemeldet.

    Testbares Beispiel

    Ausprobieren — die Analyse läuft lokal in Ihrem Browser.

    Beispiel

    Chain:   Ethereum
Endpunkt: https://eth.example.com
Methode:  eth_blockNumber

(zweiter Endpunkt, optionaler Vergleich)
https://eth2.example.com

    Erwartete Ausgabe

    web3_clientVersion  Geth/v1.14.11-stable/linux-arm64  ·  212 ms
eth_chainId         1                                 ·  204 ms
eth_blockNumber     21048321                          ·  198 ms
eth_syncing         false                             ·  201 ms
net_peerCount       48                                ·  215 ms
Status: gesund — Antwort in durchschnittlich ~205 ms.

    Ausgabe verstehen

    • Ein gesundes Ergebnis bedeutet, dass der Endpunkt die Standardmethoden beantwortet und keinen Sync-Fortschritt meldet. Es beweist nicht, dass der Knoten vertrauenswürdig, korrekt konfiguriert oder für Geldtransfers sicher ist.
    • Synchronisierend bedeutet, dass der Knoten aufholt; Anwendungen, die aktuellen Zustand brauchen, sehen veraltete oder fehlende Daten, bis er fertig ist.
    • Ein Höhenabstand zwischen zwei Endpunkten desselben Netzwerks ist bei kurzen Reorgs normal; ein anhaltender oder grosser Abstand deutet auf einen kranken oder partitionierten Knoten hin.
    • Blockiert CORS die Anfrage, erlaubt der Endpunkt keine Browser-Origins. Den curl-Befehl von einer vertrauenswürdigen Maschine ausführen, um dieselben Daten zu erhalten.

    Risiken

    • Ein antwortender Endpunkt kann dennoch veraltete, falsche oder bösartige Daten liefern. Gesundheit ist kein Vertrauen.
    • URLs können Zugangsdaten enthalten. Das Werkzeug maskiert sie, aber entfernen Sie Zugangsdaten aus der URL, bevor Sie sie teilen.
    • Öffentliche Endpunkte können wiederholte Tests drosseln oder blockieren; dieses Werkzeug ist kein Monitoring-Daemon.

    Grenzen

    • CORS-Richtlinien des Browsers können legitime öffentliche Endpunkte blockieren; der curl-Ersatz deckt diese Fälle ab.
    • Das Werkzeug prüft eine Momentaufnahme; es ist kein Uptime-Monitoring.
    • Es kann keine Konsensprobleme, Fee-Market-Manipulation oder Fehlkonfiguration jenseits der abgefragten Methoden erkennen.

    Offizielle Referenzen

    FAQ

    Ist es sicher, hier eine RPC-URL einzufügen?

    Ja — die Anfrage geht direkt von Ihrem Browser aus und nie über den OthoTools-Server. Das Werkzeug maskiert trotzdem Zugangsdaten und tokenartige Parameter auf dem Bildschirm und empfiehlt, sie vor dem Teilen zu entfernen.

    Warum schlägt ein öffentlicher Endpunkt mit CORS fehl?

    Der Server des Endpunkts entscheidet, welche Browser-Origins ihn aufrufen dürfen. Viele öffentliche RPCs senden keine CORS-Header, also blockiert der Browser die Anfrage, obwohl der Endpunkt läuft. Für diesen Fall zeigt das Werkzeug einen curl-Befehl.

    Was bedeutet „zurückliegend“?

    Es stammt aus dem Zwei-Endpunkt-Vergleich: Der Höhenabstand zwischen den Endpunkten überschreitet den Schwellenwert dieser Chain (12 Blöcke bei Ethereum, 150 Slots bei Solana, 10 Blöcke bei Cosmos). Ein Einzel-Endpunkt-Test kann „zurückliegend“ ohne Referenz nicht bestimmen.