Keywords

katana review, web scraping, open source, benchmark

Content

Katana は ProjectDiscovery のエンドポイント発見用クローラーです。Go で書かれた MIT ライセンスのバイナリで、対象を指定すると URL やエンドポイントを返し、次のツールへつなぐ前提で使えます。ブラウザを使わない HTTP モード、または Chromium を動かす -headless モードで巡回できます。公式の案内では headless のほうがより広く拾えるとされていますが、この検証用サイトを見ると、件数だけでなく「どんな種類のエンドポイントか」も重要だと分かります。

私は、意図的に性質の異なる3種類のエンドポイントを含む小さなサイトを用意し、v1.6.1 の -d 4 で各モードが何を見つけるかを測定しました。通常の HTML は、どの構成でも 4/4 のリンクと 3段階のチェーンをすべて拾えました。差が出たのは、JavaScript ソースに埋め込まれたものと、実行時に DOM が変化して現れるものです。

この検証では、headless はブラウザレス実行では見逃した runtime DOM 系のエンドポイントを拾いました。一方で、標準モードに -jc を付けると、headless の2パターンでは取れなかった JavaScript ファイル内のリテラルを拾えました。4つのコマンド構成のどれを見ても、両方のクラスを同時にカバーするものはありませんでした。さらに、スコープ、resume、known-files には別の実用上の制約もありました。

Katana とは何か

Katana クローラー — GitHub の projectdiscovery/katana — は Go 製で MIT ライセンスです。私は v1.6.1 を 2026年7月27日に検証しました。バージョンを明記するのは、下記の coverage と known-files の結果がビルド依存の観測だからです。

ここではカテゴリの理解がいつも以上に大事です。エンドポイント発見用クローラーは、フィールド抽出ツールではありません。たとえば、Go 製の Web クローラーに商品名や価格を構造化 JSON で返してほしいなら、katana は用途が違います。/products/1138 が存在することは教えてくれても、そのページの中身については何も教えてくれません。それが設計思想ですし、抽出性能で評価するのは、金属探知機に宝石の鑑定を求めるようなものです。

得意分野は、攻撃的セキュリティの調査や自動化パイプラインです。STDIN で受けて URL を吐き、次のツールへパイプする。そこで当然の注意点があります。ここでの測定はすべて、私自身が書いた 127.0.0.1 上の検証用サイトに対して行いました。katana を使うのは、所有している、または明確な許可を得ている対象だけにしてください。ここで扱うのは防御の回避ではなく、あるコマンドが対象のエンドポイント面をどれだけ列挙できるか、という話です。

3つのモードと、それぞれに見えるもの

標準モードは Go の HTTP クライアントです。HTML を取得して解析し、href をたどります。ブラウザは起動しません。高速で軽い一方、JavaScript 実行後にしか存在しないものは見えません。

-jc（-js-crawl）は、そのブラウザレス経路に JavaScript パーサーを追加します。リンク先の .js ファイルを取得し、ソース内の URL っぽい文字列リテラルを抜き出します。実行はせず、読むだけです。README には -jsl（jsluice）もあり、より重くメモリを使うパーサーとして説明されていますが、私は試していないので、coverage に違いが出るかは分かりません。

-headless は Chromium を動かし、ページのスクリプトを実行します。この検証では、断片を組み立てて runtime DOM に差し込むパスを復元できたのは、Katana のテスト済みモードの中で headless だけでした。ただし、それで将来の全パーサーや全モードが同じものを拾えるとまでは言えません。

その前に、実運用ではスコープの仕組みを真っ先に頭に入れておくべきです。

順番は見た目の問題ではありません。ホスト用の正規表現がクロール範囲を広げるのか、あるいは何も拾えない状態にしてしまうのかを決めます。

セットアップ: 1つのバイナリ、ただし例外が1つ

導入方法は3つあり、そのうちツールチェーンが必要なのは1つだけです。

私の環境では ~/go/bin/katana に入り、毎回 Current version: v1.6.1 と表示されました。Go らしい、気持ちのいい話です。1ファイルで済み、ランタイムもいりません。

