入門！Nginxの基礎と使い始め方

By /

はい、承知いたしました。「入門！Nginxの基礎と使い始め方」と題し、約5000語の詳細な解説記事を作成します。

入門！Nginxの基礎と使い始め方

Webサーバーは、インターネットの裏側で情報を届け続けるインフラの要です。数あるWebサーバーソフトウェアの中でも、近年特に注目を集め、多くの大規模サイトや高負荷な環境で採用されているのがNginx（エンジンエックス）です。

本記事では、これからNginxを学びたいという初心者の方に向けて、その基礎知識からインストール方法、基本的な使い方、さらにはリバースプロキシやロードバランサーといった応用的な機能までを、詳細かつ丁寧に解説します。約5000語にわたるこの解説を通じて、Nginxを理解し、自信を持って使い始められるようになることを目指します。

さあ、Nginxの世界へ第一歩を踏み出しましょう！

1. はじめに：Nginxとは何か、なぜ選ばれるのか

1.1. Nginxとは？

Nginxは、Igor Sysoev氏によって開発され、2004年に公開されたオープンソースのWebサーバーソフトウェアです。「エンジンエックス」と読みます。当初はロシアの検索エンジン「Rambler」の高負荷なサーバーを捌くために設計されました。その背景から、特に同時接続数が多い環境での高いパフォーマンスと安定性に強みを持っています。

Webサーバーとして広く使われていますが、それだけでなく、高機能なリバースプロキシ、ロードバランサー、HTTPキャッシュとしても機能します。また、最近ではメールプロキシ（IMAP/POP3/SMTP）や汎用的なTCP/UDPプロキシとしても利用できます。

1.2. なぜNginxを学ぶべきなのか？（Apache HTTP Serverとの比較）

Webサーバーの分野では、長い間Apache HTTP Server（通称Apache）がデファクトスタンダードでした。しかし、近年ではNginxが急速にシェアを拡大し、アクティブなウェブサイトにおいてはNginxがApacheを凌駕するほどの勢いを見せています（W3Techsなどの調査による）。なぜNginxがこれほどまでに普及したのでしょうか。

主な理由は、その高いパフォーマンスと効率性にあります。

  • アーキテクチャの違い：

    • Apache (従来のモード): 主にプロセスベースまたはスレッドベースのアーキテクチャを採用しています。リクエストごとにプロセスやスレッドを生成するため、同時接続数が増えるとメモリ消費が増大しやすく、コンテキストスイッチのオーバーヘッドも大きくなります。
    • Nginx: イベント駆動型（または非同期型）のアーキテクチャを採用しています。少数のワーカープロセスで、多数のコネクションを効率的に処理します。コネクションの確立やデータの送受信といったイベントを検知しながら、無駄なく処理を切り替えていくため、メモリ消費が少なく、同時接続数が多い環境でも高いパフォーマンスを維持できます。これは、特に「C10K問題」（1万を超える同時接続をいかに効率よく処理するかという問題）を解決するために有利なアーキテクチャと言えます。

  • 静的ファイルの配信性能： Nginxは静的ファイルの配信において、非常に高速で効率的です。これは、イベント駆動型アーキテクチャと、OSの持つ効率的なファイルIO機能（sendfileなど）を最大限に活用する設計によっているためです。大規模な静的コンテンツを配信するサイトや、静的ファイルを高速に処理したいリバースプロキシのフロントエンドとして非常に優れています。

  • リバースプロキシ・ロードバランサーとしての機能性： Nginxは、単なるWebサーバーとしてだけでなく、アプリケーションサーバー（PHP-FPM, Gunicorn, Tomcatなど）の前段に置いてリクエストを捌き、静的ファイル配信やSSL終端、キャッシュなどを担当するリバースプロキシとして広く利用されています。また、複数のバックエンドサーバーにリクエストを振り分けるロードバランサー機能も標準で備えており、これもNginxが選ばれる大きな理由です。

  • 設定のシンプルさ（側面）： Apacheの設定は.htaccessのような分散設定ファイルが便利である反面、全体像が把握しにくくなることがあります。Nginxの設定は基本的に一つのマスター設定ファイルとそのインクルードファイルに集約されるため、比較的シンプルで管理しやすいと感じるユーザーも多いです（もちろん、大規模な設定になると複雑にはなります）。

もちろん、Apacheにもmod_phpのような組み込み型でアプリケーションを実行できるといった利点や、歴史が長く情報が多いという利点もあります。しかし、現代のWebアプリケーション環境では、Nginxをリバースプロキシとして使用し、アプリケーションサーバーは別に用意するという構成が一般的になっており、この構成においてNginxは非常に優れたパフォーマンスを発揮します。

これらの理由から、特に高速性、拡張性、信頼性が求められるWebサイトやアプリケーションにおいて、Nginxは第一の選択肢となることが増えています。Nginxの基礎を学ぶことは、現代のWebエンジニアにとって非常に価値のあるスキルとなるでしょう。

1.3. この記事で学ぶこと

この記事では、以下の内容を順番に、できる限り詳細に解説していきます。

  • Nginxの基本的なアーキテクチャと設定ファイルの構造
  • Linux、macOS、WindowsにおけるNginxのインストール方法
  • 静的ファイルを配信するための基本的な設定方法
  • リクエストパスに応じて処理を振り分けるlocationブロックの詳細
  • Nginxをリバースプロキシとして利用する方法
  • 複数のサーバーに負荷を分散させるロードバランシングの設定
  • WebサイトをHTTPS化するためのSSL/TLS設定
  • その他、認証、アクセス制限、リライトなどの便利な機能
  • 基本的な運用管理とトラブルシューティングのヒント

この記事を読むことで、Nginxを自分の環境にインストールし、基本的なWebサイトを公開したり、既存のアプリケーションサーバーのフロントエンドとしてNginxを配置したりできるようになることを目指します。

2. Nginxの基礎知識

Nginxの設定や使い方を学ぶ前に、Nginxの基本的なアーキテクチャや設定ファイルの構成を理解しておくと、その後の学習がスムーズに進みます。

2.1. Nginxのアーキテクチャ：イベント駆動型とプロセスモデル

前述の通り、Nginxの最大の特徴の一つがそのイベント駆動型（非同期型）アーキテクチャです。これは、多数の同時接続を効率的に処理するために設計されています。

  • マスタープロセス (Master Process): Nginxが起動すると、まずマスタープロセスが一つ起動します。マスタープロセスの役割は、設定ファイルの読み込み、設定の検証、ワーカープロセスの管理（起動、停止、再起動、シグナル処理など）です。マスタープロセス自体は、ネットワークリクエストの処理は行いません。
  • ワーカープロセス (Worker Processes): マスタープロセスによって、設定された数のワーカープロセスが起動されます（通常、CPUコア数と同じくらいに設定されます）。これらのワーカープロセスが、実際のネットワークリクエスト（HTTPリクエストなど）を処理します。
    • イベント駆動型: 各ワーカープロセスは、複数のコネクションを同時に扱います。リクエストの受信、ファイルの読み込み、バックエンドサーバーとの通信といったI/O処理が発生しても、その完了を待つ間に他のコネクションの処理を進めます。I/O処理が完了したという「イベント」が発生したら、中断していた処理を再開します。このノンブロッキングな処理方式により、少数のプロセスで多数のコネクションを効率よく捌くことができます。
    • 共有メモリ: ワーカープロセス間では、共有メモリを通じて情報（設定、キャッシュ、セッション情報など）を共有することができます。これにより、プロセス間の連携が必要な機能（ロードバランシングのセッション維持など）を実現します。

このアーキテクチャにより、Nginxはメモリ使用量を抑えつつ、非常に高いスケーラビリティを発揮します。特に、Keep-Aliveコネクションのような長時間接続や、多数の静的ファイルを同時に配信するようなシナリオでその真価を発揮します。

2.2. 設定ファイルの構造とコンテキスト

Nginxの設定は、基本的に一つのメイン設定ファイル（通常は/etc/nginx/nginx.confや、インストールディレクトリ直下のconf/nginx.confなど）で行います。このファイルは、後述するような複数のコンテキストから構成され、それぞれのコンテキスト内にディレクティブと呼ばれる設定命令を記述します。

基本的な設定ファイルの構造例:

“`nginx

mainコンテキスト

ワーカープロセス数などの全体設定

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

events {
# eventsコンテキスト
# ネットワーク接続に関する設定
worker_connections 1024;
# use epoll; # Linuxの場合など
}

http {
# 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;

# サーバーブロックの定義 (serverコンテキスト)
server {
    listen 80; # 待ち受けポート
    server_name example.com www.example.com; # ドメイン名

    # locationブロックの定義 (locationコンテキスト)
    location / {
        root /usr/share/nginx/html; # ドキュメントルート
        index index.html index.htm; # デフォルトファイル
    }

    # 別のlocationブロックの例
    # location /images/ {
    #    root /data/images;
    # }

    # 別のサーバーブロックの例 (HTTPS)
    # server {
    #    listen 443 ssl;
    #    server_name example.com;
    #    ssl_certificate /etc/nginx/ssl/example.com.crt;
    #    ssl_certificate_key /etc/nginx/ssl/example.com.key;
    #    # ... その他のSSL設定
    #
    #    location / {
    #        # ...
    #    }
    # }
}

# 複数のserverブロックを定義可能
# server { ... }

}

mail { … } # メールプロキシ設定

stream { … } # TCP/UDPプロキシ設定

“`

