Korumalı sitelerde residential proxy ile web scraping

Bir hedef site isteği değerlendirirken yalnızca içeriğe bakmaz; isteğin hangi ağdan geldiğine de bakar. Bulut veya veri merkezi bloklarından, yani belirli ASN’lerden gelen trafik, birçok sitede “insan ziyaretçi” varsayımının dışında kalır; bazı hedefler bu ağ bloklarını baştan kısıtlar. Bu yüzden aynı betik aynı hızda ve aynı başlıklarla çalışsa bile ev bağlantısı üzerinden gelen istek ile veri merkezinden gelen istek farklı karşılanabilir. Residential proxy ile web scraping bu farkı kapatmaya yarar: istek, gerçek bir internet servis sağlayıcısının abonesine ait adres üzerinden çıkar ve hedef siteye sıradan bir bağlantı gibi görünür.

Bu cümlenin kritik kısmı “görünür” kelimesidir. Çıkış kimliği, kuralları değiştirmez. Hedefin kullanım koşulları, robots.txt dosyası ve hız sınırları aynen geçerlidir. Residential çıkışın tek işi, meşru ve izinli bir veri toplama işinin yalnızca ağ türü yüzünden reddedilmesini engellemektir. ResidentialProxy bu çerçevede, korumalı hedeflerde erişim, yerel sonuçlar ve hesap-oturum güvenilirliği gerektiren işler için konumlanır.

Sayfanın geri kalanı şu sorulara cevap verir: Hedefin tepkisi gerçekten ağ kaynaklı mı? Hangi belirtiler yumuşak engele işaret eder? İstek hızını hangi mantıkla seçmeli? GB kotası nasıl hesaplanır? Oturum isteyen akışta neden static gerekir? Hangi noktada durup hedef sahibiyle konuşmak gerekir? Ürün sayfasındaki paket kartlarını ve genel özellik listesini tekrar etmiyoruz; burada karar mantığı ve hesap var.

Sert engel kolay fark edilir: 403 ya da 429 kodu, “erişim reddedildi” sayfası. Asıl sorun yumuşak engeldir. İstek 200 koduyla döner, boru hattınız hata görmez, ama gelen sayfa gerçek içerik değildir. Aylarca eksik veriyle çalışıp bunu fark etmeyen ekipler az değildir. Bu yüzden her yanıtı yalnızca durum koduna göre değil, içeriğin beklenen yapıya uyup uymadığına göre sınıflandırmak gerekir.

Tabloyu bir karar ağacı gibi değil, bir uyarı sözlüğü gibi kullanın. Tek bir belirti kesin sonuç vermez; ama üç belirtinin aynı anda görülmesi, çıkış ağı değiştirmekten önce hızınızı ve davranışınızı sorgulamanız gerektiğini gösterir. Residential çıkış, datacenter reddini çözebilir; fakat siz hedefin kaldırabileceğinden hızlı gidiyorsanız residential adres de aynı sonucu görür.

Residential pakete geçmeden önce sorunun gerçekten ağ kaynaklı olduğunu doğrulayın. Aksi halde GB harcar, sorunu çözmeden bütçeyi büyütürsünüz. Aşağıdaki sıra, en ucuz kontrolden en pahalıya doğru ilerler.

1. 01Hedefin robots.txt dosyasını ve kullanım koşullarını okuyun. Otomatik erişim açıkça yasaksa burada durun; teknik çözüm aramak anlamsızdır.
2. 02Resmi bir API, veri akışı veya toplu indirme seçeneği olup olmadığına bakın. Varsa scraping yerine onu kullanmak hem daha ucuz hem daha güvenlidir.
3. 03Tek bir sayfayı normal tarayıcıdan, kendi bağlantınızla açın ve içeriği not edin. Bu, “doğru cevap neye benziyor” sorusunun referansıdır.
4. 04Aynı sayfayı veri merkezi çıkışından düşük hızla, tek istekle deneyin. Referansla aynı içerik geliyorsa sorun ağ türü değil, hacim veya davranıştır.
5. 05Aynı tek isteği residential çıkıştan, hedefin beklediği ülkeden deneyin ve yanıtı referansla karşılaştırın. Fark yalnızca burada kapanıyorsa ağ türü gerçekten belirleyicidir.
6. 06Farkı yazıya dökün: hangi URL, hangi ülke, hangi çıkış, hangi yanıt boyutu. Bu not hem karar kaydınız hem de ileride hata ayıklarken ilk başvurunuzdur.