例外は headless です。こちらはバイナリとは別にブラウザが必要になります。

素のサーバーでは、この手軽さは消えます。-headless を使うなら、バイナリだけでなくブラウザの予算も見ておくべきです。

CI で回すなら、もう1つ知っておくとよい点があります。katana は起動時に GitHub へバージョン確認を行います。-duc でこれを無効化できます。ノート PC なら気にしなくていい程度ですが、ネットワーク遮断環境やレート制限のある runner では、意図しない毎回の往復通信になります。私の計測では -duc を付け、クロール時間だけを測るようにしました。

どうテストしたか

モードによって差が出るように選んだ、3種類のエンドポイントです。すべて ローカルの検証サーバー にあり、実行前にグラウンドトゥルースを記録してからクロールを始めました。そのため recall は、katana がたまたま出力した内容ではなく、固定された正解集合に対して測っています。

• Class A — 通常の HTML。 /page/a、/page/b、/page/c、そして 3段階のチェーン /depth/1 → /depth/2 → /depth/3。どのクローラーでも取れてほしいものです。
• Class B — JavaScript ファイル内のリテラル。 /api/js-endpoint-7 と /api/js-endpoint-8 は、リンクされた /static/app.js の中の文字列リテラルとしてだけ存在します。JS を読みに行く実装なら、ブラウザなしでも見つけられます。
• Class C — 実行時の DOM のみに現れるもの。 'endpoint' + (6 * 7) のように断片から実行時に組み立てられ、スクリプトで DOM に挿入されるパスです。文字列 /runtime-only/endpoint42 は、サーバーが送るどのバイト列にも連続して現れません。HTML にも JS ソースにもありません。実行して初めて見えます。

これに加えて、robots.txt、別の場所には出てこない <loc> エンドポイントを2つ含む sitemap.xml、500 を返すルート、死んだリンク、そして別ホスト名にある第2サーバーへ向いたスコープ外リンクもあります。

検証で重要なのは、フィクスチャだけではありません。サーバー側が 実際に取得されたもの を数えるので、スコープや resume の主張は katana 自身の stdout ではなく、ヒットの真実に基づいています。生の実行結果は、計算を確認したい方のために benchmark repo に置いてあります。

誰も数えていない coverage の分岐

-d 4 での、モード別・クラス別のマトリクスです。

最後の2列を並べて見ると、問題がはっきりします。Class B を拾えたのは、standard に -jc を付けた構成だけでした。Class C を拾えたのは、headless の2構成だけでした。両方の列でヒットする行はありません。全体のマトリクスは discovery-summary.json にあり、計算済みの headless_jc_covers_both は false になっています。

実用上の結論は、「coverage を上げたいなら headless を使えばよい」という話では不十分だった、ということです。このテストでは headless を使っても Class B は増えず、その代わり Class C を回収しましたが、Class B は取りこぼしました。フィクスチャに植えた全クラスを網羅するには、2回クロールしてマージする必要がありました。

katana -u https://target.example -jc -d 4 -silent -o pass-jc.txt
katana -u https://target.example -headless -d 4 -silent -o pass-headless.txt
sort -u pass-jc.txt pass-headless.txt > endpoints.txt

-headless -jc の行は、上流にぜひ説明してほしいところです。headless 実行に JavaScript パーサーを足しても、何も増えませんでした。Class B は毎回 0/2 のままで、再現し直しても同じでした。ここでは挙動を報告しているのであって、なぜブラウザ経路で JS ファイルのリテラルが拾われないのか、その仕組みを追い切ったわけではありません。katana の内部を計測して原因を突き止めたわけではないので、再現可能な観測結果として、GitHub Issue に向いた話だと考えてください。（関連して、v1.6.1 の macOS ARM では -hl -jc の組み合わせが return code 0 で問題なく完了しました。これは昔から常にそうだったわけではありません。）

