Kripto para piyasa verileri için proxy çözümleri, günümüzün kantitatif finans ekipleri, DeFi analitik platformları ve piyasa verisi sağlayıcıları için vazgeçilmez bir altyapı bileşenine dönüştü. Binance, Coinbase, OKX ve Bybit gibi merkezi borsalar (CEX), public API endpoint'lerinde agresif IP tabanlı hız sınırlamaları uygular; coğrafi kısıtlamalar ise ABD tabanlı IP'lerden gelen trafiği tamamen engelleyebilir. Bu rehber, kripto para piyasa verileri için proxy mimarisini sıfırdan tasarlamayı, on-chain ve off-chain veri toplama arasındaki farkları netleştirmeyi ve ProxyHat ile üretim düzeyinde bir veri hattı kurmayı amaçlıyor.
Kripto Piyasa Verilerinde Veri Türleri ve Kaynaklar
Kripto ekosisteminde piyasa verisi iki temel kategoriye ayrılır: on-chain (zincir üstü) ve off-chain / CEX verisi. Her birinin toplama yöntemi, proxy ihtiyacı ve mimari yaklaşımı tamamen farklıdır.
CEX Verisi: Fiyat Akışları, Orderbook, Funding Rate
Merkezi borsaların sunduğu veri zenginliği, kantitatif stratejilerin temelini oluşturur:
- Spot ve türev fiyat akışları — Binance, OKX, Bybit üzerinden gerçek zamanlı tick verisi.
- Orderbook snapshot'ları — Derinlik analizi, spread hesaplamaları ve likidite profili çıkarma.
- Funding rate verileri — Perpetual kontratlardaki finansman oranları, arbitraj sinyallerinin kaynağı.
- Likidasyon verileri — Zorunlu kapatma olayları, volatilite analizi için kritik.
Bu veriler genellikle REST API ve WebSocket endpoint'leri üzerinden sunulur. Binance, public REST endpoint'lerinde IP başına 1200 istek/dakika sınırı uygular; bu sınır aşıldığında 429 Too Many Requests yanıtı döner ve tekrarlayan ihlaller 451 Unavailable For Legal Reasons veya kalıcı IP ban'ına dönüşebilir. Binance API belgeleri, bu sınırların detaylarını ve aşıldığında uygulanan yaptırımları açıkça belirtir.
On-Chain Veri: RPC Node'ları ve İndeksleyiciler
Blockchain verisi için Alchemy, Infura ve QuickNode gibi RPC sağlayıcıları, JSON-RPC üzerinden doğrudan erişim sunar. On-chain veri toplama, CEX scraping'den farklı olarak proxy gereksinimini azaltır; çünkü RPC sağlayıcıları API anahtarı tabanlı kimlik doğrulama kullanır ve IP tabanlı coğrafi engelleme uygulamaz. Ancak, yüksek hacimli indeksleme işlemlerinde birden fazla RPC endpoint'ine dağıtık istek göndermek için proxy rotasyonu throughput artırabilir.
CEX Scraping'de Neden Residential Proxy Kritik?
Merkezi borsalar, API abuse ve regulatory compliance gerekçesiyle agresif IP yönetimi uygular. Bu durum, kripto piyasa verisi scraping yapan ekipleri doğrudan etkiler:
- IP tabanlı hız sınırlamaları — Tek IP'den gelen aşırı istek, 429 yanıt koduyla reddedilir. MDN Web Docs, 429 kodunun Retry-After header'ı ile birlikte sunucu tarafında koruyucu bir mekanizma olarak çalıştığını açıklar.
- Coğrafi kısıtlamalar — Binance, ABD IP'lerinden gelen erişimi engeller; Coinbase belirli yargı alanlarında sınırlı API erişimi sağlar. Bu kısıtlamaları aşmak için hedef bölgeye ait residential IP'ler gereklidir.
- 429'dan 451'e eskalasyon — Tekrarlayan rate limit ihlalleri, geçici bloklardan kalıcı IP banlarına ve hatta yasal erişim reddine (HTTP 451) dönüşebilir.
Datacenter IP'leri, borsaların blok listelerında yüksek olasılıkla yer alır. Residential proxy'ler ise gerçek ISP atamalarından geldiği için CEX'lerin fraud detection sistemlerinden geçer. Mobil proxy'ler ise özellikle sosyal sinyal ve sentiment analizi yapan ekipler için değerlidir; çünkü mobil IP'ler en düşük şüphe skoruna sahiptir.
On-Chain Veri Toplama: Proxy Gerekli mi?
Kısa cevap: Genellikle hayır, ancak istisnalar var.
RPC sağlayıcıları (Alchemy, Infura, QuickNode), API anahtarı tabanlı erişim sunar ve IP engelleme uygulamaz. On-chain veri toplamanın doğru yaklaşımı:
- Düşük-orta hacim — Tek bir RPC sağlayıcısı yeterlidir; proxy gerekmez.
- Yüksek hacimli indeksleme — Birden fazla RPC endpoint'ine dağıtık istek göndermek için proxy rotasyonu, throughput'u 3-5 kat artırabilir.
- Coğrafi dağıtım — Belirli bölgelere yakın RPC node'ları, latency'yi düşürür. ProxyHat'ın lokasyon seçenekleri, bu senaryo için uygundur.
Mimari: WebSocket Öncelikli, REST Fallback ile Proxy Rotasyonu
Gerçek zamanlı kripto verisi için en verimli mimari WebSocket-first yaklaşımdır. Borsaların public WebSocket endpoint'leri, sürekli veri akışı sağlar ve REST'e kıyasla çok daha az istek hacmi oluşturur.
Mimari Diyagram
Üretim düzeyinde bir veri hattı şu katmanlardan oluşur:
- Veri Kaynağı Katmanı — CEX WebSocket + REST API, On-chain RPC
- Proxy Katmanı — Residential/datacenter proxy rotasyonu (ProxyHat)
- İşlem Katmanı — Normalizasyon, zaman damgası senkronizasyonu, sıralama garantisi
- Depolama Katmanı — Time-series DB (TimescaleDB, QuestDB) veya object storage
WebSocket Bağlantısı ile Proxy
WebSocket bağlantıları uzun ömürlüdür ve IP rotasyonu bağlantıyı koparır. Bu nedenle WebSocket için sticky session proxy kullanılır; REST fallback istekleri ise per-request rotasyon ile yapılır.
import asyncio
import websockets
import json
# ProxyHat sticky session ile WebSocket bağlantısı
PROXY = "http://user-session-ws1-country-US:PASSWORD@gate.proxyhat.com:8080"
async def binance_ws_orderbook(symbol: str = "btcusdt"):
url = f"wss://stream.binance.com:9443/ws/{symbol}@depth20@100ms"
# websockets kütüphanesi HTTP proxy destekler
async with websockets.connect(
url,
proxy=PROXY,
ping_interval=20
) as ws:
while True:
data = json.loads(await ws.recv())
# Zaman damgası ekle — veri bütünlüğü için kritik
data["received_ts"] = asyncio.get_event_loop().time()
print(f"Bid: {data['bids'][0][0]}, Ask: {data['asks'][0][0]}")
asyncio.run(binance_ws_orderbook())REST Fallback ile Per-Request Rotasyon
WebSocket kesintilerinde veya historical veri çekme işlemlerinde REST API kullanılır. Her istekte farklı IP ile gitmek, rate limit riskini minimize eder.
import requests
from itertools import cycle
# ProxyHat per-request rotasyon — country parametresi ile hedef bölge
PROXY_POOL = [
"http://user-country-US:PASSWORD@gate.proxyhat.com:8080",
"http://user-country-DE:PASSWORD@gate.proxyhat.com:8080",
"http://user-country-SG:PASSWORD@gate.proxyhat.com:8080",
]
proxy_cycle = cycle(PROXY_POOL)
def fetch_binance_orderbook(symbol: str = "BTCUSDT", limit: int = 20):
url = f"https://api.binance.com/api/v3/depth"
params = {"symbol": symbol, "limit": limit}
proxy = next(proxy_cycle)
resp = requests.get(
url,
params=params,
proxies={"http": proxy, "https": proxy},
timeout=10
)
if resp.status_code == 429:
# Rate limit — farklı proxy ile retry
retry_after = int(resp.headers.get("Retry-After", 5))
print(f"Rate limited. Retry after {retry_after}s")
return None
return resp.json()
# 100 sembol için sıralı çekim
for sym in ["BTCUSDT", "ETHUSDT", "SOLUSDT"]:
data = fetch_binance_orderbook(sym)
if data:
print(f"{sym}: {len(data.get('bids', []))} bids fetched")Latans Hususları: Bölgeye Özgü Proxy Seçimi
Kripto veri hattında latans, doğrudan arbitraj karlılığını etkiler. Yanlış bölgedeki bir proxy, 50-200ms ek gecikme yaratabilir; bu da HFT veya cross-exchange arbitraj stratejilerinde kabul edilemez.
| Borsa | Sunucu Bölgesi | Önerilen Proxy Lokasyonu | Beklenen Latans |
|---|---|---|---|
| Binance | Singapur / Tokyo | Güneydoğu Asya (SG, JP) | 10-30ms |
| Coinbase | ABD (Virginia) | ABD Doğu (US-VA) | 5-15ms |
| OKX | Singapur / Hong Kong | SEA (SG, HK) | 10-25ms |
| Bybit | Singapore | Singapur | 5-20ms |
ProxyHat'ın geniş lokasyon ağı, her borsa için bölgeye özgü proxy seçimini mümkün kılar. ABD borsaları için ABD Doğu lokasyonları, Asya borsaları için Singapur ve Japonya lokasyonları tercih edilmelidir.
curl ile Bölgesel Proxy Testi
# ABD lokasyonlu residential proxy ile Coinbase API testi
curl -x "http://user-country-US:PASSWORD@gate.proxyhat.com:8080" \
-w "\nLatans: %{time_total}s\n" \
"https://api.exchange.coinbase.com/products/BTC-USD/ticker"
# Singapur lokasyonlu proxy ile Binance API testi
curl -x "http://user-country-SG:PASSWORD@gate.proxyhat.com:8080" \
-w "\nLatans: %{time_total}s\n" \
"https://api.binance.com/api/v3/ticker/price?symbol=BTCUSDT"Veri Bütünlüğü: Zaman Damgaları ve Sıralama Garantisi
Finansal veri hatlarında veri bütünlüğü, proxy seçiminden daha kritik bir konudur. Her veri noktasında şu zaman damgaları tutulmalıdır:
- exchange_ts — Borsanın ilettiği zaman damgası
- received_ts — Verinin proxy'den geçip uygulamanıza ulaştığı an
- processed_ts — Verinin işlenip depolandığı an
Bu üç damga arasındaki fark, veri hattınızın gecikme profilini ortaya koyar. exchange_ts ile received_ts arasındaki fark, proxy ve ağ latansını temsil eder; bu değerin 100ms altında kalması, arbitraj stratejileri için kritik eşiktir.
Sıralama garantisi için WebSocket akışlarında sequence number takibi şarttır. Binance, her depth update mesajında finalUpdateId gönderir; bu değerler arasında boşluk varsa veri hattınızda kayıp olaylar var demektir.
Yaygın Hatalar ve Edge Case'ler
1. Datacenter IP ile CEX Scraping Yapmak
Veri merkezi IP'leri, borsaların欺诈 algılama sistemlerinde yüksek risk olarak işaretlenir. AWS, GCP ve Azure IP blokları, Binance ve OKX tarafından önceden tanınır ve hızlıca 429 veya 403 yanıtı alır. Residential proxy kullanımı bu sorunu kökten çözer.
2. WebSocket Bağlantısında Yanlış Rotasyon
WebSocket bağlantılarında per-request rotasyon uygulamak, bağlantıyı her istekte koparır. Doğru yaklaşım, her WS bağlantısı için sticky session kullanmaktır. ProxyHat'ın session flag'i bunu sağlar:
// Node.js — ws kütüphanesi ile sticky session proxy
const WebSocket = require('ws');
const HttpsProxyAgent = require('https-proxy-agent');
// ProxyHat sticky session — aynı IP'de kalır
const agent = new HttpsProxyAgent(
'http://user-session-orderbook1-country-SG:PASSWORD@gate.proxyhat.com:8080'
);
const ws = new WebSocket(
'wss://stream.binance.com:9443/ws/btcusdt@depth20@100ms',
{ agent }
);
ws.on('message', (data) => {
const parsed = JSON.parse(data);
console.log(`Bid: ${parsed.bids?.[0]?.[0]}`);
});
ws.on('error', (err) => {
console.error('WS Hatası:', err.message);
// Reconnect with new sticky session
});3. Zaman Damgası Senkronizasyonunu İhmalkâr Yaklaşımlar
Farklı borsalardan gelen verileri birleştirirken zaman damgalarının senkronize olmaması, yanlış cross-exchange sinyaller üretir. NTP senkronizasyonu ve borsa sunucu saati ile yerel saat arasındaki offset'in düzenli olarak ölçülmesi gerekir.
4. Geo-Restriction Atlatırken Yerel Yasayı İhlal Etmek
Binance'in ABD IP'lerini engellemesi, SEC düzenlemelerine uyum sağlamak amacıyladır. ABD'den bir VPN veya proxy ile Binance'e erişmek, hem borsanın Kullanım Koşulları'nı ihlal eder hem de yerel menkul kıymetler yasalarına aykırı olabilir. Bu rehber, yalnızca teknik mimariyi açıklar; yasadışı faaliyeti teşvik etmez.
ProxyHat ile Kripto Veri Hattı Kurulumu
ProxyHat, kripto piyasa verisi toplama için optimize edilmiş residential, datacenter ve mobil proxy çözümleri sunar. Kurulum adımları:
- Hesap oluşturma — ProxyHat fiyatlandırma sayfası üzerinden uygun planı seçin.
- Kimlik bilgileri — Dashboard'dan kullanıcı adı ve şifrenizi alın.
- Bölgesel yönlendirme — Hedef borsanın sunucu bölgesine en yakın lokasyonu seçin.
- Oturum yönetimi — WebSocket için sticky session, REST için per-request rotasyon yapılandırın.
Detaylı API belgeleri için ProxyHat Dokümantasyonu'na başvurun. Web scraping ve SERP takibi için use case sayfalarımızı da inceleyin: Web Scraping ve SERP Tracking.
Regülasyon ve Etik Hususlar
Kripto piyasa verisi toplama, regülasyon açısından hassas bir alandır:
- Exchange ToS — Her borsanın API kullanım koşulları farklıdır. Binance, veri çekme hızını sınırlarken, Coinbase Pro API daha esnek limitler sunar. Kullandığınız her borsanın ToS'unu okuyun.
- Menkul kıymetler yasaları — ABD'de SEC, AB'de MiFID II çerçevesinde piyasa verisi lisanslama yükümlülükleri vardır. Borsalardan gelen veriyi ticari amaçla yeniden dağıtmak, market data license gerektirebilir.
- GDPR ve CCPA — Kişisel veri işlemiyorsanız (sadece anonim piyasa verisi), bu regülasyonlar doğrudan uygulamaz; ancak kullanıcı verisi içeren endpoint'ler (örneğin trading history) bu kapsamda değerlendirilmelidir.
- robots.txt ve rate limit — Her borsanın API rate limit kurallarına uyum, uzun vadeli erişimin garantisiidir.
Temel Çıkarımlar
Özet:
- On-chain veri için proxy genellikle gerekmez; RPC sağlayıcıları yeterlidir. Yüksek hacimli indeksleme durumunda proxy rotasyonu throughput artırabilir.
- CEX scraping için residential proxy şarttır; datacenter IP'leri hızlıca engellenir.
- WebSocket-first mimari, REST fallback ile desteklenmeli; WS için sticky session, REST için per-request rotasyon kullanılmalıdır.
- Latansı minimize etmek için borsa sunucu bölgesine en yakın proxy lokasyonunu seçin.
- Her veri noktasında exchange_ts, received_ts ve processed_ts zaman damgalarını tutun; sıralama garantisi için sequence number takibi yapın.
- Coğrafi kısıtlamaları aşarken yerel yasalara ve borsanın ToS'una uyum sağlayın.
