Rotating IPv4 Residential Proxy

Residential havuzla çalışan ekiplerin en sık yaptığı hata, rotasyonu açılıp kapanan bir ayar gibi görmektir. Asıl soru “rotasyon olsun mu?” değil, “hangi istekler aynı çıkış IP’sini paylaşmak zorunda?” sorusudur. RotatingProxy’nin IPv4 Residential ürünü hem rotating hem sticky oturumla çalışabildiği için bu kararı ürün değil siz verirsiniz. Verdiğiniz karar da doğrudan üç şeye yansır: GB tüketimi, toplanan verinin doğruluğu ve hedef sitenin trafiğinizi nasıl gördüğü.

Datacenter rotasyonunda yanlış oturum modunun bedeli görece düşüktür; GB ucuz olduğu için bozulan bir akışı yeniden çalıştırmak bütçeyi pek sarsmaz. Residential tarafta ise 10–200 GB paketlerinde GB başına 1,20 USD ödenir; bu, datacenter ürününün aynı kademelerdeki 0,60 USD’sinin tam iki katıdır. Her adımda IP değiştiği için yarıda kalan üç adımlı bir akışı baştan çalıştırdığınızda, ilk denemede indirilen bütün sayfalar boşa giden kotaya dönüşür ve bu kayıp residential’da iki kat hissedilir.

İkinci fark, çıkış noktalarının niteliğidir. Residential çıkış IP’leri veri merkezindeki sabit sunucular değil, konut ağlarına ait (ya da onlara yakın) adreslerdir. Bu yüzden belirli bir IP’nin saatlerce aynı kalacağını ya da her istekte aynı hızda yanıt vereceğini varsayan bir tasarım kırılgan olur. Residential tarafta sticky oturum “mümkün olduğunca uzun tut” mantığıyla değil, “işin gerektirdiği kadar tut” mantığıyla kullanılır. Sayfanın geri kalanı bu ilkenin bütçeye, ülke seçimine ve hata yönetimine nasıl çevrildiğini anlatır.

Oturum modunu doğru seçmenin en pratik yolu, işinizi “iş birimi” denen parçalara ayırmaktır. İş birimi, aynı çıkış IP’sini paylaşması gereken en küçük istek dizisidir. Tek bir kategori sayfasını okumak, tek istekten oluşan bir birimdir. Önce ülke ya da para birimi seçip ardından ürün sayfasını açmak, iki veya üç istekten oluşan bir birimdir. Kural basittir: her iş birimi kendi sticky oturumunu alır, birim bitince oturum bırakılır, sonraki birim yeni bir oturumla başlar. Birbirinden bağımsız tek istekli birimler için sticky oturuma hiç gerek yoktur; rotating mod yükü havuza kendiliğinden yayar.

Birimleri kısa tutmanın iki faydası vardır. Birincisi, bir IP yarıda düşerse kaybedilen trafik birimin boyutuyla sınırlı kalır; üç adımlık birimde en fazla üç sayfa boşa gider, yirmi adımlık bir oturumda yirmi. İkincisi, kayıtlarınızda hangi verinin hangi çıkış IP’sinden ve hangi ülkeden geldiğini birim düzeyinde izleyebilirsiniz; bir tutarsızlık gördüğünüzde sorunlu oturumu tek başına ayıklarsınız.

Panelde rotating ya da sticky ayarını seçtikten sonra, ürünün sizin istemcinizle gerçekte nasıl davrandığını ölçmeden üretime geçmeyin. Sticky oturumun ne kadar sürdüğü, rotating modda IP’nin her istekte değişip değişmediği ve istemcinizin bağlantıyı yeniden kullanıp kullanmadığı yalnız teoride bilinebilecek şeyler değildir. Aşağıdaki küçük betik, yalnız çağıranın IP adresini düz metin olarak döndüren bir uç noktaya art arda istek gönderir ve gördüğü adresleri zaman damgasıyla yazar.