公式ドキュメント では、headless はより高い coverage を与えると説明されています。実際この検証では runtime render 系のクラスに対してその通りでした。ただし、チェックしたガイドには source literal と runtime DOM の分岐までは書かれていませんでした。したがって、このマトリクスは「自分の対象クラスで両方の経路を試せ」という判断材料であって、万能の分類法ではありません。

headless にかかる実時間コスト

アイドル状態のマシンで、各モードを 3回ずつ連続実行しました。

比率は 5.1倍 で、範囲もまったく重なりません。standard の最遅（13.17秒）でも、headless の最速（66.78秒）より53秒以上速かったのです（cost-summary.json）。測定ノイズではありません。

13秒という値には1つ補足があります。私のフィクスチャには 500 を返すルートと死んだリンクが意図的に入っており、standard は両方でデフォルトの -timeout 10 のリトライ尾を待ちます。高速モードを有利にするためにタイムアウトをいじったわけではありません。つまり、もし調整していたら standard 側はむしろ差を縮めるのではなく、差を広げていた可能性が高いです。

この比率は、ローカルでのキャパシティ指標であって、実運用の予測ではありません。実際の対象は、レイテンシ、失敗率、スクリプト処理、スケジューリングがそれぞれ違いますし、このフィクスチャにはデフォルトのタイムアウト尾があります。測定された 5.1倍という差は、headless に別予算と別対象セットが必要かを決める材料として使い、その後は代表的で権限のあるホストでその計画をベンチマークしてください。

スコープは守られたが、1つのフラグは静かに何もしなかった

スコープのテストでは2台のサーバーを使いました。1台目は 127.0.0.1、2台目は別ポートの localhost で、そのサーバーにしか存在しない パスを提供しています。したがって、そのパスへのヒットは、スコープ外ホストが単に表示されたのではなく、本当に取得された証拠になります。

スコープの厳格さは良いニュースです。デフォルトでは katana は自分の範囲内にとどまり、広げるには明示的な操作が必要でした。これは、他人のインフラに向けるツールとして正しい既定値です。

注目すべきは -cs localhost の行です。これでは第2ホストへクロールは広がりませんでしたし、URL も 1つも出力されませんでした。-cs は field scope の内側だけを絞り込むので、field scope はまだ主要ホストのままです。そのため正規表現が何にも一致せず、エラーではなく空集合が返ったのです。もし、含めたいホスト名を scope 用正規表現に書いたのに出力ファイルが空で首をかしげたことがあるなら、その仕組みです（scope-summary.json）。ホストを追加したいなら -fs を使います。既にあるホスト内でさらに絞るなら -cs / -cos を使います。

resume はフラグ名ほど細かくない

README には -resume string resume scan using resume.cfg とあり、作業ディレクトリに resume.cfg が置かれるように読めます。しかし実際は違いました。私の環境ではチェックポイントは ~/.config/katana/resume-<xid>.cfg に書かれていました。これはドキュメントにパスの記載がないので、資料ではなく実測です。

さらに重要なのは、その中身です。ファイルに入っていた InFlightUrls マップには、seed URL が1つだけ入っていました。visited set でも frontier でもありません。そこで、3秒後に SIGINT でクロールを中断し、resume したときに起きたことはこうです。

resume は最終的なエンドポイント集合を同じにしてくれたので、壊れているわけではありません。ただし、チェックポイントの粒度は URL 単位ではなく seed 単位 です。メモリ上の重複排除フィルタは永続化されないため、単一 seed のクロールを resume すると、その seed を最初から再クロールします（resume-summary.json）。もし katana に 500 ホストを渡すなら、resume が節約するのは完了済みのホストでしょう。その多 seed の挙動は状態の保存方法から推測できますが、私が測ったのは単一 seed のケースだけです。巨大サイトを1つ深く掘る場面では、resume は時間ではなく正しさを買う機能です。

known files: 要求はされたが、その後落ちた

