Web Scraping için Rotating Proxy

Scraping projelerinde proxy kararı çoğu zaman yanlış uçtan başlar. Ekip önce bütçeye ya da tanıdık bir ürün adına bakar, hedefin bu seçime nasıl tepki verdiğini ise canlıda öğrenir. Oysa web scraping için rotating proxy seçerken asıl girdi hedef sitenin kendisidir. Aynı projede bir hedef datacenter adreslerinden gelen isteklere hiç tepki vermezken bir başkası aynı trafiği ilk dakikalarda yavaşlatabilir; biri her sayfayı bağımsız sunarken diğeri sayfalar arasında oturum bekler. Tek bir ürünü bütün hedeflere zorlamak ya gereksiz maliyet ya da gereksiz hata üretir.

Bu rehber bu yüzden ürünlerden değil, hedefin dört özelliğinden yola çıkar. Ağ toleransı: hedef datacenter, konut ve mobil adreslere farklı davranıyor mu? Durum ihtiyacı: bir sayfa önceki yanıttan kalan çerez, belirteç veya imleç olmadan açılıyor mu? Adres ailesi: hedef IPv6 üzerinden aynı içeriği veriyor mu? Coğrafi duyarlılık: içerik ziyaretçinin ülkesine göre değişiyor mu? Bu dört soru yanıtlandığında ürün, rotasyon modu, eşzamanlılık tavanı ve bütçe büyük ölçüde kendiliğinden belirlenir.

RotatingProxy kataloğunda beş rotating ürün bulunur: IPv4 Datacenter, IPv4 Residential, Mobile, IPv6 Datacenter ve IPv6 Residential. İlk üçü GB bazlı ve süre sınırı olmayan paketlerle, son ikisi port bazlı aylık paketlerle satılır; beşi de HTTP, HTTPS ve SOCKS5 protokollerini destekler. Sonraki bölümler önce hedefi tanımayı, ardından ürünü, rotasyonu, hızı, hata politikasını ve maliyeti sırasıyla ele alır. En sonda hukuki çerçeve, sık görülen sorunlar ve canlı öncesi bir gözden geçirme listesi yer alır.

Keşif birkaç saatlik bir iştir ve ürün seçimindeki tahmini ölçüme çevirir. Amaç hedefi yormak değil, nasıl çalıştığını küçük bir örnekle anlamaktır. Aşağıdaki adımları her hedef için ayrı uygulayın ve sonuçları basit bir tabloda tutun; sonraki bölümlerdeki bütün kararlar bu tabloya dayanır.

1. Kuralları okuyun. robots.txt dosyasını ve kullanım koşullarını inceleyin, sitenin resmi bir API ya da veri dışa aktarma seçeneği sunup sunmadığına bakın. Resmi bir kanal varsa çoğu zaman scraping’den daha ucuz, daha kararlı ve hukuken daha temizdir.
2. Sayfa türlerini listeleyin: liste, detay, arama sonucu, sayfalandırılmış kategori gibi. Her tür için gerçekten ihtiyaç duyduğunuz alanları yazın. İhtiyaç dışı alanları toplamamak hem trafiği hem de hukuki riski azaltır.
3. Durum ihtiyacını belirleyin. Bir detay sayfası doğrudan adresiyle açılabiliyorsa durumsuzdur. İkinci sayfaya geçmek için önceki yanıttaki bir imleç, çerez veya form belirteci gerekiyorsa o akış durumludur ve oturum bazlı rotasyon ister.
4. Adres ailesini kontrol edin. Alan adının DNS kayıtlarında AAAA kaydı var mı? Varsa IPv6 üzerinden gelen yanıt IPv4 yanıtıyla aynı içeriği veriyor mu? Kaydın varlığı tek başına yetmez; içerik eşitliğini birkaç farklı sayfada karşılaştırın.
5. Coğrafi farkı ölçün. Aynı sayfayı iki farklı ülkeden açtığınızda dil, para birimi, stok ya da içerik değişiyor mu? Değişiyorsa ülke, verinin bir parçasıdır ve rotasyon her istekte ülke değiştirmemelidir.
6. Ağ toleransını küçük bir örneklemle deneyin. Birkaç düzine isteği önce datacenter, sonra residential çıkışla ve düşük hızda gönderin. Durum kodlarını, yanıt boyutlarını ve beklenen alanların gelip gelmediğini kaydedin; 200 kodu dönüp içi boş olan ya da doğrulama sayfası gösteren yanıtları ayrıca sayın.

