Web scraping kısıtlı mı? Parmak izi, IP engelleri, CAPTCHA'lar ve çoklu hesap girişi sorunlarını çözme

Bir scraping işi 403, 429, CAPTCHA veya sürekli tekrarlanan giriş hatalarıyla karşılaştığında doğru tepki IP döndürmek, parmak izlerini gizlemek ya da "gerçek bir insanı taklit etmeye" çalışmak değildir. Bu sinyaller genellikle istek sıklığının, erişim kapsamının, kimlik doğrulama yönteminin veya otomatik davranışın sitenin kabul ettiği sınırı aştığı anlamına gelir. Zorlamaya devam etmek kısıtlamayı büyütür ve hizmet şartlarını, sözleşmeleri, telif haklarını veya veri koruma kurallarını ihlal edebilir.

Daha kararlı bir yol, önce yetkilendirmeyi ve kullanılabilir arayüzleri doğrulamak, sonra trafiği azaltmak, gerekli yerlerde önbellek ve geri çekilme uygulamak ve tarayıcı otomasyonunu yalnızca JavaScript oluşturma veya insan girişi gerçekten gerektiren sayfalar için bırakmaktır. CAPTCHA'yı "aşılması gereken teknik bir engel" değil, "durma sinyali" olarak ele alın.

Belirtiden başlayıp nedeni daraltın

Belirti	Yaygın neden	Uyumlu tepki
429 Too Many Requests	İstekler çok hızlı, çok paralel veya tekrarlı	Hızı düşürün, Retry-After'a uyun, üstel geri çekilme kullanın
403 Forbidden	Yetkisiz yol, politika engeli, eksik oturum	Yetkileri, şartları, robots.txt ve kimlik doğrulama yöntemini kontrol edin
CAPTCHA çıkıyor	Site insan doğrulaması istiyor veya otomasyonu engelliyor	Görevi duraklatın, elle tamamlayın veya API isteyin
Giriş sürekli başarısız	Süresi dolmuş çerezler, üzerine yazılmış oturumlar, başarısız kimlik doğrulama	Resmi OAuth veya hizmet hesaplarını kullanın, oturum teslimini düzenleyin
Sayfada içerik var ama komut dosyası okuyamıyor	JavaScript oluşturma, API'nin eşzamansız yüklenmesi	Resmi API'yi kullanın; izinle tarayıcıda oluşturup DOM'u okuyun
Seçiciler aniden çalışmıyor	DOM yeniden tasarımı, A/B testi, dil değişikliği	Anlamsal konum belirleyiciler, yapısal testler ve uyarılar kullanın, sabit kodlanmış hiyerarşilerden kaçının
Yinelenen veya eksik veri	Sayfalama, imleçler, saat dilimleri, güncelleme penceresi hataları	Benzersiz anahtarlar, artımlı damga ve yeniden çalıştırma mekanizması kurun

Her seferinde yalnızca bir değişkeni değiştirin ve günlükleri tutun. Aynı anda IP, User-Agent, hesap ve parser'ı değiştirirseniz tesadüfen başarabilirsiniz, ama gerçekte neyin işe yaradığını ayırt edemezsiniz.

1. Adım: Bu verileri toplama hakkınız olduğunu doğrulayın

Başlamadan önce dört soruyu yanıtlayın:

1. Veriler herkese açık mı, yoksa yalnızca giriş, ödeme veya belirli roller için mi?
2. Site API, dışa aktarma, feed, webhook veya iş ortağı veri arayüzü sunuyor mu?
3. Hizmet şartları, robots.txt, sözleşmeler ve yerel yasalar öngörülen kullanıma izin veriyor mu?
4. Veriler kişisel bilgi, telifle korunan içerik veya başka hassas alanlar içeriyor mu?

robots.txt, bir sitenin otomatik istemcilere izin verdiği ve yasakladığı yolları bildirdiği standart mekanizmadır. RFC 9309, Robots Exclusion Protocol'ün sözdizimini ve eşleştirme kurallarını tanımlar ve robots.txt'nin bir erişim izni olmadığını açıkça belirtir. Başka bir deyişle, robots.txt'nin izin vermesi veriyi kopyalama, işleme veya ticari olarak kullanma hakkının tamamını size vermez; yasaklanmış yollara başka bir girişten ulaşılmamalıdır.

