Как Binance считает лимиты API на IP-адрес

Как вес запросов считается на IP

Binance считает не запросы, а их вес. У каждого эндпоинта есть своя цена, и весовая система складывает эти цены в общий бакет, привязанный к вашему IP-адресу. Лёгкий вызов — например, цена одного тикера — стоит 1–2 веса. Тяжёлый вызов, который возвращает данные по всем символам биржи сразу, может стоить в десятки раз дороже. Минутный лимит веса действует именно на этот общий бакет, а значит, все скрипты, боты и соединения на вашем адресе расходуют один и тот же бюджет.

Из этого следует, что троттлинг нужно строить иначе, чем привыкло большинство. Считать «запросы в минуту» бессмысленно, потому что сотня тяжёлых вызовов исчерпает бюджет, который три тысячи лёгких почти не тронули бы. По той же причине не помогают дополнительные API-ключи: лимит привязан к IP, а не к ключу, и все ключи на одном сервере пьют из одного бакета.

Вслепую лететь при этом не приходится: каждый ответ содержит заголовок X-MBX-USED-WEIGHT-1M с расходом текущего окна. Одна важная оговорка о том, как это окно устроено. Binance применяет несколько фиксированных интервалов лимитов одновременно: счётчик переключается на границе интервала, а не скользит непрерывно, и короткое окно может сброситься, пока длинное остаётся исчерпанным. Поэтому следите за всеми лимитами, которые возвращает ваш API, а не только за заголовком 1M. Бот, который сверяет троттлинг с этими значениями, существенно снижает шансы поймать 429 на ровной нагрузке; бот, который сверяет собственный счётчик с числом из туториала, обычно эти 429 и коллекционирует.

Почему цифра «1 200 веса в минуту» устарела

Короткий ответ: Binance поднял лимит ещё несколько лет назад, а половина интернета этого не заметила. 25 августа 2023 года бюджет на IP в Spot API вырос впятеро — со старого значения до 6 000 веса в минуту. Это не было тихим изменением: Binance объявил о нём официально, и актуальное число сегодня подтверждается везде, где это имеет значение. Сэмплы exchangeInfo в официальной документации показывают 6 000, и даже текст ошибки -1003 теперь гласит: «current limit is 6000 request weight per 1 MINUTE».

Почему же старое число продолжает всплывать? Потому что оно живёт ровно там, где разработчики реально читают. Документация python-binance до сих пор указывает старое минутное значение на обзорной странице, а обсуждения лимитов на GitHub, которые хорошо ранжируются в поиске, писались против потолка образца до 2023 года. Цена доверия к ним вполне конкретная: троттлер, настроенный на старое число, не использует 80% реального бюджета, а туториал, который учит паниковать на 1 100 веса, учит вас правилам 2023 года.

Надёжное лечение — не заменить одну зашитую константу на другую, а перестать зашивать её вовсе. Запрашивайте /api/v3/exchangeInfo при старте бота: массив rateLimits в ответе — это живой источник истины, и именно его Binance обновит первым, когда лимиты изменятся в следующий раз.

Вес запросов и счётчик ордеров — два разных лимита

Упереться в один из этих лимитов — ещё ничего не узнать о втором, потому что считаются они по разным осям. Весовой минутный лимит привязан к IP-адресу и покрывает всё, что вы отправляете. Ордерные лимиты устроены иначе: они считаются по аккаунту. Текущий сэмпл exchangeInfo в документации показывает, что это значит в числах: окно в 50 ордеров за 10 секунд, а поверх него — дневной потолок в 160 000.

В дневном потолке есть тонкость, на которой спотыкаются торговые боты, — и работает она в вашу пользу. Счётчик учитывает только неисполненные ордера, о чём Binance пишет прямо: если ваши ордера стабильно исполняются сделками, размещать их через API можно без ограничений. Иными словами, потолок существует, чтобы наказывать ордер-спам, который никогда не торгуется, а не активные стратегии, которые торгуются. Следить за своим положением можно в реальном времени: каждый успешный ордер возвращает заголовок X-MBX-ORDER-COUNT-*, а GET /api/v3/rateLimit/order показывает те же числа по запросу.

Вывод для отладки простой. Поймав 429, сначала выясните, какой именно из двух бакетов вы осушили: троттлинг опроса маркет-данных ничем не поможет, если исчерпано было ордерное окно.

Какие эндпоинты стоят дороже всего