Altıncı adımın amacı hedefin sınırını zorlamak değil, ilk izlenimi almaktır. Datacenter çıkışla beklenen alanlar eksiksiz geliyorsa en ekonomik seçenekle başlayabilirsiniz. Yanıtlar ağ türüne göre belirgin biçimde ayrışıyorsa bu farkı not edin; ürün kararı tam olarak bu farka dayanır. Birkaç düzine isteklik bir keşif için katalogdaki “Karşılama 1+1” etiketli 2 GB’lık giriş paketleri yeterlidir: IPv4 Datacenter’da 1 dolar, IPv4 Residential’da 2,5 dolar, Mobile’da 4 dolardır. Bunlar kampanya paketleridir; koşullarını sipariş adımında kontrol edin.

Keşif tablosunu bir kez doldurup unutmayın. Siteler altyapılarını, koruma katmanlarını ve sayfa yapılarını zaman içinde değiştirir. Uzun soluklu projelerde her hedef için birkaç ayda bir ya da hata oranında belirgin bir sıçrama gördüğünüzde keşfi tekrarlamak, ürün ve hız kararlarını güncel tutar.

Keşif tablosu hazırsa hedefleri tiplere ayırabilirsiniz. Aşağıdaki eşleştirme bir başlangıç noktasıdır ve her hedefin gerçek davranışı pilotta doğrulanmalıdır. Geçiş sinyali sütunu, ilk seçimin ne zaman gözden geçirilmesi gerektiğini gösterir.

IPv4 Datacenter katalogda istek başına veya oturum bazlı rotasyonla tanımlanır ve paketleri 2 GB’tan 1.000 GB’a kadar uzanır. Hedef datacenter trafiğine tepki vermiyorsa en düşük birim maliyet bu üründedir; bu yüzden her hedefte ilk deneme olarak kalmalı ve yalnız ölçülmüş bir sorun varsa bırakılmalıdır. “Residential daha garanti olur” düşüncesiyle hedefleri baştan pahalı ürüne taşımak, 100 GB kademesinde aynı veriyi iki katı maliyetle toplamak anlamına gelir.

IPv4 Residential ve Mobile, sticky ve rotating oturum seçenekleriyle gelir. Residential, coğrafi doğruluk ve hassas hedefler için asıl çalışma atıdır. Mobile ise scraping’de nadiren ilk tercihtir: LTE/5G taşıyıcı adresleri ancak hedef içeriği gerçekten mobil ağa göre değiştiriyorsa ek değer üretir. 100 GB kademesinde Mobile 225 dolar, Residential 120 dolar, Datacenter 60 dolardır; mobil farkı ölçmeden mobil ürüne geçmek bütçeyi hızla eritir.

IPv6 Datacenter ve IPv6 Residential oturum yapılandırmalı rotasyonla çalışır ve port bazlı aylık faturalanır. Lokasyon listeleri IPv4 ürünlerin 180’i aşan ülke kapsamından dardır: IPv6 Datacenter için Almanya, ABD, Hollanda, Birleşik Krallık, Türkiye, Fransa, Kanada ve Polonya; IPv6 Residential için bunlara ek olarak Avusturya listelenir. Hedefiniz bu ülkelerden birinden erişim gerektiriyorsa ve IPv6 üzerinden aynı içeriği veriyorsa port modeli sürekli işlerde güçlü bir seçenektir; aksi hâlde IPv4 ürünlerde kalın.

Rotasyon modunu ürün değil iş birimi belirler. İş birimi, hedefin gözünde tutarlı görünmesi gereken en küçük istek grubudur. Doğrudan açılan bir detay sayfası tek istekten oluşan bir iş birimidir. Bir arama sorgusunun ilk beş sonuç sayfası ise tek bir iş birimidir, çünkü üçüncü sayfanın isteği ikinci sayfadan gelen bir imlece ya da çereze dayanır. Kural basittir: iş birimi içinde çıkış adresi sabit kalmalı, iş birimleri arasında değişebilir.