-kf all -d 3 は確かに両方のファイルを要求しました。robots.txt と sitemap.xml はサーバーのヒットログに出ています。ところが、その sitemap の <loc> 要素に列挙されていたエンドポイントは 0/2 しか回収できませんでした。recall は 0.0 です。

これを限界だと言い切る前に、自分の設定ミスを疑っていろいろ試しました。どれも同じ結果でした。

ドキュメント上の要件、つまり -kf を使って、少なくとも深さ 3 まで潜る、という条件は毎回満たしています。これはフラグ不足の話ではありません。

実務で先に決めるべきなのはこれです。この IP リテラルの検証サイトでは、known files を要求したからといって、その <loc> URL までクロールに入ると決め打ちしないでください。recall を検証するか、あるいは自分で抽出して seed に渡してください。

v1.6.1 のコードパスはこの観測と整合していますが、実行中に内部計測はしていません。v1.6.1 の sitemapxml.go では、NewNavigationRequestURLFromResponse が <loc> のナビゲーションリクエストを、RootHostname が入っていない response から組み立てています。その後 request は ValidateScope に届きます。v1.6.1 の scope.go では、IP リテラルの分岐が URL の host と空の root を比較し、弾く可能性があります。別のスコープテストで使ったカスタム -fs '(127.0.0.1|localhost)' は別の分岐に入るので、ソースから予測できる救済策ではありますが、-kf の回避策として測定確認したわけではありません。known-files クライアント側でこのホストは断続的な接続失敗があり、確認試行は止まりました。そのため、報告値は引き続き 0/2 です。

実運用で私ならどうするかというと、まず sitemap を自分で取得し、<loc> の URL を抽出して、そのまま katana の seed リストとして渡します。シェル2行で済み、スコープ検証を経由しません。

1つ、記述どおりに正しく動いた点があります。500 のルートと死んだリンクは取得され、ログに残り、そのまま跨いで進みました。ブラウザレスの実行はすべて return code 0 で終わりました。最初の異常応答で落ちるクローラーは、無人運用では役に立ちません。katana はそうではありません。

導入前に、自分の対象で coverage を確認する

この検証マトリクスは、自分の権限下にある対象でテストするためのテンプレートとして最も役立ちます。Katana を回す前に、エンドポイントの種類を定義してください。通常リンク、リンク先のスクリプトにあるリテラル、実行後にしか生まれないルート、known-file のエントリは、妥当な最初の分類です。各クラスについて小さな正解サンプルを持っておきましょう。事前リストがないと、より大きな stdout ファイルが、あるクラスを見落としているのに coverage が良くなったように見えることがあります。

まずは browserless と headless を別々の測定として実行してください。コマンド、Katana のバージョン、ブラウザのビルド、return code、出力をそのまま保存します。行数で比較するのではなく、正規化して endpoint 集合を diff してください。サンプルで standard の -jc が何も追加しないなら headless のみでも十分かもしれません。ここで見たように集合が分かれるなら、2回の実行を別々に保ち、取得後にマージします。1つのコマンドに両方のフラグを付けたからといって、対象ごとの差分が証明されるまでは和集合と同じだとは思わないでください。

スコープの検証は、Katana の出力以外の証拠でも確認してください。除外されるべきホストにカナリア URL を置き、そのサーバーのリクエストログを見ます。クロールを広げる予定なら、意図した第2ホストでも同様に確認します。ここでの -cs localhost は、content scope の絞り込みが field scope を広げないため空出力になりましたが、カスタムの -fs '(127.0.0.1|localhost)' は第2サーバーへ接続しました。正規表現は1文字違うだけで見た目ではなく意味が変わるので、実際の式をそのまま記録することが重要です。

中断と known files は、探索の recall とは分けてテストしてください。resume では、代表的な seed を数ページ進めたところで中断し、生成された checkpoint のパスを保存し、完了済み URL が何件再取得されるかを数えます。-kf では、robots/sitemap を要求したことと、植えた <loc> URL が実際にスケジュールされたことの両方を確認します。これは別の主張です。このフィクスチャではファイルは取得されましたが、2つの sitemap エンドポイントは欠落しました。境界を見るには、リクエストログとエンドポイント出力の両方が必要でした。

