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

RPC-statuscontrole

Test JSON-RPC-endpoints vanuit uw browser
Resultaat0 bevindingen

    Verzoeken gaan rechtstreeks van deze browser naar het endpoint

    Inleiding

    De RPC-statuscontrole test JSON-RPC-endpoints van Ethereum (EVM), Solana en Cosmos (CometBFT) en rapporteert latentie, chain-ID, hoogte, sync-status en peer-aantal. Dit is nuttig voordat u een toepassing, indexer of wallet op een nieuw endpoint richt, en voor het vergelijken van twee endpoints van hetzelfde netwerk.

    Elk verzoek gaat rechtstreeks vanuit uw browser naar het endpoint. Er is geen proxy en geen serveroproep: het hulpmiddel bouwt de JSON-RPC-payloads lokaal op, meet de rondetijd en classificeert het resultaat. Blokkeert het endpoint de browser via CORS, dan legt het hulpmiddel uit waarom en toont het een equivalent curl-commando dat u zelf kunt uitvoeren.

    Doel

    • De endpoint-URL valideren en onveilige schema's weigeren (file:, javascript:, data:, ftp:).
    • De standaard health-methoden voor Ethereum, Solana of Cosmos testen en de latentie meten.
    • Het endpoint classificeren als gezond, synchroniserend, achter, niet beschikbaar of niet conclusief.
    • Optioneel twee endpoints van hetzelfde netwerk vergelijken op hoogteverschil, chain-ID-afwijking en versieverschillen.
    • Nooit beweren dat een endpoint betrouwbaar is alleen omdat het antwoordde.

    Invoerwaarden

    • Een of twee endpoint-URL's (https:// heeft de voorkeur).
    • Het ketentype: Ethereum (EVM), Solana of Cosmos (CometBFT).
    • Niets wordt opgeslagen, gelogd of naar de OthoTools-server verzonden.

    Hoe het werkt

    De URL wordt geparseerd en gevalideerd: alleen http(s) is toegestaan, https heeft de voorkeur; userinfo of tokenachtige queryparameters worden gedetecteerd en gemaskeerd vóór weergave. HTTP op een publieke host wordt geweigerd omdat browsers dit als mixed content blokkeren.

    Voor Ethereum roept het hulpmiddel web3_clientVersion, eth_chainId, eth_blockNumber, eth_syncing en net_peerCount aan. Voor Solana getHealth, getSlot, getVersion en getIdentity. Voor Cosmos de REST-endpoints /status en /net_info.

    Elke oproep wordt getimed. De resultaten worden genormaliseerd tot een uitkomst (hoogte, chain-ID, versie, peers, sync-status, latentie) en geclassificeerd: gezond wanneer de node met een actuele hoogte antwoordt en niet synchroniseert; synchroniserend wanneer de node inhaalt; achter wanneer een vergelijking een groot hoogteverschil toont; niet beschikbaar wanneer de aanvraag faalt of een JSON-RPC-fout retourneert; niet conclusief wanneer de vorm van de respons onverwacht is.

    Met twee endpoints worden hoogtes, chain-ID's, versies en latenties vergeleken en worden verschillen als bevindingen gerapporteerd.

    Testbaar voorbeeld

    Probeer het — de analyse draait lokaal in uw browser.

    Voorbeeld

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

(tweede endpoint, optionele vergelijking)
https://eth2.example.com

    Verwachte uitvoer

    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: gezond — antwoord in gemiddeld ~205 ms.

    De uitvoer lezen

    • Een gezond resultaat betekent dat het endpoint de standaardmethoden beantwoordt en geen sync-voortgang meldt. Het bewijst niet dat de node betrouwbaar, correct geconfigureerd of veilig is voor het verzenden van fondsen.
    • Synchroniserend betekent dat de node inhaalt; toepassingen die actuele staat nodig hebben, zien verouderde of ontbrekende gegevens totdat het klaar is.
    • Een hoogteverschil tussen twee endpoints van hetzelfde netwerk is normaal tijdens korte reorgs; een groot of aanhoudend verschil wijst op een zieke of gepartitioneerde node.
    • Blokkeert CORS het verzoek, dan staat het endpoint geen browserorigins toe. Voer het equivalente curl-commando uit vanaf een machine die u vertrouwt om dezelfde gegevens te krijgen.

    Risico's

    • Een antwoordend endpoint kan nog steeds verouderde, onjuiste of kwaadaardige gegevens leveren. Gezondheid is geen vertrouwen.
    • URL's kunnen inloggegevens bevatten. Het hulpmiddel maskeert ze, maar verwijder ze uit de URL vóór u deze deelt.
    • Publieke endpoints kunnen herhaalde tests beperken of blokkeren; gebruik dit hulpmiddel niet als monitoring-daemon.

    Beperkingen

    • CORS-beleid van de browser kan legitieme publieke endpoints blokkeren; de curl-fallback dekt die gevallen.
    • Het hulpmiddel controleert een momentopname; het is geen uptime-monitoring.
    • Het kan geen consensusproblemen, fee-marktmanipulatie of verkeerde configuratie buiten de geteste methoden detecteren.

    Officiële referenties

    FAQ

    Is het veilig om hier een RPC-URL te plakken?

    Ja — het verzoek gaat rechtstreeks vanuit uw browser en nooit via de OthoTools-server. Het hulpmiddel maskeert toch inloggegevens en tokenachtige parameters op het scherm en beveelt aan ze vóór het delen te verwijderen.

    Waarom faalt een publiek endpoint met CORS?

    De server van het endpoint bepaalt welke browserorigins het mogen aanroepen. Veel publieke RPC's sturen geen CORS-headers, dus blokkeert de browser het verzoek ook al draait het endpoint. Voor dat geval toont het hulpmiddel een curl-commando.

    Wat betekent 'achter'?

    Het komt uit de twee-endpointvergelijking: het hoogteverschil tussen de endpoints overschrijdt de drempel voor die chain (12 blokken voor Ethereum, 150 slots voor Solana, 10 blokken voor Cosmos). Een single-endpointcontrole kan 'achter' niet bepalen zonder referentie.