Гаманець перестає оновлюватися, застосунок зависає на індикаторі завантаження, а десь позаду з'являється повідомлення про перевищення ліміту запитів. З вашими ключами, балансом і самим блокчейном усе гаразд. Оператор вирішив, що за задане вікно ви поставили більше запитань, ніж дозволяє ваш тариф, і відхиляє все, що приходить вище за цю межу.
Про що насправді повідомляє помилка ліміту
RPC-вузол — це машина, яка відповідає на запитання про мережу замість гаманців і застосунків, що не тримають власного вузла. Той, хто цю машину обслуговує, вирішує й те, скільки запитань має право поставити кожен викликач, і втілює це рішення, відхиляючи все, що приходить вище за стелю.
RFC 6585 дає такій відмові окремий код стану. У ньому сказано, що код 429 означає: користувач надіслав забагато запитів за відведений час, і сам розділ називає цей стан обмеженням частоти; там же додано, що подання відповіді SHOULD містити пояснення умови й MAY містити заголовок Retry-After, який вказує, скільки чекати до нового запиту.
Звідси два наслідки, і обидва легко проґавити, дивлячись на зламаний екран. Відмова стосується викликача, а не самого виклику: той самий запит хвилиною раніше пройшов би. А стеля — це політика одного оператора, а не властивість мережі, тож інший ендпоінт з іншою політикою відповість на той самий запит без заперечень.
Відмова приходить не в одному конверті
Не кожен обмежений виклик повертається кодом стану HTTP. JSON-RPC 2.0 переносить помилки всередині тіла відповіді, а його специфікація резервує коди від -32000 до -32099 під серверні помилки, визначені реалізацією, і саме там може опинитися повідомлення провайдера про обмеження. Рівень HTTP при цьому звітує про звичайний успіх.
| Де опиняється відмова | Який вона має вигляд | Чому її пропускають |
|---|---|---|
| Код стану HTTP | Відповідь 429, іноді із заголовком Retry-After | Непомітна клієнтові, який перевіряє лише факт з'єднання |
| Тіло JSON-RPC | Об'єкт error із серверним кодом, визначеним реалізацією | Статус HTTP успішний, тож перевірка статусу пропускає його далі |
| Формулювання клієнта | Застарілий баланс, індикатор завантаження або загальна мережева помилка | Текст написано для людини, і він не називає рівень, який відмовив |
Тому діагностика починається з того, який із трьох випадків перед вами. Гаманець, який каже лише про неможливість з'єднатися, не доводить, що відмови не було: він доводить, що гаманець її не показав.
Ліміти не завжди рахуються в запитах
Стеля, виражена у викликах за секунду, — лише одна з форм ліміту. Якщо оператор зважує виклики, а не рахує їх, важкий метод бере з того самого бюджету більше за легкий, і бюджет спорожнюється швидше, ніж підказує кількість викликів.
Тому «кілька викликів» і «ви перевищили ліміт» можуть однаково точно описувати ту саму хвилину. Запит логів за широким діапазоном блоків — це один виклик за лічбою і велике списання за вагою. Прочитати власний опис оператора про те, що рахує його бюджет, швидше, ніж ставити досліди.
Звідки насправді береться обсяг запитів
Обсяг накопичується, а не обирається. Він виникає з циклів, які ніхто не вважає циклами: екран, що перечитує баланс за таймером; компонент, що заново запитує дані на кожному перемальовуванні; фоновий спостерігач, який питає, чи транзакція вже потрапила в блок.
Арифметика тут безжальна, бо інтервал малий, а сеанс довгий. Екран, що оновлює один баланс раз на секунду, за дванадцятигодинний сеанс сам собою породжує 43 200 викликів, ще до будь-яких дій користувача. На тлі тарифу, який дозволяє 100 000 викликів на добу, одна відкрита вкладка вже забрала помітну частку доби.
Повтори — друге джерело, і вони множать перше. Клієнт, який на кожну відмову відповідає новим надсиланням, перетворює одну перевищену стелю на потік відмов, і робить це саме тоді, коли оператор найменше готовий його обслуговувати.
Як повторювати, не погіршуючи відмову
Повторне надсилання з тим самим інтервалом, який спричинив відмову, відтворює відмову. Правильна поправка — чекати після кожної невдачі довше, а не стільки ж, щоб інтервал зростав, а стеля лишалася на місці, і зупинятися після обмеженої кількості спроб, а не продовжувати нескінченно.
Додайте до цього очікування випадковість. Клієнти, відхилені в ту саму мить і які відступають за тим самим правилом, повернуться теж одночасно, і відновлення обернеться новим сплеском. Випадковий зсув розносить очікування й ламає цю синхронність, нічого при цьому не коштуючи.
Якщо у відповіді є заголовок Retry-After, він заміняє здогад. Оператор сам назвав строк очікування, і дотримання цього значення швидше за вигаданий вами розклад і з меншою ймовірністю зарахується вам у мінус.
Скорочувати кількість запитів, а не піднімати стелю
Пакетування — перше скорочення, і воно належить протоколу, а не окремому провайдеру. JSON-RPC 2.0 зазначає, що для одночасного надсилання кількох об'єктів Request клієнт MAY надіслати масив, заповнений об'єктами Request, а сервер має відповісти масивом з відповідними об'єктами Response після обробки всіх об'єктів Request із пакета. Згорнувши десять викликів в один масив, той самий сеанс із 43 200 викликів ви перетворюєте на 4 320 запитів.
Кешування — друге. Значення, які не змінюються між блоками, не потрібно перечитувати між блоками: кількість знаків токена, адреса контракту, квитанція вже завершеної транзакції. Усе остаточне кешується безстроково, і перечитувати його — чиста витрата.
Підписки — третє, якщо ендпоінт їх пропонує. Опитування знову й знову питає, чи щось змінилося; підписка питає один раз і отримує сповіщення, коли відповідь змінюється. Інформація та сама, а бюджету вони коштують дуже по-різному.
| Що ви спостерігаєте | Де насправді стеля | Що це змінює |
|---|---|---|
| Відмови за невеликого навантаження | Зважений бюджет витрачено важкими методами | Звузити діапазони блоків і розбити запит |
| Відмови множаться після першої | Повтори б'ються в ту саму стелю | Відступати зі зростаючим і рандомізованим очікуванням |
| Відмови від однієї бездіяльної вкладки | Цикл опитування за таймером | Пакетувати, кешувати або підписуватися замість опитування |
| Відмови лише в одній мережі | Політика, прив'язана до цього ендпоінта | Додати другий ендпоінт для цієї мережі |
Коли повтор не є безпечним
Читання й записи повторюються по-різному. Запитати баланс двічі коштує одного зайвого виклику й нічого більше. Надіслати підписану транзакцію двічі — вже інша подія, а відмова на ендпоінті не каже, з якого боку цієї межі транзакція зупинилася.
Перш ніж надсилати знову, з'ясуйте, чи дійшла перша спроба до мемпула. Транзакція, яку мережа вже тримає, і нова транзакція з тим самим наміром невзаємозамінні, а поводження з ними як з однією річчю і є шляхом до подвійної трансляції. У Solana точка відліку свіжості робить час наочним: надсилання, затримане довгим відступом, може впертися в прострочений blockhash, і його доведеться перезбирати, а не надсилати заново.
Та сама обережність стосується й того, у що клієнт повірить потім. Гаманець, чиї читання відхиляються, звіряє власний лік надісланих транзакцій із поданням, яке він не зміг оновити, і це один зі шляхів до повідомлення завеликий nonce. Лічильник не помиляється; бракує картини, з якою його порівняли.
Зміна ендпоінта лагодить одну причину, а не решту
Якщо стеля належить оператору, перехід до іншого оператора переводить вас під іншу стелю, і зміна ендпоінта — звичайний ремонт саме для цього випадку. Звірте chain ID нового запису, перш ніж будь-що через нього спрямовувати, і збережіть запис, який уже працював. Чого зміна не дістає, так це того, що мережа вже записала: транзакція, яка виконалася і була відкочена, позначається як reverted, і будь-який чесний ендпоінт звітує про цю квитанцію однаково.
Якщо обсяг належить вам, перехід купує час і нічого більше. Той самий цикл опитування впреться в стелю наступного оператора за тим самим розкладом, а ротація між ендпоінтами заради перебування під кількома стелями одразу ховає цикл, а не лагодить його.
Третій випадок варто відокремити від обох. Виділений ендпоінт із вашим власним ключем — це не просто більший ліміт: він ще й відділяє вас від інших викликачів, які ділили спільний публічний ендпоінт, тож отримана після цього відмова справді ваша, і пояснювати її вам.
Підсумок
Помилка ліміту говорить про те, скільки ви попросили, а не про те, чи мали ви право питати. Вона називає бюджет, вікно й оператора, і корисна відповідь починається з того, яке з трьох зараз зв'язує.
Читайте відмову на тому рівні, де вона опинилася, дотримуйтесь Retry-After, коли його дано, і відступайте зі зростаючим та рандомізованим очікуванням замість надсилання за старим розкладом. Далі скорочуйте обсяг, а не женіться за більшою стелею: пакетуйте те, що може їхати разом, кешуйте те, що не змінюється, і підписуйтеся замість опитування. Удвічі більший ліміт, з'їдений тим самим циклом, скінчиться того самого дня. Щоб продовжити вивчати основи, читайте інші матеріали Bitbase Academy.
Схожі матеріали
Інші матеріали Bitbase на цю тему:
- Як безпечно змінити RPC-ендпоінт
- Максимальну комісію за транзакцію перевищено: що означає це попередження гаманця
- Що таке криптовалютний QR-код?
- Сид-фраза й парольна фраза: у чому різниця і чому це важливо
- Що таке остаточність у блокчейні?
Застереження: Ця стаття є освітнім матеріалом Bitbase Academy і надається лише для інформації. Вона не є інвестиційною, торговою, податковою чи фінансовою порадою. Криптоактиви волатильні — оцінюйте ризики самостійно. Написано станом на вересень 2026 року; орієнтуйтеся на найновішу офіційну інформацію.
Джерела
[1] M. Nottingham, R. Fielding, Additional HTTP Status Codes, RFC 6585, IETF, квітень 2012 р. rfc-editor.org
[2] JSON-RPC 2.0 Specification, робоча група JSON-RPC, оновлено 4 січня 2013 р. jsonrpc.org