各コンテキストの役割は以下の通りです。

  • main コンテキスト: 設定ファイルの最上位に位置し、Nginx全体に影響するグローバルな設定を行います。ワーカープロセス数 (worker_processes)、エラーログ (error_log)、PIDファイル (pid) など。
  • events コンテキスト: ネットワーク接続の処理方法に関する設定を行います。ワーカープロセスが同時に処理できるコネクション数 (worker_connections) や、使用するコネクション処理メソッド (use) など。mainコンテキスト直下に一つだけ記述できます。
  • http コンテキスト: HTTPサーバーとして動作する際の大域的な設定を行います。MIMEタイプの設定 (include mime.types)、デフォルトのコンテンツタイプ (default_type)、アクセスログのフォーマット (log_format) や出力先 (access_log)、静的ファイル配信の最適化 (sendfile)、Keep-Alive接続のタイムアウト (keepalive_timeout) など。mainコンテキスト直下に一つだけ記述できます。
  • server コンテキスト: 仮想ホスト（バーチャルホスト）の設定を行います。特定のIPアドレスやポート、ドメイン名に来たリクエストをどのように処理するかを定義します。httpコンテキスト内に複数記述できます。
  • location コンテキスト: 特定のリクエストURI（パスや正規表現）に対して、どのように処理を行うかを定義します。ドキュメントルート (root)、デフォルトファイル (index)、リバースプロキシ (proxy_pass)、FastCGI設定 (fastcgi_pass)、リライト (rewrite) など、URIに応じた詳細な処理を設定します。serverコンテキスト内や、他のlocationコンテキスト内に記述できます（ただし、ネストの仕方にはルールがあります）。

設定ファイルは基本的にディレクティブとコンテキスト（ブロック）で構成されます。ディレクティブは、設定項目とその値を指定する命令で、行末には必ずセミコロン ; を付けます。コンテキストは、{} で囲まれたブロックで、その内部に複数のディレクティブや子コンテキストを記述できます。設定は親コンテキストから子コンテキストへ継承されるものが多くありますが、ディレクティブによっては特定のコンテキストでのみ有効なものもあります。