# Çıkış IP'si davranış testi (Python 3, requests)
# HEDEF_URL: yalnız çağıranın IP adresini düz metin döndüren bir uç nokta
import time
import requests

PROXY = 'http://KULLANICI:ŞİFRE@GATEWAY:PORT'  # panelde rotating veya sticky için verilen bilgi
PROXIES = {'http': PROXY, 'https': PROXY}


def cikis_ip(oturum=None):
    istemci = oturum or requests
    yanit = istemci.get('HEDEF_URL', proxies=PROXIES, timeout=(10, 30))
    return yanit.text.strip()


def test_et(adet=10, ayni_baglanti=False, bekleme_sn=5):
    oturum = requests.Session() if ayni_baglanti else None
    gorulen = []
    for sira in range(1, adet + 1):
        ip = cikis_ip(oturum)
        gorulen.append(ip)
        print(f'{sira:>2}. istek  {time.strftime("%H:%M:%S")}  {ip}')
        time.sleep(bekleme_sn)
    print(f'Farklı IP: {len(set(gorulen))} / {adet}')


test_et(ayni_baglanti=False)  # her istek yeni bağlantı açar
test_et(ayni_baglanti=True)   # bağlantı yeniden kullanılır

# Örnek çıktı (rotating ayarı, yeni bağlantı):
#  1. istek  14:02:10  203.0.113.24
#  2. istek  14:02:16  198.51.100.87
#  3. istek  14:02:22  203.0.113.161

Betiği iki kez çalıştırın: bir kez panelde rotating için aldığınız bağlantı bilgisiyle, bir kez sticky için aldığınız bilgiyle. Rotating ayarında ve her istekte yeni bağlantı açıldığında, farklı IP sayısının istek sayısına yakın çıkması beklenir. Sticky ayarında aynı IP’nin kaç istek ve kaç dakika boyunca korunduğunu not edin; iş birimlerinizin bu sürenin rahatça içinde kalması gerekir. Bekleme aralığını büyüterek sticky sürenin sınırını kabaca bulabilirsiniz, ancak panelde yazan değer her zaman ölçümünüzden önce gelir.

Test trafiği de kotadan düşer, fakat IP yankı uç noktalarının yanıtı genellikle birkaç yüz bayttır. Bağlantı başına 6 KB’lık bir TLS el sıkışması varsaysanız bile yüz istekten oluşan bir test megabaytın altında kalır; davranışı ölçmenin maliyeti yok denecek kadar azdır.

GB bazlı pakette kotadan düşen, proxy üzerinden aktarılan trafiğin tamamıdır; yalnız sayfanın görünen içeriği değil. Bütçeyi yanıltan kalemler çoğunlukla gözden kaçan yan trafiklerdir. Bir isteğin kotaya yansıyan bileşenleri şunlardır:

• Yanıt gövdesi: Sunucu sıkıştırma kullanıyorsa aktarılan, sıkıştırılmış boyuttur. Accept-Encoding başlığı göndermeyen bir istemci aynı sayfa için birkaç kat fazla veri çekebilir.
• Başlıklar ve çerezler: Tek istekte küçüktür ama on binlerce istekte birikir; özellikle büyük çerez taşıyan sitelerde fark edilir.
• TLS el sıkışması: HTTPS hedefte her yeni bağlantı, sertifika zinciri dahil bir el sıkışması demektir. İstek başına rotasyonda bu maliyet her istekte tekrar eder.
• Yönlendirmeler: 301 ve 302 zincirindeki her adım ayrı bir istek ve yanıttır. Kanonik adresi doğrudan istemek bu trafiği sıfırlar.
• Yeniden denemeler: Zaman aşımına uğrayan ya da hata dönen her istek, tekrarlandığında kotayı ikinci kez kullanır.
• Gömülü kaynaklar: Headless tarayıcı kullanıyorsanız görsel, font, video ve üçüncü taraf betikler de proxy üzerinden iner; sayfanın HTML’i küçük olsa bile toplam aktarım megabaytlara çıkabilir.

