Web Scraping 12 min czytania

Proxy do danych rynkowych kryptowalut: Kompletny przewodnik implementacji

Praktyczny przewodnik po używaniu proxy do scrapingu danych rynkowych kryptowalut — od CEX po on-chain. Architektura, latency, regulacje i przykłady kodu dla zespołów quant.

ProxyHat Team
Proxies for Cryptocurrency Market Data: A Practical Guide

Dlaczego proxy do danych rynkowych kryptowalut są niezbędne

Zespoły quant i dostawcy usług market-data potrzebują niezawodnego dostępu do danych z giełd kryptowalut i blockchainów. Problem polega na tym, że centralizowane giełdy (CEX) aktywnie ograniczają i blokują zautomatyzowane żądania — a dane on-chain wymagają zupełnie innego podejścia. Proxy do danych rynkowych kryptowalut (ang. proxies for cryptocurrency market data) rozwiązują te problemy, umożliwiając stabilny dostęp do price feeds, orderbooków, funding rates i danych o liquidacjach.

W tym przewodniku wyraźnie rozgraniczamy dwie ścieżki danych:

  • Dane z CEX — Binance, Coinbase, OKX, Bybit — wymagają proxy residential/mobile do omijania rate limitów i blokad geograficznych.
  • Dane on-chain — RPC nodes (Alchemy, Infura, QuickNode) — zazwyczaj nie wymagają proxy, ale mogą zyskać na przepustowości przy dystrybucji geograficznej.

Jeśli budujesz pipeline danych krypto, musisz zrozumieć tę różnicę, żeby nie marnować zasobów i nie łamać regulaminów giełd.

Dane on-chain vs dane z CEX — dwie różne architektury

Dane on-chain: RPC nodes i indexerzy

Dane on-chain pochodzą bezpośrednio z blockchaina — salda walletów, zdarzenia smart kontraktów, logi DEX, mint/burn. Dostęp uzyskuje się przez RPC nodes (np. Alchemy, Infura, QuickNode) lub indexerów (np. The Graph, Dune Analytics).

Kluczowa różnica: RPC nodes nie blokują Cię na podstawie IP w taki sam sposób jak giełdy. Dostawcy RPC stosują rate limity na podstawie klucza API, nie adresu IP. Oznacza to, że proxy residential rzadko są potrzebne do samych zapytań on-chain.

Wyjątki:

  • Przy bardzo wysokiej przepustowości (>1000 req/s) dystrybucja zapytań przez wiele lokalizacji może poprawić throughput.
  • Niektórzy dostawcy RPC stosują soft rate limity, które mogą być omijane przez rotację IP — ale to zazwyczaj oznacza, że potrzebujesz wyższego planu, nie proxy.

Dane z CEX: giełdy aktywnie bronią się przed scrapowaniem

Centralizowane giełdy to zupełnie inna kategoria. Binance, Coinbase, OKX i Bybit utrzymują publiczne API, ale agresywnie egzekwują rate limity i geo-restrykcje:

GiełdaPubliczny rate limitGeo-blokadyTypowa odpowiedź przy limicie
Binance1200 req/min (REST)Blokuje IP z USA429 → 451 przy powtórzeniu
Coinbase10 000 req/min (public)Ograniczone w niektórych jurysdykcjach429
OKX20 req/2s (REST)Blokuje wybrane regiony429, 403
Bybit120 req/min (publiczne endpointy)Ograniczony dostęp z USA429, 403

Źródło: dokumentacja Binance API, dokumentacja OKX API v5.

Kiedy giełda wykryje nadmierne zapytania z jednego IP, eskalacja wygląda tak:

  1. 429 Too Many Requests — tymczasowy soft ban, zwykle 1-5 minut.
  2. 403 Forbidden — IP trwale blokowane na dany endpoint.
  3. 451 Unavailable for Legal Reasons — IP zablokowane ze względów geograficznych, często bez możliwości odwrócenia.

Kluczowe spostrzeżenie: Binance oficjalnie blokuje dostęp z amerykańskich adresów IP, kierując użytkowników z USA na Binance.US. Obejście tej blokady proxy może naruszać regulaminy i lokalne prawo — o czym więcej w sekcji regulacyjnej.

Jakie dane scrapujemy z CEX i dlaczego

Price feeds i tickery

Najczęściej scrapowane endpointy to publiczne ceny spot i futures. Przykładowy endpoint Binance:

GET /api/v3/ticker/price?symbol=BTCUSDT

Zwraca aktualną cenę w czasie < 50ms. Dla quant teams to podstawowy building block sygnałów tradingowych.

