Limite de requisições RPC excedido e como evitá-lo

2026-09-03

Uma carteira para de atualizar, um aplicativo trava em um indicador de carregamento e, em algum ponto atrás disso, aparece uma mensagem de limite de requisições excedido. Não há nada errado com suas chaves, seu saldo ou a rede. Um operador decidiu que você fez mais perguntas em uma janela do que seu plano permite, e recusa tudo o que chega acima dessa linha.

Limite de requisições RPC excedido e como evitá-lo: pontos principais em resumo

O que um erro de limite realmente relata

Um nó RPC é uma máquina que responde perguntas sobre a rede em nome de carteiras e aplicativos que não rodam a sua própria. Quem opera essa máquina também decide quantas perguntas cada chamador pode fazer, e impõe a decisão recusando tudo o que chega acima do teto.

A RFC 6585 dá a essa recusa um código de status próprio. Ela afirma que o código 429 indica que o usuário enviou requisições demais em um dado intervalo de tempo, e a própria seção chama essa condição de limitação de taxa; acrescenta que as representações da resposta SHOULD incluir detalhes que expliquem a condição e MAY incluir um cabeçalho Retry-After indicando quanto tempo esperar antes de uma nova requisição.

Duas consequências decorrem disso, e ambas passam despercebidas diante de uma tela quebrada. A recusa é sobre o chamador e não sobre a chamada, de modo que a requisição idêntica teria funcionado um instante antes. E o teto é a política de um operador, não uma propriedade da rede, então um segundo endpoint sob outra política responde à mesma requisição sem reclamar.

A recusa chega em mais de um envelope

Nem toda chamada limitada volta como status HTTP. O JSON-RPC 2.0 carrega erros dentro do corpo da resposta, e sua especificação reserva os códigos de -32000 a -32099 para erros de servidor definidos pela implementação, e é ali que a mensagem de limitação de um provedor pode ficar. A camada HTTP relata então um sucesso comum.

Onde a recusa aterrissa	Qual é a aparência	Por que passa batido
Status HTTP	Uma resposta 429, às vezes com cabeçalho Retry-After	Invisível para um cliente que só verifica se a conexão funcionou
Corpo JSON-RPC	Um objeto error com código de servidor definido pela implementação	O status HTTP é sucesso, então uma checagem de status o deixa passar
Texto do cliente	Um saldo desatualizado, um indicador de carregamento ou uma falha de rede genérica	O texto é escrito para uma pessoa e não nomeia a camada que recusou

O diagnóstico começa, portanto, por decidir qual dos três você está vendo. Uma carteira que diz apenas que não conseguiu conectar não prova que não houve recusa: prova que a carteira não a mostrou.

Limites nem sempre são contados em requisições

Um teto expresso em chamadas por segundo é apenas uma das formas que um limite assume. Quando um operador pondera chamadas em vez de contá-las, um método pesado tira mais do mesmo orçamento do que um leve, e o orçamento se esvazia mais rápido do que o número de chamadas sugere.

Por isso “algumas chamadas” e “você excedeu o limite” podem ser descrições igualmente exatas do mesmo minuto. Uma consulta de logs sobre uma faixa ampla de blocos é uma chamada por contagem e um saque grande por peso. Ler a descrição do próprio operador sobre o que o orçamento conta resolve isso mais rápido do que experimentar contra ele.

De onde vem de fato o volume de requisições

O volume se acumula, não é escolhido. Ele vem de laços que ninguém considera laços: uma tela que relê um saldo por temporizador, um componente que busca dados de novo a cada renderização, um observador em segundo plano perguntando se a transação já entrou.

A aritmética é implacável porque o intervalo é pequeno e a sessão é longa. Uma tela que atualiza um saldo uma vez por segundo produz sozinha 43.200 chamadas em uma sessão de doze horas, antes de contar qualquer ação do usuário. Diante de um plano que permite 100.000 chamadas por dia, uma única aba aberta já levou uma parte grande do dia.

As retentativas são a segunda fonte, e multiplicam a primeira. Um cliente que responde a cada recusa enviando de novo transforma um teto excedido em uma sequência deles, e faz isso justamente no momento em que o operador menos quer atendê-lo.

Como repetir sem piorar a recusa

Reenviar no mesmo intervalo que causou a recusa reproduz a recusa. A correção é esperar mais depois de cada falha em vez de esperar o mesmo, para que o intervalo cresça enquanto o teto permanece onde está, e parar depois de um número limitado de tentativas em vez de seguir indefinidamente.

Acrescente aleatoriedade a essa espera. Clientes recusados no mesmo instante e que recuam pela mesma regra voltam também no mesmo instante, então a recuperação chega como outra rajada. Um deslocamento aleatório espalha a espera e quebra essa sincronia, sem custar nada.

Quando há um cabeçalho Retry-After, ele substitui o palpite. O operador já disse quanto esperar, e respeitar esse valor é mais rápido do que um cronograma inventado por você e menos sujeito a ser contado contra você.

Cortar o número de requisições em vez de subir o teto

