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

Verifica stato RPC

Sonda endpoint JSON-RPC dal browser
Risultato0 risultati

    Le richieste vanno direttamente da questo browser all'endpoint

    Introduzione

    La verifica stato RPC sonda gli endpoint JSON-RPC di Ethereum (EVM), Solana e Cosmos (CometBFT) e riporta latenza, chain ID, altezza, stato di sync e numero di peer. È utile prima di puntare un'applicazione, un indexer o un wallet a un nuovo endpoint, e per confrontare due endpoint della stessa rete.

    Ogni richiesta parte direttamente dal tuo browser verso l'endpoint. Non esiste un proxy né una chiamata lato server: lo strumento costruisce i payload JSON-RPC localmente, misura il tempo di risposta e classifica l'esito. Se l'endpoint blocca il browser con CORS, lo strumento spiega il motivo e mostra un comando curl equivalente che puoi eseguire tu stesso.

    Obiettivo

    • Validare l'URL dell'endpoint e rifiutare schemi non sicuri (file:, javascript:, data:, ftp:).
    • Sondare i metodi di health standard per Ethereum, Solana o Cosmos e misurare la latenza.
    • Classificare l'endpoint come sano, in sync, indietro, non disponibile o inconcludente.
    • Confrontare opzionalmente due endpoint della stessa rete per differenza di altezza, divergenza di chain ID e differenze di versione.
    • Non dichiarare mai affidabile un endpoint solo perché ha risposto.

    Input

    • Una o due URL di endpoint (https:// preferito).
    • Il tipo di chain: Ethereum (EVM), Solana o Cosmos (CometBFT).
    • Nulla viene memorizzato, registrato o inviato al server OthoTools.

    Come funziona

    L'URL viene analizzato e validato: sono ammessi solo http(s), https è preferito; userinfo o parametri query simili a token vengono rilevati e mascherati prima della visualizzazione. HTTP su un host pubblico viene rifiutato perché i browser lo bloccano come mixed content.

    Per Ethereum lo strumento chiama web3_clientVersion, eth_chainId, eth_blockNumber, eth_syncing e net_peerCount. Per Solana getHealth, getSlot, getVersion e getIdentity. Per Cosmos gli endpoint REST /status e /net_info.

    Ogni chiamata viene cronometrata. I risultati vengono normalizzati in un esito (altezza, chain ID, versione, peer, stato di sync, latenza) e classificati: sano quando il nodo risponde con un'altezza attuale e non è in sync; in sync quando riporta progressi di recupero; indietro quando un confronto mostra una grande differenza di altezza; non disponibile quando la richiesta fallisce o restituisce un errore JSON-RPC; inconcludente quando la forma della risposta è inattesa.

    Con due endpoint, altezze, chain ID, versioni e latenze vengono confrontati e le differenze riportate come risultati.

    Esempio testabile

    Prova — l'analisi gira localmente nel tuo browser.

    Esempio

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

(secondo endpoint, confronto opzionale)
https://eth2.example.com

    Output atteso

    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
Stato: sano — risposta in ~205 ms di media.

    Leggere l'output

    • Un risultato sano significa che l'endpoint risponde ai metodi standard e non riporta progressi di sync. Non prova che il nodo sia affidabile, configurato correttamente o sicuro per inviare fondi.
    • In sync significa che il nodo sta recuperando; le applicazioni che richiedono stato recente vedranno dati obsoleti o mancanti finché non finisce.
    • Una differenza di altezza tra due endpoint della stessa rete è normale durante brevi reorg; una differenza ampia o persistente suggerisce un nodo malato o partizionato.
    • Se CORS blocca la richiesta, l'endpoint non consente origini browser. Esegui il comando curl equivalente da una macchina di cui ti fidi per ottenere gli stessi dati.

    Rischi

    • Un endpoint che risponde può comunque servire dati obsoleti, errati o malevoli. La salute non è fiducia.
    • Le URL possono contenere credenziali. Lo strumento le maschera, ma rimuovile dall'URL prima di condividerla.
    • Gli endpoint pubblici possono limitare o bloccare le sonde ripetute; non usare questo strumento come daemon di monitoraggio.

    Limiti

    • Le policy CORS del browser possono bloccare endpoint pubblici legittimi; il fallback curl copre questi casi.
    • Lo strumento controlla un'istantanea nel tempo; non è monitoraggio di uptime.
    • Non può rilevare problemi a livello di consenso, manipolazione del fee market o misconfigurazioni oltre i metodi sondati.

    Riferimenti ufficiali

    FAQ

    È sicuro incollare qui un'URL RPC?

    Sì — la richiesta parte direttamente dal tuo browser e non passa mai dal server OthoTools. Lo strumento maschera comunque credenziali e parametri simili a token a schermo e raccomanda di rimuoverli prima di condividere.

    Perché un endpoint pubblico fallisce con CORS?

    Il server dell'endpoint decide quali origini browser possono chiamarlo. Molti RPC pubblici non inviano header CORS, quindi il browser blocca la richiesta anche se l'endpoint è attivo. Per quel caso lo strumento mostra un comando curl.

    Cosa significa 'indietro'?

    Deriva dal confronto a due endpoint: la differenza di altezza tra i due supera la soglia di quella chain (12 blocchi per Ethereum, 150 slot per Solana, 10 blocchi per Cosmos). Un controllo a endpoint singolo non può determinare 'indietro' senza un riferimento.