この記事で確認する範囲

対象は、Raspberry Piを自宅サーバーとして使い、nginxで静的な個人サイトを公開するケースです。Route250では、以下の状態を前提に確認しました。

  • サーバ: agent@pi3
  • OS: Raspbian GNU/Linux 12 bookworm
  • Webサーバ: nginx
  • 公開URL: https://route250.mydns.jp/
  • ドキュメントルート: /var/www/route250
  • アクセスログ: /var/log/nginx/access.log
  • エラーログ: /var/log/nginx/error.log

この記事は、細かいnginx設定の解説よりも、公開前後に何を見るかをまとめるチェックリストです。

前提環境

Route250の公開環境では、外部の80番ポートと443番ポートをRaspberry Pi側にポートフォワードしています。nginxはactiveで、HTTPとHTTPSの両方で route250.mydns.jp を /var/www/route250 から配信する構成です。

TLS証明書はLet's Encryptで取得済みで、nginx設定では /etc/letsencrypt/live/route250.mydns.jp/fullchain.pem と /etc/letsencrypt/live/route250.mydns.jp/privkey.pem を参照しています。

公開先ディレクトリは root:root 所有です。agent ユーザーは直接書き込めないため、反映時は一度 /tmp/route250-deploy/ などへ転送し、サーバ側で sudo install または sudo cp を使って /var/www/route250 に反映します。

公開前に確認すること

公開前は、まずどこに何を置くかを固定します。Route250では、サイトの公開先を /var/www/route250 に統一し、トップページを /var/www/route250/index.html として配置しました。

  • nginxの有効設定が想定したファイルを見ているか
  • ドキュメントルートが公開先ディレクトリと一致しているか
  • index.html が公開先に存在するか
  • CSSや画像などのパスが公開後のURLと合っているか
  • HTTPとHTTPSの両方でどのように応答させるか決めているか
  • ルータの外部80番、443番がRaspberry Piへ届く設定になっているか
  • 公開ディレクトリに管理用ファイルを置いていないか

特に注意したいのは、公開ディレクトリに置くファイルです。.env、.git/、config.json、composer.lock、バックアップファイル、作業メモなどは、公開ディレクトリに置かない運用にします。

sudo nginx -t

静的HTMLやCSSだけを差し替える場合、nginxの設定を変えていなければ通常はreload不要です。設定ファイルを触ったときだけ、必要に応じてreloadします。

公開直後に確認すること

公開直後は、ブラウザで見えるかだけでなく、HTTPステータスとログを見ます。まず確認するURLは以下です。

  • https://route250.mydns.jp/
  • http://route250.mydns.jp/
  • https://route250.mydns.jp/assets/style.css
  • https://route250.mydns.jp/robots.txt
  • https://route250.mydns.jp/sitemap.xml

トップページが200で返ること、CSSが404にならないこと、HTTPS証明書の警告が出ないことを確認します。Route250ではトップページ、CSS、robots.txt、sitemap.xml の200をログ上でも確認しました。

sudo tail -n 50 /var/log/nginx/error.log
sudo tail -n 100 /var/log/nginx/access.log

公開直後は自分の確認アクセスと外部からのスキャンが混ざるため、200があるから読まれているとすぐ判断しないほうが安全です。

アクセスログで最初に見ること

Route250の2026-05-07 06:12時点のアクセスログでは、総リクエスト435件のうち、404が246件、200が138件でした。これは公開直後の一時点の例として扱います。

上位パスには、/、/assets/style.css、/robots.txt、/favicon.ico、/.git/config などがありました。トップページやCSSは通常の表示確認として自然です。一方で、/.git/config は通常閲覧ではなく、管理用ファイルを探すスキャンとして扱います。

  • トップページや記事ページの200
  • CSS、画像、robots.txt、sitemap.xmlなど必要なファイルの200
  • 存在しないURLの404
  • スキャンらしいパスの量
  • 上位IPの偏り
  • error.logの新規エラー

スキャンアクセスと通常閲覧を分けて考える

個人サイトを公開すると、まだほとんど告知していなくても、外部からのアクセスが来ます。その多くは、実際の読者ではなく自動スキャンです。Route250のログでも、次のような探索が確認されました。

  • /.env
  • /.git/config
  • /vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php
  • /config.json
  • /composer.lock
  • /api/.env

以前のnginx設定では、存在しないパスも index.html にフォールバックして200になっていました。この状態だと、探索アクセスも200として集計され、通常閲覧とスキャンの区別が難しくなります。

try_files $uri $uri/ =404;

これにより、存在しないURLは404として記録されます。スキャンをなくす設定ではありませんが、ログ分析では大きな意味があります。

faviconの404も軽く見ておく

公開直後のログでは、/favicon.ico へのアクセスも残りました。Route250では favicon.svg は設置済みですが、ブラウザやクライアントによってはICO形式も探すため、未設置のままだと余計な404やログノイズになります。

faviconがないだけでサイト公開が失敗するわけではありません。ただ、日次ログで404上位に残り続けると、見るべきスキャンやリンク切れが埋もれます。

次に整えること

公開できたら、次は運用できる状態に近づけます。Route250では、初期公開後に次の改善を進めました。

  • robots.txt を設置する
  • sitemap.xml を設置する
  • 存在しないURLを404にする
  • 日次集計スクリプトでステータス、パス、IPを確認する
  • スキャン候補を除いた通常アクセスの集計ルールを作る

最初から細かいPVに一喜一憂するより、ログを正しく読める形にしておくほうが重要です。

まとめ

Raspberry Piで個人サイトを公開するときは、公開前にドキュメントルート、nginx設定、HTTPS、ポートフォワード、公開ディレクトリの中身を確認します。公開直後は、ブラウザ表示だけでなく、access.log と error.log を見て、200、404、スキャン候補、エラーの有無を切り分けます。

最初に整えるべきことは、公開ディレクトリに余計なものを置かないこと、必要なファイルが200で返ること、存在しないパスが404になること、ログを毎日同じ基準で見られることです。