【Nginx講座 第2回】設定ファイルの解剖学。nginx.confの構造とバーチャルホストの基本

その「コピペ設定」、本当に理解していますか？

こんにちは！「LINUX工房」管理人の「リナックス先生」です。
前回は、Nginxのアーキテクチャを学び、実際にインストールして「Welcome to nginx!」を表示させるところまで進みました。

しかし、ここからが本番です。
Webサーバーとして独自のWebサイトを公開したり、WordPressを動かしたりするためには、設定ファイルである nginx.conf を書き換えなければなりません。
ネット上の記事を見よう見まねでコピペして、「動いたからヨシ！」としていませんか？
その設定、実はセキュリティホールがあったり、無駄な処理をさせていたりするかもしれません。

本記事では、nginx.conf の全体構造から、主要なディレクティブの意味、躓きやすいLocationの優先順位、そして実践的なバーチャルホストの構築までを徹底解説します。

---

第1章：nginx.confの全体構造（コンテキスト）

Nginxの設定ファイルは、「コンテキスト（Context）」と呼ばれるブロック（{ ... }）の入れ子構造になっています。
まずはこの地図を頭に入れましょう。

# 1. Main Context (グローバル設定)
user  nginx;
worker_processes  auto;

events {
    # 2. Events Context (接続処理設定)
    worker_connections  1024;
}

http {
    # 3. HTTP Context (Webサーバー全体の設定)
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;

    server {
        # 4. Server Context (バーチャルホストの設定)
        listen       80;
        server_name  example.com;

        location / {
            # 5. Location Context (URLパスごとの設定)
            root   /usr/share/nginx/html;
            index  index.html index.htm;
        }
    }
}

各コンテキストの役割

コンテキスト	役割	主な設定項目
Main	ファイルの一番外側。Nginx全体に影響する設定。	実行ユーザー、プロセス数、PIDファイル
Events	接続処理（ネットワーク）に関する設定。	最大同時接続数(worker_connections)
HTTP	Webサーバー機能の共通設定。	MIMEタイプ、ログ形式、Gzip圧縮、KeepAlive
Server	仮想サーバー（ドメイン）ごとの設定。	ポート番号、ドメイン名、SSL証明書
Location	URLのパス（/blog, /imagesなど）ごとの挙動。	ドキュメントルート、リバースプロキシ、アクセス制限

「継承」のルールを理解せよ

Nginxの設定において最も重要なのが「設定の継承（Inheritance）」です。
親ブロック（例えば http ブロック）に書いた設定は、子ブロック（server や location）に自動的に引き継がれます。

例：アクセスログの設定

• http ブロックでログ出力を設定すると、全てのサイトでログが出ます。
• 特定の server ブロック内で別のログ設定を書くと、そのサイトだけは新しい設定で上書き（Override）されます。

「共通設定は親に書き、個別設定だけ子に書く」。これがNginxの設定を美しく保つコツです。

---

第2章：主要ディレクティブの意味

コンテキストの中に書く具体的な命令を「ディレクティブ（Directive）」と呼びます。
/etc/nginx/nginx.conf の上の方にある、基本かつ重要なディレクティブを見てみましょう。

1. user

user  nginx;

Nginxのワーカープロセスを実行するOSユーザーを指定します。
セキュリティ上、特権を持たない nginx ユーザーを指定するのが一般的です。

2. worker_processes

worker_processes  auto;

起動するワーカープロセスの数です。
auto に設定すると、Nginxが自動的にサーバーのCPUコア数と同じ数を設定してくれます。
2026年現在は、迷わず auto でOKです。

3. worker_connections

events {
    worker_connections  1024;
}

1つのワーカープロセスが同時に処理できる接続数です。
worker_processes × worker_connections が、サーバー全体でさばける理論上の最大同時接続数になります。
大規模サイトではこの数字を増やします（※OS側のファイルディスクリプタ上限設定も必要になります）。

4. include

