サイト公開直後は、しばらく誰もアクセスしないと思っていました。
しかし実際のサーバーログを確認すると、公開からわずか2日後に「curl」によるアクセスが確認されました。
しかもその後、User-Agent（ユーザーエージェント）を変更して通常のページ取得まで行っている挙動も見られます。
この記事では、その一連のアクセスをログから読み解き、最初のアクセスが何をしているのかを解説します。
公開直後に確認されたcurlアクセスのログ
vivisec.net 152.32.225.99 - - [24/Feb/2026:14:37:41 +0900] "GET / HTTP/1.1" 301 228 "-" "curl/7.29.0"
www.vivisec.net 152.32.225.99 - - [24/Feb/2026:14:37:41 +0900] "GET / HTTP/1.1" 400 248 "-" "curl/7.29.0"
www.vivisec.net 152.32.225.99 - - [24/Feb/2026:14:37:52 +0900] "GET / HTTP/1.1" 200 65662 "-" "curl/7.29.0"
vivisec.net 151.115.99.182 - - [25/Feb/2026:01:51:10 +0900] "HEAD / HTTP/1.1" 301 0 "-" "curl/7.81.0"
www.vivisec.net 151.115.99.182 - - [25/Feb/2026:01:51:11 +0900] "HEAD / HTTP/2.0" 200 0 "-" "curl/7.81.0"
www.vivisec.net 151.115.99.182 - - [25/Feb/2026:01:51:11 +0900] "HEAD / HTTP/1.1" 400 0 "-" "curl/7.81.0"curlアクセスの特徴
User-Agentがcurl
curl/7.29.0
curl/7.81.0curlはブラウザではなく、コマンドラインからHTTPリクエストを送るツールです。
つまりこの時点で、人間の閲覧ではなく自動的なアクセスである可能性が高いと分かります。
※メモ
ここで使われているcurlは、Kali Linuxなどで使えるコマンドラインツールと同じもの。自分がCLIで叩いているのと本質的には同じ。
Refererが空
"-"通常のブラウザアクセスではRefererが付くことがありますが、今回のログではすべて空です。
これはリンク遷移ではなく、直接URLを叩いているアクセスです。
HEADリクエストによる確認
HEAD /HEADリクエストは、ページ内容を取得せずにステータスコードだけを確認するためのものです。
つまりこの段階では、
- サイトが存在するか
- 正常に応答するか
だけをチェックしています。
これは攻撃ではなく、サイトの存在確認
これらの特徴から、このcurlアクセスは攻撃ではなく、以下の目的と考えられます。
- ドメインが有効か確認
- Webサーバーの応答確認
- リダイレクト挙動の確認（wwwあり／なし）
実際にログでも、
- 301（リダイレクト）
- 400（異常）
- 200（正常）
といったレスポンスを順に確認しています。
また、同一IP・同一User-Agentにもかかわらず、最初のリクエストでは400エラー、その後のリクエストでは200エラーが返されています。
これはwwwあり／なしの切り替えやHostヘッダの不整合により、一度不正なリクエストとして処理された後、条件が整ったリクエストで正常応答となった可能性があります。
User-Agent変更後のアクセス挙動
次の日の同じ時間帯に、別IPから以下のようなアクセスが確認されました。
www.vivisec.net 51.158.203.239 - - [25/Feb/2026:04:52:23 +0900] "HEAD / HTTP/1.1" 400 0 "-" "curl/7.81.0"
www.vivisec.net 51.158.203.239 - - [25/Feb/2026:04:52:25 +0900] "GET / HTTP/2.0" 301 228 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/134.0.0.0 Safari/537.3"
www.vivisec.net 51.158.203.239 - - [25/Feb/2026:04:52:27 +0900] "GET / HTTP/2.0" 200 15850 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/134.0.0.0 Safari/537.3"ここで注目すべきは、
- 最初はcurlでHEADリクエスト
- その後、ブラウザのUser-Agentに変更してGET
という流れです。
これは、サーバーの挙動に応じてアクセス方法を切り替えている可能性があります。
ページ取得後に画像・CSSを取得している理由
さらにこのアクセスでは、ページ取得後に以下のリクエストが続いています。
GET /wp-content/themes/...css
GET /wp-content/uploads/...webp
GET /wp-content/uploads/...png一見すると「画像にアクセスされている」と感じますが、これは攻撃ではありません。
HTML内に含まれるリソースを取得しているだけです。
ブラウザ（またはそれを模倣したBot）は、
- HTMLを取得
- CSS・画像・JSを解析
- 必要なファイルを順に取得
という動きをします。
つまりこれは、ページを実際に表示しようとしている挙動です。
まとめ｜botのアクセスは段階的に進む
今回のログから分かる流れは以下の通りです。
- curlで軽く存在確認（HEAD）
- レスポンスを確認
- User-Agentを変更して再アクセス
- HTMLを取得
- CSS・画像などのリソースを取得
サイトへのアクセスは、いきなり攻撃が始まるわけではありません。
まずは、存在確認 → 挙動確認 → 実際の取得という段階を踏みます。
ログを1行ずつではなく、流れで見ることで、そのアクセスの目的が見えてきます。