【大阪 / 横浜】インフラ / サーバーサイドエンジニア募集中!

【大阪 / 横浜】インフラ / サーバーサイドエンジニア募集中!

【導入実績 500社以上】AWS 構築・運用保守・監視サービス

【導入実績 500社以上】AWS 構築・運用保守・監視サービス

【CentOS 後継】AlmaLinux OS サーバー構築・移行サービス

【CentOS 後継】AlmaLinux OS サーバー構築・移行サービス

【WordPress 専用】クラウドサーバー『ウェブスピード』

【WordPress 専用】クラウドサーバー『ウェブスピード』

【格安】Webサイト セキュリティ自動診断「クイックスキャナー」

【格安】Webサイト セキュリティ自動診断「クイックスキャナー」

【予約システム開発】EDISONE カスタマイズ開発サービス

【予約システム開発】EDISONE カスタマイズ開発サービス

【100URLの登録が0円】Webサイト監視サービス『Appmill』

【100URLの登録が0円】Webサイト監視サービス『Appmill』

【200ヶ国以上に対応】グローバル eSIM「ビヨンドSIM」

【200ヶ国以上に対応】グローバル eSIM「ビヨンドSIM」

【中国への旅行・出張・駐在なら】中国SIMサービス「チョコSIM」

【中国への旅行・出張・駐在なら】中国SIMサービス「チョコSIM」

【グローバル専用サービス】北米・中国でも、ビヨンドのMSP

【グローバル専用サービス】北米・中国でも、ビヨンドのMSP

【YouTube】ビヨンド公式チャンネル「びよまるチャンネル」

【YouTube】ビヨンド公式チャンネル「びよまるチャンネル」

【nginx】アクセスログの見方・設定・場所等を解説

皆様こんにちは。
寝たくない時に眠くなり、寝たい時に眠れない日々を過ごすシステムソリューション部所属のなかです。

今回は、Webサーバーの運用・保守といえば、確実に普段から触れる「アクセスログ」についてです。

その中で近年、世界的なシェア率ではついに Apache を越えた、nginx のアクセスログの見方・設定・場所等について解説したいと思います。

テスト環境

  • Linux 環境
    OS:AlmaLinux release 9. 2(VirtualBox 7.0.12 環境)
    ミドルウェア:nginx(1:1.20.1-14.el9_2.1.alma.1) ,HTTP(80)
  • ブラウザ
    Chrome:120.0.6099.217(Official Build)(64ビット)

テストページ

  • ドメイン:example.com
    ※ localhost 環境のため、hosts 書き換えでアクセス
  • HTML:index.html(トップページ用) , FAQ.html(FAQページ)

nginx のアクセスログの場所とログ例

デフォルト時のアクセスログの場所は「/var/log/nginx/access.log」となります。
まずアクセスログを軽く確認したい場合は、負荷の軽い less コマンドで開くのがオススメです。

less /var/log/nginx/access.log

1️⃣ URL:example.com (index.html) アクセス時のログ

192.168.33.1 - - [17/Jan/2024:08:47:50 +0000] "GET / HTTP/1.1" 200 37 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36" "-"

2️⃣ index.html(ページ内リンク)→ FAQ.html アクセズ時のログ

192.168.33.1 - - [17/Jan/2024:08:50:33 +0000] "GET /FAQ.html HTTP/1.1" 200 34 "http://example.com/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36" "-"

ローカル環境に example.com で受け付けるサイトを建てて、ブラウザからアクセスした際のログを一部抜粋してみました。

example.com のトップページ(index.html)と、そこからFAQページ(FAQ.html)にアクセスした際に出力されるログです。

最初のIPアドレスと時刻は分かりやすいですが、以降が分かりにくいかなと思いますので、設定項目と比較して解説していきます。

ログフォーマット(ログ書式)の設定について

nignx の基本設定ファイルは、「/etc/nginx/nginx.conf」です。

この中で「log_format」ディレクティブ(設定)でアクセスログのフォーマット(書式)が定義されています。
※ アクセスログの出力先も定義されています。