include /etc/nginx/conf.d/*.conf;

外部の設定ファイルを読み込みます。
nginx.conf に全てを書くと数千行になり管理不能になるため、バーチャルホストごとの設定は conf.d ディレクトリに分割して保存し、ここで一括読み込みするのがプロの作法です。

---

第3章：バーチャルホスト（Server Block）の仕組み

1台のサーバー（1つのIPアドレス）で、「example.com」と「test.com」という2つの異なるWebサイトを表示させる仕組み。
これをApacheでは「バーチャルホスト」と呼びますが、Nginxでは「Server Block（サーバーブロック）」と呼びます。

仕組みは「Hostヘッダ」を見るだけ

ブラウザがサーバーにアクセスする際、HTTPリクエストヘッダの中に Host: example.com という情報を入れています。
Nginxはこれを見て、「あ、これは example.com 用の server ブロックを使えばいいんだな」と判断します。

設定ファイルの書き方

/etc/nginx/conf.d/ の中に、example.com.conf のようなファイルを作成し、以下のように記述します。

server {
    listen       80;
    server_name  example.com;  # ← ここが重要！

    location / {
        root   /var/www/example;
        index  index.html;
    }
}

この server_name と、リクエストのHostヘッダが一致したブロックが採用されます。

---

第4章：実践！2つのWebサイトを作ってみよう

理屈はここまでにして、実際に手を動かしてみましょう。
以下の2つのサイトを1台のNginxで動かしてみます。

• サイトA: site-a.local (ドキュメントルート: /var/www/site-a)
• サイトB: site-b.local (ドキュメントルート: /var/www/site-b)

ステップ1：ディレクトリとHTMLの作成

まず、Webページを置く場所を作ります。

# サイトA用
sudo mkdir -p /var/www/site-a
echo "<h1>This is Site A</h1>" | sudo tee /var/www/site-a/index.html

# サイトB用
sudo mkdir -p /var/www/site-b
echo "<h1>This is Site B</h1>" | sudo tee /var/www/site-b/index.html

ステップ2：設定ファイルの作成

/etc/nginx/conf.d/ にそれぞれの設定ファイルを作ります。

sudo vi /etc/nginx/conf.d/site-a.conf

server {
    listen       80;
    server_name  site-a.local;

    location / {
        root   /var/www/site-a;
        index  index.html;
    }
}

sudo vi /etc/nginx/conf.d/site-b.conf

server {
    listen       80;
    server_name  site-b.local;

    location / {
        root   /var/www/site-b;
        index  index.html;
    }
}

ステップ3：構文チェックとリロード

設定を書いたら、必ずテストを行います。

sudo nginx -t
# syntax is ok, test is successful と出ればOK

sudo systemctl reload nginx

ステップ4：動作確認（hostsファイルの活用）

まだドメインを取得していないので、あなたのPC（WindowsやMac）の hostsファイル を書き換えて、無理やりアクセスできるようにします。

Windowsの場合:
C:\Windows\System32\drivers\etc\hosts を管理者権限のメモ帳で開き、以下を追記します。

サーバーのIPアドレス  site-a.local
サーバーのIPアドレス  site-b.local

これでブラウザから http://site-a.local にアクセスしてみてください。
「This is Site A」と表示されれば成功です！ site-b.local も同様に確認しましょう。

---

第5章：Locationブロックのパズル（優先順位の罠）

Nginxの設定で最もハマりやすいのが、location のマッチング優先順位です。
「特定のアドレスだけ別の設定にしたい」という場合、書き方によって適用される順番が決まっています。

Locationの書き方4種

1. 完全一致 ( = ): location = /path
2. 前方一致 ( ^~ ): location ^~ /path (正規表現より優先)
3. 正規表現 ( ~ ): location ~ \.php$ (大文字小文字区別あり)
4. 前方一致 (修飾なし): location /path

優先順位の鉄則

以下の順序で評価され、最初にマッチしたものではなく、「最も優先度の高いルール」が採用されます。

よくある失敗例：

location /images/ {
    # 設定A
}

location ~ \.(jpg|png)$ {
    # 設定B
}

この状態で /images/photo.jpg にアクセスするとどうなるでしょうか？
1. /images/ (前方一致) にマッチします。
2. しかし、Nginxは「正規表現もチェックしなきゃ」と考えます。
3. ~ \.(jpg|png)$ (正規表現) にもマッチします。
4. 優先順位は「正規表現 ＞ 前方一致」なので、設定B が採用されます。

もし「/images/以下は絶対に設定Aを使いたい」なら、location ^~ /images/ と書く必要があります。

---

第6章：プロの運用管理術（設定ファイルの整理整頓）

サーバーを長く運用していると、設定ファイルは肥大化しがちです。
プロは最初から「散らからない工夫」をしています。

1. 共通設定の切り出し (include)

例えば「アクセス制限の設定」や「SSLの設定」など、複数のサイトで同じ設定を使う場合。
/etc/nginx/common/acl.conf のようなファイルを作り、そこに共通設定を書きます。

server {
    server_name site-a.local;
    include /etc/nginx/common/acl.conf;  # 読み込むだけ！
}

これで、変更があった時も1ファイルを直すだけで全サイトに反映されます。

2. 設定ファイルの無効化

サイトを一時的に停止したい場合、ファイルを削除するのは危険です。
ファイル名の末尾を .conf から .conf.disabled などに変更すれば、Nginxは読み込まなくなります。

sudo mv /etc/nginx/conf.d/site-b.conf /etc/nginx/conf.d/site-b.conf.disabled
sudo systemctl reload nginx

3. Gitでのバージョン管理

/etc/nginx/ ディレクトリ全体を Git で管理することを強くおすすめします。
「設定を変えたら起動しなくなった！」という時、git diff で変更点を確認したり、git checkout で元に戻したりできるのは、インフラエンジニアの命綱です。

---

まとめ：設定ファイルは怖くない

お疲れ様でした！
今回は、Nginxの心臓部である設定ファイルの構造と、バーチャルホストの構築、そしてLocationの優先順位について解説しました。

今回の重要ポイント：

• 設定は「Main > HTTP > Server > Location」の入れ子構造。
• server_name を使って、1台で複数のドメインを運用できる（バーチャルホスト）。
• Locationの優先順位は「完全一致(=) > 優先前方(^~) > 正規表現(~) > 前方一致」。
• include を活用して、設定ファイルを部品化・整理する。

これで、複数のWebサイトをホスティングする基盤が整いました。
しかし、今のままではサーバー上のファイルをそのまま表示しているだけです。
「特定のフォルダにはアクセスさせたくない」「画像ファイルが見つからない時は別のページを出したい」といった要望に応えるには、もう少し踏み込んだ設定が必要です。

次回、第3回は「静的コンテンツ配信の極意。root/aliasの使い分けとインデックス設定」です。
Webサーバーの基本機能であるファイル配信を極めます。
「rootとaliasの違い」というNginx最大の混乱ポイントをクリアにし、カスタムエラーページの作り方まで解説します。お楽しみに！