Kurumsal projeler veri kaynaklarını, erişim gerekçesini, amacı, alanları, saklama süresini ve silme mekanizmasını belgelemelidir. Toplu veriler işi çözüyorsa, kişileri tanımlayan bilgileri toplamaktan kaçının.

2. Adım: Kararlı veri giriş noktalarına öncelik verin

Olağan öncelik sırası şudur:

1. Resmi API'ler, webhook'lar veya veri dışa aktarımları;
2. Herkese açık feed'ler, site haritaları veya toplu dosyalar;
3. İzin alınmış sıradan HTTP sayfaları;
4. JavaScript gerçekten oluşturulması gerekiyorsa tarayıcı otomasyonu;
5. İnsan hesabı ve etkileşimi gerektiren sayfalar, en sonda.

API'ler genellikle alan tanımları, sayfalama, hız limitleri ve hata kodları sağlar; bu da bir kullanıcı arayüzünü ayrıştırmaktan daha ucuz bir bakım anlamına gelir. Web sayfası insan gözüne yönelik bir yüzeydir; her an değişebilir ve kararlı bir veritabanı gibi ele alınmamalıdır.

Sitede uygun bir arayüz yoksa, önce veri sahibiyle iletişime geçip amacı, sıklığı, alanları ve ticari ölçeği açıklayın. Net bir veri lisansı, kısıtlamalarla uzun bir mücadeleden genelde daha ucuzdur.

3. Adım: 429 ve IP engellerini kaynağı gizleyerek değil yükü azaltarak çözün

Hız ve eşzamanlılık tavanları belirleyin

Tek bir işçi ve geniş bir aralıkla başlayın, yanıt süresini ve hata oranını izleyin. Sunucu Retry-After döndürüyorsa tam o kadar bekleyin. Döndürmüyorsa, birden çok görev aynı anda yeniden denemesin diye üstel geri çekilme ile rastgele titreşim kullanın.

Basit bir politika:

bekle = min(tavan, taban × 2^deneme) + titreşim

Maksimum deneme sayısına ulaştığınızda durun ve uyarı verin. Sonsuz döngüye girmeyin.

Önbellek ve artımlı güncellemeler

Aynı URL'yi önbelleğe alın ve desteklenen yerlerde ETag veya Last-Modified ile koşullu istekler gönderin. Yalnızca yeni ve değişen içerikleri almak için son güncelleme zamanını veya bir imleci kaydedin. Tam alma görevini günlük artımlı görevden ayırmak istek hacmini belirgin şekilde düşürür.

İstemcinizi dürüstçe tanımlayın

Uyumlu bir tarayıcı, kararlı ve gerçek bir User-Agent kullanır, amacını belirtir ve bir iletişim sayfası veya e-posta sunar. Sıradan bir tarayıcıymış gibi görünmek ve sık sık kimlik değiştirmek sitenin iyi ile kötü trafiği ayırt etmesini zorlaştırır ve sonuçta engelleme olasılığını artırır.

Belirli bir IP kısıtlandıysa görevi duraklatın ve nedenini inceleyin. Erişimi sürdürmek için proxy döndürmeye devam etmek, erişim kontrollerini atlatmak olarak değerlendirilebilir, çözüm değildir.

4. Adım: Parmak izi ve davranış analiziyle başa çıkma

Tarayıcı parmak izi User-Agent, işletim sistemi, dil, saat dilimi, çözünürlük, Canvas ve WebGL gibi sinyalleri birleştirir. Site ayrıca istek ritmini, gezinme yollarını ve oturum davranışını da analiz edebilir. OWASP, Fingerprinting, Scraping, CAPTCHA Defeat, Credential Stuffing ve benzerlerini ayrı otomasyon tehdit kategorileri olarak listeler; bu da sitenin otomasyon riskini değerlendirirken neden birden çok sinyali birleştirdiğini açıklar.

Yetkili işlerde hedef, "insansı" kimlikler üretmek değil, ortamı kararlı ve açıklanabilir tutmaktır:

