Kripto Piyasası Verileri için Proxyler: CEX ve On-Chain Veri Toplama Rehberi

Kripto piyasası verileri için proxyler, nicel (quant) ekiplerin ve veri servislerinin en kritik altyapı bileşenlerinden biridir. Ancak çoğu ekip, on-chain veri ile merkeziyetsiz borsa (CEX) verisini aynı proxy stratejisiyle toplamaya çalışır — bu hem maliyet israfı hem de gereksiz engellenmelere yol açar. Bu rehberde, kripto piyasası verileri için proxyler konusunu iki ayrı veri kaynağı üzerinden ele alacağız: CEX API'leri ve web scraping (proxy kritik) ile on-chain RPC/indexer verileri (proxy genelde gereksiz).

Kripto Piyasası Verileri için Proxyler: Ne Zaman ve Neden Gerekir?

Kripto veri toplama, temelde iki farklı dünyaya ayrılır:

• CEX verisi: Binance, Coinbase, OKX, Bybit gibi merkezi borsaların REST ve WebSocket API'lerinden fiyat, orderbook, funding rate, likidasyon verisi. Burada IP bazlı rate limitler ve geo-restriction'lar proxy kullanımını zorunlu kılar.
• On-chain veri: Ethereum, Solana, Arbitrum gibi blokzincirlerinden doğrudan RPC node'ları veya Alchemy, Infura, QuickNode gibi indexer servisleri aracılığıyla blok, transaction, log verisi. Burada proxy genellikle gerekmez.

Yanlış proxy stratejisi, 429 (Too Many Requests) hatalarının 451 (Unavailable For Legal Reasons) hatalarına dönüşmesine, WebSocket bağlantılarının kesilmesine ve veri bütünlüğünün bozulmasına neden olur. Aşağıda her iki dünya için doğru mimariyi adım adım inceleyeceğiz.

Hedef Veri Kaynakları ve Teknik Bağlam

CEX Price Feeds ve Public API'ler

Binance, Coinbase, OKX ve Bybit gibi borsalar public REST ve WebSocket endpoint'leri sunar. Örneğin Binance'in /api/v3/ticker/24hr endpoint'i tüm semboller için 24 saatlik istatistikleri döner. Ancak bu endpoint'ler IP bazlı rate limit uygular — Binance, weight-based bir sistem kullanır ve IP başına dakikada 1200 weight limiti vardır (Binance API dokümantasyonu). Tek bir /api/v3/ticker/24hr çağrısı tüm semboller için ~80 weight tüketir, yani dakikada ~15 çağrı yapabilirsiniz.

WebSocket ise gerçek zamanlı veri için tercih edilir. Binance'in wss://stream.binance.com:9443 endpoint'i üzerinden tek bağlantıda birden fazla stream aboneliği yapılabilir. Ancak WebSocket bağlantıları da IP bazlı bağlantı limitlerine tabidir — Binance, bağlantı başına 1024 stream limiti ve IP başına 300 bağlantı limiti uygular.

Orderbook Snapshots ve Depth Verisi

Orderbook verisi, quant stratejileri için en kritik veri türlerinden biridir. Binance /api/v3/depth endpoint'i ile snapshot alınabilir, ancak gerçek zamanlı takip için WebSocket depth20@100ms stream'leri kullanılır. Orderbook verisi yüksek frekansta güncellendiği için, hem bağlantı stabilitesi hem de veri sıralama garantisi (sequence number) kritiktir.

Funding Rates ve Likidasyonlar

Futures piyasası için funding rate ve likidasyon verisi, arbitraj ve risk yönetimi stratejilerinin temelidir. Binance Futures /fapi/v1/premiumIndex ve /fapi/v1/allForceOrders endpoint'leri bu veriyi sağlar. Bybit ve OKX de benzer endpoint'ler sunar. Bu endpoint'lerin rate limit'leri spot endpoint'lerinden farklı olabilir — dikkatli weight hesabı gerekir.

On-Chain Veri: RPC ve Indexer Servisleri

On-chain veri için doğrudan RPC node'larına bağlanmak en yaygın yaklaşımdır. Ethereum mainnet için Alchemy, Infura, QuickNode gibi servisler managed RPC endpoint'leri sağlar. Bu servislerin kendi rate limit ve authentication mekanizmaları vardır ve proxy kullanımı genellikle gerekmez.

