Proxy untuk Firecrawl, Crawl4AI, dan Crawlee: Kumpulkan Korpus untuk RAG Tanpa Pemblokiran

```html

Skema "mengangkat Firecrawl di Docker, mengarahkannya ke daftar domain, mendapatkan markdown untuk RAG" bekerja dengan baik hingga seribu halaman pertama. Setelah itu, dua tagihan muncul. Yang pertama — dari anti-bot: beberapa domain mulai memberikan 403 alih-alih konten, dan di basis pengetahuan muncul celah yang Anda ketahui ketika asisten menjawab "tidak ada informasi dalam materi yang diberikan". Tagihan kedua — untuk lalu lintas: crawler dengan jujur menarik setiap gambar dan setiap font, yang pada akhirnya tidak akan masuk ke markdown.

Mari kita bahas bagaimana menghubungkan proxy ke tiga crawler LLM terpopuler tahun 2026 — Firecrawl, Crawl4AI, dan Crawlee — dan bagaimana mengatur mereka agar proxy hanya berfungsi di tempat yang diperlukan, dan tidak membakar gigabyte di setiap halaman.

Untuk siapa panduan ini

Jika Anda mengumpulkan kumpulan dokumen untuk RAG, mengisi basis pengetahuan internal, membangun pipeline data untuk pelatihan ulang, atau hanya secara rutin mengunduh ratusan domain — ini adalah kasus Anda. Ketiga alat di bawah ini dalam konfigurasi default menggunakan IP server Anda dan memuat halaman secara keseluruhan. Kedua default ini perlu diubah.

Skala masalah dapat dilihat dari angka popularitas: Firecrawl pada saat publikasi memiliki sekitar 170 ribu bintang di GitHub (lisensi AGPL-3.0), Crawl4AI sekitar 79 ribu, dan Crawlee dari Apify sekitar 25 ribu. Ini bukan lagi eksperimen niche, tetapi alat standar, dan sistem anti-bot mengenali perilaku mereka tidak lebih baik dari Anda.

Tagihan pertama: 403 alih-alih konten

Kesalahan kunci saat mengumpulkan kumpulan adalah menganggap bahwa crawler berhasil jika tidak mengalami kegagalan. Firecrawl dan Crawl4AI pada halaman yang diblokir tidak mengembalikan pengecualian, tetapi hasil: halaman pengganti anti-bot, halaman dengan pemeriksaan browser, atau teks pendek tentang penolakan akses. Secara formal ini adalah markdown yang valid, ia dengan tenang masuk ke basis vektor dan tinggal di sana hingga permintaan pengguna pertama.

Oleh karena itu, hal pertama yang perlu dilakukan sebelum pengaturan proxy adalah menambahkan kontrol kualitas hasil. Versi minimal: menolak dokumen yang lebih pendek dari ambang tertentu (untuk halaman konten tipikal, masuk akal 500–800 karakter teks) dan secara terpisah menangkap penanda karakteristik dalam teks — penyebutan pemeriksaan koneksi, JavaScript yang diaktifkan, "Akses ditolak". Dokumen semacam itu tidak dikirim ke basis, tetapi ke antrean untuk pengulangan — sudah melalui proxy.

Tagihan kedua: gigabyte yang Anda buang

Di sini aritmetika membantu. Menurut Web Almanac dari HTTP Archive untuk tahun 2025, halaman utama median memiliki berat sekitar 2,86 MB di desktop dan 2,56 MB di perangkat mobile. Dari jumlah tersebut, gambar menyumbang sekitar 1.059 KB di halaman utama dan 911 KB di halaman internal, sedangkan JavaScript — 697 KB dan 632 KB masing-masing. Jadi gambar adalah kategori terberat, sekitar sepertiga dari berat halaman.

Dan sekarang ingat apa yang Anda lakukan dengan hasilnya. Anda mengonversi halaman menjadi markdown dan memotongnya menjadi potongan untuk embedding. Gambar tidak masuk ke pipeline ini sama sekali — dalam kasus terbaik, hanya tersisa satu baris dengan teks alt. Video, font, skrip analitik, pixel iklan — juga terlewat.

Jika Anda menjalankan pengunduhan melalui proxy residensial dengan pembayaran per gigabyte, Anda secara harfiah membayar untuk pengiriman data yang Anda buang di langkah berikutnya dari pipeline. Pada kumpulan 100 ribu halaman, perbedaan antara "menarik semuanya" dan "menarik hanya HTML dan teks" diukur bukan dalam persentase, tetapi dalam kali lipat. Penghematan yang tepat tergantung pada tema situs: media dan e-commerce lebih berat daripada dokumentasi dan blog.

Langkah 1. Eskalasi alih-alih "proxy untuk semuanya"

Teknik arsitektur utama yang menghemat paling banyak: jangan mengarahkan seluruh lalu lintas melalui proxy. Sebagian besar domain saat mengumpulkan basis pengetahuan — dokumentasi, blog, situs referensi, portal pemerintah — memberikan konten secara langsung dan tidak memblokir siapa pun. Proxy hanya diperlukan oleh minoritas.

Skema yang benar adalah eskalasi bertingkat: pertama permintaan langsung, saat ada tanda pemblokiran — beralih ke tingkat berikutnya. Dan ini bukanlah solusi buatan sendiri, kedua kerangka kerja besar sudah bisa melakukannya dari awal.

Di Crawlee, ada tieredProxyUrls untuk ini. Tingkat diurutkan dari yang murah ke yang mahal, dan crawler secara otomatis naik saat terjadi pemblokiran, dan kemudian secara berkala mencoba kembali ke tingkat yang lebih rendah:

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

Nuansa penting dari dokumentasi: tieredProxyUrls hanya berfungsi saat digunakan melalui instance crawler. Panggilan langsung newUrl() akan memberikan hasil yang tidak terduga.

Di Crawl4AI, mekanisme serupa muncul di versi 0.8.5 dan ada di cabang terbaru (rilis terakhir pada saat publikasi — v0.9.2 dari 15 Juli 2026). Ini disebut eskalasi proxy dan diatur langsung di CrawlerRunConfig: deteksi pemblokiran tiga tingkat — vendor anti-bot yang dikenal, indikator umum pemblokiran, dan pemeriksaan integritas struktural halaman — ditambah pengulangan otomatis melalui rantai 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,
)

Perhatikan ProxyConfig.DIRECT sebagai elemen pertama — ini adalah "cobalah tanpa proxy terlebih dahulu".

Langkah 2. Menghubungkan proxy di setiap alat

Selanjutnya — detail pengaturan. Urutan tindakan sama: pertama proxy, kemudian pemotongan lalu lintas yang tidak perlu, lalu pemeriksaan.

1. Firecrawl (self-hosted). Proxy ditentukan oleh tiga variabel lingkungan yang diteruskan ke Playwright: PROXY_SERVER, PROXY_USERNAME, PROXY_PASSWORD. Ditulis di .env untuk apps/api; dalam komentar mereka, pengembang secara langsung menulis bahwa alih-alih alamat statis, Anda dapat menunjuk layanan proxy yang merotasi IP pada setiap permintaan.
2. Crawl4AI. Proxy berada di BrowserConfig, di bidang proxy_config — ini adalah objek ProxyConfig atau kamus dengan bidang server, username, password. Satu konfigurasi browser untuk seluruh sesi crawling; CrawlerRunConfig terpisah diteruskan pada setiap panggilan arun().
3. Crawlee. Kelas ProxyConfiguration dengan opsi proxyUrls — daftar alamat, di mana pustaka berjalan dalam putaran (round-robin). Nilai null dalam daftar berarti "tanpa proxy". Integrasi menyeluruh: HttpCrawler, CheerioCrawler, JSDOMCrawler, PlaywrightCrawler, PuppeteerCrawler.
4. Aturan titik. Jika diketahui domain mana yang memblokir dan mana yang tidak, di Crawlee ada newUrlFunction — logika pemilihan proxy berdasarkan URL permintaan. Untuk domain putih, kembalikan null, untuk yang lainnya — alamat proxy. Ini adalah opsi paling murah ketika daftar tujuan stabil.
5. Pemeriksaan. Sebelum menjalankan pengujian, jalankan halaman yang memberikan IP eksternal Anda melalui crawler yang telah diatur, dan pastikan Anda melihat alamat proxy, bukan server. Tiga baris yang menghemat hari penyelidikan.

Langkah 3. Memotong semua yang tidak menjadi teks

Ketika proxy terhubung, aktifkan penghematan lalu lintas — jika tidak, tagihan untuk gigabyte akan datang lebih cepat daripada kumpulan yang terkumpul.

Di Firecrawl, ini diatur oleh variabel BLOCK_MEDIA. Dalam contoh konfigurasi resmi, ada komentar harfiah: atur jika Anda ingin memblokir permintaan media untuk menghemat bandwidth proxy. Ini adalah cara tercepat untuk menghapus pengeluaran utama.

Di Crawl4AI, tuas serupa berada di BrowserConfig: text_mode mematikan gambar dan mempercepat crawling teks, light_mode mematikan beberapa fungsi latar belakang browser, avoid_css memblokir pemuatan CSS. Mereka dapat digabungkan. Untuk mengumpulkan kumpulan untuk RAG, ini hampir selalu merupakan set yang benar — Anda tidak memerlukan tata letak, Anda memerlukan teks.

Di Crawlee, logikanya berbeda: jika konten disajikan dalam HTML, gunakan CheerioCrawler atau HttpCrawler alih-alih yang berbasis browser. Permintaan HTTP biasa alih-alih rendering penuh — ini bukan hanya penghematan lalu lintas, ini adalah urutan pengeluaran yang berbeda. Crawler berbasis browser (PlaywrightCrawler, PuppeteerCrawler) hanya untuk halaman yang tidak dapat dikumpulkan tanpa JavaScript.

Perangkap

Sesi vs rotasi. Mengganti IP pada setiap permintaan sendiri terlihat mencurigakan dan merusak skenario multi-langkah — paginasi, perpindahan di dalam satu domain. Di Crawlee, setiap panggilan newUrl() mengaitkan proxy dengan objek Session, dan mereka berotasi bersama dengan sidik jari browser dan header. Jangan putuskan ikatan ini secara manual.

Mediа dimatikan, tetapi konten hilang. Beberapa situs dengan pemuatan malas menarik tidak hanya gambar, tetapi juga teks. Setelah mengaktifkan text_mode atau BLOCK_MEDIA, pastikan untuk menjalankan sampel kontrol dari 20–30 halaman dan bandingkan volume teks dengan standar.

Retry tanpa batas. Eskalasi melalui tingkat proxy berarti bahwa satu halaman yang keras kepala dapat diunduh tiga kali — dan semua tiga kali dibayar. Batasi max_retries dan buat daftar domain yang setelah N kegagalan dikecualikan dari crawling sama sekali.

Robots.txt dan kerangka hukum. Pengumpulan data untuk pelatihan dan RAG pada tahun 2026 diatur lebih ketat daripada beberapa tahun yang lalu — dari persyaratan pengungkapan sumber hingga mekanisme penolakan dari text and data mining. Pastikan bahwa pipeline Anda menghormati sinyal ini sebelum ia bekerja pada ratusan ribu halaman.

Jenis proxy apa yang harus diambil untuk pipeline RAG

Jawabannya tergantung pada tingkat eskalasi di mana Anda berada.

• Tingkat nol — tanpa proxy. Dokumentasi, proyek open-source, situs pemerintah, sebagian besar blog perusahaan. Di sini IP server berfungsi dengan baik, dan tidak ada yang perlu dibayar.
• Tingkat menengah — data center proxy. Cepat dan murah, cocok untuk melawan pembatasan tingkat sederhana dan pembatasan regional. Saat mengumpulkan kumpulan besar, ini adalah kuda kerja: ketika volume diukur dalam ratusan gigabyte, perbedaan harga per gigabyte menjadi faktor utama.
• Tingkat atas — residential proxy. Untuk domain dengan perlindungan anti-bot yang serius, di mana subnet data center disaring di pintu masuk. Itulah sebabnya mereka tidak dapat dijadikan tingkat default — pembayaran per gigabyte mengubah setiap gambar yang tidak perlu menjadi baris pengeluaran.

Sebelum membangun pipeline, sebaiknya hitung ekonomi dengan jujur: kami telah membahas biaya penuh untuk mem-parsing satu juta halaman dengan mempertimbangkan berat halaman, retry, dan biaya tersembunyi. Dan pertanyaan terpisah yang berguna untuk diajukan sebelum menulis baris pertama kode: apakah crawling benar-benar diperlukan — dalam analisis API resmi vs dataset siap pakai dan parsing terlihat bahwa untuk beberapa sumber, data siap pakai lebih murah daripada crawler Anda sendiri.

Kesimpulan

Proxy di crawler LLM bukanlah saklar "nyala/mati", tetapi skema tiga tingkat. Permintaan langsung sebagai tingkat default, data center proxy di tingkat menengah, residential — hanya untuk domain yang tidak dapat diambil dengan cara lain. Ditambah pemotongan keras media, karena Anda mengumpulkan teks, tetapi membayar untuk byte.

Urutan pekerjaan sederhana: pertama kontrol kualitas hasil (jika tidak, Anda tidak akan tahu bahwa setengah dari kumpulan adalah halaman pengganti), kemudian eskalasi proxy menggunakan alat dari kerangka kerja itu sendiri, lalu penghematan lalu lintas. Dalam urutan ini — dan kumpulan akan lengkap, dan tagihan dapat diprediksi.