HTTPS hedeflerde proxy yalnız CONNECT tünelini görür; bu yüzden istek başına rotasyon pratikte bağlantı başına çalışır ve istemci tüneli yeniden kullandıkça çıkış adresi değişmez. İstek başına rotasyon durumsuz işlerin varsayılanıdır. Yük havuza en geniş biçimde dağılır, tek bir adres hedefte iz biriktirmez ve bir isteğin başarısız olması diğerlerini etkilemez. Oturum bazlı rotasyon ise durumlu akışlar içindir: oturum boyunca aynı çıkış adresi kullanılır, akış bittiğinde ya da bir hata oturumu bozduğunda yeni oturum açılır. Bir oturumun ne kadar süre aynı adreste kalabileceği ve oturum kimliğinin bağlantıya nasıl iletildiği ürüne göre değişebilir; bunları panelde ve ürün dokümanında kontrol edin, varsayımla kod yazmayın.

Oturum bazlı rotasyonda en sık yapılan hata oturumu gereğinden uzun tutmaktır. Oturum, iş birimiyle birlikte doğmalı ve onunla birlikte kapanmalıdır. Beş sayfalık bir sayfalandırmayı bitiren işçi, bir sonraki aramaya aynı oturumla devam ederse yükü yine tek adrese yığar ve istek başına rotasyonun sağladığı dağılımı kaybeder. Tersi de sorundur: bir akışın ortasında hata alan işçi yalnız o isteği değil bütün iş birimini baştan, yeni bir oturumla tekrarlamalıdır; yarım kalmış bir akışa farklı bir adresten devam etmek çoğu zaman tutarsız veri üretir.

Rotating proxy hakkındaki en yaygın yanlış okuma şudur: her istek başka bir adresten gidiyorsa hedefe istediğim kadar hızlı gidebilirim. Hedefin kapasitesi, sunucu yükü ve hız sınırları çıkış adreslerinizin sayısıyla artmaz. Pek çok site hız sınırını yalnız IP adresine göre değil; oturuma, çereze, istek örüntüsüne ve toplam yüke göre uygular. Bu yüzden eşzamanlılık iki ayrı tavanla yönetilir: hedef başına tavan ve toplam tavan.

Hedef başına tavan, tek bir alan adına aynı anda açık olabilecek istek sayısıdır ve hedefin kaldırabileceği yükü temsil eder. Küçük ve orta ölçekli sitelerde bu sayıyı tek haneli tutmak, yanıt süreleri uzadığında ise düşürmek iyi bir başlangıçtır. Toplam tavan ise sizin altyapınızın, bant genişliğinizin ve proxy paketinizin sınırıdır. Port bazlı IPv6 ürünlerde katalog, port sayısının eşzamanlı oturum kapasitenizi belirlediğini söyler; bir portun kaç eşzamanlı bağlantı taşıdığını panelde kontrol edin ve toplam tavanı bu değerin altında tutun. GB bazlı IPv4 ürünlerde de varsa eşzamanlı bağlantı koşulunu sipariş adımında ya da panelde doğrulayın.

Kaç işçiye ihtiyacınız olduğunu kabaca bulmak için hedeflediğiniz istek hızını ortalama yanıt süresiyle çarpın. Örneğin bir hedeften saniyede 2 sayfa almak istiyor ve yanıtların ortalama 1,5 saniye sürdüğünü ölçtüyseniz (ikisi de varsayım) yaklaşık 3 eşzamanlı isteğe ihtiyacınız vardır. Yanıt süresi yükle birlikte uzuyorsa bu bir uyarıdır: işçi eklemek hızı artırmaz, yalnız hedefin üzerindeki baskıyı artırır.

Güvenli bir hız bulmanın en pratik yolu kademeli artıştır. Hedef başına tek eşzamanlı istekle başlayın, birkaç dakika boyunca durum kodlarını ve yanıt sürelerini izleyin, sorun yoksa tavanı bir artırın. 429, 503 veya yanıt süresinde belirgin bir yükselme gördüğünüz ilk kademede durun ve bir önceki kademeye dönün. Bulduğunuz değer o hedefin çalışma tavanıdır. Bunu yapılandırmada hedefe özel saklayın, çünkü bir hedef için güvenli olan hız başka bir hedefi rahatsız edebilir. Mümkünse taramaları hedefin yoğun saatleri dışına planlayın; aynı veri, sitenin sakin olduğu saatlerde hem daha az hata hem de daha az yeniden deneme ile toplanır.

