Apache Nutch review: vier grenzen die bepalen of het werkt en wat het vindt

Apache Nutch is een crawler van de Apache Software Foundation waarvan de ontwikkeling in 2004 begon. Het is een JVM-systeem dat op Hadoop draait en meer als een herhalende workflow is opgebouwd dan als één doorlopende opdracht: seed-URL’s worden via inject in een permanente database gezet, gevolgd door rondes generate → fetch → parse → updatedb, met plugin-slots voor protocol, parser, URL-filter en scoring. De gebruikelijke output gaat naar een zoekindex zoals Solr of Elasticsearch, niet naar een CSV.

Ik heb Nutch 1.22 getest op een gecontroleerde lokale testsite — eentje die elke request server-side logt, zodat de uitkomst wordt beoordeeld op wat de server echt heeft gezien en niet op wat de crawler beweert. Vier grenzen bepaalden het resultaat: de JDK-versie, http.agent.name, de crawl-scope en of parse-js in plugin.includes voorkomt. De volledige cyclus draaide herhaaldelijk met de geteste configuratie; verander je de JDK of laat je de agent-identiteit leeg, dan stopt het nog vóór er bruikbare pagina’s worden opgehaald.

De JDK-grens verschijnt al vóór de crawl begint. Nutch 1.22 startte hier niet op JDK 26.0.1: de eerste Hadoop-job sneuvelde in Subject.getSubject() nadat Java het SecurityManager-pad had verwijderd. Nutch bundelt Hadoop 3.4.2, terwijl de fix pas zeven dagen na de release van Nutch 1.22 landde in Hadoop 3.4.3. Daarnaast zorgde parse-js ervoor dat twee JavaScript-string-literals van 0/2 naar 2/2 werden hersteld, zonder dat er een browser werd uitgevoerd.

Waar Nutch voor is, en waar juist niet

Nutch is geen scraper. Gestructureerde velduitlijning is niet het doel: het ontdekt en haalt URL’s op in volume, onderhoudt een persistente database van die URL’s en hun status (de crawldb), en levert segmenten aan iets anders dat daar een index van maakt. Zet je het op een catalogus in de hoop op een tabel met namen en prijzen, dan krijg je in plaats daarvan een crawldb.

Die architectuur verklaart het grootste deel van wat volgt. Nutch komt uit het tijdperk vóór de single-binary crawler, en is gebouwd voor het probleem waarvoor Hadoop ook gebouwd is: meer pagina’s crawlen dan op één machine passen. Het draaien op een laptop tegen een testset van 12 pagina’s is alsof je een goederentrein huurt om een boekenkast te verplaatsen — informatief over de trein, maar het is onredelijk om fiets-ergonomie te verwachten.

De huidige release is 1.22, aangekondigd op 17 februari 2026. Het project is Apache-2.0 gelicentieerd, de repo stond bij mijn controle op 27 juli 2026 op 3.272 stars met 8 open issues, en de master-branch was vier dagen daarvoor nog gepusht. Dit is dus een actief onderhouden project, niet een verlaten project — en dat is precies het juiste kader voor het JDK-probleem: een release-venster dat een week te vroeg sloot, geen verwaarlozing.

De versiematrix: JDK 24+, Hadoop 3.4.2 en een tweeregelige fix

De blokkade is een interactie tussen drie versies, en het enige deel waar jij grip op hebt is welke JDK Nutch gebruikt. De allereerste Hadoop-job op de standaard JDK van de host crashte tijdens initialisatie:

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)

Exitcode 255. Geen enkele pagina opgehaald. bin/nutch inject komt niet eens aan het netwerk toe — het initialiseert een Hadoop LocalJobRunner, die vraagt wie de huidige gebruiker is, wat Subject.getSubject() aanroept, en JEP 486 veranderde dat in een onvoorwaardelijke uitzondering toen JDK 24 de SecurityManager definitief verwijderde. Mijn host draaide OpenJDK 26.0.1, dus ver voorbij die grens.