Bu kalemlerin ağırlığı işe göre değişir. Büyük HTML sayfalarında TLS el sıkışmasının payı küçüktür; küçük JSON yanıtlarında ise belirleyici olabilir. El sıkışma başına 6 KB varsayımıyla, 8 KB’lık bir JSON yanıtı her istekte yeni bağlantıyla alınırsa istek başına aktarım 14 KB olur. Aynı uç noktaya on çağrıyı tek bağlantıda yapmak 140 KB yerine 86 KB tüketir; yani küçük yanıtlı işlerde bağlantıyı korumak trafiği yaklaşık yüzde 39 azaltır. 120 KB’lık bir sayfada ise aynı varsayımla el sıkışmanın payı yüzde 5 civarında kalır.

Tahmini doğru yapmanın tek yolu, kendi hedeflerinizden temsilî bir örnek alıp gerçekten aktarılan boyutu ölçmektir. Aşağıdaki betik, sunucunun gönderdiği sıkıştırılmış gövdeyi ve başlıkları sayar; çıkan ortalama, kota hesabında kullanacağınız değerdir. Örnek listesini tek tip sayfalardan değil, işin gerçek karışımından seçin: liste sayfaları, ürün sayfaları ve varsa JSON uç noktaları birlikte.

# Örnek sayfalardan ortalama aktarım boyutunu ölçme (Python 3, requests)
import statistics
import requests

PROXY = 'http://KULLANICI:ŞİFRE@GATEWAY:PORT'
PROXIES = {'http': PROXY, 'https': PROXY}
BASLIKLAR = {
    'Accept-Encoding': 'gzip, deflate',
    'Accept-Language': 'tr-TR,tr;q=0.9',  # kuyruğun ülkesine göre değiştirin
}


def aktarim_kb(url):
    with requests.get(url, proxies=PROXIES, headers=BASLIKLAR,
                      stream=True, timeout=(10, 30)) as yanit:
        govde = yanit.raw.read(decode_content=False)  # sıkıştırılmış gövde
        baslik = sum(len(k) + len(v) + 4 for k, v in yanit.headers.items())
        return (len(govde) + baslik) / 1000


ornekler = ['HEDEF_URL']  # işin gerçek karışımından 50-100 URL
olcumler = [aktarim_kb(url) for url in ornekler]
print(f'Ortalama: {statistics.mean(olcumler):.1f} KB')
print(f'En büyük: {max(olcumler):.1f} KB')

Betik yalnız son yanıtı sayar; ölçüm sırasında yönlendirme görüyorsanız zincirdeki adımları ayrıca ekleyin. Elde ettiğiniz ortalama, aşağıdaki örnek senaryoda kullanılan varsayımların yerini alacak gerçek değerdir.

IPv4 Residential paketleri tek seferlik ödenir ve GB bazlıdır; katalogdaki tanımıyla süre sınırı yoktur, kota bitene kadar kullanılır. Fiyatı paket boyutuna böldüğünüzde tablo çok daha anlamlı hale gelir:

Tablonun ilk dersi şudur: 10 GB ile 200 GB arasında birim fiyat değişmez. 200 GB almak ile iki kez 100 GB almak aynı paraya gelir. Bu aralıkta paket boyutunu indirim değil, nakit akışı ve tüketim hızı belirler; ihtiyacınızı ölçene kadar küçük paketlerle ilerlemek ek maliyet yaratmaz.