最後に、アイドル状態のマシンで連続実行してローカルのコスト基準を作り、その後で代表的なホストでも繰り返してください。倍率だけでなく、最小・最大・中央値を残します。ここでの 5.1倍という数字には、このフィクスチャ特有の失敗とタイムアウト挙動が含まれます。つまり、headless に独立した予算が必要だということは分かっても、実運用のインベントリに何分かかるかまでは分かりません。

長所と短所

長所:

• どのモードでも通常の HTML に対する recall が完璧。4/4 リンクと 3/3 の深さチェーンを、追加設定なしですべて回収。
• -jc はブラウザレスでも本当に効く。リンク先 JS ファイル内の文字列リテラルから 2/2 エンドポイントを回収でき、ブラウザコストは不要。
• -headless は実行時に組み立てられるエンドポイントを見つけた唯一の手段。ソース解析では構造上見えないクラスを拾える。
• スコープのデフォルトは保守的。スコープ外ホストは、デフォルトでも -fs fqdn でも -cs でも取得されなかった。
• 単一の Go バイナリ、MIT ライセンス、事前ビルド版と Docker イメージあり、パイプライン向きの I/O。
• 失敗に強い。500 や死んだリンクでクロールが止まらない。

短所:

• 1回の実行では、JS ファイル系と runtime DOM 系の両方を同時にカバーできなかった。完全な coverage には2回の実行とマージが必要。
• -jc は -headless の下では何も足さなかった。headless 実行では Class B が毎回 0/2。
• headless は wall time が 5.1倍かかる（p50 66.82秒 対 13.08秒、範囲も重ならない）。
• -resume は seed 内の完了済みページを再クロールする。endpoint set は復元しても、経過時間は戻らない。
• known files は robots.txt と sitemap.xml を要求したが、IP 対象では sitemap の <loc> エンドポイント 0/2 だった。
• headless には結局 Chromium が必要で、「1つのバイナリ」の話はブラウザまででは終わらない。
• あくまで探索専用。構造化抽出も、内容変換も、フィールドスキーマもない。

未検証、したがってこれらの数値の対象外なのは、-jsluice、-d 1 / -d 2 での専用の深さ制限テスト、multi-seed resume、自動フォーム入力、そして実際の JavaScript が重い保護済み本番サイトです。すべての数値は、1台のマシン（macOS arm64）でローカルの検証サイトに対して得られたものです。

どんな人向けか、誰が避けるべきか

権限のあるインフラのエンドポイント一覧を作るのが仕事なら、katana には適切なパイプライン形状があります。STDIN/STDOUT のつなぎやすさ、配布可能なバイナリ、ブラウザレスとブラウザ付きの両モードです。この検証では 2回の実行とマージが必要でしたが、あなたの対象でも両方要るかは、代表的なページで確かめるべきです。

URL ではなくデータが欲しいなら、使うべきではありません。Katana は商品一覧表を返してはくれません。商品があり得る URL を返すだけで、抽出は別のツールの仕事です。1回のコマンドで完結する必要がある場合も向きません。2回走らせてマージするのはパイプラインでは問題なくても、対話実行だと面倒です。さらに、IP を対象にしながら sitemap の <loc> エンドポイントに頼って列挙しているなら、出力を信じる前に実際に何が取れているか検証してください。私のフィクスチャでは、その経路は何も返しませんでした。

代替案と、抽出との境界

Katana は無料で、MIT ライセンスで、セルフホストできます。探索、モード選択、ブラウザの配備、結果のマージを、自分の側で管理できます。

オープンソースの中では、比較は言語より役割で見るほうが有益です。Colly は別の Go 製選択肢ですが、これは自分でコールバックを書くライブラリで、JavaScript のレンダリングはしません。Crawl4AI は実ブラウザを使い、LLM パイプライン向けに Markdown を出力します。出力の性質がまったく異なります。複数の候補を同時に検討するなら、オープンソースのスクレイパー総まとめ でカテゴリを並べて比較できます。