• aynı iş hesabı için sabit ortam ve normal kimlik doğrulama kullanın;
• tarayıcı parametrelerini gerçek bölge ve cihazla tutarlı tutun;
• engellerden kaçınmak için parmak izini rastgele değiştirmeyin;
• toplama sıklığını, görev kimliğini ve sorumlu kişiyi günlüklere yazın;
• site ile izin verilen hesap sayısı, eşzamanlılık ve veri kapsamı üzerinde anlaşın.

Site yetkili bir görevi yine de yanlış sınıflandırıyorsa, zaman damgalarını, User-Agent'ı, çıkış IP'sini ve örnek istekleri paylaşıp beyaz listeye alınmasını veya özel bir arayüz verilmesini isteyin.

5. Adım: CAPTCHA çıktığında otomasyonu durdurun

CAPTCHA bir insanı doğrulamak veya şüpheli otomasyonu engellemek içindir. OCR, CAPTCHA çözme hizmetleri, CAPTCHA kırma eklentileri ya da başka bir otomatik atlatma yöntemi kullanmayın.

Doğru akış:

1. mevcut hesabı ve görev kuyruğunu hemen duraklatın;
2. tetiklenmeden hemen önceki istek sıklığını, yolları ve hata günlüğünü kaydedin;
3. yetkili bir kişi gerekli doğrulamayı resmi sayfada yapar;
4. isteklerin çok hızlı mı, oturumun mu süresi dolmuş ya da izin verilmeyen bir yol mu kullanılmış kontrol edin;
5. uzun süreli otomasyon için siteden API, hizmet hesabı veya beyaz liste isteyin.

Bir insan bir kez CAPTCHA çözse bile bu, sonrasında sınırsız otomatik istek gönderme hakkı vermez. Önce tetikleyici nedeni giderin.

6. Adım: Giriş ve çoklu hesabı resmi izinlerle yönetin

Girişin arkasındaki veriler herkese açık sayfalardan daha hassastır. OAuth, hizmet hesapları, API belirteçleri veya platformun resmi ekibinin verdiği izinleri tercih edin. Bir komut dosyasının kişinin ana parolasını saklamasına izin vermeyin.

Tarayıcı oturumu gerçekten gerekli olduğunda:

• bir meşru iş hesabı, bir kararlı ortama eşlenir;
• çerezler şifreli, süre sonu ve iptal edilebilir biçimde saklanır;
• MFA'yı açın, otomasyon iki adımlı doğrulamayı atlatmamalıdır;
• birden çok kişinin aynı anda parola sıfırlamasını veya çerez kopyalamasını yasaklayın;
• kimin hangi görevi ne zaman başlattığını kaydedin;
• ayrılma, projenin bitmesi veya rol değişikliğinde erişimi hemen iptal edin.

Çoklu hesap yalnızca gerçekten sahip olduğunuz veya kullanımı için izin aldığınız hesaplar için geçerlidir. Site bir tüzel kişiliği tek hesapla sınırlandırıyorsa ortam izolasyonu bu sınırı aşmak için kullanılmamalıdır.

7. Adım: Dinamik sayfa ayrıştırmasını yeniden tasarımlara dayanıklı kılın

Anlamsal ve kararlı öznitelikler kullanın

Başlıkları, başlık etiketlerini, erişilebilirlik özniteliklerini ve sitenin yayımladığı test tanımlayıcılarını tercih edin. div:nth-child(7) gibi kırılgan hiyerarşilerden kaçının. Sayfa yenilendikten sonra DOM'u yeniden okuyun, eski düğümün hâlâ orada olduğunu varsaymayın.

Çıkarmayı iş mantığından ayırın

Toplama katmanı sayfayı yalnızca yapılandırılmış alanlara dönüştürür. Doğrulama katmanı türleri, aralıkları, benzersiz anahtarları ve zorunlu alanları denetler. Bu ayrım sayesinde yeniden tasarım yalnızca parser'ı etkiler, sonraki analiz bozulmaz.

Örnekler ve uyarılar oluşturun

Uyacak şekilde az sayıda HTML veya yapısal anlık görüntüyü test örneği olarak saklayın. Tam hesap sayfalarını veya hassas verileri saklamayın. Eksik alan oranını, kayıt sayısını, çift kayıt oranını ve sayfa başlıklarını izleyin; sapma olduğunda üretim verisine yazmayı durdurun.

Yetkili scraping'de PurpleMark'ın uygun rolü

