Resumen
Un tester de RPC es cualquier herramienta o script que envía solicitudes JSON-RPC a un endpoint de blockchain e informa si el endpoint responde correctamente, con qué consistencia responde y si devuelve los datos que tu aplicación espera. Los desarrolladores buscan uno cuando tienen una URL de endpoint en mano y necesitan saber si es seguro desplegarla, o cuando una app está fallando y necesitan separar los problemas del endpoint de los bugs de la aplicación.
Los resultados de búsqueda para esta consulta mezclan dos cosas muy diferentes: clientes genéricos de prueba RPC TCP/Windows y verificadores de endpoints JSON-RPC de Web3. Para el trabajo con blockchain, solo importa la segunda categoría. Un tester de RPC de Web3 útil comprueba la identidad de la cadena, el soporte de métodos, la forma de las respuestas, el comportamiento ante errores y la estabilidad bajo llamadas repetidas, no solo si un puerto está abierto.
Esta página explica qué probar, cómo ejecutar las comprobaciones tú mismo con curl y JavaScript, y cuándo basta con una prueba rápida frente a cuándo necesitas una API RPC gestionada o un nodo dedicado de un proveedor como OnFinality.
Puntos clave
- Un tester de RPC de blockchain debe verificar la identidad de la cadena, el soporte de métodos, la forma de las respuestas y el comportamiento ante errores, no solo la conectividad TCP.
- Empieza con eth_chainId y una consulta de bloque conocido para confirmar que estás hablando con la red correcta.
- Prueba exactamente los métodos que usa tu app, incluidas las llamadas archive y trace si tu carga de trabajo depende de ellas.
- Mide el comportamiento bajo solicitudes repetidas y concurrentes, no una sola llamada en caliente.
- Comprueba las respuestas de error: un buen endpoint devuelve errores JSON-RPC estructurados, no HTML ni cuerpos vacíos.
- Si un endpoint supera las pruebas básicas pero falla en producción, la brecha suele ser los límites de tasa, la profundidad de archive o el soporte de WebSocket.
- Las API RPC gestionadas y los nodos dedicados de OnFinality son opciones cuando las autopruebas muestran que un endpoint público no es suficiente.
Respuesta rápida: qué debería decirte un tester de RPC
Un tester de RPC de blockchain responde a cuatro preguntas: ¿está vivo este endpoint?, ¿está en la cadena que espero?, ¿admite los métodos que llamo? y ¿se comporta de forma consistente cuando lo llamo repetidamente? Si una herramienta solo responde a la primera pregunta, es un verificador de conectividad, no un tester de RPC.
La prueba manual más rápida es un POST JSON-RPC con curl. Si devuelve un resultado válido para eth_chainId y eth_blockNumber, el endpoint es accesible y habla JSON-RPC. Eso es la línea de salida, no la de meta.
- Identidad de la cadena: eth_chainId debe coincidir con la red que pretendes usar.
- Soporte de métodos: los métodos que llama tu app deben devolver resultados, no errores de método no encontrado.
- Forma de las respuestas: los resultados deben coincidir con la especificación JSON-RPC de ese método.
- Comportamiento ante errores: las solicitudes no válidas deben devolver errores estructurados, no HTML ni tiempos de espera.
- Estabilidad: las llamadas repetidas y concurrentes no deben degradarse de forma inesperada.
Guía de decisión: ¿comprobación rápida, RPC gestionado o nodo dedicado?
Usa los resultados de tus pruebas para decidir qué tipo de endpoint necesitas. Un endpoint público que supera las comprobaciones básicas puede servir para un prototipo, un script o una billetera que estás probando localmente. Rara vez es suficiente para una aplicación con usuarios reales, porque los endpoints compartidos aplican límites de tasa y pueden no exponer métodos archive o trace.
Si tus pruebas pasan pero el tráfico de producción provoca fallos, el endpoint no es el problema que debas resolver probando más a fondo: necesitas un nivel de servicio diferente. Una API RPC gestionada te da un endpoint con clave y límites documentados. Un nodo dedicado te da recursos aislados cuando tu carga de trabajo necesita profundidad de archive, alto volumen de solicitudes o un comportamiento predecible.
| Criterio | Qué revisar | Por qué importa |
|---|---|---|
| Prototipo o script local | Las comprobaciones básicas de chain ID y número de bloque pasan | Un endpoint público suele ser suficiente mientras validas la lógica. |
| App con usuarios reales | Límites de tasa, cobertura de métodos y manejo de errores bajo carga | Los endpoints compartidos pueden limitar o rechazar ráfagas que genera una app en producción. |
| Dependencia de archive o trace | Las llamadas a estado histórico y los métodos trace/debug devuelven resultados | Muchos endpoints públicos podan el estado antiguo o desactivan por completo los métodos trace. |
| Rendimiento alto o en ráfagas | Comportamiento bajo solicitudes concurrentes y carga sostenida | Una sola llamada en caliente te dice poco sobre cómo maneja el tráfico el endpoint. |
| Suscripciones WebSocket | Los métodos de suscripción se conectan y entregan eventos | Los endpoints solo HTTP harán fallar las apps que dependen de flujos de eventos en tiempo real. |
Ejecuta las primeras comprobaciones con curl
Empieza con dos llamadas: eth_chainId para confirmar la red y eth_blockNumber para confirmar que el endpoint sigue la cabeza de la cadena. Ambas son baratas y funcionan en cualquier endpoint compatible con EVM.
Sustituye la URL de marcador de posición por el endpoint que estás probando. Si aún no tienes uno, explora las redes compatibles para encontrar el endpoint de tu cadena.
curl -s -X POST <YOUR_RPC_URL> -H 'Content-Type: application/json' -d '{"jsonrpc":"2.0","id":1,"method":"eth_chainId","params":[]}'curl -s -X POST <YOUR_RPC_URL> -H 'Content-Type: application/json' -d '{"jsonrpc":"2.0","id":2,"method":"eth_blockNumber","params":[]}'curl -s -X POST <YOUR_RPC_URL> -H 'Content-Type: application/json' -d '{"jsonrpc":"2.0","id":3,"method":"eth_getBalance","params":["0x0000000000000000000000000000000000000000","latest"]}'
Prueba los métodos que tu app llama realmente
Un tester de RPC genérico comprueba métodos comunes. Tu aplicación tiene un perfil de métodos específico, y ese perfil es lo que importa. Si tu app lee logs, prueba eth_getLogs con un rango de bloques realista. Si lee el estado de un contrato en bloques históricos, prueba eth_call con un número de bloque pasado. Si depende del trazado, prueba debug_traceTransaction o trace_block y espera que muchos endpoints los rechacen.
La tabla siguiente relaciona tipos comunes de carga de trabajo con los métodos que vale la pena probar y el fallo que intentas detectar.
| Criterio | Qué revisar | Por qué importa |
|---|---|---|
| Billetera o visualización de saldo | eth_getBalance, eth_getTransactionCount, eth_call | Son las llamadas que más hacen los usuarios; los fallos aquí son visibles de inmediato. |
| Indexación de eventos | eth_getLogs con rangos de bloques y filtros de topics realistas | Las consultas de logs suelen estar limitadas por tasa o acotadas por rango de bloques en endpoints compartidos. |
| Analítica histórica | eth_call y eth_getStorageAt en números de bloque antiguos | Los endpoints podados devuelven errores para estado que ya no está disponible. |
| Depuración de transacciones | debug_traceTransaction, trace_block | Los métodos trace se desactivan con frecuencia en endpoints públicos y compartidos. |
| UI en tiempo real | eth_subscribe sobre WebSocket | Los endpoints solo HTTP no pueden entregar suscripciones en absoluto. |
Sondea la estabilidad con un pequeño script
Una sola llamada exitosa demuestra que el endpoint funciona una vez. Un script corto que envía solicitudes repetidas y concurrentes muestra si aguanta. El ejemplo siguiente usa fetch y mide la latencia y la tasa de errores en un lote de llamadas. Ejecútalo desde la misma región y condiciones de red que tu aplicación, porque los resultados de un portátil en otro continente no son representativos.
Trata las cifras como señales relativas, no como benchmarks absolutos. Compara endpoints entre sí en las mismas condiciones en lugar de contra un objetivo fijo.
- Envía al menos 50 llamadas secuenciales y registra la tasa de éxito y la distribución de latencia.
- Envía una pequeña ráfaga concurrente y comprueba si los errores son errores JSON-RPC estructurados o tiempos de espera.
- Repite la ejecución a distintas horas del día para ver si el comportamiento cambia.
- Registra el cuerpo de respuesta sin procesar de los fallos para poder distinguir el límite de tasa de los errores de método.
Lee las respuestas de error, no solo los éxitos
Muchos problemas de endpoints se esconden en el manejo de errores. Un endpoint bien comportado devuelve un objeto de error JSON-RPC con un código y un mensaje cuando una solicitud no es válida o un método no es compatible. Un endpoint mal configurado o un proxy delante de él puede devolver HTML, un cuerpo vacío o un error HTTP genérico, lo que rompe las librerías cliente de formas confusas.
Prueba deliberadamente solicitudes incorrectas: un método desconocido, un parámetro mal formado y una solicitud de un bloque que no existe. La forma de esas respuestas te dice cuánto puedes confiar en el endpoint cuando algo sale mal en producción.
| Criterio | Qué revisar | Por qué importa |
|---|---|---|
| Método desconocido | Error JSON-RPC estructurado con un código de método no encontrado | Confirma que el endpoint habla JSON-RPC en lugar de devolver una página de error de proxy. |
| Parámetros mal formados | Error de parámetros no válidos, no un fallo ni un tiempo de espera | Muestra que el endpoint valida la entrada y falla de forma predecible. |
| Bloque inexistente | Resultado nulo o un error claro para un bloque más allá de la cabeza de la cadena | Te ayuda a manejar correctamente las condiciones de carrera en torno a la cabeza de la cadena. |
| Respuesta de límite de tasa | HTTP 429 o un error de límite de tasa documentado | Permite que tu cliente aplique backoff en lugar de reintentar a ciegas. |
Cuando una prueba superada no es suficiente
Un endpoint puede superar todas las comprobaciones de esta página y aun así fallar en producción, porque las pruebas se ejecutaron con poco volumen desde una sola ubicación. Las brechas habituales son los límites de tasa que solo aparecen con tráfico real, la profundidad de archive que solo importa cuando un usuario solicita datos antiguos y el soporte de WebSocket que solo importa cuando una UI se suscribe a eventos.
Si tus pruebas revelan esas brechas, el siguiente paso es un nivel de servicio, no otra prueba. OnFinality ofrece acceso a la API RPC en las redes compatibles e infraestructura de nodos dedicados cuando necesitas recursos aislados. Consulta los precios de RPC para comparar planes y revisa la lista de redes compatibles para confirmar que tu cadena está disponible.
- Límites de tasa: comprueba los límites documentados y prueba una ráfaga que se parezca a tu tráfico máximo.
- Profundidad de archive: confirma que el estado histórico está disponible si tu app consulta bloques antiguos.
- WebSocket: confirma que las suscripciones funcionan si tu app necesita eventos en tiempo real.
- Failover: decide qué hace tu cliente cuando el endpoint principal devuelve errores.
Preguntas frecuentes
¿Qué es un tester de RPC?
Un tester de RPC es una herramienta o script que envía solicitudes JSON-RPC a un endpoint de blockchain e informa si responde correctamente, qué métodos admite y cómo se comporta bajo llamadas repetidas. Para el trabajo con Web3, debe comprobar la identidad de la cadena, el soporte de métodos, la forma de las respuestas y el comportamiento ante errores, no solo la conectividad TCP.
¿Puedo probar un endpoint RPC con curl?
Sí. Un POST JSON-RPC con curl basta para comprobar eth_chainId, eth_blockNumber y el soporte básico de métodos. Úsalo como primera pasada y luego ejecuta un pequeño script para llamadas repetidas y concurrentes si necesitas evaluar la estabilidad.
¿Por qué mi endpoint supera una prueba básica pero falla en mi app?
Las razones más comunes son los límites de tasa con tráfico real, la falta de métodos archive o trace y la ausencia de soporte de WebSocket. Una prueba básica se ejecuta con poco volumen y puede no llamar a los métodos de los que depende tu app.
¿Cómo sé si un endpoint admite datos de archive?
Llama a eth_getBalance o eth_call con un número de bloque muy anterior a la cabeza de la cadena. Si el endpoint devuelve un resultado, tiene ese estado disponible. Si devuelve un error sobre estado faltante, el endpoint está podado o limita las consultas históricas.
¿Debería usar un endpoint público en producción?
Los endpoints públicos son útiles para pruebas y prototipos, pero son compartidos y normalmente tienen límites de tasa. Para aplicaciones con usuarios reales, una API RPC gestionada o un nodo dedicado te dan límites documentados y un comportamiento más predecible.
Ethereum
Solana
Polygon
Base
Arbitrum
BNB Chain
Polkadot
Optimism
