Nginx server_name とは？設定方法と使い方を徹底解説

By /

Nginx server_name とは？設定方法と使い方を徹底解説

はじめに

現代のウェブサーバーにおいて、単一のサーバー上で複数のウェブサイトをホストすることは一般的です。例えば、example.com、blog.example.com、anothersite.orgといった異なるドメイン名を持つ複数のサイトを、1台の物理サーバーまたは仮想サーバー上で運用したい場合があります。このような「仮想ホスト」の概念を実現するために、Nginxのようなウェブサーバーソフトウェアは、受信したリクエストがどのドメイン名宛てであるかを識別し、それに対応する適切な設定を適用する必要があります。

Nginxにおいて、このドメイン名の識別と仮想ホストの切り替えを司るのが、server_nameディレクティブです。server_nameは、特定のserverブロックがどのようなドメイン名（またはIPアドレス）からのリクエストに応答するかを定義します。適切にserver_nameを設定することで、Nginxは大量のリクエストの中から特定のドメイン名に該当するものを正確に振り分け、設定されたコンテンツを提供したり、特定のリバースプロキシ設定を適用したりすることが可能になります。

この記事では、Nginxのserver_nameディレクティブについて、その基本的な役割から詳細なマッチングの仕組み、ワイルドカードや正規表現を使った高度な設定、そしてデフォルトサーバーの概念まで、網羅的に解説します。約5000語のボリュームで、初心者の方でも理解できるよう丁寧に、かつ実践的な設定例やトラブルシューティングを含めて深掘りしていきます。Nginxを使ったウェブサイト運用やアプリケーションのデプロイにおいて、server_nameは避けて通れない重要な要素です。この記事を通して、server_nameを完全にマスターし、あなたのNginx設定をより柔軟かつ効率的に構築できるようになることを目指します。

Nginxの仮想ホストとserver_nameの役割

Nginxは、設定ファイル（通常はnginx.confやそのインクルードファイル）に記述されたディレクティブに基づいて動作します。仮想ホストを実現するために、Nginxはserverブロックという単位で設定を管理します。各serverブロックは、特定のポートで待ち受けるリクエストに対して、どのように応答するかを定義します。

“`nginx
server {
listen 80; # このサーバーブロックが待ち受けるポート

server_name example.com www.example.com; # このサーバーブロックに対応するドメイン名

root /var/www/example.com/html; # ドキュメントルート

index index.html index.htm; # デフォルトで表示するファイル

location / {
    # リクエストのパスがルート('/')の場合の処理
    try_files $uri $uri/ =404;
}

# 他の設定...

}

server {
listen 80;

server_name anothersite.org;

root /var/www/anothersite.org/html;

index index.html;

location / {
    try_files $uri $uri/ =404;
}

# 他の設定...

}
“`

上記の例では、2つの異なるserverブロックがあります。それぞれのブロックは同じポート80で待ち受けていますが、server_nameディレクティブによって、どのドメイン名のリクエストを処理するかが区別されています。

  • 最初のserverブロックは、server_name example.com www.example.com; と定義されており、Hostヘッダーがexample.comまたはwww.example.comであるリクエストを処理します。
  • 2番目のserverブロックは、server_name anothersite.org; と定義されており、Hostヘッダーがanothersite.orgであるリクエストを処理します。

クライアント（ブラウザなど）がNginxにリクエストを送信する際、通常はHTTPヘッダーにHostフィールドを含めます。例えば、http://example.com/index.htmlにアクセスする場合、リクエストヘッダーにはHost: example.comが含まれます。Nginxは、受信したリクエストのHostヘッダーの値を見て、最も適切にマッチするserverブロックを探します。そして、マッチしたserverブロック内で定義されている設定（root、location、リライトルールなど）を適用して応答を返します。

したがって、server_nameディレクティブの主な役割は以下の通りです。

  1. 仮想ホストの識別: 特定のserverブロックがどのドメイン名に対応するかをNginxに伝える。
  2. リクエストのルーティング: 受信したリクエストのHostヘッダーに基づいて、適切なserverブロックを選択する基準となる。

この仕組みにより、単一のIPアドレスとポートで、複数の異なるドメイン名を持つウェブサイトを同時に運用することが可能になります。

server_nameの基本的な設定方法

server_nameディレクティブは、serverブロックのコンテキスト内で使用されます。基本的な構文は非常にシンプルです。

nginx
server_name name1 name2 ... namen;

ここで、name1, name2, … namenは、このserverブロックが応答するホスト名（ドメイン名やIPアドレス）を指定します。複数のホスト名を指定する場合は、スペースで区切ります。指定できるホスト名には、以下の種類があります。

  1. 正確なドメイン名: example.com のように、完全に一致するドメイン名。
  2. ワイルドカード名: *.example.com のように、一部がワイルドカードになっているドメイン名。
  3. 正規表現: ~^example\.com$ のように、正規表現パターンで定義されるホスト名。
  4. IPアドレス: 192.168.1.1 のように、IPアドレスそのもの。
  5. アンダースコア (_): 後述する特別な意味を持つ名前。

それぞれの設定方法を具体的に見ていきましょう。

1. 単一ドメインの指定

最も基本的な設定です。特定のドメイン名からのリクエストのみを処理する場合に使用します。

