Rotating IPv4 Datacenter Proxy

Bu üründe ödeme, bağlandığınız IP sayısına ya da ay sayısına göre değil, proxy üzerinden geçen veri miktarına göre yapılır. Katalogda paketler tek seferlik GB satın alımı olarak listelenir ve fiyatlar USD cinsindendir. Bu modelin pratik sonucu şudur: maliyetinizi istek sayısı değil, isteklerin toplam boyutu belirler. Aynı bütçeyle küçük JSON yanıtları toplayan bir ekip milyonlarca istek yapabilirken, görselleri ve betikleri de indiren bir tarayıcı otomasyonu aynı GB’ı birkaç gün içinde bitirebilir.

Tablodaki önemli ayrıntı, 10 GB ile 100 GB arasında birim fiyatın değişmemesidir. Büyük paket almak GB başına indirim getirmez; bu yüzden paket büyüklüğünü indirim beklentisiyle değil, ölçülmüş tüketiminize ve satın alma sıklığınıza göre seçmek daha mantıklıdır. Büyük paketin avantajı operasyoneldir: kota bitti diye gece çalışan bir işin yarıda kalma riski azalır ve ekip her hafta yeniden sipariş vermek zorunda kalmaz.

Katalog açıklaması bu ürün ailesindeki GB paketlerinin süre bitimi olmayan paketler olduğunu ve doğrulanmış katalogdaki koşullara tabi olduğunu belirtir. Yine de kalan kotanın geçerlilik ve kullanım koşullarını satın almadan önce panelde okumak iyi bir alışkanlıktır. Muhasebe tarafında bu model, aylık abonelikten çok ön ödemeli bir kontöre benzer; tüketim raporu tutmazsanız maliyetin hangi işten geldiğini sonradan ayırmak zordur.

GB bazlı bir ürünü planlarken en sık yapılan hata, sayfa boyutunu tarayıcıda görünen değere göre tahmin etmektir. Proxy kotasından düşen miktar; istek başlıkları, TLS el sıkışması, yönlendirmeler, sıkıştırılmış ya da sıkıştırılmamış yanıt gövdesi ve başarısız denemelerin tamamını kapsar. Bu nedenle tahmin yerine küçük bir ölçüm yapın: hedeften temsil edici 200–500 adreslik bir örnek seçin, proxy olmadan ve proxy ile çekin, istek başına aktarılan bayt miktarını kaydedin.

Aşağıdaki hesap tamamen varsayımsaldır ve yalnızca yöntemi göstermek içindir. Kendi hedefinizde ölçtüğünüz değerleri koyduğunuzda sonuç değişecektir. Varsayımlar şunlardır: sıkıştırma açıkken bir HTML ürün sayfası başlıklar ve TLS ek yüküyle birlikte ortalama 150 KB tutar; bir JSON API yanıtı ortalama 15 KB tutar; başarısız istekler ve yeniden denemeler toplam trafiğe yüzde 10 ek yük getirir; hesap kolaylığı için 1 GB yaklaşık 1.000.000 KB kabul edilir. Sağlayıcının GB tanımını ve sayaç davranışını panelde doğrulayın.

İlk satırda günlük 20.000 sayfa, 150 KB ile 3.000.000 KB yani yaklaşık 3 GB eder; yüzde 10 yeniden deneme payıyla 3,3 GB olur ve 30 günde yaklaşık 99 GB’a ulaşır. Bu iş için 100 GB paket tam sınırdadır; bir hedefin sayfa yapısı büyürse ay sonuna yetmeyebilir. Üçüncü ve dördüncü satırlar ise aynı sayıda sayfanın, yalnızca tarayıcının neyi indirdiğine göre beş kat farklı maliyet üretebileceğini gösterir. GB bazlı modelde en etkili tasarruf aracı pazarlık değil, istemci yapılandırmasıdır.

