Lista de RPC de BNB: ¿A qué endpoints debería conectarse tu aplicación?

Una lista de RPC de BNB es un punto de partida, no una decisión. El endpoint que elijas determina tus límites de velocidad, si puedes consultar el estado histórico, si las suscripciones WebSocket permanecen abiertas y cuánto de tu tiempo de ingeniería se destina a reintentos en lugar de al trabajo de producto.

Esta página te proporciona los detalles concretos de conexión para BNB Smart Chain mainnet y testnet, y luego explica cómo elegir entre un endpoint público, una API RPC gestionada y un nodo dedicado. Si ya sabes que quieres un endpoint BNB gestionado o dedicado, comienza en BNB Chain RPC.

Elige tu tipo de endpoint antes de copiar una URL

La mayoría de los desarrolladores que buscan una lista de RPC de BNB intentan desbloquear una de cuatro situaciones. Relaciona tu situación con la fila de abajo y ve directamente a esa sección.

Si estás en la primera fila, el endpoint público de abajo es suficiente. Si estás en las filas dos a cuatro, el resto de esta página explica qué verificar antes de comprometerte.

Configuración de conexión de BNB Smart Chain

Estos son los valores que tu wallet, SDK o configuración de infraestructura necesita. Los desajustes de Chain ID son la causa más común de informes de "transacción fallida" que resultan ser un problema de configuración de red en lugar de un problema de contrato.

Mainnet admite tanto transporte HTTP como WebSocket a través de OnFinality. Testnet es solo HTTP, lo cual importa si estás construyendo una función basada en suscripciones y probando primero contra testnet.

Una entrada de configuración de red de wallet se ve así:

{
  "chainId": "0x38",
  "chainName": "BNB Smart Chain Mainnet",
  "nativeCurrency": { "name": "BNB", "symbol": "BNB", "decimals": 18 },
  "rpcUrls": ["https://bnb.api.onfinality.io/public"],
  "blockExplorerUrls": ["https://bscscan.com"]
}

Ten en cuenta que 0x38 es 56 en hexadecimal. Las wallets rechazan la conexión si los valores hexadecimal y decimal no coinciden con el endpoint al que apuntas.

Endpoints públicos, RPC gestionado y nodos dedicados

Una lista de RPC de BNB generalmente mezcla tres productos muy diferentes bajo un mismo encabezado. No son intercambiables, y las compensaciones son operativas más que puramente técnicas.

Los endpoints públicos son compartidos, no autenticados y convenientes. Son apropiados para desarrollo, configuración de wallets y lecturas de bajo volumen. No son apropiados como único endpoint detrás de una aplicación en producción, porque no tienes control sobre cuánta capacidad compartida obtienes en un momento dado.

Las API RPC gestionadas te dan un endpoint autenticado con soporte de métodos definido, opciones de acceso a archivo y una ruta de soporte. Esta es la opción de producción común para dApps, bots y servicios backend que necesitan un comportamiento predecible sin ejecutar infraestructura. El servicio de API RPC de OnFinality entra en esta categoría, con BNB Chain disponible junto a otras redes RPC compatibles.

Los nodos dedicados te dan capacidad que no se comparte con otros clientes. Esto importa cuando tu carga de trabajo es en ráfagas de una manera que los límites compartidos no pueden absorber, cuando necesitas un comportamiento de WebSocket consistente o cuando quieres una ruta privada para el envío de transacciones. Consulta nodos dedicados para saber cómo se aprovisiona.

Qué verificar antes de comprometerte con un endpoint

Copiar una URL toma segundos. Verificarla toma unos minutos y ahorra días. Revisa esta lista con cualquier endpoint BNB que estés considerando, incluido el nuestro.

• Cobertura de métodos. Confirma que el endpoint admite los métodos que realmente llamas. eth_call, eth_getLogs, eth_getTransactionReceipt y eth_blockNumber son lo mínimo. Los métodos de trace y debug no están disponibles universalmente.
• Profundidad de archivo. Si consultas el estado en un bloque antiguo, necesitas acceso a archivo. Los nodos sin archivo devuelven errores o resultados vacíos para consultas históricas.
• Límites de rango de eth_getLogs. Las consultas de logs sobre rangos de bloques grandes son la fuente más común de tiempos de espera en BNB Chain. Pregunta qué rango se admite por solicitud.
• Comportamiento de WebSocket. Si te suscribes a newHeads o logs, confirma que el endpoint mantiene las conexiones abiertas y cómo maneja los tiempos de espera por inactividad.
• Estrategia de failover. Un solo endpoint es un único punto de fallo. Conoce qué sucede cuando se degrada.
• Límites de velocidad y comportamiento en ráfagas. Comprende tanto el límite sostenido como si se absorben ráfagas cortas.

Ejemplos de solicitudes que puedes ejecutar ahora

Comienza con una verificación básica de estado. Esto confirma que el endpoint es accesible y devuelve la altura de bloque actual.

curl -s https://bnb.api.onfinality.io/public \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_blockNumber","params":[]}'

Una respuesta exitosa devuelve un número de bloque en hexadecimal. Si en su lugar obtienes un objeto de error JSON-RPC, el endpoint es accesible pero rechaza la solicitud, lo que generalmente apunta a un problema de método o parámetro en lugar de conectividad.