Beşinci adımda fark kapanmıyorsa residential çıkış sorununuzu çözmüyor demektir. Bu durumda genellikle üç neden vardır: hız çok yüksek, istek başlıkları ve davranış tutarsız ya da içerik oturum veya bölge koşuluna bağlı. Üçüncüsü için ülke seçimi ve static IP bölümlerine geçin.

Hız sınırı, hedef sitenin size söylediği en açık cümledir. Hedefler bunu bazen Retry-After başlığıyla, bazen robots.txt içindeki Crawl-delay yönergesiyle, bazen de yalnızca yavaşlayan yanıtlarla bildirir. Saygılı bir plan, bu sinyalleri okur ve ona göre geri çekilir. Rotating çıkış size çok sayıda adres verir; ama hedefin sunucusunun kapasitesi adres sayısıyla büyümez. Aynı siteye saniyede yüzlerce istek göndermek, hangi IP’den çıkarsa çıksın hedefe yük bindirir.

Planın iki değişkeni vardır: eşzamanlılık ve aralık. Eşzamanlılığı hedef başına sınırlayın, toplam sınırı ayrıca tutun; böylece birden fazla hedefi paralel tararken hiçbirine fazla yüklenmezsiniz. Aralığı sabit bir taban olarak seçin; amaç fark edilmemek değil, ani yük yığılmalarından kaçınmaktır. Aşağıdaki iskelet, robots.txt kontrolü, Retry-After saygısı ve indirilen bayt sayacı içerir. Bağlantı bilgileri yer tutucudur; gerçek değerleri panelden alın.

import time
import urllib.robotparser
import requests

PROXY = 'http://KULLANICI:ŞİFRE@GATEWAY:PORT'
PROXIES = {'http': PROXY, 'https': PROXY}
UA = 'ornek-veri-toplayici/1.0 (iletisim: [email protected])'
ARALIK_SN = 4.0          # varsayım: hedef başına istekler arası taban süre
MAKS_DENEME = 3

rp = urllib.robotparser.RobotFileParser()
rp.set_url('HEDEF_URL/robots.txt')
rp.read()

toplam_bayt = 0

def getir(url):
    global toplam_bayt
    if not rp.can_fetch(UA, url):
        return None                      # robots.txt izin vermiyorsa istek atılmaz
    for deneme in range(MAKS_DENEME):
        r = requests.get(url, proxies=PROXIES, headers={'User-Agent': UA}, timeout=30)
        toplam_bayt += len(r.content)    # yaklaşık bayt sayacı; kesin kota tüketimi için paneli esas alın
        if r.status_code == 200:
            return r.text
        if r.status_code in (429, 503):
            bekle = r.headers.get('Retry-After', '')
            bekle = int(bekle) if bekle.isdigit() else 30 * (deneme + 1)
            time.sleep(bekle)            # hedef yavaşlamamızı istiyor
            continue
        return None                      # 403, 404 gibi kodlarda yeniden deneme yok
    return None

for sayfa in ['HEDEF_URL/kategori/1', 'HEDEF_URL/kategori/2']:
    icerik = getir(sayfa)
    time.sleep(ARALIK_SN)

print('Toplam indirilen bayt:', toplam_bayt)