Ölçüm için pratik bir kural: pilot çalışmayı 10 GB paketle yapın, ilk 48 saatin tüketimini iş bazında kaydedin ve aylık tahmini bu ölçüme göre çıkarın. Ölçüm yapmadan büyük paket almak, birim fiyat zaten sabit olduğu için hiçbir avantaj sağlamaz.

Çıkış IP’sinin değişmesi sunucu açısından yeni bir ziyaretçi demektir. Bu durum istemci kodunuzun varsayımlarını bozabilir. Örneğin bir hedef, ilk istekte çerez atayıp sonraki isteklerde aynı çerezin aynı IP’den gelmesini bekliyorsa, IP değiştiğinde oturum geçersiz sayılabilir ya da ek doğrulama istenebilir. Katalog bu ürünün dönüş politikasının oturum ve istemci ayarına bağlı olduğunu belirtir; her istekte mi yoksa belirli bir oturum boyunca mı aynı IP’nin kullanılacağını entegrasyon ayarlarından ve panelden kontrol etmeniz gerekir.

Pratikte işleri iki gruba ayırmak sorunların çoğunu çözer. Birinci grup durumsuz işlerdir: herkese açık bir ürün sayfasını, kategori listesini ya da arama sonucunu tek istekle çekmek. Bu işlerde her isteğin farklı IP’den çıkması avantajdır, çünkü yük hedefin gözünde dağılır. İkinci grup durumlu işlerdir: sepete ürün ekleyip fiyatı görmek, sayfalama için sunucunun verdiği imleci takip etmek, giriş gerektiren bir panelden rapor almak. Bu işlerde akışın tamamı aynı IP ve aynı çerez kavanozuyla tamamlanmalıdır; aksi halde ikinci adımda hata alırsınız.

Datacenter altyapısının avantajı, bağlantıların genellikle düşük gecikmeli ve tutarlı olmasıdır; ancak verim yalnızca proxy’ye bağlı değildir. Toplam süre; istemcinizden proxy ağ geçidine olan mesafe, ağ geçidinden hedefe olan mesafe, hedefin yanıt üretme süresi ve sizin aynı anda kaç istek gönderdiğiniz tarafından belirlenir. Lokasyon seçimi burada doğrudan rol oynar: hedef sunucu Avrupa’daysa ve çıkışınız Avrupa’daki bir lokasyondaysa ağ turu kısalır. Rotating IPv4 ürününde katalog Amerika Birleşik Devletleri, Birleşik Krallık, Almanya, Fransa, Türkiye, Hollanda, Kanada, Brezilya, Avustralya, Japonya, Hindistan, Polonya, Avusturya, Portekiz ve İspanya’yı öne çıkan lokasyonlar olarak listeler; genel kapsam notu ise 180+ olarak geçer. Hangi lokasyonun hangi pakette seçilebildiğini sipariş adımında doğrulayın.

Eşzamanlılık artırıldıkça verim belli bir noktaya kadar doğrusal büyür, sonra düzleşir ve ardından hatalar artmaya başlar. Bu kırılma noktası genellikle proxy’den değil hedeften gelir: hedef sunucu kısa sürede çok sayıda istek gördüğünde yanıt süresini uzatır, 429 döndürür ya da bağlantıyı keser. Bu yüzden eşzamanlılık sabit bir sayı olarak değil, ölçülerek bulunan bir değer olarak ele alınmalıdır. Kaynak katalogda eşzamanlı bağlantı limiti belirtilmez; hesabınıza tanımlı bir sınır olup olmadığını panelde kontrol edin.