İkinci ders eşiklerdir. Toplam ihtiyacınız 460 GB ve üzerindeyse, 1,20 USD kademesinden parça parça almak 552 USD ve üstüne çıkar; 550 USD’lik 500 GB paketi daha ucuzdur. Benzer şekilde 500 GB paketin üzerine 1,20 USD’den ek paket almak, toplam ihtiyaç yaklaşık 790–800 GB’a ulaştığında 1000 GB paketin 900 USD’lik fiyatını yakalar. Somut karşılaştırmalar: beş adet 100 GB paket 600 USD tutarken 500 GB paket 550 USD’dir (50 USD fark); iki adet 500 GB paket 1.100 USD tutarken 1000 GB paket 900 USD’dir (200 USD fark); on adet 100 GB paket ise 1.200 USD ile 1000 GB paketten 300 USD pahalıdır.

Mobile ürünle kıyaslamak da residential’ın yerini netleştirir: Mobile paketlerde GB başına fiyat 2,00 ile 2,50 USD arasındadır. Residential, maliyet olarak datacenter ile mobile arasında durur; taşıyıcı ağı gerektirmeyen ama datacenter’ın yetmediği işlerde orta basamaktır.

Bir pazar analizi ekibinin, kamuya açık bir katalog sitesinin Türkiye, Almanya ve Birleşik Krallık’taki görünümünü her gün ölçtüğünü düşünelim. İş iki koldan oluşur. A kolu, 1.500 kategori ve arama sonucu sayfasını her ülkeden birer kez okur; adımlar arasında durum olmadığı için rotating modda çalışır. B kolu, 300 ürün için ülke seçimi, ürün sayfası ve stok sorgusundan oluşan üç adımlı bir akışı her ülkede çalıştırır; adımlar birbirine bağlı olduğu için her akış ayrı bir sticky oturumdur.

Aşağıdaki değerlerin tamamı varsayımdır ve pilot ölçümünüzle değiştirilmelidir:

• A kolunda sıkıştırılmış HTML ortalaması 120 KB’tır ve her istek yeni bağlantı açar.
• B kolunda iş birimi başına gövde toplamı 280 KB’tır (ülke seçimi sayfası 120 KB, ürün sayfası 150 KB, stok yanıtı 10 KB); birim boyunca tek bağlantı korunur.
• TLS el sıkışması bağlantı başına 6 KB tutar.
• İsteklerin ve iş birimlerinin yüzde 10’u yeniden denenir.
• Ay 30 gün, 1 GB ise 1.000.000 KB alınır; panel 1.024 tabanlı sayıyorsa sonuçlar birkaç yüzde değişir.
• Hesaplanan değere yüzde 20 güvenlik payı eklenir.

# Aylık GB ve maliyet tahmini; girdilerin tamamı varsayımdır
GB_KB = 1_000_000      # hesap kolaylığı: 1 GB = 1.000.000 KB
RES_GB_USD = 1.20      # IPv4 Residential, 10-200 GB paketleri
DC_GB_USD = 0.60       # IPv4 Datacenter, 10-500 GB paketleri
PAY = 1.20             # yüzde 20 güvenlik payı


def aylik_gb(gunluk_birim, govde_kb, baglanti=1, el_sikisma_kb=6,
             tekrar=0.10, gun=30):
    birim_kb = govde_kb + baglanti * el_sikisma_kb
    return gunluk_birim * (1 + tekrar) * birim_kb * gun / GB_KB


kollar = {
    'A rotating': aylik_gb(1500 * 3, govde_kb=120),  # 1 istek, 1 bağlantı
    'B sticky': aylik_gb(300 * 3, govde_kb=280),     # 3 adım, 1 bağlantı
}
kollar['Toplam'] = sum(kollar.values())

for ad, gb in kollar.items():
    payli = gb * PAY
    print(f'{ad:<11}{gb:6.1f} GB  paylı {payli:5.1f} GB  '
          f'RES {payli * RES_GB_USD:6.2f} USD  DC {payli * DC_GB_USD:6.2f} USD')

