Ulasan Apache Nutch: Empat Batas yang Menentukan Apakah Ia Bisa Berjalan dan Apa yang Ditemukannya

Apache Nutch adalah crawler dari Apache Software Foundation yang pengembangannya dimulai pada 2004. Ini sistem berbasis JVM yang dibangun di atas Hadoop, disusun sebagai sebuah siklus alih-alih satu perintah streaming tunggal: URL seed di-inject ke basis data persisten, lalu berputar melalui generate → fetch → parse → updatedb, dengan slot plugin untuk protokol, parser, filter URL, dan scoring. Hasil akhirnya biasanya diarahkan ke indeks pencarian seperti Solr atau Elasticsearch, bukan ke CSV.

Saya menjalankan Nutch 1.22 pada sebuah situs uji lokal yang dikendalikan dengan ketat — situs yang mencatat setiap request di sisi server, sehingga hasil dinilai dari apa yang benar-benar dilihat server, bukan dari klaim crawler. Ada empat batas yang sangat memengaruhi proses ini: versi JDK, http.agent.name, cakupan crawl, dan apakah parse-js ada di plugin.includes. Siklus penuh dijalankan berulang kali dengan konfigurasi yang diuji; ubah JDK atau biarkan identitas agent kosong, dan proses berhenti sebelum sempat mengambil halaman yang berguna.

Batas JDK muncul sebelum crawl apa pun dimulai. Nutch 1.22 tidak bisa berjalan di JDK 26.0.1 di sini: job Hadoop pertama gagal di dalam Subject.getSubject() setelah Java menghapus jalur SecurityManager. Nutch menyertakan Hadoop 3.4.2, sementara perbaikannya baru mendarat di Hadoop 3.4.3 tujuh hari setelah Nutch 1.22 dirilis. Di sisi lain, parse-js mengubah pemulihan dua literal JavaScript dari 0/2 menjadi 2/2 tanpa menjalankan browser.

Untuk apa Nutch, dan untuk apa bukan

Nutch bukan scraper. Ekstraksi field terstruktur bukan tugas utamanya: ia menemukan dan mengambil URL dalam skala besar, menyimpan basis data persisten dari URL dan statusnya (crawldb), lalu menyerahkan segment yang kemudian diubah menjadi indeks oleh alat lain. Jika Anda mengarahkannya ke katalog dan berharap keluar tabel nama dan harga, yang Anda dapat justru crawldb.

Arsitektur itu menjelaskan hampir semua hal setelah ini. Nutch lahir hampir dua dekade sebelum era crawler satu-binary, dan ia dibuat untuk masalah yang juga menjadi fokus Hadoop: merayapi lebih banyak halaman daripada yang muat di satu mesin. Menjalankannya di laptop untuk fixture 12 halaman itu seperti menyewa kereta barang untuk memindahkan rak buku — informatif tentang keretanya, tapi tidak adil kalau berharap ergonomi seperti sepeda.

Rilis saat ini adalah 1.22, diumumkan pada 17 Februari 2026. Lisensinya Apache-2.0, repositorinya punya 3.272 bintang dengan 8 issue terbuka saat saya cek pada 27 Juli 2026, dan master masih di-push empat hari sebelumnya. Ini proyek yang masih dirawat, bukan proyek yang ditinggalkan — dan itu sudut pandang yang tepat untuk memahami problem JDK: masalah jendela paket yang tertutup seminggu terlalu cepat, bukan kelalaian.

Matriks versi: JDK 24+, Hadoop 3.4.2, dan perbaikan dua baris

Penghalangnya adalah interaksi tiga arah antarversi, dan satu-satunya bagian yang bisa Anda kendalikan adalah JDK yang dipakai Nutch. Job Hadoop pertama, pada JDK default host, langsung mati saat inisialisasi:

java.lang.UnsupportedOperationException: getSubject is not supported
    at java.base/javax.security.auth.Subject.getSubject(Subject.java:277)
    at org.apache.hadoop.security.UserGroupInformation.getCurrentUser(UserGroupInformation.java:588)
    at org.apache.nutch.crawl.Injector.inject(Injector.java:473)

Return code 255. Tidak ada halaman yang diambil. bin/nutch inject bahkan belum menyentuh jaringan — ia menginisialisasi Hadoop LocalJobRunner, yang bertanya siapa user saat ini, lalu memanggil Subject.getSubject(), yang JEP 486 ubah menjadi exception tanpa syarat ketika JDK 24 menghapus SecurityManager secara permanen. JDK host saya adalah OpenJDK 26.0.1, jauh melewati batas itu.

