エラーログ監視

アクセスログには、原因が書かれていない

3章で作ったアクセスログには、リクエストの結果が並びます。403 が返ったことは分かりますが、なぜ 403 だったのかは書かれていません。原因が書いてあるのは、もう1つのログのほうです。

error_log /var/log/nginx/mysite-error.log warn;

アクセスログと同じく、server ブロックごとに分けられます。うしろの warn は、どの深刻さから記録するかの指定です。

深刻さには段階がある

記録する水準は、軽いものから重いものへ並んでいます。

• debug — 開発時の細かい情報。量が膨大になる
• info — 通常の出来事
• notice — 気に留めておく程度
• warn — 警告。運用ではここから見る
• error — 処理に失敗した
• crit — 深刻。サーバー自体が危うい

指定した水準以上が記録されます。warn と書けば warn から crit までが入り、info や debug は捨てられます。既定は error なので、警告を拾いたければ warn と明示します。

debug はふだん使いません。1リクエストで何十行も出るため、ディスクを埋めますし、肝心の行が埋もれます。原因が分からないときだけ一時的に上げて、済んだら戻す。この使い方が基本です。

実際にエラーを起こして読む

読み方は、起こしてみるのがいちばん早いです。ファイルを nginx から読めない状態にしてみます。

chmod 000 /var/www/mysite/secret.html
curl -sI http://localhost/secret.html
# HTTP/1.1 403 Forbidden

訪問者には 403 としか分かりません。エラーログには理由が出ています。

tail -1 /var/log/nginx/mysite-error.log
# 2026/08/08 12:00:00 [error] 412#412: *1 open() "/var/www/mysite/secret.html" failed (13: Permission denied), client: 127.0.0.1, ...

開こうとしたファイルの絶対パスと、失敗の理由が書かれています。この絶対パスがとても効きます。設定を読み違えて別の場所を見に行っていた、という間違いは、ここを見た瞬間に分かります。3章の alias と root の取り違えも、このログで一発です。

4章で nginx の worker が www-data で動いていることを見ました。Permission denied は、その www-data から読めない、という意味です。読み手が誰なのかを知っていると、ログの一行が具体的に読めます。

見るべき場所を決めておく

困ったときに見る順番を決めておくと、慌てずに済みます。

1. curl -sI でステータスコードを見る。何が起きたかを掴む
2. エラーログの末尾を読む。なぜ起きたかを掴む
3. 必要なら journalctl -u nginx を見る。nginx 自体が起動できたかを掴む

2章で見た journalctl は、nginx が立ち上がる前後の話を持っています。設定を書き間違えて起動に失敗した場合は、エラーログではなくこちらに出ます。どちらを見るかは、nginx が動いているかどうかで決まります。

手を動かす

サイト専用のエラーログを出すようにして、わざと読めないファイルを作り、その理由がログに残ることを確かめます。