1. Hedef başına düşük bir eşzamanlılıkla başlayın, örneğin 5 paralel istek, ve 15 dakika boyunca medyan ile yüzde 95’lik yanıt süresini, hata oranını ve dakika başına başarılı isteği kaydedin.
2. Eşzamanlılığı adım adım artırın, örneğin 5, 10, 20, 40 şeklinde, ve her adımda aynı ölçümleri tekrarlayın.
3. Yüzde 95’lik yanıt süresinin belirgin biçimde uzadığı ya da 429 ve zaman aşımı oranının yükseldiği ilk adımı not edin.
4. Üretim eşzamanlılığını bu değerin bir adım altında sabitleyin; kalan kapasiteyi yeniden denemeler için bırakın.
5. Her hedef için ayrı bir sınır tutun; bir hedefin dayanabildiği yükü başka bir hedefe uygulamayın.
6. Ölçümü haftalık tekrarlayın, çünkü hedeflerin koruma ayarları ve sayfa boyutları zamanla değişir.

Bu yaklaşımın maliyet tarafı da vardır. Kırılma noktasının üzerinde çalışan bir iş, hatalı yanıtlar ve yeniden denemeler yüzünden aynı sayıda başarılı sayfa için daha fazla GB tüketir. Yani agresif eşzamanlılık hem hedefe hem bütçenize zarar verir. Dakika başına başarılı sayfa sayısını tüketilen GB’a bölerek izlediğiniz bir verimlilik metriği, ayarın doğru olup olmadığını en net gösteren göstergedir.

Datacenter IP’leri, barındırma şirketlerine ait otonom sistem numaralarından yani ASN’lerden yayınlanır. Pek çok hedef site, gelen trafiğin ev internet sağlayıcısından mı yoksa bir veri merkezinden mi geldiğini ASN üzerinden kolayca anlayabilir. Bu bir yasak anlamına gelmez; kamuya açık verileri sunan sitelerin çoğu datacenter trafiğini normal karşılar. Ancak bazı hedefler, özellikle hesap açma, ödeme ya da sınırlı stok sayfalarında, datacenter ASN’lerinden gelen istekleri daha sıkı inceler ya da ek doğrulama gösterir.

Rotasyon bu durumu ortadan kaldırmaz. IP değiştiğinde ASN çoğu zaman aynı ailede kalır; hedef tek tek IP’leri değil, ağ bloğunu ya da ASN’yi değerlendiriyorsa rotasyonun etkisi sınırlıdır. Bu yüzden rotating IPv4 datacenter proxy, hedefin kurallarına uyan, makul hızda yapılan, herkese açık veri toplama işlerinde en iyi sonucu verir. Hedef açıkça residential kimlik bekliyorsa katalog da bu ürünün o senaryoya uygun olmadığını belirtir.

İtibar açısından en çok işe yarayan uygulamalar teknik değil davranışsaldır: tanımlanabilir ve dürüst bir User-Agent kullanmak, gereksiz sayfaları çekmemek, önbellek başlıklarına saygı göstermek, aynı içeriği kısa aralıklarla tekrar istememek ve gece saatleri gibi hedefin düşük yükte olduğu zaman dilimlerini tercih etmek. Bu uygulamalar hem engellenme olasılığını düşürür hem de gereksiz trafik üretmediğiniz için GB tüketimini azaltır.

Rotating bir proxy ile çalışırken bazı isteklerin başarısız olması normaldir: hedef geçici olarak yavaşlar, bir çıkış kısa süreli sorun yaşar ya da hedef 429 ile yavaşlamanızı ister. Sorun, bu hatalara verilen tepkidir. Hemen ve sınırsız tekrar deneyen bir istemci hem hedefi daha çok zorlar hem de her denemede GB harcar. Sağlıklı bir yeniden deneme politikasının üç özelliği vardır: deneme sayısı sınırlıdır, denemeler arasındaki bekleme üstel olarak artar ve rastgele bir sapma içerir, ve her hata türü aynı şekilde ele alınmaz.

Bağlantı zaman aşımı ve 502, 503, 504 gibi ağ geçidi hataları genellikle yeniden denemeye değerdir; rotasyon sayesinde ikinci deneme farklı bir çıkıştan gidebilir. 429 yanıtında ise sunucunun Retry-After başlığı varsa ona uyulmalı ve o hedef için genel hız düşürülmelidir. 403 ve 401 gibi yanıtlar çoğu zaman tekrar denemeyle düzelmez; bunları kaydedip insan gözüyle incelemek gerekir. 404 ise kalıcıdır ve tekrar denenmemelidir.