Para código de aplicación, viem es una opción común:

import { createPublicClient, http } from 'viem';
import { bsc } from 'viem/chains';

const client = createPublicClient({
  chain: bsc,
  transport: http('https://bnb.api.onfinality.io/public')
});

const block = await client.getBlockNumber();
console.log('BNB Chain head:', block);

Para suscripciones de logs a través de WebSocket en mainnet:

import WebSocket from 'ws';

const ws = new WebSocket('wss://bnb.api.onfinality.io/public/ws');

ws.on('open', () => {
  ws.send(JSON.stringify({
    jsonrpc: '2.0',
    id: 1,
    method: 'eth_subscribe',
    params: ['newHeads']
  }));
});

ws.on('message', (data) => console.log(JSON.parse(data.toString())));

Si tu conexión WebSocket se cae repetidamente, eso es una señal para considerar capacidad dedicada en lugar de lógica de reintentos.

Modos de fallo y lo que suelen significar

La mayoría de los problemas de RPC de BNB caen en un pequeño número de categorías. El síntoma te dice dónde buscar.

Los errores relacionados con nonce son lo suficientemente comunes en BNB Chain como para merecer un tratamiento aparte. Si ves repetidamente errores nonce too low o nonce is already consumed, el problema suele ser la gestión de transacciones en lugar del endpoint en sí.

Ejecutar BNB Chain en producción

Una vez que superas un solo endpoint, las preguntas operativas cambian. Ya no preguntas "qué URL funciona" sino "qué sucede cuando esta URL no funciona".

Una configuración práctica utiliza un endpoint gestionado primario con un endpoint secundario para failover, además de monitoreo que alerte sobre la tasa de errores en lugar de solo la disponibilidad. Una sonda simple que verifica la progresión de la altura de bloque captura más incidentes reales que una verificación de ping:

#!/usr/bin/env bash
HEAD=$(curl -s https://bnb.api.onfinality.io/public \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_blockNumber","params":[]}' \
  | grep -o '"result":"[^"]*"')
echo "BNB head: $HEAD"

Si la cabeza deja de avanzar, el endpoint está degradado incluso si todavía devuelve HTTP 200. Rastrea eso a lo largo del tiempo y detectarás problemas antes que tus usuarios.

Para equipos que prefieren no encargarse de esto, OnFinality ofrece opciones de RPC gestionado y nodos dedicados para BNB Chain. Los detalles de capacidad y planes están en la página de precios de RPC, y los detalles específicos de la red están en BNB Chain RPC.

Puntos clave

• BNB Smart Chain mainnet usa chain ID 56 y testnet usa chain ID 97. Equivocarse en esto rompe las conexiones de wallet antes de que se ejecute cualquier llamada a contrato.
• Una lista de RPC de BNB mezcla endpoints públicos, gestionados y dedicados. Resuelven problemas diferentes y no son intercambiables.
• Los endpoints públicos están bien para desarrollo y configuración de wallets. Las aplicaciones en producción necesitan soporte de métodos definido, acceso a archivo cuando sea relevante y un plan de failover.
• Los límites de rango de eth_getLogs y los tiempos de espera por inactividad de WebSocket son las dos sorpresas operativas más comunes en BNB Chain.
• Monitorea la progresión de la altura de bloque, no solo el estado HTTP. Un endpoint accesible que ha dejado de sincronizar sigue siendo una interrupción.
• Si tu carga de trabajo es en ráfagas o sensible a la latencia, evalúa nodos dedicados en lugar de intentar absorber límites con reintentos.

Preguntas frecuentes

¿Cuál es el endpoint RPC de BNB Smart Chain? El endpoint público de mainnet de OnFinality es https://bnb.api.onfinality.io/public, con soporte de WebSocket en mainnet. Testnet usa https://bnb-testnet.api.onfinality.io/public. Para cargas de trabajo en producción, un endpoint gestionado o dedicado suele ser la mejor opción.

¿Cuál es el chain ID de BNB Chain? Mainnet es 56 (0x38) y testnet es 97 (0x61). Las wallets y SDKs necesitan el valor correcto para la red a la que te conectas.

¿Puedo usar un endpoint RPC público de BNB en producción? Puedes, pero la capacidad compartida significa que tu rendimiento depende de otros usuarios en un momento dado. La mayoría de los equipos de producción pasan a una API RPC gestionada o a un nodo dedicado una vez que el tráfico se vuelve predecible.

¿Por qué eth_getLogs se agota en BNB Chain? BNB Chain produce bloques rápidamente, por lo que un rango de bloques amplio puede contener una gran cantidad de logs. Dividir las consultas en rangos más pequeños y usar un endpoint con límites apropiados resuelve la mayoría de estos tiempos de espera.

¿Necesito un nodo de archivo para BNB Chain? Solo si consultas estado histórico o logs en bloques antiguos. Los nodos estándar sirven estado reciente; el acceso a archivo es una capacidad separada que debes confirmar antes de depender de ella.

¿Cómo hago failover entre endpoints RPC de BNB? Configura un endpoint primario y uno secundario en tu cliente, y activa el failover ante errores repetidos o altura de bloque estancada en lugar de ante una sola solicitud fallida. Monitorear la progresión de bloques es más confiable que verificar solo el estado HTTP.