nginx
server {
listen 80;
server_name example.com; # このサーバーブロックは example.com のリクエストに応答する
# ... 他の設定
}

2. 複数ドメイン (エイリアス) の指定

一つのウェブサイトに複数のドメイン名でアクセスさせたい場合（例えば、example.comとwww.example.com）、複数の名前をスペース区切りで指定します。

nginx
server {
listen 80;
server_name example.com www.example.com; # example.com と www.example.com 両方に応答する
# ... 他の設定
}

この設定により、http://example.com/ と http://www.example.com/ のどちらでアクセスしても、同じserverブロックが処理を担当します。ただし、SEOの観点や統一性を保つために、どちらか一方に正規化（リダイレクト）することが一般的です。例えば、www.example.com へのアクセスを example.com にリダイレクトしたい場合は、以下のように2つのserverブロックを組み合わせます。

“`nginx

wwwありからwwwなしへのリダイレクトを行うサーバーブロック

server {
listen 80;
server_name www.example.com;
return 301 http://example.com$request_uri; # 301リダイレクトを返す
}

wwwなしの example.com を処理するサーバーブロック

server {
listen 80;
server_name example.com;
root /var/www/example.com/html;
index index.html;
location / {
try_files $uri $uri/ =404;
}
# … 他の設定
}
“`

3. IPアドレスの指定

ドメイン名ではなく、IPアドレスで直接サーバーにアクセスされた場合に特定の応答をしたい場合、IPアドレスをserver_nameとして指定できます。ただし、同じIPアドレスで複数の仮想ホストを運用している場合、IPアドレスでのアクセスは特定のserverブロックにしかマッチしないか、後述するデフォルトサーバーにマッチすることが多いです。

nginx
server {
listen 80;
server_name 192.168.1.1; # IPアドレスでのアクセスに応答
# ... 他の設定
}

通常、ウェブサイトへのアクセスはドメイン名を通じて行われるため、IPアドレスをserver_nameとして明示的に指定することは稀です。多くの場合は、ドメイン名に対するDNS解決によってIPアドレスが特定され、そのIPアドレス宛てにリクエストが送られ、そのリクエストに含まれるHostヘッダーのドメイン名に基づいてserver_nameがマッチングされます。IPアドレスのみでアクセスされた場合のマッチングについては、「デフォルトサーバー」のセクションで詳しく解説します。

server_nameのマッチングアルゴリズムと優先順位

Nginxがリクエストを受け取った際、どのserverブロックがそのリクエストを処理するのかを決定するために、server_nameとリクエストのHostヘッダー値を比較します。この比較には明確な優先順位とアルゴリズムが存在します。この仕組みを理解することは、意図した通りにリクエストが処理されるように設定するために非常に重要です。

Nginxは、受信したリクエストのHostヘッダーの値に対し、設定されている全てのserverブロックのserver_nameを以下の優先順位で照合していきます。

  1. 正確な名前 (Exact Name): Hostヘッダーの値と完全に一致するserver_nameが最優先されます。

    • 例: server_name example.com www.example.com; の設定がある場合、Host: example.com のリクエストはexample.com に、Host: www.example.com のリクエストはwww.example.com に正確にマッチします。

  2. 最も長い前方一致ワイルドカード名 (Longest Wildcard Name starting with an asterisk): *.example.com のように、アスタリスク (*) で始まるワイルドカード名の中で、リクエストのHostヘッダーに最も長くマッチするもの。

    • 例: server_name *.example.com; と server_name *.www.example.com; の設定がある場合、Host: mail.www.example.com のリクエストには *.www.example.com の方が長くマッチするため、こちらが優先されます。

  3. 最も長い後方一致ワイルドカード名 (Longest Wildcard Name ending with an asterisk): www.example.* のように、アスタリスク (*) で終わるワイルドカード名の中で、リクエストのHostヘッダーに最も長くマッチするもの。

    • 例: server_name www.example.*; と server_name www.example.co.*; の設定がある場合、Host: www.example.co.uk のリクエストには www.example.co.* の方が長くマッチするため、こちらが優先されます。

  4. 最初の正規表現 (First Regular Expression): 正規表現 (~ または ~*) で指定されたserver_nameの中で、設定ファイルに最初に記述されているものが優先されます。優先順位は「設定ファイルにおける出現順」です。

    • 例: server_name ~^sub\.example\.com$; と server_name ~^blog\.example\.com$; がこの順で記述されている場合、Host: sub.example.com のリクエストには最初の正規表現がマッチするため、それが使用されます。Host: blog.example.com のリクエストも2番目の正規表現にマッチしますが、Host: sub.example.com のリクエストが来た場合は最初の正規表現が優先されます（正規表現同士の比較ではなく、正規表現ブロック全体が正確一致やワイルドカードの後に評価され、その中で一番最初に定義された正規表現にマッチしたものを使用するという意味合いです）。