Общее правило прямо из официальной документации по лимитам: дороже те эндпоинты, что выполняют операции сразу над несколькими символами. Публичные эндпоинты маркет-данных добавляют к этому вторую закономерность: их цена растёт вместе с объёмом данных, который вы просите в одном вызове. Как это работает, видно на примере стакана. Один и тот же эндпоинт стоит 5 веса, когда вы запрашиваете до 100 уровней, 25 веса — до 500 уровней и 50 веса — на полной тысяче; это числа из разобранного примера самой Binance Academy. Та же логика делает классическим убийцей бюджета вызов тикеров без параметра symbol: вы просите один запрос ответить за всю биржу сразу.

Свечи находятся на противоположном конце этой шкалы. Эндпоинт свечных данных стоит плоские 2 веса за вызов по актуальной таблице эндпоинтов — независимо от таймфрейма. Этот разрыв в цене объясняет закономерность из реальных проектов: стратегии на свечах при типовых нагрузках упираются в потолок редко, а краулеры стаканов — постоянно. Мы измерили это на своём стенде: вес свечного запроса не зависит и от размера страницы, поэтому запрашивайте всегда limit=1000 — списание то же, данных в тысячу раз больше (подробности в разделе с тестом ниже).

Для экономии веса на публичных данных существуют два официальных рычага, и оба должны стоять в архитектуре ДО любых разговоров о масштабировании адресами. Первый: маркет-стримы WebSocket не расходуют вес вовсе — текст ошибки 429 у Binance сам советует перейти с опроса на WebSocket. Только не путайте при сравнении лимитов REST и WebSocket: бесплатны именно стримы; request-response WebSocket API расходует тот же весовой пул, что и REST (одно открытие соединения стоит 2 веса), а подключения ограничены 300 за 5 минут на IP. Второй рычаг: для сервисов, работающих только с публичными рыночными данными, Binance прямо рекомендует специальный базовый эндпоинт data-api.binance.vision — те же пути, без аккаунтных эндпоинтов. Направляйте публичные пайплайны туда, а не на основной хост API.

Чем отличаются лимиты спота и фьючерсов

Спот и фьючерсы — раздельные системы с раздельными бюджетами, поэтому исчерпание одного никак не задевает другой. Spot REST даёт каждому IP 6 000 веса в минуту на api.binance.com. Фьючерсный API живёт на другом хосте, fapi.binance.com, и ведёт собственную бухгалтерию: для контрактов USDⓈ-M лимит составляет 2 400 веса в минуту на IP, согласно фьючерсной документации. Бакет меньше, но и рассчитан он на API, где большинство вызовов данных легче своих спотовых аналогов.

Для бота, который торгует оба рынка с одного сервера, это палка о двух концах. С одной стороны, у вас два независимых бюджета — это удобно. С другой — два независимых способа сжечь один и тот же IP-адрес, потому что бан 418 действует на уровне адреса и не разбирается, какой из API его заработал. И правило «не хардкодить» здесь работает с двойной силой: каждый фьючерсный вкус (USDⓈ-M и COIN-M) публикует собственный exchangeInfo, и их числа никогда не менялись синхронно со спотом. Запрашивайте лимиты того API, на котором реально торгуете.

Как жить в лимитах, когда крутится бот

На практике правила лимитов для трейдинга сводятся к четырём привычкам, и ни одна из них не требует запоминать числа.

Первая привычка — читать заголовки, а не документацию. Ведите троттлинг от значения X-MBX-USED-WEIGHT-1M в живых ответах, а потолки обновляйте из exchangeInfo при старте. Боты, собранные по этому принципу, пережили смену лимитов 2023 года без единой правки — просто потому, что изначально не доверяли константам. Обе проверки занимают пару строк. Актуальные потолки достаются без всякого API-ключа:

curl -s "https://api.binance.com/api/v3/exchangeInfo?symbol=BTCUSDT" | jq '.rateLimits'

В выводе ищите объекты, где rateLimitType равен REQUEST_WEIGHT и ORDERS. Поле limit рядом с каждым interval — то число, которому должен доверять троттлер; обратите внимание, что интервалов на один тип может быть несколько. Следить за расходом в реальном времени так же коротко:

import requests

r = requests.get("https://api.binance.com/api/v3/ticker/price",
                 params={"symbol": "BTCUSDT"})
print(r.headers["X-MBX-USED-WEIGHT-1M"])   # вес, потраченный в текущем окне

Проверку уровня «пересекли 90% — спим» считайте демонстрацией, а не production-лимитером. Настоящий расчёт бюджета выглядит ближе к этому:

effective_remaining = configured_limit
                    - observed_used_weight
                    - reserved_weight_for_inflight_requests
                    - safety_margin

Что за этим стоит при нескольких воркерах — отдельная тема, ей посвящён следующий раздел.

Вторая привычка — воспринимать 429 как жёсткий стоп, а не как рекомендацию. Ответ несёт заголовок Retry-After со временем ожидания в секундах, и уважать его важно: продавливание сквозь повторные 429 — документированная дорога к 418, а IP-баны для рецидивистов растут от 2 минут до 3 дней.

Третья — сначала увести публичные данные на официальные пути разгрузки: стримы и data-api.binance.vision, о которых выше. Всё, что бот опрашивает по таймеру, должно жить там; REST-бюджет основного хоста берегите для того, чему он действительно нужен, — ордеров и состояния аккаунта.

Четвёртая привычка — архитектурная: точно знать, какие процессы делят исходящий IP. Бюджет в 6 000 принадлежит адресу, и его делит всё, что за этим адресом стоит. Именно поэтому лимиты торговых ботов так часто выглядят мистикой: три процесса на одном сервере пьют из одного бакета, и «случайные» 429 — это просто соседи, конкурирующие за общий бюджет. По той же причине здесь могут подвести фреймворки: у ccxt есть встроенный троттлер, но общий IP незаметно ломает его математику, ведь библиотека видит только собственный трафик и ничего не знает о соседях. Отсюда два честных варианта: скоординировать воркеров за одним адресом или развести их по отдельным адресам. Следующие два раздела разбирают оба по очереди.

Как скоординировать несколько воркеров за одним IP

Если воркеры обязаны делить адрес, лечение — центральный лимитер: один хранитель бюджета, к которому каждый процесс обращается перед отправкой. Паттерн описывается коротко: счётчик живёт в общем хранилище (обычно Redis), вес эндпоинта резервируется атомарно до отправки запроса, а локальное состояние сверяется с заголовками X-MBX-USED-WEIGHT-* из ответов — потому что число сервера истина, а ваше лишь оценка. Production-ориентированный набросок:

# Набросок, не библиотека: центральный лимитер веса для воркеров за одним IP
import time, random, logging, redis, requests

r = redis.Redis()
BASE = "https://api.binance.com"
SAFETY = 0.10        # консервативно для парка воркеров; одиночный сборщик может снизить до 0.05
SPANS = {"SECOND": 1, "MINUTE": 60, "DAY": 86400}
WEIGHTS = {"/api/v3/klines": 2,
           "/api/v3/depth": 50}   # 50 — худший случай (1 000 уровней); до 100 уровней вес 5, до 500 — 25

def load_limits():
    info = requests.get(f"{BASE}/api/v3/exchangeInfo",
                        params={"symbol": "BTCUSDT"}).json()
    limits = {}
    for l in info["rateLimits"]:
        if l["rateLimitType"] != "REQUEST_WEIGHT":
            continue
        if l["interval"] not in SPANS:                   # новый тип интервала — не падаем в горячем пути
            logging.warning("неизвестный интервал %s — пропущен", l["interval"])
            continue
        limits[(l["interval"], l["intervalNum"])] = l["limit"]
    return limits

LIMITS = load_limits()

def window_key(interval, num):
    span = SPANS[interval] * num
    return f"w:{interval}{num}:{int(time.time()) // span}", span

def reserve(weight):
    acquired = []
    for (interval, num), limit in LIMITS.items():        # каждый интервал, не только 1M
        key, span = window_key(interval, num)
        used = r.incrby(key, weight)                     # атомарный резерв ДО отправки
        r.expire(key, span)
        acquired.append(key)
        if used > limit * (1 - SAFETY):
            for k in acquired:                           # откат по ВСЕМ занятым интервалам
                r.decrby(k, weight)
            return False
    return True

def call(path, params):
    weight = WEIGHTS[path]
    while not reserve(weight):
        time.sleep(0.2 + random.random())                # джиттер против одновременного старта
    resp = requests.get(BASE + path, params=params)
    used = resp.headers.get("X-MBX-USED-WEIGHT-1M")
    if used:                                             # сверка: правда за сервером
        key, span = window_key("MINUTE", 1)
        r.set(key, max(int(used), int(r.get(key) or 0)), ex=span)   # ex — не снимать TTL с ключа окна
    if resp.status_code == 429:
        time.sleep(int(resp.headers.get("Retry-After", "1")))
    elif resp.status_code == 418:
        raise RuntimeError("IP забанен: остановить весь парк, не ретраить")
    return resp