O agrupamento é a primeira redução, e pertence ao protocolo e não a um provedor específico. O JSON-RPC 2.0 afirma que, para enviar vários objetos Request ao mesmo tempo, o cliente MAY enviar um array preenchido com objetos Request, e que o servidor deve responder com um array contendo os objetos Response correspondentes depois de processar todos os objetos Request do lote. Dobrar dez chamadas em um array transforma aquela sessão de 43.200 chamadas em 4.320 requisições.

O cache é a segunda. Valores que não podem mudar entre blocos não precisam ser relidos entre blocos: as casas decimais de um token, o endereço de um contrato, o recibo de uma transação já liquidada. Tudo o que é definitivo pode ser guardado por tempo indeterminado, e relê-lo é gasto puro.

As assinaturas são a terceira, quando o endpoint as oferece. O polling pergunta repetidamente se algo mudou; uma assinatura pergunta uma vez e é avisada quando a resposta muda. As duas carregam a mesma informação e custam parcelas muito diferentes do orçamento.

O que você observa	Onde o teto está de fato	O que muda isso
Recusas com uso leve	Um orçamento ponderado gasto por métodos pesados	Estreitar as faixas de blocos e dividir a consulta
Recusas se multiplicam depois da primeira	As retentativas batem no mesmo teto	Recuar com uma espera crescente e aleatorizada
Recusas vindas de uma única aba ociosa	Um laço de polling em um temporizador	Agrupar, armazenar em cache ou assinar em vez de fazer polling
Recusas em apenas uma rede	Uma política ligada àquele endpoint	Adicionar um segundo endpoint para essa rede

Quando repetir não é o movimento seguro

Leituras e escritas não se repetem do mesmo jeito. Pedir um saldo duas vezes custa uma chamada extra e nada mais. Enviar uma transação assinada duas vezes é outro evento, e uma recusa no endpoint não diz de que lado dessa fronteira a transação parou.

Antes de reenviar, verifique se a primeira tentativa chegou ao mempool. Uma transação que a rede já guarda e uma transação nova que expressa a mesma intenção não são intercambiáveis, e tratá-las como uma só é o caminho para uma transmissão duplicada. Em Solana a referência de frescor deixa o tempo explícito: um envio atrasado por um recuo longo pode esbarrar em um blockhash expirado e precisar de reconstrução em vez de reenvio.

A mesma cautela vale para o que seu cliente vai acreditar depois. Uma carteira cujas leituras estão sendo recusadas compara a própria contagem de transações enviadas com uma visão que não conseguiu atualizar, e esse é um dos caminhos para a mensagem nonce muito alto. O contador não está errado; falta a imagem com a qual ele foi comparado.

Trocar de endpoint conserta uma causa, não as outras

Se o teto pertence ao operador, migrar para outro operador coloca você sob um teto diferente, e trocar de endpoint é o conserto de rotina para esse caso. Verifique o chain ID da nova entrada antes de rotear qualquer coisa por ela, e mantenha a entrada que já funcionava. O que uma troca não alcança é tudo o que a rede já registrou: uma transação que executou e foi desfeita fica revertida, e qualquer endpoint honesto relata esse recibo de forma idêntica.

Se o volume pertence a você, a troca compra tempo e nada mais. O mesmo laço de polling encontra o teto do próximo operador no mesmo cronograma, e girar entre endpoints para caber sob vários tetos ao mesmo tempo esconde o laço em vez de consertá-lo.

Um terceiro caso merece ser separado dos dois. Um endpoint dedicado com sua própria chave não é simplesmente uma cota maior; ele também o isola de outros chamadores que dividiam um endpoint público, de modo que uma recusa recebida depois é de fato sua para explicar.

Em resumo

Um erro de limite é uma afirmação sobre quanto você pediu, não sobre se tinha direito de pedir. Ele nomeia um orçamento, uma janela e um operador, e uma resposta útil começa por identificar qual dos três está restringindo.

Leia a recusa onde ela aterrissa, respeite o Retry-After quando for oferecido e recue com uma espera crescente e aleatorizada em vez de reenviar no cronograma antigo. Depois reduza o volume em vez de perseguir um teto maior: agrupe o que pode viajar junto, guarde em cache o que não muda e assine em vez de fazer polling. Uma cota duas vezes maior, consumida pelo mesmo laço, acaba na mesma tarde. Para continuar aprendendo os fundamentos, acompanhe mais conteúdos da Bitbase Academy.

Leituras relacionadas

Outros artigos da Bitbase sobre este tema:

- Como trocar de endpoint RPC com segurança

- Taxa máxima de transação excedida: o que significa esse aviso da carteira

- O que é um QR code de cripto?

- Frase-semente e passphrase: a diferença e por que ela importa

- O que é finalidade em blockchain?

Aviso: Este artigo é conteúdo educacional da Bitbase Academy, fornecido apenas para fins informativos. Não constitui aconselhamento de investimento, negociação, tributário ou financeiro. Criptoativos são voláteis; avalie seu próprio risco. Escrito em setembro de 2026; consulte as informações oficiais mais recentes.