Помилка часової позначки Binance API -1021: як виправити розбіжність годинника в торговому боті на власному сервері
Торговий бот на власному сервері може правильно підписати запит, але Binance все одно його відхилить. Помилка -1021 вказує на проблему з часовою позначкою: час у підписаному запиті виходить за межі допустимого Binance вікна або випереджає час сервера. Зазвичай виправляти потрібно не код стратегії, а комп’ютер, на якому працює бот. Якщо ви шукаєте «як виправити помилку Binance API -1021», спершу перевірте годинник середовища виконання, а не змінюйте торгову логіку.
Вносьте зміни по одній. Спочатку зафіксуйте помилку, потім перевірте годинник середовища виконання та відновіть синхронізацію часу. Лише після цього змінюйте обробку часових позначок або параметр recvWindow. Такий порядок допоможе не замаскувати проблему з годинником хоста збільшеним вікном запиту.
1. Переконайтеся, що -1021 спричинена розбіжністю годинника
Перевірте повне тіло відповіді, а не лише HTTP-статус чи скорочений рядок у журналі. Код і повідомлення про помилку API Binance мають вказувати, що часова позначка виходить за межі дозволеного вікна або випереджає час сервера.
Ця відповідь відрізняється від повідомлень про неправильний підпис, відсутній API-ключ або брак дозволів. Такі проблеми зазвичай супроводжуються іншими кодами чи повідомленнями API. Якщо отримано код -1021, спершу перевірте часову позначку підписаного запиту, годинник сервера та налаштований параметр recvWindow. Не змінюйте ключі й дозволи для торгівлі як перший крок.
Також переконайтеся, що помилка виникає саме під час підписаного виклику. Для публічних запитів ринкових даних може використовуватися інший механізм автентифікації, тоді як запити до облікового запису й торгові кінцеві точки зазвичай потребують підпису. Якщо бот помиляється лише під час підписаних викликів, це важлива підказка.
2. Відтворіть помилку за допомогою одного підписаного запиту
Перш ніж почати розслідування, призупиніть розміщення ордерів. Для перевірки скористайтеся мінімальною кінцевою точкою для підписаного запиту лише на читання, до якої має доступ ваш API-ключ. Так ви зможете зібрати потрібні дані, не створюючи й не скасовуючи ордерів. Якщо ключ не має доступу до цієї кінцевої точки, скористайтеся іншою підтримуваною кінцевою точкою лише на читання для вашої версії Binance API.
Запишіть точну часову позначку запиту, кінцеву точку, статус відповіді, код і повідомлення про помилку Binance, а також час, коли запит залишив процес. Перед збереженням журналів приховайте API-ключ, підпис, дані облікового запису та інші секрети. Ніколи не публікуйте підписану URL-адресу чи повний заголовок автентифікації у відкритому обговоренні або чаті.
Зведіть відтворення помилки до мінімуму.
Запустіть перевірку в тому самому середовищі процесу, де виникла помилка. Годинник хоста може бути правильним, але контейнер, віртуальна машина чи робочий процес можуть використовувати інше середовище виконання. Якщо після коригування годинника один запит лише на читання проходить успішно, перш ніж перезапускати весь торговий цикл, порівняйте його часову позначку й відповідь із зафіксованою помилкою.
3. Порівняйте годинник хоста з надійним джерелом часу
Перевірте час UTC і стан синхронізації на фактичному комп’ютері або хості контейнера, де працює бот. У Linux команди на кшталт date -u і timedatectl status показують поточний час UTC і стан синхронізації системного часу. Доступні команди залежать від дистрибутива та встановленої служби синхронізації часу.
Не плутайте відображення часового поясу з розбіжністю годинника. Хост із місцевим часовим поясом може показувати іншу годину, ніж UTC, але водночас правильно відображати той самий момент часу. Порівнюйте значення UTC або часові позначки Unix, а не лише годину на екрані.
Зазвичай контейнери використовують системний годинник хоста й не мають окремого годинника, але це залежить від платформи та середовища виконання. Також перевірте вузол або віртуальну машину, де працює контейнер. У середовищах оркестрації визначте, який саме робочий вузол обробив запит із помилкою: перевірка іншого вузла може показати, що все гаразд, але не пояснити збій.
Перевіряйте фактичне відхилення й стан синхронізації, а не просто правдоподібну дату. Розбіжності в кілька секунд може бути достатньо, щоб запит із часовою позначкою відхилили, залежно від вікна запиту та стану мережі.
4. Відновіть синхронізацію часу на хості, де працює бот
Скористайтеся службою синхронізації часу, яку підтримує хост. У системах під керуванням systemd перевірте systemd-timesyncd або налаштовану альтернативу, наприклад Chrony. Не припускайте, що ввімкнення служби означає, що саме вона є активним джерелом часу. Після застосування стандартної конфігурації хоста перевірте стан служби та чи повідомляє вона про успішну синхронізацію.
Якщо ви використовуєте хмарну віртуальну машину, переконайтеся, що служба часу гостьової системи працює з рекомендованим провайдером джерелом часу. Якщо віртуальну машину призупиняли, відновлювали, переносили або запускали зі знімка, перш ніж повертати бота в роботу, знову перевірте годинник. У деяких середовищах час коригується поступово, тому процес, запущений одразу після значного стрибка годинника, ще деякий час може неправильно підписувати запити.
У випадку з контейнером відновлюйте синхронізацію на хості або вузлі оркестрації, а не намагайтеся змінити годинник контейнера. Зазвичай контейнери не мають дозволу змінювати системний час, і надавати такі права торговому боту — ненадійне рішення. Після відновлення синхронізації переконайтеся, що фактичний хост середовища виконання повідомляє про активну синхронізацію. Самого статусу «увімкнено» недостатньо, щоб підтвердити зв’язок із джерелом часу.
Перезапускайте бота лише після перевірки годинника хоста. Потім повторіть той самий запит лише на читання та збережіть відповідь. Якщо помилка не зникла, перш ніж змінювати код підписання запитів у боті, порівняйте часову позначку запиту з часом сервера Binance.
5. Виміряйте різницю з часом сервера Binance перед підписанням запитів
У Binance є публічна кінцева точка часу сервера, за допомогою якої можна перевірити час, що його повідомляє біржа. Зверніться до неї безпосередньо перед контрольованою перевіркою або під час неї та зафіксуйте часову позначку сервера й місцевий час на початку та наприкінці запиту. Так ви зможете безпосередньо порівняти час сервера з годинником, який використовує бот, і зрозуміти, як синхронізувати час сервера для Binance API.
На результат порівняння впливає затримка мережі. Для приблизної оцінки зафіксуйте місцевий час надсилання й отримання відповіді, а потім порівняйте час Binance із середнім значенням між ними. Наприклад, якщо запит надіслано в місцевий час t1, а відповідь отримано в t2, використайте середнє значення між t1 і t2 як приблизний місцевий час, коли сервер сформував відповідь. Отримане відхилення буде неточним: затримка в обох напрямках може різнитися, а обробка запиту на кінцевій точці не обов’язково займає нуль часу.
Повторіть вимірювання кілька разів і використовуйте стабільну оцінку, отриману для відповідей із невеликою затримкою передавання туди й назад. Не вважайте одиничну відповідь із великою затримкою надійним показником часу.
Якщо годинник хоста суттєво відрізняється від оцінки часу сервера, спершу відновіть синхронізацію. Коригування на рівні застосунку може допомогти компенсувати невелику виміряну різницю, але не повинно замінювати справну службу синхронізації часу на хості.
6. Безпечно налаштуйте відхилення часу й recvWindow
Якщо боту потрібне коригування відхилення, обчислюйте його за кількома вимірюваннями часу сервера й застосовуйте під час формування підписаної часової позначки. Зберігайте коригування в пам’яті або контрольованому параметрі конфігурації, періодично оновлюйте його та записуйте в журнал виміряне відхилення й часову позначку кожного невдалого запиту. Не задавайте фіксоване значення, скопійоване з однієї перевірки: затримка мережі й умови роботи хоста можуть змінитися.
Застосовуйте коригування до підписання запиту. Часова позначка в підписаних параметрах має збігатися з тією, що входить до підпису; якщо змінити її після створення підпису, він стане недійсним. Перш ніж дозволити боту розміщувати ордери, перевірте цю послідовність на кінцевій точці лише на читання.
Помірне збільшення recvWindow може врахувати звичайну затримку мережі або незначні коливання часу. Але воно не виправить годинник хоста, який постійно показує неправильний час. Надто велике вікно також може дозволити приймати запізнілі запити довше, ніж потрібно, тож визначаючи налаштування recvWindow у Binance API, задавайте мінімальне значення, сумісне з виміряною затримкою бота та правилами API.
Використовуйте лише один спосіб коригування за раз. Якщо годинник хоста синхронізований, а виміряне відхилення близьке до нуля, приберіть непотрібне коригування на рівні застосунку, а не додавайте відхилення часу сервера поверх коригування, яке вже виконує інша бібліотека. Перш ніж додавати власний код, перевірте, як клієнтська бібліотека обробляє часові позначки.
7. Перевірте відновлення та запобігайте повторним збоям годинника
Повторіть той самий підписаний запит лише на читання й переконайтеся, що у відповіді більше немає -1021. Порівняйте часову позначку, виміряне відхилення від часу сервера та затримку передавання туди й назад із даними попередньої помилки. Лише після цього відновлюйте обробку ордерів, бажано в тестовому режимі або режимі з низьким ризиком, якщо його підтримує ваша конфігурація.
Записуйте в журнал назву хоста чи вузла, місцеву часову позначку, виміряне відхилення та код помилки API. Налаштуйте сповіщення про повторні помилки часових позначок, а не про одиничний випадок: серія помилок після перезавантаження може свідчити, що синхронізація ще не завершилася, а регулярні збої на одному вузлі — про проблему саме з цим хостом.
Перевіряйте годинник після призупинення віртуальної машини, перезавантаження, перенесення контейнерів і перезапуску служби часу. Якщо після зміни хоста помилки повернулися, припиніть розміщення ордерів і перевірте вузол, який обробив запит, перш ніж збільшувати recvWindow. Так можна не допустити, щоб годинник із застарілим часом перетворив тимчасовий збій інфраструктури на потік відхилених ордерів.