На что смотреть при запуске. Цикл в reserve обходит все интервалы из exchangeInfo — именно это спасает, когда короткое окно сбросилось, а длинное всё ещё исчерпано, — а при отказе откатывает резерв по всем уже занятым интервалам, а не только по последнему: иначе каждая неудачная попытка накручивала бы короткое окно, и лимитер начал бы блокировать сам себя при нулевой реальной нагрузке. Шаг сверки подтягивает счётчик в Redis до серверного заголовка при любом расхождении — обязательно с ex=span, потому что голый SET снимает TTL и оставляет ключи окон в Redis навсегда. Порог SAFETY согласуйте с задачей: 10% останавливают резерв на 5 400 веса из 6 000 — разумный запас для парка воркеров, но одиночный сборщик, который метит в 90–94% бюджета из нашего теста ниже, может снизить его до 5%. И честно о том, чего реальному деплою ещё не хватает поверх наброска: circuit breaker, который ставит парк на паузу после серии 429; освобождение резерва для запросов, упавших до Binance; цикл обновления таблицы WEIGHTS — в идеале с весом стакана как функцией запрошенной глубины, а не константой худшего случая; и один неймспейс Redis на исходящий IP — все ключи и воркеры за одним адресом обязаны делить одного хранителя бюджета.

Координации нужны и глаза. Минимальный набор метрик, после которого «случайное» поведение лимитов перестаёт выглядеть случайным:

binance_used_weight_ratio
binance_order_count_ratio
binance_http_429_total
binance_http_418_total
binance_retry_after_seconds
binance_request_weight_by_endpoint
binance_websocket_reconnect_total

Если used_weight_ratio подскочил, а request_weight_by_endpoint вашего воркера ничего нового не показывает — бюджет тратит кто-то ещё за тем же адресом. Чистое лечение — развести нагрузки по отдельным адресам, а насколько независимы их бюджеты на самом деле, мы измерили в следующем разделе.

Наш тест: где на самом деле заканчивается бюджет одного IP

Что проверяли. Выше статья утверждает, что Binance выдаёт каждому исходящему IP независимый бюджет 6 000 REQUEST_WEIGHT в минуту. Мы потратили двое суток и проверили это на собственной инфраструктуре: выделенные HTTP-прокси PapaProxy.net с egress в Германии, публичный эндпоинт GET /api/v3/klines на api.binance.com, пара BTCUSDT, интервал 1m.

Сначала — сколько стоит запрос. Прямым соединением, по 8 замеров на каждое значение, мы считывали приращение заголовка X-MBX-USED-WEIGHT-1M:

Вес не зависит от размера страницы. Практический вывод простой: всегда запрашивайте limit=1000 — списание одинаковое, а данных в тысячу раз больше. Запрос за одной свечой стоит ровно столько же, сколько запрос за тысячей.

Лестница по одновременным соединениям. Один выделенный адрес, limit=1000, ступени по 120 секунд, без искусственных пауз между запросами:

Первый 429 пришёл на 24 соединениях, на запросе №4910, с заголовком Retry-After.

Что это значит. Бюджет 6 000 веса в минуту — реальный и достижимый. Чтобы выбрать его при limit=1000, адрес должен отдавать 50 запросов в секунду по 169 КБ, то есть держать около 68 Мбит/с. Наш адрес выдал 95,6 Мбит/с — то есть ограничением становится бюджет Binance, а не канал прокси. И эту скорость каждый адрес пула держит независимо: при параллельной работе десятков или сотен IP узким местом станет канал вашего сервера или ноутбука, а не прокси. На 16 соединениях мы получили 94% бюджета без единой ошибки; между 16 и 24 соединениями проходит граница.

Рабочая точка, которую мы рекомендуем: 14–16 одновременных соединений на адрес. Это 90–94% бюджета с запасом на неровности. Идти к 100% смысла нет: первая же задержка на стороне API сдвинет окно и даст 429.

Независимы ли бюджеты у разных адресов. Три выделенных адреса, работающих одновременно по 14 соединений каждый, 120 секунд:

Суммарно 17 066 веса в минуту — почти втрое больше бюджета одного адреса, и ни одного 429. Если бы адреса делили общий egress, лимит сработал бы почти сразу. Бюджеты независимы, и параллельные адреса складываются линейно: каждый следующий IP добавляет к общему потолку ещё 6 000 веса в минуту.

