Proxy dla danych rynkowych kryptowalut: przewodnik implementacji dla zespołów quant

Proxy dla danych rynkowych kryptowalut — dlaczego to nie jest zwykły scraping

Dane rynkowe kryptowalut to dziś podstawowy surowiec dla zespołów quant, usług market-data, DeFi analytics i platform arbitrażowych. Proxy dla danych rynkowych kryptowalut nie są jednak uniwersalnym narzędziem — ich rola drastycznie różni się w zależności od tego, czy pobierasz dane on-chain (z blockchaina przez RPC), czy z centralizowanych giełd (CEX). W tym przewodniku skupiamy się na implementacji, a nie na definicjach: pokazujemy, gdzie proxy są konieczne, gdzie są zbędne, i jak zbudować architekturę, która utrzyma throughput i integralność sekwencji zdarzeń.

Dla zespołów quant najważniejsze są trzy metryki: latency, success rate oraz sequence integrity (kolejność i timestamp zdarzeń). Crypto market data scraping bez proxy zwykle kończy się na 429, a w skrajnych przypadkach na 451 — statusie, który giełdy zwracają, gdy uznają, że ruch pochodzi z jurysdykcji zakazanej przez ich ToS. Właśnie dlatego regulaminy giełd i geo-bloki są pierwszą rzeczą, którą trzeba zrozumieć przed napisaniem choćby linii kodu.

On-chain vs CEX: dwa zupełnie różne problemy

Podstawowy błąd zespołów zaczynających budowę market-data pipeline to traktowanie blockchaina i giełdy jako tego samego źródła. W rzeczywistości to dwa oddzielne stosy technologiczne, z różnymi wymaganiami co do proxy.

Dane on-chain — RPC i indexery

Dane on-chain pobiera się przez RPC nodes (np. Alchemy, Infura, QuickNode) lub dedykowane indexery (The Graph, Dune, własne node’y). Tu ruch idzie do jednego endpointu HTTPS/WS, który sam zarządza rate limitami na poziomie klucza API. Proxy nie są tu potrzebne do omijania blokad — provider rozlicza Cię po requestach lub jednostkach compute.

Proxy mogą mieć jednak sens w dwóch przypadkach:

• Throughput: gdy provider nakłada per-IP limits na free tier, rotacja residential IP może podbić limit z 10 req/s do ~100 req/s bez przejścia na wyższy plan.
• Geo: niektóre RPC providers mają endpointy regionalne — proxy w tym samym regionie co node obniżają latency o 30–80 ms.

W 90% przypadków on-chain wystarczy dobry provider RPC + odpowiedni plan. Proxy wchodzą do gry dopiero przy bardzo wysokiej konkurencji o rate limit.

Dane CEX — scraping i public API

Tutaj sytuacja jest inna. Giełdy (Binance, Coinbase, OKX, Bybit) udostępniają publiczne REST i WebSocket endpoints, ale:

• Stosują IP-based rate limits — np. Binance public REST ma weight 1200/min per IP.
• Geo-blokują całe jurysdykcje: Binance.com blokuje IP z USA (stąd Binance.US), podobnie Bybit i OKX w niektórych regionach.
• Eskalują od 429 Too Many Requests do 451 Unavailable For Legal Reasons, gdy uznają, że ruch narusza ToS lub pochodzi z zakazanej lokacji.

To sprawia, że exchange API proxies to kategoria sama w sobie — muszą oferować geo-targetowanie, sticky session i przewidywalną rotację, a nie tylko „ukrywanie IP”.

Co dokładnie scrapujemy — mapa targetów

Zanim dojdziemy do implementacji, warto sprecyzować, jakie dane pobieramy. Każdy target ma inną wrażliwość na rate limit i geo-blok.

Warto zauważyć, że Binance proxy to osobny pod-temat — giełda ma najbardziej rozbudowany system weight limits i najagresywniejsze geo-bloki spośród topowych CEX. Z tego powodu większość zespołów quant traktuje Binance jako osobny pipeline z dedykowaną strategią rotacji.