Bununla birlikte, kendi node'unuzu çalıştırıyorsanız veya birden fazla RPC sağlayıcısını paralel kullanıyorsanız, geo-distribüted proxy'ler throughput artışı sağlayabilir. Örneğin, ABD'deki bir node'a Avrupa'dan bağlanmak ~80-120ms ek latency eklerken, aynı bölgedeki bir proxy üzerinden gitmek bu gecikmeyi azaltabilir.

Crypto Market Data Scraping için Neden Residential Proxy'ler Kritiktir

Crypto market data scraping yapan ekiplerin en sık karşılaştığı sorun, IP bazlı rate limit'ler ve geo-restriction'lardır. İşte tipik senaryolar:

IP Bazlı Rate Limit'ler

Borsalar, public API'lerini IP bazlı sınırlar. Tek bir IP'den gelen istekler belirli bir eşiği aştığında, önce 429 (Too Many Requests) hatası döner. Bu durum devam ederse, bazı borsalar IP'yi geçici olarak banlar veya 451 (Unavailable For Legal Reasons) hatası dönmeye başlar. Binance özellikle agresif rate limit enforcement uygulayan borsalardan biridir.

Datacenter IP'leri (örneğin AWS, GCP IP blokları) genellikle daha sıkı rate limit'lere tabi tutulur, çünkü borsalar bu IP'leri bot trafiği olarak işaretler. Residential proxy'ler, gerçek ISP IP'leri olduğu için daha az şüphe çeker ve daha yüksek rate limit'ler elde edebilir.

Geo-Restriction'lar

Binance, ABD IP'lerinden gelen erişimi engeller ve kullanıcıları Binance.US'a yönlendirir. Benzer şekilde, bazı borsalar belirli ülkelerdeki IP'leri tamamen bloke eder. Eğer Avrupa veya Asya merkezli bir veri toplama ekibindeyseniz ve ABD borsalarından (örneğin Coinbase) veri toplamanız gerekiyorsa, doğru geo-targeted proxy kullanımı zorunludur.

Binance'in geo-restriction politikaları hakkında detaylı bilgi Binance yasal sayfasında bulunabilir. Bu kısıtlamalar, REST API'leri kadar WebSocket bağlantılarını da etkiler.

429'dan 451'ye Eskalasyon

Rate limit ihlalleri zamanla eskale olur. Tipik senaryo:

1. İlk aşamada 429 hatası ve Retry-After header'ı döner.
2. İhlal devam ederse, IP geçici olarak banlanır (genellikle 2-24 saat).
3. Bazı borsalar, tekrarlayan ihlallerde IP'yi kalıcı olarak bloke eder ve 451 hatası döner.

Bu eskalasyonu önlemek için, residential proxy rotasyonu ve doğru retry stratejisi şarttır.

On-Chain Veri Yaklaşımı: RPC Sağlayıcıları Yeterli

On-chain veri toplamada proxy kullanımı genellikle gereksizdir. Alchemy, Infura, QuickNode gibi servisler, API key bazlı authentication kullanır ve IP bazlı kısıtlama uygulamaz. Bu servislerin kendi tier-based rate limit'leri vardır ve limit artışı için daha yüksek tier'a geçmeniz yeterlidir.

Ancak iki senaryoda proxy faydalı olabilir:

• Self-hosted node: Kendi node'unuzu çalıştırıyorsanız ve birden fazla bölgeden erişmeniz gerekiyorsa, geo-targeted proxy latency'yi azaltabilir.
• Çoklu RPC sağlayıcı: Birden fazla RPC sağlayıcısını paralel kullanıyorsanız, her sağlayıcıya farklı bir bölgeden erişmek throughput'u artırabilir.

Genel kural: on-chain veri için proxy yerine, doğru RPC sağlayıcı tier'ı seçmek daha maliyet etkindir.

Mimari: WebSocket-First, REST Fallback ile Proxy Rotasyonu

Gerçek zamanlı kripto verisi için doğru mimari, WebSocket-First yaklaşımıdır. Borsaların public WebSocket endpoint'leri, REST API'lere göre çok daha verimlidir — tek bağlantıda onlarca stream aboneliği yapılabilir ve push-based veri akışı sağlanır.

Ancak WebSocket bağlantıları da IP bazlı limitlere tabi olduğundan, yüksek sayıda sembol veya borsa izliyorsanız, birden fazla proxy IP'si üzerinden paralel WebSocket bağlantıları kurmanız gerekir.