実際の運用では、nginx.confにはhttpコンテキストまでの基本的な設定を記述し、個々の仮想ホスト（サイト）の設定は別のファイル（例えば/etc/nginx/sites-available/example.com）に記述し、nginx.confのhttpコンテキスト内から include /etc/nginx/sites-enabled/*; のような形で読み込むのが一般的なプラクティスです。これにより、設定ファイルが整理され、サイトごとの設定管理が容易になります。

2.3. 主なディレクティブと役割

Nginxには非常に多くのディレクティブがありますが、入門として知っておくべき主なものをいくつか紹介します。

  • listen: 待ち受けポート番号とオプション（IPアドレス、sslなど）を指定します。serverコンテキスト内で使用します。例: listen 80;, listen 127.0.0.1:8080;, listen 443 ssl;
  • server_name: このserverブロックがどのホスト名（ドメイン名）のリクエストに応答するかを指定します。複数のホスト名をスペース区切りで指定できます。serverコンテキスト内で使用します。例: server_name example.com www.example.com;, server_name *.example.com;
  • root: リクエストされたURIに対応するファイルを探す際の、ファイルシステムのルートディレクトリを指定します。http, server, location, if コンテキスト内で使用できます。例: root /usr/share/nginx/html;
  • index: ディレクトリがリクエストされた際に、どのファイルをデフォルトで表示するかを指定します。複数のファイル名をスペース区切りで指定でき、指定順に探します。http, server, location コンテキスト内で使用できます。例: index index.html index.htm index.php;
  • location: 特定のURIパターンにマッチするリクエストに対する処理を定義します。後述の「詳細な使い方（locationブロック）」で詳しく解説します。serverコンテキスト内で使用します。例: location /images/ { ... }
  • proxy_pass: リクエストを別のサーバー（アプリケーションサーバーなど）に転送（リバースプロキシ）します。location, if, limit_except コンテキスト内で使用できます。例: proxy_pass http://localhost:8000;
  • fastcgi_pass: リクエストをFastCGIプロトコルを話すサーバー（PHP-FPMなど）に転送します。location, if, limit_except コンテキスト内で使用できます。例: fastcgi_pass unix:/var/run/php-fpm.sock;
  • include: 別の設定ファイルを読み込みます。設定ファイルを分割して管理する際に便利です。多くのコンテキスト内で使用できます。例: include /etc/nginx/mime.types;, include sites-enabled/*;
  • access_log, error_log: アクセスログ、エラーログの出力先とレベルを指定します。main, http, server, location コンテキスト内で使用できます。例: access_log /var/log/nginx/access.log main;, error_log /var/log/nginx/error.log warn;
  • gzip: 応答をgzip圧縮するかどうかを指定します。静的ファイルの転送量を削減し、表示速度を向上させます。http, server, location, if コンテキスト内で使用できます。例: gzip on;

これらのディレクティブは、Nginxの設定を理解し、基本的な動作を制御するために不可欠です。

3. Nginxのインストール

Nginxのインストールは、使用しているOSによって方法が異なります。ここでは、主要なOSであるLinux (Debian/Ubuntu系, RHEL/CentOS系)、macOS、Windowsでの一般的なインストール方法を説明します。

3.1. Linuxへのインストール

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

Debian/Ubuntu系 (apt)

“`bash

パッケージリストを更新

sudo apt update

Nginxをインストール

sudo apt install nginx

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

サービスの状態を確認

sudo systemctl status nginx

もし起動していなければ、起動

sudo systemctl start nginx

システム起動時に自動実行しないようにする場合

sudo systemctl disable nginx

システム起動時に自動実行するように設定する場合

sudo systemctl enable nginx

“`

RHEL/CentOS/AlmaLinux/Rocky Linux系 (yum/dnf)

“`bash

パッケージリストを更新 (RHEL/CentOS 7まで)

sudo yum update

パッケージリストを更新 (CentOS 8+, RHEL 8+, AlmaLinux, Rocky Linux)

sudo dnf update

Nginxをインストール (CentOS 7)

sudo yum install epel-release # NginxはEPELリポジトリにある場合がある

sudo yum install nginx

Nginxをインストール (CentOS 8+, RHEL 8+, AlmaLinux, Rocky Linux)

NginxはAppStreamリポジトリにあるためEPELは不要な場合が多い

sudo dnf install nginx

インストール後、サービスを起動し、自動実行を設定

sudo systemctl start nginx
sudo systemctl enable nginx

サービスの状態を確認

sudo systemctl status nginx
“`

ファイアウォールの設定:
Linuxサーバーでファイアウォールが有効になっている場合、HTTP (80番ポート) および HTTPS (443番ポート) へのアクセスを許可する必要があります。

  • firewalld (RHEL/CentOS 7+, AlmaLinux, Rocky Linux):
    bash
    sudo firewall-cmd --permanent --add-service=http
    sudo firewall-cmd --permanent --add-service=https
    sudo firewall-cmd --reload
  • ufw (Ubuntu):
    bash
    sudo ufw allow 'Nginx HTTP' # または sudo ufw allow 80
    sudo ufw allow 'Nginx HTTPS' # または sudo ufw allow 443
    # sudo ufw allow 'Nginx Full' # HTTPとHTTPSの両方
    sudo ufw enable # UFWが有効になっていない場合
    sudo ufw status

3.2. macOSへのインストール

macOSでは、Homebrewパッケージマネージャーを使うのが最も簡単です。

“`bash

Homebrewがインストールされていない場合はインストール

/bin/bash -c “$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)”

Nginxをインストール

brew install nginx

インストールされたNginxの設定ファイルパスやrootディレクトリなどを確認

brew info nginx

Nginxを起動

brew services start nginx

Nginxを停止

brew services stop nginx

Nginxを再起動

brew services restart nginx

Nginxの設定ファイルは通常、/usr/local/etc/nginx/nginx.conf に配置されます。

ドキュメントルートは /usr/local/var/www になることが多いです（brew infoで確認してください）。

“`

3.3. Windowsへのインストール

Windows版Nginxは、バイナリファイルが公式サイトで提供されています。パッケージマネージャーは使用しません。

  1. 公式サイトからダウンロード:
    Nginxの公式サイト (nginx.org) のダウンロードページにアクセスし、Windows用の最新のStable versionまたはMainline versionのzipファイルをダウンロードします。
  2. ファイルを展開:
    ダウンロードしたzipファイルを、任意のディレクトリ（例: C:\nginx）に展開します。
  3. Nginxの実行:
    コマンドプロンプトまたはPowerShellを開き、Nginxを展開したディレクトリに移動します。
    cmd
    cd C:\nginx
    Nginxを起動します。
    cmd
    nginx
    または（Powershellの場合）
    powershell
    .\nginx.exe

  4. 停止/再読み込みなど:
    起動中のNginxプロセスにコマンドを送ることで制御します。
    “`cmd
    # 設定ファイルを再読み込み（変更を反映、ダウンタイムなし）
    nginx -s reload

    Graceful Shutdown（現在のリクエスト処理完了後に停止）

    nginx -s quit

    Fast Shutdown（すぐに停止）

    nginx -s stop

    設定ファイルの構文チェックのみ

    nginx -t
    “`
    Windows版Nginxはサービスのようには実行されません。コマンドプロンプトを閉じるとNginxも終了します。サービスとして実行したい場合は、別途ツール（NSSMなど）を利用する必要があります。

3.4. インストールの確認

どのOSでも、インストールが完了したら、Webブラウザを開いてhttp://localhost/またはサーバーのIPアドレスにアクセスしてみてください。Nginxのデフォルトのウェルカムページが表示されれば、インストールは成功です。

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

“`bash
nginx -v

または、より詳細な情報

nginx -V

“`

4. 基本的な使い方：静的ファイルの配信

Nginxの最も基本的で得意な役割の一つは、静的ファイル（HTML, CSS, JavaScript, 画像など）を高速に配信することです。ここでは、最小限の設定で静的ファイルを配信する方法を学びます。

4.1. デフォルト設定ファイルの確認

インストール直後のNginxは、デフォルトの設定ファイルに基づいて動作します。Linuxの場合、通常/etc/nginx/nginx.confとその配下のファイル群が使用されます。macOS (Homebrew) の場合は/usr/local/etc/nginx/nginx.conf、Windowsの場合は展開したディレクトリのconf/nginx.confです。

デフォルト設定では、通常80番ポートでリッスンし、/usr/share/nginx/html (Linux), /usr/local/var/www (macOS), 展開ディレクトリのhtml (Windows) などのディレクトリをドキュメントルートとして静的ファイルを配信するようになっています。

このデフォルト設定ファイルを直接編集することも可能ですが、特にLinux環境では、サイトごとに設定ファイルを分けて管理する方が一般的です。

4.2. サイトごとの設定管理 (sites-available/sites-enabled)

Debian/Ubuntu系のNginxパッケージでよく採用されている設定ファイルの管理方法です。

  • /etc/nginx/sites-available/: 有効/無効にかかわらず、すべてのサイト設定ファイルを置くディレクトリ。
  • /etc/nginx/sites-enabled/: 有効にしたいサイト設定ファイルへのシンボリックリンクを置くディレクトリ。

メイン設定ファイル /etc/nginx/nginx.conf の http コンテキスト内で、include /etc/nginx/sites-enabled/*; のような記述があり、このディレクトリ内のファイルを読み込むようになっています。

この方式のメリットは、サイトの有効/無効をシンボリックリンクの作成/削除で簡単に切り替えられることです。

4.3. 新しい設定ファイルの作成と有効化（Linuxの場合）

静的サイトmywebsite.localを配信するための設定ファイルを作成してみましょう。

  1. サイト設定ファイルの作成:
    /etc/nginx/sites-available/ディレクトリに新しいファイルを作成します。例えば、mywebsite.local.confという名前にします。
    bash
    sudo nano /etc/nginx/sites-available/mywebsite.local.conf
    ファイルの内容は以下のようにします。

    “`nginx

    serverコンテキスト開始

    server {
    # 待ち受けポート
    listen 80;

    # このサーバーブロックが応答するホスト名
server_name mywebsite.local www.mywebsite.local;

# リクエストURI '/' にマッチするlocationブロック
location / {
    # ドキュメントルート（静的ファイルを置く場所）
    root /var/www/mywebsite.local/html;

    # ディレクトリがリクエストされた場合のデフォルトファイル
    index index.html index.htm;

    # ファイルが存在しない場合の処理 (404 Not Foundを返す)
    try_files $uri $uri/ =404;
}

# 必要に応じて、他のlocationブロックなどをここに追加

    }
    “`

    • listen 80;: 80番ポートで待ち受けます。
    • server_name mywebsite.local www.mywebsite.local;: mywebsite.localまたはwww.mywebsite.localというホスト名でのリクエストをこのサーバーブロックで処理します。
    • location / { ... }: リクエストURIが/で始まるもの（つまり、すべてのリクエスト）に適用される設定です。
    • root /var/www/mywebsite.local/html;: ドキュメントルートを/var/www/mywebsite.local/htmlに設定します。ここにHTMLファイルや画像などを置きます。
    • index index.html index.htm;: ディレクトリへのリクエスト（例: http://mywebsite.local/）に対して、まずindex.htmlを探し、なければindex.htmを探して表示します。
    • try_files $uri $uri/ =404;: このディレクティブは非常に重要です。
      • まず $uri が示すファイルが存在するか試みます（例: /path/to/request が /var/www/mywebsite.local/html/path/to/request というファイルとして存在するか）。
      • もしファイルが存在しなければ、$uri/ が示すディレクトリに index ディレクティブで指定されたファイル（この場合は index.html または index.htm）が存在するか試みます（例: /path/to/request/ が /var/www/mywebsite.local/html/path/to/request/index.html として存在するか）。
      • どちらも見つからなければ、最後に =404 を実行し、404 Not Foundエラーを返します。
        このディレクティブは、パスと実際のファイルパスを紐付けたり、ファイルが見つからない場合の挙動を制御したりするのに非常に便利です。

  2. ドキュメントルートディレクトリの作成とテストファイルの配置:
    設定ファイルで指定したドキュメントルートディレクトリを作成し、テスト用のindex.htmlファイルを配置します。
    bash
    sudo mkdir -p /var/www/mywebsite.local/html
    echo "<h1>Hello from Nginx!</h1>" | sudo tee /var/www/mywebsite.local/html/index.html

  3. サイト設定の有効化:
    sites-availableにある設定ファイルへのシンボリックリンクをsites-enabledディレクトリに作成します。
    bash
    sudo ln -s /etc/nginx/sites-available/mywebsite.local.conf /etc/nginx/sites-enabled/
    デフォルトサイトの設定が有効になっている場合は、無効にしておくと競合を避けられます。
    bash
    # Ubuntu/Debianの場合
    # sudo unlink /etc/nginx/sites-enabled/default
    # CentOS/RHEL/AlmaLinux/Rocky Linuxの場合
    # デフォルト設定は /etc/nginx/nginx.conf 内に含まれていることが多いので、必要に応じてコメントアウトなどを検討

  4. Nginx設定のテスト:
    新しい設定ファイルが正しい構文であるか、エラーがないかを確認します。
    bash
    sudo nginx -t
    出力が syntax is ok と test is successful であれば問題ありません。エラーが表示された場合は、エラーメッセージをよく読んで設定ファイルを修正してください。

  5. Nginx設定のリロード:
    設定変更を反映させるには、Nginxをリロードまたは再起動する必要があります。設定テストが成功していれば、通常はリロードで十分です。リロードは、新しい設定を読み込み、古い設定で動いているワーカープロセスが現在のリクエストの処理を終えるのを待ってから新しいワーカープロセスに切り替えるため、ダウンタイムが発生しません。

    “`bash

    systemdを使用しているシステム (多くの最近のLinux)

    sudo systemctl reload nginx

    SysVinitを使用しているシステム (古いLinux)

    sudo service nginx reload

    “`

  6. アクセス確認:
    ブラウザからhttp://mywebsite.local/にアクセスします。ローカルPCでテストしている場合は、hostsファイルに127.0.0.1 mywebsite.local www.mywebsite.localといった行を追加して、mywebsite.localをローカルのNginxサーバーに向ける必要があります。サーバーにアクセスできる環境であれば、サーバーのIPアドレスでアクセスできます。

    「Hello from Nginx!」という見出しのページが表示されれば成功です。

4.4. Windows/macOSでの設定ファイルの編集

Windows版の場合、Nginxを展開したディレクトリのconf/nginx.confを直接編集するのが一般的です。macOS (Homebrew) の場合は/usr/local/etc/nginx/nginx.confを編集します。サイトごとにファイルを分ける場合は、例えばconf/sites/mywebsite.local.confのようなディレクトリを作成し、メインのnginx.confのhttpブロック内でinclude sites/*;のような記述を追加することで同様の構成を実現できます。

編集後は、Windowsの場合はnginx -s reloadコマンド、macOSの場合はbrew services reload nginx（またはbrew services restart nginx）コマンドで設定を反映させてください。設定テスト(nginx -t)も忘れずに行いましょう。

5. 詳細な使い方：locationブロック

locationブロックは、NginxがリクエストURIに基づいて処理を振り分けるための最も重要な要素です。パスの書き方によって、リクエストがどのlocationブロックにマッチするかが決まります。そのマッチングルールはいくつか種類があり、優先順位も存在します。

5.1. locationブロックのマッチングルール

locationディレクティブは、以下のような構文で記述します。

nginx
location [修飾子] パターン {
# このlocationブロックにマッチした場合の設定
...
}

修飾子の種類と、それに対応するパターンのマッチングルールは以下の通りです。

  1. プレフィックスマッチング（修飾子なし、または^~）

    • 修飾子なし: パターンで指定されたパスで始まるURIにマッチします。例: location /images/ { ... } は /images/photo.jpg や /images/thumbnails/ などにマッチします。最も一般的なマッチング方法です。複数のプレフィックスマッチングがある場合、最も長く一致するパスが優先されます。
    • ^~ 修飾子: パターンで指定されたパスで始まるURIにマッチします。これはプレフィックスマッチングですが、この修飾子が付いている場合、正規表現マッチングよりも優先されます。複数の^~マッチングがある場合も、最も長く一致するパスが優先されます。例: location ^~ /static/ { ... } は /static/ で始まるURIにマッチし、たとえ後述の正規表現locationが定義されていても、こちらが優先されます。

  2. 完全一致マッチング (= 修飾子)

    • = 修飾子: パターンで指定されたURIと完全に一致する場合のみマッチします。例: location = /login { ... } は /login というURIにのみマッチします。完全一致は最優先で評価されます。一致した場合、他のマッチングルールは評価されません。

  3. 正規表現マッチング (~ または ~* 修飾子)

    • ~ 修飾子: パターンで指定された正規表現に大文字小文字を区別してマッチします。例: location ~ \.(jpg|png|gif)$ { ... } は末尾が.jpg, .png, .gif のURIにマッチします（/images/photo.jpg にはマッチしますが、/images/Photo.JPG にはマッチしません）。
    • ~* 修飾子: パターンで指定された正規表現に大文字小文字を区別せずにマッチします。例: location ~* \.(jpg|png|gif)$ { ... } は末尾が.jpg, .png, .gif （大文字小文字問わず）のURIにマッチします。

  4. 名前付きlocation (@ 修飾子)

    • @ 修飾子: このlocationブロックは、直接リクエストURIをマッチングするのではなく、try_files や error_page ディレクティブなどから内部的にリダイレクトされたURIを処理するために使用されます。例: location @fallback { ... }

マッチングの優先順位:

リクエストURIが来たとき、Nginxは以下の順序でlocationブロックを評価し、最初に見つかったマッチング結果で処理を行います。

  1. 完全一致 (=): まず、すべての=付きlocationブロックを調べ、URIと完全に一致するものがあるか確認します。一致するものがあれば、そのブロックが使われ、他の評価は行われません。
  2. ^~ 付きプレフィックスマッチング: 次に、すべての^~付きプレフィックスマッチングlocationブロックを調べ、URIの先頭部分に一致するものの中で、最も長く一致するパスを持つものを探します。もし一致するものがあれば、そのブロックが使われ、正規表現マッチングは行われません。
  3. 正規表現 (~, ~*): ^~付きプレフィックスマッチングでマッチするものが見つからなかった場合、すべての正規表現locationブロックを記述された順序で評価します。最初にマッチした正規表現locationブロックが使われます。
  4. プレフィックスマッチング (修飾子なし): 正規表現locationブロックのどれにもマッチしなかった場合、すべての修飾子なしプレフィックスマッチングlocationブロックを調べ、URIの先頭部分に一致するものの中で、最も長く一致するパスを持つものを探します。そのブロックが使われます。

どのルールにもマッチしなかった場合、リクエストはデフォルトのサーバーブロック（最も最初に定義された、または特定のデフォルト指定がされたサーバーブロック）で定義された処理（通常はエラー）に進みます。

この優先順位、特に「最も長く一致するパスが優先される（プレフィックスマッチング）」と「正規表現は記述順、^~は正規表現より優先」という点を理解することが重要です。

例:

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

# 1. 完全一致 (最優先)
location = /login {
    # ログインページ専用の設定
}

# 2. ^~ プレフィックス (正規表現より優先)
location ^~ /static/ {
    root /data/static;
    # ここに静的ファイル配信の最適化設定など
}

# 3. 正規表現 (記述順)
location ~ \.(jpg|png|gif)$ {
    root /data/images;
    expires 30d; # 画像ファイルは30日間キャッシュ
}

location ~ \.php$ {
    # PHPファイルの処理 (例: FastCGIへ転送)
    fastcgi_pass unix:/var/run/php-fpm.sock;
    include fastcgi_params;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}

# 4. プレフィックス (最も長いものが優先、正規表現にマッチしなければ)
location / {
    # デフォルトの処理 (index.htmlを表示など)
    root /data/www;
    index index.html;
    try_files $uri $uri/ /index.html =404; # ファイルが見つからなければ /index.html を試し、それでもなければ404
}

}
“`

  • /login へのリクエスト: = /login にマッチ (1番)
  • /static/style.css へのリクエスト: ^~ /static/ にマッチ (2番)
  • /images/photo.jpg へのリクエスト: ~ \.(jpg|png|gif)$ にマッチ (3番、/static/ にはマッチしないので正規表現へ)
  • /script.php へのリクエスト: ~ \.php$ にマッチ (3番、.jpg|.png|.gif にはマッチしないので次の正規表現へ)
  • /about/ へのリクエスト: 上記のどれにもマッチしないため、location / にマッチ (4番)

5.2. locationブロック内での主なディレクティブ

locationブロック内では、そのパスへのリクエストに対する具体的な処理を定義します。よく使われるディレクティブには以下のようなものがあります。

  • root vs alias:

    • root パス;: rootディレクティブは、リクエストURIのパスをドキュメントルートのパスに結合して、ファイルシステムのパスを決定します。例: location /images/ { root /data; } の場合、/images/photo.jpg へのリクエストは /data/images/photo.jpg というファイルを読み込みます。
    • alias パス;: aliasディレクティブは、リクエストURIのパスのうち、locationパターンにマッチした部分を、指定されたパスに置き換えてファイルシステムのパスを決定します。例: location /images/ { alias /data/photos/; } の場合、/images/photo.jpg へのリクエストは /data/photos/photo.jpg というファイルを読み込みます。aliasを使う際は、通常、locationパターンがスラッシュ / で終わる場合、aliasのパスもスラッシュで終わらせる必要があります。location / {} の中でaliasを使うことはできません。

  • try_files:
    前述の通り、指定されたファイルパスやディレクトリパスを順番に試し、最初に見つかったものを内部的に処理します。最後に指定した引数は、どれも見つからなかった場合に返すレスポンス（エラーコードや名前付きlocationへのリダイレクトなど）を指定できます。非常に柔軟にファイル配信の挙動を制御できます。例: try_files $uri $uri/ /fallback.html =404;

  • proxy_pass:
    リクエストを指定されたURLまたはupstreamグループに転送します。Nginxをリバースプロキシとして使う際に使用します。後述の「リバースプロキシ」セクションで詳しく解説します。例: proxy_pass http://backend_servers;

  • fastcgi_pass:
    リクエストを指定されたFastCGIサーバーに転送します。PHP-FPMのようなFastCGIアプリケーションサーバーと連携する際に使用します。例: fastcgi_pass unix:/var/run/php-fpm.sock;

  • uwsgi_pass, scgi_pass, grpc_pass など:
    PythonのuWSGI、SCGI、gRPCなどのプロトコルに対応したアプリケーションサーバーへの転送に使用します。

  • return:
    指定したステータスコードをクライアントに返し、リクエストの処理を終了します。リダイレクト（3xxコード）やエラー（4xx, 5xxコード）を簡単に返すのに便利です。例: return 404;, return 301 https://$host$request_uri;

  • rewrite:
    リクエストURIを正規表現を使って書き換えます。複雑なURLの書き換えやリダイレクトに使用できますが、try_files や return で実現できる場合はそちらの方がシンプルでパフォーマンスが良いことが多いです。例: rewrite ^/old-path/(.*)$ /new-path/$1 permanent;

5.3. 静的ファイルの最適化設定

静的ファイルの配信はNginxが得意とするところですが、さらにパフォーマンスを向上させるための設定があります。

  • gzip圧縮:
    テキストベースの静的ファイル（HTML, CSS, JS, SVGなど）をgzip圧縮して転送量を削減します。

    nginx
    http {
    gzip on; # gzip圧縮を有効にする
    gzip_vary on; # Vary: Accept-Encoding ヘッダーを追加 (キャッシュ関連)
    gzip_proxied any; # プロキシ経由のリクエストでも圧縮する
    gzip_comp_level 6; # 圧縮レベル (1-9, 5-6が一般的)
    gzip_buffers 16 8k; # 圧縮バッファの設定
    gzip_http_version 1.1; # HTTP/1.1以降で圧縮する
    gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript image/svg+xml; # 圧縮するMIMEタイプを指定 (default: text/html)
    # gzip_disable "MSIE [1-6]\."; # 古いIEを除外する場合
    }
    これらの設定はhttp, server, location コンテキストで有効です。通常はhttpコンテキストで全体的に設定します。

  • ブラウザキャッシュ (expires/Cache-Control):
    ブラウザが静的ファイルを一定期間キャッシュするように指示することで、再訪問時の表示を高速化します。

    “`nginx
    server {
    # …

    location ~* \.(jpg|jpeg|png|gif|ico|css|js|svg)$ {
    expires 30d; # 30日間キャッシュ
    # または Cache-Control ヘッダーを直接指定
    # add_header Cache-Control "public, max-age=2592000"; # 30日 = 2592000秒
}

# HTMLファイルなどはキャッシュしないか、短期間のキャッシュに設定
location ~* \.(html|htm)$ {
    expires -1; # キャッシュしない
    # add_header Cache-Control "no-cache";
}

    }
    ``expiresディレクティブは、指定した期間に応じてExpiresヘッダーとCache-Controlヘッダーを自動的に設定してくれます。期間は秒 (s), 分 (m), 時間 (h), 日 (d), 週 (w), 年 (y) で指定できます。-1はキャッシュしない、epoch` は常に最新のバージョンをチェックさせます。

5.4. ログ設定

Nginxはアクセスログとエラーログを出力します。これらのログは、サイトへのアクセス状況の把握やトラブルシューティングに非常に役立ちます。

  • access_log:
    どのリクエストがNginxに届き、どのように処理されたかの情報を記録します。log_format ディレクティブでログの書式を定義できます。

    “`nginx
    http {
    # ログフォーマットの定義 (デフォルトのcombinedフォーマット)
    log_format combined ‘$remote_addr – $remote_user [$time_local] “$request” ‘
    ‘$status $body_bytes_sent “$http_referer” ‘
    ‘”$http_user_agent”‘;

    # アクセスログの出力先とフォーマットを指定
access_log /var/log/nginx/access.log combined;

server {
    # このサーバーブロックではログを出力しない場合
    # access_log off;
}

    }
    ``
    ログフォーマットの変数    $remote_addr(クライアントIP),$request(リクエスト行),$status(HTTPステータスコード),$body_bytes_sent` (レスポンスボディサイズ) など、多くの情報を含めることができます。

  • error_log:
    Nginxのエラー、警告、情報などを記録します。トラブルシューティングで最初に確認すべきログです。

    “`nginx

    mainコンテキスト または http, server, location

    error_log /var/log/nginx/error.log warn;
    ``
    ログレベルは    debug,info,notice,warn,error,crit,alert,emergが指定でき、指定したレベル以上のメッセージが記録されます。通常はwarnまたはerror` を使用します。

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

Nginxの最も一般的な使い方の一つが、リバースプロキシです。リバースプロキシとして機能させることで、アプリケーションサーバー（Node.js, Python/Django/Flask, Ruby/Rails, Java/Spring, PHP-FPMなど）の前に立ち、様々な役割を担わせることができます。

6.1. リバースプロキシとは？

クライアントからのリクエストを受け付け、それを内部の別のサーバー（バックエンドサーバー、アプリケーションサーバー）に転送し、バックエンドサーバーからの応答をクライアントに返すサーバーのことです。

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

  • 負荷分散: 複数のバックエンドサーバーにリクエストを振り分けることで、単一サーバーへの負荷集中を防ぎます（ロードバランシング）。
  • SSL終端: SSL/TLS証明書をリバースプロキシサーバーで集中管理し、クライアントとのSSL通信を担当させることができます。バックエンドサーバーはHTTPで通信すれば良くなるため、負荷が軽減されます。
  • 静的ファイル配信の高速化: アプリケーションサーバーではなく、高速なNginxで静的ファイルを配信することで、アプリケーションサーバーの負荷を減らし、応答速度を向上させます。
  • キャッシュ: バックエンドサーバーからの応答をキャッシュし、同じリクエストに対してはキャッシュから応答を返すことで、バックエンドへの負荷を軽減し、応答速度を向上させます。
  • セキュリティ: バックエンドサーバーを直接インターネットに公開せず、リバースプロキシを介することで、バックエンドサーバーを保護できます。WAF (Web Application Firewall) との連携なども容易になります。
  • シングルエントリーポイント: 複数のバックエンドサービスを、一つのドメイン名・ポートで公開できます。
  • メンテナンス性の向上: バックエンドサーバーのメンテナンス時でも、リバースプロキシ側でメンテナンス中であることを示すページを表示したり、他のサーバーにトラフィックを振り替えたりできます。

6.2. リバースプロキシの設定方法 (proxy_pass)

proxy_passディレクティブを使用して、リクエストを指定されたバックエンドサーバーに転送します。

“`nginx
server {
listen 80;
server_name myapp.local;

location / {
    # リクエストを http://localhost:8000 に転送
    proxy_pass http://localhost:8000;

    # 以下は一般的なプロキシヘッダーの設定例
    # クライアントのIPアドレスをバックエンドに伝える
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    # 元のホスト名をバックエンドに伝える
    proxy_set_header Host $host;
    # クライアントがHTTPSで接続しているかバックエンドに伝える (SSL終端している場合)
    proxy_set_header X-Forwarded-Proto $scheme;
}

# 静的ファイルはNginxで直接配信 (アプリケーションサーバーに負荷をかけない)
location /static/ {
    alias /path/to/your/application/static;
    expires 30d; # 静的ファイルはキャッシュ
    access_log off; # 静的ファイルのアクセスログは記録しないことも検討
}

# メディアファイルなどもNginxで直接配信
location /media/ {
    alias /path/to/your/application/media;
    expires 30d;
    access_log off;
}

}
“`

  • proxy_pass http://localhost:8000;: / へのリクエストを http://localhost:8000 で待ち受けているサーバー（例えばアプリケーションサーバー）に転送します。proxy_pass に指定するURLの末尾に / を付けるかどうかで挙動が変わる点に注意が必要です。

    • 末尾に / がある場合 (例: proxy_pass http://localhost:8000/;): LocationパターンにマッチしたURI部分を削除し、残りのパスを指定されたURLに付加して転送します。例えば、location /app/ { proxy_pass http://localhost:8000/; } の場合、/app/users/1 へのリクエストは http://localhost:8000/users/1 に転送されます。
    • 末尾に / がない場合 (例: proxy_pass http://localhost:8000;): LocationパターンにマッチしたURI部分を削除せず、locationパターンにマッチしたURI全体を指定されたURLに付加して転送します。例えば、location /app/ { proxy_pass http://localhost:8000; } の場合、/app/users/1 へのリクエストは http://localhost:8000/app/users/1 に転送されます。
    • Locationパターンが正規表現の場合: proxy_pass のURLにパスを付けない（例: proxy_pass http://localhost:8000;）と、マッチしたURI全体がバックエンドに渡されます。パスを付けたい場合は、rewriteディレクティブなどでURIを書き換えてからproxy_passを使用するか、名前付きlocationを活用する必要があります。

  • proxy_set_header ...: リクエストヘッダーを変更または追加してバックエンドサーバーに転送します。バックエンドサーバーがクライアントの元の情報（IPアドレス、ホスト名、プロトコルなど）を取得できるようにするために重要です。

    • X-Forwarded-For: クライアントの元のIPアドレスを伝えるための標準的なヘッダー。$proxy_add_x_forwarded_for 変数は、Nginxが受け取ったX-Forwarded-Forヘッダーに、接続元のIPアドレス（つまりNginxに接続してきたクライアントのIP）を追記します。これにより、複数のプロキシを経由した場合でも、元のクライアントIPを知ることができます。
    • Host: クライアントがリクエストした元のホスト名（ドメイン名）を伝えるヘッダー。バックエンドサーバーが仮想ホストを区別するのに使用されます。$host 変数は、リクエストヘッダーのHostフィールドの値、または存在しない場合はserver_nameの値になります。
    • X-Forwarded-Proto: クライアントがどのプロトコル（httpまたはhttps）でNginxに接続してきたかを伝えるヘッダー。NginxでSSL終端している場合に、バックエンドアプリケーションがHTTPSで接続されていると判断するために使用されます。$scheme 変数は、リクエストのスキーム（httpまたはhttps）になります。

6.3. タイムアウト設定

バックエンドサーバーへの接続や通信に時間がかかりすぎた場合、Nginxはデフォルトでエラーを返します。これらのタイムアウト時間は調整可能です。

“`nginx
location / {
proxy_pass http://localhost:8000;

# バックエンドへの接続タイムアウト (デフォルト 60秒)
proxy_connect_timeout 5s;

# バックエンドへのデータ送信タイムアウト (デフォルト 60秒)
proxy_send_timeout 5s;

# バックエンドからの応答読み込みタイムアウト (デフォルト 60秒)
proxy_read_timeout 5s;

}
“`

これらのタイムアウトを適切に設定することで、バックエンドの応答遅延がフロントエンドのユーザー体験に与える影響を制御できます。

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

Nginxは、リバースプロキシ機能を発展させて、複数のバックエンドサーバーにリクエストを分散させるロードバランサーとしても非常に優れています。

7.1. ロードバランシングとは？

ロードバランシングは、複数のサーバー（アプリケーションサーバー、データベースサーバーなど）にネットワークトラフィックを分散させる技術です。これにより、以下のメリットが得られます。

  • 高可用性 (High Availability): いずれかのサーバーがダウンしても、他のサーバーがリクエストを処理し続けるため、サービス全体の停止を防ぐことができます。
  • スケーラビリティ: アクセスが増加した場合でも、サーバー台数を増やすことで容易に処理能力を向上させることができます。
  • パフォーマンス向上: 複数のサーバーで負荷を分担することで、個々のリクエストの処理時間を短縮できます。

Nginxは、L7ロードバランサー（HTTPリクエストの内容を見て振り分ける）として機能します。

7.2. ロードバランシング設定 (upstreamブロック)

ロードバランシングを設定するには、まずhttpコンテキスト内にupstreamブロックを定義し、分散対象のバックエンドサーバーをリストアップします。次に、serverコンテキスト内のlocationブロックから、定義したupstreamグループにproxy_passでリクエストを転送します。

“`nginx
http {
# upstreamブロックの定義
upstream backend_servers {
# バックエンドサーバーのリスト
server 192.168.1.100:8000;
server 192.168.1.101:8000;
server 192.168.1.102:8000;

    # ロードバランシング方式 (デフォルトは round-robin)
    # round-robin;
    # least_conn; # コネクション数が最も少ないサーバーに振り分ける
    # ip_hash; # クライアントIPアドレスのハッシュ値で振り分ける (セッション維持に使える)
    # generic_hash key [consistent]; # 指定したキーのハッシュ値で振り分ける (Nginx Plus)
    # random [least_conn] [not_least_conn]; # ランダムに振り分ける (Nginx Plus)
    # random two [least_conn]; # 2台を選んでそのうちの1台に振り分ける (Nginx Plus)

    # ヘルスチェックなどのオプション
    # server 192.168.1.100:8000 weight=3; # 重みを付けて振り分け比率を変える
    # server 192.168.1.101:8000 down; # メンテナンスなどで一時的に無効にする
    # server 192.168.1.102:8000 max_fails=3 fail_timeout=30s; # 3回失敗したら30秒間無効にする
}

server {
    listen 80;
    server_name myapp.local;

    location / {
        # リクエストを backend_servers グループに転送
        proxy_pass http://backend_servers;

        # リバースプロキシのヘッダー設定なども同様に行う
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-Proto $scheme;

        # タイムアウト設定なども同様
        proxy_connect_timeout 5s;
        proxy_read_timeout 60s;
    }

    # 静的ファイルなどはNginxで直接配信
    location /static/ {
        # ...
    }
}

}
“`

  • upstream name { ... }: ロードバランシンググループを定義します。nameは任意の名前です。
  • server address [parameters];: upstreamブロック内に、バックエンドサーバーのアドレス（IPアドレスまたはホスト名とポート番号）を指定します。複数のserverディレクティブを記述することで、複数のバックエンドサーバーを指定できます。
  • ロードバランシング方式:
    • round-robin (デフォルト): リクエストを順番に各サーバーに均等に振り分ける方式です。設定ディレクティブは不要です。
    • least_conn: その時点でアクティブなコネクション数が最も少ないサーバーにリクエストを振り分ける方式です。サーバーのリソース利用率を考慮した分散に適しています。
    • ip_hash: クライアントのIPアドレスをハッシュ化し、そのハッシュ値に基づいて振り分けるサーバーを決定する方式です。同じクライアントからのリクエストは常に同じサーバーに送られます。これは、セッション情報をサーバー側に保持している場合などに便利です（セッション維持、Sticky Session）。ただし、特定のIPからのアクセスが集中すると、そのサーバーに負荷が偏る可能性があります。
    • その他、weight パラメータでサーバーごとの振り分け比率を変えたり、down, backup (他のサーバーが全てダウンした場合にのみ使用) などの状態を指定したりできます。

7.3. ヘルスチェック

Nginxは、バックエンドサーバーが正常に動作しているか（応答可能か）を定期的に確認し、応答しないサーバーへのリクエスト転送を自動的に停止するヘルスチェック機能を持っています。

オープンソース版のNginxには、パッシブヘルスチェックという基本的なヘルスチェック機能があります。これは、Nginxが実際にリクエストを転送した際の応答に基づいて、サーバーが正常か異常かを判断する機能です。

  • max_fails=number: 指定した期間内に、そのサーバーへのリクエストがnumber回失敗した場合、そのサーバーを異常と判断します。デフォルトは1回です。
  • fail_timeout=time: max_failsで指定した回数失敗した後、そのサーバーを異常と判断し、指定した期間（デフォルトは10秒）リクエストを転送しないようにします。この期間が経過すると、次のリクエスト時に再びサーバーをテストし、正常であればリストに戻します。

nginx
upstream backend_servers {
server 192.168.1.100:8000 max_fails=3 fail_timeout=30s; # 30秒間に3回失敗したら、次の30秒間は無効
server 192.168.1.101:8000 max_fails=5 fail_timeout=60s; # 60秒間に5回失敗したら、次の60秒間は無効
server 192.168.1.102:8000; # デフォルト (max_fails=1, fail_timeout=10s)
}

より高度なアクティブヘルスチェック（Nginxが定期的にバックエンドサーバーにヘルスチェック用のリクエストを送信して状態を確認する機能）は、商用版であるNginx Plusで提供されています。オープンソース版でアクティブヘルスチェックを行いたい場合は、別途サードパーティモジュール（例: nginx-module-healthcheck) を導入するか、Keepalivedなどの外部ツールと連携する必要があります。

8. SSL/TLSによるHTTPS化

Webサイトのセキュリティと信頼性を高めるために、HTTPSは不可欠です。Nginxは、SSL/TLS通信の終端（クライアントとの暗号化通信をNginxで行い、バックエンドとの通信はHTTPで行う）を行うことができます。

8.1. なぜHTTPSが必要か？

  • データの盗聴・改ざん防止: 通信内容が暗号化されるため、第三者によるデータの盗聴や改ざんを防ぎます。特にログイン情報や個人情報、クレジットカード情報などを扱うサイトでは必須です。
  • 信頼性の向上: SSL/TLS証明書により、アクセスしているサイトが本物であることを証明できます。
  • SEOへの影響: Googleなどの検索エンジンは、HTTPSサイトを高く評価する傾向があります。
  • モダンなWeb機能の利用: HTTP/2などの新しいプロトコルや、Service Workerのような一部のWeb APIは、HTTPS接続が必須です。

8.2. 証明書の取得方法

HTTPSを有効にするには、SSL/TLS証明書が必要です。証明書は認証局 (CA) から発行されます。

  • 商用証明書: DigiCert, Sectigo (Comodo), GeoTrustなどの商用認証局から購入します。組織の実在証明などが含まれる場合もあり、信頼性が高いですが費用がかかります。
  • 無料証明書 (Let’s Encrypt): Let’s Encryptは、無料でSSL/TLS証明書を発行してくれる認証局です。ドメインの所有権を確認するだけで自動的に証明書を発行・更新できるため、個人ブログから大規模サイトまで広く利用されています。有効期間は90日ですが、Certbotなどのクライアントツールを使えば自動更新が容易です。
  • 自己署名証明書: 自分で秘密鍵と証明書を作成する方法です。開発・テスト目的には使えますが、ブラウザに警告が表示されるため、本番環境では使用すべきではありません。

本番環境でNginxをHTTPS化する場合、Let’s Encryptが最も手軽で推奨される選択肢です。Certbotツールを使えば、証明書の取得からNginx設定の自動更新まで行ってくれます。

8.3. NginxでのSSL設定

取得した証明書ファイル（.crtまたは.pem形式）と秘密鍵ファイル（.key形式）を使用して、Nginxを設定します。

“`nginx
server {
# HTTPSの標準ポート443で待ち受ける
listen 443 ssl;
# HTTP/2を有効にする場合 (最近のNginxバージョンで ssl と同時に指定可能)
# listen 443 ssl http2;

server_name example.com www.example.com;

# SSL証明書ファイルへのパス
ssl_certificate /etc/nginx/ssl/example.com/fullchain.pem;
# 秘密鍵ファイルへのパス
ssl_certificate_key /etc/nginx/ssl/example.com/privkey.pem;

# 推奨されるSSL設定 (セキュリティと互換性のバランス)
ssl_protocols TLSv1.2 TLSv1.3; # 使用するTLSプロトコルのバージョン
ssl_ciphers 'TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384: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セッションのタイムアウト
ssl_session_tickets off; # セッションチケットを無効にする (セキュリティリスク回避)

# OCSP Stapling を有効にする (証明書の失効状態を高速に確認)
ssl_stapling on;
ssl_stapling_verify on;
resolver 8.8.8.8 8.8.4.4 valid=300s; # DNSリゾルバを指定
resolver_timeout 5s;

# HSTS (HTTP Strict Transport Security) ヘッダーを追加
# クライアントブラウザに、次回以降はこのドメインには必ずHTTPSでアクセスするように指示
# add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload";

location / {
    # 静的ファイル配信、リバースプロキシなど
    root /usr/share/nginx/html;
    index index.html;
    try_files $uri $uri/ =404;
}

}
“`

  • listen 443 ssl;: 443番ポートでSSL接続を受け付けます。http2 を追加することでHTTP/2も有効にできます（クライアントとサーバー双方が対応している場合）。
  • ssl_certificate, ssl_certificate_key: 証明書ファイルと秘密鍵ファイルへのパスを指定します。fullchain.pem は、Let’s Encryptなどで提供される、サイト証明書と中間証明書を連結したファイルです。
  • ssl_protocols, ssl_ciphers, ssl_prefer_server_ciphers: 使用するSSL/TLSプロトコルバージョンと暗号スイートを指定します。セキュリティと互換性のバランスを取りながら、弱い暗号化や古いプロトコルを無効にすることが重要です。Mozilla SSL Configuration Generatorなどのツールを参考に設定すると良いでしょう。
  • ssl_session_cache, ssl_session_timeout: SSLセッション情報をキャッシュすることで、再接続時のSSLハンドシェイクのオーバーヘッドを削減できます。
  • ssl_stapling: OCSP Staplingを有効にすることで、クライアントが別途OCSPリクエストを発行して証明書の有効性を確認する手間を省き、SSLハンドシェイクを高速化できます。
  • Strict-Transport-Security ヘッダー: HSTSは、一度HTTPSでアクセスしたドメインに対して、その後指定された期間（max-age）はHTTPでアクセスしようとしても強制的にHTTPSに切り替えるようブラウザに指示します。中間者攻撃（MIM攻撃）によってHTTP接続にダウングレードされるのを防ぐ効果があります。設定には注意が必要で、一度設定すると元に戻すのが難しい側面もあります。

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

多くのユーザーはURLを直接入力する際にhttp://を付けないため、デフォルトではHTTP (80番ポート) へのアクセスが発生します。これらのアクセスを自動的にHTTPS (443番ポート) にリダイレクトするのが一般的です。

これは、80番ポート用のserverブロックを別途作成し、そこから301リダイレクトを行うことで実現できます。

“`nginx

HTTP (80番ポート) 用のサーバーブロック

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

# どんなリクエストが来てもHTTPSにリダイレクト
return 301 https://$host$request_uri;

}

HTTPS (443番ポート) 用のサーバーブロック

server {
listen 443 ssl;
server_name example.com www.example.com;
# … SSL設定 …

location / {
    # ... 静的ファイル配信、リバースプロキシなど ...
}

}
``$host変数にはリクエストのホスト名（example.comまたはwww.example.com`）が、$request_uriにはリクエストパスとクエリストリングが含まれるため、元のURLを維持したままHTTPSにリダイレクトできます。

9. その他の便利な機能

Nginxは、これまでに説明した機能以外にも、様々な便利な機能を提供しています。

9.1. Basic認証

特定のディレクトリやファイルへのアクセスに、ユーザー名とパスワードによる認証をかけることができます。

  1. 認証情報ファイルの作成:
    認証情報を格納するファイルを作成します。ファイル形式はApacheの.htpasswd形式です。htpasswdコマンド（Apacheユーティリティの一部、または別途インストール）を使用して作成するのが一般的です。

    “`bash

    パスワードを暗号化してファイルを新規作成

    sudo htpasswd -c /etc/nginx/conf.d/.htpasswd username

    既存ファイルにユーザーを追加

    sudo htpasswd /etc/nginx/conf.d/.htpasswd anotheruser

    “`
    このコマンドを実行すると、指定したユーザー名のパスワード入力を求められ、暗号化されたパスワードがファイルに保存されます。ファイルのパーミッションはNginxが読み取れるように設定しますが、Webからアクセスできない場所に置くことが重要です。

  2. Nginx設定での認証指定:
    保護したいlocationブロックにauth_basicとauth_basic_user_fileディレクティブを追加します。

    “`nginx
    server {
    # …

    location /admin/ {
    # Basic認証を有効にする際のメッセージ
    auth_basic "Restricted Area";
    # 認証情報ファイルへのパス
    auth_basic_user_file /etc/nginx/conf.d/.htpasswd;

    # このディレクトリ以下の静的ファイルを配信
    root /var/www/mywebsite.local/admin;
    index index.html;
}

    }
    ``
    これで、    /admin/`以下のリソースにアクセスしようとすると、ブラウザにBasic認証のダイアログが表示されるようになります。

9.2. アクセス制限 (allow, deny)

特定のIPアドレスからのアクセスを許可または拒否することができます。

“`nginx
server {
# …

location /private/ {
    # 特定のIPアドレスからのアクセスのみ許可
    allow 192.168.1.100;
    allow 192.168.1.0/24; # サブネットからのアクセスも許可
    deny all; # 上記以外からのアクセスは全て拒否

    # このディレクトリ以下のコンテンツ
    root /var/www/private;
}

location / {
    # 全体には制限をかけない
    allow all;
}

}
``allowとdenyは記述順に評価され、最初に見つかったルールが適用されます。上記例では、192.168.1.100または192.168.1.0/24のIPアドレスからのアクセスは許可され、それ以外のIPアドレスからのアクセスは拒否されます。最後にdeny all;を記述することで、リストにない全てのIPアドレスを拒否できます。逆に、最後にallow all;を記述すれば、リストにない全てのIPアドレスを許可できます（リストにあるdeny`ルールが優先）。

9.3. リライトルール (rewrite)

正規表現を使ってリクエストURIを書き換える機能です。URLの構造変更や、古いURLから新しいURLへのリダイレクトなどに使用できます。

“`nginx
server {
# …

# 例: /old-path/ から /new-path/ にリダイレクト (恒久的リダイレクト)
rewrite ^/old-path/(.*)$ /new-path/$1 permanent;

# 例: /product/123 を /items.php?id=123 に内部的に書き換える
# rewrite ^/product/([0-9]+)$ /items.php?id=$1 last;

location / {
    # デフォルトの処理
}

location ~ \.php$ {
    # PHPの処理
    fastcgi_pass ...;
}

}
``rewriteディレクティブの構文はrewrite 変換前の正規表現 変換後の文字列 [フラグ];` です。

主なフラグ:
* last: 書き換え後のURIで、再度locationブロックのマッチングを行います。通常、内部的な書き換え（リクエストがNginxの外部に出ない）に使用されます。
* break: 書き換え後のURIで、現在のlocationブロック内の処理を継続しますが、それ以降のrewriteディレクティブの評価は停止します。静的ファイル配信など、特定のlocation内で処理を完結させたい場合に有用です。
* redirect: HTTPステータスコード302 (一時的なリダイレクト) をクライアントに返し、ブラウザに新しいURLへの再リクエストを促します。
* permanent: HTTPステータスコード301 (恒久的なリダイレクト) をクライアントに返し、ブラウザに新しいURLへの再リクエストを促します。

リライトは強力ですが、複雑になりやすいため、可能な限りtry_filesやreturnディレクティブで代替することを検討してください。

9.4. エラーページのカスタマイズ (error_page)

Nginxが返す各種エラー（404 Not Found, 500 Internal Server Errorなど）のページをカスタマイズできます。

“`nginx
server {
# …

# 404エラーが発生した場合、/404.html を返す
error_page 404 /404.html;

# 404.html が見つかった場合の内部的なlocation定義
location = /404.html {
    root /usr/share/nginx/html; # エラーページのドキュメントルート
    internal; # このlocationは内部リクエストからのみアクセス可能にする
}

# 500, 502, 503, 504エラーが発生した場合、/50x.html を返す
error_page 500 502 503 504 /50x.html;

# 50x.html の内部的なlocation定義
location = /50x.html {
    root /usr/share/nginx/html;
    internal;
}

# リクエストをアプリケーションサーバーにプロキシするが、エラー時はカスタムページを返す
# location /app/ {
#     proxy_pass http://localhost:8000;
#     error_page 500 502 503 504 /custom_error.html; # このlocation内で発生したエラーのみ適用
#     # ...
# }
# location = /custom_error.html {
#     root /usr/share/nginx/html;
#     internal;
# }

}
``error_page code … uri;の形式で指定します。uriには、エラー発生時に内部的にリダイレクトされるURIを指定します。このURIは、通常、internal;ディレクティブが設定されたlocationブロックで処理されるようにします。internal;` は、そのlocationへのアクセスをNginxの内部リクエストのみに制限し、外部からの直接アクセスを防ぎます。

10. Nginxの運用管理

Nginxを本番環境で運用する上で、ログの監視や基本的なトラブルシューティングは不可欠です。

10.1. ログの監視と解析

Nginxのアクセスログとエラーログは、サーバーの状況を把握するための重要な情報源です。

  • アクセスログ (access_log):

    • どのIPアドレスから
    • いつ
    • どのようなリクエスト（メソッド、URI、HTTPバージョン）で
    • どのステータスコードが返され
    • どれくらいのデータが転送されたか
      などが記録されます。
      これらのログを解析することで、アクセス数の推移、人気のあるページ、エラーの傾向などを把握できます。log_format をカスタマイズすることで、より詳細な情報を記録することも可能です（例: リクエスト処理時間 $request_time, リバースプロキシの場合のバックエンド応答時間 $upstream_response_time）。
      大規模なサイトではログ量が膨大になるため、ログローテーション (logrotateなどのツールを使用) の設定が必須です。また、Fluentd, Logstash, rsyslogなどのログ収集ツールと連携させ、ElasticsearchやSplunkなどの集中ログ管理システムで解析するのが一般的です。

  • エラーログ (error_log):

    • エラーが発生した日時
    • エラーのレベル（警告、エラー、致命的など）
    • エラーの原因（設定ファイルの構文エラー、ファイルの読み込み失敗、バックエンドサーバーとの通信エラーなど）
      などが記録されます。
      Nginxの起動失敗、設定リロードの失敗、リクエスト処理中の様々な問題の原因究明に不可欠です。特にerror以上のレベルのログは、即座に対応が必要な問題を示唆している可能性があります。

10.2. パフォーマンスチューニングのヒント

入門段階ではデフォルト設定でも十分なことが多いですが、高負荷環境ではチューニングを検討します。

  • worker_processes: 通常、CPUコア数と同じ値に設定するのが推奨されます。autoと設定すると、Nginxが自動的にコア数を検知して設定します。
  • worker_connections: 各ワーカープロセスが同時に処理できるコネクション数の最大値です。この値は、サーバーのリソース（特にファイルディスクリプタ数）によって制限されます。ulimit -nなどで現在の制限を確認し、必要に応じてOSレベルの設定も変更する必要があります。理論上の最大同時接続数は worker_processes * worker_connections です。
  • multi_accept on; (eventsコンテキスト): 新しいコネクションをワーカープロセスがまとめて受け付けるようにします。高負荷時に有用な場合があります。
  • use epoll; (eventsコンテキスト, Linux): 使用するコネクション処理メソッドを指定します。Linuxではepollが最も効率的です。他のOSではkqueue (BSD/macOS), devpoll (Solaris), select/poll などがあります。通常、NginxはOSに最適なものを自動選択するため、明示的な指定は不要なことが多いです。
  • sendfile on;: ファイル送信時に、ユーザーランドのバッファを経由せず、カーネル間で直接データをコピーすることで効率を向上させます。静的ファイル配信においてパフォーマンスを大きく向上させます。多くのシステムでデフォルトで有効になっています。
  • tcp_nopush on;: sendfile on; と併用することで、TCPパケットをまとめて送信し、ネットワーク効率を向上させます。
  • tcp_nodelay on;: TCPパケットの送信を遅延させず、すぐに送信します。これはインタラクティブな通信（例えばSSH）で応答性を向上させるための設定ですが、HTTPでも一般的に有効にされます。
  • keepalive_timeout: クライアントとのKeep-Alive接続を維持する時間を指定します。適切な値を設定することで、繰り返し接続するクライアント（ブラウザなど）のオーバーヘッドを削減できます。
  • open_file_cache: よくアクセスされる静的ファイルのファイルディスクリプタやメタデータをキャッシュすることで、ファイルアクセスのオーバーヘッドを削減します。

チューニングは、実際のワークロードやサーバー環境に合わせて行う必要があります。ツール（ab, wrk, JMeterなど）を使って負荷テストを行い、ボトルネックを特定しながら進めるのが効果的です。

10.3. トラブルシューティングの基本

Nginxで問題が発生した場合の基本的なトラブルシューティング手順です。

  1. エラーログを確認する:
    前述のerror_logファイルを確認します。Nginxの起動や設定リロードができない場合、特定のHTTPリクエストでエラーが発生する場合など、ほとんどの問題の原因がここに記録されています。エラーメッセージをよく読んで、原因（設定ファイルの記述ミス、ファイルのパーミッション不足、バックエンドサーバーとの通信問題など）を特定します。
  2. 設定ファイルの構文チェック:
    設定ファイルを変更した後は、必ずnginx -tコマンドで構文をチェックします。これにより、Nginxをリロード/再起動する前にエラーを検出できます。
  3. サービスの状態を確認する:
    Nginxプロセスが正常に起動しているか、予期せず停止していないかを確認します。systemctl status nginx (systemdの場合) や service nginx status (SysVinitの場合) コマンドを使用します。
  4. ネットワーク接続を確認する:
    curlやtelnetコマンドを使って、Nginxサーバーの待ち受けポート（通常80番、443番）に接続できるか確認します。ファイアウォール設定、サーバーのIPアドレス、ポート番号などが正しいか確認します。
    例: curl -I http://localhost/ (ヘッダー情報のみ取得), curl http://your_server_ip/
    バックエンドサーバーへのリバースプロキシを設定している場合は、Nginxサーバーからバックエンドサーバーへの接続も確認します。
    例: curl http://localhost:8000/ (Nginxサーバー内で実行)
  5. アクセスログを確認する:
    リクエストがNginxに届いているか、どのlocationブロックで処理され、どのステータスコードが返されているかなどをaccess_logで確認します。これにより、リクエストがNginxまで到達しているか、期待した処理がされているかなどを判断できます。
  6. ワーカープロセスの状態を確認する:
    ps aux | grep nginxなどでNginxのプロセス一覧を確認し、マスタープロセスとワーカープロセスが期待通りに起動しているか確認します。ワーカープロセスが大量にクラッシュしている場合などは、他のログやシステムの状態を確認します。
  7. リソース利用状況を確認する:
    CPU、メモリ、ディスクI/O、ネットワークなどのシステムリソース利用状況をtop, htop, vmstat, iostat, netstatなどのコマンドで確認します。特定のボトルネックがNginxのパフォーマンス問題やエラーの原因になっている場合があります。

11. まとめと次のステップ

この長い記事では、Nginxの基本的な概念から、インストール、静的ファイル配信、locationブロック、リバースプロキシ、ロードバランシング、HTTPS化、その他の便利な機能、そして基本的な運用管理とトラブルシューティングまで、Nginxを使い始めるために必要な多くの情報を網羅的に解説しました。

Nginxは、その高いパフォーマンスと柔軟性から、現代のWeb環境において非常に重要な役割を担っています。この記事を通じて、Nginxの基本的な仕組みと使い方を理解し、自分のプロジェクトや環境に導入する第一歩を踏み出せたなら幸いです。

Nginxの学習はここで終わりではありません。さらに深く学ぶための次のステップとして、以下の分野を探求することをお勧めします。

  • 詳細なディレクティブ: Nginxの公式サイトには、すべてのディレクティブに関する詳細なドキュメントがあります。必要に応じて個々のディレクティブのオプションや挙動を深く掘り下げてみてください。
  • Luaモジュール: NginxとLuaスクリプトを連携させることで、リクエスト処理中に複雑なロジックを実行したり、動的な設定を行ったりすることが可能になります。
  • Nginx Plus: 商用版のNginx Plusは、アクティブヘルスチェック、高度なロードバランシングアルゴリズム、ライブアクティビティ監視、Web Application Firewall (WAF) 連携などのエンタープライズレベルの機能を提供します。
  • コンテナ環境での利用: DockerやKubernetesといったコンテナ環境でNginxを利用するケースは非常に多いです。Nginxをコンテナ化する方法や、Kubernetes Ingress ControllerとしてのNginxなどについて学ぶのも良いでしょう。
  • パフォーマンスチューニングの深掘り: OSのカーネルパラメータ（ファイルディスクリプタ制限、TCPスタック設定など）、ネットワーク設定、ハードウェアの選択など、Nginxのパフォーマンスを最大限に引き出すための要素は多岐にわたります。
  • セキュリティ設定: DDoS対策、Rate Limiting、ModSecurityなどのWAFモジュールとの連携など、Nginxをより安全に運用するための設定について学びましょう。

Nginxは非常に多機能で奥深いソフトウェアです。実際に手を動かし、様々な設定を試しながら学ぶことが、習得への一番の近道です。この記事が、あなたのNginx学習の確かな土台となり、さらなる探求へのきっかけとなることを願っています。

Happy Nginx-ing!

注: 約5000語という指定のため、各セクションを可能な限り詳細に記述しましたが、Nginxの全機能を網羅することはできません。ここに記載されている内容は、入門者が必要とするであろう主要な機能と概念に焦点を当てています。実際の運用にあたっては、Nginx公式ドキュメントや信頼できるリソースを参照することを強く推奨します。また、設定例は一般的なものであり、特定の環境や要件に合わせて適宜修正が必要です。

文字数カウント: 約5000語を目指しましたが、執筆ツールでのカウント結果や内容の網羅性によって変動します。上記記事は、構成と内容の深掘りを意識して執筆しており、一般的なブログ記事の倍以上の情報量を持っています。正確な語数はツールによって異なりますが、おおよそ目標に近いボリュームになっているはずです。
上記が「入門！Nginxの基礎と使い始め方」の詳細な解説記事です。約5000語という要件を満たすため、Nginxの基礎からインストール、静的配信、locationブロック、リバースプロキシ、ロードバランシング、HTTPS化、その他の機能、運用管理までを網羅し、詳細な解説と設定例を盛り込みました。

この内容を直接利用して記事として公開することができます。

コメントする

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

上部へスクロール