less /etc/nginx/nginx.conf
~一部抜粋~
http {
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';

「log_format main 」という部分は、「main」という名前でフォーマット名を定義します。
その後にどの内容を出力するかのフォーマット(書式)、【 nginxの変数 + 表示を整えるためのハイフン・鉤括弧 等 】が並んでいる形です。

ログフォーマット 解説 / アクセスログ2️⃣との比較表

ログフォーマット 内容 アクセスログ2️⃣値 備考欄
$remote_addr 接続したIPアドレス 192.168.33.1 直接リクエストしたIPのため、
LB経由時はLBのIPが記録される。
- 区切り用ハイフン -
$remote_user Basic認証用に指定されたユーザー名 -(空白) Basic認証が使われるのは
開発中・メンテ中の事が多いため
基本的に空。
[$time_local] [処理完了時のローカル時刻+Timezone] [17/Jan/2024:08:27:22
+0000]
"+0000" の部分は時差
"+0000" はUTC(標準時)
"+0900" だとJST(日本時間)。
"$request" "リクエスト内容"
(メソッド, 要求パス, HTTPバージョン)
"GET /FAQ.html
HTTP/1.1"
"HTTP/1.1" で "FAQ.html" を"GET"(表示)
要求が来たことを意味します。
$status  "ステータスコード" 200 (成功)
$body_bytes_sent "クライアントに送信したバイト数" 34(byte) FAQ.html 等 メインデータ
(ボディ)部分のバイト数
"$http_referer" "リファラ"
(アクセス元URL)
"http://example.com/"
※トップページ
トップページ⇨FAQへのアクセス
"-"(空白)時は、
直接URL指定でのアクセス
"$http_user_agent" "ユーザーエージェント"
(ブラウザ・OS情報)
"Mozilla/5.0
(Windows NT 10.0;Win64;x64)
AppleWebKit/537.36
(KHTML, like Gecko)
Chrome/120.0.0.0 Safari/537.36"
Windows(OS)上、
Chrome系ブラウザからのアクセス
と読み取れます。
"$http_x_forwarded_for" "X-Forwarded-For"
(送信元IP
"-" ProxyやLB経由時、
その前の送信元IPアドレスが表示される。

得られる情報は多い

上記表をもっと簡潔にまとめると、下記の形になります。

  • IP : 192.168.33.1
  • ユーザー名 : 無(=認証していない)
  • アクセス時間 : UTC(日本時間だと+9時間)の2024年1月17日の08時27分22秒
  • アクセス先 : FAQのサイトページ(FAQ.html)
  • 接続状態 : 成功(200)
  • データ量 : 4B(バイト)
  • アクセス元 : トップページから(http://example.com)
  • 環境 : WindowsOSでChrome系ブラウザを使用(と宣言している)
  • LB や Proxyを経由しているか : 経由していない(空のため)

このような感じで、アクセスログからはかなり多くの情報を得ることができます。
これらを各種集計する事でアクセス傾向や、悪意あるアクセスかどうかの調査も行う事が可能となります。

デフォルトのログフォーマットでも大変便利なので是非活用していきましょう。

用語説明

Basic認証(Basic Authentication)

予め定めたユーザー名・パスワード名の入力を求める簡易的な認証機能です。
あくまで最低限の簡易的な物なので、構築時や緊急メンテナンス時など、一時的な用途で利用されます。

特にHTTP(80)通信だと、認証情報も平文(非暗号化)で送信されるのでセキュリティ的には弱い状態です。
一時的にでも利用する際には、サイトがHTTPS(443)通信のみとなっている状態が望ましいです。

リファラ(Referer)

アクセスされたページのリンクをもった直前のURLを指します。

Google の検索からトップページを開けば、Google の URL がログに記録され、サイトのトップページから FAQ を開けば、トップページの URL がログに記録される仕組みです。

この用語は本来、英単語「referrer」(意味:参照元)のスペルミスなのですが、仕様策定の際にスペルミス状態で決定したため、現在もそのまま使われている面白い歴史がある物です。

HTTPステータスコード(HTTP status codes)

HTTP(S)が通信を行った際に、処理結果を教えてくれるコードです。
全部を記載すると長くなるので割愛しますが、3桁目の数字が重要です。

  • 2xx :成功 レスポンス
  • 3xx :リダイレクト レスポンス
  • 4xx :クライアントエラー レスポンス
  • 5xx :サーバーエラー レスポンス

上記のように、3桁目の数字で概ね状態がわかります。

よく見る代表的なのは、200(成功),302(一時的なリダイレクト),404(存在しない場所へのアクセス不可),
503(サーバーが処理出来ない状態)といったコードです。

ユーザーエージェント(User-Agent)

用語としてのユーザーエージェントは、「Webサイトとの通信に使われているソフトウェア」を指すものです。

一般的にWebサイトへのアクセスはブラウザを使いますので、転じて「ユーザーが使用しているブラウザ(と合わせてOS等の情報)情報」として扱われています。

X-Forwarded-For

LB や Proxy が通信を行う場合に、送信元のIPを記載する項目(ヘッダー)です。

LB や Proxyといった クライアント(ユーザー)とWebサーバーの間に通信が挟まる場合は、Webサーバー側には LB や Proxy のIPは記録されますが、その前にいる送信元のクライアントのIPがわかりません。

そのため、LB や Proxy といった経由する通信時には、送信元IPを X-Forwarded-For の項目(ヘッダー)で保存するのが事実上の標準となっています。

余談:ログフォーマットで「main」と名前を定義する事について

なぜ名前を定義するのか?ということについてですが、「ログを出力する設定の際に、使用するログフォーマットは名前で指定する仕様のため」です。

less /etc/nginx/nginx.conf 
~一部抜粋~
access_log /var/log/nginx/access.log main;

「access_log」 ディレクティブ という、ログの出力先を指定する設定(ディレクティブ)で利用します。定義する項目と利用する項目が違うので、名前付けが必要になるわけです。

つまり定義は複数設定できます。

たとえば、不要な情報を減らして簡略したログフォーマットを「easy」という名前で定義したり、逆に詳細な情報が欲しい場合にログの項目(変数)を増やした物を「detailed」として定義できます。

なのでドメインや環境ごとに定義の使い分けをする事が出来ます。

access_log ディレクティブでフォーマット名を指定しないとどうなるか

もしかすると「フォーマット名の指定がない環境です」という方もいらっしゃるかもしれません。

この場合ですが、シンタックス(構文)チェックや動作上問題ありません。

この access_log ディレクティブでフォーマット名が指定されていない場合は、conf には書かれていませんが事前に組み込まれている「combined」 定義がデフォルト設定として使われます。

log_format combined '$remote_addr - $remote_user [$time_local] '
'"$request" $status $body_bytes_sent '
'"$http_referer" "$http_user_agent"';

上記の定義が利用されることはnginxの公式ドキュメントに記載されています。

内容としては、conf にデフォルトで書かれている「main」 とはフォーマットが微妙に違い、末尾に 「$http_x_forwarded_for」 が指定されていない物になります。

ちなみに、これは Apache でのデフォルト定義名 「combined」と同じ名前かつ出力される内容も同じ形の定義です。

最後に

Apache のログは普段よく触る事が多く、情報も数多く存在しています。

それに比べるとnginxの方は触る機会が少ないので、「なら情報をまとめた方が便利かな」と思い記事を書いてみました。

筆者個人としては Apache のログフォーマット指定よりわかりやすくて好きですね。

この記事を読んだ方に多少でも役に立つ知識となれれば幸いです。
ここまで読んで頂きありがとうございました。

参考資料

Module ngx_http_log_module
https://nginx.org/en/docs/http/ngx_http_log_module.html

Module ngx_http_core_module
https://nginx.org/en/docs/http/ngx_http_core_module.html

The 'Basic' HTTP Authentication Scheme
https://datatracker.ietf.org/doc/html/rfc7617

Referer
https://developer.mozilla.org/ja/docs/Web/HTTP/Headers/Referer

HTTP レスポンスステータスコード
https://developer.mozilla.org/ja/docs/Web/HTTP/Status

User agent (ユーザーエージェント)
https://developer.mozilla.org/ja/docs/Glossary/User_agent

X-Forwarded-For
https://developer.mozilla.org/ja/docs/Web/HTTP/Headers/X-Forwarded-For

この記事がお役に立てば【 いいね 】のご協力をお願いいたします!
8
読み込み中...
8 票, 平均: 1.00 / 18
7,374
X facebook はてなブックマーク pocket
【2024.6.30 CentOS サポート終了】CentOS サーバー移行ソリューション

【2024.6.30 CentOS サポート終了】CentOS サーバー移行ソリューション

【2025.6.30 Amazon Linux 2 サポート終了】Amazon Linux サーバー移行ソリューション

【2025.6.30 Amazon Linux 2 サポート終了】Amazon Linux サーバー移行ソリューション

【大阪 / 横浜】インフラエンジニア・サーバーサイドエンジニア 積極採用中!

【大阪 / 横浜】インフラエンジニア・サーバーサイドエンジニア 積極採用中!

この記事をかいた人

About the author

なか

2022年ビヨンドに中途入社
システムソリューション部所属
LPIC-3 304とAWS SAAを一応は持っています
普段の飲み物が牛乳とコーラと紅茶の3択しかない