import random
import time
import requests

PROXY = 'http://KULLANICI:ŞİFRE@GATEWAY:PORT'
PROXIES = {'http': PROXY, 'https': PROXY}

RETRY_STATUS = {502, 503, 504}
MAX_TRIES = 4

def fetch(url, session=None):
    s = session or requests.Session()
    for attempt in range(1, MAX_TRIES + 1):
        try:
            r = s.get(url, proxies=PROXIES, timeout=(5, 20))
        except (requests.ConnectTimeout, requests.ReadTimeout, requests.ConnectionError):
            r = None
        if r is not None:
            if r.status_code == 429:
                wait = float(r.headers.get('Retry-After', 10))
                time.sleep(wait)
                continue
            if r.status_code not in RETRY_STATUS:
                return r  # 2xx, 3xx, 403, 404 gibi yanıtlar çağırana döner
        backoff = min(60, 2 ** attempt) + random.uniform(0, 1)
        time.sleep(backoff)
    return None  # deneme hakkı bitti; kaydedip kuyruğa sonra geri koyun

Bu iskelette 429 durumunda bekleme süresi sunucudan alınır, ağ geçidi hatalarında üstel bekleme uygulanır ve 403 gibi yanıtlar çağırana döndürülerek ayrı bir karar mekanizmasına bırakılır. Üretim ortamında buna hedef bazlı bir devre kesici eklemek iyi olur: belirli bir pencerede hata oranı eşiği aşan hedef için tüm istekler birkaç dakika durdurulur. Böylece hedef sorun yaşarken yüzlerce başarısız istekle GB yakmazsınız.

Katalog bu ürün için HTTP, HTTPS ve SOCKS5 protokollerini listeler. Seçim çoğunlukla istemcinize göre yapılır. Web istekleri yapan araçların neredeyse hepsi HTTP proxy’yi doğrudan destekler ve HTTPS hedefler için CONNECT yöntemiyle şifreli tünel kurar; bu durumda proxy içeriği görmez, yalnızca hedef alan adını ve aktarılan bayt miktarını bilir. SOCKS5 ise daha genel bir tünel sağlar ve HTTP dışındaki TCP trafiği için de kullanılabilir. DNS çözümlemesinin nerede yapılacağı da önemlidir: SOCKS5 ile alan adını proxy tarafında çözdürmek, istemcinizin bulunduğu ağın DNS sonuçlarının hedef lokasyonla uyuşmaması sorununu önler.

Aşağıdaki örneklerde GATEWAY, PORT, KULLANICI ve ŞİFRE yer tutucudur. Gerçek ağ geçidi adresi, port numarası ve kimlik doğrulama yöntemi panelinizde yer alır; bu sayfada belirli bir değer verilmez. Kimlik doğrulama kullanıcı adı ve şifre yerine IP izin listesiyle yapılıyorsa kimlik bilgisi kısmını çıkarmanız gerekir.

# HTTP proxy: üç ardışık istekte çıkış IP'sini yazdırır
for i in 1 2 3; do
  curl -s -x http://KULLANICI:ŞİFRE@GATEWAY:PORT https://api.ipify.org
  echo
done

# SOCKS5, alan adı proxy tarafında çözülür (socks5h)
curl -s --proxy socks5h://KULLANICI:ŞİFRE@GATEWAY:PORT https://api.ipify.org

# Aktarılan bayt miktarını görmek için (tüketim ölçümü)
curl -s -o /dev/null -w "%{size_download} bayt, %{time_total} sn\n" \
  -x http://KULLANICI:ŞİFRE@GATEWAY:PORT https://example.com/

import { ProxyAgent, request } from 'undici'

