Bloga geri dön

Firecrawl, Crawl4AI ve Crawlee için Proxy: Engeller Olmadan RAG İçin Veri Toplama

Firecrawl, Crawl4AI ve Crawlee varsayılan olarak sunucunuzun IP'si ile çalışır ve sayfayı tamamen çeker — markdown'da yer almayacak olan resimlerle birlikte. Her bir araçta proxy'nin nasıl ayarlandığını, çok katmanlı yükseltmenin (doğrudan istek → veri merkezi → yerleşik) nasıl etkinleştirileceğini ve RAG için gövde toplamanın gigabayt faturalarına dönüşmemesi için medya trafiğinin nasıl kesileceğini inceliyoruz.

📅22 Ağustos 2026
Firecrawl, Crawl4AI ve Crawlee için Proxy: Engeller Olmadan RAG İçin Veri Toplama
```html

“Firecrawl’ı Docker’da başlattım, bir alanlar listesine yönlendirdim, RAG için markdown aldım” şeması, tam olarak ilk bin sayfaya kadar çalışıyor. Sonrasında iki fatura geliyor. Birincisi — anti-botlardan: bazı alanlar içerik yerine 403 döndürmeye başlıyor ve bilgi asistanı “sağlanan materyallerde bilgi yok” dediğinde, bilgi tabanında boşluklar ortaya çıkıyor. İkinci fatura — trafik için: tarayıcı her resmi ve her yazı tipini titizlikle çekiyor, ama sonuçta bu içerikler nihai markdown’a dahil edilmiyor.

2026 yılının en popüler üç LLM tarayıcısına — Firecrawl, Crawl4AI ve Crawlee — proxy nasıl bağlanır ve proxy’nin yalnızca gerektiği yerlerde çalışacak şekilde nasıl ayarlanacağına bakalım, böylece her sayfada gigabaytlar harcamayalım.

Bu kılavuz kimler için

Eğer RAG için bir belge koleksiyonu topluyorsanız, iç bilgi tabanınızı dolduruyorsanız, yeniden eğitim için bir veri boru hattı oluşturuyorsanız ya da düzenli olarak yüzlerce alan indiriyorsanız — bu sizin durumunuz. Aşağıdaki üç aracın varsayılan yapılandırması, sunucunuzun IP’si ile çalışır ve sayfayı tamamen yükler. Bu iki varsayılan ayarı değiştirmek gerekir.

Problemin ölçeği, popülarite rakamlarıyla anlaşılabilir: Firecrawl, yayınlandığı sırada GitHub’da yaklaşık 170 bin yıldız almış (lisans AGPL-3.0), Crawl4AI yaklaşık 79 bin, Apify’den Crawlee ise yaklaşık 25 bin. Artık bunlar niş deneyler değil, standart araçlar ve anti-bot sistemleri onların davranışlarını sizin kadar iyi biliyor.

Birinci fatura: içerik yerine 403

Belge koleksiyonu toplarken yapılan temel hata, tarayıcının başarılı bir şekilde çalıştığını düşünmektir, eğer çökmediyse. Firecrawl ve Crawl4AI, engellenmiş bir sayfada bir istisna değil, bir sonuç döndürür: anti-botun bir geçici sayfası, bir tarayıcı kontrol sayfası veya erişim reddi hakkında kısa bir metin. Resmi olarak bu geçerli bir markdown’dur, rahatlıkla vektör veri tabanına yerleştirilir ve kullanıcıdan gelen ilk isteğe kadar orada kalır.

Bu nedenle, proxy ayarlarından önce yapmanız gereken ilk şey, sonuçların kalite kontrolünü eklemektir. En basit versiyon: belirli bir eşiğin altındaki belgeleri ayıklamak (tipik bir içerik sayfası için makul olan 500–800 karakter metin) ve metinde belirgin işaretleri ayrı olarak yakalamak — bağlantı kontrolü, etkin JavaScript, “Erişim reddedildi” gibi. Bu tür belgeler veri tabanına değil, yeniden tarama kuyruğuna gönderilir — zaten proxy üzerinden.

İkinci fatura: attığınız gigabaytlar

Burada aritmetik işe yarar. 2025 yılı için HTTP Archive’dan alınan Web Almanac verilerine göre, medyan ana sayfa masaüstünde yaklaşık 2,86 MB ve mobilde 2,56 MB ağırlığındadır. Bunların yaklaşık 1.059 KB’si ana sayfalardaki görüntülere ve 911 KB’si iç sayfalardaki görüntülere aittir; JavaScript için ise sırasıyla 697 KB ve 632 KB’dir. Yani resimler, sayfanın ağırlığının yaklaşık üçte birini oluşturan en ağır kategoridir.

Şimdi sonuçla ne yaptığınızı hatırlayın. Sayfayı markdown’a dönüştürüyorsunuz ve gömme işlemleri için parçalara ayırıyorsunuz. Resimler bu boru hattına hiç girmiyor — en iyi ihtimalle sadece alt metinle bir satır kalıyor. Videolar, yazı tipleri, analitik betikler, reklam pikselleri — hepsi dışarıda kalıyor.

Eğer bir konut proxy’si üzerinden gigabayt başına ödeme yaparak tarama yapıyorsanız, aslında bir sonraki adımda attığınız verilerin teslimatı için ödeme yapıyorsunuz. 100 bin sayfalık bir koleksiyonda “her şeyi çekmek” ile “sadece HTML ve metni çekmek” arasındaki fark, yüzdelerle değil, katlarla ölçülür. Kesin tasarruf, sitelerin konusuna bağlıdır: medya ve e-ticaret, belgeler ve bloglardan daha ağırdır.

Adım 1. “Her şey için proxy” yerine yükseltme

En çok tasarruf sağlayan ana mimari teknik: tüm trafiği proxy üzerinden geçirmemek. Bilgi tabanı toplarken çoğu alan — belgeler, bloglar, referans siteleri, devlet portalları — içeriği doğrudan sunar ve kimseyi engellemez. Proxy, azınlığa ihtiyaç duyar.

Doğru şema, çok katmanlı bir yükseltmedir: önce doğrudan bir istek, engelleme belirtileri varsa — bir sonraki katmana geçiş. Bu, kendi yazdığınız bir geçici çözüm değil, her iki büyük çerçeve de bunu kutudan çıkar çıkmaz yapabiliyor.

Crawlee’de bunun için tieredProxyUrls vardır. Katmanlar, ucuzdan pahalıya doğru sıralanır ve tarayıcı, engellemeler olduğunda kendiliğinden yukarı çıkar, ardından periyodik olarak alt katmana geri dönmeyi dener:

const proxyConfiguration = new ProxyConfiguration({
    tieredProxyUrls: [
        [null],
        ['http://user:pass@datacenter-proxy:8080'],
        ['http://user:pass@residential-proxy:8000'],
    ]
});

Belgelerden önemli bir not: tieredProxyUrls, yalnızca tarayıcı örneği üzerinden kullanıldığında çalışır. Doğrudan newUrl() çağrıları beklenmedik bir sonuç verecektir.

Crawl4AI’de benzer bir mekanizma 0.8.5 sürümünde ortaya çıktı ve güncel dalda yaşamaktadır (yayınlandığı sırada son sürüm — 15 Temmuz 2026 tarihli v0.9.2). Buna proxy escalation denir ve CrawlerRunConfig içinde doğrudan ayarlanır: üç katmanlı engelleme tespiti — bilinen anti-bot satıcıları, genel engelleme göstergeleri ve sayfanın yapısal bütünlüğünün kontrolü — artı otomatik yeniden deneme zinciri üzerinden proxy.

from crawl4ai import CrawlerRunConfig
from crawl4ai.async_configs import ProxyConfig

config = CrawlerRunConfig(
    proxy_config=[ProxyConfig.DIRECT, ProxyConfig(server="http://my-proxy:8080")],
    max_retries=2,
)

İlk öğe olarak ProxyConfig.DIRECT’e dikkat edin — bu, “önce proxy olmadan dene” demektir.

Adım 2. Her araçta proxy bağlantısı

Sonraki adımlar ayarlarla ilgili. İşlem sırası aynıdır: önce proxy, sonra gereksiz trafiği kesmek, ardından kontrol.

  1. Firecrawl (kendinize ait). Proxy, Playwright’a geçirilen üç ortam değişkeni ile belirlenir: PROXY_SERVER, PROXY_USERNAME, PROXY_PASSWORD. Bunlar .env dosyasına apps/api için yazılır; geliştiriciler, statik bir adres yerine her istekte IP’yi döndüren bir proxy hizmeti belirtilebileceğini açıkça yazarlar.
  2. Crawl4AI. Proxy, BrowserConfig içinde yaşar, proxy_config alanında — bu bir ProxyConfig nesnesi veya server, username, password alanlarına sahip bir sözlüktür. Tek bir tarayıcı yapılandırması, tüm tarama oturumu için geçerlidir; her arun() çağrısında ayrı bir CrawlerRunConfig geçirilir.
  3. Crawlee. ProxyConfiguration sınıfı, proxyUrls seçeneği ile — kütüphanenin döngüsel olarak gittiği adresler listesi (round-robin). Listede null değeri, “proxy olmadan” anlamına gelir. Entegre sistem: HttpCrawler, CheerioCrawler, JSDOMCrawler, PlaywrightCrawler, PuppeteerCrawler.
  4. Hedefe özel kurallar. Hangi alanların engellediği ve hangilerinin engellemediği biliniyorsa, Crawlee’de newUrlFunction vardır — istek URL’sine dayalı olarak proxy seçme mantığı. Beyaz alanlar için null döndürüyorsunuz, diğerleri için — proxy adresi. Bu, hedef listesi sabit olduğunda en ucuz seçenektir.
  5. Kontrol. Savaş öncesi, ayarlanmış tarayıcıdan dış IP’nizi döndüren bir sayfayı geçirin ve proxy adresini, sunucu adresi yerine gördüğünüzden emin olun. Üç satır, bir gün boyunca sorun çözmenizi tasarruf ettirir.

Adım 3. Metin olmayan her şeyi kesmek

Proxy bağlandığında, trafik tasarrufunu etkinleştirin — aksi takdirde gigabayt faturası, koleksiyon toplanmadan daha hızlı gelir.

Firecrawl’da bunun için BLOCK_MEDIA değişkeni sorumludur. Resmi yapılandırma örneğinde, bunun için bir yorum vardır: medya isteklerini engellemek istiyorsanız, proxy bant genişliğini tasarruf etmek için ayarlayın. Bu, ana maliyet kalemini kaldırmanın en hızlı yoludur.

Crawl4AI’de benzer kontroller BrowserConfig içinde bulunur: text_mode resimleri kapatır ve metin taramasını hızlandırır, light_mode tarayıcının bazı arka plan işlevlerini kapatır, avoid_css CSS yüklemesini engeller. Bunları birleştirebilirsiniz. RAG için bir koleksiyon toplarken bu neredeyse her zaman doğru bir settir — tasarımınıza ihtiyacınız yok, metne ihtiyacınız var.

Crawlee’de mantık farklıdır: içerik HTML olarak sunuluyorsa, tarayıcı tabanlı olanlar yerine CheerioCrawler veya HttpCrawler kullanın. Tam bir render yerine normal bir HTTP isteği — bu sadece trafik tasarrufu değil, aynı zamanda harcama sırasını da değiştirir. Tarayıcı tabanlı tarayıcıları (PlaywrightCrawler, PuppeteerCrawler) yalnızca JavaScript olmadan toplanamayan sayfalar için bırakın.

Tuzağa düşme noktaları

Oturumlar karşı rotasyon. Her istekte IP değişikliği, kendiliğinden şüpheli görünür ve çok aşamalı senaryoları bozar — sayfa numaralandırması, bir alan içinde geçişler. Crawlee’de her newUrl() çağrısı, proxy’yi Session nesnesi ile bağlar ve bunlar tarayıcı parmak izleri ve başlıklarla birlikte döner. Bu bağı manuel olarak koparmayın.

Medya kapalı, ama içerik kayboldu. Bazı siteler, tembel yükleme ile yalnızca resimleri değil, metni de çekiyor. text_mode veya BLOCK_MEDIA etkinleştirildikten sonra, 20–30 sayfadan oluşan bir kontrol örneğini geçirin ve metin miktarını standartla karşılaştırın.

Sınırsız yeniden denemeler. Proxy katmanları arasında yükselmek, inatçı bir sayfanın üç kez indirilmesi anlamına gelebilir — ve bu üç kez de ödenir. max_retries değerini sınırlayın ve N başarısızlıktan sonra taramadan tamamen çıkarılacak alanların bir listesini oluşturun.

Robots.txt ve yasal çerçeve. 2026 yılında eğitim ve RAG için veri toplama, birkaç yıl öncesine göre daha sıkı bir şekilde düzenlenmektedir — kaynakların açıklanması gerekliliklerinden, metin ve veri madenciliğinden vazgeçme mekanizmalarına kadar. Boru hattınızın bu sinyallere saygı gösterdiğinden emin olun, yüz binlerce sayfa üzerinde çalışmadan önce.

RAG boru hattı için hangi tür proxy alınmalı

Cevap, hangi yükseltme seviyesinde bulunduğunuza bağlıdır.

  • Sıfır seviye — proxy olmadan. Belgeler, açık kaynak projeleri, devlet siteleri, çoğu kurumsal blog. Burada sunucu IP’si normal çalışır ve ödeme yapacak bir şey yoktur.
  • Orta seviye — veri merkezi proxy’leri. Hızlı ve ucuzdur, basit oran sınırlamalarına ve bölgesel kısıtlamalara karşı uygundur. Büyük koleksiyonlar toplarken, bu çalışma atı: hacim yüzlerce gigabaytla ölçüldüğünde, gigabayt başına fiyat farkı ana faktör haline gelir.
  • Üst seviye — konut proxy’leri. Ciddi anti-bot koruması olan alanlar için, veri merkezi alt ağları girişte elenir. Bu nedenle, varsayılan seviye olarak ayarlanamazlar — gigabayt başına ödeme, her gereksiz resmi bir maliyet kalemine dönüştürür.

Boru hattı oluşturmadan önce, ekonomiyi dürüstçe hesaplamak önemlidir: bir milyon sayfanın ayrıştırma maliyetini sayfa ağırlığı, yeniden denemeler ve gizli maliyetler göz önünde bulundurularak inceledik. Ve ilk kod satırını yazmadan önce sormak faydalı bir sorudur: gerçekten tarama gerekli mi — resmi API ile hazır veri setleri ve ayrıştırma karşılaştırmasında, bazı kaynaklar için hazır verilerin kendi tarayıcınızdan daha ucuz olduğu görülmektedir.

Sonuç

LLM tarayıcısında proxy, “aç/kapa” anahtarı değil, üç katmanlı bir şemadır. Varsayılan seviye olarak doğrudan istek, orta seviyede veri merkezi proxy’leri, konut proxy’leri ise yalnızca başka türlü alınamayan alanlar için. Ayrıca medya kesimi sıkı olmalıdır, çünkü metin topluyorsunuz ve baytlar için ödeme yapıyorsunuz.

İş sırası basittir: önce sonuçların kalite kontrolü (aksi takdirde koleksiyonun yarısının geçici sayfalar olduğunu öğrenemezsiniz), sonra çerçevenin kendisiyle proxy yükseltmesi, ardından trafik tasarrufu. Bu sırayla — hem koleksiyon tam olacak, hem de fatura öngörülebilir olacaktır.

```