De klassieke uitweg werkt ook niet. Als je -Djava.security.manager=allow toevoegt, de vlag die vroeger het oude gedrag weer inschakelde, weigert de VM al te starten voordat Nutch-code überhaupt wordt geladen:

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.

Dat levert exitcode 1 op, en is bewust een dood spoor — de vlag is samen met de functie verwijderd.

De onderliggende oorzaak zit in de Hadoop-versie die met Nutch 1.22 wordt meegeleverd. Het getSubject-probleem staat geregistreerd als HADOOP-19212 en is opgelost in Hadoop 3.4.3 en 3.5.0; Nutch 1.22 bundelt hadoop-common-3.4.2. Nutch 1.22 verscheen op 17 februari 2026, en Hadoop 3.4.3 volgde ongeveer een week later.

Het is ook geen probleem met Solr of een Hadoop-cluster. Er bestaat vaak de aanname dat Nutch een Hadoop-cluster en een draaiende Solr nodig heeft om überhaupt iets te doen. Dat is niet zo. De lokale modus gebruikt Hadoop’s in-process LocalJobRunner — geen HDFS-daemon, geen YARN, geen cluster. De volledige inject → generate → fetch → parse → updatedb-cyclus draait op één machine zonder dat er verder iets geïnstalleerd hoeft te zijn. De JDK-grens is puur een probleem met een gebundelde bibliotheekversie, en blokkeert je nog vóór die infrastructuurvraag überhaupt relevant wordt.

De praktische versiematrix, alle drie de rijen gemeten:

De oplossing bestaat uit twee commando’s. Installeer een LTS-JDK en verwijs Nutch daarnaar:

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

Keg-only, dus het raakt de systeemstandaard niet. De eigen CI van Nutch richt zich op Java 17, en het project heeft openlijk aangekondigd dat 1.22 de laatste release is die op Java 11 draait en dat 1.23 Java 17 zal vereisen. Een LTS-JDK is dus geen workaround maar de ondersteunde configuratie. De mismatch zit tussen wat Nutch ondersteunt en wat brew install openjdk je in 2026 geeft, en dat zijn twee verschillende vragen die toevallig botsen bij het allereerste commando.

Alles vanaf hier draaide op OpenJDK 17.0.20, waar de hele cyclus netjes verloopt.

Setup, gemeten: 396 MB en één property die alles blokkeert

“Zwaar” is het woord dat iedereen gebruikt, maar zonder meting zegt het weinig. Dit is wat de uitgepakte Nutch 1.22-binarydistributie daadwerkelijk bevat:

Ter vergelijking: een moderne Go-crawler zoals katana wordt geleverd als één binary van ongeveer 50 MB, zonder JVM en zonder externe jars.

Dan is er nog de poort waar niemand je voor waarschuwt. De meegeleverde nutch-site.xml is leeg, en http.agent.name staat standaard op een lege string. Als je die leeg laat, haalde mijn eerste crawl nul paden op en verscheen dit in de log:

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

Alleen dat ene property invullen — verder niets — maakte de fetch werkend. Met een lege property werd de opdracht voltooid zonder pagina’s op te halen, en de log meldde de fout hierboven; het was dus niet stil.

De minimale werkbare configuratie bleek uit drie onderdelen te bestaan: conf/nutch-site.xml (agentnaam, plugin-set, scope), conf/regex-urlfilter.txt (host-scope) en een seed-URL-bestand. Dat is niet buitensporig. Het zijn alleen drie bestanden meer dan crawler run <url>.

Wat het vond: de plugin-schakelaar die ertoe doet

De testsite had drie bewust verschillende soorten endpoints, en het gedrag van Nutch splitste daar netjes over uit:

• Klasse A — gewone HTML-links (4 pagina’s, plus een keten van 3 links diep)
• Klasse B — endpoints die alleen bestaan als string-literals in een gekoppeld JavaScript-bestand: één als functie-argument, fetch('/api/js-endpoint-7'), en één als toewijzing, const other = "/api/js-endpoint-8"
• Klasse C — een endpoint dat pas bestaat nadat JavaScript draait en het in de DOM injecteert

