Proxy per dati di mercato delle criptovalute: guida pratica all'implementazione

Proxy per dati di mercato delle criptovalute: perché servono e quando no

I proxy per dati di mercato delle criptovalute risolvono un problema concreto che ogni team quant e ogni servizio di market data incontra prima o poi: gli exchange centralizzati (CEX) impongono limiti di frequenza basati sull'IP, restrizioni geografiche aggressive e, in casi estremi, risposte HTTP 451 (Unavailable For Legal Reasons) che bloccano interi range di IP. Se la tua pipeline di crypto market data scraping si basa su endpoint pubblici di Binance, Coinbase, OKX o Bybit, prima o poi ti troverai davanti un HTTP 429 — e poi un ban temporaneo.

Ma non tutti i dati crypto richiedono proxy nello stesso modo. Esistono due categorie fondamentali con dinamiche completamente diverse:

• Dati on-chain (transazioni, stati di contratto, eventi): si ottengono tramite nodi RPC o indexer come Alchemy, Infura, QuickNode. Qui i proxy sono raramente necessari — basta usare più provider o nodi propri.
• Dati di exchange (prezzi, orderbook, funding rates, liquidazioni): si ottengono da API REST/WebSocket pubbliche o da interfacce web dei CEX. Qui i proxy residenziali sono spesso essenziali per superare rate limit e geo-restriction.

Questa guida copre entrambi gli scenari con esempi di codice, considerazioni di latenza e architettura, e setup specifico con ProxyHat.

Target data: cosa raccogliere e da dove

Dati di exchange centralizzati (CEX)

I CEX espongono tipicamente due tipi di interfaccia pubblica:

• API REST pubbliche: ticker, orderbook snapshot, kline/candlestick, funding rates, dati di liquidazione. Esempi: GET /api/v3/ticker/24hr su Binance, GET /api/v3/depth per orderbook.
• WebSocket pubblici: stream in tempo reale per orderbook updates, trade feed, ticker. Esempi: wss://stream.binance.com:9443/ws/btcusdt@depth.

Gli endpoint pubblici REST hanno rate limit che variano per exchange: Binance applica un sistema a peso (weight) con un limite di 1.200 richieste al minuto per IP sulla maggior parte degli endpoint (documentazione ufficiale Binance API). Coinbase ha un limite di 10 richieste al secondo per IP su endpoint pubblici (documentazione Coinbase Exchange API). OKX e Bybit applicano limiti simili, tipicamente 20 richieste ogni 2 secondi per IP.

Il problema è immediato: se fai polling di orderbook su 50 trading pair ogni 500ms, superi il limite di Binance in meno di 30 secondi con un solo IP.

Dati on-chain

I dati on-chain — transazioni Ethereum, log di smart contract, stati di pool Uniswap — si ottengono tramite chiamate JSON-RPC a nodi Ethereum o tramite API di indexer. I provider principali sono:

• Alchemy — API REST e WebSocket, piano free con 300M compute units/mese
• Infura — 100.000 richieste/giorno sul piano free
• QuickNode — endpoint dedicati con latenze <50ms

Per i dati on-chain, i proxy non sono generalmente necessari. I provider RPC gestiscono i rate limit a livello di API key, non di IP. Tuttavia, se gestisci nodi propri o hai bisogno di throughput molto elevato, puoi usare proxy con geo-targeting per ottimizzare la latenza verso nodi in regioni specifiche.

Perché i proxy residenziali matter per il CEX scraping

Rate limit basati su IP

Tutti i principali CEX applicano rate limiting basato sull'IP di origine. Questo significa che aggiungere più API key non aiuta se tutte le richieste provengono dallo stesso IP. La rotazione IP tramite exchange API proxies è la soluzione più diretta: distribuisci le richieste su più IP residenziali, ciascuno con il proprio budget di rate limit.

Il calcolo è semplice: con 50 IP rotanti e un limite di 1.200 richieste/minuto per IP su Binance, ottieni un throughput teorico di 60.000 richieste/minuto — sufficiente per monitorare orderbook su centinaia di pair con frequenza sub-secondo.

Geo-restriction e blocchi regionali

Binance ha bloccato l'accesso da IP statunitensi alla sua piattaforma globale, reindirizzando gli utenti verso Binance.US. Questo significa che se il tuo server è negli Stati Uniti e tenti di accedere a api.binance.com, potresti ricevere un HTTP 451. Altri exchange applicano logiche simili:

• Bybit — restrizioni per utenti in UK, US, e altri paesi
• OKX — geo-restriction variabile per giurisdizione
• Binance — blocco IP US su API globali, endpoint diversi per Binance.US

I proxy residenziali con geo-targeting permettono di selezionare IP in giurisdizioni non bloccate. Un IP residenziale tedesco o giapponese appare come traffico legittimo da quel paese, non come un tentativo di evasione da parte di un datacenter.