Rotating proxy ile yeniden deneme yazmak kolaydır ve bu kolaylık tehlikelidir. Her hatada yeni adresle tekrar dene diyen bir döngü, geçici bir sorunu çözerken kalıcı bir sorunu büyütür. Hedefin açıkça reddettiği bir isteği farklı adreslerden tekrar tekrar göndermek hem kotayı yakar hem de bütün trafiğinizi hedefin gözünde şüpheli hâle getirir. Doğru politika önce yanıtı sınıflandırır, sonra o sınıfa uygun tek bir davranış seçer.

Bekleme süresi için üstel geri çekilmeyi rastgelelikle birlikte kullanın: her denemede üst sınırı ikiye katlayın ve gerçek bekleme süresini sıfır ile bu üst sınır arasında rastgele seçin. Rastgelelik, aynı anda başarısız olan çok sayıda işçinin aynı anda tekrar denemesini, yani hedefe dalga hâlinde yüklenmesini önler. Retry-After başlığı varsa hesapladığınız değerden önce gelir; hedef ne kadar beklemenizi istiyorsa o kadar bekleyin.

İki sınır daha ekleyin. Birincisi yeniden deneme bütçesidir: toplam isteklerin belirli bir oranından fazlası yeniden deneme olamaz. Bu oran aşıldığında sorun tek tek isteklerde değil, hızda ya da hedefin tutumundadır ve daha fazla deneme yalnız GB harcar. İkincisi hedef başına devre kesicidir: kısa sürede art arda hata alan hedef bir süre tamamen durdurulur, bekleme bitince tek bir istekle yeniden yoklanır; o istek de başarısız olursa devre yeniden açılır. Aşağıdaki Node.js iskeleti bu kuralları bir araya getirir. Node’un yerleşik fetch işlevi tek başına proxy ayarı almaz; bu örnekte fetch ve ProxyAgent birlikte undici paketinden içe aktarılır, bu yüzden paketi projenize eklemeniz gerekir. İstek başına rotasyon gerekiyorsa bağlantı yeniden kullanımını kapatın ya da iş birimi başına yeni bir ProxyAgent oluşturun, çünkü ProxyAgent aynı hedef için açtığı tüneli yeniden kullanabilir.

import { fetch, ProxyAgent } from 'undici'

const agent = new ProxyAgent('http://KULLANICI:ŞİFRE@GATEWAY:PORT')
const RETRYABLE = new Set([429, 500, 502, 503, 504])
const MAX_ATTEMPTS = 4
const BASE_MS = 1000
const CAP_MS = 60000
const RETRY_BUDGET = 0.1          // varsayım: isteklerin en fazla yüzde 10u tekrar
const BREAK_AFTER = 5             // devreyi açan art arda hata sayısı
const COOLDOWN_MS = 10 * 60000    // devrenin açık kalma süresi

const stats = { requests: 0, retries: 0, bytes: 0 }
const breakers = new Map()        // host -> { fails, openUntil }
const sleep = (ms) => new Promise((r) => setTimeout(r, ms))

function backoff(attempt, retryAfter) {
  const seconds = Number(retryAfter)
  if (retryAfter && Number.isFinite(seconds)) return seconds * 1000
  const ceiling = Math.min(CAP_MS, BASE_MS * 2 ** attempt)
  return Math.random() * ceiling  // tam rastgele bekleme
}

function breakerFor(host) {
  if (!breakers.has(host)) breakers.set(host, { fails: 0, openUntil: 0 })
  return breakers.get(host)
}

