これだけは知っておきたい！nginxの基本的な設定と特徴

By /

これだけは知っておきたい！Nginxの基本的な設定と特徴

Webサーバーは、現代のインターネットにおいて不可欠な存在です。その中でも、高性能かつ軽量なWebサーバーとして世界中の多くのWebサイトやアプリケーションで利用されているのがNginx（エンジンエックス）です。本記事では、Nginxの基本的な仕組み、特徴、そして初心者でも理解できる必須設定について、詳細に解説していきます。

1. はじめに：Nginxとは何か？

Nginxは、Igor Sysoev氏によって開発され、2004年に公開されたオープンソースのWebサーバーソフトウェアです。当初はC10k問題（同時に多数の接続を効率的に処理する問題）を解決するために設計されました。現在では、Webサーバーとしての機能に加え、リバースプロキシ、ロードバランサー、HTTPキャッシュ、メールプロキシなど、多岐にわたる用途で利用されています。

Nginxが登場する以前は、Apache HTTP ServerがWebサーバー市場の圧倒的なシェアを占めていました。Apacheはモジュールによる拡張性が高く、機能が豊富でしたが、接続数が増加するとパフォーマンスが低下しやすいという課題がありました。これは、Apacheがデフォルトで採用していたプロセスベースまたはスレッドベースの処理モデルに起因する部分が大きいです。

一方、Nginxは、後述するイベントドリブン型（非同期ノンブロッキング）アーキテクチャを採用することで、Apacheが苦手としていた多数の同時接続処理に非常に優れています。この特性から、高トラフィックなWebサイトや大規模なシステムにおいて、Nginxは急速に普及しました。現在では、アクティブなWebサイトにおいてNginxはApacheと並ぶ、あるいはそれ以上のシェアを獲得しています。

なぜNginxを知るべきなのでしょうか？

  • 高性能・高効率: 少数のプロセスで多数の接続を効率的に処理できるため、メモリ使用量が少なく、同じハードウェアリソースでもより多くのリクエストを捌くことができます。
  • 軽量: シンプルな設計で、起動が速く、リソース消費が少ないです。
  • 多機能: 静的ファイルの配信だけでなく、リバースプロキシ、ロードバランシング、キャッシングなど、現代のWebアプリケーションに必要な多くの機能を提供します。
  • 高い拡張性: モジュールによって機能を拡張できます（Apacheほどではありませんが）。
  • 信頼性: 長年にわたり多くの本番環境で稼働しており、安定性が高いです。

この記事では、Nginxの基本的な仕組みからインストール、そして最も重要な設定ファイルであるnginx.confの構造と主要なディレクティブについて、具体的な設定例を交えながら詳しく解説します。Nginxをこれから学びたい方、基本的な設定を理解したい方にとって、この記事が確かな第一歩となることを願っています。

2. Nginxのアーキテクチャと特徴

Nginxがなぜ高性能なのかを理解するには、その基本的なアーキテクチャを知ることが重要です。Nginxはイベントドリブン型（非同期ノンブロッキング）アーキテクチャを採用しています。

2.1 イベントドリブン型アーキテクチャとは？

従来のWebサーバー（Apacheのデフォルト設定など）は、クライアントからの接続があるたびに新しいプロセスやスレッドを生成して処理を行う、プロセスベース/スレッドベースのアーキテクチャが一般的でした。接続ごとにリソース（メモリ、CPU）を割り当てるため、同時接続数が増えるとプロセス/スレッド生成・管理のオーバーヘッドが大きくなり、パフォーマンスが低下したり、リソースを大量に消費したりする傾向がありました。これがC10k問題（同時に1万件の接続を捌けない、あるいは捌くのが困難になる問題）の根源の一つでした。

一方、Nginxのイベントドリブン型アーキテクチャでは、少数のワーカープロセスが、OSの提供する効率的なイベント通知機構（Linuxのepoll, FreeBSDのkqueue, Solarisの/dev/poll, WindowsのIOCPなど）を利用して、多数の接続を「待機」します。接続からのリクエストの読み込み、レスポンスの送信といったI/O処理が発生した際に、イベントとして通知を受け取り、その処理をノンブロッキング（処理完了を待たずに次の処理へ移る）で行います。

例えるなら、

  • プロセス/スレッドベース: 電話が鳴るたびに新しいオペレーターを雇い、そのオペレーターが通話が終わるまで他の電話に出られない。
  • イベントドリブン型: 少数のベテランオペレーターが、複数の電話回線を効率的に監視し、着信があったり、通話相手が話し終わったりするイベントを通知で受け取り、都度適切な対応を行う。対応中に相手が考え込んでいる間は、他の電話の対応に切り替える。

このように、Nginxは接続ごとに専用のリソースを割り当てるのではなく、限られたリソース（少数のプロセス）で多くの接続の状態を管理し、I/Oイベントが発生した接続に対して効率的に処理を切り替えていきます。このため、多数の同時接続があっても、リソース消費を抑えつつ高いパフォーマンスを維持できるのです。これが、NginxがC10k問題を解決できた大きな理由です。

2.2 マスタープロセスとワーカープロセス

Nginxのプロセスモデルは、主に以下の2種類のプロセスで構成されます。

  • マスタープロセス (Master Process):

    • Nginxの起動、停止、設定リロードを管理します。
    • 設定ファイルを読み込み、構文チェックを行います。
    • ワーカープロセスを生成、管理します。
    • ワーカープロセスが異常終了した場合、新しいプロセスを起動します。
    • 基本的に単一のプロセスとして動作します。

  • ワーカープロセス (Worker Processes):

    • クライアントからの接続を受け付け、リクエストを処理し、レスポンスを返します。
    • 実際のI/O処理（ネットワーク通信、ファイル操作）を行います。
    • イベントドリブン型アーキテクチャの主体であり、各ワーカープロセスは単一のスレッドで動作し、ノンブロッキングI/Oを利用して多数の接続を処理します。
    • 通常は、CPUコア数と同じか、それ以上の数を設定します。これは設定ファイル（nginx.conf）のworker_processesディレクティブで指定します。

このマスター/ワーカーモデルにより、Nginxは高い安定性と効率性を実現しています。マスタープロセスが全体を管理し、ワーカープロセスが実際の処理を並行して行うことで、例えば設定をリロードする際も、既存の接続を切断することなく新しい設定を適用する「graceful restart/reload」が可能になります。

2.3 その他の主要な特徴

  • C10k問題の解決: 上記のイベントドリブン型アーキテクチャにより、1万件以上の同時接続を効率的に処理できます。
  • リバースプロキシ: クライアントからのリクエストを、別のサーバー（バックエンドサーバー）に転送する機能です。これにより、バックエンドサーバーの負荷分散、セキュリティ向上、SSLオフロードなどが実現できます。
  • ロードバランサー: 複数のバックエンドサーバーにトラフィックを分散させる機能です。ラウンドロビン、IPハッシュ、最小接続数など、様々なアルゴバズムをサポートしています。
  • 静的ファイルサーバー: HTML、CSS、JavaScript、画像などの静的コンテンツを非常に高速かつ効率的に配信できます。これはNginxの最も基本的な機能の一つです。
  • HTTPキャッシュ: バックエンドサーバーからのレスポンスをキャッシュし、次回同じリクエストが来た際にキャッシュから素早く返信することで、バックエンドサーバーの負荷を軽減し、レスポンス速度を向上させます。
  • SSL/TLS終端: クライアントとのSSL/TLS接続をNginxで終端し、バックエンドサーバーとの通信はHTTPで行うことができます。これにより、バックエンドサーバーのCPU負荷を軽減できます。
  • モジュール構造: 必要に応じて様々なモジュール（HTTP/2, Gzip, SSL, Rewiteなど）を組み込むことで機能を拡張できます。

これらの特徴により、Nginxは単なるWebサーバーにとどまらず、現代の複雑なWebシステムにおける重要なコンポーネントとして広く利用されています。

3. Nginxのインストール

Nginxのインストールは、使用しているOSやディストリビューションによって異なります。ここでは、一般的な方法をいくつか紹介します。

3.1 Linuxでのインストール

多くのLinuxディストリビューションでは、パッケージマネージャーを使用してNginxを簡単にインストールできます。