# A rotating   18.7 GB  paylı  22.5 GB  RES  26.94 USD  DC  13.47 USD
# B sticky      8.5 GB  paylı  10.2 GB  RES  12.23 USD  DC   6.12 USD
# Toplam       27.2 GB  paylı  32.6 GB  RES  39.18 USD  DC  19.59 USD

Ayda yaklaşık 32,6 GB, 60 USD’lik 50 GB paketin bir buçuk aydan biraz uzun sürede tükeneceği anlamına gelir. Yıllık ihtiyaç yaklaşık 392 GB’tır; 460 GB eşiğinin altında kaldığı için 1,20 USD kademesinden gerektikçe almak mantıklıdır. 500 GB paket bu tempoda yaklaşık 15 ay yeter; proje en az bu kadar sürecekse 550 USD’lik tek ödeme, GB başına 0,10 USD tasarruf sağlar.

Hesabın en hassas girdisi sayfa boyutudur. A kolundaki ortalama HTML 120 KB yerine 250 KB çıkarsa, aynı varsayımlarla A kolunun aylık tüketimi 18,7 GB’tan 38,0 GB’a çıkar. Ülke sayısı ise doğrudan bir çarpandır: dördüncü bir ülke eklemek toplamı üçte bir artırır. Bu yüzden ülke listesini ve tarama sıklığını işin gerçek ihtiyacına göre kademelendirmek, çoğu zaman paket seçiminden daha büyük tasarruf sağlar.

Ülke seçtiğinizde rotasyon, havuzun yalnız o ülkeye düşen kısmında gerçekleşir. Katalogda IPv4 Residential için 180’den fazla ülkede kapsama belirtilir; ürün sayfasında öne çıkan doğrulanmış liste Amerika Birleşik Devletleri, Birleşik Krallık, Almanya, Fransa, Türkiye, Hollanda, Kanada, Brezilya, Avustralya, Japonya, Hindistan, Polonya, Avusturya, Portekiz ve İspanya’dan oluşur. Listede olmayan bir ülkeye ihtiyacınız varsa sipariş öncesinde panelde ya da destek kanalında doğrulayın. Şehir düzeyinde hedefleme katalogda yer almaz; bu ihtiyaç için de varsayım yapmadan kontrol edin.

Ülke filtresinin rotasyona üç etkisi vardır. Birincisi, havuz daraldıkça art arda gelen isteklerin aynı ya da yakın adreslerden çıkma ihtimali artabilir; kodunuz IP benzersizliğine güvenen bir mantık içermemelidir. İkincisi, sunucunuz ile çıkış ülkesi arasındaki mesafe yanıt süresini etkiler; uzak ülke kuyruklarına daha cömert zaman aşımı verin. Üçüncüsü, katalogdaki paket fiyatları ülkeye göre ayrı listelenmez; güncel koşulu sipariş ekranında kontrol edin. Her ek ülke ise istek sayısını çoğaltır ve maliyet ülke sayısıyla doğrusal büyür.

Uygulamada işe yarayan alışkanlıklar şunlardır: her kaydı ülke koduyla birlikte saklayın; aynı sticky oturumda iki ülkeyi asla karıştırmayın; Accept-Language başlığını ve para birimi çerezini kuyruğun ülkesiyle uyumlu tutun; her ülke kuyruğuna ayrı çerez kabı ve ayrı hız bütçesi verin. Çıkış ülkesini de körü körüne kabul etmeyin; her gün küçük bir örnekle IP’nin ve hedef sayfada görünen ülke ya da para biriminin beklenenle eşleştiğini kontrol edin.

Ülke sayısını azaltmadan maliyeti düşürmenin yolu sıklığı kademelendirmektir. Örnek senaryoda Birleşik Krallık’ı günlük yerine haftalık ölçüme alırsanız, o ülkenin payı olan yaklaşık 10,9 GB’lık aylık tüketim 1,6 GB civarına iner. Bu, ayda yaklaşık 9,3 GB ve residential fiyatıyla 11,2 USD tasarruf demektir. Birincil pazarı günlük, ikincil pazarları haftalık ölçmek çoğu analiz için yeterli çözünürlüğü korur.