Escalation 429 → 451

Un pattern comune e pericoloso: ripetuti HTTP 429 (Too Many Requests) da un IP possono portare l'exchange a bloccare permanentemente quell'IP o persino l'intero range, restituendo HTTP 451. Questo è particolarmente problematico con IP datacenter, che sono spesso già flaggati come sospetti. I proxy residenziali riducono questo rischio perché gli IP appartengono a ISP reali e hanno reputazione più alta.

Approccio on-chain: perché i proxy sono (quasi) irrilevanti

Per i dati on-chain, l'architettura standard è:

1. Usare un provider RPC (Alchemy, Infura, QuickNode) con una API key
2. Inviare chiamate JSON-RPC (eth_getBlockByNumber, eth_getLogs, ecc.)
3. Gestire i rate limit a livello di API key, non di IP

I provider RPC non bloccano per IP — il controllo è tutto sull'API key. Se hai bisogno di più throughput, aggiungi API key o passa a un piano superiore. I proxy entrano in gioco solo in due casi marginali:

• Nodi propri: se gestisci un nodo Ethereum e vuoi distribuire le richieste read da più IP per evitare di saturare la connessione del nodo.
• Throughput su endpoint pubblici gratuiti: alcuni endpoint RPC pubblici (non i provider commerciali) applicano rate limit per IP. Qui i proxy possono aiutare, ma è meglio usare un provider commerciale.

Architettura: WebSocket-first con fallback REST e proxy rotation

Un'architettura robusta per crypto market data scraping combina WebSocket per dati real-time e REST con proxy rotation per snapshot e fallback.

Livello 1: WebSocket per real-time

Gli exchange espongono WebSocket pubblici che non richiedono autenticazione per i dati di mercato. Il WebSocket mantiene una connessione persistente, quindi il rate limit per IP è meno problematico — ma la connessione può essere chiusa dall'exchange se rileva comportamento anomalo.

Ecco un esempio in Node.js per il feed orderbook di Binance:

const WebSocket = require('ws');

// Binance public WebSocket — no auth needed for market data
const ws = new WebSocket('wss://stream.binance.com:9443/ws/btcusdt@depth@100ms');

ws.on('open', () => {
  console.log('WS connected to Binance depth stream');
});

ws.on('message', (data) => {
  const update = JSON.parse(data);
  // Process orderbook delta
  // { lastUpdateId, bids: [[price, qty]], asks: [[price, qty]] }
});

ws.on('error', (err) => {
  console.error('WS error:', err.message);
  // Implement reconnect with backoff
});

ws.on('close', () => {
  console.log('WS closed — reconnecting in 3s');
  setTimeout(connect, 3000);
});

Per i WebSocket, i proxy sono utili principalmente per: (a) evitare geo-block sulla connessione iniziale, (b) distribuire connessioni multiple su IP diversi quando monitorai centinaia di stream.

Livello 2: REST con proxy rotation per snapshot e fallback

Per snapshot periodici (orderbook completo, funding rates, kline storici), il REST API è la via principale. Qui la proxy rotation è essenziale.

Esempio in Python con ProxyHat:

import requests
import itertools

# ProxyHat residential proxy with rotation
# Format: http://user-country-DE:pass@gate.proxyhat.com:8080
proxy_url = "http://user-country-DE:YOUR_PASSWORD@gate.proxyhat.com:8080"

proxies = {
    "http": proxy_url,
    "https": proxy_url,
}

# Binance public endpoint — orderbook snapshot
url = "https://api.binance.com/api/v3/depth"
params = {"symbol": "BTCUSDT", "limit": 100}

try:
    resp = requests.get(url, params=params, proxies=proxies, timeout=10)
    if resp.status_code == 200:
        orderbook = resp.json()
        print(f"Bids: {len(orderbook['bids'])}, Asks: {len(orderbook['asks'])}")
    elif resp.status_code == 429:
        print("Rate limited — proxy should rotate on next request")
    elif resp.status_code == 451:
        print("Geo-blocked — try different country flag")
    else:
        print(f"Unexpected status: {resp.status_code}")
except requests.exceptions.RequestException as e:
    print(f"Request failed: {e}")

Livello 3: curl per test rapidi

Per verificare rapidamente che un proxy funzioni con un endpoint specifico:

# Test Binance ticker through ProxyHat with German IP
curl -x http://user-country-DE:YOUR_PASSWORD@gate.proxyhat.com:8080 \
  "https://api.binance.com/api/v3/ticker/price?symbol=BTCUSDT"

# Test with Japanese IP for Bybit
curl -x http://user-country-JP:YOUR_PASSWORD@gate.proxyhat.com:8080 \
  "https://api.bybit.com/v5/market/tickers?category=spot&symbol=BTCUSDT"

