“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.
- Firecrawl (kendinize ait). Proxy, Playwright’a geçirilen üç ortam değişkeni ile belirlenir:
PROXY_SERVER,PROXY_USERNAME,PROXY_PASSWORD. Bunlar.envdosyasınaapps/apiiç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. - Crawl4AI. Proxy,
BrowserConfigiçinde yaşar,proxy_configalanında — bu birProxyConfignesnesi veyaserver,username,passwordalanlarına sahip bir sözlüktür. Tek bir tarayıcı yapılandırması, tüm tarama oturumu için geçerlidir; herarun()çağrısında ayrı birCrawlerRunConfiggeçirilir. - Crawlee.
ProxyConfigurationsınıfı,proxyUrlsseçeneği ile — kütüphanenin döngüsel olarak gittiği adresler listesi (round-robin). Listedenulldeğeri, “proxy olmadan” anlamına gelir. Entegre sistem:HttpCrawler,CheerioCrawler,JSDOMCrawler,PlaywrightCrawler,PuppeteerCrawler. - Hedefe özel kurallar. Hangi alanların engellediği ve hangilerinin engellemediği biliniyorsa, Crawlee’de
newUrlFunctionvardır — istek URL’sine dayalı olarak proxy seçme mantığı. Beyaz alanlar içinnulldöndürüyorsunuz, diğerleri için — proxy adresi. Bu, hedef listesi sabit olduğunda en ucuz seçenektir. - 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.
```