Rotating IPv4 residential paketleri katalogda GB bazlı ve tek seferlik olarak yayınlanır. Bu, maliyetin istek sayısına değil aktarılan veri miktarına bağlı olduğu anlamına gelir. Bir ürün sayfası tarayıcıda 3 MB görünse bile, yalnızca HTML’i indiren bir betik çok daha azını harcar. Başarısız denemelerin ve yönlendirmelerin kotadan nasıl düşüldüğünü katalog belirtmez; bunu pilot sırasında panelden doğrulayın ve hesabı temkinli yapın. Hesabı yanıt başına ölçülen gerçek bayt üzerinden yapın, tahmin üzerinden değil.

Tabloya bakınca 2 GB’lık paket dışında GB başına maliyetin sabit olduğunu görürsünüz. Bu, “büyük paket alırsam indirim kazanırım” beklentisini ortadan kaldırır ve karar kriterini sadeleştirir: ihtiyacınızı doğru tahmin edin, gereksiz kota satın almayın. Bayt tüketimini düşürmenin yolları ise tamamen sizin tarafınızdadır: yalnızca gerekli sayfaları çekmek, görsel ve betik dosyalarını istememek, değişmeyen sayfaları atlamak ve yeniden denemeleri sınırlamak.

Her iş her istekte yeni adres istemez. Giriş yapılmış bir panelden rapor çekmek, sepeti birkaç adım boyunca takip etmek veya hesaba bağlı bir listeyi sayfa sayfa gezmek, oturum boyunca aynı çıkış adresini gerektirir. Adres oturumun ortasında değişirse hedef bunu şüpheli bir oturum değişikliği olarak değerlendirebilir ve oturumu sonlandırabilir. Bu tür işlerde rotating havuz yanlış araçtır.

Katalogda rotating IPv4 ürününün özellikleri arasında sticky veya rotating oturum senaryolarına uyum yazıyor. Sticky davranışın ayrıntıları, yani süresi ve nasıl seçildiği, ürün sayfasında yer almıyor; sipariş adımında ve panelde kontrol edin, varsayımla plan yapmayın. Oturumun saatlerce veya günlerce aynı adreste kalması gerekiyorsa static ürün daha öngörülebilirdir.

Static ürünler aylık adet bazlı satıldığı için bütçe hesabı farklıdır: Türkiye lokasyonunda 1 adet 2,25 USD, 10 adet 22,50 USD aylıktır. Diğer ülkelerde katalogdaki başlangıç paketi 5 adet 17,50 USD’dir; ABD ve Almanya için 10 adet 34 USD, 50 adet 170 USD, 100 adet 340 USD olarak yayınlanır. Bu fiyatlar paket başına aylık maliyeti verir; GB hesabı yapmanız gerekmez. Trafik veya bağlantı sınırları katalogda belirtilmediği için bunları sipariş adımında kontrol edin.

ResidentialProxy kataloğu dört aileden oluşur. Hangisinin hangi işe uyduğunu, hedefin tepkisine ve faturalama biçimine bakarak seçin. Aşağıdaki tablo yalnızca katalogdaki bilgileri ve bunlardan türetilmiş sonuçları içerir; teknik ayrıntılar için sipariş adımını ve paneli kontrol edin.

Port bazlı modelin matematiği farklıdır. Rotating IPv6’da 1 port 29 USD, 5 port 80 USD, yani port başına 16 USD; 10 portta 175 USD, port başına 17,50 USD. Burada 5 port, 10 porttan port başına daha ucuzdur. GB bazlı rotating IPv4 ile karşılaştırırken aktarım hacmini port sayısına çevirmeniz gerekir; bu çeviri hedefin IPv6 desteğine ve eşzamanlılık beklentinize bağlıdır, bu yüzden pilot ölçüm olmadan karar vermeyin.

Varsayalım bir ekip, üç ülkedeki bir ilan platformunun herkese açık kategori sayfalarını haftada bir izliyor ve platformun robots.txt dosyası bu yolları taramaya izin veriyor. Aşağıdaki rakamlar tamamen varsayımdır; amacı hesap yöntemini göstermektir. Kendi hedefinizde ölçtüğünüz değerlerle değiştirin.