Dlaczego residential proxy mają znaczenie dla CEX scraping

Datacenter proxy są tańsze i szybsze, ale giełdy coraz skuteczniej je wykrywają. ASN fingerprinting i bazy IP2Location pozwalają odróżnić IP z DigitalOcean czy AWS od IP domowego operatora. Residential proxy mają tę zaletę, że pochodzą z puli ISP, co utrudnia klasyfikację jako „bot traffic”.

Dla crypto market data scraping to ma trzy konkretne konsekwencje:

1. Niższy wskaźnik 429 — residential IP częściej traktowane są jak normalny klient.
2. Obejście geo-bloków — IP z Singapuru czy Japonii dla Binance.com wygląda jak lokalny użytkownik.
3. Stabilniejsze sesje WebSocket — giełdy rzadziej zrywają long-lived połączenia z residential IP.

Mobile proxy są jeszcze „lepsze” pod kątem reputacji, ale mają wyższą latency (często 200–500 ms), co dyskwalifikuje je do real-time orderbook streaming. Dlatego dla CEX market data rekomendujemy residential sticky w regionie giełdy, a mobile tylko jako fallback dla ekstremalnie blokowanych targetów.

Architektura — WebSocket-first z REST fallback

Najczęstszy błąd to budowanie pipeline wyłącznie na REST. Dla real-time danych (orderbook, trades, liquidations) WebSocket jest obowiązkowy: niższy overhead, push zamiast poll, mniejsze ryzyko rate limit. REST stosujemy jako fallback dla snapshotów i endpointów, których giełda nie wystawia na WS.

Proponowana architektura:

• Warstwa 1 — WebSocket: jedno long-lived połączenie per giełda, przez residential sticky session.
• Warstwa 2 — REST snapshot: orderbook snapshot co N sekund, z rotacją IP tylko przy 429.
• Warstwa 3 — reconciler: łączy stream WS ze snapshotami REST, waliduje sequence id i timestampy.
• Warstwa 4 — storage: timeseries DB (kdb+, ClickHouse, QuestDB) z partycjonowaniem po symbolu i giełdzie.

Kluczowe: sequence integrity. Binance i OKX wystawiaj lastUpdateId / u w orderbook diff — jeśli gap wystąpi, trzeba przeładować snapshot. Proxy z rotacją per-request psują tę logikę, dlatego dla WS używamy sticky session, a rotację robimy tylko przy restarcie połączenia.

Przykład 1 — Binance WebSocket przez ProxyHat (SOCKS5)

import asyncio, websockets, json

# SOCKS5 sticky session w Singapurze dla Binance.com
PROXY = "socks5://user-country-SG-session-bn01:pass@gate.proxyhat.com:1080"
URL = "wss://stream.binance.com:9443/ws/btcusdt@depth@100ms"

async def listen():
    async with websockets.connect(URL, proxy=PROXY, ping_interval=20) as ws:
        async for msg in ws:
            data = json.loads(msg)
            # data["u"] = lastUpdateId — używane do reconcilacji ze snapshotem
            print(data["u"], data["b"][0] if data.get("b") else None)

asyncio.run(listen())

Sticky session session-bn01 utrzymuje to samo IP przez całą sesję — giełda widzi stabilnego klienta, a my nie tracimy kolejności diff-ów.

Przykład 2 — REST snapshot z rotacją przy 429 (Python)

import requests, time
from itertools import cycle

PROXIES = [
    "http://user-country-SG-session-snap1:pass@gate.proxyhat.com:8080",
    "http://user-country-SG-session-snap2:pass@gate.proxyhat.com:8080",
    "http://user-country-SG-session-snap3:pass@gate.proxyhat.com:8080",
]
pool = cycle(PROXIES)

def snapshot(symbol="BTCUSDT", limit=1000):
    url = f"https://api.binance.com/api/v3/depth?symbol={symbol}&limit={limit}"
    for attempt in range(5):
        p = {"http": next(pool), "https": next(pool)}
        r = requests.get(url, proxies=p, timeout=5)
        if r.status_code == 200:
            return r.json()
        if r.status_code in (429, 451):
            time.sleep(2 ** attempt)  # exponential backoff
            continue
        r.raise_for_status()
    raise RuntimeError("snapshot failed")