Orderbook snapshots

Orderbook depth pozwala obliczyć bid-ask spread, slippage i płynność. Binance oferuje depth do 5000 poziomów:

GET /api/v3/depth?symbol=BTCUSDT&limit=1000

Pełny snapshot 5000 poziomów to ~2 MB danych — przy częstym odpytywaniu szybko uderzysz w rate limit.

Funding rates i liquidacje

Funding rates to krytyczny sygnał dla perp-tradingu. Binance publikuje je na /fapi/v1/fundingRate. Dane o liquidacjach są dostępne na /fapi/v1/allForceOrders. Te endpointy są szczególnie agresywnie rate-limitowane, ponieważ zawierają cenne sygnały rynkowe.

Architektura scrapingu: WebSocket-first z REST fallback

Profesjonalny pipeline danych kryptowalut powinien być WebSocket-first wszędzie, gdzie giełda udostępnia publiczne strumienie WS.

Dlaczego WebSocket?

  • Mniej żądań HTTP = mniejsze ryzyko rate limitów.
  • Dane w czasie rzeczywistym (latency < 100ms vs 200-500ms dla REST polling).
  • Jedno połączenie WS może dostarczać tysiące aktualizacji orderbooka na sekundę.

Problem: WebSocket również wymaga proxy, gdy giełda blokuje IP z Twojej lokalizacji.

REST z rotacją proxy jako fallback

REST jest niezbędny dla:

  • Snapshotów orderbook (inicjalny stan przed subskrypcją WS delta).
  • Endpointów historycznych (kandle, funding rate history).
  • Recovery po utracie połączenia WS.

Tutaj residential proxy z rotacją per-request są kluczowe.

Przykład implementacji w Python

Poniższy kod pobiera orderbook snapshot z Binance przez ProxyHat z rotacją IP:

import requests
from itertools import cycle

# ProxyHat configuration
PROXY_URL = "http://user-country-US:PASSWORD@gate.proxyhat.com:8080"

# For per-request rotation, use sticky sessions with unique session IDs
proxies = {
    "http": PROXY_URL,
    "https": PROXY_URL,
}

def fetch_orderbook(symbol: str, limit: int = 100) -> dict:
    """Fetch Binance orderbook snapshot via ProxyHat."""
    url = "https://api.binance.com/api/v3/depth"
    params = {"symbol": symbol, "limit": limit}
    
    # Use sticky session for consistency within a single request
    session = requests.Session()
    session.proxies = proxies
    
    response = session.get(url, params=params, timeout=10)
    
    if response.status_code == 429:
        # Rate limited — rotate to a new IP
        print("Rate limited. Rotating IP...")
        return fetch_with_rotation(symbol, limit)
    
    response.raise_for_status()
    return response.json()

def fetch_with_rotation(symbol: str, limit: int) -> dict:
    """Fetch with per-request IP rotation via ProxyHat session IDs."""
    import uuid
    session_id = str(uuid.uuid4())[:8]
    proxy_url = f"http://user-country-US-session-{session_id}:PASSWORD@gate.proxyhat.com:8080"
    
    s = requests.Session()
    s.proxies = {"http": proxy_url, "https": proxy_url}
    
    url = "https://api.binance.com/api/v3/depth"
    response = s.get(url, params={"symbol": symbol, "limit": limit}, timeout=10)
    response.raise_for_status()
    return response.json()

# Usage
orderbook = fetch_orderbook("BTCUSDT", limit=100)
print(f"Best bid: {orderbook['bids'][0]}")
print(f"Best ask: {orderbook['asks'][0]}")

WebSocket przez proxy w Node.js

Do strumieniowania danych w czasie rzeczywistym użyj WebSocket przez SOCKS5 proxy:

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

// ProxyHat SOCKS5 configuration
const agent = new SocksProxyAgent(
  'socks5://user-country-US:PASSWORD@gate.proxyhat.com:1080'
);

// Connect to Binance WebSocket stream
const ws = new WebSocket(
  'wss://stream.binance.com:9443/ws/btcusdt@depth20@100ms',
  { agent }
);

ws.on('open', () => {
  console.log('Connected to Binance WS via ProxyHat');
});

ws.on('message', (data) => {
  const parsed = JSON.parse(data);
  // Process orderbook delta
  if (parsed.bids && parsed.asks) {
    console.log(`Best bid: ${parsed.bids[0]}, Best ask: ${parsed.asks[0]}`);
  }
});

ws.on('error', (err) => {
  console.error('WS error:', err.message);
});

