Kripto Para Piyasa Verileri İçin Proxy Kılavuzu: CEX Scraping ve On-Chain Veri

Kripto Piyasa Verileri İçin Neden Proxy Gerekli?

Kripto para piyasalarında piyasa verisi, algoritmik ticaret stratejilerinden risk yönetimine, DeFi analitiklerinden regülasyon uyum raporlamalarına kadar neredeyse her iş akışının temelini oluşturur. Ancak bu veriyi güvenilir ve kesintisiz toplamak — özellikle merkezi borsaların (CEX) API'leri üzerinden — önemli mühendislik zorlukları barındırır. Crypto market data scraping süreçlerinde karşılaştığınız başlıca engeller — IP tabanlı hız sınırları, coğrafi kısıtlamalar ve 429→451 hata kodu eskalasyonu — doğru proxy mimarisi ile aşılabilir.

Bu rehberde, kripto piyasa verilerini toplamanın iki temel yolunu — CEX API scraping ve on-chain veri toplama — net bir şekilde ayırarak, her birinde proxy'lerin rolünü, mimari tercihlerini, gecikme optimizasyonunu ve regülasyon hususlarını inceleyeceğiz.

CEX ve On-Chain Veri: İki Farklı Dünya

Kripto piyasa verilerini toplarken ilk karar, verinin kaynağıdır. Bu seçim, proxy ihtiyacını doğrudan belirler:

Bu ayrım kritiktir: On-chain veri, doğası gereği kamuya açık ve blok zinciri üzerinde kriptografik olarak doğrulanabilir olduğundan proxy ihtiyacı minimumdur. CEX verisi ise özel API'ler üzerinden dağıtılır ve borsa operatörünün kurallarına tabidir.

Hedef Veri Türleri

CEX scraping senaryolarında en çok talep edilen veri türleri:

• Fiyat akışları (Price Feeds): Binance, Coinbase, OKX, Bybit REST ve WebSocket endpoint'leri üzerinden gerçek zamanlı fiyat verisi.
• Emir defteri anlık görüntüleri (Orderbook Snapshots): Derinlik verisi, spread analizi ve likidite haritalaması için — genellikle REST ile alınır.
• Funding Rate'ler: Perpetual sözleşmelerde finansman oranları — genellikle 8 saatlik döngülerle güncellenir, arbitraj sinyali üretir.
• Likidasyon verileri: Açık pozisyonların zorunlu kapatma olayları, risk modelleri ve volatilite tahminleri için kritik.

On-chain tarafında ise RPC sağlayıcıları (Alchemy, Infura, QuickNode) veya indexer'lar (The Graph, Dune Analytics) aracılığıyla blok verisi, event log'ları ve token transferleri toplanır. Bu veri yolu için proxy genellikle gerekli değildir.

CEX API Scraping: Proxy Neden Kritik?

Merkezi borsalar, API'lerini korumak için katmanlı savunma mekanizmaları uygular. Bu mekanizmalar, proxy kullanmadan veri toplamayı giderek zorlaştırır.

1. IP Tabanlı Hız Sınırları (Rate Limiting)

Binance REST API, dakikada 1200 request weight sınırı uygular (Binance API dokümantasyonu); Coinbase public endpoint'lerde saniyede yaklaşık 10 istek limiti koyar. Bu sınırlar aşıldığında sunucu 429 Too Many Requests yanıtı döner. Tek bir IP ile yüksek frekansta veri toplamaya çalışan quant ekipleri, bu sınıra dakikalar içinde ulaşır.

Residential proxy döndürme ile her istek farklı bir IP'den geldiğinden, tek bir IP'nin rate limit havuzunu tüketmesi sorunu ortadan kalkar. Exchange API proxies kullanarak toplam istek hacminizi tek bir IP'nin sınırına bağlı kalmadan ölçekleyebilirsiniz.

2. Coğrafi Kısıtlamalar (Geo-Restrictions)

Binance, ABD IP adreslerinden erişimi engeller ve kullanıcıları Binance.US'a yönlendirir — bu platform çok daha sınırlı bir çift yelpazesi sunar. Benzer şekilde bazı borsalar belirli yargı bölgelerinden gelen trafiği 451 Unavailable For Legal Reasons koduyla reddeder. Bu, 429'dan çok daha ciddi bir durumdur: hız sınırı aşıldığında biraz beklersiniz, ancak 451 alırsanız o IP'den o endpoint'e erişim kalıcı olarak engellenir.