Resultaten, uit server-side hitlogs, drie keer herhaald:

Identiek in alle drie de herhalingen. Deterministisch.

De sprong bij klasse B wordt vaak onderschat. Nutch vond beide in JavaScript ingebedde endpoints zonder een browser te draaien, via de regex-gebaseerde scan van JavaScript-inhoud door de parse-js-plugin. Het app.js-bestand zelf werd in beide configuraties opgehaald — Nutch behandelt <script src> sowieso als een outlink — dus het hele verschil zit erin of iets de inhoud van dat bestand doorzoekt op URL-achtige strings. Zet de plugin aan, en hij pakt beide letterlijke vormen mee.

Op deze testset bereikten Nutch’s standaardmodus en katana’s standaardmodus hetzelfde klasse-A-setje, terwijl Nutch met parse-js en katana met -jc klassen A en B zonder browser bereikten. De versie van Katana en het volledige commando staan niet in dit artikel, dus dat resultaat is context en geen strikte productbenchmark.

Klasse C is de eerlijke bovengrens. Geen enkele statische pluginconfiguratie kwam daar, en dat is te verwachten: een endpoint terugvinden dat pas na scriptuitvoering ontstaat, vereist dat script ook echt uitvoeren. Ik heb wel geprobeerd protocol-http te vervangen door protocol-htmlunit, Nutch’s pure-Java protocol dat JavaScript uitvoert. Dat laadde en draaide zonder te crashen, maar in hetzelfde vier-ronden-harnas voltooide het slechts één ronde, haalde alleen de seed-pagina en app.js op, bereikte geen van A/B/C, en in ronde twee stond er 0 records selected for fetching. Dat is een ondergeconfigureerde probe, geen oordeel over de capaciteiten van HtmlUnit. Wat het wel laat zien is smaller: een JS-uitvoerend protocol erin zetten is geen drop-in wijziging, en klasse C bleef in elke getest configuratie onbereikbaar.

Crawlbesturing en foutgedrag

Diepte is geen vlag. Er bestaat geen --depth 3 in Nutch; diepte is simpelweg het aantal generate → fetch → parse → updatedb-rondes dat je uitvoert, omdat ronde R de frontier ophaalt die in ronde R-1 is ontdekt. Mijn diepteketen bevestigde dat precies:

Netjes en mechanisch, maar het betekent dat diepte een lus-telling in je script is en geen parameter.

Nu de valkuil. De standaardinstelling die Nutch meelevert is db.ignore.external.links=false, gecombineerd met een permissieve +.-URL-filter — wat betekent dat een standaard Nutch-crawl links buiten je seed-host gewoon volgt. Ik seedde een pagina met één in-scope pad en één link naar een andere host, en de crawl haalde die externe host op. Twee onafhankelijke signalen kwamen overeen: Nutch’s eigen crawldb markeerde het als db_fetched, en de servercounter van de andere host registreerde de hit.

Binnen scope blijven is opt-in, en beide oplossingen werken aantoonbaar:

Als je één site crawlt, stel dan vóór je eerste echte run één van deze twee in. Eén methodologische kanttekening: deze test is gevoelig voor de belasting op de lokale server, dus die drie rijen komen uit een run waarin verder niets die fixture aanraakte. Het gedrag zelf is mechanisch duidelijk en wordt door twee onafhankelijke signalen ondersteund; de concrete rijwaarden komen uit één schone run, niet uit een gemiddelde van vele.

Sitemaps zijn een aparte stap. Politeness staat aan — een normale crawl haalde /robots.txt op — maar de sitemap zelf heeft een eigen commando nodig:

Een ander model dan crawlers die known files inline ophalen, en je betaalt ervoor met een extra commando, maar het doet het werk volledig.

Twee kleinere gedragingen hielden zich goed.

Foutafhandeling: een crawl over een pagina met links naar een 500 en een 404 liep alle rondes netjes af, haalde nog steeds alle vier klasse-A-pagina’s op, en registreerde beide fouten afzonderlijk:

Niets ontspoorde.

Politeness: met één thread per queue volgde de pauze tussen fetches van dezelfde host de ingestelde waarde:

De knop doet precies wat hij zegt. De standaardinstelling is 5.0 seconden, wat conservatief is en, opnieuw, waarschijnlijk juist voor een tool die ontworpen is om de servers van anderen netjes te benaderen.

De batchbelasting, in seconden

Elke Nutch-opdracht is een verse JVM. Dat ene feit bepaalt de timing meer dan welk aspect van het fetchen dan ook.

De effectieve ondergrens per job — JVM-start plus Hadoop-initialisatie, gemeten als de goedkoopste fase met triviaal werk — ligt rond 1.77 seconden. Vermenigvuldig dat met vier opdrachten per ronde, tel de initiële inject erbij op, en het totaalplaatje voor een crawl ziet er zo uit:

Dat verschil zit niet in fetch-throughput; beide tools vragen dezelfde handvol pagina’s op. Het is architectuur. Nutch betaalt per fase een vaste proceskost, omdat die fasen als MapReduce-jobs zijn ontworpen. Op een kleine lokale crawl domineert setup. Die vaste kost zou bij een langere job een kleiner aandeel moeten worden, maar deze test heeft niet gemeten vanaf welk schaalniveau Nutch en katana elkaar kruisen, of hun verhouding ooit omdraait.

Voor- en nadelen

Voordelen

• Deterministische statische ontdekking: 4/4 HTML-klassen, 3/3 diepteketen, identiek over drie herhaalde runs.
• parse-js herstelt JavaScript-file-literal-endpoints (2/2) zonder browser, en pakt zowel call-argument- als assignment-vormen mee.
• Twee geverifieerde scopecontroles die een crawl volledig beperken (db.ignore.external.links en hostregel in regex-urlfilter).
• Sitemap-inname via bin/nutch sitemap behaalde volledige 2/2 recall op endpoints die een normale crawl volledig miste.
• Robuust bij fouten: 500 en 404 werden elk met een eigen crawldb-status afgehandeld, crawl ging door.
• In deze lokale run kwam het gemeten interval tussen requests naar dezelfde host overeen met de ingestelde 1.0-secondevertraging; de standaard is 5.0 seconden.
• Apache-2.0, actief onderhouden, 78 plugins en een persistente crawldb die per-URL-status over rondes heen bewaart.
• Draait in lokale modus zonder cluster, HDFS of Solr nodig.

Nadelen

• Draait niet op JDK 24 of hoger, waar het verwijderen van de SecurityManager toeslaat (ik mat de fout op 26.0.1) — de meegeleverde Hadoop 3.4.2 loopt vóór op de upstream fix en de escape-vlag bestaat niet meer, dus een vastgepinde LTS-JDK is een harde voorwaarde, geen voorkeur.
• ≈396 MB uitgepakt, 188 library-jars, 78 plugindirectories, 35 configuratiebestanden.
• Een frisse JVM per opdracht betekent ~1.77 s vaste overhead per fase; ~45 s voor een crawl van diepte 4 over 12 pagina’s tegenover ~13 s voor een single-binary crawler op identieke grond.
• De standaardconfiguratie volgt links naar externe hosts; binnen één site blijven is opt-in.
• http.agent.name wordt leeg meegeleverd en de fetcher weigert te draaien tot je het instelt.
• Geen diepte-vlag — diepte is een lus-telling die je zelf beheert.
• Runtime-DOM-endpoints waren in elke geteste configuratie onbereikbaar, en een JS-uitvoerend protocol erin zetten was geen drop-in wijziging.
• Ik testte lokale modus op één host met een kleine fixture. Gedistribueerde/HDFS-modus, Solr-indexing, hostdb, resume en incrementele re-crawl-planning vielen buiten deze ronde — zie dat hier dus als ongetest, niet als bevestigd.

Wie het wel moet gebruiken, en wie beter kan afhaken