Надёжность пула на длинной дистанции. Отдельно, до основной серии, мы прогнали продолжительный тест на общем пуле из 1 000 адресов: равномерный round-robin по всему пулу, публичный эндпоинт свечей, суммарно около четырёх с половиной часов работы.

Важная деталь про методику: тот загрузчик открывал новое соединение на каждый запрос, а не переиспользовал сессии. То есть 0,16% — это доля неудачных установок соединения из 197,5 тысячи попыток, а не доля сбоев внутри пары сотен долгоживущих сессий. Для оценки надёжности пула это более строгий сценарий. Этот прогон шёл с низкой нагрузкой на каждый отдельный адрес и не является проверкой лимитов Binance — из него нельзя делать выводов о 429. Он отвечает только на вопрос, насколько стабильно пул держит соединения при длительной равномерной работе.

Проверка на втором адресе. Границу 6 000 веса в минуту мы получили дважды и независимо: на выделенном адресе в основной серии и, ранее, на другом адресе общего пула — там 429 пришёл на 16 соединениях при limit=1. Совпадение границы на двух разных адресах и двух разных размерах страницы говорит, что лимит считается по исходящему IP, а не по маршруту или типу трафика.

Геолокация имеет значение. Выделенные адреса в США на api.binance.com возвращали HTTP 451, немецкие — 200. Это не сбой, а граница между двумя разными компаниями: Binance.US — отдельная организация со своими эндпоинтами (api.binance.us), поэтому для работы с американской биржей нужны именно американские адреса. Для эндпоинтов глобальной Binance подходят адреса любой обслуживаемой страны — кроме США. Страну egress выбирайте до начала работы, иначе тест упрётся не в лимиты, а в блокировку.

Практические следствия для сбора истории. Вся минутная история BTCUSDT — примерно 4,7 млн свечей, то есть около 4 710 страниц по 1000. Это 9 420 единиц веса, около полутора минут бюджета одного адреса и примерно 796 МБ трафика. Иными словами, лимиты Binance полный бэкфилл одной пары не ограничивают вообще — ограничивает передача данных. Два числа ниже получены пересчётом из таблицы выше, а не отдельным замером:

• последовательный обход в одно соединение (3,09 запроса/с) — около 25 минут;
• 16 соединений на одном адресе (47,02 запроса/с) — около 100 секунд.

Разница здесь целиком про конкурентность, а не про прокси. Если ваш загрузчик ходит по страницам последовательно, добавление адресов не поможет — сначала нужно распараллелить обход по диапазонам времени.

Условия теста. Выделенные HTTP-прокси PapaProxy.net, egress DE, авторизация по белому списку IP. Цель — публичный api.binance.com, без ключей и подписи. Ступени по 120 секунд, пауза 65 секунд между ступенями для сброса минутного окна. Лестница останавливается на первом 429 и выше не поднимается. Прогон от 5 августа 2026 года.

Практический итог для планирования: рабочая точка — 14–16 соединений на адрес, бюджеты адресов складываются линейно, а дальше — чистая арифметика вашего объёма. Наши клиенты решают эту задачу двумя схемами, и выбор зависит только от объёма: пакеты в 5 000–10 000 адресов из общего пула под массовый сбор данных — или выделенные адреса, когда IP должен принадлежать только вам. Обе схемы рабочие, обе прошли через этот тест с разных сторон, и обе доступны на странице прокси для Binance: выделенные адреса от одного IP, пакеты из общего пула, доступ по белому списку IP, а на каждом адресе — HTTP, HTTPS, SOCKS4 и SOCKS5.

FAQ

Есть ли у Binance API бесплатный тариф?

Платных тарифов нет вовсе — API бесплатен для любого верифицированного аккаунта. Лимиты, в которые вы упираетесь, технические, а не коммерческие: 6 000 веса в минуту на IP и ордерные потолки на аккаунт одинаковы для всех, и никакая оплата их не поднимает. Масштабируются эффективным расходом веса и добавлением IP-адресов, а не апгрейдом плана.

Какие лимиты у бесплатного использования на практике?

Те же, что у всех: 6 000 веса в минуту на каждый IP-адрес и ордерные лимиты на аккаунт — 50 ордеров за 10 секунд и 160 000 неисполненных в день по текущему сэмплу exchangeInfo в официальной документации. Исполненные ордера дневной счётчик не душат. Живые значения проверяйте через /api/v3/exchangeInfo — Binance обновляет их там первыми.