const agent = new ProxyAgent('http://KULLANICI:ŞİFRE@GATEWAY:PORT')
const LIMIT = 10 // ölçerek bulduğunuz hedef bazlı eşzamanlılık

async function worker(queue, results) {
  while (queue.length) {
    const url = queue.shift()
    try {
      const res = await request(url, { dispatcher: agent, headersTimeout: 20000 })
      const body = await res.body.text()
      results.push({ url, status: res.statusCode, bytes: body.length })
    } catch (err) {
      results.push({ url, error: String(err) })
    }
  }
}

export async function run(urls) {
  const queue = [...urls]
  const results = []
  await Promise.all(Array.from({ length: LIMIT }, () => worker(queue, results)))
  return results
}

Node örneğinde yanıt boyutu her istek için kaydedilir. Bu kayıtları günlük olarak toplarsanız, panelde gördüğünüz tüketimle kendi ölçümünüzü karşılaştırabilir ve hangi hedefin kotayı beklenenden hızlı tükettiğini erkenden yakalarsınız. Gövde uzunluğu, başlıklar ve TLS ek yükü içermediği için panel değerinden bir miktar düşük çıkacaktır; aradaki farkın oranını bir kez bulmanız yeterlidir.

Birim fiyat sabit olduğu için GB bazlı modelde tasarruf yalnızca daha az veri aktararak sağlanır. Aşağıdaki ayarlar, toplanan verinin kalitesini düşürmeden tüketimi azaltır. Her birini uygulamadan önce ve sonra aynı örnek adres listesiyle ölçüm yapın; bazı hedeflerde etki büyük, bazılarında küçük olacaktır.

• Sıkıştırmayı açık tutun: Accept-Encoding başlığında gzip ve br gönderin. Metin içerikte aktarım çoğu zaman birkaç kat küçülür.
• Başsız tarayıcıda görsel, video, font ve reklam betiklerini engelleyin; yalnızca veriyi üreten belge ve gerekli betikleri yükleyin.
• Hedef bir JSON uç noktası sunuyorsa ve kullanım koşulları izin veriyorsa HTML yerine o uç noktayı kullanın.
• Koşullu istekler kullanın: If-None-Match ya da If-Modified-Since ile değişmeyen sayfalar için 304 yanıtı alın.
• Aynı adresi kısa aralıkla tekrar istemeyin; değişim sıklığına göre tarama takvimi kurun.
• Yönlendirme zincirlerini çözüp doğrudan son adresi isteyin; her yönlendirme ayrı bir istek ve ek bayt demektir.
• Zaman aşımını gerçekçi tutun; çok uzun zaman aşımı yavaş yanıtları sonuna kadar indirir, çok kısa zaman aşımı ise neredeyse tamamlanmış indirmeleri çöpe atar.

Bu ayarların etkisini varsayımsal bir örnekle düşünelim: günde 5.000 sayfa çeken bir tarayıcı otomasyonu kaynak engeli olmadan sayfa başına 2.000 KB aktarıyorsa ayda yaklaşık 330 GB tüketir. Aynı iş görsel ve fontları engelleyip sayfa başına 400 KB’a indiğinde ihtiyaç yaklaşık 66 GB’a düşer. 0,60 USD birim maliyetle bu, ayda yaklaşık 198 USD yerine yaklaşık 39,60 USD demektir. Değerler varsayımdır ama oran, istemci ayarının paket seçiminden çok daha belirleyici olduğunu gösterir.

Aşağıdaki tablo, rotating IPv4 datacenter kullanımında sık görülen belirtileri ve ilk bakılması gereken yerleri özetler. Proxy kaynaklı hatalarla hedef kaynaklı hataları ayırmak için önce aynı isteği proxy olmadan ve tek bir basit adrese, örneğin çıkış IP’sini gösteren bir servise, proxy ile gönderin. Basit adres çalışıyorsa sorun büyük olasılıkla hedefin size verdiği tepkidir.

