IP whitelist API-ключа Binance: почему отключается торговля

Ключевые выводыВывод средств без IP whitelist включить нельзя — это официальное жёсткое правило; спотовая торговля без ограничений работает, но разрешение отключается через 90 дней без доверенного IP.

Вывод средств без IP whitelist включить нельзя — это официальное жёсткое правило; спотовая торговля без ограничений работает, но разрешение отключается через 90 дней без доверенного IP.
Фьючерсному разрешению whitelist не нужен; его типовой отказ — ключ, созданный до открытия фьючерсного аккаунта.
В список вписывается исходящий IP — проверяйте его однострочным запросом через тот же маршрут, которым ходит бот: NAT, облачные редеплои и домашние подключения могут скрывать реальный адрес.
Надёжность белого списка зависит от стабильности адреса: динамический исходящий IP приводит к ошибкам аутентификации, поэтому продовые ключи обычно работают через статические адреса.
Ошибка -2015 называет три возможные причины: сначала сверьте исходящий IP со списком, затем фактические разрешения через apiRestrictions, затем сам ключ.
Выдавайте минимум прав, используйте отдельный ключ для каждой интеграции, регулярно меняйте ключи, предпочитайте Ed25519 и храните секреты вне репозиториев.

Краткое содержание подготовлено с помощью ИИ.

Каким разрешениям нужен IP из белого списка

Whitelist — не один переключатель: с каждым разрешением он взаимодействует по-своему, и именно на этих различиях ключи перестают работать. Самое жёсткое правило касается вывода: официальная документация формулирует его прямо — включить вывод средств можно только после применения фильтра IP Access Restriction. Нет белого списка — нет разрешения на вывод. Так запросы с ключом, способным перемещать средства с аккаунта, ограничиваются явно указанными доверенными IP.

Спотовая торговля устроена мягче, но со встроенным таймером. Ключ может торговать без ограничений по IP временно. Оставьте список пустым, и спотовое торговое разрешение автоматически отключится через 90 дней: переключатель станет неактивным, а торговые запросы бота перестанут работать. Добавьте хотя бы один доверенный IP — и это ограничение по сроку исчезнет. Binance также удаляет неиспользуемые ключи без ограничений, поэтому у простаивающего ключа без списка срок работы может оказаться ещё короче.

Фьючерсному торговому разрешению whitelist сам по себе не нужен. Его ограничения находятся в другом месте: тот же эндпоинт разрешений отмечает, что Futures API не работает, если ключ создан до открытия фьючерсного аккаунта. Это затрагивает пользователей, которые включили фьючерсы позже и продолжают использовать старый ключ. При проверке запрашивайте фактическое состояние ключа через эндпоинт разрешений (GET /sapi/v1/account/apiRestrictions): ответ показывает ipRestrict, enableWithdrawals, enableFutures и остальные разрешения булевыми значениями.

Какой именно IP вписывать в список

Binance должен увидеть ваш исходящий IP — адрес, с которого запросы выходят в интернет, — и это часто не тот адрес, который машина показывает локально. Устройство за NAT видит внутренний адрес 192.168.x.x, тогда как внешние сервисы видят публичный адрес роутера. Облачная функция или контейнерная платформа может менять исходящие адреса между деплоями. Домашнее подключение также может получить новый IP от провайдера, после чего запросы с нового адреса перестанут проходить аутентификацию.

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

import requests

# Прямой маршрут — исходящий IP самой машины:
print(requests.get("https://api.ipify.org").text)

# Через прокси — исходящий IP, который реально увидит Binance:
proxy = {"https": "http://login:password@PROXY_IP:port"}
print(requests.get("https://api.ipify.org", proxies=proxy).text)

Адрес, который напечатает второй вызов с активными прокси-настройками бота, и нужно добавить в белый список. Отсюда следует важное требование: whitelist зависит от стабильности каждого адреса в нём. При смене динамического исходящего IP аутентификация перестаёт проходить. В production обычно используют один статический исходящий адрес на ключ — фиксированный IP, который сохраняется после перезагрузок и редеплоев, — и добавляют его один раз.

Что означает ошибка -2015

-2015: Invalid API-key, IP, or permissions for action называет три возможные причины, но не сообщает, какая из них сработала. Проверяйте их в порядке вероятности.

Начинайте с IP — это частая и незаметная причина: текущего исходящего адреса нет в белом списке ключа. Выполните проверку из предыдущего раздела через тот же маршрут, которым ходит проблемный код, и посимвольно сравните результат со списком. Сменившийся домашний IP, передеплоенный контейнер или трафик, случайно ушедший мимо прокси, приводят к такому расхождению. Затем проверьте разрешение. У ключа может не быть права на конкретный вызов: торговый запрос выполняется с read-only-ключом, фьючерсный запрос — с ключом, созданным до открытия фьючерсного аккаунта, вывод — с ключом без IP Access Restriction. Запросите apiRestrictions и проверьте соответствующее булево значение. Наконец, проверьте сам ключ: тестовый ключ мог быть направлен в production, ключ мог быть удалён или просрочен, а при копировании мог добавиться пробел.

Одна практика заметно упрощает диагностику -2015: записывайте исходящий IP при запуске бота рядом с последними четырьмя символами ключа. При появлении ошибки лог сразу покажет, использовались ли ожидаемые ключ и маршрут.

Правила безопасности для любого API-ключа

IP whitelist отвечает только за одну часть безопасности ключа. Остальные правила основаны на рекомендациях Binance и типовых сбоях production-систем.

Выдавайте минимум прав. Чтение, торговля и вывод — отдельные переключатели: включайте только то, чем пользуется интеграция. Трекеру цен достаточно чтения. Торговому боту нужны чтение и спотовая торговля. Вывод должен оставаться выключенным, если перемещение средств через API не является явной частью рабочего процесса. Утечка торгового ключа тоже может привести к потерям через манипулятивные сделки на низколиквидных парах, поэтому ограничения по IP важны даже без разрешения на вывод.

Используйте отдельный ключ для каждой интеграции. Выдайте собственные ключи боту, дашборду и налоговому сервису вместо одного общего. Так разрешения остаются ограниченными, компрометация одного ключа не затрагивает остальные интеграции, а его отзыв не останавливает другие инструменты. Регулярно проверяйте ключи: откройте страницу API Management, удалите неизвестные ключи, смените оставшиеся и предпочитайте Ed25519 там, где этот тип поддерживается вашим стеком. Binance рекомендует Ed25519, а подписи с ним работают быстрее.

Храните секреты вне кода. Ключи должны находиться в переменных окружения или менеджере секретов, но не в репозитории. Публичные репозитории постоянно сканируются на ключи бирж, поэтому опубликованный секрет следует считать скомпрометированным. Если ключ мог попасть к третьим лицам, сначала удалите его, выпустите новый и заново настройте ограничения по IP.

Эти меры лучше всего работают, когда каждый ключ использует один известный статический исходящий адрес. Под такую схему подходят наши прокси для Binance: выделенные IPv4, которые остаются статическими весь срок действия плана, по одному на ключ или бота, с доступом через IP whitelisting и поддержкой HTTP, HTTPS, SOCKS4 и SOCKS5. Добавьте тот же IP прокси в whitelist Binance, чтобы торговое разрешение оставалось активным.