Resumen
Si buscaste "rpc test" y terminaste en tiras de cloro o en el puerto 135 de RPC de Windows, estás en el lugar equivocado. En Web3, una prueba de RPC es el proceso de verificar si un endpoint de nodo de blockchain realmente funciona para tu aplicación: responde a los métodos JSON-RPC que necesitas, devuelve datos correctos, maneja tu volumen de solicitudes y falla de manera predecible. Una llamada rápida a eth_blockNumber es una prueba de humo, no una prueba de producción.
Esta página te ofrece un flujo de trabajo de pruebas práctico que puedes ejecutar contra cualquier endpoint EVM, incluidos la API RPC y los nodos dedicados de OnFinality. Cubre qué probar, cómo interpretar los fallos y cuándo un endpoint compartido es suficiente frente a cuándo necesitas infraestructura dedicada.
Úsalo como una lista de verificación antes de lanzar: prueba la conectividad, el soporte de métodos, la profundidad de archivo, el comportamiento de WebSocket y el manejo de errores. Luego decide si mantener el endpoint, agregar un respaldo o pasar a un nodo dedicado.
Puntos clave
- Una prueba de RPC verifica más que la conectividad: el soporte de métodos, la corrección de datos, la profundidad de archivo, el comportamiento de WebSocket y el manejo de errores son importantes.
- Comienza con una llamada JSON-RPC mínima como eth_blockNumber, luego amplía a los métodos que tu aplicación realmente usa.
- Prueba los métodos de archivo y trace por separado; muchos endpoints públicos responden a llamadas básicas pero rechazan el estado histórico o las llamadas de depuración.
- Las suscripciones WebSocket necesitan su propia prueba porque el éxito de HTTP no garantiza la entrega de mensajes push.
- Registra los modos de fallo (tiempos de espera, respuestas de límite de velocidad, JSON malformado) para que puedas diseñar reintentos y respaldos.
- Si tus pruebas muestran límites repetidos o métodos faltantes, evalúa un nodo dedicado o un proveedor de RPC gestionado como OnFinality.
Qué necesita demostrar realmente una prueba de RPC
Una prueba de RPC de blockchain responde una pregunta: ¿puede este endpoint servir el tráfico real de mi aplicación sin sorpresas? Eso es más amplio que un ping. Un nodo puede aceptar conexiones TCP y aún así devolver errores para los métodos de los que dependes, o devolver datos obsoletos porque está retrasado respecto de la cabeza de la cadena.
El conjunto de pruebas práctico tiene cinco capas: alcanzabilidad del transporte, corrección de JSON-RPC, cobertura de métodos, comportamiento de capacidad y comportamiento de fallo. Cada capa detecta una clase diferente de problema, y omitir una capa es cómo los endpoints pasan en staging y fallan en producción.
- Transporte: ¿puedes alcanzar el endpoint a través de HTTPS o WSS desde tu entorno de despliegue?
- Corrección: ¿un método conocido devuelve un resultado plausible y actual?
- Cobertura: ¿los métodos específicos que llama tu aplicación tienen éxito, incluidas las llamadas de archivo y trace?
- Capacidad: ¿qué sucede bajo tu tasa de solicitudes esperada y patrón de ráfagas?
- Comportamiento de fallo: ¿qué devuelve el endpoint cuando se limita la velocidad, se sobrecarga o le faltan datos?
Recomendación rápida: primero prueba de humo, luego pruebas específicas
Si solo tienes un minuto, ejecuta una única llamada JSON-RPC y confirma que obtienes una respuesta válida con un número de bloque reciente. Eso te dice que el endpoint está vivo y habla JSON-RPC. No te dice que esté listo para producción.
Si estás eligiendo un endpoint para una aplicación, ejecuta la prueba de humo, luego prueba los métodos exactos que llama tu aplicación, luego prueba bajo carga. Si alguna capa falla, detente y corrige esa capa antes de continuar. Probar todo a la vez hace que los fallos sean difíciles de atribuir.
| Criterio | Qué revisar | Por qué importa |
|---|---|---|
| Prueba de humo | eth_blockNumber devuelve un número de bloque hexadecimal que avanza con el tiempo | Confirma que el endpoint es alcanzable y está sincronizando, no solo aceptando conexiones |
| Cobertura de métodos | Cada método que llama tu aplicación devuelve un resultado válido o un error claro | Los endpoints compartidos a menudo restringen métodos de archivo, trace o debug |
| Corrección de datos | Compara un bloque o transacción conocida con una segunda fuente | Detecta nodos obsoletos o inconsistentes antes de que corrompan el estado de la aplicación |
| Comportamiento de capacidad | Tiempos de respuesta y tasas de error a tu tasa de solicitudes esperada | Muestra si el endpoint puede absorber tu tráfico normal y de ráfagas |
| Comportamiento de fallo | Códigos de estado y cuerpos de error cuando se alcanzan los límites | Determina cómo debe escribirse tu lógica de reintentos y respaldos |
Ejecuta una prueba JSON-RPC mínima
Comienza con curl para que puedas ver la respuesta sin procesar. Una respuesta válida tiene una versión JSON-RPC, un id que coincide con tu solicitud y un objeto result o error. Si obtienes HTML, una redirección o un cuerpo que no es JSON, el endpoint no está hablando JSON-RPC en esa URL.
Reemplaza la URL de marcador de posición con el endpoint de tu proveedor o tu propio nodo. No asumas que una URL funciona porque parece correcta; confírmalo siempre con una llamada real.
curl -s -X POST <YOUR_RPC_URL> -H 'Content-Type: application/json' -d '{"jsonrpc":"2.0","id":1,"method":"eth_blockNumber","params":[]}'- Ejecútalo dos veces con unos segundos de diferencia y confirma que el número de bloque aumenta.
- Verifica el código de estado HTTP y también el cuerpo JSON; algunos fallos devuelven 200 con un objeto de error.
Prueba los métodos que tu aplicación realmente llama
Cada aplicación tiene un perfil de métodos. Una billetera lee saldos y nonces. Un indexador lee registros y bloques. Un bot de trading puede necesitar transacciones pendientes y suscripciones WebSocket. Prueba ese perfil directamente en lugar de probar una lista genérica.
Los métodos de archivo y trace merecen atención especial. Muchos endpoints responden a llamadas de estado actual pero rechazan el estado histórico o las llamadas de depuración. Si tu aplicación necesita saldos históricos o trazas de transacciones, pruébalos explícitamente y registra el error exacto que obtienes cuando no están disponibles.
| Criterio | Qué revisar | Por qué importa |
|---|---|---|
| eth_getBalance | Saldo actual de una dirección conocida | Ruta de lectura básica de billetera y panel |
| eth_getLogs | Registros para un rango de bloques acotado | Los indexadores y las aplicaciones basadas en eventos dependen de los límites de rango y el tamaño de los resultados |
| eth_getBlockByNumber | Un bloque histórico por número | Confirma la profundidad de archivo si solicitas bloques antiguos |
| debug_traceTransaction | Traza de una transacción conocida | A menudo deshabilitado en endpoints compartidos; necesario para depuración y análisis |
| eth_subscribe | La suscripción WebSocket entrega nuevas cabezas | El éxito de HTTP no prueba que funcione la entrega push |
Prueba el comportamiento de WebSocket por separado
Los endpoints WebSocket fallan de manera diferente a los endpoints HTTP. Una conexión puede abrirse y luego no entregar nada, o caerse después de un período de inactividad. Prueba que recibes mensajes de suscripción, que las reconexiones funcionan y que tu cliente maneja las conexiones caídas sin perder el estado.
Usa un pequeño script o un cliente WebSocket para suscribirte a nuevas cabezas y registrar marcas de tiempo. Si los mensajes dejan de llegar mientras la cadena sigue produciendo bloques, tienes un problema de entrega, no un problema de cadena.
- Abre una conexión WSS y envía una solicitud eth_subscribe para newHeads.
- Registra cada mensaje con una marca de tiempo y confirma que los mensajes llegan a un ritmo constante.
- Mata la conexión y confirma que tu cliente se reconecta y se vuelve a suscribir.
- Deja la conexión inactiva por un tiempo y verifica si el servidor la cierra.
Lee las respuestas de fallo antes de necesitarlas
La parte más útil de una prueba de RPC es la respuesta de fallo. Cuando un endpoint tiene límite de velocidad o está sobrecargado, puede devolver HTTP 429, un objeto de error JSON-RPC o un tiempo de espera. Cada uno requiere un comportamiento diferente del cliente. Captura la respuesta exacta para que puedas escribir una lógica de reintentos que no empeore el problema.
También prueba qué sucede cuando envías una solicitud malformada o un método no soportado. Un endpoint bien comportado devuelve un error JSON-RPC estructurado; un proxy mal configurado puede devolver HTML o un cuerpo vacío.
| Criterio | Qué revisar | Por qué importa |
|---|---|---|
| HTTP 429 o error de límite de velocidad | Encabezado Retry-After o mensaje de error | Te dice si debes retroceder y por cuánto tiempo |
| Objeto de error JSON-RPC | Código de error y mensaje para métodos no soportados | Distingue las restricciones de métodos de los fallos de transporte |
| Tiempo de espera o restablecimiento de conexión | Si el endpoint se recupera al reintentar | Indica capacidad o inestabilidad de red en lugar de un error de código |
| Respuesta no JSON | HTML, redirección o cuerpo vacío | Generalmente es una URL incorrecta, un problema de proxy o un problema de autenticación |
Decide si mantener, usar un respaldo o pasar a infraestructura dedicada
Después de las pruebas, tienes tres opciones: mantener el endpoint tal como está, mantenerlo con un respaldo o pasar a infraestructura dedicada. La elección correcta depende de qué capas fallaron y con qué frecuencia.
Si el endpoint pasa las pruebas de humo y de métodos pero muestra respuestas de límite de velocidad bajo tu carga esperada, un respaldo o un plan de nivel superior puede ser suficiente. Si rechaza los métodos de archivo o trace que necesitas, o si no puedes obtener capacidad predecible, un nodo dedicado es el camino más limpio. OnFinality ofrece tanto endpoints de API RPC gestionados como nodos dedicados, para que puedas probar el mismo flujo de trabajo contra cualquiera de los dos.
- Mantén tal como está cuando todas las capas pasan con tu carga y perfil de métodos esperados.
- Agrega un respaldo cuando el endpoint principal está saludable pero quieres resiliencia ante incidentes regionales o del proveedor.
- Pasa a dedicado cuando las restricciones de métodos, los límites de capacidad o los requisitos de aislamiento bloquean tu aplicación.
- Vuelve a ejecutar la prueba después de cualquier cambio de plan o proveedor; el comportamiento del endpoint puede variar según el nivel.
Preguntas frecuentes
¿Qué es una prueba de RPC en Web3?
Una prueba de RPC verifica si un endpoint de nodo de blockchain puede servir correctamente las solicitudes JSON-RPC de tu aplicación. Cubre conectividad, soporte de métodos, corrección de datos, comportamiento de capacidad y respuestas de fallo, no solo si la URL responde.
¿Es suficiente eth_blockNumber para probar un endpoint?
No. eth_blockNumber es una prueba de humo útil, pero no demuestra que funcionen las llamadas de archivo, los métodos trace, las consultas de registros o las suscripciones WebSocket. Prueba los métodos que tu aplicación realmente usa.
¿Por qué mi endpoint funciona en curl pero falla en mi aplicación?
Las causas comunes incluyen encabezados faltantes, método HTTP incorrecto, tiempos de espera del lado del cliente, desajuste entre WebSocket y HTTP, o que la aplicación llame a métodos que el endpoint restringe. Compara la solicitud sin procesar que envía tu aplicación con la solicitud curl que funcionó.
¿Cómo pruebo un endpoint RPC de archivo?
Solicita un bloque histórico o un saldo por número de bloque que sea más antiguo que la ventana de poda del nodo. Si el endpoint devuelve un error o datos faltantes, no está sirviendo el estado de archivo para ese rango.
¿Cuándo debo usar un nodo dedicado en lugar de un endpoint RPC compartido?
Considera un nodo dedicado cuando necesites métodos que los planes compartidos restringen, capacidad predecible para tráfico sostenido o en ráfagas, o aislamiento de otros usuarios. Prueba tu carga de trabajo contra ambas opciones antes de decidir.
Ethereum
Solana
Polygon
Base
Arbitrum
BNB Chain
Polkadot
Optimism