ws.on('close', () => {
  console.log('Connection closed. Reconnecting...');
  // Implement reconnection logic with backoff
});

On-chain: zapytanie RPC bez proxy

Dla kontrastu, zapytanie on-chain przez dostawcę RPC nie wymaga proxy:

import requests

# Direct RPC call — no proxy needed
ALCHEMY_URL = "https://eth-mainnet.g.alchemy.com/v2/YOUR_API_KEY"

def get_latest_block_number() -> int:
    """Fetch latest Ethereum block number via Alchemy RPC."""
    payload = {
        "jsonrpc": "2.0",
        "method": "eth_blockNumber",
        "params": [],
        "id": 1
    }
    response = requests.post(ALCHEMY_URL, json=payload, timeout=10)
    result = response.json()
    return int(result["result"], 16)

block = get_latest_block_number()
print(f"Latest block: {block}")

Jak widać, zapytanie on-chain jest proste — klucz API wystarczy do autoryzacji. Proxy są potrzebne dopiero wtedy, gdy Twój dostawca RPC limituje throughput na klucz i musisz dystrybuować zapytania geograficznie.

Latency i wybór lokalizacji proxy

W tradingu kryptowalut latency ma znaczenie. Każda milisekunda opóźnienia między giełdą a Twoim serwerem to potencjalny slippage.

Zasady wyboru lokalizacji proxy

  • Giełdy w USA (Coinbase, Kraken) — użyj proxy w USA. Target latency: < 50ms.
  • Giełdy w UE (Bitstamp, niektóre endpointy Binance) — proxy w UE (Niemcy, Holandia). Target latency: < 30ms.

ProxyHat oferuje geo-targeting na poziomie kraju i miasta, co pozwala minimalizować latency:

# Low-latency US proxy for Coinbase
curl -x http://user-country-US:PASSWORD@gate.proxyhat.com:8080 \
  "https://api.exchange.coinbase.com/products/BTC-USD/ticker"

# Low-latency EU proxy for Binance (non-US endpoints)
curl -x http://user-country-DE:PASSWORD@gate.proxyhat.com:8080 \
  "https://api.binance.com/api/v3/ticker/price?symbol=BTCUSDT"

# SEA proxy for Bybit (Singapore-hosted)
curl -x http://user-country-SG:PASSWORD@gate.proxyhat.com:8080 \
  "https://api.bybit.com/v5/market/tickers?category=linear&symbol=BTCUSDT"

Typowe latencje z ProxyHat:

  • USA → USA: ~20-40ms
  • UE → UE: ~15-35ms
  • SEA → SEA: ~25-50ms
  • Cross-region (np. USA → SEA): ~150-250ms

Dla arbitrażu cross-exchange, minimalizujesz latency na każdej parze giełd osobno, używając proxy w odpowiednich lokalizacjach.

Najczęstsze błędy i edge case'y

Błąd 1: Używanie datacenter proxy do scrapowania CEX

Giełdy utrzymzają listy znanych zakresów IP datacenter (AWS, GCP, Azure, DigitalOcean). Datacenter proxy są natychmiast wykrywane i blokowane. Residential i mobile proxy są kluczowe, bo pochodzą z puli ISP.

Błąd 2: Brak exponential backoff przy 429

Gdy otrzymasz 429, nie natychmiast ponawiaj zapytanie z nowym IP. Wiele giełd śledzi wzorce zapytań i eskaluje blokady. Implementuj exponential backoff (1s, 2s, 4s, 8s...) i rotuj IP przy każdym ponowieniu.

Błąd 3: Ignorowanie nagłówka Retry-After

Binance i Coinbase zwracają nagłówek Retry-After przy 429. Szanuj tę wartość — to Twój wyznacznik, kiedy bezpiecznie ponowić zapytanie.

Błąd 4: Zbyt agresywny scraping orderbooków

Orderbook depth 5000 poziomów to ~2 MB na zapytanie. Przy 10 req/s to 20 MB/s przepustowości. Giełdy to wykrywają. Używaj WebSocket do delta updates i REST tylko do initial snapshot.

Błąd 5: Mieszanie on-chain i CEX w jednym pipeline proxy

Zapytania on-chain przez RPC nie potrzebują proxy — dodawanie proxy niepotrzebnie zwiększa latency i koszty. Oddziel pipeline CEX (z proxy) od pipeline on-chain (bez proxy).

Regulacje i zgodność prawna

Scraping danych z giełd kryptowalut wiąże się z kwestiami prawnymi, które nie mogą być ignorowane.

Regulaminy giełd (Terms of Service)