Önerilen Mimari

• Katman 1 — WebSocket: Her borsa için, sticky session proxy üzerinden WebSocket bağlantısı. Her bağlantı ~100-200 stream aboneliği yapar.
• Katman 2 — REST fallback: WebSocket bağlantısı koptuğunda veya geçmiş veri gerektiğinde, rotating residential proxy üzerinden REST çağrıları.
• Katman 3 — On-chain: RPC sağlayıcı üzerinden doğrudan erişim, proxy gerekmez.

Python ile Binance WebSocket + Proxy Örneği

Aşağıdaki örnek, ProxyHat residential proxy üzerinden Binance WebSocket bağlantısı kurar:

import asyncio
import websockets
import json

# ProxyHat residential proxy (SOCKS5 for WebSocket support)
PROXY_URL = "socks5://user-country-DE:pass@gate.proxyhat.com:1080"

# Binance WebSocket endpoint
WS_URL = "wss://stream.binance.com:9443/stream"

async def listen_orderbook():
    # Subscribe to BTCUSDT and ETHUSDT depth streams
    streams = "btcusdt@depth20@100ms/ethusdt@depth20@100ms"
    url = f"{WS_URL}?streams={streams}"
    
    # websockets library supports SOCKS5 via proxy parameter
    async with websockets.connect(
        url,
        proxy=PROXY_URL,
        ping_interval=20,
        ping_timeout=10
    ) as ws:
        while True:
            msg = await ws.recv()
            data = json.loads(msg)
            stream = data.get("stream", "")
            payload = data.get("data", {})
            print(f"[{stream}] bids: {len(payload.get('bids', []))}, asks: {len(payload.get('asks', []))}")

asyncio.run(listen_orderbook())

Bu örnekte user-country-DE flag'i ile Almanya IP'si kullanılır. Binance, Avrupa IP'lerinden gelen erişime izin verir ve Almanya lokasyonu Frankfurt veri merkezlerine yakın olduğu için düşük latency sağlar.

REST Fallback ile Rotasyon

WebSocket bağlantısı koptuğunda veya geçmiş veri gerektiğinde, rotating residential proxy ile REST çağrıları yapılır:

import requests
from requests.auth import HTTPProxyAuth

# ProxyHat rotating residential proxy
PROXY = "http://gate.proxyhat.com:8080"
AUTH = HTTPProxyAuth("user-country-DE", "pass")

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

def fetch_funding_rate(symbol="BTCUSDT"):
    url = "https://fapi.binance.com/fapi/v1/premiumIndex"
    params = {"symbol": symbol}
    
    resp = requests.get(
        url,
        params=params,
        proxies=proxies,
        auth=AUTH,
        timeout=10
    )
    
    if resp.status_code == 429:
        # Rate limited — rotate to a new IP automatically
        # ProxyHat rotating proxy assigns a new IP per request
        print("Rate limited, retrying with new IP...")
        return None
    
    if resp.status_code == 451:
        print("Geo-blocked — check proxy country setting")
        return None
    
    data = resp.json()
    return {
        "symbol": data["symbol"],
        "funding_rate": float(data["lastFundingRate"]),
        "mark_price": float(data["markPrice"])
    }

result = fetch_funding_rate("BTCUSDT")
print(result)

ProxyHat'in rotating residential proxy'si, her istekte yeni bir IP atar. Bu, tek bir IP'nin rate limit'e takılmasını önler. Ancak exchange API proxies kullanırken, her borsa için doğru ülke seçimi kritiktir — aşağıda latency bölümünde bunu detaylandıracağız.

Node.js ile Çoklu Borsa Veri Toplama

const axios = require('axios');
const HttpsProxyAgent = require('https-proxy-agent');

// ProxyHat proxy — different country per exchange
const proxies = {
  binance: new HttpsProxyAgent('http://user-country-DE:pass@gate.proxyhat.com:8080'),
  coinbase: new HttpsProxyAgent('http://user-country-US:pass@gate.proxyhat.com:8080'),
  bybit: new HttpsProxyAgent('http://user-country-SG:pass@gate.proxyhat.com:8080')
};

