Kripto para piyasa verileri için proxy kullanımı, nicel (quant) ekiplerin ve piyasa verisi servislerinin en kritik altyapı kararlarından biridir. Binance, Coinbase, OKX ve Bybit gibi merkezi borsalar (CEX) her gün milyarlarca işlem barındırırken, bu veriye erişim IP tabanlı hız sınırları ve coğrafi kısıtlamalarla giderek daha sıkı hale gelmektedir. Bu rehberde, on-chain veri (RPC düğümleri) ile borsa verisi (CEX API + web scraping) arasındaki farkı net bir şekilde çizecek ve her iki senaryo için pratik bir proxy mimarisi kuracağız.
Kripto Para Piyasa Verileri İçin Proxy: Ne Zaman ve Neden Gerekir?
Kripto veri toplama dünyasında iki temel veri kaynağı vardır ve her biri farklı bir proxy stratejisi gerektirir:
- On-chain (zincir üstü) veri: Ethereum, Solana, Bitcoin gibi blokzincirlerinden doğrudan RPC düğümleri veya Alchemy, Infura, QuickNode gibi indeksleyiciler (indexer) üzerinden alınır. Burada IP rotasyonu genellikle gerekmez; çünkü RPC sağlayıcıları API anahtarı bazlı kimlik doğrulama kullanır.
- Borsa verisi (CEX): Binance, Coinbase, OKX, Bybit gibi merkezi borsaların REST API'leri, WebSocket akışları ve web arayüzlerinden alınır. Burada IP tabanlı hız sınırları, coğrafi engeller ve anti-bot savunmaları proxy kullanımını zorunlu kılar.
Kripto piyasa verisi kazıma işleminde proxy'lerin temel rolü, borsa API'lerindeki IP başına hız sınırlarını aşmak ve coğrafi kısıtlamaları yönetmektir. Örneğin Binance, ABD IP adreslerini belirli endpoint'lerde engeller ve bu durum HTTP 451 (Legal Reasons) yanıtıyla sonuçlanır. Benzer şekilde, hız sınırı aşımları önce HTTP 429 (Too Many Requests) ile uyarır, ardından HTTP 403 veya IP ban ile sonuçlanabilir.
Hedef Veri Kaynakları ve Teknik Bağlam
CEX Veri Tipleri
Borsa API'lerinden tipik olarak toplanan veri türleri şunlardır:
| Veri Tipi | Tipik Endpoint | Güncelleme Sıklığı | Proxy İhtiyacı |
|---|---|---|---|
| Fiyat akışı (ticker) | /api/v3/ticker/24hr |
1-5 sn | Yüksek (rate limit) |
| Emir defteri (orderbook) | /api/v3/depth |
100ms-1sn | Orta-Yüksek |
| Funding rate | /fapi/v1/premiumIndex | d>1-8 saat
Düşük | |
| Likidasyonlar | WebSocket stream | Gerçek zamanlı | Orta (geo) |
| Mum (candlestick) verisi | /api/v3/klines |
1m-1d | Yüksek (bulk çekim) |
Binance'in resmi API dokümantasyonuna göre, REST API weight tabanlı bir hız sınırma sistemi kullanır: her endpoint farklı bir ağırlık (weight) tüketir ve IP başına dakikada 6.000 weight limiti uygulanır. Bu, tek bir IP'den dakikada yaklaşık 1.200 ticker isteği veya 600 orderbook snapshot'ı anlamına gelir. Daha yüksek hacimler için IP rotasyonu şarttır.
On-Chain Veri Tipleri
On-chain veri toplama sürecinde ise durum farklıdır. Ethereum JSON-RPC spesifikasyonuna göre, RPC düğümleri API anahtarı bazlı kimlik doğrulama ve rate limiting kullanır. Alchemy, Infura veya QuickNode gibi sağlayıcılar, günlük istek kotalarını API anahtarı başına hesaplar — IP başına değil. Bu nedenle on-chain veri toplama için proxy rotasyonu genellikle gerekmez.
Ancak iki istisna vardır:
- Self-hosted RPC düğümleri: Kendi Ethereum düğümünüzü çalıştırıyorsanız ve birden fazla servisten yükleniyorsanız, IP bazlı throttling uygulayabilirsiniz.
- Geo-based throughput: Bazı RPC sağlayıcıları, belirli bölgelerden gelen istekler için daha yüksek throughput sunar. Bu durumda bölgesel proxy'ler veri toplama hızını artırabilir.
Neden Residential Proxy'ler CEX Scraping İçin Kritiktir
Borsa API proxy'leri seçerken datacenter ve residential proxy'ler arasındaki farkı anlamak önemlidir. CEX'lerin anti-bot sistemleri, datacenter IP bloklarını (AWS, GCP, Azure) kolayca tespit edebilir ve daha agresif hız sınırları uygulayabilir. Residential proxy'ler ise gerçek ISP'lere ait IP adresleri sunduğu için, borsa sistemleri tarafından normal kullanıcı trafiği olarak değerlendirilir.
İşte kripto piyasa verisi kazıma sürecinde residential proxy'lerin kritik olduğu üç senaryo:
1. IP Tabanlı Hız Sınırları
Bybit'in API dokümantasyonu, REST endpoint'leri için saniyede 120 istek limiti belirtir. 50 sembolün orderbook verisini saniyede bir kez çekmek isteyen bir quant ekibi, tek IP ile bu limitin %42'sini tüketir. 100 sembol için ise limit aşılır ve 429 yanıtı alınır. Proxy rotasyonu ile bu yükü 3-4 IP arasında dağıtarak güvenli bir marj elde edebilirsiniz.
2. Coğrafi Kısıtlamalar
Binance, ABD merkezli IP'lerden spot ticaret API'lerine erişimi engeller. Coinbase Pro ise belirli ülkelerde API erişimini kısıtlar. Bu durum, ABD'de faaliyet gösteren bir veri servisi için kritik bir engeldir. Coğrafi hedefleme özellikli proxy'ler, veri toplama işlemini izin verilen bölgelerden gerçekleştirmenizi sağlar.
3. 429'dan 451'e Eskalasyon
Hız sınırı ihlalleri genellikle şu şekilde eskale olur: önce 429 (Too Many Requests) → ardından 403 (Forbidden) → son olarak 451 (Unavailable For Legal Reasons) veya kalıcı IP ban. Bu eskalasyon, özellikle datacenter IP'lerde daha hızlı gerçekleşir. Residential proxy'ler ise bu eskalasyon zincirini yavaşlatır çünkü her IP bağımsız bir "kullanıcı" olarak görünür.
Mimari: WebSocket Öncelikli, REST Yedekli
Kripto piyasa verisi için ideal mimari, gerçek zamanlı veriyi WebSocket üzerinden alıp, REST API'yi yedek ve bulk veri çekimi için kullanmaktır. İşte mimari bileşenler:
- WebSocket katmanı: Binance, OKX ve Bybit tüm genel WebSocket akışlarını (emir defteri güncellemeleri, ticker, likidasyon) açıkça sunar. WebSocket bağlantıları uzun ömürlüdür ve bağlantı başına sınırlı sembol sayısı izin verir (Binance'de bağlantı başına 200 stream).
- REST fallback katmanı: WebSocket kopmaları, geçmiş veri çekimi (klines) ve funding rate gibi düşük frekanslı veriler için REST API kullanılır. Burada proxy rotasyonu devreye girer.
- On-chain katmanı: RPC sağlayıcı üzerinden blok verisi, log filtreleri ve event subscription. Proxy genellikle gerekmez.
Kod Örneği 1: Binance REST API ile ProxyHat Kullanımı (curl)
# Binance ticker verisi - ABD IP'sinden erişim için Almanya proxy'si
curl -x "http://user-country-DE:pass@gate.proxyhat.com:8080" \
"https://api.binance.com/api/v3/ticker/24hr?symbol=BTCUSDT"
# Orderbook snapshot - Japonya proxy'si ile düşük gecikme
curl -x "http://user-country-JP:pass@gate.proxyhat.com:8080" \
"https://api.binance.com/api/v3/depth?symbol=BTCUSDT&limit=100"
# Sticky session ile aynı IP'den ardışık istekler
curl -x "http://user-session-binance01-country-DE:pass@gate.proxyhat.com:8080" \
"https://api.binance.com/api/v3/klines?symbol=BTCUSDT&interval=1m&limit=1000"Kod Örneği 2: Python ile Çoklu Borsa Veri Toplama ve Proxy Rotasyonu
import requests
import time
from itertools import cycle
# ProxyHat gateway - ülkeler arasında rotasyon
proxies = [
{"http": "http://user-country-DE:pass@gate.proxyhat.com:8080",
"https": "http://user-country-DE:pass@gate.proxyhat.com:8080"},
{"http": "http://user-country-JP:pass@gate.proxyhat.com:8080",
"https": "http://user-country-JP:pass@gate.proxyhat.com:8080"},
{"http": "http://user-country-SG:pass@gate.proxyhat.com:8080",
"https": "http://user-country-SG:pass@gate.proxyhat.com:8080"},
]
proxy_pool = cycle(proxies)
exchanges = {
"binance": "https://api.binance.com/api/v3/ticker/24hr?symbol=BTCUSDT",
"bybit": "https://api.bybit.com/v2/tickers?symbol=BTCUSD",
"okx": "https://www.okx.com/api/v5/market/ticker?instId=BTC-USDT",
}
for name, url in exchanges.items():
proxy = next(proxy_pool)
try:
resp = requests.get(url, proxies=proxy, timeout=10)
data = resp.json()
print(f"{name}: status={resp.status_code}, proxy={proxy['http'].split('@')[1]}")
time.sleep(0.5) # Rate limit buffer
except Exception as e:
print(f"{name}: error={e}")Kod Örneği 3: Node.js ile WebSocket + REST Fallback Mimarisi
const WebSocket = require('ws');
const axios = require('axios');
const HttpsProxyAgent = require('https-proxy-agent');
// ProxyHat SOCKS5 proxy (düşük gecikme için)
const proxyAgent = new HttpsProxyAgent(
'http://user-country-DE-session-ws01:pass@gate.proxyhat.com:8080'
);
// WebSocket: Binance emir defteri akışı
const ws = new WebSocket('wss://stream.binance.com:9443/ws/btcusdt@depth@100ms');
ws.on('message', (data) => {
const update = JSON.parse(data);
// Orderbook increment işle
console.log(`Bid: ${update.b?.[0]?.[0]}, Ask: ${update.a?.[0]?.[0]}`);
});
ws.on('error', (err) => {
console.error('WS error, REST fallback aktif:', err.message);
// REST fallback: proxy üzerinden orderbook snapshot
axios.get('https://api.binance.com/api/v3/depth', {
params: { symbol: 'BTCUSDT', limit: 100 },
httpsAgent: proxyAgent,
timeout: 5000
}).then(res => {
console.log('REST fallback orderbook:', res.data.bids[0], res.data.asks[0]);
}).catch(e => console.error('REST fallback hatası:', e.message));
});
ws.on('close', () => {
console.log('WebSocket kapandı, 5 sn sonra yeniden bağlanılacak...');
setTimeout(() => { /* reconnect logic */ }, 5000);
});Kod Örneği 4: On-Chain Veri (Proxy Gerekmez)
# On-chain veri: RPC sağlayıcı üzerinden - proxy kullanılmaz
curl -X POST "https://eth-mainnet.g.alchemy.com/v2/YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}'
# Block içeriği ve log filtreleme
import requests
ALCHEMY_URL = "https://eth-mainnet.g.alchemy.com/v2/YOUR_API_KEY"
payload = {
"jsonrpc": "2.0",
"method": "eth_getLogs",
"params": [{
"fromBlock": "0x12A5B6C",
"toBlock": "0x12A5B7C",
"address": "0x88e6A0c2dDD26FEEb64F039a2c41296FcB3f5640", # USDC/ETH pool
"topics": ["0x241ea03c7b8e58ac4f3c81b406e4f0c0d4d8a67e0c0c0c0c0c0c0c0c0c0c0c0c"]
}],
"id": 1
}
resp = requests.post(ALCHEMY_URL, json=payload, timeout=30)
logs = resp.json().get('result', [])
print(f"Toplam log: {len(logs)}")
# Not: On-chain veri için proxy rotasyonu gerekmez.
# RPC sağlayıcı API anahtarı bazlı rate limiting kullanır.Gecikme (Latency) Konuları
Kripto piyasa verisi kazıma işleminde gecikme, arbitraj ve ticaret sinyalleri için doğrudan kar/zarar etkiler. Proxy seçiminde gecikme optimizasyonu şu prensiplere dayanır:
Borsa-Region Eşleştirme
| Borsa | Sunucu Bölgesi | Önerilen Proxy Bölgesi | Tipik RTT |
|---|---|---|---|
| Binance | Asya (Tokyo, Singapur) | JP, SG, KR | 20-50ms |
| Coinbase | ABD (Virginia, Chicago) | US, CA | 10-40ms |
| OKX | Asya (Hong Kong, Singapur) | HK, SG, JP | 15-45ms |
| Bybit | Asya (Singapur) | SG, JP, KR | 20-50ms |
Önemli bir not: ProxyHat'in lokasyon sayfasında mevcut ülkeler kontrol edilmelidir. Coğrafi hedefleme, sadece erişim engellerini aşmakla kalmaz, aynı zamanda TCP round-trip süresini de optimize eder. 200ms'lik ek proxy gecikmesi, saniyeler içinde arbitraj fırsatlarını ortadan kaldırabilir.
WebSocket bağlantıları için sticky session kullanımı esastır. Her yeniden bağlantı, ~100-300ms ek gecikme ve orderbook senkronizasyon kaybı anlamına gelir. ProxyHat'in session flag'ı (user-session-xxx) ile aynı IP'de kalabilirsiniz.
Yaygın Hatalar ve Edge Case'ler
Hata 1: WebSocket'e Proxy Rotasyonu Uygulamak
WebSocket bağlantıları uzun ömürlüdür ve her bağlantı bir IP'ye sabittir. Per-request rotasyon WebSocket için anlamsızdır — bunun yerine sticky session kullanın ve bağlantı kopması durumunda yeni IP ile yeniden bağlanın.
Hata 2: Weight-Based Limitleri Göz Ardı Etmek
Binance'in weight sistemi, her endpoint için farklı ağırlık değerleri atar. /api/v3/depth?limit=1000 çağrısı 20 weight tüketirken, ?limit=100 sadece 1 weight tüketir. Weight hesabı yapmadan rotasyon stratejisi kurmak, gereksiz proxy kullanımına yol açar.
Hata 3: On-Chain Veri İçin Proxy Kullanmak
RPC sağlayıcıları API anahtarı bazlı çalışır. On-chain veri için proxy eklemek, sadece gecikmeyi artırır ve maliyeti yükseltir. İstisna: self-hosted node kullanıyorsanız ve IP bazlı throttling yapıyorsanız.
Hata 4: Tek Bölge Proxy Kullanmak
Tüm borsalar için aynı bölge proxy kullanmak, bazı borsalarda yüksek gecikmeye ve diğerlerinde coğrafi engellere yol açar. Borsa-bölge eşleştirme tablosunu referans alın.
ProxyHat Kurulumu ve Yapılandırması
ProxyHat ile kripto piyasa verisi kazıma altyapısını kurmak için şu adımları izleyin:
- Hesap oluşturun: ProxyHat fiyatlandırma sayfasından ihtiyacınıza uygun planı seçin. Residential proxy'ler CEX scraping için önerilir.
- Bölge seçimi: Hedef borsaların sunucu bölgelerine en yakın lokasyonları seçin. Binance için JP/SG, Coinbase için US/CA.
- Session yönetimi: WebSocket bağlantıları için sticky session, REST istekleri için per-request rotasyon kullanın.
- Monitoring: Başarı oranı (success rate), ortalama gecikme ve 429/451 oranını takip edin. %95 altındaki başarı oranları proxy stratejisini yeniden değerlendirmeniz gerektiğini gösterir.
Daha fazla teknik detay için ProxyHat dokümantasyonunu inceleyin. Web scraping kullanım senaryoları için web scraping rehberimize ve SERP takibi için SERP takip sayfamıza bakabilirsiniz.
Düzenleyici ve Hukuki Hususlar
Kripto piyasa verisi toplama sürecinde dikkat edilmesi gereken düzenleyici çerçeveler:
- Borsa ToS (Kullanım Şartları): Her borsanın API kullanım şartları farklıdır. Binance, ticari amaçlı veri yeniden dağıtımını kısıtlayabilir. Coinbase'in API şartları, veri ticari kullanım için ek lisans gerektirebilir. ToS'u mutlaka okuyun.
- Coğrafi kısıtlamalar ve yerel yasa: Binance'in ABD IP engellemesi, ABD menkul kıymet mevzuatına uyum kapsamındadır. Bu engeli aşmak, teknik olarak mümkün olsa da yerel yasaları ihlal edebilir. Yargı alanınıza danışın.
- Veri lisansı: Piyasa verisi yeniden dağıtımı için borsa lisans anlaşmaları gerekebilir. Örneğin, CME futures verisi için doğrudan lisans şarttır. Kripto borsaları da benzer kurallar uygulayabilir.
- GDPR/CCPA: Kişisel veri içermeyen piyasa verisi (fiyat, orderbook) için GDPR/CCPA doğrudan uygulaması sınırlıdır, ancak kullanıcı davranışı verisi topluyorsanız uyum gereklidir.
Önemli: Bu rehber teknik uygulama odaklıdır ve hukuki tavsiye içermez. Coğrafi kısıtlamaları aşmadan önce yargı alanınızdaki mevzuatı kontrol edin.
Key Takeaways — Önemli Çıkarımlar
- On-chain vs CEX: On-chain veri (RPC) için proxy genellikle gerekmez; CEX verisi için IP rotasyonu ve coğrafi hedefleme şarttır.
- WebSocket öncelikli: Gerçek zamanlı veri için WebSocket + sticky session, bulk ve fallback için REST + proxy rotasyonu kullanın.
- Bölge eşleştirme: Binance için JP/SG, Coinbase için US/CA proxy'leri gecikmeyi minimize eder.
- Weight-aware rotasyon: Binance'in weight sistemini hesaba katmadan rotasyon planlamak gereksiz maliyet yaratır.
- 429→451 eskalasyonu: Datacenter IP'lerde hızlı eskale olan bu zincir, residential proxy'lerle yavaşlatılır.
- ToS ve mevzuat: Borsa kullanım şartlarını ve yerel kripto mevzuatını ihlal etmeyin; teknik mümkünlik hukuki uygunluk anlamına gelmez.
SSS
Kripto para piyasa verileri için proxy nedir?
Kripto para piyasa verileri için proxy, merkezi borsaların (CEX) API'lerinden veri toplarken IP tabanlı hız sınırlarını yönetmek ve coğrafi kısıtlamaları aşmak için kullanılan bir ara sunucudur. Binance, Coinbase, OKX gibi borsalar IP başına istek limitleri uygular ve belirli bölgelerden erişimi engeller. Proxy'ler, istekleri farklı IP'lerden ve bölgelerden yönlendirerek bu engelleri yönetmenizi sağlar. On-chain veri (RPC düğümleri) için ise proxy genellikle gerekmez.
Kripto para piyasa verileri için proxy kullanıcıları için neden önemlidir?
Proxy kullanıcıları için bu önemlidir çünkü kripto piyasa verisi kazıma işlemi, IP tabanlı hız sınırları (429), coğrafi engeller (451) ve datacenter IP tespiti gibi çoklu engellerle karşılaşır. Tek bir IP'den yüksek hacimli veri çekmek, hızla IP ban'a yol açabilir. Residential proxy'ler, istekleri gerçek ISP IP'leri üzerinden dağıtarak bu engelleri minimize eder. Ayrıca, doğru bölge proxy'si seçmek gecikmeyi 20-50ms seviyelerinde optimize eder — bu da arbitraj ve ticaret sinyalleri için kritiktir.
Kripto para piyasa verileri için hangi proxy tipi en iyisidir?
CEX veri toplama için residential proxy'ler en iyi seçenektir. Datacenter IP'leri borsa anti-bot sistemleri tarafından kolayca tespit edilir ve daha agresif hız sınırlarına maruz kalır. Residential proxy'ler ise gerçek ISP'lere ait IP'ler sunduğu için normal kullanıcı trafiği olarak görünür. On-chain veri toplama için proxy genellikle gerekmez — RPC sağlayıcıları (Alchemy, Infura, QuickNode) API anahtarı bazlı rate limiting kullanır. Mobil proxy'ler ise yalnızca çok yüksek gizlilik gerektiren senaryolar için değerlendirilebilir, ancak maliyet/fayda oranı residential'a göre daha düşüktür.
Kripto para piyasa verileri için proxy kullanırken blokları nasıl önlersiniz?
Blokları önlemek için dört temel strateji uygulayın: (1) Weight-aware rotasyon — Binance'in weight sistemini hesaba katarak her IP'nin limit altında kalmasını sağlayın. (2) Bölge eşleştirme — her borsa için en yakın sunucu bölgesini seçin (Binance için JP/SG, Coinbase için US). (3) WebSocket için sticky session — uzun ömürlü bağlantılarda IP değiştirmekten kaçının. (4) Exponential backoff — 429 yanıtı aldığınızda isteği hemen farklı bir IP ile değil, birkaç saniye bekleyip sonra yeniden deneyin. Ayrıca, dakikada 1.200'den fazla ticker isteği tek IP'den göndermeyin.
Binance proxy kullanırken hangi bölgeyi seçmeliyim?
Binance'in ana sunucuları Asya bölgesinde (Tokyo ve Singapur) bulunur, bu nedenle Japonya (JP), Singapur (SG) veya Güney Kore (KR) proxy'leri en düşük gecikmeyi sağlar. Tipik round-trip süresi 20-50ms aralığındadır. ABD IP'leri Binance'in spot API'lerinde 451 yanıtı alacağı için kullanılmamalıdır. Avrupa proxy'leri (DE, FR) orta seviye gecikme (80-120ms) sunar ve coğrafi erişim engeli olmadan kullanılabilir. WebSocket bağlantıları için sticky session ile seçtiğiniz bölgede kalın.