マッチングのプロセスは以下の順序で行われます:

  1. まず、Nginxは全てのserverブロックのserver_nameの中から、リクエストのHostヘッダーと正確に一致するものを探します。正確に一致するものが見つかれば、そのserverブロックが選択され、マッチングは終了します。
  2. 正確に一致するものが見つからなかった場合、Nginxは次にワイルドカード名を探します。前方一致ワイルドカード (*.example.com) と後方一致ワイルドカード (www.example.*) の両方が考慮されます。この際、「最も長くマッチする」ワイルドカード名が優先されます。ワイルドカードマッチが見つかれば、そのserverブロックが選択され、マッチングは終了します。
  3. ワイルドカードマッチも見つからなかった場合、Nginxは設定ファイルに記述されている順に正規表現のserver_nameを評価します。リクエストのHostヘッダーに最初にマッチした正規表現を持つserverブロックが選択され、マッチングは終了します。
  4. 上記全てにマッチしなかった場合、Nginxは最終手段として、そのIPアドレスとポートで待ち受けているデフォルトサーバーを選択します。デフォルトサーバーは、listenディレクティブにdefault_serverパラメータが付加されたserverブロックです。明示的にdefault_serverが指定されていない場合、Nginxは設定ファイルの先頭に記述されているserverブロックを暗黙的にデフォルトサーバーとして扱います。

重要なポイント:

  • 正確な名前が最も優先されます。ワイルドカードや正規表現よりも先に評価されます。
  • ワイルドカードは「最も長くマッチするもの」が優先されます。
  • 正規表現は他のどの種類にもマッチしなかった場合に評価され、設定ファイルで「最初に記述されたもの」が優先されます。正規表現同士の長さや複雑さは優先順位に関係しません。
  • どのserver_nameにもマッチしないリクエストは、そのlistenポートにおける「デフォルトサーバー」で処理されます。

この優先順位を理解しておくことで、複数のserverブロックが重複する可能性のある設定（例: *.example.com と www.example.com）を持つ場合に、どのserverブロックが優先されるかを予測できます。

server_nameの高度な使い方

基本的な設定に加えて、server_nameはワイルドカードや正規表現を使うことで、より柔軟なマッチングを実現できます。

ワイルドカード名の使用

ワイルドカード (*) は、名前の先頭 (*.example.com) または末尾 (www.example.*) に使用できます。これは、多数のサブドメインや異なるトップレベルドメインを持つサイトを効率的に設定する場合に便利です。

アスタリスクが先頭にある場合 (*.example.com)

これは、example.comの全てのサブドメインにマッチします。例えば、blog.example.com, shop.example.com, mail.example.comなどにマッチします。example.comそのもの（サブドメインなし）にはマッチしません。

nginx
server {
listen 80;
server_name *.example.com; # blog.example.com, shop.example.com などに応答
# ... サブドメイン共通の設定
}

*.example.com と example.com の両方に対応したい場合は、以下のように両方を記述する必要があります。

nginx
server {
listen 80;
server_name example.com *.example.com; # example.com とその全てのサブドメインに応答
# ... 設定
}

アスタリスクが末尾にある場合 (www.example.*)

これは、www.example.で始まるドメイン名の、後ろの部分が何であってもマッチします。例えば、www.example.com, www.example.org, www.example.co.ukなどにマッチします。

nginx
server {
listen 80;
server_name www.example.*; # www.example.com, www.example.org などに応答
# ... 設定
}

ワイルドカードは、正確な名前や正規表現に比べてシンプルでパフォーマンスも優れていますが、正規表現ほど柔軟ではありません。

正規表現によるマッチング

server_nameに正規表現を使用することで、非常に複雑なパターンマッチングが可能になります。正規表現を使用するには、名前の前にチルダ (~) またはアスタリスク付きチルダ (~*) を付けます。

  • ~: 大文字・小文字を区別してマッチングを行います。
  • ~*: 大文字・小文字を区別せずにマッチングを行います。

“`nginx
server {
listen 80;
server_name ~^(.+.)?example.com$; # example.com および全てのサブドメインに応答 (正規表現版)
# … 設定
}

server {
listen 80;
server_name ~*^www\d+.example.com$; # www1.example.com, www2.example.com などに応答 (大文字小文字区別なし)
# … 設定
}
“`

正規表現の強力な点の1つは、パターン内の括弧 () を使って部分文字列をキャプチャし、それを変数として利用できることです。キャプチャされた部分は、$1, $2, … のように変数に格納され、同じserverブロック内の他のディレクティブ（例: rewrite、root、proxy_passなど）で参照できます。

“`nginx
server {
listen 80;
server_name ~^(www.)?(?P.+).com$; # ドメイン名をキャプチャし、名前付きキャプチャも使用

root /var/www/$domain/html; # キャプチャしたドメイン名を変数として利用

location / {
    # ...
}

}
“`

上記の例では、server_nameは .com で終わる全てのドメイン名にマッチし、ドメイン名部分（www.は除く）を$2または名前付きキャプチャの$domainとしてキャプチャしています。そして、そのキャプチャした値を使ってrootディレクトリを動的に設定しています。これにより、多数のドメイン名に対して共通の設定を適用しつつ、ドキュメントルートをドメイン名ごとに分けるといったことが効率的に行えます。