Status 451 traktujemy tak samo jak 429 — to sygnał, że obecne IP lub region jest flagowany i trzeba przełączyć sesję.

Przykład 3 — curl z geo-targetowaniem dla Coinbase

curl -x "http://user-country-US-session-cb1:pass@gate.proxyhat.com:8080" \
  "https://api.exchange.coinbase.com/products/BTC-USD/book?level=2"

Dla Coinbase używamy US IP, ponieważ giełda ma endpointy zoptymalizowane pod North America i niższy latency z US-East.

Latency — wybór regionu proxy ma znaczenie

W crypto market data scraping latency to nie tylko wygoda — to bezpośrednio P&L dla strategii arbitrażowych. Zasada jest prosta: proxy powinno być w tym samym regionie co endpoint giełdy.

• Binance.com — główne serwery w Tokio i Singapurze → proxy SEA (SG, JP, HK).
• Bybit, OKX — podobnie SEA.
• Coinbase, Kraken — US-East (Virginia, Chicago) → proxy US.
• Bitstamp — EU (Luxemburg) → proxy EU (DE, NL, FR).

Konkretnie: residential proxy US-East do Coinbase ma latency ~20–40 ms, podczas gdy proxy EU do Coinbase to ~120–180 ms. Dla orderbook streaming na poziomie 100ms diff to różnica między „działa” a „zawsze spóźniony o jeden tick”.

Dane liczbowe z testów produkcyjnych zespołów quant:

• Binance WS depth@100ms przez ProxyHat SG: median latency 35 ms, p99 90 ms.
• Coinbase REST L2 przez ProxyHat US-East: median 28 ms, p99 70 ms.
• Bybit WS przez ProxyHat SG: median 40 ms, p99 110 ms.

Te liczby pokazują, że geo-targetowanie proxy to nie dodatek, a wymóg dla real-time CEX data.

Regulatory i ToS — co wolno, a czego nie

Crypto to obszar, gdzie regulacje zmieniają się co kwartał. Kilka zasad, które warto trzymać w pipeline:

1. Czytaj ToS giełdy. Binance, OKX i Bybit mają w ToS klauzule zakazujące scraping z jurysdykcji objętych embargiem. Omijanie geo-bloku w celu naruszenia ToS to jedno, ale omijanie go w celu naruszenia lokalnego prawa (np. US sanctions) to zupełnie inna kategoria.
2. Rozróżnij publiczne vs prywatne dane. Publiczne price feed i orderbook są powszechnie scrapowane. Privileged data (np. dane innych użytkowników, internal endpoints) — nigdy.
3. Market-data license. Niektóre giełdy (zwłaszcza tradycjonalne jak CME/ICE) wymagają licencji do redystrybucji depth-of-market. CEX zwykle nie, ale jeśli budujesz usługę SaaS market-data, sprawdź, czy Twoi klienci potrzebują sub-licencji.
4. SEC / MiFID II. Jeśli pochodzące z crypto dane wchodzą do raportowania finansowego lub indeksów referencyjnych, mogą podlegać przepisom o benchmarkach (EU BMR) lub regulacjom SEC dot. investment adviser. To rzadki przypadek, ale dla SaaS market-data istotny.
5. GDPR / CCPA. Same dane rynkowe nie są danymi osobowymi, ale logi z adresów IP klientów już tak — pamiętaj o retencji i minimizacji.

Nasza rekomendacja: omijanie geo-bloków w celu czytania publicznych endpointów jest akceptowalne, o ile nie narusza lokalnego prawa. Jeśli jednak giełda wyraźnie zabrania dostępu z Twojej jurysdykcji i Ty to obchodzisz, ryzykujesz banem konta i ewentualnie roszczeniami cywilnymi. Konsultuj z legalnym zespołem przed deploymentem produkcyjnym.

ProxyHat — konfiguracja i integracja