Debian/Ubuntuの場合 (apt)

bash
sudo apt update
sudo apt install nginx

RHEL/CentOS/Fedoraの場合 (yum/dnf)

“`bash
sudo yum install epel-release # EPELリポジトリの有効化 (RHEL/CentOS)
sudo yum install nginx # CentOS 7まで

または

sudo dnf install nginx # Fedora/CentOS 8以降
“`

インストール後、Nginxサービスを起動し、システム起動時に自動実行されるように設定します。

bash
sudo systemctl start nginx
sudo systemctl enable nginx

ファイアウォールが有効な場合は、HTTP (80番ポート) と HTTPS (443番ポート) の通信を許可する必要があります。

“`bash

firewalldの場合 (RHEL/CentOS/Fedora)

sudo firewall-cmd –permanent –add-service=http
sudo firewall-cmd –permanent –add-service=https
sudo firewall-cmd –reload

ufwの場合 (Debian/Ubuntu)

sudo ufw allow ‘Nginx HTTP’
sudo ufw allow ‘Nginx HTTPS’
sudo ufw reload
“`

3.2 macOSでのインストール

macOSでは、Homebrewパッケージマネージャーを使用するのが一般的です。

bash
brew install nginx

インストール後、以下のコマンドでNginxを起動できます。

bash
brew services start nginx

macOSの場合、デフォルト設定ではhttp://localhost:8080でアクセスできることが多いです。

3.3 Windowsでのインストール

Windows版も存在しますが、Linux版に比べて情報が少なかったり、機能に制約があったりする場合があるため、本番環境では通常Linux系OSが使用されます。公式サイトからバイナリをダウンロードしてインストールします。

3.4 インストール後の確認

ブラウザでサーバーのIPアドレスまたはドメイン名にアクセスし、Nginxのデフォルトページが表示されればインストール成功です。

また、以下のコマンドでNginxのバージョンを確認できます。

bash
nginx -v

設定ファイルの構文チェックと場所の確認は以下のコマンドで行えます。

bash
nginx -t

このコマンドの出力で、設定ファイル（通常/etc/nginx/nginx.conf）のパスと、設定が正しいかどうかが表示されます。

4. Nginxの基本設定ファイル (nginx.conf)

Nginxの動作は、設定ファイルによって完全に制御されます。主要な設定ファイルは通常/etc/nginx/nginx.confにあります。このファイルは、複数の設定ブロックから構成されており、各ブロック内でディレクティブと呼ばれる設定項目を指定します。

4.1 設定ファイルの構造

nginx.confは、以下の図のように階層構造を持つブロックで構成されています。

“`nginx

グローバル/メインコンテキスト

user nginx;
worker_processes auto;
error_log /var/log/nginx/error.log warn;
pid /var/run/nginx.pid;

events {
# イベント処理に関する設定
worker_connections 1024;
# use epoll; # Linuxの場合によく使われる
}

http {
# HTTPサーバーに関する設定
include mime.types; # MIMEタイプ定義ファイルをインクルード
default_type application/octet-stream;

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;

sendfile        on;
#tcp_nopush     on; # sendfile on の場合に推奨

keepalive_timeout  65;

#gzip  on; # 圧縮設定

# バーチャルホスト定義
server {
    listen       80;          # 待ち受けポート
    server_name  localhost;   # ホスト名

    # 特定のURIに対する処理定義
    location / {
        root   /usr/share/nginx/html; # ドキュメントルート
        index  index.html index.htm; # デフォルトファイル
    }

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

# 別のバーチャルホスト (例: example.com)
# server {
#     listen 80;
#     server_name example.com www.example.com;
#     root /var/www/example.com/html;
#     index index.html;
# }

# 設定ファイルの分割によく使われる include
# include /etc/nginx/conf.d/*.conf;

}

stream { # TCP/UDPプロキシ設定 (必要な場合)

…

}

“`

主なブロック（コンテキスト）は以下の通りです。

  • main (グローバル): 設定ファイルの先頭に記述される全体的な設定。Nginxプロセス全体に関わる設定（ユーザー、ワーカープロセス数、エラーログなど）を行います。
  • events: ネットワーク接続の処理方法に関する設定。ワーカープロセスごとの最大接続数などを指定します。
  • http: HTTPサーバーとしての設定。このブロック内に複数のserverブロックを定義してバーチャルホストを設定します。HTTP全体に関わる設定（MIMEタイプ、ログフォーマット、タイムアウトなど）もここで行います。
  • server: バーチャルホストの設定。特定のドメイン名やIPアドレス、ポート番号に対する設定を行います。一つのhttpブロック内に複数のserverブロックを記述できます。
  • location: serverブロック内に記述され、特定のURIパスに対する処理設定（静的ファイルの配信、リバースプロキシ、アクセス制御など）を行います。一つのserverブロック内に複数のlocationブロックを記述できます。
  • stream: TCP/UDPプロキシに関する設定。Web以外のプロトコルを扱う場合に利用します（本記事では詳細を割愛します）。

ディレクティブ:

各ブロック内に記述される「キーワード 設定値;」の形式のものがディレクティブです。例えば、worker_processes auto;は、ワーカープロセス数を自動設定するというディレクティブです。ディレクティブは必ず末尾にセミコロン(;)が必要です。ブロックは中括弧({})で囲みます。

コメント:

設定ファイル中の#記号以降はコメントとして扱われ、Nginxに無視されます。設定の意図などをメモするのに便利です。

4.2 設定ファイルの場所と分割