正規表現使用時の注意点:

  • パフォーマンス: 正規表現のマッチングは、正確な名前やワイルドカード名に比べてCPU負荷が高くなる可能性があります。多数のリクエストを処理する高負荷な環境では、可能な限り正確な名前やワイルドカード名を使用し、正規表現の使用は最小限に抑えることが推奨されます。
  • 優先順位: 前述の通り、正規表現は正確な名前やワイルドカード名の後に評価され、さらに設定ファイルに最初に記述されているものが優先されます。意図しないserverブロックにマッチしないよう、正規表現を使用する場合は記述順序に注意が必要です。

特殊なserver_name: デフォルトサーバー (default_server)

これまで見てきたどのserver_nameにもマッチしないリクエストは、どのように処理されるのでしょうか？ Nginxはそのようなリクエストに対して、そのIPアドレスとポートで待ち受けているデフォルトサーバーを選択します。

デフォルトサーバーは、listenディレクティブにdefault_serverパラメータを付加することで明示的に指定できます。

“`nginx
server {
listen 80 default_server; # このサーバーブロックをデフォルトサーバーとして指定
server_name _; # またはここに実際のマッチしない名前などを指定することも多い

# ... デフォルトサーバーとして処理するための設定

}
“`

一つのlistenディレクティブ（つまり、同じIPアドレスとポートの組み合わせ）に対して、default_serverを指定できるserverブロックは1つだけです。もし複数のserverブロックにdefault_serverが指定されている場合、Nginxの起動時にエラーが発生します。

もし明示的にdefault_serverを指定しなかった場合、NginxはそのIPアドレスとポートで待ち受けているserverブロックのうち、設定ファイル内で一番最初に記述されているものを自動的にデフォルトサーバーとして扱います。

デフォルトサーバーが使用されるケース

デフォルトサーバーは主に以下のような場合に選択されます。

  1. Hostヘッダーがないリクエスト: 一部の旧式のクライアントや特定のツールからのリクエストでは、Hostヘッダーが含まれない場合があります。
  2. Hostヘッダーの値が、どのserver_nameにも正確に、ワイルドカードで、または正規表現でマッチしない場合。 これが最も一般的なケースです。
  3. IPアドレスで直接アクセスされた場合: http://192.168.1.1/ のようにIPアドレスを指定してアクセスされた場合、ブラウザは通常Host: 192.168.1.1 というヘッダーを送信します。もしserver_name 192.168.1.1; と記述されたserverブロックが他にない場合、デフォルトサーバーが選択されます。
  4. DNSの設定が誤っているか、まだ伝播していない場合: クライアントが間違ったIPアドレスに接続した場合や、DNSが正しく機能していない場合など、意図したドメイン名に対応するserverブロックに到達できないことがあります。

アンダースコア (_) をserver_nameに指定する意味

デフォルトサーバーの設定例で、server_name _; という記述を見かけることがあります。アンダースコア (_) は、それ自体が有効なドメイン名として登録されることはまずありません。したがって、これをserver_nameとして指定すると、実際にはほとんど任意のリクエストのHostヘッダーともマッチしません（一部の非常に特殊なケースや不正なリクエストを除く）。

server_name _; をデフォルトサーバーに設定することは、「正確な名前、ワイルドカード、正規表現のどれにもマッチしないリクエスト」を明確に処理するための慣習的な記述です。なぜなら、もしデフォルトサーバーに存在する可能性のあるドメイン名（例: server_name example.com;）を指定してしまうと、他のserverブロックでexample.comを設定していた場合に、マッチングの優先順位の関係で意図しない動作を引き起こす可能性があるからです。アンダースコアのように、絶対に存在しない名前を指定することで、そのserverブロックが他の名前付きサーバーにマッチしなかったリクエスト専用であることを明確に示せます。

デフォルトサーバーの推奨設定

デフォルトサーバーは、予期しないリクエストや悪意のあるスキャンなどを受信する可能性があります。そのため、デフォルトサーバーではウェブサイトのコンテンツを表示するのではなく、以下のような処理を行うことが推奨されます。

  • エラー応答: 444 (No Response), 400 (Bad Request), 403 (Forbidden) などのエラーを返す。特に444はNginx独自のコードで、クライアントへの応答を行わずにコネクションをクローズするため、リソースの消費を抑えられます。
  • 特定ページへのリダイレクト: 例えば、会社のコーポレートサイトや「このサーバーではサービスを提供していません」といった案内ページにリダイレクトする。

“`nginx

デフォルトサーバーとしてエラーを返す設定例 (ポート80)

server {
listen 80 default_server;
server_name _;

# Hostヘッダーにマッチしない、あるいは不正なリクエストに対して444を返す
return 444;

}

デフォルトサーバーとして特定ページにリダイレクトする設定例 (ポート80)

server {
listen 80 default_server;
server_name _;

# 会社サイトにリダイレクト
return 301 http://yourcompany.com;

}

SSL/TLS (ポート443) のデフォルトサーバーも同様に設定が必要

SSL/TLSのデフォルトサーバーについては、証明書の問題もあるため注意が必要

server {
listen 443 ssl default_server;
server_name _;

ssl_certificate /etc/nginx/ssl/default.crt; # ダミーまたは共通の証明書
ssl_certificate_key /etc/nginx/ssl/default.key; # ダミーまたは共通のキー

return 444; # または 400 (Bad Request) も適切

}
“`