Ekip aynı anda birden çok yetkili hesabı, farklı müşteri ortamlarını veya farklı bölgeleri sürdürmek zorunda olduğunda, PurpleMark web app içinde her iş hesabı için bağımsız bir tarayıcı ortamı oluşturabilir, ilgili çerezleri, giriş sonrası varsayılan olarak açılacak sayfayı ve olağan ağ yapılandırmasını birlikte saklayabilir. Ortam yeniden açıldığında tarayıcı son oturuma ve çalışma sayfasına döner; böylece birden çok kişi aynı çerez kümesini paylaşmaz ve her seferinde yeniden giriş yapmak gerekmez.

Hesapların müşteriye, platforma veya bölgeye göre ayrılması gerektiğinde ortam grupları iş hesaplarını farklı klasörlerde toplamanıza olanak tanır; üye izinleri, paylaşım ve devir kimin hangi ortamı açabileceğini belirler. İşlem günlüğü her ortamın ne zaman ve kim tarafından açıldığını ya da değiştirildiğini kaydeder. Yetkili bir scraping hakkında soru çıktığında belirli bir hesaba ve belirlenmiş bir sorumluya hızla ulaşılabilir.

PurpleMark ekibin "hesapları, ortamları, oturumları ve sorumluluğu" uzun süre tek bir çalışma alanında yönetmesine yardımcı olur, ancak IP engellerini, CAPTCHA'ları, hesap sayısı sınırlarını veya bir sitenin otomasyon karşıtı savunmasını atlatmak için tasarlanmamıştır. Önce izin alın, sonra otomasyondan söz edin.

Bakımı kolay bir scraping mimarisi

Beş katmanlı yararlı bir ayrım:

1. Planlama: sıklığı, eşzamanlılığı, görev önceliğini ve duraklamayı yönetir;
2. Erişim: API, HTTP veya yetkili tarayıcı oturumu;
3. Ayrıştırma: yanıtları yapılandırılmış alanlara dönüştürür;
4. Kalite: tekilleştirme, tür denetimi, eksik alan uyarıları, sürüm kaydı;
5. Yönetişim: izinler, kaynak, amaç, saklama süresi, silme.

Her kayıt kaynak URL'sini, toplama zamanını ve parser sürümünü saklar. Bir hata olduğunda, tüm siteyi yeniden taramak yerine etkilenen kayıtları hedefleyip yeniden çalıştırabilirsiniz.

Sık sorulan sorular

Proxy döndürmek bir IP engelini çözer mi?

Çıkış adresini bir süre değiştirebilir, ama sıklık, izin ve davranış sorununu çözmez. Erişimi sürdürmek için proxy döndürmek atlatma sayılabilir. Önce görevi durdurun, istekleri azaltın ve siteyle iletişime geçin.

CAPTCHA otomatik çözülebilir mi?

Hayır. CAPTCHA durma veya bir insanı devreye alma sinyalidir. Sürekli otomasyon için API, hizmet hesabı veya beyaz liste isteyin.

robots.txt izin veriyorsa her zaman scraping yapabilir miyim?

Zorunlu olarak değil. robots.txt erişim izni değildir; şartlar, telif hakkı, gizlilik, sözleşmeler ve verilerin kullanım amacı da dikkate alınmalıdır.

Parmak izi gizleyen tarayıcı scraping'i "görünmez" kılar mı?

Bunu garanti etmek mümkün değil ve bu bir hedef olmamalı. Asıl uygun kullanım, meşru hesap oturumlarını ve ekip izinlerini ayırmak, çerez karışıklıklarını ve kullanım hatalarını azaltmaktır.

Kapanış

Web scraping kısıtlamaları sadece "bot karşıtı teknik bir sorun" değildir. 403, 429, parmak izi, CAPTCHA'lar ve çoklu hesap sınırları hep birlikte izin, yük ve kimlik yönetimine işaret eder.

Kararlı bir yaklaşım her zaman API'yi önceliklendirmeye, net yetkilendirmeye, ölçülü isteklere, artımlı önbelleğe, test edilebilir ayrıştırmaya ve denetlenebilir hesaplara döner. CAPTCHA veya engel çıktığında otomasyonun kaynağını gizlemeye devam etmek yerine süreci durdurup düzeltin.