Jalan keluar tradisional juga tidak berfungsi. Menambahkan -Djava.security.manager=allow, flag yang dulu mengaktifkan perilaku lama, justru ditolak VM sebelum kode Nutch sempat dimuat:

Error occurred during initialization of VM
java.lang.Error: A command line option has attempted to allow or enable the Security
Manager. Enabling a Security Manager is not supported.

Itu return code 1, dan memang dead end secara desain — flag itu dihapus bersama fiturnya.

Akar masalahnya ada pada versi Hadoop yang dibundel Nutch 1.22. Masalah getSubject tercatat sebagai HADOOP-19212 dan diperbaiki di Hadoop 3.4.3 dan 3.5.0; Nutch 1.22 menyertakan hadoop-common-3.4.2. Nutch 1.22 dirilis pada 17 Februari 2026, dan Hadoop 3.4.3 menyusul sekitar seminggu kemudian.

Ini juga bukan masalah dependensi Solr atau cluster Hadoop. Ada anggapan umum bahwa Nutch butuh cluster Hadoop dan Solr yang sedang berjalan agar bisa melakukan apa pun. Tidak. Local mode menjalankan LocalJobRunner di proses yang sama — tanpa daemon HDFS, tanpa YARN, tanpa cluster. Seluruh siklus inject → generate → fetch → parse → updatedb berjalan di satu mesin tanpa instalasi tambahan. Dinding JDK murni masalah versi library yang dibundel, dan itu menghentikan Anda sebelum pertanyaan infrastruktur itu bahkan muncul.

Matriks versi yang praktis, semua tiga baris terukur:

Perbaikannya hanya dua perintah. Pasang JDK LTS dan arahkan Nutch ke sana:

brew install openjdk@17
export NUTCH_JAVA_HOME=/opt/homebrew/opt/openjdk@17

Karena bersifat keg-only, konfigurasi ini tidak mengubah default sistem. CI milik Nutch sendiri menarget Java 17, dan proyek ini secara publik menyatakan bahwa 1.22 adalah rilis terakhir yang berjalan di Java 11 dan bahwa 1.23 akan mewajibkan Java 17. Jadi, JDK LTS bukan sekadar workaround — itulah konfigurasi yang didukung. Ketidaksesuaian terjadi antara apa yang didukung Nutch dan apa yang diberikan brew install openjdk pada 2026, dan itu dua pertanyaan berbeda yang kebetulan bertabrakan pada perintah pertama.

Mulai dari sini semuanya dijalankan di OpenJDK 17.0.20, dan siklusnya bersih.

Setup, diukur: 396 MB dan satu properti yang memblokir semuanya

“Berat” adalah kata yang sering dipakai, tapi tidak berarti tanpa ukuran. Inilah isi nyata distribusi binary Nutch 1.22 yang sudah diekstrak:

Sebagai pembanding skala, crawler Go modern seperti katana hadir sebagai satu binary ~50 MB tanpa JVM dan tanpa JAR eksternal.

Lalu ada gerbang yang biasanya tidak diperingatkan ke Anda. nutch-site.xml bawaan kosong, dan http.agent.name default-nya string kosong. Jika dibiarkan, crawl pertama saya mengambil nol path dan mencatat:

ERROR Fetcher: No agents listed in 'http.agent.name' property.

Mengisi satu properti itu saja — tanpa yang lain — langsung membuat fetch berfungsi. Saat properti kosong, perintah selesai tanpa mengambil halaman, dan log menampilkan error nama agent di atas; ini bukan kondisi yang diam-diam gagal.

Konfigurasi minimum yang benar-benar diperlukan ternyata terdiri dari tiga artefak: conf/nutch-site.xml (nama agent, set plugin, scope), conf/regex-urlfilter.txt (pembatasan host), dan file URL seed. Itu bukan jumlah yang buruk. Hanya tiga file lebih banyak daripada crawler run <url>.

Apa yang ditemukan: toggle plugin yang menentukan

Situs uji memiliki tiga kelas endpoint yang sengaja dibuat berbeda, dan perilaku Nutch terpisah rapi di antaranya:

• Kelas A — tautan HTML biasa (4 halaman, plus rantai sedalam 3 link)
• Kelas B — endpoint yang hanya ada sebagai literal string di dalam file JavaScript yang ditautkan: satu sebagai argumen pemanggilan, fetch('/api/js-endpoint-7'), satu sebagai assignment, const other = "/api/js-endpoint-8"
• Kelas C — endpoint yang baru ada setelah JavaScript berjalan dan menyuntikkannya ke DOM

Hasil dari log hit sisi server, diulang tiga kali:

Identik di ketiga pengulangan. Deterministik.

Lonjakan kelas B adalah bagian yang paling sering diremehkan. Nutch menemukan kedua endpoint yang tertanam di JavaScript tanpa menjalankan browser, menggunakan pemindaian regex berbasis parse-js terhadap konten JavaScript. File app.js sendiri diambil di kedua konfigurasi — Nutch memperlakukan <script src> sebagai outlink apa pun bentuknya — jadi satu-satunya perbedaan adalah apakah ada yang membaca isi file untuk mencari string mirip URL. Aktifkan plugin-nya, dan dua bentuk literal itu tertangkap.

Pada fixture ini, mode default Nutch dan mode standar katana mencapai set kelas-A yang sama, sedangkan Nutch dengan parse-js dan katana dengan -jc mencapai kelas A dan B tanpa browser. Versi Katana dan perintah lengkapnya tidak dicantumkan dalam artikel ini, jadi hasil itu bersifat konteks, bukan benchmark produk yang ketat.

Kelas C adalah batas jujur. Tidak ada konfigurasi plugin statis yang mencapai endpoint ini, dan itu memang diharapkan: memulihkan endpoint yang hanya muncul setelah eksekusi script membutuhkan benar-benar menjalankan script. Saya memang mencoba mengganti protocol-http dengan protocol-htmlunit, protokol Nutch berbasis Java yang mengeksekusi JS. Protokol itu memuat dan berjalan tanpa crash, tetapi dalam harness empat putaran yang sama ia hanya menyelesaikan satu putaran, hanya mengambil seed page dan app.js, tidak mencapai A/B/C, dan putaran kedua melaporkan 0 records selected for fetching. Itu lebih merupakan probe yang kurang terkonfigurasi, bukan kesimpulan tentang kemampuan HtmlUnit. Yang bisa dipastikan lebih sempit: mengganti ke protokol yang mengeksekusi JS bukan perubahan plug-and-play, dan kelas C tetap tidak terjangkau di semua konfigurasi yang saya uji.

Kontrol crawl dan perilaku saat gagal

Kedalaman bukan flag. Tidak ada --depth 3 di Nutch; depth ditentukan oleh berapa banyak putaran generate → fetch → parse → updatedb yang Anda jalankan, karena putaran R mengambil frontier yang ditemukan pada putaran R-1. Rantai kedalaman saya mengonfirmasi hal itu dengan tepat:

Bersih dan mekanis, tetapi artinya depth adalah hitungan loop di skrip Anda, bukan parameter.

Sekarang jebakannya. Default bawaan Nutch adalah db.ignore.external.links=false, dipasangkan dengan URL filter permisif +. — artinya crawl Nutch bawaan akan mengikuti link ke luar host seed Anda. Saya men-seed sebuah halaman yang menaut ke satu path dalam scope dan satu link ke hostname lain, dan crawl mengambil host asing itu. Dua sinyal independen setuju: crawldb milik Nutch menandainya db_fetched, dan counter server host lain mencatat hit tersebut.

Tetap dalam scope harus diaktifkan secara eksplisit, dan kedua solusi ini terbukti bekerja:

Jika Anda hanya merayapi satu situs, atur salah satu dari itu sebelum run nyata pertama. Satu catatan metodologis: pengujian ini sensitif terhadap beban pada server lokal, jadi tiga baris itu berasal dari run saat tidak ada proses lain yang menyentuh fixture. Perilakunya sendiri jelas secara mekanis dan didukung dua sinyal independen; nilai baris spesifiknya adalah satu run yang bersih, bukan rata-rata dari banyak percobaan.

Sitemap adalah langkah terpisah. Politeness aktif — crawl normal mengambil /robots.txt — tetapi sitemap sendiri membutuhkan perintah khusus:

Modelnya berbeda dari crawler yang menarik known files secara inline, dan memang menuntut satu perintah tambahan, tetapi hasilnya lengkap.