async function fetchTicker(exchange, symbol) {
  const urls = {
    binance: `https://api.binance.com/api/v3/ticker/price?symbol=${symbol}`,
    coinbase: `https://api.exchange.coinbase.com/products/${symbol}/ticker`,
    bybit: `https://api.bybit.com/v5/market/tickers?category=spot&symbol=${symbol}`
  };
  
  try {
    const resp = await axios.get(urls[exchange], {
      httpsAgent: proxies[exchange],
      timeout: 8000
    });
    return { exchange, data: resp.data };
  } catch (err) {
    if (err.response?.status === 429) console.error(`${exchange}: rate limited`);
    if (err.response?.status === 451) console.error(`${exchange}: geo-blocked`);
    return null;
  }
}

// Fetch BTC price from all three exchanges
Promise.all([
  fetchTicker('binance', 'BTCUSDT'),
  fetchTicker('coinbase', 'BTC-USD'),
  fetchTicker('bybit', 'BTCUSDT')
]).then(results => console.log(results));

Latency Optimizasyonu: Doğru Bölge Seçimi

Kripto veri toplamada latency, veri kalitesini doğrudan etkiler. Orderbook verisinde 50ms'lik gecikme, arbitraj fırsatlarını kaçırmaya neden olabilir. Doğru proxy bölgesi seçimi, exchange sunucularına yakın lokasyonlardan bağlanmayı sağlar.

Borsa-Lokasyon Eşleştirme

Borsa	Ana Sunucu Bölgesi	Önerilen Proxy Ülkesi	Beklenen Latency
Binance	Global (AWS Tokyo/Frankfurt/Virginia)	DE, JP, SG	20-80ms
Coinbase	ABD (AWS us-east-1)	US	10-40ms
OKX	Asya (AWS Hong Kong/Singapore)	SG, HK, JP	15-60ms
Bybit	Asya (AWS Singapore)	SG, JP	10-50ms

ProxyHat ile ülke bazlı targeting user-country-XX flag'i ile yapılır. Örneğin:

• user-country-US — Coinbase için ABD IP'si
• user-country-DE — Binance Avrupa endpoint'i için Almanya IP'si
• user-country-SG — Bybit ve OKX için Singapur IP'si

Şehir bazlı targeting de mümkündür: user-country-DE-city-frankfurt gibi. Bu, AWS Frankfurt bölgesine en yakın IP'yi seçmenizi sağlar.

Sticky Session vs Rotasyon

WebSocket bağlantıları için sticky session zorunludur — bağlantı süresince aynı IP'de kalmanız gerekir. Aksi halde IP değiştiğinde bağlantı kopar ve veri boşluğu oluşur.

# Sticky session — same IP for 30 minutes
socks5://user-country-DE-session-myws01:pass@gate.proxyhat.com:1080

REST fallback için ise rotasyon tercih edilir — her istekte yeni IP, rate limit dağılımı için. ProxyHat'in rotating proxy'si varsayılan olarak her istekte yeni IP atar.

Düzenleyici ve Hukuki Hususlar

Kripto veri toplama, düzenleyici açıdan hassas bir alandır. Şu hususlara dikkat edin:

Borsa TOS ve Veri Lisansları

Her borsa, API kullanım şartlarını kendi TOS'unda (Terms of Service) tanımlar. Bazı borsalar, ticari veri yeniden satışını veya redistriübüyü kısıtlar. Örneğin, borsanın tick verisini üçüncü taraflara satmak, çoğu borsanın TOS'una aykırıdır. Kişisel kullanım veya iç analiz için API kullanımı genellikle izinlidir, ancak veri lisanslama gerekebilir.

ABD merkezli borsalar için SEC ve CFTC düzenlemeleri, piyasa verisi lisanslama konusunda katı kurallar uygular. MiFID II kapsamında ise AB'de ticari amaçla piyasa verisi toplama ve dağıtma, belirli kayıt ve raporlama yükümlülükleri doğurabilir.

Geo-Restriction ve Yerel Hukuk

Binance'in ABD IP'lerini engellemesi, ABD düzenleyici gerekliliklerinden kaynaklanır. Proxy kullanarak bu engeli aşmak, teknik olarak mümkün olsa da, ABD vatandaşı veya ABD merkezli bir kurum iseniz, bu durum yerel hukuka (CFTC, FinCEN) aykırı olabilir. Avrupa veya Asya merkezli ekipler için ise, kendi yargı bölgesindeki kripto düzenlemelerine uyum sağlamak gerekir.