export async function getPage(url, mustContain) {
  const b = breakerFor(new URL(url).host)
  if (Date.now() < b.openUntil) return { url, outcome: 'devre-acik' }

  for (let attempt = 0; attempt < MAX_ATTEMPTS; attempt++) {
    if (attempt > 0) {
      const overBudget = stats.requests >= 100 &&
        stats.retries >= stats.requests * RETRY_BUDGET
      if (overBudget) return { url, outcome: 'butce-asildi' }
      stats.retries++
    }
    stats.requests++

    let res
    try {
      res = await fetch(url, {
        dispatcher: agent,
        headers: { 'user-agent': 'OrnekVeriToplayici/1.0 (iletisim adresiniz)' },
        signal: AbortSignal.timeout(30000),
      })
    } catch {
      await sleep(backoff(attempt))
      continue                      // ağ hatası: yeni bağlantıyla tekrar
    }

    if (res.status === 407) throw new Error('Proxy kimlik bilgisi hatalı, döngü durduruldu')
    if ([403, 404, 410].includes(res.status)) {
      await res.body?.cancel()
      return { url, outcome: 'birak-' + res.status }
    }
    if (RETRYABLE.has(res.status)) {
      const wait = backoff(attempt, res.headers.get('retry-after'))
      await res.body?.cancel()
      b.fails++
      if (b.fails >= BREAK_AFTER) {
        b.openUntil = Date.now() + COOLDOWN_MS
        return { url, outcome: 'devre-kesildi' }
      }
      await sleep(wait)
      continue
    }

    const body = await res.text()
    stats.bytes += Buffer.byteLength(body)  // açılmış boyut: faturayla aynı değil, eğilim içindir
    b.fails = 0
    if (mustContain && !body.includes(mustContain)) {
      return { url, outcome: 'yumusak-engel-suphesi' }
    }
    return { url, outcome: 'ok', body }
  }
  return { url, outcome: 'deneme-bitti' }
}

İskelette üç bilinçli tercih var. İlki, 403 ve 404 asla yeniden denenmez; 407 ise bütün işi durdurur, çünkü kimlik bilgisi hatası her istekte aynen tekrar edecektir. İkincisi, beklenen bir metin parçası yanıtta yoksa istek başarılı sayılmaz; bu kontrol, 200 kodlu yumuşak engellerin veri setinize sessizce boş kayıt olarak girmesini önler. Üçüncüsü, sayaçtaki bayt değeri açılmış içeriğin boyutudur. Proxy tarafında ölçülen trafik sıkıştırma, başlıklar ve şifreleme katmanı nedeniyle bundan farklıdır; sayaç fatura tahmini için değil, hedef bazında eğilimi izlemek içindir.

Python tarafında çalışan ekipler aynı ilkelerin çoğunu Scrapy’nin yerleşik ayarlarıyla kurabilir. Aşağıdaki örnekteki asıl fikir, ürün seçiminin kodun içine gömülmemesi ve hedef bazında bir tabloda durmasıdır. Küçük bir ara katman, isteğin gittiği alan adına bakarak hangi ürünün bağlantı bilgisinin kullanılacağına karar verir. Kimlik bilgisi proxy adresinin içine yazıldığında Scrapy’nin yerleşik proxy ara katmanı yetkilendirme başlığını kendisi ekler.

# settings.py
ROBOTSTXT_OBEY = True
USER_AGENT = "OrnekVeriToplayici/1.0 (+iletisim adresiniz)"

CONCURRENT_REQUESTS = 16               # varsayım: toplam tavan
CONCURRENT_REQUESTS_PER_DOMAIN = 2     # varsayım: hedef başına tavan
DOWNLOAD_DELAY = 1.0                   # aynı hedefe ardışık istekler arası taban bekleme

AUTOTHROTTLE_ENABLED = True
AUTOTHROTTLE_START_DELAY = 2.0
AUTOTHROTTLE_MAX_DELAY = 60.0
AUTOTHROTTLE_TARGET_CONCURRENCY = 1.0

RETRY_ENABLED = True
RETRY_TIMES = 3
RETRY_HTTP_CODES = [429, 500, 502, 503, 504]   # 403 bilerek listede yok
DOWNLOAD_TIMEOUT = 30

DOWNLOADER_MIDDLEWARES = {
    "proje.middlewares.HedefeGoreProxy": 350,  # yerleşik proxy katmanından (750) önce çalışır
}

# middlewares.py
from scrapy.utils.httpobj import urlparse_cached

# Her ürünün bağlantı bilgisi kendi panelinden alınır.
HEDEF_URUN = {
    "katalog.example": "http://KULLANICI:ŞİFRE@GATEWAY:PORT",    # IPv4 Datacenter
    "bolgesel.example": "http://KULLANICI:ŞİFRE@GATEWAY:PORT",   # IPv4 Residential, ülke sabit
}