Dua perilaku kecil juga berjalan dengan baik.

Penanganan error: crawl pada halaman yang menaut ke 500 dan 404 selesai dengan rapi di semua putaran, tetap mengambil keempat halaman kelas-A, dan mencatat tiap kegagalan secara terpisah:

Tidak ada yang menjatuhkan proses.

Politeness: dengan satu thread per queue, jeda antar fetch pada host yang sama mengikuti pengaturan:

Tombolnya melakukan persis apa yang tertulis. Default bawaan adalah 5.0 detik, yang konservatif dan, lagi-lagi, kemungkinan memang tepat untuk alat yang dirancang merayapi server milik orang lain.

Pajak batch, dalam detik

Setiap perintah Nutch memulai JVM baru. Satu fakta itu lebih mendominasi profil waktu daripada apa pun yang berkaitan dengan fetching.

Batas bawah efektif per job — startup JVM plus inisialisasi Hadoop, diukur sebagai fase kerja trivial termurah — sekitar 1.77 detik. Kalikan itu dengan empat perintah per putaran, tambah inject awal, dan gambaran crawl penuh menjadi seperti ini:

Kesenjangan itu bukan soal throughput fetch; kedua alat meminta sejumlah halaman yang sama. Ini soal arsitektur. Nutch membayar biaya proses tetap untuk tiap fase karena fase-fase itu dirancang sebagai job MapReduce. Pada crawl lokal yang kecil, biaya setup mendominasi. Biaya tetap itu seharusnya menjadi porsi yang lebih kecil pada job yang lebih panjang, tetapi pengujian ini tidak mengukur pada skala di mana Nutch dan katana saling menyalip, atau apakah rasionya berbalik.

Kelebihan dan kekurangan

Kelebihan

• Penemuan statis yang deterministik: kelas HTML 4/4, rantai kedalaman 3/3, identik di tiga run berulang.
• parse-js memulihkan endpoint literal di file JavaScript (2/2) tanpa browser, menangkap bentuk argumen pemanggilan dan assignment.
• Dua kontrol scope yang terverifikasi dan benar-benar membatasi crawl (db.ignore.external.links dan host regex-urlfilter).
• Ingest sitemap lewat bin/nutch sitemap mencapai recall penuh 2/2 pada endpoint yang dilewatkan crawl normal.
• Tahan terhadap kegagalan: 500 dan 404 sama-sama ditangani dengan state crawldb yang berbeda, crawl tetap lanjut.
• Pada run lokal ini, interval antar request pada host yang sama konsisten dengan delay 1.0 detik yang dikonfigurasi; default bawaan adalah 5.0 detik.
• Apache-2.0, masih dirawat aktif, 78 plugin, dan crawldb persisten yang melacak state per-URL lintas putaran.
• Berjalan di local mode tanpa cluster, tanpa HDFS, dan tanpa Solr.

Kekurangan

• Tidak berjalan di JDK 24 atau lebih baru, di mana penghapusan SecurityManager menimbulkan masalah (saya mengukur kegagalan ini di 26.0.1) — Hadoop 3.4.2 yang dibundel mendahului perbaikan upstream dan flag jalan keluar sudah tidak ada, jadi pin ke JDK LTS adalah prasyarat keras, bukan preferensi.
• ≈396 MB setelah diekstrak, 188 JAR library, 78 direktori plugin, 35 file konfigurasi.
• JVM baru di setiap perintah berarti overhead tetap ~1.77 detik per fase; ~45 detik untuk crawl depth-4 pada 12 halaman dibanding ~13 detik pada crawler satu binary di kondisi yang sama.
• Default bawaan mengikuti link ke host eksternal; tetap di satu situs harus diaktifkan sendiri.
• http.agent.name bawaan kosong dan fetcher menolak berjalan sampai Anda mengisinya.
• Tidak ada flag depth — depth adalah hitungan loop yang harus Anda kelola sendiri.
• Endpoint yang bergantung pada DOM runtime tidak terjangkau di semua konfigurasi yang diuji, dan mengganti protokol yang mengeksekusi JS bukan perubahan plug-and-play.
• Saya menguji local mode pada satu host dengan fixture kecil. Mode terdistribusi/HDFS, indexing Solr, hostdb, resume, dan penjadwalan re-crawl inkremental berada di luar pengujian ini — anggap belum diuji di sini, bukan sebagai hal yang direkomendasikan.