Aynı işi sayfaların tamamını görsel ve betikle indirerek yapsaydınız (varsayım olarak sayfa başına 3 MB), haftalık veri 120 GB, aylık 480 GB olurdu. GB başına 1,20 USD ile bu hacim yaklaşık 576 USD’ye karşılık gelir. Aradaki fark, sadece gerekli baytı çekmenin ne kadar belirleyici olduğunu gösterir. Ayrıca bu senaryoda çalışmayı hedefin sakin saatlerine yaymak, hem yanıt süresini hem de hatalı yanıt oranını iyileştirir.

Oturumlu bir iş eklerseniz tablo değişir. Örneğin hesaba bağlı bir panelden günlük rapor çekmek için Türkiye lokasyonunda 3 static adres gerekiyorsa, 1 adetlik paketten üç tane almak aylık 3 x 2,25 = 6,75 USD eder (alternatif olarak 5 adetlik paket 11,25 USD) ve GB hesabı bu kalemde devreye girmez. İki yaklaşımı aynı bütçe tablosunda göstermek, ekip içinde “neden bu işe rotating, şuna static” tartışmasını kısaltır.

Teknik olarak mümkün olan her şey hukuken ve sözleşme açısından uygun değildir. Scraping işine başlamadan önce üç belgeyi okuyun: hedefin kullanım koşulları, robots.txt dosyası ve varsa API şartları. Kullanım koşulları otomatik erişimi yasaklıyorsa, residential çıkış bu yasağı kaldırmaz; yalnızca ihlalin teknik olarak fark edilmesini zorlaştırır. Bu tür bir kullanımı biz de desteklemiyoruz.

Kişisel veri ayrı bir başlıktır. Kişileri tanımlayabilen veriyi, yani ad, e-posta, telefon, profil içeriği gibi alanları toplamak; Türkiye’de KVKK, Avrupa’da GDPR kapsamında ayrı yükümlülükler doğurur. Veri sorumlusu sizseniz hukuki dayanak, saklama süresi ve aydınlatma gibi konuları işin başında netleştirin. Fiyat, stok, kategori sayısı, kamuya açık yayın tarihi gibi kişisel olmayan alanlarla çalışmak bu açıdan çok daha sadedir.

Giriş yapılmış alanlar da dikkat ister. Hesabın sahibi sizseniz ve koşullar izin veriyorsa kendi verinizi çekebilirsiniz. Başkasının hesabına izinsiz girmek, yetkisiz erişim kapsamındadır. İşiniz bir şirket adına yapılıyorsa hukuk veya uyum ekibinin bu çerçeveyi önceden onaylaması, sonradan düzeltmeye göre çok ucuzdur.

Her hatayı aynı şekilde yeniden denemek en sık yapılan hatadır. 407 yeniden denemeyle düzelmez; kimlik bilgisi sorunudur. 429 hemen yeniden denemeyle daha da kötüleşir; beklemek gerekir. Zaman aşımı birkaç kez denenebilir ama sınırsız değil. Hata sınıfına göre ayrı davranış tanımlamak, hem kotayı hem hedefin sabrını korur.

Pilot, harcamanın ve riskin küçük kaldığı dönemdir. Amaç tam ölçekli veri toplamak değil, hedefin tepkisini ve gerçek bayt maliyetini öğrenmektir. Aşağıdaki sıra ilk on günü kapsar ve her adımın bir çıktısı vardır.