Residential’ın ek maliyeti katalog fiyatlarıyla kesin olarak hesaplanabilir. Değip değmediği ise tek bir ölçüye bağlıdır: kullanılabilir yanıt başına maliyet. Kullanılabilir yanıt; doğru ülkenin içeriğini taşıyan, eksiksiz yüklenmiş ve iki üründe aynı alanları veren yanıttır. Doğrulama sayfası dönen hedef bu hesaba girmez; o hedefte durulur. Hesap şöyledir: kullanılabilir yanıt başına maliyet, GB fiyatı ile ortalama aktarımın çarpımının kullanılabilir yanıt oranına bölünmesiyle bulunur. İki üründe ortalama aktarım aynıysa, residential’ın daha ekonomik olması için datacenter’ın kullanılabilir yanıt oranının residential’ınkinin belirli bir yüzdesinin altına düşmesi gerekir. Bu yüzde doğrudan fiyat oranından gelir:

Tablo şöyle okunur: pilotta residential ile 100 yanıttan 90’ının kullanılabilir çıktığını varsayalım; bu rakam yalnız örnektir, bir ürün ölçümü değildir. 10–200 GB kademesinde datacenter’ın aynı örnekte en az 45 kullanılabilir yanıt üretmesi gerekir. 45’in altında kalırsa residential, pahalı görünmesine rağmen kullanılabilir yanıt başına daha ucuzdur. Zaman aşımı ve eksik yüklenen yanıtlar çoğu zaman tam sayfadan az trafik harcadığı için gerçekte datacenter, tablodaki eşiğin biraz altında da ekonomik kalabilir.

Formül yalnız parayı ölçer. Residential’ın asıl değeri bazen sessiz hatalarda ortaya çıkar: hedef site datacenter adreslerine farklı fiyat, farklı stok ya da farklı sıralama gösteriyorsa, datacenter ile toplanan veri hata vermeden yanlış olur. Bunu anlamanın yolu, aynı 50–100 URL’lik örneği iki üründen de geçirip çıkardığınız alanları satır satır karşılaştırmaktır. Alanlar birebir tutuyorsa ve kullanılabilir yanıt oranı eşiğin üzerindeyse, ek maliyet o iş kolu için değmez.

Çoğu projede doğru cevap “ya o ya bu” değil, iş kollarını ayırmaktır. Örnek senaryoda A kolundaki sayfalar iki üründe aynı içeriği veriyorsa A’yı datacenter’a, ülkeye bağlı stok ve teslimat bilgisini taşıyan B kolunu residential’a almak, payla birlikte aylık 39,18 USD’lik tamamen residential bütçeyi 25,70 USD’ye indirir; bu yaklaşık yüzde 34 daha azdır. Tamamen datacenter kurgusuna göre fark ise yalnız 6,11 USD’dir ve bu fark, B kolundaki verinin doğruluğu için ödenen bedeldir.

Residential rotasyonda karşılaşılan sorunların çoğu, oturum modu ile iş biriminin uyuşmamasından ya da görünmeyen trafikten kaynaklanır. Aşağıdaki tablo belirtiden başlayarak ilerler:

Bu çözümlerin ortak noktası, sorunu IP sayısını artırarak değil, iş biriminin tasarımını ve istek temposunu düzelterek gidermeleridir. Özellikle 429 yanıtında havuzdan daha çok IP çekmek hem kotayı hızla tüketir hem de hedef sitenin koyduğu sınırı yok saymak anlamına gelir.

Residential bütçeyi tahminle değil ölçümle kurmak için küçük bir pilot yeterlidir. 2 GB’lık giriş paketi bu iş için uygundur: örnek senaryodaki 126 KB’lık ortalama istekle yaklaşık 15.800 isteği karşılar; bu da hem davranış testlerine hem de temsilî bir örneklemeye fazlasıyla yeter.