# SOCKS5 variant for lower overhead
curl -x socks5://user-country-SG:YOUR_PASSWORD@gate.proxyhat.com:1080 \
  "https://api.okx.com/api/v5/market/ticker?instId=BTC-USDT"

Considerazioni di latenza: proxy per regione di exchange

La latenza del proxy è critica per il market data. Un proxy con 200ms di latenza aggiuntiva può rendere inutile un feed che dovrebbe essere near-real-time. La regola generale è: usa proxy nella stessa regione del server dell'exchange.

Exchange	Regione server principale	Proxy consigliato	Latenza tipica
Binance (globale)	Asia Sud-Est (SG, JP)	Proxy SG/JP	30-80ms
Binance.US	USA (est)	Proxy US	20-60ms
Coinbase	USA (est/ovest)	Proxy US	20-50ms
OKX	Asia (HK, SG)	Proxy HK/SG	40-90ms
Bybit	Asia (SG)	Proxy SG	30-70ms
Kraken	USA/EU	Proxy US/EU	30-80ms

Con ProxyHat, puoi specificare il paese nel flag username:

# Singapore proxy for Binance/Bybit — low latency to SEA servers
http://user-country-SG:YOUR_PASSWORD@gate.proxyhat.com:8080

# US proxy for Coinbase
http://user-country-US:YOUR_PASSWORD@gate.proxyhat.com:8080

# City-level targeting for even lower latency
http://user-country-DE-city-frankfurt:YOUR_PASSWORD@gate.proxyhat.com:8080

Per i Binance proxy in particolare, Singapore e Giappone offrono le latenze più basse verso i server principali di Binance. Per Coinbase, proxy negli USA (est) sono preferibili.

Sessioni sticky vs rotazione per-request

ProxyHat supporta due modalità di rotazione:

• Rotazione per-request: ogni richiesta ottiene un IP nuovo. Ideale per distribuire il carico REST su molti IP e massimizzare il throughput.
• Sessioni sticky: un ID di sessione mantiene lo stesso IP per un periodo. Ideale per WebSocket o per sequenze REST che devono provenire dallo stesso IP (es. paginazione orderbook).

Esempio di sessione sticky:

# Sticky session — same IP for all requests in this session
http://user-session-myfeed001-country-DE:YOUR_PASSWORD@gate.proxyhat.com:8080

Per il WebSocket, usa una sessione sticky: la connessione deve rimanere sullo stesso IP per tutta la sua durata. Per il REST polling, usa rotazione per-request per massimizzare il throughput.

Errori comuni e edge case

1. Usare proxy datacenter invece di residenziali

I CEX mantengono liste di IP datacenter noti (AWS, GCP, Azure, DigitalOcean). Le richieste da questi IP sono spesso flaggate o rate-limited più aggressivamente. I proxy residenziali hanno reputazione ISP reale e sono molto meno soggetti a blocchi preventivi.

2. Ignorare il weight system di Binance

Binance non conta le richieste 1:1 — ogni endpoint ha un peso (weight). Un /api/v3/depth con limit=1000 costa 20 weight, non 1. Con un limite di 1.200 weight/minuto per IP, puoi fare solo 60 chiamate/minuto a quell'endpoint con un singolo IP. Calcola il throughput in base al weight, non al numero di richieste.

3. Non gestire il reconnect WebSocket

I WebSocket dei CEX si disconnettono regolarmente (manutenzione, timeout, restart). Senza una logica di reconnect con backoff, perdi minuti di dati. Implementa sempre reconnect con backoff esponenziale (1s, 2s, 4s, 8s, max 30s).

4. Mischiare endpoint globali e regionali

Binance globale (api.binance.com) e Binance.US (api.binance.us) hanno pair diversi, fee diverse, e dati diversi. Non assumere che i proxy US funzionino con l'endpoint globale — usa proxy non-US per l'endpoint globale e proxy US per Binance.US.

5. Non rispettare i rate limit header

Molti CEX restituiscono header con il rate limit residuo: X-MBX-USED-WEIGHT-1M su Binance, X-RateLimit-Remaining su Coinbase. Leggi questi header e adatta il throughput dinamicamente invece di aspettare il 429.

Considerazioni regolamentari

Lo scraping di dati di mercato crypto solleva questioni regolamentari che vanno oltre la pura tecnica:

• Termini di servizio (ToS) dell'exchange: la maggior parte dei CEX permette l'accesso ai dati di mercato pubblici via API, ma proibisce lo scraping dell'interfaccia web. Leggi i ToS prima di raschiare pagine HTML.
• Geo-restriction e legge locale: usare un proxy per accedere a un exchange da una giurisdizione bloccata può violare i ToS dell'exchange e, in alcuni casi, la legge locale. Per esempio, accedere a Binance globale dagli USA tramite proxy non-US viola i ToS di Binance e potenzialmente regolamenti CFTC/SEC. La SEC ha chiarito la propria giurisdizione su molti asset crypto — assicurati di comprendere le implicazioni.
• Licenze di market data: se redistribuisci i dati a terzi (come servizio di market data), alcuni exchange richiedono accordi di licenza commerciali. I dati di mercato pubblici sono generalmente liberamente utilizzabili per uso interno, ma la redistribuzione commerciale può richiedere accordi specifici.
• MiFID II (UE): per i servizi di market data operanti in UE, la MiFID II impone requisiti su trasparenza e qualità dei dati. Se costruisci un servizio che fornisce dati a enti finanziari UE, verifica la conformità con gli articoli 13-16 di MiFID II.

Nota pratica: ProxyHat fornisce infrastruttura proxy — la responsabilità di rispettare i ToS degli exchange e la legge locale resta sull'utente. Usa i proxy per ottimizzare il accesso consentito, non per evadere restrizioni legali.

Setup ProxyHat: configurazione completa

Per iniziare con ProxyHat per il crypto market data scraping, configura l'accesso nel dashboard e usa i parametri seguenti.

Connessione HTTP (default per REST API)

# Gateway: gate.proxyhat.com:8080
# Username con flag geo/session
http://user-country-SG:PASSWORD@gate.proxyhat.com:8080

Connessione SOCKS5 (overhead minore, utile per WebSocket)

# Gateway: gate.proxyhat.com:1080
socks5://user-country-SG:PASSWORD@gate.proxyhat.com:1080

Flag disponibili nel username

Flag	Esempio	Descrizione
country	user-country-DE	Geo-targeting per paese
city	user-country-DE-city-berlin	Geo-targeting a livello città
session	user-session-abc123	Sessione sticky (IP persistente)

Puoi combinare i flag: user-session-feed01-country-SG mantiene un IP singaporese stabile per la sessione feed01.

Per i dettagli su piani e pricing, visita la pagina pricing di ProxyHat. Per le location disponibili, consulta la pagina locations. Per approfondire lo scraping di dati web, vedi il caso d'uso web scraping e SERP tracking.

On-chain: esempio RPC senza proxy

Per completezza, ecco come ottenere dati on-chain senza proxy — usando un provider RPC diretto:

import requests
import json

# Alchemy RPC endpoint — no proxy needed
rpc_url = "https://eth-mainnet.g.alchemy.com/v2/YOUR_API_KEY"

# Get latest block number
payload = {
    "jsonrpc": "2.0",
    "method": "eth_blockNumber",
    "params": [],
    "id": 1
}

resp = requests.post(rpc_url, json=payload, timeout=10)
block_hex = resp.json()["result"]
block_num = int(block_hex, 16)
print(f"Latest block: {block_num}")

# Get logs from Uniswap V3 pool (filter by contract address)
payload = {
    "jsonrpc": "2.0",
    "method": "eth_getLogs",
    "params": [{
        "address": "0x88e6A0c2dDD26FEEb64F039a2c41296FcB3f5640",  # USDC/ETH 0.05% pool
        "fromBlock": hex(block_num - 1000),
        "toBlock": "latest"
    }],
    "id": 2
}

resp = requests.post(rpc_url, json=payload, timeout=30)
logs = resp.json()["result"]
print(f"Retrieved {len(logs)} log entries")

Come si vede, nessun proxy è necessario — l'autenticazione e il rate limiting sono gestiti dall'API key di Alchemy. Se avessi bisogno di più throughput, aggiungeresti un'altra API key o passeresti a un piano superiore, non proxy.

Key Takeaways

• Distingui on-chain da exchange data: i dati on-chain usano provider RPC e non richiedono proxy; i dati di exchange CEX richiedono proxy residenziali per gestire rate limit e geo-restriction.
• WebSocket-first, REST fallback: usa WebSocket per dati real-time (basso rate limit impact) e REST con proxy rotation per snapshot e storici.
• Geo-targeting per latenza: scegli proxy nella stessa regione dei server dell'exchange — SG/JP per Binance, US per Coinbase, HK/SG per OKX.
• Sessioni sticky per WebSocket, rotazione per-request per REST: non mischiare le modalità — il WebSocket ha bisogno di IP stabile, il REST beneficia della distribuzione.
• Leggi i rate limit header: adatta il throughput dinamicamente in base agli header restituiti dall'exchange invece di aspettare il 429.
• Rispetta ToS e legge locale: usa i proxy per ottimizzare l'accesso consentito, non per evadere restrizioni legali o geo-block che violano la legge.

Per iniziare a configurare i tuoi proxy per dati di mercato crypto, visita il dashboard ProxyHat o consulta la documentazione ufficiale.