エラーログ監視
アクセスログには、原因が書かれていない
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 から読めない、という意味です。読み手が誰なのかを知っていると、ログの一行が具体的に読めます。
見るべき場所を決めておく
困ったときに見る順番を決めておくと、慌てずに済みます。
curl -sIでステータスコードを見る。何が起きたかを掴む- エラーログの末尾を読む。なぜ起きたかを掴む
- 必要なら
journalctl -u nginxを見る。nginx 自体が起動できたかを掴む
2章で見た journalctl は、nginx が立ち上がる前後の話を持っています。設定を書き間違えて起動に失敗した場合は、エラーログではなくこちらに出ます。どちらを見るかは、nginx が動いているかどうかで決まります。
手を動かす
サイト専用のエラーログを出すようにして、わざと読めないファイルを作り、その理由がログに残ることを確かめます。