class HedefeGoreProxy:
    def process_request(self, request, spider):
        if "proxy" in request.meta:
            return None
        proxy = HEDEF_URUN.get(urlparse_cached(request).hostname)
        if proxy:
            request.meta["proxy"] = proxy
        return None

Bu yapıda bir hedefi datacenter’dan residential’a taşımak tek satırlık bir değişikliktir ve diğer hedefleri etkilemez; senaryo bölümünde bunun maliyete etkisi görülecek. Tabloda olmayan bir alan adına giden istek proxy kullanmadan çıkar; bunu istemiyorsanız varsayılan bir ürün tanımlayın ya da tanımsız hedefe giden isteği reddedin. AutoThrottle yanıt sürelerine bakarak beklemeyi kendisi ayarlar ve hedef başına tavanla birlikte hızın hedefe göre şekillenmesini sağlar.

Yerleşik yeniden deneme ara katmanının Retry-After başlığını dikkate alıp almadığını kullandığınız Scrapy sürümünün dokümantasyonundan doğrulayın; 429’un sık görüldüğü hedeflerde bu başlığı okuyan küçük bir ara katman eklemek ya da hedef başına tavanı düşürmek gerekebilir. RETRY_HTTP_CODES listesinde 403’ün olmaması bilinçlidir ve listeye eklenmemelidir. Ayrıca ayrıştırma aşamasında beklenen alan yoksa öğeyi üretmek yerine uyarı kaydı bırakın; böylece yumuşak engeller veri setine değil günlüğe düşer.

RotatingProxy kataloğunda iki faturalama modeli var ve ikisi farklı şeyleri ölçer. GB modeli aktardığınız veriyi sayar; işin ne kadar sürdüğü önemli değildir ve IPv4 paketlerinde süre sınırı olmadığı için kullanılmayan kota bir sonraki taramaya kalır. Port modeli ise zamanı ve kanalı sayar: katalogda paketler GB yerine port ve aylık süreyle fiyatlanır, port sayısı eşzamanlı kanal kapasitesini belirler. Port başına bir trafik koşulu olup olmadığını sipariş adımında ve panelde kontrol edin; aşağıdaki karşılaştırmalar trafik sınırı olmadığını varsayar. Scraping iş yükleri doğaları gereği bu iki modelden birine daha yakındır.

Tablodan iki pratik sonuç çıkar. Birincisi, GB modelinde ürünler arasındaki fark paketler arasındaki farktan büyüktür: 100 GB kademesinde Residential, Datacenter’ın iki katı; Mobile ise 3,75 katıdır. Doğru ürünü seçmek, aynı ürünün daha büyük paketini almaktan daha fazla tasarruf sağlar. İkincisi, port modelinde 5 portluk paket port başına en düşük fiyatı verir (aylık 16 dolar); 10 portluk paket port başına 17,5 dolara gelir. On kanala ihtiyacınız varsa iki adet 5 portluk paket ile tek bir 10 portluk paket arasındaki fiyat ve yönetim farkını sipariş adımında karşılaştırın.

Hangi modelin ucuz olduğunu aylık trafik belirler; aşağıdaki başabaş hesapları port paketinde trafik sınırı olmadığı varsayımına dayanır. 5 portluk IPv6 Datacenter paketi aylık 80 dolardır; bu tutar IPv4 Datacenter’ın GB başına 0,60 dolarlık fiyatıyla yaklaşık 133 GB’a karşılık gelir. Yani IPv6 üzerinden erişilebilen bir hedefte aylık trafiğiniz düzenli olarak bu düzeyin üzerindeyse ve 5 portun kanal kapasitesi işinize yetiyorsa port modeli öne geçer. Karşılaştırmayı residential tarafında yaparsanız eşik düşer: 80 dolar, GB başına 1,20 dolarla yaklaşık 67 GB eder. Trafik düzensizse, örneğin ayda bir yapılan büyük bir tarama söz konusuysa, süre sınırı olmayan GB paketleri boşta geçen haftalar için ödeme yapmamanızı sağlar.