ProxyHat udostępnia residential, mobile i datacenter proxy z geo-targetowaniem na poziomie kraju i miasta. Dla crypto market data rekomendujemy pulę residential z sticky session w regionie giełdy. Konfiguracja sprowadza się do ustawienia username z flagami geo i session.

Formaty:

• HTTP: http://user-country-SG-session-bn01:pass@gate.proxyhat.com:8080
• SOCKS5: socks5://user-country-US-session-cb1:pass@gate.proxyhat.com:1080
• City-level: http://user-country-DE-city-berlin-session-x1:pass@gate.proxyhat.com:8080

Szczegóły konfiguracji znajdziesz w dokumentacji ProxyHat. Cennik i plany: /pl/pricing. Dostępne lokalizacje: /pl/locations.

Jeśli chcesz zobaczyć, jak ProxyHat sprawdza się w szerszym kontekście web scraping, przeczytaj use case web scraping oraz SERP tracking. Te same wzorce (rotacja przy 429, sticky dla sesji, geo dla latency) przenoszą się bezpośrednio na CEX market data.

Przykład 4 — Node.js: WebSocket OKX z ProxyHat

const { WebSocket } = require("ws");
const { SocksProxyAgent } = require("socks-proxy-agent");

const agent = new SocksProxyAgent(
  "socks5://user-country-SG-session-okx1:pass@gate.proxyhat.com:1080"
);

const ws = new WebSocket("wss://ws.okx.com:8443/ws/v5/public", { agent });

ws.on("open", () => {
  ws.send(JSON.stringify({
    op: "subscribe",
    args: [{ channel: "books", instId: "BTC-USDT-SWAP" }]
  }));
});

ws.on("message", (raw) => {
  const msg = JSON.parse(raw.toString());
  // OKX zwraca seqId w data — używane do gap detection
  if (msg.data) console.log(msg.data[0]?.seqId);
});

Najczęstsze błędy i edge cases

• Rotacja IP na WebSocket: psuje sequence integrity. Używaj sticky session dla WS, rotuj tylko przy restarcie.
• Jeden IP dla równoległych REST: giełda traktuje to jako „burst”, szybko 429. Używaj co najmniej 3–5 sesji.
• Ignorowanie weight limitu: Binance liczy weight, nie requesty. 10 zapytań /depth?limit=1000 to 20 weight, nie 10.
• Brak reconcilacji snapshot + diff: orderbook driftuje, jeśli nie sprawdzasz lastUpdateId.
• Zbyt agresywny backoff: 60s wait po pierwszym 429 to overkill — zacznij od 1s, potem 2s, 4s.
• Mieszanie regionów proxy: SG proxy do Coinbase daje 150 ms latency zamiast 30 ms. Mapuj region proxy do regionu giełdy.
• Nieczytanie ToS: niektóre giełdy (np. dla klientów instytucjonalnych) mają osobne klauzule o automated access.

Kluczowe wnioski (Key Takeaways)

• Dane on-chain i CEX to dwa różne problemy — proxy są potrzebne głównie dla CEX scraping.
• WebSocket-first + REST fallback + reconciler to standardowa architektura market-data pipeline.
• Residential proxy ze sticky session w regionie giełdy dają najlepszy kompromis latency vs reputacja IP.
• Status 451 traktuj jak 429 — to sygnał do zmiany sesji, nie do paniki.
• Geo-targetowanie proxy bezpośrednio wpływa na latency: US-East do Coinbase ~28 ms, EU ~150 ms.
• Czytaj ToS giełdy i rozróżnij omijanie geo-bloku (często OK dla publicznych danych) od naruszenia lokalnego prawa (nigdy nie OK).

Jeśli budujesz produkcyjny crypto market-data pipeline, zacznij od residential proxy w regionie giełdy, sticky session dla WS i jasnej polityki rotacji dla REST. ProxyHat udostępnia wszystkie potrzebne flagi w username — bez dodatkowego SDK. Sprawdź cennik i dostępne lokalizacje, a następnie zintegruj bramkę gate.proxyhat.com:8080 ze swoim stackiem quant.