Hata kayıtlarınızda en az şu alanları tutmanız sorun giderme süresini ciddi biçimde kısaltır: istek zamanı, hedef alan adı, kullanılan lokasyon, HTTP durum kodu, yanıt süresi, aktarılan bayt ve deneme sırası. Destek ekibine başvurduğunuzda bu bilgiler, sorunun proxy tarafında mı yoksa hedefte mi olduğunu hızla ayırmayı sağlar.

Paket seçimini iki soruya indirgemek mümkündür: ayda ne kadar veri aktaracaksınız ve kotanın bitmesi işinizi ne kadar etkiler. Birinci sorunun cevabı ölçümden, ikincisinin cevabı işin kritikliğinden gelir. Birim fiyat 10 GB ile 100 GB arasında aynı olduğu için paket büyüklüğü bir maliyet değil, operasyon kararıdır. Aşağıdaki tablo tipik iş yüklerini katalogdaki paketlerle eşleştirir; GB değerleri önceki bölümdeki varsayımlara dayanır.

1. İşlerinizi durumsuz ve durumlu olarak ayırın; durumlu akışlar için oturum davranışını panelde netleştirin.
2. Her hedef için 200–500 adreslik bir örnek seçin ve istek başına ortalama aktarımı ölçün.
3. Günlük istek sayısını, ortalama aktarımı ve yeniden deneme payını çarparak aylık GB tahminini çıkarın.
4. Tahmini 0,60 USD ile çarpıp aylık bütçeyi bulun; kampanyalı paketi bu hesaba katmayın.
5. Kotanın bitmesi kritik bir işi durduruyorsa tahminin yüzde 20 üzerinde bir tampon planlayın.
6. Kalan kota için bir eşik uyarısı kurun ve yeni siparişi kota bitmeden önce verin.
7. Ay sonunda gerçek tüketimi tahminle karşılaştırın ve bir sonraki ayın planını güncelleyin.

Aşağıdaki liste, rotating IPv4 datacenter proxy’yi üretim işine bağlamadan önce gözden geçirilmesi gereken noktaları toplar. Her madde, daha önceki bölümlerde anlatılan bir maliyet ya da güvenilirlik riskine karşılık gelir.

• Ağ geçidi adresi, port, protokol ve kimlik doğrulama yöntemi panelden alındı ve basit bir çıkış IP’si testiyle doğrulandı.
• Lokasyon seçimi hedef sunucunun bölgesine göre yapıldı ve yanıtların doğru ülkeden geldiği kontrol edildi.
• Durumsuz ve durumlu işler ayrıldı; durumlu akışlar için oturum davranışı test edildi.
• Her iş için ayrı çerez deposu kullanılıyor.
• Hedef bazlı eşzamanlılık ölçülerek belirlendi ve kırılma noktasının altında sabitlendi.
• Yeniden deneme sayısı sınırlı, bekleme üstel ve rastgele sapmalı; 429 için Retry-After dikkate alınıyor.
• Sıkıştırma açık; başsız tarayıcıda gereksiz kaynaklar engelli.
• İstek başına aktarılan bayt ve durum kodu kaydediliyor; günlük tüketim panel değeriyle karşılaştırılıyor.
• Kalan kota için eşik uyarısı kuruldu ve yeni sipariş sorumlusu belli.
• Hedeflerin robots.txt yönergeleri, kullanım koşulları ve yayınlanan hız sınırları gözden geçirildi.

Bu listenin tamamı işaretlendiğinde, GB bütçeniz tahmin edilebilir hale gelir ve hedeflerle ilişkiniz sürdürülebilir olur. İlk ay sonunda gerçek tüketimi ve hata oranlarını gözden geçirip eşzamanlılık ile paket büyüklüğünü yeniden ayarlamak, ikinci aydan itibaren maliyeti ve verimi en iyi noktaya yaklaştırır.