Bir pazar araştırma ekibinin aylık veri toplama planını düşünelim. Ekip üç grup hedeften yalnız kamuya açık sayfaları topluyor ve her grup keşif adımlarında farklı bir profil çıkardı. Grup A, datacenter trafiğine tepki vermeyen teknik doküman ve ürün kataloğu siteleri. Grup B, Almanya ve Türkiye ziyaretçilerine farklı içerik gösteren ve datacenter çıkışta eksik veri veren bölgesel siteler. Grup C, IPv6 üzerinden aynı içeriği veren ve gün boyu sürekli izlenen tek bir büyük hedef. Sayfa sayıları, yanıt boyutları ve yeniden deneme payları tamamen varsayımdır; hesapta 1 GB = 1.000.000 KB alınmıştır. Fiyatlar RotatingProxy kataloğundandır.

Grup C için kapasiteyi de kontrol edelim. Ayda 2 milyon istek, 30 günlük bir ayda saniyede ortalama 0,77 isteğe denk gelir. Ortalama yanıt süresi 2 saniye ise (varsayım) bu hız yaklaşık 2 eşzamanlı istekle karşılanır. 5 portun bu yükü taşıyıp taşımadığını port başına bağlantı koşulunu panelde okuyarak doğrulayın; yük gün içinde eşit dağılmıyorsa hesabı ortalamaya göre değil en yoğun saate göre yapın.

Karma planın aylık toplamı 30 + 36 + 80 = 146 USD’dir. Aynı 207,3 GB’lık trafiğin tamamı IPv4 Residential’a verilseydi 200 GB ve 10 GB paketlerle 240 + 12 = 252 USD ödenecekti. Hedef bazında ürün seçimi bu senaryoda aylık 106 USD, yani yaklaşık yüzde 42 tasarruf sağlıyor. Fark ürünlerin kalitesinden değil, her hedefe yetecek kadar ürün verilmesinden geliyor; bütün trafiği tek bir ürüne zorlamak ya bu farkı ödemek ya da Grup B’de eksik veri kabul etmek demektir.

Plan canlıda değişecektir ve hedef bazında yapı bu değişikliği ucuzlatır. Grup A’daki dört hedeften birinde (varsayım: trafiğin dörtte biri) datacenter çıkışta eksik veri görülmeye başlarsa ve koşullar izin veriyorsa yalnız o hedefi residential’a taşımak yeterlidir. Bu yaklaşık 9,9 GB residential’da 11,88 USD, datacenter’da 5,94 USD tutar; fark aylık 6 USD civarındadır. Bütün grubu taşımak ise 39,6 GB için 47,52 USD’ye mal olur ve sorunu olmayan üç hedefin maliyetini de ikiye katlar. Grup C’nin hedefi IPv6 üzerinden içerik vermeyi bırakırsa port paketini bir sonraki dönemde yenilemeyip trafiği IPv4 Datacenter’a döndürürsünüz; tablodaki karşılaştırmaya göre bu aylık yaklaşık 10 USD fark demektir.

Teknik olarak erişilebilen her veri toplanabilir veri değildir. Hukuki çerçeve ülkeden ülkeye değişir ve bu bölüm hukuki danışmanlığın yerine geçmez; ancak meşru bir scraping projesinin üzerinde durduğu birkaç sabit nokta vardır. Bunları proje başında yazılı hâle getirmek, ileride bir site sahibinden ya da müşteriden gelen soruya hazırlıklı olmanızı sağlar.

• robots.txt: Robots Exclusion Protocol, RFC 9309 ile standartlaştırılmıştır. Dosya bir erişim yetkilendirme mekanizması değil, site sahibinin tarayıcılardan beklentisini bildiren bir metindir; ona uymak meşruiyetin ilk göstergesidir. Crawl-delay gibi yönergeler standardın parçası değildir, ama site sahibinin hız beklentisini gösterdiği için dikkate alınmalıdır.
• Kullanım koşulları: Pek çok site otomatik erişimi koşullarında sınırlar ya da yasaklar. Koşulları kabul ettiğiniz bir hesapla giriş yapıp veri toplamak, kamuya açık bir sayfayı ziyaret etmekten farklı bir hukuki durum yaratır.
• Kişisel veri: Türkiye’de 6698 sayılı Kişisel Verilerin Korunması Kanunu, AB’deki hedeflerde ise GDPR kişisel verilerin işlenmesini düzenler. Ad, e-posta, telefon, kullanıcı adı veya profil bilgisi gibi alanlara ihtiyacınız yoksa toplamayın; gerekiyorsa hukuki dayanağı, saklama süresini ve silme sürecini önceden belirleyin.
• Fikri haklar: Metinler, görseller ve derlenmiş veri tabanları telif ve veri tabanı haklarıyla korunabilir. Fiyat, stok durumu veya teknik özellik gibi olgusal veriyi toplamak ile içeriği olduğu gibi yeniden yayımlamak aynı risk düzeyinde değildir.
• Teknik önlemler: CAPTCHA, giriş duvarı veya bot korumasını aşmak, sistem sahibinin açıkça koyduğu bir sınırı ihlal etmektir ve duruma göre yetkisiz erişim boyutuna varabilir; Türk Ceza Kanunu bilişim sistemine hukuka aykırı girmeyi suç olarak düzenler.
• Kendinizi tanıtın: User-Agent başlığında toplayıcınızın adını ve size ulaşılabilecek bir iletişim bilgisini verin. Site sahibi bir sorun gördüğünde sizi doğrudan engellemek yerine size yazabilir.