Residential proxy'ler, hedef borsa için uygun bir coğrafi konumdan bağlantı sağlayarak bu engeli aşmanıza olanak tanır. ProxyHat'ın desteklenen lokasyonları arasında 190+ ülke bulunur.

3. 429'dan 451'e Eskalasyon

Pratikte 429 hatalarını görmezden gelip retry storm yapmak, borsanın sizi daha agresif koruma katmanlarına taşımasına neden olur. Tekrar eden 429 ihlalleri, IP'nin geçici kara listeye alınmasına ve nihayetinde 451 yanıtına yol açabilir. Binance proxy stratejiniz sadece "farklı IP kullanmak" değil, akıllı rotasyon ve istek sıklığı yönetimi olmalıdır.

On-Chain Veri Toplama: RPC Sağlayıcıları Yeterli mi?

Blok zinciri verisi, doğası gereği merkeziyetsiz ve kamuya açıktır. Ethereum mainnet'ten blok verisi okumak için bir proxy'ye ihtiyacınız yoktur; bir RPC sağlayıcı yeterlidir:

• Alchemy: Ücretsiz katman saniyede 300 compute unit, gelişmiş NFT ve token API'leri.
• Infura: Ethereum, IPFS ve Layer 2 desteği; saniyede 100 istek (ücretsiz katman).
• QuickNode: Çoklu zincir desteği, düşük gecikmeli endpoint'ler, gelişmiş analitik eklentileri.

Ancak bazı durumlarda proxy kullanımı faydalı olabilir:

• Coğrafi gecikme optimizasyonu: RPC sağlayıcının endpoint'i uzak bir bölgedeyse, daha yakın bir proxy üzerinden yönlendirme gecikmeyi azaltabilir.
• İstek hacmi dağıtımı: Birden fazla RPC sağlayıcıya paralel istek atarak throughput artırılabilir; proxy rotasyonu her sağlayıcının rate limit'ini bağımsız kullanmanıza yardımcı olur.
• Yük devretme (Failover): Bir RPC sağlayıcı çöktüğünde, proxy katmanı istekleri otomatik olarak yedek sağlayıcıya yönlendirebilir.

Özetle: On-chain veri için proxy genellikle gerekli değildir, ancak yüksek hacimli veya gecikme duyarlı senaryolarda avantaj sağlayabilir.

Proxy Türleri: Kripto Veri Toplama İçin Karşılaştırma

CEX scraping için residential proxy en uygun dengedir: datacenter gibi tanınmaz, mobile gibi pahalı değildir. Gerçek zamanlı arbitraj gibi aşırı gecikme duyarlı işlemler için datacenter proxy denenebilir, ancak IP engellenme riskini artırdığını unutmayın.

Mimari: WebSocket Öncelikli, REST Yedekli

Gerçek zamanlı veri gerektiren quant stratejilerinde mimari seçimi kritiktir. İki temel yaklaşım:

WebSocket: Gerçek Zamanlı Akış

Binance, OKX, Bybit ve Coinbase public WebSocket endpoint'leri sunar. WebSocket bağlantıları REST'e kıyasla çok daha düşük gecikme ve daha az bant genişliği tüketimi sağlar. Ancak WS bağlantıları uzun ömürlüdür ve tek bir IP üzerinden sürdürülür — rate limiting sorunu yaratmaz, ancak geo-restriction riski taşır.

import asyncio
import websockets
import json

async def binance_ws_stream(symbols):
    """Binance WebSocket üzerinden gerçek zamanlı fiyat akışı."""
    stream_names = "/".join([f"{s.lower()}@ticker" for s in symbols])
    uri = f"wss://stream.binance.com:9443/ws/{stream_names}"

    async with websockets.connect(uri) as ws:
        while True:
            msg = await ws.recv()
            data = json.loads(msg)
            # Exchange timestamp ile veri bütünlüğü sağla
            print(f"{data['s']}: {data['c']} @ ts={data['E']}")

asyncio.run(binance_ws_stream(["BTCUSDT", "ETHUSDT"]))