Siapa yang sebaiknya memakai, dan siapa yang sebaiknya pergi

Nutch layak dipakai ketika crawling itu sendiri adalah bagian tersulit. Jika Anda membangun indeks pencarian, menjalankan crawl luas lintas domain, membutuhkan database URL persisten dengan state per-URL dan semantik retry, atau ingin pada akhirnya mendistribusikan pekerjaan ke banyak mesin, ini adalah infrastruktur yang memang sudah mengerjakan tugas itu sejak sebelum kebanyakan alternatif ada. Sistem pluginnya berarti Anda bisa mengubah perilaku protocol, parser, filter, dan scoring tanpa me-fork apa pun. Default politeness-nya konservatif dengan cara yang menunjukkan para maintainer benar-benar memikirkan bagaimana menjadi warga internet yang baik.

Tinggalkan saja jika Anda ingin data terstruktur dari beberapa halaman saja. Nutch akan mengambil dan memparsenya, lalu menyerahkan crawldb dan segment kepada Anda dan mengharapkan Anda membawa indexer. Tinggalkan jika target Anda adalah aplikasi single-page yang dirender client-side — kelas C tetap tidak terjangkau dalam semua percobaan saya. Tinggalkan jika tim Anda tidak menjalankan JVM, karena Anda akan menambahkan toolchain Java, pin JDK LTS, dan 396 MB JAR ke stack yang sebelumnya tidak memilikinya. Dan jika beban kerjanya adalah "crawl satu situs, empat level dalam, seminggu sekali," Anda akan menghabiskan lebih banyak waktu pada loop putaran dan file konfigurasi daripada pantas untuk tugas tersebut.

Bagi kebanyakan orang yang sedang memilih scraper, kasus terakhir itulah yang paling sering terjadi. Itu bukan kritik terhadap Nutch — melainkan ketidakcocokan antara alat dan pekerjaan. Jika Anda ingin gambaran tentang lanskap yang lebih luas, rangkuman scraper open-source dan proyek web scraping GitHub terbaik kami membahas sisi yang lebih ringan dengan lebih detail.

Alternatif, termasuk posisi stack kami sendiri

Pertama, framing yang adil: Nutch gratis, berlisensi Apache, self-hosted, dan sepenuhnya milik Anda untuk dijalankan selamanya tanpa biaya per request. Itu keunggulan nyata, dan tidak ada yang menghapusnya di bawah ini.

Ulasan terkait: Ulasan Browsertrix Crawler.

Di dunia open-source, perbandingannya tergantung pada apa yang ingin Anda optimalkan. Jika Anda menginginkan framework Python dengan kontrol crawl dan filosofi request-first, Scrapy adalah analog yang lebih dekat untuk banyak proyek; artikel ini tidak mengukur ukuran instalasinya dengan basis yang sama. Jika Anda menginginkan crawler Go yang ringkas tanpa browser, Colly adalah bentuk lain yang layak dievaluasi. Jika masalah Anda adalah mengubah halaman menjadi konten siap LLM, bukan menemukan URL, Crawl4AI diarahkan ke lapisan yang berbeda.

Layanan terkelola seperti Thunderbit memindahkan fetching, rendering, dan ekstraksi ke belakang API, sementara Nutch tetap menjaga state crawl dan infrastruktur di bawah kendali Anda. Thunderbit tidak dijalankan pada fixture ini, jadi ini adalah perbandingan model kepemilikan, bukan klaim tentang recall yang sama atau performa halaman dinamis yang setara.

Tukarannya adalah kendali versus overhead, dan perbedaannya tidak halus. Nutch memberi Anda kontrol total, crawldb persisten, skalabilitas cluster secara desain, dan biaya marginal nol — dengan imbalan JVM, pin JDK LTS, 396 MB JAR, loop per putaran, dan lapisan indexing Anda sendiri. API terkelola memberi Anda output terstruktur pada panggilan pertama dan tanpa infrastruktur — dengan imbalan harga per panggilan dan kontrol yang lebih kecil atas frontier crawl. Jika tugas Anda "mengindeks 50 juta halaman," model Nutch adalah yang benar dan API akan terasa absurd. Jika tugas Anda "mengambil record terstruktur dari 200 halaman produk sebelum Kamis," kebalikannya yang benar.

Coba Thunderbit untuk Ekstraksi Data Web

Putusan