Aşağıdaki sorunlar genel bağlantı hatalarından çok rotasyonun kendisinden ya da ürün ile hedef arasındaki uyumsuzluktan doğar. Önce belirtiyi bulun, nedeni küçük bir testle doğrulayın, sonra çözümü uygulayın. Birden fazla ayarı aynı anda değiştirmek, hangisinin işe yaradığını gizler ve bir sonraki sorunda aynı belirsizliği yeniden yaşatır.

Tablodaki sorunların çoğu canlıda değil, pilotta yakalanabilir. Pilot sırasında her hedef için durum kodu dağılımını, beklenen alan oranını ve bayt tüketimini ayrı ayrı kaydederseniz bu belirtilerin hangisinin hangi hedefte ortaya çıktığını ilk günden görürsünüz. Toplam başarı oranına bakmak sorunu gizler: dokuz sorunsuz hedef, onuncu hedefteki tamamen boş verinin üzerini örtebilir.

• Her hedef için keşif kaydı var: robots.txt ve koşullar okundu; durum ihtiyacı, adres ailesi, coğrafi fark ve ağ toleransı yazıldı.
• Hedef ile ürün eşleşmesi yapılandırmada hedef bazında tanımlı; bütün trafik tek ürüne zorlanmıyor ve tanımsız hedefe ne olacağı belli.
• Her akışın iş birimi belirlendi; durumlu akışlar oturum bazlı, durumsuz istekler istek başına rotasyonla çalışıyor.
• Ülkeye duyarlı hedeflerde ülke sabit ve kayıtlarda ülke alanı tutuluyor.
• Hedef başına ve toplam eşzamanlılık tavanı kademeli artışla bulundu; port bazlı üründe toplam tavan port kapasitesinin altında.
• Yeniden deneme yalnız 429, 5xx ve ağ hatalarında yapılıyor; 403, 404 ve 407 tekrar edilmiyor; Retry-After dikkate alınıyor.
• Yeniden deneme bütçesi ve hedef başına devre kesici tanımlı; eşik aşıldığında ekibe uyarı gidiyor.
• Beklenen alan kontrolü var; boş ya da doğrulama sayfası olan 200 yanıtlar veri setine girmiyor.
• GB tüketimi hedef bazında izleniyor; aylık tahmin ile gerçekleşen arasındaki fark düzenli olarak gözden geçiriliyor.
• Kişisel veri alanları toplanmıyor ya da hukuki dayanak, saklama süresi ve silme süreci belirlenmiş.
• User-Agent toplayıcının adını ve iletişim bilgisini taşıyor; site sahibinden gelen bir talebe kimin yanıt vereceği belli.

Listenin amacı işi yavaşlatmak değil, sorunları canlıda değil pilotta yakalamaktır. Maddelerin çoğu bir kez kurulur ve sonra kendiliğinden çalışır: hedef tablosu, hata sınıflandırması, devre kesici ve bayt sayacı yerinde olduğunda yeni bir hedef eklemek, keşif adımlarını uygulayıp tabloya bir satır eklemekten ibarettir. Ürün değiştirme kararı da aynı kayıtlardan çıkar; tahminle değil, hedef bazında ölçülen hata oranı ve GB tüketimiyle verilir.