1. 01Gün 1: Hedefin robots.txt ve kullanım koşullarını okuyun, sonucu kısa bir izin notuna yazın.
2. 02Gün 2: Referans sayfaları elle belirleyin: beklenen alanlar, yaklaşık boyut, ülke farkı.
3. 03Gün 3: 2 GB’lık paketle (2,50 USD) tek akışlı, düşük hızlı bir deneme çalıştırın; her yanıtın boyutunu ve durum kodunu kaydedin.
4. 04Gün 4: Kayıtları inceleyin: boş yanıt oranı, yanıt süresi dağılımı, ortalama bayt.
5. 05Gün 5: Yumuşak engel belirtisi varsa hızı düşürün ve aynı denemeyi tekrarlayın.
6. 06Gün 6: Oturumlu akış varsa static bir adresle ayrı bir deneme yapın.
7. 07Gün 7: Ölçülen ortalama bayttan aylık kota tahmini çıkarın ve yeniden deneme payını ekleyin.
8. 08Gün 8: Gerekli paketi seçin: GB için 10, 20, 50 veya 100 GB; oturumlu iş için static adet.
9. 09Gün 9: Alarm kurallarını yazın: yanıt boyutu eşiği, 429 oranı, kalan kota.
10. 10Gün 10: Üretim çalışmasını küçük bir hedef alt kümesiyle başlatın ve ilk haftanın kayıtlarını gözden geçirin.

Pilotun sonunda iki sayı elinizde olmalı: hedef başına sürdürülebilir hız ve sayfa başına gerçek bayt. İkisini de yazılı tutun; hedefte bir değişiklik olduğunda bu kayıtlar karşılaştırma noktanız olur.

Üçüncü günde tek bir sayfayı komut satırından denemek, betik yazmadan önce çıkışın çalıştığını doğrular. Aşağıdaki örnekte yalnızca yanıt kodunu, indirilen boyutu ve toplam süreyi yazdırıyoruz; böylece hem bağlantıyı hem de sayfa başına bayt değerini aynı komutla görürsünüz. Çıkış adresini görmek için panelde belirtilen yöntemi kullanın.

curl -s -o /dev/null \
  -x http://KULLANICI:ŞİFRE@GATEWAY:PORT \
  -A 'ornek-veri-toplayici/1.0 (iletisim: [email protected])' \
  -w 'kod=%{http_code} bayt=%{size_download} sure=%{time_total}\n' \
  HEDEF_URL/kategori/1

Aynı komutu proxy olmadan (kendi bağlantınızla ya da veri merkezi çıkışınızla) ve residential çıkışla birer kez çalıştırın, iki satırı karşılaştırın. Bayt değeri belirgin biçimde farklıysa, ağ türünün hedefin cevabını değiştirdiğine dair güçlü bir işarettir; farklı değilse residential pakete para harcamanın gerekçesi zayıftır.

• —Hedefin robots.txt ve kullanım koşulları okundu; otomatik erişim yasaklı değil.
• —Resmi API veya veri akışı seçeneği araştırıldı ve gerekçesi kaydedildi.
• —Kişisel veri toplanıyorsa KVKK/GDPR dayanağı ve saklama süresi belirlendi.
• —User-Agent işinizi ve iletişim adresinizi içeriyor.
• —Hedef başına eşzamanlılık ve istekler arası süre tanımlı; Retry-After ve Crawl-delay okunuyor.
• —Yanıtlar durum koduna ek olarak boyut ve beklenen alanlarla doğrulanıyor.
• —Başarısız istekler dahil bayt tüketimi loglanıyor ve kalan kota için alarm var.
• —Hata sınıflarına göre ayrı yeniden deneme kuralı uygulanıyor; 407 ve 403 sonsuz denenmiyor.
• —Oturumlu akışlar static adresle, herkese açık sayfalar rotating çıkışla ayrılmış.
• —IPv6 ürün düşünülüyorsa hedefin IPv6 desteği tek istekle doğrulandı.
• —Ülke seçimi, verinin beklenen pazarla eşleştiği kontrol edilerek yapıldı.
• —Hedef sahibinden gelebilecek bir durdurma talebine cevap verecek bir sorumlu belirlendi.

Liste kısa görünse de her madde bir kararı temsil eder. Özellikle ilk ikisi, geri kalan her şeyin zeminidir: izin yoksa ya da resmi bir yol varsa ileri adımların anlamı kalmaz. Hazır olduğunuzda katalogdaki paketleri ürün sayfalarından inceleyebilir, bağlantı ayrıntılarını panelden doğrulayabilirsiniz.