Nginx設定ファイル（nginx.conf）の基本的な書き方と設定方法

By /

Nginx 設定ファイル（nginx.conf）の基本的な書き方と設定方法

はじめに

Nginx（エンジンエックス）は、高性能で軽量なウェブサーバー、リバースプロキシ、ロードバランサー、HTTPキャッシュなどとして利用される、非常に人気のあるソフトウェアです。その柔軟性とパフォーマンスは、静的コンテンツの配信から複雑なウェブアプリケーションの負荷分散まで、幅広い用途で採用されています。

Nginxの動作を制御するのが、設定ファイルである nginx.conf です。このファイルを適切に記述することで、Nginxを目的の役割に合わせてカスタマイズできます。しかし、その構造やディレクティブ（設定項目）の多さから、初めて触れる方にとっては少し難しく感じられるかもしれません。

この記事では、nginx.conf の基本的な構造、主要なディレクティブ、そしてよく使われる設定例について、詳細かつ分かりやすく解説します。この記事を読むことで、Nginxの設定ファイルの読み方・書き方の基本を習得し、自身の環境に合わせてNginxを設定できるようになることを目指します。

1. nginx.conf とは？

nginx.conf は、Nginxの動作を定義する主要な設定ファイルです。Nginxが起動する際にこのファイルを読み込み、記述された内容に従ってリクエストの処理を行います。

ファイルの場所はオペレーティングシステムやインストール方法によって異なりますが、一般的な場所としては以下のようなパスが挙げられます。

  • /etc/nginx/nginx.conf (Debian/Ubuntu, CentOS/RHELなどの多くのLinuxディストリビューション)
  • /usr/local/etc/nginx/nginx.conf (macOS + Homebrewなど)