Nutch is de moeite waard wanneer de crawl zelf het moeilijke deel is. Als je een zoekindex bouwt, een brede multi-domain crawl uitvoert, een persistente URL-database met per-URL-status en retry-semantieken nodig hebt, of verwacht het werk later over meerdere machines te verdelen, dan is dit infrastructuur die die specifieke taak al doet sinds vóór de meeste alternatieven bestonden. Het plugin-systeem laat je protocol-, parser-, filter- en scoringgedrag aanpassen zonder iets af te takken. De politeness-defaults zijn zo conservatief dat het lijkt alsof de beheerders echt hebben nagedacht over goed gedrag op andermans servers.

Haak af als je gestructureerde data uit een handvol pagina’s wilt halen. Nutch haalt en parseert ze wel, maar levert je daarna een crawldb en segmenten en verwacht dat jij een indexer meebrengt. Haak af als je doel client-gerenderde single-page apps zijn — klasse C bleef in alles wat ik draaide onbereikbaar. Haak af als je team geen JVM runt, want dan voeg je een Java-toolchain, een vastgepinde LTS-JDK en 396 MB aan jars toe aan een stack die dat nu niet heeft. En als de workload neerkomt op “één site, vier niveaus diep, eens per week”, dan ben je meer tijd kwijt aan de rondes en configuratiebestanden dan de crawl verdient.

Voor de meeste mensen die een scraper zoeken, is dát laatste precies de situatie. En dat is geen kritiek op Nutch — het is een mismatch tussen tool en klus. Wil je een breder beeld van het veld, dan behandelen onze rondleiding langs open-source scrapers en de beste web scraping GitHub-projecten het lichtere segment uitgebreider.

Alternatieven, inclusief waar onze eigen stack past

Eerst de eerlijke framing: Nutch is gratis, Apache-gelicentieerd, self-hosted en voor altijd van jou te draaien zonder kosten per request. Dat is een echt voordeel, en niets hieronder doet daar iets van af.

Gerelateerde review: Browsertrix Crawler review.

Binnen de open-sourcewereld hangt de vergelijking af van wat je optimaliseert. Als je een Python-framework wilt met crawlcontrole en een request-first filosofie, dan is Scrapy voor veel projecten een nauwere analogie; deze review heeft de install-footprint daarvan niet op dezelfde manier gemeten. Als je een compacte Go-crawler zonder browser zoekt, is Colly een andere vorm om te bekijken. Als je probleem is om pagina’s om te zetten naar LLM-klare content in plaats van URL’s te ontdekken, dan mikt Crawl4AI op een andere laag.

Een managed service zoals Thunderbit verplaatst het ophalen, renderen en extraheren achter een API, terwijl Nutch crawlstatus en infrastructuur in eigen hand houdt. Thunderbit is niet op deze fixture getest, dus dit is een vergelijking in eigenaarsmodel en geen claim over gelijke recall of prestaties op dynamische pagina’s.

De afweging is eigenaarschap versus overhead, en dat is niet subtiel. Nutch geeft je volledige controle, een persistente crawldb, schaalbaarheid via clusterdesign en nul marginale kosten — in ruil voor een JVM, een vastgepinde LTS-JDK, 396 MB aan jars, een ronde-loop en je eigen indexinglaag. Een managed API geeft je bij de eerste call gestructureerde output en geen infrastructuur — in ruil voor prijs per call en minder controle over de crawl frontier. Als je taak is “50 miljoen pagina’s indexeren”, dan klopt het model van Nutch en zou een API absurd zijn. Als je taak is “tegen donderdag gestructureerde records uit 200 productpagina’s halen”, dan geldt het omgekeerde.

Probeer Thunderbit voor webdata-extractie

Conclusie

Apache Nutch is het evalueren waard als je een doorlopende crawl over meerdere domeinen draait en al JVM-infrastructuur beheert. Op deze testset was de statische ontdekking deterministisch over herhalingen, parse-js vond beide letterlijke JavaScript-endpoints, fouten bleven in de crawldb zichtbaar en de gemeten request-afstand kwam overeen met de ingestelde vertraging.