1. Hedef listesini çıkarın ve her hedef için robots.txt kurallarını, kullanım koşullarını ve bilinen hız sınırlarını not edin; kişisel veri toplanmayacağını netleştirin.
2. Panelde residential için rotating ve sticky bağlantı bilgilerini alın; kimlik doğrulama yöntemini, oturum ve ülke parametrelerinin yazımını ve sticky sürenin üst sınırını oradan okuyun.
3. Çıkış IP’si davranış testini her iki ayarla çalıştırın; sticky IP’nin kaç dakika korunduğunu ve rotating ayarında bağlantı yeniden kullanımının IP’yi sabitleyip sabitlemediğini kaydedin.
4. İşinizi iş birimlerine bölün ve her birim için oturum modunu yazın; en uzun birimin ölçtüğünüz sticky süresinin rahatça içinde kaldığını doğrulayın.
5. Her iş kolundan 50–100 temsilî URL ile ortalama aktarım boyutunu ölçün; yönlendirme ve yeniden deneme oranını da kaydedin.
6. Mümkünse aynı örneği datacenter ürünüyle de geçirin; kullanılabilir yanıt oranlarını ve çıkarılan alanları karşılaştırıp eşik tablosuna göre iş kollarını dağıtın.
7. Ölçtüğünüz değerleri hesap aracına girin, yüzde 20 pay ekleyin ve paket kademesini 460 GB ile yaklaşık 800 GB eşiklerine göre seçin.
8. Üretimde günlük GB tüketimini, yeniden deneme oranını, iş birimi yeniden başlatma oranını ve ülke doğrulama sonuçlarını izleyin; günlük tüketim hesaplanan değeri belirgin biçimde aşarsa alarm üretin.
9. İlk haftanın sonunda gerçek tüketimi hesapla karşılaştırın ve varsayımlarınızı ölçülen değerlerle güncelleyin.

Pilotun en değerli çıktısı rakamlardan çok, hangi iş kolunun gerçekten residential gerektirdiğinin netleşmesidir. Pilot sonunda iş kollarının bir kısmı datacenter’a kayıyorsa bu bir başarısızlık değil, bütçenin doğru yere yönlendirilmesidir.

Üretim trafiğini açmadan önce aşağıdaki maddelerin her birine “evet” diyebiliyor olmalısınız:

• Her iş kolunun oturum modu, rotating ya da sticky olarak yazılı ve gerekçesi belli.
• Sticky iş birimleri, panelde yazan ve testte ölçülen süreden belirgin biçimde kısa.
• Birimin başında ve sonunda çıkış IP’si kaydediliyor; IP’si değişen birim atılıp en fazla iki kez yeniden başlatılıyor.
• Rotating iş kollarında istemcinin bağlantı yeniden kullanımı bilinçli olarak ayarlandı.
• İstemci Accept-Encoding gönderiyor; headless tarayıcıda görsel, font ve video istekleri engelli.
• Yeniden deneme sayısı istek başına sınırlı ve 429 yanıtında Retry-After başlığına uyuluyor.
• Her kayıt ülke koduyla saklanıyor; ülke kuyrukları ayrı çerez kabı ve ayrı hız bütçesi kullanıyor.
• Çıkış ülkesi ve hedef sayfadaki ülke ya da para birimi, günlük örneklemle doğrulanıyor.
• Aylık GB tahmini ölçülen ortalama aktarımla hesaplandı ve yüzde 20 pay eklendi.
• Datacenter ile karşılaştırma yapıldı; residential yalnız eşiğin altında kalan ya da coğrafi doğruluk gerektiren iş kollarında kullanılıyor.
• Hedeflerin kullanım koşulları, robots.txt kuralları ve hız sınırları gözden geçirildi; kişisel veri toplanmıyor.