Криптовалютные квантовые команды и сервисы рыночных данных работают в двух параллельных мирах: централизованные биржи (CEX) с их REST и WebSocket API, и ончейн-данные, доступные через RPC-узлы и индексаторы. Подход к прокси в каждом случае кардинально различается. В этом руководстве мы разберём, когда прокси критически необходимы, когда избыточны, и как построить надёжную архитектуру сбора данных.
Два мира криптоданных: ончейн и CEX
Прежде чем выбирать инфраструктуру, важно понимать фундаментальную разницу между источниками данных.
CEX-данные — это данные, которые биржа публикует через свои API: тикеры, стаканы (orderbook), ставки финансирования (funding rates), ликвидации, историю сделок. Доступ контролируется биржей: IP-лимиты, гео-ограничения, требования к API-ключам.
Ончейн-данные — это всё, что записано в блокчейн: транзакции, события смарт-контрактов, состояние памяти (storage), газ-цены. Доступ децентрализован: любой RPC-узел отдаёт одни и те же данные. Биржа не может вас заблокировать, потому что данные не принадлежат ей.
Ключевое правило: если данные приходят с веб-сервера биржи — вам нужны прокси. Если данные читаются из блокчейна через RPC — прокси вторичны.
Целевые данные: что именно мы собираем
CEX — ценовые потоки, стаканы, ставки финансирования
Четыре крупнейшие биржи по объёму — Binance, Coinbase, OKX, Bybit — предоставляют публичные REST и WebSocket API с разной степенью открытости.
| Биржа | Публичный REST | WebSocket | Лимит (запросов/мин) | Гео-блоки |
|---|---|---|---|---|
| Binance | Да | Да | ~1200 (weight-based) | US, Канада, ряд стран ЕС |
| Coinbase | Да | Да | ~600 (public) | Ограниченный список |
| OKX | Да | Да | ~600 | US, ряд юрисдикций |
| Bybit | Да | Да | ~600–1200 | US, Канада, Сингапур |
Типичные целевые эндпоинты:
- Тикеры — текущая цена, объём 24h, процент изменения.
- Orderbook snapshots — глубина стакана до N уровней (10, 20, 100).
- Funding rates — ставки бессрочных фьючерсов, критичны для арбитражных стратегий.
- Ликвидации — потоки принудительных закрытий позиций.
Ончейн — RPC-провайдеры и индексаторы
Для ончейн-данных используются RPC-провайдеры: Alchemy, Infura, QuickNode, а также собственные ноды. Данные включают:
- События DEX (swaps, mints, burns) — через логи смарт-контрактов.
- Состояние пулов ликвидности — reserves, TVL.
- Транзакции MEV и gas-аналитику.
- Данные из The Graph и аналогичных индексаторов.
Здесь прокси обычно не нужны — RPC-провайдер не блокирует по IP, а ограничивает по API-ключу и тарифу. Однако гео-маршрутизация прокси может помочь снизить латентность до ноды (подробнее ниже).
Почему residential-прокси критичны для CEX-скрейпинга
Crypto market data scraping с бирж — это не просто техническая задача, а игра в кошки-мышки с инфраструктурой защиты бирж.
IP-лимиты и эскалация 429 → 451
Биржи используют многоуровневую систему ограничения:
- Предупреждение — заголовки
X-MBX-USED-WEIGHTпоказывают текущую нагрузку. - HTTP 429 Too Many Requests — временная блокировка, обычно на 1–10 минут.
- HTTP 451 Unavailable For Legal Reasons — постоянная блокировка IP на основе геолокации или паттернов злоупотребления.
Проблема в том, что 429 легко эскалирует в 451. Если ваш IP-адрес repeatedly получает 429, биржа может внести его в чёрный список навсегда. Datacenter-IP блокируются быстрее — биржи знают, что легитимные пользователи не заходят из AWS-диапазонов.
Именно здесь residential-прокси дают критическое преимущество: их IP-адреса принадлежат реальным ISP, и биржи не могут массово блокировать такие диапазоны без ущерба для легитимных пользователей.
Географические ограничения бирж
Binance блокирует IP из США, перенаправляя на binance.us. OKX и Bybit блокируют доступ из США и ряда других юрисдикций. При попытке доступа с заблокированного IP вы получаете:
- Редирект на региональный домен с ограниченным функционалом.
- HTTP 451 с юридическим обоснованием.
- Пустые или цензурированные ответы (без определённых торговых пар).
Residential-прокси с гео-таргетингом решают эту проблему — запросы идут через IP-адреса разрешённых юрисдикций. Пример с ProxyHat:
# Binance API через residential-прокси (IP в Германии)
curl -x http://user-country-DE:pass@gate.proxyhat.com:8080 \
"https://api.binance.com/api/v3/depth?symbol=BTCUSDT&limit=100"Обратите внимание: user-country-DE в имени пользователя указывает ProxyHat использовать немецкий IP. Это критически важно для Binance, который блокирует US-IP, но свободно обслуживает ЕС.
Ончейн-подход: когда прокси не нужны, а когда помогают
Для ончейн-данных архитектура принципиально иная. RPC-провайдеры (Alchemy, Infura, QuickNode) авторизуют по API-ключу, а не по IP. Географических ограничений нет — Ethereum-нода в Токио и в Франкфурте возвращают одинаковые данные.
Когда прокси не нужны:
- Вы используете платный RPC-провайдер с достаточным лимитом запросов.
- Латентность не критична (например, историческая аналитика).
- Вы читаете данные из The Graph или аналогичного индексатора.
Когда прокси могут помочь:
- Пропускная способность — если вы упираетесь в лимит одного API-ключа, можно распределять запросы через несколько прокси-IP к разным ключам.
- Латентность — прокси, расположенные рядом с RPC-нодой, снижают round-trip time. Для QuickNode-ноды во Франкфурте используйте немецкий residential-прокси.
- Резервирование — если основной RPC-провайдер падает, прокси через другого провайдера обеспечивает failover.
Архитектура: WebSocket-first + REST с ротацией прокси
Правильная архитектура сбора данных с бирж должна быть WebSocket-first: биржи публикуют публичные WebSocket-стримы для тикеров, стаканов и сделок, и эти стримы не подвержены тем же IP-лимитам, что и REST.
WebSocket для реального времени
WebSocket-соединения поддерживаются долго — одно соединение может стримить данные часами. IP-лимиты для WebSocket обычно мягче: биржа ограничивает количество одновременных соединений с одного IP (обычно 5), а не частоту запросов.
import asyncio
import websockets
import json
# WebSocket Binance через SOCKS5-прокси
# Требует websockets[speedups] и python-socks
from python_socks.async_.asyncio import Proxy
proxy = Proxy.from_url(
"socks5://user-country-DE:pass@gate.proxyhat.com:1080"
)
sock = await proxy.connect(dest_host="stream.binance.com", dest_port=9443)
async with websockets.client.connect(
"wss://stream.binance.com:9443/ws/btcusdt@depth20@100ms",
sock=sock,
ssl=True
) as ws:
while True:
msg = json.loads(await ws.recv())
# Обработка снэпшота стакана
bids = [(float(b[0]), float(b[1])) for b in msg["bids"]]
asks = [(float(a[0]), float(a[1])) for a in msg["asks"]]
print(f"Best bid: {bids[0]}, Best ask: {asks[0]}")Для WebSocket достаточно одного стабильного прокси-соединения — ротация IP здесь не нужна и даже вредна (каждое переподключение теряет данные). Используйте sticky-сессию ProxyHat:
# Sticky-сессия для WebSocket (IP не меняется)
socks5://user-country-DE-session-ws1:pass@gate.proxyhat.com:1080REST-фолбэк с ротацией IP
Для исторических данных, снэпшотов стакана, funding rates и ликвидаций используется REST API. Здесь ротация IP обязательна — без неё вы быстро упрётесь в 429.
import requests
import itertools
import time
class BinanceScraper:
def __init__(self, countries=["DE", "NL", "FR", "GB"]):
self.proxy_cycle = itertools.cycle([
f"http://user-country-{c}:pass@gate.proxyhat.com:8080"
for c in countries
])
self.base = "https://api.binance.com"
def _get(self, path, params=None):
proxy = next(self.proxy_cycle)
resp = requests.get(
f"{self.base}{path}",
params=params,
proxies={"http": proxy, "https": proxy},
timeout=10
)
if resp.status_code == 429:
# Ротация уже произойдёт при следующем вызове
retry_after = int(resp.headers.get("Retry-After", 60))
time.sleep(retry_after)
return self._get(path, params)
resp.raise_for_status()
return resp.json()
def funding_rate(self, symbol="BTCUSDT"):
return self._get("/fapi/v1/fundingRate", {"symbol": symbol, "limit": 100})
def orderbook(self, symbol="BTCUSDT", limit=100):
return self._get("/api/v3/depth", {"symbol": symbol, "limit": limit})
scraper = BinanceScraper()
fr = scraper.funding_rate("ETHUSDT")
print(f"Последняя funding rate ETH: {fr[-1]['fundingRate']}")Ключевой момент: мы ротируем по странам, а не по случайным IP. Это гарантирует, что каждый запрос приходит с residential-IP из разрешённой юрисдикции, и при этом распределение нагрузки снижает риск 429.
Латентность: выбор локации прокси
Для квантовых стратегий латентность критична. Разница в 50мс может стоить арбитражной возможности. Правило простое: прокси должен быть географически близко к серверам биржи.
| Биржа | Основные серверы | Рекомендуемая локация прокси | Ожидаемая RTT |
|---|---|---|---|
| Binance | Tokyo, Singapore | JP, SG (SEA) | 5–20 мс |
| Coinbase | US-East (AWS us-east-1) | US, CA | 10–30 мс |
| OKX | Hong Kong, Singapore | HK, SG | 5–15 мс |
| Bybit | Singapore | SG, HK | 5–15 мс |
Но здесь есть конфликт: Binance блокирует US-IP, а Coinbase — наиболее доступен из US. Решение:
- Для Binance/OKX/Bybit — SEA-прокси (Сингапур, Япония, Гонконг). ProxyHat:
user-country-SG,user-country-JP. - Для Coinbase — US-прокси. ProxyHat:
user-country-US. - Для арбитража CEX-CEX — нужна инфраструктура в обоих регионах с единой координацией.
Для высокочастотных стратегий (HFT) residential-прокси могут добавлять нежелательную латентность. В таких случаях datacenter-прокси в той же зоне доступности — лучший выбор, хотя они блокируются быстрее. Баланс: residential для массового скрейпинга, datacenter для низколатентных стримов.
Пример Node.js для мультибиржевого коллектора с оптимальной маршрутизацией:
const axios = require('axios');
const PROXY_CONFIG = {
binance: {
base: 'https://api.binance.com',
proxy: 'http://user-country-SG:pass@gate.proxyhat.com:8080'
},
coinbase: {
base: 'https://api.exchange.coinbase.com',
proxy: 'http://user-country-US:pass@gate.proxyhat.com:8080'
},
okx: {
base: 'https://www.okx.com',
proxy: 'http://user-country-HK:pass@gate.proxyhat.com:8080'
}
};
async function fetchTicker(exchange, symbol) {
const cfg = PROXY_CONFIG[exchange];
const paths = {
binance: `/api/v3/ticker/price?symbol=${symbol}`,
coinbase: `/products/${symbol}/ticker`,
okx: `/api/v5/market/ticker?instId=${symbol}`
};
const resp = await axios.get(`${cfg.base}${paths[exchange]}`, {
proxy: false,
httpsAgent: new (require('https-proxy-agent'))(cfg.proxy),
timeout: 5000
});
return resp.data;
}
// Арбитражный запрос
Promise.all([
fetchTicker('binance', 'BTCUSDT'),
fetchTicker('coinbase', 'BTC-USD'),
fetchTicker('okx', 'BTC-USDT')
]).then(([b, c, o]) => console.log({ binance: b, coinbase: c, okx: o }));Регуляторные аспекты
Exchange API proxies — это не только технический, но и правовой вопрос. Ключевые моменты:
Условия использования бирж (ToS). Большинство бирж прямо запрещают скрейпинг в своих условиях. Binance ToS, например, запрещает «автоматизированные системы, которые создают чрезмерную нагрузку на инфраструктуру». Практика показывает, что биржи редко преследуют за сбор публичных данных, но могут отозвать API-ключи и заблокировать аккаунт.
Географические ограничения и местное право. Обход гео-блоков Binance из США — это нарушение ToS, но может также нарушать регуляторные требования SEC и FinCEN. Если вы находитесь в США и получаете данные с binance.com через прокси, вы можете нарушать:
- SEC Regulation ATS (если данные используются для торговли).
- Требования KYC/AML для американских резидентов.
- Лицензионные требования штата.
MiFID II и рыночные данные в ЕС. Если вы перепродаёте рыночные данные как сервис в ЕС, MiFID II требует определённой лицензии для поставщиков данных (APAs — Approved Publication Arrangements). Это относится к данным традиционных рынков, но регуляторы всё чаще обращают внимание на крипто-данные.
Лицензирование рыночных данных. Биржи считают свои orderbook-данные проприетарными. Перепродажа данных без лицензии — юридический риск. Это особенно актуально для сервисов, которые агрегируют данные с нескольких бирж и продают подписку.
Практические рекомендации:
- Не используйте API-ключи с правами торговли для сбора данных — только read-only ключи.
- Соблюдайте публичные лимиты запросов; не пытайтесь обойти их агрессивной ротацией.
- Если вы в США — используйте binance.us, а не обходите гео-блок через прокси.
- Проконсультируйтесь с юристом, если перепродаёте данные как сервис.
Ключевые выводы
- CEX-скрейпинг требует прокси — IP-лимиты, гео-блоки и эскалация 429→451 делают residential-прокси обязательными. Datacenter-IP блокируются быстрее.
- Ончейн-данные обычно не требуют прокси — RPC-провайдеры авторизуют по ключу, а не по IP. Прокси помогают только для латентности и пропускной способности.
- WebSocket-first — используйте WebSocket для реального времени (одно стабильное прокси-соединение), REST с ротацией IP для исторических данных и снэпшотов.
- Локация прокси = локация биржи — SEA для Binance/OKX/Bybit, US для Coinbase. Латентность напрямую влияет на арбитражные возможности.
- Регуляция важна — обход гео-блоков может нарушать не только ToS, но и местное законодательство. Для US-резидентов используйте binance.us.
Готовы начать сбор криптоданных через надёжные residential-прокси? Ознакомьтесь с тарифами ProxyHat и доступными локациями — более 190 стран для точного гео-таргетинга ваших запросов.