Önemli: Bu rehber teknik implementasyon için yazılmıştır. Geo-restriction aşmanın sizin yargı bölgenizde yasal olup olmadığını bir hukuk danışmanına doğrulayın. ProxyHat, yasa dışı amaçlarla kullanımı desteklemez.

Veri Bütünlüğü ve Timestamp Garantileri

Finansal veri toplamada veri bütünlüğü kritiktir. Şu pratikleri uygulayın:

• Timestamp kaydı: Her veri noktası için exchange timestamp ve lokal alım timestamp'ını ayrı ayrı kaydedin. Bu, latency ölçümü ve veri kalitesi kontrolü için şarttır.
• Sequence number kontrolü: Binance WebSocket depth stream'leri sequence number içerir. Eksik sequence, veri boşluğu anlamına gelir — REST ile gap fill yapın.
• Idempotent yazım: Veritabanına yazımda, aynı timestamp ve sembol için tekrarlayan yazımları idempotent şekilde ele alın (upsert).

Yaygın Hatalar ve Edge Case'ler

1. Datacenter Proxy ile CEX Scraping

Datacenter IP'leri (AWS, GCP, Azure), borsalar tarafından bot trafiği olarak işaretlenir. Residential proxy yerine datacenter proxy kullanmak, 3-5x daha sık rate limit'e takılmanıza neden olur. Maliyet tasarrufu sanırken, daha fazla retry ve daha düşük başarı oranı ile daha pahalı hale gelir.

2. WebSocket için Rotating Proxy

WebSocket bağlantısında rotating proxy kullanmak, her IP değişiminde bağlantının kopmasına neden olur. WebSocket için her zaman sticky session kullanın. Rotasyon sadece REST fallback için uygundur.

3. Yanlış Ülke Seçimi

Coinbase verisini Almanya proxy'si üzerinden toplamak, 100-150ms ek latency ekler. Her borsa için ana sunucu bölgesine en yakın proxy ülkesini seçin. Yukarıdaki tabloyu referans alın.

4. Retry-After Header'ını Görmezden Gelmek

429 hatası döndüğünde, Retry-After header'ı size ne kadar beklemeniz gerektiğini söyler. Bu değeri görmezden gelip hemen retry yapmak, IP ban'a giden yolu hızlandırır. Exponential backoff ile birlikte Retry-After değerine saygı gösterin.

ProxyHat Kurulumu ve İç Kaynaklar

ProxyHat ile kripto veri toplama altyapısını kurmak için şu adımları izleyin:

1. Hesap oluşturun: ProxyHat fiyatlandırma sayfasından residential proxy paketinizi seçin.
2. Lokasyon seçin: ProxyHat lokasyon sayfasından hedef borsalarınıza en yakın ülkeleri belirleyin.
3. Bağlantıyı yapılandırın: Yukarıdaki kod örneklerindeki gate.proxyhat.com:8080 (HTTP) veya gate.proxyhat.com:1080 (SOCKS5) gateway'ini kullanın.
4. Web scraping use case'ini inceleyin: web scraping use case sayfamızda genel scraping mimarisi ve best practice'leri bulun.
5. SERP tracking ile karşılaştırın: SERP tracking use case sayfamız, benzer rate limit ve rotasyon stratejilerini farklı bir veri türü için gösterir.
6. Dokümantasyon: Detaylı API ve konfigürasyon bilgisi için ProxyHat dokümantasyonunu inceleyin.

Key Takeaways

• On-chain vs CEX ayrımı: On-chain veri için RPC sağlayıcı (Alchemy, Infura) yeterli — proxy genellikle gereksiz. CEX verisi için residential proxy kritik.
• WebSocket-first mimari: Gerçek zamanlı veri için WebSocket + sticky session proxy; REST fallback için rotating proxy.
• Geo-targeting: Her borsa için ana sunucu bölgesine en yakın proxy ülkesini seçin (Coinbase→US, Bybit→SG, Binance→DE/JP).
• Residential > Datacenter: CEX scraping'de datacenter IP'leri 3-5x daha sık rate limit'e takılır.
• 429→451 eskalasyonu: Rate limit ihlalleri zamanla IP ban'a dönüşür. Retry-After header'ına saygı gösterin ve exponential backoff kullanın.
• Düzenleyici uyum: Borsa TOS'larını okuyun, geo-restriction aşmanın yerel hukuka uygunluğunu doğrulayın.

SSS