デフォルトの設定ファイルは/etc/nginx/nginx.confですが、多くのディストリビューションでは、可読性や管理性を高めるために設定ファイルを複数のファイルに分割しています。

  • /etc/nginx/nginx.conf: メインの設定ファイル。httpブロックなどでincludeディレクティブを使って他のファイルを読み込むのが一般的です。
  • /etc/nginx/conf.d/: このディレクトリ内の.confファイルを自動的にインクルードする設定がnginx.confのhttpブロックにあることが多いです (include /etc/nginx/conf.d/*.conf;)。個別のバーチャルホスト設定などをこのディレクトリに配置します。
  • /etc/nginx/sites-available/ および /etc/nginx/sites-enabled/: Debian/Ubuntu系のディストリビューションでよく使われる仕組みです。sites-availableに設定ファイルを置き、sites-enabledにそのファイルへのシンボリックリンクを作成することで、有効/無効を切り替えます。

開発環境や小規模な設定であればnginx.confに全て記述しても問題ありませんが、複数のサイトをホストする場合や設定が複雑になる場合は、ファイルを分割することで管理が容易になります。

5. 各主要設定ブロックの詳細

ここでは、Nginx設定の核となる各ブロックについて、よく使われる主要なディレクティブを詳しく見ていきます。

5.1 main ブロック

Nginx全体の動作に関わる設定を行います。

  • user <user> [<group>];: ワーカープロセスを実行するユーザーとグループを指定します。セキュリティのため、root以外のユーザーを指定するのが一般的です。nginxユーザーなどがデフォルトで使用されます。
    nginx
    user nginx; # または www-data など
  • worker_processes <number> | auto;: ワーカープロセスの数を指定します。通常はCPUコア数と同じか、その1.5〜2倍程度に設定すると良いとされています。autoを指定すると、Nginxが自動的にCPUコア数を検出して設定します。
    nginx
    worker_processes auto;
    # worker_processes 4; # 4コアCPUの場合など
  • error_log <file> [<level>];: エラーログの出力先ファイルとログレベルを指定します。ログレベルは、debug, info, notice, warn, error, crit, alert, emerg のいずれかで、指定したレベル以上のエラーが記録されます。warnやerrorが一般的です。
    nginx
    error_log /var/log/nginx/error.log warn;
  • pid <file>;: マスタープロセスのプロセスID (PID) を記録するファイルを指定します。
    nginx
    pid /var/run/nginx.pid;

5.2 events ブロック

ワーカープロセスがどのように接続を処理するかに関する設定です。

  • worker_connections <number>;: 一つのワーカープロセスが同時に処理できる最大接続数を指定します。この値は、サーバーのリソース（ファイルディスクリプタ数など）やOSの制限と関連します。例えば、1024を指定すると、各ワーカープロセスは最大1024件の接続を処理できます。worker_processesとこの値の積が、理論上の最大同時接続数になります。
    nginx
    events {
    worker_connections 1024;
    }
  • use <method>;: イベント通知モデルを指定します。OSに最適なものを自動的に選択させることが多いですが、明示的に指定することも可能です（例: epoll for Linux, kqueue for FreeBSD/macOS, devpoll for Solaris, select/poll for汎用）。通常はコメントアウトしておき、Nginxに自動選択させるのが推奨されます。
    nginx
    events {
    worker_connections 1024;
    # use epoll;
    }

5.3 http ブロック

HTTPプロトコルに関するグローバル設定を行います。このブロック内に複数のserverブロックを含めることで、異なるドメイン名やポートで複数のWebサイト（バーチャルホスト）を運用できます。

  • include <file> | <mask>;: 他の設定ファイルをインクルードします。mime.typesなど、共通の設定ファイルを読み込むのに使われます。ワイルドカード（*）も使用可能です。
    nginx
    include mime.types; # よく使われるMIMEタイプの定義を読み込む
    include /etc/nginx/conf.d/*.conf; # conf.dディレクトリ内の.confファイルを全て読み込む
  • default_type <mime-type>;: ファイルのMIMEタイプがmime.typesなどで定義されていない場合のデフォルトMIMEタイプを指定します。
    nginx
    default_type application/octet-stream;
  • log_format <name> <format>;: アクセスログのフォーマットを定義します。<name>でフォーマット名を指定し、<format>で変数を使ってフォーマットを記述します。mainという名前のフォーマットがよく使われます。
    nginx
    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 <file> [<format> | off];: アクセスログの出力先ファイルと、使用するログフォーマット（上記で定義した名前）を指定します。offを指定するとログを無効にします。
    nginx
    access_log /var/log/nginx/access.log main;
  • sendfile on | off;: ファイル送信にsendfile()システムコールを使用するかどうかを指定します。カーネルレベルでのファイル送信が可能になり、CPUオーバーヘッドが削減されるため、静的ファイルの配信パフォーマンスが向上します。通常はonに設定します。
    nginx
    sendfile on;
  • tcp_nopush on | off;: sendfile onの場合に有効な設定です。レスポンスヘッダーとファイルの内容をまとめて送信することで、ネットワーク効率を向上させます。通常はonに設定します。
    nginx
    tcp_nopush on;
  • tcp_nodelay on | off;: keepalive_timeoutが有効な場合に有効な設定です。小さなデータをすぐに送信するか（on）、一定量まとまるまで待機するか（off）を指定します。リアルタイム性が重要な場合はon、効率が重要な場合はoffですが、通常はonで問題ありません。
    nginx
    tcp_nodelay on;
  • keepalive_timeout <timeout> [header_timeout];: Keep-Aliveコネクションのタイムアウト時間を秒数で指定します。これにより、一つのTCP接続で複数のリクエスト/レスポンスをやり取りできるようになり、接続確立のオーバーヘッドを削減できます。一般的に60秒〜120秒程度が使われます。
    nginx
    keepalive_timeout 65;
  • types_hash_max_size <size>;: MIMEタイプハッシュテーブルの最大サイズを指定します。mime.typesが多い場合やカスタムMIMEタイプを定義する場合に調整が必要になることがあります。
    nginx
    types_hash_max_size 2048;
  • server_tokens on | off | build | string;: Nginxのバージョン情報をレスポンスヘッダー（Serverヘッダー）に含めるかどうかを指定します。セキュリティのためoffにするのが推奨されます。
    nginx
    server_tokens off;
  • gzip on | off;: レスポンスをgzip圧縮するかどうかを指定します。帯域幅の節約になりますが、CPUリソースを消費します。テキストベースのコンテンツ（HTML, CSS, JavaScript）に有効です。詳細な設定は後述します。
    nginx
    gzip on;

5.4 server ブロック

特定のバーチャルホストを定義します。IPアドレス、ポート、ドメイン名に基づいてどのserverブロックでリクエストを処理するかを決定します。

  • listen <address>:<port> [parameters];: Nginxがリクエストを待ち受けるIPアドレスとポート番号を指定します。
    • listen 80;: 全てのIPアドレスの80番ポートで待ち受け。
    • listen 192.168.1.1:80;: 特定のIPアドレスの80番ポートで待ち受け。
    • listen 80 default_server;: どのserver_nameにもマッチしなかった場合のデフォルトサーバーとして指定します。
    • listen 443 ssl;: 443番ポートで待ち受け、SSL/TLSを有効にします。
      nginx
      server {
      listen 80;
      listen 443 ssl; # HTTPとHTTPSの両方で待ち受ける例
      ...
      }

  • server_name <name> [...];: このserverブロックが処理するホスト名（ドメイン名）を指定します。複数のホスト名をスペース区切りで指定できます。ワイルドカード（*.example.com, www.*）や正規表現（~ ^www\.(.+)\.com$;）も使用可能です。リクエストのHostヘッダーと照合されます。
    “`nginx
    server {
    listen 80;
    server_name example.com www.example.com; # 複数のドメイン名を指定
    …
    }

    server {
    listen 80;
    server_name *.sub.example.com; # ワイルドカード
    …
    }

    server {
    listen 80;
    server_name ~^www.(?.+).com$; # 正規表現 (名前付きキャプチャも可能)
    …
    }
    ``
    **    server_nameのマッチング優先順位:**
    1. 完全一致する名前
    2. アスタリスクが先頭にあるワイルドカード名（例:    .example.com）
    3. アスタリスクが末尾にあるワイルドカード名（例:    www.    `）
    4. 正規表現

    どのserver_nameにもマッチしない場合、listenディレクティブにdefault_serverパラメータが指定されたサーバーブロックが処理されます。default_serverが指定されていない場合は、nginx.conf内で最初に定義されたserverブロックがデフォルトサーバーとして扱われます。

  • root <path>;: このserverブロック全体、またはlocationブロックで指定されなかった場合のドキュメントルートディレクトリを指定します。静的ファイルはこのディレクトリ以下から探されます。
    nginx
    server {
    listen 80;
    server_name example.com;
    root /var/www/example.com/html; # このサーバーのドキュメントルート
    ...
    }

  • index <file> [...];: ディレクトリへのリクエストが来た際に、デフォルトで返すファイル名を指定します。指定された順にファイルを探します。
    nginx
    server {
    ...
    index index.html index.htm index.php; # index.htmlがあればそれを返し、なければindex.htm、...
    ...
    }
  • error_page <code...> <uri>;: 特定のHTTPステータスコードが発生した場合に、指定されたURIの内容をクライアントに返します。カスタムエラーページを表示するのに使います。
    nginx
    server {
    ...
    error_page 404 /404.html; # 404エラーが発生したら/404.htmlの内容を返す
    location = /404.html { # error_pageで指定したURIの処理は別途locationブロックで定義するのが一般的
    root /usr/share/nginx/html; # 404.htmlがある場所
    internal; # このlocationは外部からの直接アクセスを許可しない
    }
    error_page 500 502 503 504 /50x.html; # 複数のエラーコード
    location = /50x.html {
    root /usr/share/nginx/html;
    }
    ...
    }
  • ssl_certificate <file>;, ssl_certificate_key <file>;: SSL/TLS通信に使用する証明書ファイルと秘密鍵ファイルを指定します。HTTPSサイトを構築する際に必須です。
    “`nginx
    server {
    listen 443 ssl;
    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_protocols <protocol...> ;`: 使用を許可するSSL/TLSプロトコルバージョンを指定します。セキュリティのため、古いSSLv3などを無効にし、TLSv1.2やTLSv1.3のみを有効にするのが推奨されます。nginx
    ssl_protocols TLSv1.2 TLSv1.3;
    * `ssl_ciphers <cipher_string>;`: 使用を許可する暗号スイートを指定します。強力な暗号化アルゴリズムのみを許可することで、セキュリティを向上させます。複雑な設定文字列になりますが、セキュリティガイドラインやツールで推奨される設定を利用するのが一般的です。nginx
    ssl_ciphers ‘ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:…’; # 推奨設定文字列
    “`

5.5 location ブロック

serverブロック内に記述され、リクエストURIに基づいて特定の処理を定義します。locationディレクティブは、様々なマッチング方法と優先順位を持っています。

マッチング方法:

  • location = <uri> { ... }: URIが<uri>と完全に一致する場合にマッチします。最も優先順位が高いです。
  • location ^~ <uri> { ... }: URIが<uri>で始まる場合にマッチします。正規表現マッチより優先されます。
  • location ~ <regex> { ... }: URIが<regex>（大文字・小文字を区別する正規表現）にマッチする場合にマッチします。
  • location ~* <regex> { ... }: URIが<regex>（大文字・小文字を区別しない正規表現）にマッチする場合にマッチします。
  • location <uri> { ... }: URIが<uri>で始まる場合にマッチします（プレフィックスマッチ）。正規表現マッチより優先度は低いですが、^~がない場合は先に評価されます。
  • location / { ... }: 全てのURIにマッチします。どの他のlocationブロックにもマッチしなかった場合の最終的なフォールバックとして機能します。最も優先順位が低いです。

マッチング優先順位 (複雑ですが、概ね以下の順に評価されます):

  1. = による完全一致マッチ
  2. ^~ によるプレフィックスマッチ
  3. 正規表現マッチ（~ または ~*）。複数の正規表現がマッチする場合、設定ファイル中で先に定義されたものが優先されます。
  4. 通常のプレフィックスマッチ
  5. / によるフォールバック

よく使うディレクティブ (locationブロック内):

  • root <path>;: このlocationブロックで処理されるリクエストに対するドキュメントルートを指定します。これはserverブロックのrootを上書きします。
  • alias <path>;: rootと似ていますが、マッチしたURIの残りの部分をaliasで指定したパスにマッピングします。locationの定義の最後にスラッシュ/がある場合は、aliasの定義の最後にもスラッシュが必要です。
    nginx
    # 例: /images/a.jpg へのリクエスト
    location /images/ {
    root /var/www/html/; # -> /var/www/html/images/a.jpg を探す
    }
    location /static/ {
    alias /opt/static/; # -> /opt/static/a.jpg (a.jpgはURIの/static/より後ろの部分) を探す
    }
    通常、rootはlocation /のようなプレフィックスマッチで使用し、aliasはより具体的なパスや正規表現マッチで使用します。
  • index <file> [...];: このlocationで処理されるディレクトリへのリクエストに対するデフォルトファイル名を指定します。

  • try_files <file> ... <uri> | =<code>;: リクエストされたURIに対応するファイルを特定の順序で探します。ファイルが見つからない場合は、指定されたURIに内部リダイレクトするか、指定されたステータスコードを返します。静的ファイル配信で非常によく使われます。
    “`nginx
    location / {
    # /path/to/request.html を探す
    # なければ /path/to/request/index.html を探す
    # なければ /index.html に内部リダイレクトする
    try_files $uri $uri/ /index.html;
    }

    location /static/ {
    # /var/www/static/request.js を探す
    # なければ 404 エラーを返す
    root /var/www/;
    try_files $uri =404;
    }
    `$uri`はリクエストURI（例えば`/images/logo.png`）、`$uri/`はリクエストURIに`/`を付けたもの（例えば`/images/logo.png/`、ディレクトリとして解釈される）、最後のパスは内部リダイレクト先URIです。
    * `return <code [text]>;`: 指定されたステータスコードとオプションのテキストをクライアントに返します。単純なリダイレクトやエラー応答に使われます。    nginx
    location /old-path {
    return 301 /new-path; # /old-path へのリクエストを /new-path に恒久的にリダイレクト (301 Moved Permanently)
    }

    location /forbidden {
    return 403 “Access Denied”; # 403 Forbidden エラーを返す
    }
    * `proxy_pass <url>;`: リクエストを別のサーバー（バックエンドサーバー）に転送します。Nginxをリバースプロキシとして使用する際に使用する最も重要なディレクティブです。nginx
    location /api/ {
    proxy_pass http://backend_server_address; # または upstream で定義した名前
    }
    “`
    詳細なリバースプロキシ設定は後述します。

6. 静的ファイルサーバーとしてのNginx

Nginxの最も基本的な役割の一つは、HTML、CSS、JavaScript、画像などの静的コンテンツを高速に配信することです。イベントドリブンアーキテクチャとsendfileなどの効率的なI/O処理により、非常に高いパフォーマンスを発揮します。

基本的な設定は以下のようになります。

“`nginx
server {
listen 80;
server_name your_domain.com;

root /var/www/html; # Webサイトのファイルが置かれているディレクトリ

location / {
    # リクエストURI ($uri) に対応するファイルを root ディレクトリから探す
    # 見つからなければ、URIに / を付けたディレクトリ内の index.html を探す ($uri/)
    # それも見つからなければ、/index.html を探す
    try_files $uri $uri/ /index.html =404; # 最後の =404 は、どれも見つからなければ404エラーを返す
}

# 特定の種類のファイルに対するキャッシュ設定などもここに追加できる
location ~* \.(css|js|jpg|jpeg|gif|png|svg|webp)$ {
    root /var/www/html;
    expires 30d; # クライアント側のキャッシュ期間を30日間に設定
    access_log off; # 静的ファイルはログに残さない場合
}

}
“`

解説:

  • root /var/www/html;: このサーバーブロック全体のドキュメントルートを指定します。/以下のリクエストは、rootで指定されたディレクトリからの相対パスで処理されます。
  • location / { ... }: 全てのURIにマッチするフォールバックのロケーションです。
  • try_files $uri $uri/ /index.html =404;:
    • $uri: リクエストされたURI（例: /about/index.html）。rootと組み合わされて/var/www/html/about/index.htmlを探します。
    • $uri/: リクエストURIに/を付けたもの（例: /about/ -> /about/index.html）。ディレクトリへのアクセス時にindexディレクティブで指定されたファイルを探すのと同じ動作をします。
    • /index.html: 上記で見つからなかった場合のフォールバックURIです。NginxはこのURIに対して内部リダイレクトを行い、location /ブロック（あるいはマッチする他のlocationブロック）で再処理します。この例では/var/www/html/index.htmlが返されます。これはシングルページアプリケーション(SPA)などで、存在しないパスへのアクセスを全てindex.htmlにルーティングするのに便利です。
    • =404: 上記のどのファイルも見つからなかった場合に、404 Not Foundエラーを返します。
  • location ~* \.(css|js|jpg|jpeg|gif|png|svg|webp)$ { ... }: 拡張子がCSS, JS, 画像ファイルである場合にマッチする正規表現ロケーションです。~*はケースインセンシティブ（大文字小文字を区別しない）マッチです。
  • expires 30d;: ブラウザなどのクライアントに対して、このリソースを30日間キャッシュして良いというヘッダー（Cache-ControlやExpires）を付与します。静的コンテンツの表示速度向上とサーバー負荷軽減に有効です。
  • access_log off;: 静的ファイルへのアクセスログは大量になりがちなので、不要であれば無効にすることでディスクI/Oを削減できます。

7. リバースプロキシとしてのNginx

リバースプロキシとは、クライアントからのリクエストを受け付け、それを内部のバックエンドサーバー（アプリケーションサーバーなど）に転送し、バックエンドサーバーからのレスポンスを受け取ってクライアントに返すサーバーです。Nginxはこのリバースプロキシ機能に非常に優れており、Webシステムの中核として広く利用されています。

7.1 リバースプロキシのメリット

  • 負荷分散: 複数のバックエンドサーバーにトラフィックを分散させ、単一サーバーへの負荷集中を防ぎます。（ロードバランシング機能）
  • セキュリティ向上: バックエンドサーバーの存在や内部ネットワーク構成を隠蔽できます。外部からの直接アクセスを防ぎ、Nginxでアクセス制御やSSL終端を行うことで、バックエンドサーバーのセキュリティ負担を軽減できます。
  • SSL/TLS終端: NginxでSSL証明書を管理し、HTTPS接続を終端させることができます。バックエンドサーバーはHTTPで通信できるため、SSL処理の負荷から解放されます。
  • キャッシング: バックエンドからのレスポンスをNginxでキャッシュし、同じリクエストに対してはキャッシュから返すことで、バックエンドの負荷を軽減し、応答速度を向上させます。
  • 圧縮: バックエンドからのレスポンスをNginxで圧縮してクライアントに返すことができます。
  • A/Bテストやルーティング: 特定の条件に基づいてリクエストを異なるバックエンドにルーティングすることができます。

7.2 基本的なリバースプロキシ設定 (proxy_pass)

proxy_passディレクティブは、リクエストを転送するバックエンドサーバーのURLを指定します。

“`nginx
server {
listen 80;
server_name your_app.com;

location / {
    proxy_pass http://127.0.0.1:8000; # ローカルホストの8000番ポートで動くバックエンドへ転送
    # proxy_pass http://backend.internal.network/app/; # ドメイン名でも指定可能
}

location /api/ {
    proxy_pass http://backend-api-server; # 別の上流サーバーグループへ転送 (upstreamで定義)
}

}
“`

proxy_passで指定するURLの末尾に/を付けるか付けないかで、転送されるURIが変わることに注意が必要です。

  • proxy_pass http://backend/; (proxy_passのURLの末尾に/がある場合):
    リクエストURIのlocationブロックでマッチした部分が、proxy_passのURLに置き換えられます。
    例: location /app/ { proxy_pass http://backend/; }
    /app/users へのリクエスト → http://backend/users へ転送
  • proxy_pass http://backend; (proxy_passのURLの末尾に/がない場合):
    リクエストURIのlocationブロックでマッチした部分が、proxy_passのURLに追加されます。
    例: location /app/ { proxy_pass http://backend; }
    /app/users へのリクエスト → http://backend/app/users へ転送

意図しないURIへの転送を防ぐため、一般的にはproxy_passのURLの末尾に/を付け、locationブロックのマッチングと合わせて転送先URIを制御することが多いです。あるいは、location / { ... }のようにルートに対する設定を行う場合は、proxy_passに/を付けない方が直感的な結果になることが多いです。

7.3 重要なプロキシヘッダー (proxy_set_header)

クライアントからNginxへのリクエストには様々なHTTPヘッダーが含まれていますが、デフォルトでは一部しかバックエンドサーバーに転送されません。特に重要なヘッダーをバックエンドに伝えるためには、proxy_set_headerディレクティブを使用してヘッダーを再設定または追加する必要があります。

  • Host: オリジナルのリクエストのHostヘッダーをバックエンドに伝えます。バックエンドがバーチャルホストで動作している場合に重要です。
  • X-Real-IP: クライアントのIPアドレスをバックエンドに伝えます。Nginxが直接クライアントに接続している場合のIPアドレスです。
  • X-Forwarded-For: クライアントのIPアドレス（および途中のプロキシのIPアドレス）をバックエンドに伝えます。複数のプロキシを経由する場合に、元のクライアントIPを特定するために使用されます。
  • X-Forwarded-Proto: クライアントがNginxに接続した際のプロトコル（httpまたはhttps）をバックエンドに伝えます。バックエンドがHTTPで待ち受けているが、HTTPSでアクセスされたことを知りたい場合に重要です。

推奨される基本的な設定は以下の通りです。

“`nginx
location / {
proxy_pass http://backend_server_address;

# 重要なヘッダーを設定
proxy_set_header Host $host; # $host はオリジナルのHostヘッダーの値
proxy_set_header X-Real-IP $remote_addr; # $remote_addr はクライアントのIPアドレス
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; # 既存の値にクライアントIPを追加
proxy_set_header X-Forwarded-Proto $scheme; # $scheme は http または https

}
“`

$proxy_add_x_forwarded_forという特別な変数を使用すると、クライアントのIPアドレスが既存のX-Forwarded-Forヘッダーに自動的に追加されるため便利です。

7.4 プロキシバッファリングとタイムアウト

リクエストやレスポンスのバッファリング、および各種タイムアウト設定も重要です。

  • proxy_buffering on | off;: レスポンスをNginxのバッファに溜め込むかどうかを指定します。on（デフォルト）の場合、バックエンドからのレスポンスをNginxが全て受け取ってからクライアントに送信するため、バックエンドはすぐに次のリクエストを処理できます。offの場合、レスポンスはすぐにクライアントに送信されます。大きなファイルやストリーミングなどではoffが適している場合があります。
  • proxy_buffers <number> <size>;: バッファリングが有効な場合に、ワーカープロセスごとに割り当てるバッファの数とサイズを指定します。
  • proxy_buffer_size <size>;: レスポンスヘッダーや小さなレスポンスボディに使用するバッファサイズを指定します。
  • proxy_connect_timeout <time>;: バックエンドサーバーへの接続を確立する際のタイムアウトを指定します。
  • proxy_send_timeout <time>;: バックエンドサーバーへリクエストを送信する際のタイムアウトを指定します。
  • proxy_read_timeout <time>;: バックエンドサーバーからのレスポンスを読み込む際のタイムアウトを指定します。

“`nginx
location / {
proxy_pass http://backend_server_address;

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;

proxy_connect_timeout 60s; # 接続タイムアウト (デフォルト 60s)
proxy_send_timeout 60s;    # 送信タイムアウト (デフォルト 60s)
proxy_read_timeout 60s;    # 読み込みタイムアウト (デフォルト 60s)

proxy_buffering on; # バッファリング有効 (デフォルト)
proxy_buffers 8 16k; # 8個の16KBバッファ
proxy_buffer_size 8k; # 小さなバッファ

}
“`

これらの設定を適切に行うことで、リバースプロキシとしてのパフォーマンスと安定性を向上させることができます。

8. ロードバランサーとしてのNginx

複数のバックエンドサーバーがある場合に、それらのサーバーへ効率的にリクエストを分散させるのがロードバランシングです。Nginxは内蔵のロードバランシング機能を提供しており、リバースプロキシと組み合わせて使用します。

8.1 ロードバランシングの概念

ロードバランシングは、 incoming（入ってくる）トラフィックを複数のサーバーに分散させることで、以下のメリットをもたらします。

  • 可用性向上: 一部のサーバーがダウンしても、他のサーバーがリクエストを処理し続けるため、サービス全体の可用性が向上します。
  • スケーラビリティ: サーバーを追加することで、システム全体の処理能力を向上させることができます。
  • パフォーマンス向上: 各サーバーの負荷が軽減されるため、個々のリクエスト処理速度が向上します。

8.2 upstream ブロックの定義

Nginxでロードバランシングを行うには、まずhttpブロック内でupstreamブロックを定義し、そこにバックエンドサーバーのリストを記述します。

“`nginx
http {
# … 他の http 設定 …

upstream backend_servers { # バックエンドサーバーグループの名前
    server backend1.example.com;
    server backend2.example.com:8080; # ポート指定も可能
    server 192.168.1.100;
    server unix:/tmp/backend3.sock; # Unixドメインソケットも可能

    # サーバーパラメータ (オプション)
    # server backend4.example.com weight=3; # 重み付け (3倍リクエストを送る)
    # server backend5.example.com down;     # サーバーを一時的に無効にする
    # server backend6.example.com backup;   # 全てのプライマリサーバーがダウンした場合に使用
}

server {
    listen 80;
    server_name your_loadbalanced_app.com;

    location / {
        proxy_pass http://backend_servers; # upstreamで定義した名前を指定
        # ... プロキシヘッダーなどの設定 ...
    }
}

}
“`

upstreamブロック内で定義されたサーバーグループの名前（例: backend_servers）を、proxy_passディレクティブで指定します。これにより、Nginxはこのグループ内のサーバーにリクエストを分散して転送します。

8.3 ロードバランシングアルゴリズム

Nginxはいくつかのロードバランシングアルゴリズムをサポートしています。デフォルトはラウンドロビンです。upstreamブロック内で指定します。

  • round_robin (デフォルト): リクエストをバックエンドサーバーに順番に振り分けます。最もシンプルで広く使われるアルゴリズムです。
    nginx
    upstream backend_servers {
    # アルゴリズム指定なし = round_robin
    server backend1.example.com;
    server backend2.example.com;
    }
  • least_conn: その時点でアクティブな接続数が最も少ないサーバーにリクエストを振り分けます。接続時間が長いリクエストが多い場合に有効です。
    nginx
    upstream backend_servers {
    least_conn; # アルゴリズム指定
    server backend1.example.com;
    server backend2.example.com;
    }
  • ip_hash: クライアントのIPアドレスのハッシュ値に基づいてサーバーを決定します。同じクライアントからのリクエストは常に同じサーバーに振り分けられるため、セッション維持が必要なアプリケーションに適しています。ただし、IPアドレスが変わるとセッションが切れる可能性があります。
    nginx
    upstream backend_servers {
    ip_hash; # アルゴリズム指定
    server backend1.example.com;
    server backend2.example.com;
    }
  • hash [consistent]; (Nginx Plus またはサードパーティモジュール): 指定したキー（変数や文字列など）のハッシュ値に基づいてサーバーを決定します。ip_hashよりも柔軟です。consistentパラメータは、サーバーリストの変更によるキーのマッピング変動を最小限に抑えます。
    nginx
    upstream backend_servers {
    hash $request_uri consistent; # リクエストURIに基づいてハッシュ
    server backend1.example.com;
    server backend2.example.com;
    }
  • random [least_conn | two] ; (Nginx Plus またはサードパーティモジュール): ランダムにサーバーを選びます。least_connパラメータを付けると、ランダムに2つサーバーを選び、そのうち接続数が少ない方に振り分けます。
    nginx
    upstream backend_servers {
    random least_conn;
    server backend1.example.com;
    server backend2.example.com;
    }
  • least_time [header | last_byte]; (Nginx Plus またはサードパーティモジュール): 最も応答時間が短いサーバーにリクエストを振り分けます。headerはヘッダー受信までの時間、last_byteは全バイト受信までの時間で判断します。

8.4 ヘルスチェック

ロードバランサーにとって、バックエンドサーバーが正常に動作しているか（ヘルスチェック）を判断し、異常なサーバーへのリクエスト転送を停止することは非常に重要です。Nginxオープンソース版には、バックエンドへの接続エラーが発生した場合にそのサーバーを一時的に切り離す基本的なヘルスチェック機能（Passive Health Check）があります。

nginx
upstream backend_servers {
server backend1.example.com max_fails=3 fail_timeout=30s; # 30秒間に3回失敗したら、30秒間そのサーバーを無効にする
server backend2.example.com max_fails=3 fail_timeout=30s;
}

max_fails: 指定した回数リクエストが失敗した場合、そのサーバーは異常とみなされます。デフォルトは1回です。0を指定するとヘルスチェックは無効になります。
fail_timeout: max_fails回失敗したサーバーを、この指定時間だけ無効にします。この時間経過後、最初の正常なリクエストが成功すれば再度有効になります。デフォルトは10秒です。

より高度なActive Health Check（定期的にバックエンドにリクエストを送信して応答を確認する機能）は、Nginx Plusで提供されます。

9. キャッシュサーバーとしてのNginx

Nginxはリバースプロキシとして機能する際に、バックエンドサーバーからのレスポンスをキャッシュする機能も提供します。これにより、同じリクエストが来た際にバックエンドに問い合わせることなく、Nginx自身がキャッシュからレスポンスを返すことができ、バックエンドの負荷軽減と応答速度の大幅な向上が期待できます。

9.1 キャッシュ機能の有効化

キャッシュ機能を使用するには、まずキャッシュデータを保存する場所を定義し、次にその場所を指定してキャッシュを有効にします。

“`nginx
http {
# … 他の http 設定 …

# キャッシュパスの定義 (httpブロック内)
# proxy_cache_path <path> levels=L1:L2 keys_zone=name:size max_size=size [inactive=time] [use_temp_path=on|off];
proxy_cache_path /data/nginx/cache levels=1:2 keys_zone=my_cache:10m max_size=1g inactive=60m use_temp_path=off;
# /data/nginx/cache: キャッシュを保存するルートディレクトリ
# levels=1:2: キャッシュキーのハッシュ値に基づいて2段階のサブディレクトリを作成 (例: /data/nginx/cache/c/29)
# keys_zone=my_cache:10m: キャッシュキーとメタデータをメモリに保存するゾーン名(my_cache)とサイズ(10MB)。zoneサイズはキー1000個あたり約0.5MBが必要と言われます。
# max_size=1g: キャッシュディレクトリの最大サイズ (1GB)。このサイズを超えると、古いキャッシュが削除されます。
# inactive=60m: 60分間アクセスされなかったキャッシュアイテムを削除します。
# use_temp_path=off: キャッシュファイル書き込み時に一旦テンポラリディレクトリに書き込まず、直接キャッシュディレクトリに書き込みます。パフォーマンス向上に寄与します。オンの場合は proxy_temp_path を指定する必要があります。

server {
    listen 80;
    server_name your_cached_site.com;

    location / {
        proxy_pass http://backend;

        # キャッシュの有効化 (locationブロック内)
        proxy_cache my_cache; # keys_zoneで定義したゾーン名を指定

        # キャッシュ期間の設定
        proxy_cache_valid 200 302 10m; # ステータスコード200, 302のレスポンスを10分間キャッシュ
        proxy_cache_valid 404 1m;      # 404レスポンスも1分間キャッシュ
        proxy_cache_valid any 1m;      # その他のステータスコードを1分間キャッシュ

        # キャッシュキーの定義 (デフォルトは $scheme$proxy_host$request_uri)
        # proxy_cache_key "$host$request_uri $cookie_user"; # カスタムキャッシュキー (例: ホスト名+URI+ユーザーIDクッキー)

        # キャッシュヒット/ミスの情報をヘッダーに追加 (デバッグ用など)
        add_header X-Cache-Status $upstream_cache_status;
        # Possible values: MISS, BYPASS, EXPIRED, STALE, UPDATING, REVALIDATED, HIT
    }
}

}
“`

解説:

  • proxy_cache_path: キャッシュ機能全体の構成を定義します。これはhttpブロック内で一度だけ定義します。
  • proxy_cache: locationブロック内で、使用するキャッシュゾーン（keys_zoneで定義した名前）を指定してキャッシュを有効にします。
  • proxy_cache_valid: どのステータスコードのレスポンスを、どのくらいの期間キャッシュするかを定義します。
  • proxy_cache_key: キャッシュのキーとして使用する値を定義します。デフォルトは $scheme$proxy_host$request_uri ですが、必要に応じて $arg_ 変数（クエリストリングパラメータ）、$cookie_ 変数（クッキー）などを組み合わせてカスタムキーを設定できます。
  • add_header X-Cache-Status $upstream_cache_status;: デバッグや監視のために、そのリクエストがキャッシュから返されたか（HIT）、バックエンドに問い合わせたか（MISS）などの情報をレスポンスヘッダーに追加します。

9.2 キャッシュ制御に関するディレクティブ

バックエンドサーバーは、レスポンスヘッダー（Cache-Control, Expiresなど）でキャッシュの挙動を制御できます。Nginxはデフォルトでこれらのヘッダーに従いますが、Nginx側でキャッシュの挙動を強制的に制御することも可能です。

  • proxy_ignore_headers <header> [...];: バックエンドからのレスポンスに含まれる特定のヘッダー（例: Cache-Control, Expires, Set-Cookie）を無視します。Nginxでキャッシュ期間を完全に制御したい場合や、Set-Cookieヘッダーが含まれるレスポンスをキャッシュしたい場合などに使用します。
  • proxy_cache_bypass <string> [...];: 指定した文字列の値が空または”0″でない場合、キャッシュを参照せずにバックエンドサーバーにリクエストを転送します。例えば、ログインユーザーのリクエストをキャッシュしないようにする場合などに使います。
    nginx
    proxy_cache_bypass $cookie_nocache $arg_nocache; # nocacheというクッキーかクエリストリングがある場合はキャッシュバイパス
  • proxy_no_cache <string> [...];: 指定した文字列の値が空または”0″でない場合、バックエンドからのレスポンスをキャッシュしません。
    nginx
    proxy_no_cache $cookie_sessionid; # セッションIDクッキーがあるレスポンスはキャッシュしない

これらのディレクティブを適切に使用することで、キャッシュの効率と正確性を高めることができます。

10. SSL/TLS設定

Webサイトのセキュリティと信頼性を向上させるために、HTTPS化は必須です。NginxはSSL/TLS終端機能を提供し、効率的にHTTPS通信を処理できます。

基本的なHTTPS設定はserverブロック内で行います。

“`nginx
server {
listen 443 ssl; # 443番ポートでSSL/TLSを有効にして待ち受け
server_name your_secure_domain.com;

# SSL証明書と秘密鍵のパスを指定
ssl_certificate /etc/letsencrypt/live/your_secure_domain.com/fullchain.pem; # 証明書ファイル
ssl_certificate_key /etc/letsencrypt/live/your_secure_domain.com/privkey.pem; # 秘密鍵ファイル

# 使用するSSL/TLSプロトコルを指定 (古い/脆弱なバージョンは無効化)
ssl_protocols TLSv1.2 TLSv1.3;

# 使用する暗号スイートを指定 (強力なもののみを選択)
# Mozilla SSL Configuration Generator などのツールで推奨設定を生成するのが良い
ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:...';

# サーバー側で暗号スイートの順序を優先 (クライアント指定より優先)
ssl_prefer_server_ciphers on;

# SSLセッションキャッシュの設定 (パフォーマンス向上)
ssl_session_cache shared:SSL:10m; # SSLという名前で10MBの共有キャッシュ
ssl_session_timeout 10m;          # セッションキャッシュの有効期限

# HSTS (HTTP Strict Transport Security) ヘッダーの追加
# 今後このドメインへのアクセスは必ずHTTPSで行うようブラウザに指示 (セキュリティ向上)
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload";

# ... 他の server, location 設定 ...

}
“`

解説:

  • listen 443 ssl;: 443番ポートで待ち受け、このポートへの接続に対してSSL/TLSを有効にします。
  • ssl_certificate / ssl_certificate_key: 証明機関(CA)から取得したSSL証明書ファイルと、その証明書に対応する秘密鍵ファイルのパスを指定します。Let’s Encryptなどの無料CAや、商用CAから取得した証明書を使用します。
  • ssl_protocols / ssl_ciphers: 使用するプロトコルと暗号スイートを制限します。最新かつ安全な設定を選択することがセキュリティ上非常に重要です。これらの設定は定期的に見直す必要があります。
  • ssl_prefer_server_ciphers on;: これをonにすると、Nginxがクライアントよりもサーバー側の暗号スイートリストの順序を優先して使用します。これにより、より強力な暗号化を優先的に使用させることができます。
  • ssl_session_cache / ssl_session_timeout: SSL/TLS接続確立には計算リソースが必要ですが、セッション情報をキャッシュすることで、同じクライアントからの再接続時のハンドシェイクを高速化し、サーバー負荷を軽減できます。
  • add_header Strict-Transport-Security ...;: HSTSヘッダーを追加することで、ユーザーエージェント（ブラウザなど）に、今後このドメインへのアクセスは全てHTTPSで行うように強制させます。これにより、中間者攻撃によるダウングレード攻撃（HTTPSからHTTPへの誘導）を防ぐことができます。preloadパラメータは、ブラウザのHSTSプリロードリストに登録されるための条件の一つです。

10.1 HTTPからHTTPSへのリダイレクト

多くの場合は、HTTP (80番ポート) へのアクセスを自動的にHTTPS (443番ポート) へリダイレクトさせたいはずです。これは、80番ポートで待ち受ける別のserverブロックを作成し、そこでリダイレクトを設定することで実現できます。

“`nginx

HTTP (80番ポート) 待ち受け用サーバーブロック

server {
listen 80;
server_name your_secure_domain.com www.your_secure_domain.com; # リダイレクトしたいドメイン名

# 全てのリクエストをHTTPSにリダイレクト
# $request_uri はクエリストリングを含む元のURI
return 301 https://$host$request_uri;

}

HTTPS (443番ポート) 待ち受け用サーバーブロック (上記のSSL設定を含むもの)

server {
listen 443 ssl;
server_name your_secure_domain.com www.your_secure_domain.com;

# ... 上記のSSL設定 ...
# ... その他の server, location 設定 ...

}
“`

この設定により、http://your_secure_domain.com/path?query へのアクセスは、ブラウザにhttps://your_secure_domain.com/path?query への301リダイレクトを指示します。

11. その他の便利な設定と機能

Nginxは他にも多くの便利な設定と機能を提供しています。

11.1 ログ設定 (詳細)

httpブロックのlog_formatと、http, server, locationブロックのaccess_logを使って、アクセスログの形式と出力先を詳細に制御できます。

“`nginx
http {
# カスタムログフォーマットの定義
log_format combined_timing ‘$remote_addr – $remote_user [$time_local] ‘
‘”$request” $status $body_bytes_sent ‘
‘”$http_referer” “$http_user_agent” ‘
‘$request_time $upstream_response_time’;
# $request_time: Nginxがリクエストを受け付けてからレスポンスをクライアントに送信し終えるまでの時間
# $upstream_response_time: Nginxがバックエンドサーバーにリクエストを送信してからレスポンスを受け取り終えるまでの時間 (プロキシの場合)

server {
    listen 80;
    server_name example.com;

    # このサーバーブロック全体のログ
    access_log /var/log/nginx/example.com-access.log combined_timing;
    error_log /var/log/nginx/example.com-error.log warn;

    location /static/ {
        # 静的ファイルはログを無効化
        access_log off;
        root /var/www/example.com/static;
    }

    location /api/ {
        # APIリクエストは別のログファイルに
        access_log /var/log/nginx/example.com-api.log combined_timing;
        proxy_pass http://backend_api;
    }
}

}
“`
ログフォーマットで利用できる変数には、上記以外にも多くの種類があります。詳細はNginxの公式ドキュメントを参照してください。

11.2 gzip圧縮

レスポンスコンテンツをgzip圧縮して送信することで、転送データ量を削減し、表示速度を向上させることができます。

nginx
http {
gzip on; # gzip圧縮を有効化
gzip_vary on; # Vary: Accept-Encoding ヘッダーを追加 (プロキシキャッシュなどの問題を防ぐ)
gzip_proxied any; # プロキシ経由のリクエストも圧縮 (httpヘッダーに応じて圧縮を制御)
gzip_comp_level 6; # 圧縮レベル (1-9, 高いほど圧縮率が高いがCPU消費も増える)
gzip_buffers 16 8k; # 圧縮用バッファの数とサイズ
# 圧縮対象のMIMEタイプを指定 (通常はテキストベースのコンテンツ)
gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;
# gzip_disable "MSIE [1-6]\."; # IE6以下の古いブラウザでは圧縮を無効化 (バグ対策)
}
これらの設定は通常httpブロック全体で有効にします。

11.3 バーチャルホストと設定ファイルの分割 (include)

複数のドメイン名で異なるWebサイトを運用する場合、nginx.confのhttpブロック内に複数のserverブロックを定義します。

“`nginx
http {
# … httpブロックの共通設定 …

# サイトAのサーバーブロック
server {
    listen 80;
    server_name site-a.com www.site-a.com;
    root /var/www/site-a/html;
    # ... site-a 固有の設定 ...
}

# サイトBのサーバーブロック
server {
    listen 80;
    server_name site-b.com www.site-b.com;
    root /var/www/site-b/html;
    # ... site-b 固有の設定 ...
}

}
``
設定ファイルが肥大化するのを防ぐため、多くの環境ではsites-available/sites-enabledディレクトリやconf.d`ディレクトリを利用して、サイトごとに設定ファイルを分割します。

例: /etc/nginx/conf.d/site-a.conf にサイトAの設定を記述し、nginx.confのhttpブロックでinclude /etc/nginx/conf.d/*.conf;のように読み込みます。

11.4 基本認証 (auth_basic)

特定のディレクトリやURIへのアクセスに、IDとパスワードによる基本認証をかけることができます。

nginx
server {
...
location /admin/ {
auth_basic "Restricted Area"; # 認証ダイアログに表示されるテキスト
auth_basic_user_file /etc/nginx/conf.d/.htpasswd; # ユーザー名とパスワードを記述したファイル
# ... その他の設定 ...
}
...
}
.htpasswdファイルは、htpasswdコマンド（Apacheユーティリティに含まれることが多い）を使って作成します。

“`bash

パスワードを暗号化して追加 (初めての場合は-cオプションでファイル作成)

htpasswd -c /etc/nginx/conf.d/.htpasswd username
“`

11.5 レート制限 (limit_req)

クライアントからのリクエストレート（単位時間あたりのリクエスト数）を制限し、DoS攻撃などからサーバーを保護したり、APIの利用を制限したりできます。

“`nginx
http {
# レート制限ゾーンの定義 (httpブロック内)
# limit_req_zone zone=: rate=;
limit_req_zone $binary_remote_addr zone=mylimit:10m rate=5r/s;
# $binary_remote_addr: クライアントIPアドレス (バイナリ形式) – ゾーンのキー
# zone=mylimit:10m: mylimit という名前で、10MBの共有メモリゾーンを作成
# rate=5r/s: 1秒あたり5リクエストに制限

server {
    ...
    location /api/ {
        # レート制限の適用 (locationブロック内)
        limit_req zone=mylimit burst=10 nodelay;
        # zone=mylimit: 適用するゾーン名
        # burst=10: 制限レートを超えて一時的に許可するリクエスト数 (バースト許容数)
        # nodelay: バースト許容数の範囲内であれば、遅延させずに即座に処理 (デフォルトは遅延)
        # delay: バースト許容数の範囲内のリクエストも制限レートに従って処理 (遅延させる)

        proxy_pass http://backend_api;
    }
    ...
}

}
``limit_req_zoneでゾーンを定義し、limit_reqでそれを適用します。burst`は一時的なトラフィック増加を許容する設定です。

11.6 アクセス制御 (allow, deny)

IPアドレスに基づいてアクセスを許可または拒否することができます。

“`nginx
location /admin/ {
allow 192.168.1.0/24; # 指定ネットワークからのアクセスを許可
allow 10.0.0.1; # 指定IPアドレスからのアクセスを許可
deny all; # その他全てのアクセスを拒否
# … その他の設定 …
}

location / {
deny 1.2.3.4; # 特定のIPアドレスからのアクセスを拒否
allow all; # その他全てのアクセスを許可 (deny all の逆)
# … その他の設定 …
}
``allowとdenyディレクティブは記述順に評価されます。最後に評価されたディレクティブが優先されます。ただし、allow all;がある場合は、それ以前のdeny`が優先されます。

12. Nginxの設定変更とリロード/再起動

Nginxの設定ファイルを変更した場合、その変更を反映させるためにはNginxを再起動またはリロードする必要があります。

12.1 設定ファイルの構文チェック (nginx -t)

設定ファイルを編集した後、サービスを再起動する前に必ず構文チェックを行いましょう。

bash
sudo nginx -t
または

bash
sudo /usr/sbin/nginx -t # Nginxの実行パスを指定する場合

設定に問題がなければ、以下のようなメッセージが表示されます。

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

エラーがある場合は、エラーが発生した設定ファイルの行数とエラー内容が表示されます。

12.2 設定のリロード (nginx -s reload)

構文チェックが成功したら、Nginxサービスをリロードします。リロードは、Nginxのマスタープロセスに設定ファイルを再読み込みするシグナルを送信します。新しい設定が適用されますが、既存のワーカープロセスは現在のリクエスト処理を完了させてから、新しい設定で起動された新しいワーカープロセスに切り替わります。これにより、サービスを中断することなく設定変更を適用できます（Graceful Reload）。

bash
sudo systemctl reload nginx # systemdを使用している場合 (推奨)
または

bash
sudo nginx -s reload # Nginxコマンドを使用

12.3 設定の再起動 (nginx -s restart)

再起動は、実行中のNginxプロセスを完全に停止し、新しいプロセスとして起動し直します。設定変更だけでなく、モジュールの追加やアップグレードなどでNginxバイナリ自体を変更した場合に必要です。リロードと異なり、一時的にサービスが中断する可能性があります。

bash
sudo systemctl restart nginx # systemdを使用している場合 (推奨)
または

bash
sudo nginx -s stop # 停止
sudo nginx # 起動

本番環境では、サービスの中断を最小限に抑えるため、可能な限りリロード（systemctl reload nginx）を使用するのが推奨されます。

12.4 Graceful Shutdown

Nginxはワーカープロセスが現在の接続を処理し終えてから終了する「Graceful Shutdown」をサポートしています。nginx -s quitコマンドやSIGQUITシグナルで終了させようとした場合にこの動作になります。nginx -s stopやSIGTERMシグナルはすぐに終了させようとします。systemctl stop nginxは通常SIGTERMを送信しますが、systemdの設定によってはGraceful Shutdownを行うように構成されている場合もあります。

13. トラブルシューティングのヒント

Nginxの設定で問題が発生した場合、以下の点を確認してみてください。

  • エラーログの確認: 最も重要な手がかりです。error_logディレクティブで指定したファイル（通常/var/log/nginx/error.log）を確認し、エラーメッセージを探します。
  • 構文チェックの実行: sudo nginx -tを実行して、設定ファイルに構文エラーがないか確認します。
  • ファイアウォール設定: Nginxが待ち受けるポート（通常80番、443番）がサーバーのファイアウォールで許可されているか確認します。
  • Nginxプロセスの状態確認: Nginxプロセスが正常に実行されているか確認します。sudo systemctl status nginxやps aux | grep nginxコマンドを使用します。
  • SELinux/AppArmor: SELinuxやAppArmorといったLinuxセキュリティ機構が有効になっている場合、Nginxが必要なファイル（Webコンテンツファイル、証明書、ログファイルなど）にアクセスするのをブロックしている可能性があります。これらのログ（/var/log/audit/audit.logなど）を確認するか、一時的に無効にしてテストしてみてください（本番環境では適切に設定してください）。
  • 権限問題: Nginxワーカープロセスを実行するユーザー（nginxやwww-dataなど）が、Webコンテンツディレクトリやログファイルディレクトリへの読み書き権限を持っているか確認します。
  • ネットワークの問題: バックエンドサーバーへのプロキシ設定の場合、Nginxサーバーからバックエンドサーバーへのネットワーク接続が可能か（ファイアウォール、ルーティングなど）確認します。telnetやcurlコマンドを使ってテストできます。
  • 他のサービスとのポート競合: Nginxが使用しようとしているポートを、別のサービス（Apacheなど）が既にListenしていないか確認します。sudo ss -tulnp | grep :80 のようなコマンドで確認できます。

これらの基本的なステップを踏むことで、多くの設定問題を解決できるはずです。

14. まとめ

本記事では、高性能Webサーバー/リバースプロキシとして広く利用されているNginxについて、そのユニークなアーキテクチャと、基本的な設定方法を詳細に解説しました。

Nginxのイベントドリブン型アーキテクチャが、なぜ多数の同時接続に強いのかを理解し、その設定の中心であるnginx.confファイルの主要なブロック（main, events, http, server, location）と、そこで使用される重要なディレクティブについて学びました。

具体的には、以下の設定例を通してNginxの能力を見てきました。

  • 静的ファイルサーバーとしての高速配信設定
  • リバースプロキシとしてのバックエンドへの転送とヘッダー設定
  • ロードバランサーとしての複数のバックエンドへのトラフィック分散とアルゴリズム
  • キャッシュサーバーとしてのコンテンツキャッシュによるパフォーマンス向上
  • SSL/TLSによるHTTPSサイトの構築とセキュリティ設定
  • その他の便利な機能（ログ、gzip、認証、レート制限、アクセス制御）

これらの基本的な設定と機能を理解することで、あなたはNginxを使って自身のWebサイトやアプリケーションを公開・運用するための強固な基盤を築くことができるでしょう。

Nginxには、ここで紹介した以外にも多くの機能や詳細な設定オプションがあります。例えば、HTTP/2、WebSocketプロキシ、GeoIPモジュール、Luaスクリプティング、さらにはNginx Plusで提供される商用機能（Active Health Check、高度なモニタリングなど）などです。

Nginxの設定は非常に柔軟ですが、同時に詳細な動作を理解しないと意図しない結果になることもあります。公式ドキュメントを参考にしたり、実際に小さな設定で試しながら学ぶことをお勧めします。

Nginxは現代のWebインフラストラクチャにおいて欠かせない存在です。この記事が、あなたがNginxの世界へ踏み出すための一助となれば幸いです。Nginxを活用して、より高速で、より堅牢なWebサービスを構築してください。

コメントする

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

上部へスクロール