REST: Anlık Görüntüler ve Proxy Rotasyonu

Emir defteri anlık görüntüleri, funding rate'ler ve likidasyon verileri genellikle REST endpoint'leri üzerinden alınır. Bu noktada proxy rotasyonu devreye girer:

import requests

# ProxyHat residential proxy — Singapur lokasyonu (Binance için düşük gecikme)
PROXY_URL = "http://user-country-SG:PASSWORD@gate.proxyhat.com:8080"

def fetch_binance_orderbook(symbol, limit=100):
    """Binance emir defteri anlık görüntüsü — ProxyHat üzerinden."""
    proxies = {"http": PROXY_URL, "https": PROXY_URL}
    url = "https://api.binance.com/api/v3/depth"
    params = {"symbol": symbol, "limit": limit}

    resp = requests.get(url, params=params, proxies=proxies, timeout=10)
    resp.raise_for_status()
    return resp.json()

orderbook = fetch_binance_orderbook("BTCUSDT")
print(f"Best bid: {orderbook['bids'][0][0]}, Best ask: {orderbook['asks'][0][0]}")

Çoklu Borsa Veri Toplama: Coğrafi Proxy Eşleştirmesi

Birden fazla borsadan aynı anda veri toplarken, her borsa için uygun coğrafi lokasyon seçimi gecikmeyi minimize eder. Aşağıdaki Node.js örneği, paralel veri toplama ve borsa-özel proxy atamasını gösterir:

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

// ProxyHat — borsa-özel coğrafi lokasyon eşleştirmesi
const EXCHANGE_PROXIES = {
  binance:  new HttpsProxyAgent('http://user-country-SG:PASSWORD@gate.proxyhat.com:8080'),
  okx:      new HttpsProxyAgent('http://user-country-HK:PASSWORD@gate.proxyhat.com:8080'),
  coinbase: new HttpsProxyAgent('http://user-country-US:PASSWORD@gate.proxyhat.com:8080'),
  bybit:    new HttpsProxyAgent('http://user-country-SG:PASSWORD@gate.proxyhat.com:8080'),
};

const EXCHANGE_ENDPOINTS = {
  binance:  (sym) => `https://api.binance.com/api/v3/ticker/price?symbol=${sym}`,
  okx:      (sym) => `https://www.okx.com/api/v5/market/ticker?instId=${sym}`,
  coinbase: (sym) => `https://api.exchange.coinbase.com/products/${sym}/ticker`,
  bybit:    (sym) => `https://api.bybit.com/v5/market/tickers?symbol=${sym}&category=spot`,
};

async function fetchTicker(exchange, symbol) {
  const url = EXCHANGE_ENDPOINTS[exchange](symbol);
  const resp = await axios.get(url, {
    httpsAgent: EXCHANGE_PROXIES[exchange],
    timeout: 10000,
  });
  return { exchange, data: resp.data, localTs: Date.now() };
}

// Paralel çoklu borsa veri toplama
const results = await Promise.all([
  fetchTicker('binance', 'BTCUSDT'),
  fetchTicker('okx', 'BTC-USDT'),
  fetchTicker('coinbase', 'BTC-USD'),
  fetchTicker('bybit', 'BTCUSDT'),
]);
console.log(results);

curl ile Hızlı Test

ProxyHat proxy'lerini doğrulamak için curl kullanabilirsiniz:

# Binance emir defteri — Singapur residential proxy
 curl -x http://user-country-SG:PASSWORD@gate.proxyhat.com:8080 \
   "https://api.binance.com/api/v3/depth?symbol=BTCUSDT&limit=5"

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

# OKX funding rate — Hong Kong SOCKS5 proxy
curl -x socks5://user-country-HK:PASSWORD@gate.proxyhat.com:1080 \
  "https://www.okx.com/api/v5/public/funding-rate?instId=BTC-USDT-SWAP"

Gecikme (Latency) Optimizasyonu

Algoritmik ticaret ve arbitraj stratejilerinde gecikme doğrudan PnL'yi etkiler. Proxy seçiminde gecikme faktörleri:

• Binance / OKX / Bybit: Sunucuları ağırlıklı olarak Singapur, Tokyo ve Hong Kong'da barındırılır. Güneydoğu Asya lokasyonlu residential proxy'ler, Avrupa veya ABD proxy'lerine kıyasla 50–150 ms daha düşük gecikme sağlar.
• Coinbase / Kraken: ABD merkezli altyapı. ABD veya Batı Avrupa lokasyonlu proxy'ler optimaldir.
• Veri bütünlüğü ve zaman damgaları: Gecikme sadece hız değil, veri sıralaması için de kritiktir. Yüksek gecikmeli bir proxy, fiyat güncellemelerinin sıra dışı gelmesine (out-of-order delivery) neden olabilir. Her zaman exchange-provided timestamp'leri kullanın, yerel saate güvenmeyin. Clock drift farklı borsalar arasında 100 ms'yi bulabilir.

Kural: Hedef borsanın sunucu lokasyonuna en yakın residential proxy çıkış noktasını seçin. ProxyHat'ın lokasyon sayfasından mevcut bölgeleri kontrol edebilirsiniz.

Veri Bütünlüğü: Zaman Damgaları ve Sıralama Garantileri

Finansal veri borçları (data obligations) bağlamında, veri bütünlüğü regülasyon gereksinimi olabilir. SEC ve MiFID II kapsamında, işlem verisinin zaman damgalarının doğruluğu ve sıralama garantisi zorunludur. CEX API'lerinden gelen veride:

• Zaman damgaları: Her borsa kendi sunucu saatini kullanır. Farklı borsaların saatleri arasında clock drift olabilir. Veriyi birleştirirken exchange-provided timestamp alanlarını kullanın.
• Sıralama garantisi: REST API'lerinden gelen yanıtların sırası, ağ gecikmesi nedeniyle garanti edilmez. WebSocket akışlarında sıralama daha güvenilirdir, ancak yine de exchange seviyesinde garanti edilip edilmediğini kontrol edin.
• Veri kaybı tespiti: WebSocket bağlantısında kopma olursa, yeniden bağlandığınızda kaç veri noktası kaçırdığınızı tespit etmek için sıra numaraları (sequence numbers) kullanın.

Yaygın Hatalar ve Uç Durumlar

• Datacenter proxy ile CEX scraping: Datacenter IP'leri borsalar tarafından kolayca tanınır ve rate limit'ler daha agresif uygulanır. Residential proxy'ler gerçek kullanıcı trafiğinden ayırt edilemez.
• Sticky session kullanmadan WebSocket: WebSocket bağlantıları uzun ömürlüdür; per-request rotasyon bağlantıyı koparır. WS için sticky session (user-session-SESSIONID), REST için per-request rotasyon kullanın.
• Retry storm: 429 hatası alındığında exponential backoff olmadan tekrar denemek, IP'nin kara listeye alınmasını hızlandırır. Her zaman backoff stratejisi uygulayın.
• Zaman damgası doğrulaması atlamak: Farklı borsalardan gelen veriyi birleştirirken clock drift'i dikkate alın. Exchange-provided timestamp'leri kullanın, yerel saate güvenmeyin.
• Tek proxy lokasyonu ile tüm borsalar: Singapur lokasyonlu bir proxy, Coinbase için suboptimal gecikme üretir. Her borsa için ayrı coğrafi lokasyon kullanın.
• WebSocket reconnect sırasında veri kaybını görmezden gelmek: Yeniden bağlantı sonrası kaçırdığınız aralığı REST ile geri doldurun (backfill).

ProxyHat ile Kripto Veri Toplama Kurulumu

ProxyHat, esnek fiyatlandırma seçenekleriyle residential, mobil ve datacenter proxy hizmetleri sunar. Kripto piyasa verisi toplama için residential proxy'ler en uygun seçimdir.

1. ProxyHat Hesabı ve Kimlik Bilgileri

ProxyHat dashboard üzerinden hesap oluşturun ve kimlik bilgilerinizi alın. Detaylı konfigürasyon için ProxyHat dokümantasyonunu inceleyin.

2. Coğrafi Hedefleme ile Proxy URL Oluşturma

Borsa-özel lokasyon seçimi, kullanıcı adı parametreleriyle yapılır:

• Ülke bazlı: user-country-SG:PASSWORD@gate.proxyhat.com:8080
• Şehir bazlı: user-country-US-city-newyork:PASSWORD@gate.proxyhat.com:8080
• Sticky session: user-country-SG-session-wsbtc01:PASSWORD@gate.proxyhat.com:8080

3. Session (Sticky) vs Per-Request Rotasyon

• Per-request rotasyon: Varsayılan davranış; her istek yeni IP alır. REST endpoint'leri için ideal.
• Sticky session: user-session-SESSIONID parametresiyle belirli bir IP'ye sabitlenir. WebSocket bağlantıları için gereklidir — aksi halde bağlantı her IP değişiminde kopar.

WebSocket için örnek konfigürasyon: http://user-country-SG-session-wsbtc01:PASSWORD@gate.proxyhat.com:8080

4. İzleme ve Sağlık Kontrolü

ProxyHat üzerinden yapılan isteklerin başarı oranını izleyin. Başarı oranı %95'in altına düştüğünde: (a) hedef lokasyonu değiştirmeyi, (b) residential'dan mobile proxy'ye geçişi, (c) istek sıklığını düşürmeyi değerlendirin. Web scraping kullanım senaryosu sayfamızda izleme en iyi uygulamalarını bulabilirsiniz.

Regülasyon ve Etik Hususlar

Kripto piyasa verisi toplarken regülasyon çerçevesini bilmek, hem teknik hem de hukuki açıdan zorunludur:

• Borsa Kullanım Koşulları (ToS): Birçok borsa, API'lerini "kişisel, ticari olmayan amaçlarla" sınırlar. Ticari veri ürünleri için borsanın veri lisans anlaşmasını inceleyin.
• Pazar verisi lisansları: SEC ve MiFID II kapsamında, borsa verisinin yeniden dağıtımı (redistribution) genellikle özel lisans gerektirir. Veriyi dahili kullanım için toplamak ile üçüncü tarafa satmak arasındaki farkı netleştirin.
• Coğrafi kısıtlamalar ve yerel yasa: Bir borsanın geo-restriction'ını proxy ile aşmak, borsanın ToS'unu ihlal edebilir. Ancak bu, yerel yasanızı da ihlal ediyorsa (örneğin ABD'de Binance.com'a erişim yasağı), hukuki danışmanlık alın.
• GDPR / CCPA: Topladığınız veri kişisel veri içeriyorsa, ilgili gizlilik mevzuatına uyum sağlamanız gerekir. Kamuya açık fiyat ve emir defteri verisi genellikle bu kapsama girmez.
• On-chain veri: Kamu blok zinciri verisi, veri koruma regülasyonları açısından farklı değerlendirilebilir. Ancak transaction hash ve adres gibi sahte anonim veriler, GDPR kapsamında kişisel veri sayılabilir — özellikle off-chain kimlik ile eşleştirilebiliyorsa.

Proxy kullanmak, teknik bir çözümdür — hukuki bir kalkan değildir. Her zaman yerel düzenlemelere ve borsa kullanım koşullarına uygun hareket edin. Gerekirse hukuki danışmanlık alın.

Temel Çıkarımlar

• CEX vs On-Chain ayrımı yapın: CEX API scraping proxy gerektirir; on-chain veri için RPC sağlayıcıları genellikle yeterlidir.
• Residential proxy tercih edin: Datacenter IP'leri borsalar tarafından tanınır; residential IP'ler gerçek kullanıcı trafiğinden ayırt edilemez.
• Coğrafi lokasyonu borsaya göre seçin: Binance/OKX/Bybit için SEA, Coinbase/Kraken için ABD/EU lokasyonları gecikmeyi minimize eder.
• WebSocket için sticky, REST için rotasyon: Uzun ömürlü bağlantılarda session sabitleyin; anlık isteklerde IP döndürün.
• 429→451 eskalasyonundan kaçının: Exponential backoff uygulayın, agresif retry yapmayın.
• Veri bütünlüğünü sağlayın: Exchange-provided timestamp'leri kullanın, clock drift'i hesaba katın, WebSocket kopmalarında backfill yapın.
• Regülasyonu ihmal etmeyin: ToS, pazar verisi lisansları ve yerel yasa düzenlemelerini inceleyin; gerekirse hukuki danışmanlık alın.