Większość giełd wprost zabrania lub ogranicza scraping w swoich ToS. Na przykład Binance w swoich warunkach użytkowania zastrzega prawo do ograniczenia dostępu do API. Coinbase wymaga zgodności z ich polityką API.

Obejście geo-blokad giełdy proxy może naruszać ToS, nawet jeśli samo scrapowanie danych publicznych jest prawnie dopuszczalne w wielu jurysdykcjach.

Regulacje SEC i MiFID II

Zespoły operujące w USA powinny być świadome regulacji SEC dotyczących market data. Według SEC, dane rynkowe mogą podlegać licencjonowaniu, szczególnie jeśli pochodzą z regulated exchanges. W UE, MiFID II nakłada wymagania dotyczące transparencji i raportowania transakcji — dane używane do raportów regulacyjnych muszą spełniać standardy MiFID II.

GDPR i ochrona danych

Jeśli scrapujesz dane zawierające identyfikatory użytkowników (np. wallet addresses powiązane z KYC), musisz przestrzegać GDPR. Dane on-chain są pseudonimizowane, ale powiązanie z danymi z CEX może stworzyć dane osobowe.

Praktyczna zasada: scrapuj tylko dane rynkowe (ceny, wolumeny, orderbooki) — nie dane użytkowników. Jeśli potrzebujesz danych użytkowników, uzyskaj wyraźną zgodę lub kup licencjonowany dataset.

Konfiguracja ProxyHat do danych rynkowych kryptowalut

ProxyHat oferuje residential, mobile i datacenter proxy z geo-targetingiem na poziomie kraju i miasta. Dla scrapingu CEX rekomendujemy residential proxy jako podstawowy wybór.

Konfiguracja podstawowa

Format połączenia HTTP:

http://USERNAME:PASSWORD@gate.proxyhat.com:8080

Format połączenia SOCKS5 (rekomendowany dla WebSocket):

socks5://USERNAME:PASSWORD@gate.proxyhat.com:1080

Geo-targeting

Wybierz kraj, który nie jest blokowany przez docelową giełdę:

  • Dla Binance (global): user-country-DE (Niemcy), user-country-JP (Japonia), user-country-SG (Singapur)
  • Dla Coinbase: user-country-US
  • Dla OKX: user-country-SG, user-country-HK

Szczegółowe lokalizacje znajdziesz na stronie ProxyHat Locations.

Sticky sessions vs rotacja per-request

  • Rotacja per-request — każdy request przez nowy IP. Idealne do REST endpointów historycznych i snapshotów.
  • Sticky sessions — trzymaj IP przez określony czas. Niezbędne dla WebSocket i wielokrokowych operacji.

Przykład sticky session (10 minut):

http://user-country-DE-session-abc123:PASSWORD@gate.proxyhat.com:8080

Szczegóły cennika i planów znajdziesz na ProxyHat Pricing.

Integracja z popularnymi bibliotekami

ProxyHat współpracuje ze wszystkimi standardowymi bibliotekami HTTP i WS. Pełną dokumentację techniczną znajdziesz na docs.proxyhat.com.

Więcej przykładów scrapingu znajdziesz w naszym przewodniku Web Scraping use case oraz SERP Tracking.

Kluczowe wnioski

  • Rozróżniaj on-chain i CEX — dane on-chain (RPC) rzadko wymagają proxy; dane z CEX prawie zawsze.
  • Używaj WebSocket-first — mniej zapytań, niższe latency, mniejsze ryzyko rate limitów.
  • Residential proxy są kluczowe dla CEX — datacenter IP są szybko wykrywane i blokowane.
  • Dopasuj lokalizację proxy do giełdy — US proxy dla Coinbase, EU proxy dla Binance global, SEA proxy dla Bybit.
  • Implementuj exponential backoff — szanuj nagłówki Retry-After i rotuj IP przy ponowieniach.
  • Przestrzegaj regulaminów giełd i lokalnego prawa — nie scrapuj danych użytkowników, nie łam geo-blokad w sposób niezgodny z prawem.
  • Oddziel pipeline CEX i on-chain — proxy dla CEX, bez proxy dla RPC. Nie mieszaj.

Gotowy do budowy pipeline danych kryptowalut? Sprawdź plany ProxyHat i zacznij od residential proxy z geo-targetingiem w 190+ lokalizacjach.

Gotowy, aby zacząć?

Dostęp do ponad 50 mln rezydencjalnych IP w ponad 148 krajach z filtrowaniem AI.

Zobacz cenyProxy rezydencjalne
← Powrót do Bloga