sslパラメータ付きのlistenディレクティブに対するdefault_serverも同様に設定できます。ただし、SSL/TLSの場合、クライアントはHTTPS接続を確立しようとする前にサーバー証明書を受け取ります。デフォルトサーバーに設定された証明書がクライアントがアクセスしようとしたドメイン名と一致しない場合、ブラウザは証明書エラーを表示します。これを完全に回避することは難しいため、デフォルトのSSLサーバーでは、共通の証明書を使用するか、単に接続を閉じる（return 444）などの対応が取られます。

デフォルトサーバーを適切に設定することは、サーバーセキュリティの観点からも重要です。意図しないドメイン名でのアクセスに対してコンテンツを誤って公開したり、悪意のあるリクエストに不必要に応答したりするリスクを減らすことができます。

server_nameと他のNginx設定要素との連携

server_nameディレクティブは、serverブロック全体の設定の入り口となりますが、他の重要なディレクティブと組み合わせて使用されることで、仮想ホストとしての完全な機能を発揮します。

  • listenディレクティブ:
    listenディレクティブは、そのserverブロックがどのIPアドレスとポートでリクエストを待ち受けるかを指定します。server_nameによるマッチングは、まずクライアントが接続してきたIPアドレスとポートに対応するserverブロック群の中から行われます。例えば、ポート80 (listen 80;) で待ち受けるserverブロックと、ポート443 (listen 443 ssl;) で待ち受けるserverブロックがある場合、ポート80へのリクエストはポート80をlistenしているserverブロック群の中から、ポート443へのリクエストはポート443をlistenしているserverブロック群の中から、それぞれ独立してserver_nameによるマッチングが行われます。

  • rootディレクティブ:
    rootディレクティブは、そのserverブロック（またはlocationブロック）が静的ファイルを提供する場合のドキュメントルートを指定します。server_nameで特定のドメイン名にマッチしたリクエストに対して、どのディレクトリからファイルを提供するかをrootディレクティブで定義します。前述の例のように、正規表現のキャプチャ機能と組み合わせることで、ドメイン名に基づいて動的にrootを設定することも可能です。

  • locationディレクティブ:
    locationディレクティブは、リクエストURLのパス部分に基づいてさらに細かい処理を定義します。Nginxはまずserver_nameでserverブロックを特定し、次にそのserverブロック内のlocationディレクティブ群の中から、リクエストURLのパスに最も適切にマッチするものを選んで処理を続行します。server_nameが仮想ホスト全体を識別するのに対し、locationは仮想ホスト内の特定のURLパスに対する挙動を制御します。

  • SSL/TLS設定 (ssl_certificate, ssl_certificate_keyなど):
    HTTPS通信を行うserverブロックでは、SSL証明書と秘密鍵の設定が必要です。server_nameは、クライアントがアクセスしようとしているドメイン名をNginxに伝える役割を果たしますが、SSL/TLSハンドシェイクにおいては、サーバーが提示する証明書がそのドメイン名に対して有効である必要があります。ブラウザは、証明書のCommon Name (CN) またはSubject Alternative Names (SANs) フィールドに含まれるドメイン名と、実際にアクセスしようとしているドメイン名（Hostヘッダーの値）を比較して、証明書が信頼できるか判断します。したがって、HTTPS対応のserverブロックでは、server_nameに記述されたドメイン名が、対応するSSL証明書に含まれていることが必須です。SNI (Server Name Indication) の仕組みにより、単一のIPアドレスで複数のSSL証明書を持つ仮想ホストを運用することが可能ですが、これもクライアントがSSLハンドシェイク時に目的のドメイン名（server_nameと一致する値）をサーバーに通知することで実現されます。

  • includeディレクティブ:
    Nginxの設定ファイルが大規模になる場合、includeディレクティブを使って設定を複数のファイルに分割することが推奨されます。これにより、設定の管理が容易になり、例えば各仮想ホストの設定を個別のファイル (/etc/nginx/sites-available/example.com.confなど) に分けて管理できます。これらのファイル内でserverブロックとserver_nameを定義し、メインの設定ファイルからinclude /etc/nginx/sites-enabled/*; のように読み込むのが一般的な構成です。

具体的な設定例と解説

ここからは、いくつかの具体的なシナリオにおけるserver_nameの設定例とその解説を見ていきましょう。

例1: 単一ドメインの基本的なウェブサイト

“`nginx

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

server {
listen 80;
listen [::]:80; # IPv6でも待ち受ける場合
server_name example.com www.example.com;

root /var/www/example.com/html;
index index.html index.htm;

location / {
    try_files $uri $uri/ =404; # 静的ファイルがあればそれを返し、なければディレクトリとして試し、それでもなければ404を返す
}

# エラーページの設定 (オプション)
error_page 404 /404.html;
location = /404.html {
    internal; # Nginx内部からのリクエストのみ許可
}

# アクセスログとエラーログ
access_log /var/log/nginx/example.com.access.log;
error_log /var/log/nginx/example.com.error.log;

}
“`

解説:
この例では、example.comとwww.example.comの両方の名前でアクセスされたリクエストを処理するserverブロックです。listen 80; はIPv4のポート80、listen [::]:80; はIPv6のポート80で待ち受けます。rootでドキュメントルートを指定し、indexでデフォルトのファイル名を定義しています。location /ブロックは、ルートパス以下の全てのリクエストに対して、対応するファイルを探し、見つからなければ404エラーを返す設定です。

例2: WWWなしへの正規化リダイレクト

SEOやCanonicalization（正規化）のために、www.example.comへのアクセスをexample.comへリダイレクトしたい場合の設定です。

“`nginx

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

wwwあり -> wwwなし へのリダイレクト

server {
listen 80;
listen [::]:80;
server_name www.example.com; # リダイレクト元の名前

# 301 Moved Permanently ステータスコードでリダイレクト
# $scheme は http または https を、$host は www.example.com を含むHostヘッダーの値を示す
# $request_uri は /index.html?param=value のようなパスとクエリ文字列を含む
return 301 $scheme://example.com$request_uri;

}

wwwなし example.com を処理するメインのサーバーブロック

server {
listen 80;
listen [::]:80;
server_name example.com; # リダイレクト後の処理を行う名前

root /var/www/example.com/html;
index index.html index.htm;

location / {
    try_files $uri $uri/ =404;
}

# ... 他の設定 (ログ、SSLなど)

}
“`

解説:
この設定では、2つのserverブロックを使っています。最初のブロックはserver_name www.example.com; にマッチしたリクエストを捉え、return 301 ...; ディレクティブを使ってexample.comの同じパスに恒久的なリダイレクトを行います。$schemeや$request_uriといった組み込み変数を使うことで、柔軟なリダイレクトを実現できます。2番目のブロックはserver_name example.com; にマッチするリクエストを処理し、実際のコンテンツを配信します。

例3: 複数のサブドメインをワイルドカードで処理

blog.example.com, shop.example.comなど、example.comの全てのサブドメインをまとめて処理したい場合。

“`nginx

/etc/nginx/sites-available/subdomains.example.com.conf

server {
listen 80;
listen [::]:80;
server_name *.example.com; # example.com以外の全てのサブドメインにマッチ

# ドキュメントルートをサブドメイン名に応じて分ける例
# $host 変数には blog.example.com, shop.example.com などが入る
root /var/www/$host/html;
index index.html index.htm;

location / {
    try_files $uri $uri/ =404;
}

# ... 共通の設定

}

注意: example.com そのものはこのワイルドカードにはマッチしないため、

example.com を処理する別のserverブロックが必要になることが多い

server {
listen 80;
listen [::]:80;
server_name example.com;
# … example.com の設定
}
“`

解説:
server_name *.example.com; は、example.com以外の任意のサブドメインにマッチします。この例では、rootディレクティブに$host変数を使用しており、例えばblog.example.comへのアクセスであれば/var/www/blog.example.com/htmlをドキュメントルートとして使用します。これにより、各サブドメインのコンテンツを異なるディレクトリに配置しつつ、設定は一つのserverブロックで管理できます。ただし、example.comそのものはこのワイルドカードには含まれないため、別途設定が必要です。

例4: 正規表現を使った柔軟なマッチングとキャプチャ

より複雑なルールでドメイン名をマッチングしたり、マッチした部分を使って動的に設定を変更したりする場合。

“`nginx

/etc/nginx/sites-available/regex.example.com.conf

server {
listen 80;
listen [::]:80;
# TLD (.com, .org, .netなど) の違いを吸収しつつ、
# ホスト名部分 (www., blog. など) をキャプチャ
server_name ~^(www.)?(blog|shop|wiki).example.(com|org|net)$;

# キャプチャしたホスト名の一部 ($2) を使ってサブディレクトリを切り替える例
root /var/www/example.com/html/$2;
index index.html;

location / {
    try_files $uri $uri/ =404;
}

# ... 設定

}
“`

解説:
server_name ~^(www\.)?(blog|shop|wiki)\.example\.(com|org|net)$; は、www.blog.example.com, blog.example.org, shop.example.net, www.wiki.example.comなど、特定のパターンに一致する様々なドメイン名にマッチします。
正規表現中の () はキャプチャグループです。
* (www\.)?: www.があるかないかをキャプチャ ($1)
* (blog|shop|wiki): blog, shop, または wiki のいずれかをキャプチャ ($2)
* (com|org|net): com, org, または net のいずれかをキャプチャ ($3)
この例では、rootに$2（blog, shop, または wiki）を使用しており、例えばblog.example.comへのアクセスであれば/var/www/example.com/html/blogをドキュメントルートとします。このように、正規表現とキャプチャ変数を使うことで、非常に動的で柔軟な設定が可能になります。ただし、正規表現は前述の通りパフォーマンスと優先順位に注意が必要です。

例5: デフォルトサーバーの設定

どの名前付きserver_nameにもマッチしないリクエストや、IPアドレスでの直接アクセスを処理するためのデフォルトサーバー設定です。

“`nginx

/etc/nginx/sites-available/default.conf

server {
listen 80 default_server; # ポート80のデフォルトサーバー
listen [::]:80 default_server; # IPv6 ポート80のデフォルトサーバー

server_name _; # ほぼマッチしない名前を指定

# このサーバーブロックにマッチしたリクエストは全て444エラー (No Response) を返す
return 444;

# または、特定のエラーページやリダイレクトを設定することもできる
# root /var/www/default;
# index index.html;
# location / {
#    try_files $uri $uri/ =404;
# }
# error_page 404 /404.html;
# return 301 http://yourcompany.com;

}

ポート443 (HTTPS) のデフォルトサーバーも別途設定が必要

server {
listen 443 ssl default_server;
listen [::]:443 ssl default_server;

server_name _;

ssl_certificate /etc/nginx/ssl/default.crt; # ダミーまたは共通の証明書が必要
ssl_certificate_key /etc/nginx/ssl/default.key; # ダミーまたは共通のキーが必要

# SSLハンドシェイク後の不正なリクエストに対して444を返す
return 444;

}
“`

解説:
listenディレクティブにdefault_serverパラメータを付けることで、そのserverブロックがデフォルトサーバーとして機能します。server_name _; は、このブロックが名前によるマッチングを目的としないことを示します。ここでは、シンプルに444エラーを返す設定にしています。これは、意図しないアクセスに対してサーバーのリソースを消費せず、情報漏洩のリスクも最小限に抑えるための推奨設定の一つです。HTTPSのデフォルトサーバーも同様に設定しますが、SSL証明書が必要になる点が異なります。

例6: IPアドレスとポートのみでアクセスされる場合の考慮

もしNginxがリバースプロキシとして機能しており、バックエンドアプリケーションがホストヘッダーを見ない場合や、テスト目的でIPアドレス直打ちでアクセスすることがある場合、IPアドレスをserver_nameに含めることを検討することもあります。しかし、前述の通り、IPアドレスでアクセスされた場合は通常デフォルトサーバーにマッチします。特定のIPアドレスでのアクセスのみに応答する専用のserverブロックを設けることも技術的には可能ですが、これは一般的ではありません。

“`nginx

あまり一般的ではないが、IPアドレスでアクセスされた場合のみ応答する例

server {
listen 80;
server_name 192.168.1.100; # このサーバーのIPアドレス

root /var/www/default_ip_access;
index index.html;

location / {
    try_files $uri $uri/ =404;
}

}
“`

この設定は、Host: 192.168.1.100 というヘッダーを含むリクエスト（IPアドレス直打ちでアクセスした場合の一般的なHostヘッダー）に正確にマッチします。ただし、同じポート80で他のドメイン名を使った仮想ホストを設定している場合は、それぞれのserver_nameによるマッチングが優先され、どのserver_nameにもマッチしない場合に初めてデフォルトサーバーが使われるというserver_nameの優先順位を忘れないでください。IPアドレスでのアクセスも、名前によるマッチングが行われ、マッチしなければデフォルトサーバーに送られます。

例7: SSL設定とserver_name

HTTPS通信の場合、server_nameはSSL証明書と密接に関連します。

“`nginx

/etc/nginx/sites-available/example.com_ssl.conf

server {
listen 443 ssl;
listen [::]:443 ssl;
server_name example.com www.example.com;

# SSL/TLS 設定
ssl_certificate /etc/nginx/ssl/example.com.crt; # example.com と www.example.com が含まれる証明書
ssl_certificate_key /etc/nginx/ssl/example.com.key;
ssl_protocols TLSv1.2 TLSv1.3; # 推奨されるプロトコルバージョン
ssl_ciphers '...' # 推奨される暗号スイート
ssl_prefer_server_ciphers on;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;
ssl_session_tickets off;
ssl_stapling on;
ssl_stapling_verify on;
resolver 8.8.8.8 8.8.4.4 valid=300s;
resolver_timeout 5s;

# HTTPからHTTPSへのリダイレクト (オプション)
# listen 80;
# listen [::]:80;
# return 301 https://$host$request_uri;

root /var/www/example.com/html;
index index.html index.htm;

location / {
    try_files $uri $uri/ =404;
}

# ... 他の設定

}
“`

解説:
listen 443 ssl; でHTTPSポートを待ち受けます。server_name example.com www.example.com; で、これらのドメイン名へのHTTPSリクエストを処理することを指定します。重要なのは、ここで指定されたserver_nameのドメイン名が、ssl_certificateで指定された証明書のCNまたはSANsフィールドに含まれている必要があるという点です。証明書とserver_nameが一致しない場合、多くのブラウザは警告を表示するか、接続を拒否します。HTTP (ポート80) へのアクセスをHTTPS (ポート443) へ自動的にリダイレクトしたい場合は、コメントアウトされているHTTP用のserverブロックを追加します。

トラブルシューティング

server_nameの設定に関する一般的な問題と、その解決策について説明します。

期待するサイトが表示されない / 意図しないサイトが表示される

  • Hostヘッダーの確認: ブラウザの開発者ツールやcurl -H "Host: example.com" http://your_server_ip/ のようなコマンドを使って、クライアントが実際にどのようなHostヘッダーを送信しているかを確認してください。
  • Nginx設定ファイルの構文エラー: 設定ファイルを変更した後、sudo nginx -t コマンドで構文エラーがないかチェックしてください。エラーがあれば、Nginxは起動またはリロードに失敗します。
  • Nginxのリロード/再起動忘れ: 設定ファイルを変更した後は、必ずsudo nginx -s reload または sudo systemctl reload nginx で設定を反映させてください。再起動 (restart) はサービス全体を停止・起動するため、運用中のサーバーではreloadが推奨されます。
  • server_nameのマッチング優先順位の誤解: 前述の優先順位（正確 > ワイルドカード > 正規表現 > デフォルト）を再確認し、複数のserverブロックのserver_nameが重複していないか、特に正規表現の記述順が適切かを確認してください。
  • デフォルトサーバーへのマッチング: どのserver_nameにもマッチせず、意図せずデフォルトサーバーにリクエストが送られていないか確認してください。デフォルトサーバーの設定内容（例えば、エラーを返しているか、別のサイトにリダイレクトしているか）が、表示される結果と一致しないか確認してください。
  • DNS設定: クライアントが正しいIPアドレスに接続できているか確認してください。pingコマンドやdigコマンドでドメイン名が正しいサーバーIPアドレスに解決されるか確認できます。DNSの変更は伝播に時間がかかる場合があります。
  • ファイアウォール: サーバーのファイアウォール（例: ufw, firewalld, Iptables）やネットワーク上のファイアウォールが、特定のポートやIPアドレスからの接続をブロックしていないか確認してください。

設定変更が反映されない

  • 設定ファイルの場所: 編集しているファイルが、実際にNginxが読み込んでいる設定ファイルであることを確認してください。通常、メインのnginx.confがあり、そこからconf.d/* や sites-enabled/* のファイルをincludeしています。意図したファイルがincludeされているか確認してください。
  • Nginxユーザーのパーミッション: Nginxが設定ファイルを読み込むユーザー（通常はwww-dataやnginx）が、設定ファイルやインクルード先のファイルを読み込む権限を持っているか確認してください。
  • 設定のキャッシュ: ブラウザのキャッシュが古いコンテンツを表示している場合があります。スーパーリロード（Ctrl+Shift+R または Cmd+Shift+R）を試すか、別のブラウザやシークレットウィンドウでアクセスしてみてください。

どのserverブロックにマッチしているか確認したい

  • アクセスログ: 各serverブロックに専用のaccess_logを設定し、どのログファイルにリクエストが記録されているかを確認することで、どのserverブロックが処理を行ったかを特定できます。
  • デバッグログ: Nginxのデバッグログを有効にすると、リクエストがどのserverブロックとlocationブロックにマッチしたかを含む、詳細な処理プロセスを確認できます。ただし、デバッグログは非常に大量の情報を出力し、パフォーマンスに影響を与える可能性があるため、トラブルシューティング時以外は無効にしておくべきです。デバッグログの有効化方法はNginxのバージョンやビルドによって異なりますが、通常はコンパイルオプションやerror_logディレクティブで設定します。例: error_log /var/log/nginx/debug.log debug; (Nginxがデバッグモードでビルドされている必要があります)
  • HTTPヘッダーの追加: 一時的に、各serverブロックに特定のカスタムHTTPヘッダーを追加する設定を施し、ブラウザでそのヘッダーを確認することで、どのブロックが応答したかを特定できます。

“`nginx

特定のserverブロックに一時的に追加する例

server {
listen 80;
server_name example.com;
add_header X-Matched-Server “example.com”; # このヘッダーを追加
# … 他の設定
}

server {
listen 80;
server_name *.example.com;
add_header X-Matched-Server “wildcard_subdomain”; # このヘッダーを追加
# … 他の設定
}
``
ブラウザの開発者ツールで応答ヘッダーを確認し、X-Matched-Server`ヘッダーの値を見ることで、どのブロックが応答したか分かります。

まとめ

この記事では、Nginxのserver_nameディレクティブについて、その基本的な役割から応用的な使い方、マッチングの仕組み、そして関連する設定要素やトラブルシューティングまで、詳細に解説しました。

server_nameは、Nginxが仮想ホストを実現するための最も基本的なディレクティブの一つです。受信したリクエストのHostヘッダーに基づいて、どのserverブロックがそのリクエストを処理するかを決定する役割を担います。正確な名前、ワイルドカード名、正規表現といった複数の指定方法があり、それぞれに明確な優先順位が存在します。この優先順位を正しく理解することは、意図した通りにリクエストをルーティングするために不可欠です。

また、どのserver_nameにもマッチしないリクエストを処理する「デフォルトサーバー」の概念も非常に重要です。デフォルトサーバーを適切に設定することで、予期しないアクセスや悪意のあるリクエストに対して安全かつ効率的に対処できます。慣習的にserver_name _; を指定し、エラーを返す設定とすることが多いです。

server_nameは、listen、root、location、SSL設定など、他の多くのNginxディレクティブと連携して仮想ホストとしての機能を構築します。これらの要素がどのように組み合わさるかを理解することで、より複雑な要件にも対応できる柔軟なNginx設定を作成できます。

Nginxの設定においてserver_nameは非常に頻繁に登場し、その設定が全体の挙動に大きく影響します。この記事で解説した内容が、あなたのNginx設定の理解を深め、より堅牢で効率的なウェブサーバー環境を構築するための一助となれば幸いです。設定変更を行った際は、必ずnginx -tで構文チェックを行い、nginx -s reloadで設定を反映させることを忘れないようにしましょう。そして、もし問題が発生した場合は、マッチングの優先順位を再確認し、ログを丁寧に確認することが解決への近道となります。

コメントする

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

上部へスクロール