多くの場合、/etc/nginx/nginx.conf がメインの設定ファイルであり、他の設定ファイルを include ディレクティブで読み込む構造になっています。これにより、設定を機能ごとやサイトごとに分割し、管理しやすくしています。例えば、個別のウェブサイトの設定は /etc/nginx/conf.d/*.conf や /etc/nginx/sites-available/* に配置され、メインの nginx.conf から参照されるのが一般的です。

2. 設定ファイルの基本的な構造

nginx.conf は、階層的なブロック構造を持っています。設定は「コンテキスト」と呼ばれるブロック内に記述され、それぞれのコンテキストが特定のスコープや機能に関連する設定を保持します。最も外側のコンテキストが「メインコンテキスト」であり、その中に「イベントコンテキスト」「HTTPコンテキスト」などがネストされます。さらに、HTTPコンテキストの中には「サーバーコンテキスト」が、サーバーコンテキストの中には「ロケーションコンテキスト」が含まれるのが典型的な構造です。

各コンテキスト内には、様々な「ディレクティブ」とその引数が記述されます。ディレクティブは Nginx の具体的な動作を指定するコマンドのようなものです。ディレクティブの末尾は必ずセミコロン (;) で終わります。コンテキストブロックは波括弧 ({}) で囲みます。

基本的な構造は以下のようになります。

“`nginx

メインコンテキスト (main)

Nginx全体に関わる設定

worker_processes auto; # Nginxのワーカープロセス数

events {
# イベントコンテキスト (events)
# 接続処理方法に関わる設定

worker_connections 1024; # 各ワーカープロセスが同時に処理できる接続数
# use epoll; # 使用する接続処理モデル (Linuxの場合epollが一般的、自動検出されることが多い)

}

http {
# HTTPコンテキスト (http)
# HTTPサーバー全般に関わる設定
# MIMEタイプ、ログ形式、共通ヘッダーなど

include mime.types; # MIMEタイプ定義ファイルを読み込む
default_type application/octet-stream; # デフォルトのMIMEタイプ

log_format main '$remote_addr - $remote_user [$time_local] "$request" '
                '$status $body_bytes_sent "$http_referer" '
                '"$http_user_agent" "$http_x_forwarded_for"'; # アクセスログの形式定義

access_log /var/log/nginx/access.log main; # アクセスログの出力先と形式
error_log /var/log/nginx/error.log error; # エラーログの出力先とレベル

sendfile on; # sendfileシステムコールを有効化 (ファイル転送の効率向上)
#tcp_nopush on; # sendfile利用時にパケットを一度にまとめて送る

keepalive_timeout 65; # キープアライブ接続のタイムアウト時間

# gzip圧縮設定 (帯域幅削減)
gzip on;
gzip_disable "msie6"; # IE6の場合はgzip無効

# serverコンテキスト (server)
# 仮想ホスト（特定のドメインやポート）の設定
server {
    listen 80; # リッスンするポート
    server_name example.com www.example.com; # このサーバーブロックが応答するドメイン名

    # locationコンテキスト (location)
    # 特定のURLパスに対する設定
    location / {
        root /usr/share/nginx/html; # ドキュメントルート
        index index.html index.htm; # ディレクトリインデックスファイル
    }

    location /images/ {
         # /images/ 以下へのリクエストに対する設定
         alias /data/images/; # 別ディレクトリをマッピング
         autoindex on; # ディレクトリ一覧表示を有効化
    }

    location /api/ {
        # /api/ 以下へのリクエストに対する設定
        proxy_pass http://backend_server; # バックエンドサーバーへリクエストを転送 (リバースプロキシ)
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }

    # エラーページ設定
    error_page 500 502 503 504 /50x.html;
    location = /50x.html {
        root /usr/share/nginx/html;
    }
}

# 別のserverコンテキスト (別の仮想ホストやSSLサイトなど)
# server {
#    listen 443 ssl;
#    server_name secure.example.com;
#    ssl_certificate /etc/nginx/ssl/secure.example.com.crt;
#    ssl_certificate_key /etc/nginx/ssl/secure.example.com.key;
#    # その他のSSL/TLS設定...
#
#    location / {
#        # 設定...
#    }
# }

}
“`

コメント (#) は行の最後までを無効化します。設定を一時的に無効にしたり、説明を記述したりするのに使います。

3. 主要なコンテキストの詳細

各コンテキストがどのような役割を持ち、どのような設定を記述するのかをさらに詳しく見ていきましょう。

3.1. メインコンテキスト (main)

nginx.conf の最も外側に位置するコンテキストです。Nginx全体に関わるグローバルな設定を行います。

  • worker_processes: Nginxが起動するワーカープロセスの数を指定します。通常はCPUコア数と同じか auto に設定するのが推奨されます。各ワーカープロセスが独立してリクエストを処理します。
    • 例: worker_processes auto;
  • error_log: グローバルなエラーログの設定です。HTTPコンテキストやサーバーコンテキストで設定されない場合に使われます。
    • 例: error_log /var/log/nginx/error.log error; (ログレベル error 以上のものを指定ファイルに出力)
  • pid: NginxのマスタープロセスのPIDを記録するファイルのパスを指定します。
    • 例: pid /run/nginx.pid;
  • include: 他のファイルを読み込みます。設定をモジュール化するのに非常に便利です。
    • 例: include /etc/nginx/mime.types;, include /etc/nginx/conf.d/*.conf;

3.2. イベントコンテキスト (events)

接続の処理方法に関する設定を行います。メインコンテキスト内に記述されます。

  • worker_connections: 各ワーカープロセスが同時に保持できる接続の最大数を指定します。システムのファイルディスクリプタ数の上限など、OS側の設定も考慮する必要があります。
    • 例: worker_connections 1024; (これは同時に1024個の接続を処理できることを意味します)
  • use: Nginxが使用する接続処理モデル（I/O多重化モデル）を指定します。epoll (Linux), kqueue (BSD系), devpoll (Solaris), poll, select などがあります。通常はNginxが自動的に最適なものを検出してくれますが、明示的に指定することも可能です。
    • 例: use epoll;

3.3. HTTPコンテキスト (http)

HTTPサーバー全般に関わる設定を行います。イベントコンテキストの後に、メインコンテキスト内に記述されます。ここに記述された設定は、その中に含まれる全ての server ブロックに継承されます（ただし、server ブロックで同じディレクティブが指定された場合はサーバーブロックの設定が優先されます）。

非常に多くのディレクティブがあり、ウェブサーバーの基本的な動作のほとんどをここで設定できます。

  • include mime.types;: ファイル拡張子とMIMEタイプを関連付ける設定ファイルを読み込みます。これにより、Nginxは応答するファイルの種類を正確にブラウザに伝達できます。
  • default_type: mime.types で定義されていないMIMEタイプのリクエストに対するデフォルトタイプを指定します。
    • 例: default_type application/octet-stream; (未知のファイルタイプはバイナリデータとして扱う)
  • log_format: アクセスログの出力形式を定義します。複数の形式を定義し、後述の access_log で使い分けることができます。
    • 例: 上記の構造例にある main 形式が一般的です。$remote_addr (クライアントIP), $request (リクエストライン), $status (HTTPステータスコード), $body_bytes_sent (応答ボディサイズ) などの変数を使用します。
  • access_log: アクセスログの出力先ファイルと使用する log_format を指定します。off を指定するとアクセスログは出力されません。
    • 例: access_log /var/log/nginx/access.log main;
  • error_log: エラーログの出力先ファイルと最小レベルを指定します。レベルは debug, info, notice, warn, error, crit, alert, emerg の順に詳細度が低くなります。通常は error レベルが使われます。
    • 例: error_log /var/log/nginx/error.log error;
  • sendfile: OSの sendfile() システムコールを使用するかどうかを設定します。有効にすると、カーネル空間内で直接ファイル転送が行われ、データコピーが削減されるため、静的ファイルの配信パフォーマンスが向上します。
    • 例: sendfile on;
  • tcp_nopush: sendfile が on の場合に使用できる設定です。TCPパケットを効率的に送信するために、ヘッダーとデータの最初の部分をまとめて送信したり、大きなレスポンスを送信する際にバッファがいっぱいになるまで待機したりします。
    • 例: tcp_nopush on;
  • tcp_nodelay: Nagleアルゴリズムを無効にするかどうかを設定します。通常は有効 (on) にすることで、小さなデータパケットの送信遅延を減らし、インタラクティブなアプリケーションの応答性を向上させます。
    • 例: tcp_nodelay on; (Keep-Alive接続でのみ有効)
  • keepalive_timeout: クライアントとのキープアライブ接続を開いておく最大時間を指定します。この時間内に次のリクエストがない場合、接続は閉じられます。
    • 例: keepalive_timeout 65;
  • types_hash_max_size: MIMEタイプのハッシュテーブルの最大サイズを指定します。多数のカスタムMIMEタイプを使用する場合に調整が必要になることがあります。
  • server_tokens: Nginxのバージョン情報を応答ヘッダー (Server) やエラーページに表示するかどうかを設定します。セキュリティのために off にすることが推奨されます。
    • 例: server_tokens off;
  • client_max_body_size: クライアントからのリクエストボディ（PUTやPOSTメソッドで送信されるデータ）の最大サイズを指定します。これを超えるリクエストは413 (Request Entity Too Large) エラーになります。ファイルのアップロードサイズ制限などに利用します。
    • 例: client_max_body_size 100m; (100MB)
  • gzip: 応答をgzip圧縮するかどうかを有効/無効にします。有効にすると、転送データ量が削減され、帯域幅を節約できます。CPU負荷は増加します。
    • 例: gzip on;
  • gzip_types: gzip圧縮を適用するMIMEタイプを指定します。テキストベースのコンテンツ（text/html, application/json, text/css, application/javascriptなど）が対象です。
    • 例: gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;
  • gzip_comp_level: gzip圧縮レベルを指定します。1（最低圧縮率、最高速度）から9（最高圧縮率、最低速度）まであります。通常は4〜6がバランスが良いとされます。
    • 例: gzip_comp_level 5;
  • gzip_vary: 応答ヘッダーに Vary: Accept-Encoding を追加するかどうかを設定します。これにより、キャッシュサーバーは圧縮された応答とされていない応答を区別してキャッシュできます。通常は on にします。
    • 例: gzip_vary on;

これらのHTTPコンテキストのディレクティブは、様々な server ブロックで共有される共通設定として非常に役立ちます。

3.4. サーバーコンテキスト (server)

特定の仮想ホストを設定するためのコンテキストです。HTTPコンテキスト内に複数記述できます。IPアドレスとポート番号、またはドメイン名（server_name）によってリクエストをどの server ブロックで処理するかが決定されます。

  • listen: NginxがリッスンするIPアドレスとポート番号を指定します。
    • 例: listen 80; (IPv4の80番ポート), listen 127.0.0.1:8000; (特定のIPとポート), listen [::]:80; (IPv6の80番ポート)
    • listen 80 default_server;: そのIP/ポートに対するデフォルトのサーバーブロックを指定します。
    • listen 443 ssl;: SSL/TLS接続を受け付けるポートを指定します。
  • server_name: この server ブロックが応答するドメイン名を指定します。複数のドメイン名をスペース区切りで指定したり、ワイルドカード (*.example.com) や正規表現 (~^www\.(?P<domain>.+)\.com$) を使用したりできます。
    • 例: server_name example.com www.example.com;
    • server_name *.example.com;
    • server_name ~^(?<subdomain>.+)\.example\.com$;
  • root: この server ブロック全体のドキュメントルートディレクトリを指定します。後述の location ブロックで root が指定されていない場合に適用されます。
    • 例: root /var/www/html;
  • index: ディレクトリへのリクエストがあった場合に自動的に探すファイル名を指定します。複数指定可能で、左から順に検索されます。
    • 例: index index.html index.htm index.nginx-debian.html;
  • ssl_certificate: SSL/TLS証明書ファイル（公開鍵）のパスを指定します。
    • 例: ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
  • ssl_certificate_key: SSL/TLS証明書秘密鍵ファイルのパスを指定します。
    • 例: ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
  • ssl_protocols: 有効にするSSL/TLSプロトコルバージョンを指定します。安全性の観点から、TLSv1.2とTLSv1.3のみを有効にするのが推奨されます。
    • 例: ssl_protocols TLSv1.2 TLSv1.3;
  • ssl_ciphers: 使用する暗号スイートを指定します。安全性が高く、かつ広くサポートされているものを指定することが重要です。Mozilla SSL Configuration Generatorなどのツールを利用すると良いでしょう。
    • 例: ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:...';
  • ssl_prefer_server_ciphers: サーバーが提供する暗号スイートの順序を優先するかどうか。通常は on にして、より安全な暗号スイートを優先させます。
    • 例: ssl_prefer_server_ciphers on;
  • return: 指定されたステータスコードでレスポンスを返すか、指定されたURLへリダイレクトを行います。単純なリダイレクトやエラー応答に便利です。
    • 例: return 301 https://$server_name$request_uri; (HTTPからHTTPSへのリダイレクト)
    • 例: return 404; (404エラーを返す)

3.5. ロケーションコンテキスト (location)

特定のURLパスに対するリクエストの処理方法を設定するためのコンテキストです。server コンテキスト内に複数記述できます。クライアントからのリクエストURLがどの location ブロックにマッチするかによって、適用される設定が決まります。

location ディレクティブには、マッチング方法を指定する修飾子があります。

  • location /: プレフィックスマッチ。最も一般的で、/ で始まるすべてのリクエストにマッチします。他のより具体的な location ブロックにマッチしなかった場合の最後の手段として使われることが多いです。
  • location = /uri: 完全一致マッチ。指定されたURIと完全に一致する場合にのみマッチします。最も優先度が高いです。
  • location ~ uri: 正規表現マッチ（大文字小文字を区別する）。
  • location ~* uri: 正規表現マッチ（大文字小文字を区別しない）。
  • location ^~ uri: プレフィックスマッチ。正規表現マッチよりも優先されます。

マッチングは以下の順序で行われます。

  1. = による完全一致マッチを検索。一致するものがあればそれを採用し、探索を終了。
  2. ^~ によるプレフィックスマッチを検索。最も長くマッチするものを採用し、正規表現マッチより優先してそれを採用し、探索を終了。
  3. 正規表現マッチ (~ または ~*) を検索。設定ファイルに記述された順に評価し、最初に見つかった正規表現マッチを採用し、探索を終了。
  4. 通常のプレフィックスマッチ (/ または修飾子なしのパス) を検索。最も長くマッチするものを採用。

どの location ブロックにもマッチしない場合は、最も長くマッチしたプレフィックスマッチが採用されます。（これは ^~ のルールとは異なり、正規表現マッチの後に評価されます）。 / locationは特別なプレフィックスマッチとして扱われ、他のどのプレフィックスマッチにも該当しない場合、または正規表現マッチが見つからない場合に採用されます。

ロケーションコンテキストでよく使われるディレクティブ：

  • root: この location ブロックのドキュメントルートを指定します。server ブロックの root より優先されます。
    • 例: root /var/www/example.com/html;
  • alias: root と似ていますが、マッチしたURIのプレフィックス部分を除いたパスを、指定されたディレクトリにマッピングします。主に、URIのパスとは異なる場所にあるファイルを提供したい場合に使います。
    • 例: location /images/ { alias /data/images/; } (/images/photo.jpg へのリクエストは /data/images/photo.jpg を探します)
    • alias を使用する際は、指定したディレクトリパスの末尾に / を付けるかどうかを、locationのパスの末尾に / を付けるかどうかに合わせる必要があります。（例: location /images/ { alias /data/images/; } はOK, location /images { alias /data/images; } もOKだが、location /images/ { alias /data/images; } や location /images { alias /data/images/; } は予期しない動作を引き起こす可能性がある）。root はこの問題を避けられます。
  • index: この location ブロックにおけるディレクトリインデックスファイルを指定します。
    • 例: index index.html;
  • try_files: リクエストされたURIに対応するファイルやディレクトリを、指定された順序で検索し、最初に見つかったものを内部的に処理します。最後の引数には、何も見つからなかった場合に内部リダイレクトするURI、またはステータスコードを指定します。動的コンテンツ（PHPなど）のURL書き換え（Rewrite）によく使われます。
    • 例: try_files $uri $uri/ /index.php?$args; (まず $uri (リクエストされたパス) に対応するファイルを試す -> なければ $uri/ (パス名のディレクトリ) に対応するファイルを試す -> それもなければ /index.php に内部リダイレクトし、元のクエリ文字列 ($args) を渡す)
  • proxy_pass: リクエストを別のサーバー（バックエンドサーバー）に転送します。Nginxをリバースプロキシとして使用する際に核となるディレクティブです。バックエンドサーバーのアドレス（IP:ポートまたはドメイン名）を指定します。
    • 例: proxy_pass http://localhost:8080; (ローカルの8080ポートで動作するサーバーへ転送)
    • 例: proxy_pass http://backend_servers; (後述の upstream ブロックで定義されたサーバー群へ転送)
    • proxy_pass に指定するURLのパス部分の有無で、転送時のURIの扱いが変わる点に注意が必要です。
      • proxy_pass http://backend_server/; (末尾に/あり): マッチしたlocationのパス部分を削除し、/ 以下を転送先のURIに付加します。例: location /app/ ブロックで proxy_pass http://backend/api/; とすると、/app/users は /api/users としてバックエンドに転送されます。
      • proxy_pass http://backend_server; (末尾に/なし): マッチしたlocationのパス部分をそのまま転送先のURIに付加します。例: location /app/ ブロックで proxy_pass http://backend/api; とすると、/app/users は /api/app/users としてバックエンドに転送されます。通常は末尾に / を付けた方が意図した挙動になりやすいです。
  • proxy_set_header: バックエンドサーバーに転送するリクエストヘッダーをカスタマイズします。クライアントのIPアドレスやオリジナルのホスト名をバックエンドに伝えるためによく使われます。
    • 例: proxy_set_header Host $host; (オリジナルのHostヘッダーを転送)
    • 例: proxy_set_header X-Real-IP $remote_addr; (クライアントのIPアドレスをカスタムヘッダーで転送)
    • 例: proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; (リクエストパスウェイ上のクライアントIPをリスト形式で追加)
    • 例: proxy_set_header X-Forwarded-Proto $scheme; (元のプロトコル(http/https)を転送)
  • rewrite: リクエストURIを書き換えます。正規表現を使用してURIを変換し、内部的な処理を継続するか、外部リダイレクトを行うかを選択できます。複雑になりがちなので、可能な場合は try_files や return の使用が推奨されます。
    • 例: rewrite ^/old-path/(.*)$ /new-path/$1 permanent; (/old-path/... を /new-path/... に301リダイレクト)
    • 例: rewrite ^/download/(.*)$ /files/$1 break; (/download/... を内部的に /files/... に書き換えて、このlocationブロック内での処理を継続)
  • error_page: 指定されたHTTPステータスコードに対するカスタムエラーページを設定します。
    • 例: error_page 404 /404.html; (404エラーが発生したら /404.html に内部リダイレクト)
    • 例: error_page 500 502 503 504 /custom_50x.html; (複数のサーバーエラーコードに対するカスタムページ)
  • autoindex: ディレクトリへのリクエストがあった場合に、ディレクトリ内のファイル一覧を自動生成して表示するかどうか。主に開発環境やファイル配布に使われます。
    • 例: autoindex on;
  • allow, deny: 特定のIPアドレスやネットワークからのアクセスを許可または拒否します。
    • 例: allow 192.168.1.0/24; (特定のネットワークからのアクセスを許可)
    • 例: deny all; (それ以外の全てのアクセスを拒否)
    • 記述順序が重要で、最初にマッチしたルールが適用されます。通常は allow を先に記述し、最後に deny all とすることで、許可されたIP以外を全て拒否します。

3.6. アップストリームコンテキスト (upstream)

ロードバランシングやバックエンドサーバーの定義に使用するコンテキストです。HTTPコンテキスト内に記述されます。proxy_pass ディレクティブ内でこのアップストリーム名を指定することで、リクエストを指定されたバックエンドサーバー群に分散させることができます。

  • upstream name { ... }: バックエンドサーバーグループを定義します。name は任意の識別子です。
  • server address [parameters];: アップストリームグループ内にバックエンドサーバーを定義します。address は IP:ポート、ホスト名:ポート、またはUnixドメインソケットパスです。parameters で重み付けやヘルスチェックなどを設定できます。
    • 例: server localhost:8080;
    • 例: server backend1.example.com:80 weight=3; (重み付け3で他のサーバーより多くのリクエストを処理)
    • 例: server unix:/tmp/backend.sock; (Unixドメインソケット)
    • 例: server backend2.example.com:80 max_fails=3 fail_timeout=30s; (3回失敗したら30秒間はダウンとみなす)
  • ロードバランシングメソッド: upstream ブロック内でメソッドを指定できます。
    • least_conn;: アクティブな接続数が最も少ないサーバーにリクエストを送信します。（デフォルトはラウンドロビン）
    • ip_hash;: クライアントのIPアドレスに基づいてサーバーを選択します。特定のクライアントからのリクエストが常に同じサーバーに送られるため、セッション維持に役立ちます。
    • hash key;: 指定されたキー（変数など）のハッシュ値に基づいてサーバーを選択します。
    • random;: ランダムにサーバーを選択します。
    • sticky; (Nginx Plus): クライアントとサーバー間のセッション永続性を維持します。

例:

“`nginx
http {
upstream backend_servers {
# ロードバランシング方法を指定しない場合はデフォルトのラウンドロビン
# least_conn; # 最小接続数アルゴリズム

    server backend1.example.com:80 weight=5; # 重み付け
    server backend2.example.com:80;
    server backend3.example.com:80 max_fails=3 fail_timeout=20s; # ヘルスチェックパラメータ
}

server {
    listen 80;
    server_name myapp.example.com;

    location / {
        proxy_pass http://backend_servers; # アップストリーム名を指定
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

}
“`

4. 具体的な設定例

いくつかの一般的な設定シナリオにおける nginx.conf の記述例を見てみましょう。

4.1. 静的ファイルの配信

最も基本的な設定です。特定のディレクトリにあるHTMLファイル、画像、CSS、JavaScriptなどを配信します。

“`nginx
http {
include mime.types;
default_type application/octet-stream;

server {
    listen 80;
    server_name example.com www.example.com;

    root /usr/share/nginx/html; # ここがドキュメントルート

    location / {
        # リクエストされたURIに対応するファイルをまず探す
        # なければ、URIに/を付けたディレクトリ内のindexファイルを試す
        # それもなければ、404エラーを返す (または他のfall-through設定)
        try_files $uri $uri/ =404;

        # あるいはシンプルに root と index を指定
        # root /usr/share/nginx/html; # serverブロックに記述済みの場合は不要
        # index index.html index.htm;
    }

    # 特定のディレクトリだけ別にする場合
    location /images/ {
        alias /data/static/images/; # /images/xxx は /data/static/images/xxx を探す
    }

    # キャッシュコントロールの設定例
    location ~* \.(jpg|jpeg|gif|png|css|js|ico)$ {
        expires 30d; # ブラウザに30日間キャッシュさせる
        # add_header Cache-Control "public, no-transform";
    }
}

}
“`

try_files は静的ファイル配信において非常に強力でよく使われます。$uri はリクエストされたURI（例: /css/style.css, /about/）。$uri/ はディレクトリの場合に index ディレクティブで指定されたファイルを試すためのものです（例: /about/ のリクエストに対して /about/index.html を探す）。最後の =404 は、前の全てが見つからなかった場合にHTTPステータスコード404を返すことを意味します。

4.2. リバースプロキシ設定

Nginxをフロントエンドとし、別のアプリケーションサーバー（Node.js, Python/Django/Flask, Ruby/Rails, Javaなど）がバックエンドで動作している構成です。Nginxはクライアントからのリクエストを受け付け、それをバックエンドサーバーに転送し、バックエンドからの応答をクライアントに返します。これにより、Nginxの静的ファイル配信能力、SSL終端、負荷分散、キャッシングなどの機能を活用しつつ、バックエンドアプリケーションサーバーはアプリケーションロジックに専念できます。

“`nginx
http {
upstream myapp_backend {
server 127.0.0.1:8080; # バックエンドアプリケーションサーバーのアドレス
# server unix:/var/run/myapp.sock; # あるいはUnixソケット
}

server {
    listen 80;
    server_name myapp.example.com;

    location / {
        proxy_pass http://myapp_backend; # バックエンドグループに転送

        # バックエンドにクライアント情報などを正確に伝えるためのヘッダー設定
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        # WebSocketのプロキシ設定例
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }

    # 静的ファイルはNginxで直接配信する（パフォーマンス向上）
    location /static/ {
        alias /var/www/myapp/static/;
        expires 30d;
    }

    # 特定のURLだけ別のバックエンドへ
    location /api/v2/ {
        proxy_pass http://another_backend_server;
        # 別のproxy_set_header 設定など...
    }
}

}
“`

proxy_pass はリバースプロキシ設定の核心です。proxy_set_header は非常に重要で、これを適切に設定しないと、バックエンドサーバーがクライアントのIPアドレスを取得できなかったり、HTTPS接続がHTTPとして認識されたりすることがあります。

4.3. SSL/TLS 設定

HTTPSを使用して安全な通信を実現するための設定です。証明書（.crt または .pem）と秘密鍵（.key）が必要です。Let’s Encryptなどで無料で取得できます。

“`nginx
http {
server {
listen 80;
server_name secure.example.com;

    # HTTPでアクセスされた場合にHTTPSにリダイレクト
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2; # HTTPSとHTTP/2を有効化
    server_name secure.example.com;

    ssl_certificate /etc/letsencrypt/live/secure.example.com/fullchain.pem; # 証明書ファイルのパス
    ssl_certificate_key /etc/letsencrypt/live/secure.example.com/privkey.pem; # 秘密鍵ファイルのパス

    # 推奨されるSSL/TLS設定（セキュリティと互換性のバランス）
    ssl_protocols TLSv1.2 TLSv1.3; # 安全なプロトコルのみを使用
    ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384';
    ssl_prefer_server_ciphers on; # サーバー側の暗号リスト順序を優先
    ssl_session_cache shared:SSL:10m; # SSLセッションキャッシュ
    ssl_session_timeout 10m;
    ssl_session_tickets off; # セッションチケットを無効化（前方秘匿性向上のため）

    # HSTS (HTTP Strict Transport Security) ヘッダー
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload";

    # その他のセキュリティヘッダー例
    # add_header X-Frame-Options DENY;
    # add_header X-Content-Type-Options nosniff;
    # add_header X-XSS-Protection "1; mode=block";
    # add_header Referrer-Policy no-referrer-when-downgrade;

    # ドキュメントルートまたはリバースプロキシ設定
    location / {
        root /var/www/secure.example.com/html;
        index index.html;
        try_files $uri $uri/ =404;

        # またはリバースプロキシの場合
        # proxy_pass http://backend;
        # proxy_set_header Host $host;
        # proxy_set_header X-Real-IP $remote_addr;
        # proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        # proxy_set_header X-Forwarded-Proto https; # 重要: バックエンドにHTTPSで受け付けたことを伝える
    }
}

}
“`

SSL/TLSの設定は、プロトコルと暗号スイートの選択がセキュリティに直結するため非常に重要です。常に最新のセキュリティ情報を確認し、Mozilla SSL Configuration Generatorのようなツールを使って推奨設定を生成することをおすすめします。ssl_protocols と ssl_ciphers は特に注意が必要です。add_header Strict-Transport-Security はHSTSヘッダーを追加し、以降のアクセスを強制的にHTTPSにするための重要なセキュリティ設定です。

5. 設定のテストとリロード/再起動

nginx.conf を変更した後は、Nginxにその設定を適用する必要があります。その前に、設定ファイルに構文エラーがないかを確認することが非常に重要です。

5.1. 設定ファイルのテスト

設定ファイルの構文チェックは以下のコマンドで行います。

bash
sudo nginx -t

エラーがなければ、以下のような出力が表示されます。

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

エラーがある場合は、エラーが発生したファイルの行番号とエラー内容が表示されます。エラーメッセージをよく読んで修正してください。例えば、ディレクティブの末尾にセミコロンを付け忘れたり、コンテキストの波括弧が閉じられていなかったりすることがよくある原因です。

5.2. 設定のリロード

設定ファイルをテストして問題がなかったら、Nginxを停止せずに設定を再読み込みすることができます。これは「リロード」と呼ばれ、新しい設定を適用しつつ、既存の接続を維持できるため、サービスの無停止アップデートが可能です。

bash
sudo nginx -s reload

マスタープロセスが新しい設定ファイルを読み込み、新しいワーカープロセスを起動します。古いワーカープロセスは現在処理中のリクエストが完了次第、優雅に終了します。

5.3. Nginxの再起動と停止

設定に大きな変更があった場合や、Nginx自体を完全に再起動したい場合は、再起動コマンドを使用します。これは、Nginxを完全に停止し、再度起動します。この際、一瞬サービスが停止します。

“`bash
sudo systemctl restart nginx # systemdを使用している場合

あるいは

sudo service nginx restart # SysVinitを使用している場合

“`

Nginxを停止するには以下のコマンドを使います。

“`bash
sudo systemctl stop nginx # systemdを使用している場合

あるいは

sudo service nginx stop # SysVinitを使用している場合

“`

または、Nginxコマンドで直接停止することも可能です (quit は優雅な停止、stop は即時停止)。

bash
sudo nginx -s quit # 処理中のリクエストを待って終了
sudo nginx -s stop # 即時終了 (非推奨、実行中のリクエストが中断される可能性がある)

6. 設定をモジュール化する (include)

前述しましたが、include ディレクティブは設定ファイルを分割し、管理しやすくするために非常に重要です。メインの nginx.conf ファイルに全ての設定を記述するのではなく、以下のように分割することが一般的です。

  • /etc/nginx/nginx.conf: メイン設定（ワーカープロセス数、イベント設定、HTTPコンテキストの開始など）。include /etc/nginx/conf.d/*.conf; や include /etc/nginx/sites-enabled/*; などが記述されます。
  • /etc/nginx/mime.types: MIMEタイプ定義（Nginxパッケージに含まれることが多い）。
  • /etc/nginx/conf.d/: 共通設定や特定の機能に関する設定を置くディレクトリ。例えば、proxy.conf (プロキシ設定の共通ヘッダーなど), ssl.conf (SSL/TLS設定の共通パラメータ), gzip.conf (gzip設定)などを配置します。
  • /etc/nginx/sites-available/: 各ウェブサイト（仮想ホスト）の設定ファイルを置くディレクトリ。.conf 拡張子を付けたファイルでサイトごとに設定を記述します。
  • /etc/nginx/sites-enabled/: /etc/nginx/sites-available/ にある設定ファイルへのシンボリックリンクを置くディレクトリ。このディレクトリにある設定ファイルのみが nginx.conf から include されて有効になります。サイトを有効化/無効化したい場合は、このディレクトリへのシンボリックリンクを作成/削除するだけで済みます。

この構造により、特定のサイトの設定だけを変更したり、新しいサイトを追加したり、サイトを有効/無効にしたりといった作業が容易になります。

例: /etc/nginx/sites-available/example.com.conf

“`nginx

このファイルは /etc/nginx/sites-enabled/ にシンボリックリンクを作成して有効化される

server {
listen 80;
server_name example.com www.example.com;

# ここに個別のサイト設定を記述
root /var/www/example.com/html;
index index.html;
try_files $uri $uri/ =404;

# 共通設定ファイルがある場合
# include /etc/nginx/conf.d/common_headers.conf;

}
“`

例: /etc/nginx/conf.d/proxy_headers.conf

“`nginx

HTTPコンテキストやserverコンテキストでincludeされることを想定

proxy_set_header Host $host;

proxy_set_header X-Real-IP $remote_addr;

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

proxy_set_header X-Forwarded-Proto $scheme;

“`

このように設定を分割することで、nginx.conf 全体が巨大になるのを防ぎ、可読性とメンテナンス性を向上させることができます。

7. よくある落とし穴とトラブルシューティング

Nginxの設定でつまずきやすい点と、その解決策をいくつか紹介します。

  • 構文エラー (Syntax Errors): 最も一般的です。セミコロンの付け忘れ、波括弧の閉じ忘れ、ディレクティブ名のスペルミスなどです。nginx -t コマンドを必ず実行し、エラーメッセージの行番号を確認してください。
  • 設定が反映されない:
    • nginx -s reload または systemctl reload nginx を実行し忘れていませんか？
    • 編集したファイルが nginx.conf から include されているか確認してください。特に /etc/nginx/sites-enabled/ にシンボリックリンクがあるか確認してください。
    • 複数の server ブロックや location ブロックがある場合、リクエストが意図したブロックにマッチしているか確認してください。server_name や location のマッチング順序が重要です。
  • パーミッションエラー: Nginxワーカープロセスがファイル（HTMLファイル、ログファイル、証明書ファイルなど）を読み書きするための適切なファイルシステム権限を持っているか確認してください。Nginxは通常、特定のユーザー（nginx, www-dataなど）で実行されます。
  • ポートが使用中 (Port Conflict): listen ディレクティブで指定したポートが、既に他のプロセス（別のNginxインスタンス、Apache、Dockerコンテナなど）によって使用されていないか確認してください。ss -tulnp | grep <port_number> (または netstat -tulnp) コマンドで確認できます。
  • ファイアウォール: Nginxがリッスンしているポートへの外部からのアクセスが、OSのファイアウォール（ufw, firewalld, iptablesなど）によってブロックされていないか確認してください。
  • location マッチングの混乱: location の修飾子 (=, ^~, ~, ~*) や順序によって、どのブロックが適用されるか理解することが重要です。複雑なパス構造の場合は、テスト用のダミーファイルを作成して挙動を確認するか、error_log を debug レベルにしてリクエスト処理の流れを確認すると良いでしょう。（ただし、debugログは非常に大量に出力される可能性があるため注意）
  • リバースプロキシ時の無限リダイレクト: HTTPS終端をNginxで行い、バックエンドへHTTPで転送する場合、バックエンドアプリケーションが常にHTTPSを要求していると、バックエンドからのHTTPSリダイレクト応答をNginxが受け取り、再度HTTPでバックエンドに転送…というループが発生することがあります。これを避けるには、proxy_set_header X-Forwarded-Proto $scheme; などでプロトコル情報をバックエンドに正確に伝え、バックエンドアプリケーション側で X-Forwarded-Proto ヘッダーを確認するように実装する必要があります。
  • エラーログの確認: 何か問題が起きたら、まずはNginxのエラーログ (error_log ディレクティブで指定したファイル) を確認することが基本です。エラーの原因を示すメッセージが出力されていることが多いです。

8. さらなる学習に向けて

この記事では nginx.conf の基本的な構造と主要な設定について解説しましたが、Nginxには他にも様々な高度な機能やディレクティブが存在します。

  • キャッシュ機能: リバースプロキシとして使用する際に、バックエンドからの応答をNginx側でキャッシュし、パフォーマンスを大幅に向上させることができます (proxy_cache_path, proxy_cache, proxy_cache_validなど)。
  • レート制限: クライアントからのリクエストレートを制限し、サーバーの過負荷を防ぐことができます (limit_req_zone, limit_req)。
  • 接続制限: 同時接続数を制限することができます (limit_conn_zone, limit_conn)。
  • Web Application Firewall (WAF): ModSecurityなどのWAFモジュールと連携して、悪意のあるリクエストをブロックできます。
  • ストリームモジュール: HTTP以外のTCP/UDPトラフィックのリバースプロキシやロードバランシングを行うことができます。
  • 変数: $uri, $request_method, $remote_addr などの組み込み変数や、map ディレクティブで定義するカスタム変数を使って、より柔軟な設定が可能です。
  • Luaスクリプト: Luaモジュールを組み込むことで、設定内で複雑なロジックを実装できます。

これらの機能について学ぶことで、Nginxをさらに強力に活用できるようになります。公式ドキュメントは非常に詳細で正確な情報源です。

9. まとめ

この記事では、Nginxの設定ファイル nginx.conf の基本について以下の点を中心に解説しました。

  • nginx.conf の役割と一般的な配置場所
  • 設定ファイルの階層的なブロック構造（メイン、イベント、HTTP、サーバー、ロケーション、アップストリーム）
  • ディレクティブの基本構文（名前、引数、セミコロン、コメント）
  • 各主要コンテキスト (main, events, http, server, location, upstream) の目的とよく使われるディレクティブ
  • 静的ファイル配信、リバースプロキシ、SSL/TLS設定といった具体的な設定例
  • 設定変更後のテスト (nginx -t) と適用方法 (nginx -s reload, systemctl restart nginx)
  • include ディレクティブによる設定のモジュール化
  • 設定時のよくある落とし穴とトラブルシューティングのヒント

Nginxの設定は、ウェブサーバーの安定性、パフォーマンス、セキュリティに直接影響します。この記事で学んだ基本を基に、実際に設定ファイルを編集し、テストとリロードを繰り返しながら、Nginxの設定に慣れていくことが重要です。最初から複雑な設定を目指すのではなく、まずは静的ファイル配信やシンプルなリバースプロキシから始め、徐々に高度な設定に挑戦していくと良いでしょう。

Nginxはその柔軟性と拡張性から、非常に多岐にわたる用途に対応できます。この記事が、あなたのNginx設定ジャーニーの強力な一歩となることを願っています。

コメントする

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

上部へスクロール