開示事項: Thunderbit は公開元の製品であり、この Katana の検証ではテストしていません。Thunderbit は、管理された抽出カテゴリの下流にあり、ページをテキストや構造化レコードに変換するもので、許可された対象のエンドポイント面を列挙するものではありません。ワークフローの中で両方を使うことはありますが、このレビューが証拠として扱うのは Katana の探索挙動だけです。

Web データ抽出に Thunderbit を試す

結論

権限のある対象をクロールしてエンドポイント一覧を作るのが目的で、その対象に対するモード別の coverage を検証できるなら、katana を使う価値があります。この検証では、標準の -jc が植えた JavaScript ファイル内リテラルを回収し、headless が runtime DOM のエンドポイントを回収しました。テストしたブラウザレスモードは、その runtime パスを拾えませんでした。デフォルトのスコープは第2ホストを未取得に保ち、ブラウザレス実行は 500 と死んだリンクを越えて進みました。

注意点は運用面です。混在したエンドポイントクラスでは2回の実行とマージが必要になることがあり、headless はローカル実行時間で約5倍かかり、単一 seed の resume は完了済みパスを再取得し、known files の recall は IP 対象に対して 0/2 でした。これらは v1.6.1 のフィクスチャ結果であって、すべてのサイトに対する保証ではありません。ただし、本番評価で確認すべき点を定義するには十分です。

Web データ抽出に Thunderbit を試す Get Started Free

よくある質問

katana の resume ファイルはどこに保存されますか？ また、resume すると既に巡回したページは飛ばされますか？
チェックポイントは、フラグのヘルプが示すような作業ディレクトリ内の resume.cfg ではなく、~/.config/katana/resume-<xid>.cfg に保存されました。さらに、完了済みページは飛ばされません。ファイルには進行中の seed URL しか入らないため、単一 seed の resume では、既に完了していた10個を含む基準パス11個すべてが再取得されました。最終的なエンドポイント集合は同じになりますが、節約されるのは時間ではありません。

なぜ -kf all は sitemap.xml を要求したのに、その中の URL をクロールしなかったのですか？
IP 対象に対しては、これはフラグのミスではなくスコープ検証の境界です。Katana の sitemap パーサーは、Root hostname を引き継がないまま各 <loc> のリクエストを組み立て、その後 IP リテラルの DNS スコープチェックで URL の host を空の root と比較し、失敗したものを落とします。私が試したあらゆるフラグ、深さ、seed の組み合わせで recall は 0 のままでした。カスタムの -fs ホスト正規表現は別の検証分岐に入るので、ソース上は修正策として予想されますが、私の環境では -kf で確認できませんでした。今のところは、自分で <loc> URL を抽出して、katana に seed として渡す方法を信頼します。

Katana の coverage テストを報告するとき、何を残すべきですか？
Katana の正確なバージョンとコマンドを、-fs の式まで1文字単位で記録してください。実行前にエンドポイントの分類を定義し、stdout だけでなくサーバー側のヒットログも残します。さらに、実測結果とソースからの仮説は分けて書きます。headless 実行ではブラウザのビルド番号も記録してください。この検証ではそれを残していないため、再現性に制限があります。

-jc、-headless、それとも両方を使うべきですか？
必要なエンドポイントクラスで決めてください。この検証では、standard の -jc が JavaScript ファイル内のリテラルを見つけ、headless が runtime DOM に挿入されたエンドポイントを見つけました。どちらか一方だけで両方をカバーできなかったので、混在ターゲットでは 2回実行して重複排除するのが妥当でした。

1つの失敗 URL でクロールは止まりますか？
この制御された実行では止まりませんでした。Katana は 500 応答と死んだリンクの後も継続し、到達可能な他のパスを返しました。ただし、本番でのエラー管理の代わりにはなりません。失敗リクエストのログを残し、許容可能な失敗率を決めて、部分成功を完全な coverage と誤認しないようにしてください。