Wees eerlijk over de instapkosten. Nutch 1.22 faalde hier op JDK 26.0.1; OpenJDK 17.0.20 is de LTS-configuratie die in deze review daadwerkelijk is geverifieerd, terwijl Java 21 niet getest is. Stel daarna http.agent.name in, bepaal je scope expliciet en houd rekening met de gemeten vaste ondergrens van ongeveer 1.77 seconden per fase in deze kleine lokale run. Of die trade-off logisch is, hangt af van de duur, breedte en de behoefte aan persistente status van de crawl.

Probeer Thunderbit voor webdata-extractie Get Started Free

FAQ’s

Waarom faalt Apache Nutch met "getSubject is not supported"? Op JDK 24 of nieuwer maakte JEP 486 dat Subject.getSubject() altijd een uitzondering gooit, terwijl de meegeleverde Hadoop 3.4.2 die methode nog aanriep. Daardoor crasht de eerste Hadoop-job nog vóór er een pagina wordt opgehaald, en de oude uitweg -Djava.security.manager=allow start de VM niet meer. Gebruik de geverifieerde Java 17-configuratie en zet NUTCH_JAVA_HOME; Java 21 kan ondersteund zijn, maar deze review heeft daar niet de volledige cyclus op gedraaid.

Welke Java-versie moet ik gebruiken voor Nutch 1.22? Java 17 is het veiligste antwoord — de eigen CI van Nutch richt zich daarop en het werkte probleemloos in mijn test met OpenJDK 17.0.20. Java 11 blijft ook nog ondersteund voor 1.22, al heeft het project aangekondigd dat 1.23 Java 17 zal vereisen. Alles vanaf JDK 24 werkt niet. Een keg-only Homebrew-installatie (brew install openjdk@17) plus NUTCH_JAVA_HOME laat je systeemstandaard-JDK ongemoeid.

Kan Nutch JavaScript-zware sites crawlen? Gedeeltelijk, en dat onderscheid is belangrijk. Met de parse-js-plugin ingeschakeld vond Nutch beide endpoints die alleen als string-literals in een gekoppeld JavaScript-bestand bestonden — 2/2, zonder browser. Met de standaard plugin-set vond hij die niet. Maar een endpoint dat pas verschijnt nadat JavaScript draait en de DOM wijzigt, bleef in elke statische configuratie die ik testte onbereikbaar, en het vervangen door het HtmlUnit-protocol was in mijn run geen drop-in wijziging. Voor client-rendered apps moet je dus rekenen op een JS-uitvoerend protocol plus serieuze configuratie, of op een ander hulpmiddel.

Heeft Nutch Hadoop en Solr geïnstalleerd nodig? Nee. De lokale modus draait Hadoop’s in-process LocalJobRunner — geen cluster, geen HDFS-daemon, geen YARN — en de volledige inject → generate → fetch → parse → updatedb-cyclus werkt op één machine zonder dat verder iets geïnstalleerd hoeft te zijn. Solr is wel de gebruikelijke bestemming voor indexing, maar de crawl zelf heeft het niet nodig. Wel worden Hadoop-jars meegeleverd (13 stuks, versie 3.4.2), en precies daarom bestaat het JDK-compatibiliteitsprobleem überhaupt.

Hoe voorkom ik dat Nutch andere websites crawlt? Stel het expliciet in, want de standaard doet dat niet. Nutch 1.22 wordt geleverd met db.ignore.external.links=false en een permissieve URL-filter, en in mijn test volgde de standaardcrawl een link naar een andere host en haalde die op. Zet óf db.ignore.external.links=true in nutch-site.xml, óf voeg een hostregel toe aan conf/regex-urlfilter.txt (bijvoorbeeld +^https://example\.com/ gevolgd door -.). Beide hielden de crawl in mijn tests volledig binnen scope, geverifieerd via zowel Nutch’s eigen crawldb als het requestlog van de andere server.