Apache Nutch layak dievaluasi jika Anda menjalankan crawl berkelanjutan lintas banyak domain dan sudah mengoperasikan infrastruktur JVM. Pada fixture ini, penemuan statisnya deterministik di setiap pengulangan, parse-js menemukan kedua endpoint JavaScript literal, kegagalan tetap tercatat di crawldb, dan jarak antar request yang diamati sesuai dengan delay yang dikonfigurasi.

Nilai biaya masuknya secara jujur. Nutch 1.22 gagal di sini pada JDK 26.0.1; OpenJDK 17.0.20 adalah konfigurasi LTS yang benar-benar terverifikasi dalam ulasan ini, sementara Java 21 tidak diuji. Lalu set http.agent.name, tentukan scope secara eksplisit, dan perhitungkan batas tetap sekitar ~1.77 detik per fase yang teramati pada run lokal kecil ini. Apakah trade-off itu masuk akal tergantung pada durasi crawl, cakupan, dan kebutuhan akan state persisten.

Coba Thunderbit untuk Ekstraksi Data Web Get Started Free

FAQ

Mengapa Apache Nutch gagal dengan "getSubject is not supported"? Pada JDK 24 atau lebih baru, JEP 486 membuat Subject.getSubject() selalu melempar exception, sementara Hadoop 3.4.2 yang dibundel masih memanggilnya. Job Hadoop pertama pun mati sebelum ada halaman yang diambil, dan jalan keluar lama -Djava.security.manager=allow tidak lagi bisa menyalakan VM. Gunakan konfigurasi Java 17 yang sudah diverifikasi dan set NUTCH_JAVA_HOME; Java 21 mungkin didukung, tetapi review ini tidak menjalankan siklus penuh di sana.

Versi Java apa yang sebaiknya dipakai untuk Nutch 1.22? Java 17 adalah jawaban paling aman — CI Nutch sendiri menargetkannya, dan itu berjalan bersih pada pengujian saya di OpenJDK 17.0.20. Java 11 juga masih didukung untuk 1.22, meski proyek telah mengumumkan bahwa 1.23 akan mewajibkan Java 17. Apa pun dari JDK 24 ke atas tidak akan berjalan. Instalasi Homebrew keg-only (brew install openjdk@17) plus NUTCH_JAVA_HOME menjaga default JDK sistem tetap tidak berubah.

Apakah Nutch bisa merayapi situs yang berat JavaScript? Sebagian, dan perbedaannya penting. Dengan plugin parse-js diaktifkan, Nutch menemukan dua endpoint yang hanya ada sebagai literal string di file JavaScript yang ditautkan — 2/2, tanpa browser. Dengan set plugin default, keduanya tidak ditemukan. Tetapi endpoint yang baru muncul setelah JavaScript dieksekusi dan memodifikasi DOM tetap tidak terjangkau di setiap konfigurasi statis yang saya uji, dan mengganti ke protokol HtmlUnit bukan perubahan plug-and-play dalam run saya. Untuk aplikasi yang dirender client-side, siapkan protokol yang mengeksekusi JS plus pekerjaan konfigurasi yang nyata, atau gunakan alat lain.

Apakah Nutch butuh Hadoop dan Solr terpasang? Tidak. Local mode menjalankan LocalJobRunner Hadoop di proses yang sama — tanpa cluster, tanpa daemon HDFS, tanpa YARN — dan seluruh siklus inject → generate → fetch → parse → updatedb bekerja di satu mesin tanpa instalasi tambahan. Solr biasanya menjadi tujuan indexing, tetapi crawl-nya sendiri tidak memerlukannya. Namun, JAR Hadoop memang dibundel (13 buah, versi 3.4.2), dan itulah alasan problem kompatibilitas JDK itu muncul sejak awal.

Bagaimana cara menghentikan Nutch agar tidak merayapi website lain? Atur secara eksplisit, karena default bawaan tidak melakukannya. Nutch 1.22 mengirim db.ignore.external.links=false dengan URL filter yang permisif, dan pada pengujian saya crawl default mengikuti link ke host lain dan mengambilnya. Anda bisa set db.ignore.external.links=true di nutch-site.xml, atau menambahkan aturan host ke conf/regex-urlfilter.txt (misalnya +^https://example\.com/ lalu -.). Keduanya benar-benar menahan crawl dalam scope pada pengujian, diverifikasi dari crawldb Nutch sendiri dan dari log request server lain.