サーバ名

ワイルドカード名
正規表現名
その他の名
国際化された名
仮想サーバの選択
最適化
互換性

サーバ名は、server_name ディレクティブを使用して定義され、特定のリクエストにどのserver ブロックを使用するかを決定します。「nginxによるリクエスト処理方法」も参照してください。完全一致名、ワイルドカード名、または正規表現を使用して定義できます。

server {
    listen       80;
    server_name  example.org  www.example.org;
    ...
}

server {
    listen       80;
    server_name  *.example.org;
    ...
}

server {
    listen       80;
    server_name  mail.*;
    ...
}

server {
    listen       80;
    server_name  ~^(?<user>.+)\.example\.net$;
    ...
}

名前で仮想サーバを検索する場合、名前が指定された複数のバリアント（ワイルドカード名と正規表現の両方が一致するなど）と一致する場合、次の優先順位で最初に一致したバリアントが選択されます。

  1. 完全一致名
  2. アスタリスクで始まる最長のワイルドカード名（例：「*.example.org」）
  3. アスタリスクで終わる最長のワイルドカード名（例：「mail.*」）
  4. 最初に一致した正規表現（設定ファイルでの出現順）

ワイルドカード名

ワイルドカード名は、名前の先頭または末尾、およびドットの境界でのみアスタリスクを含めることができます。「www.*.example.org」や「w*.example.org」という名前は無効です。ただし、これらの名前は正規表現を使用して指定できます（例：「~^www\..+\.example\.org$」と「~^w.*\.example\.org$」）。アスタリスクは、複数の名前部分を一致させることができます。「*.example.org」という名前は、www.example.orgだけでなく、www.sub.example.orgにも一致します。

「.example.org」形式の特別なワイルドカード名は、完全一致名「example.org」とワイルドカード名「*.example.org」の両方に一致するために使用できます。

正規表現名

nginxで使用される正規表現は、Perlプログラミング言語（PCRE）で使用される正規表現と互換性があります。正規表現を使用するには、サーバ名はチルダ文字で始まる必要があります。

server_name  ~^www\d+\.example\.net$;

そうでない場合は、完全一致名として扱われます。または、式にアスタリスクが含まれている場合は、ワイルドカード名（そしてほとんどの場合、無効なワイルドカード名）として扱われます。「^」と「$」のアンカーを設定することを忘れないでください。構文上は必須ではありませんが、論理的には必要です。また、ドメイン名のドットはバックスラッシュでエスケープする必要があることにも注意してください。「{」と「}」を含む正規表現は引用符で囲む必要があります。

server_name  "~^(?<name>\w\d{1,3}+)\.example\.net$";

そうしないと、nginxの起動に失敗し、エラーメッセージが表示されます。

directive "server_name" is not terminated by ";" in ...

名前付き正規表現キャプチャは、後で変数として使用できます。

server {
    server_name   ~^(www\.)?(?<domain>.+)$;

    location / {
        root   /sites/$domain;
    }
}

PCREライブラリは、次の構文を使用して名前付きキャプチャをサポートしています。

?<name> Perl 5.10互換構文（PCRE-7.0以降でサポート）
?'name' Perl 5.10互換構文（PCRE-7.0以降でサポート）
?P<name> Python互換構文（PCRE-4.0以降でサポート）
nginxの起動に失敗し、エラーメッセージが表示された場合

pcre_compile() failed: unrecognized character after (?< in ...

これは、PCREライブラリが古く、「?P<name>」構文を試す必要があることを意味します。キャプチャは、数値形式でも使用できます。

server {
    server_name   ~^(www\.)?(.+)$;

    location / {
        root   /sites/$2;
    }
}

ただし、このような使い方は簡単な場合（上記のような場合）に限定する必要があります。数値参照は簡単に上書きされる可能性があるためです。

その他の名

特別に扱われるサーバ名がいくつかあります。

デフォルトでないserverブロックで「Host」ヘッダーフィールドのないリクエストを処理する必要がある場合、空の名前を指定する必要があります。

server {
    listen       80;
    server_name  example.org  www.example.org  "";
    ...
}

serverブロックにserver_nameが定義されていない場合、nginxは空の名前をサーバ名として使用します。

0.8.48までのnginxバージョンでは、この場合、マシンのホスト名がサーバ名として使用されていました。

サーバ名が「$hostname」（0.9.4）として定義されている場合、マシンのホスト名が使用されます。

サーバ名ではなくIPアドレスを使用してリクエストが行われた場合、「Host」リクエストヘッダーフィールドにはIPアドレスが含まれ、リクエストはIPアドレスをサーバ名として使用して処理できます。

server {
    listen       80;
    server_name  example.org
                 www.example.org
                 ""
                 192.168.1.1
                 ;
    ...
}

キャッチオールサーバの例では、「_」という奇妙な名前が見られます。

server {
    listen       80  default_server;
    server_name  _;
    return       444;
}

この名前には特別な意味はなく、単に無数の無効なドメイン名の1つであり、実際のどの名前とも交差することはありません。「--」や「!@#」などの他の無効な名前も同様に使用できます。

0.6.25までのnginxバージョンは、誤ってキャッチオール名として解釈された特別な名前「*」をサポートしていました。キャッチオールサーバ名またはワイルドカードサーバ名として機能したことはありません。代わりに、現在server_name_in_redirectディレクティブによって提供されている機能を提供していました。特別な名前「*」は現在非推奨となっており、server_name_in_redirectディレクティブを使用する必要があります。server_nameディレクティブを使用して、キャッチオール名またはデフォルトサーバを指定する方法はないことに注意してください。これはlistenディレクティブのプロパティであり、server_nameディレクティブのプロパティではありません。「nginxによるリクエスト処理方法」も参照してください。ポート*:80と*:8080をリッスンするサーバを定義し、一方をポート*:8080のデフォルトサーバに、もう一方をポート*:80のデフォルトサーバにすることができます。

server {
    listen       80;
    listen       8080  default_server;
    server_name  example.net;
    ...
}

server {
    listen       80  default_server;
    listen       8080;
    server_name  example.org;
    ...
}

国際化された名

国際化ドメイン名（IDN）は、server_nameディレクティブでASCII（Punycode）表記を使用して指定する必要があります。

server {
    listen       80;
    server_name  xn--e1afmkfd.xn--80akhbyknj4f;  # пример.испытание
    ...
}

仮想サーバの選択

まず、デフォルトサーバコンテキストで接続が作成されます。次に、サーバ名は、次のリクエスト処理段階で決定できます。各段階は、サーバ設定の選択に関与しています。

これらの各段階で、異なるサーバ設定を適用できます。そのため、特定のディレクティブは注意して指定する必要があります。

最適化

完全一致名、アスタリスクで始まるワイルドカード名、アスタリスクで終わるワイルドカード名は、リッスンポートにバインドされた3つのハッシュテーブルに格納されます。ハッシュテーブルのサイズは設定フェーズで最適化されるため、名前をCPUキャッシュミスが最小限で検索できます。ハッシュテーブルの設定の詳細については、別のドキュメントを参照してください。

最初に完全一致名のハッシュテーブルが検索されます。名前が見つからない場合は、アスタリスクで始まるワイルドカード名のハッシュテーブルが検索されます。そこで名前が見つからない場合は、アスタリスクで終わるワイルドカード名のハッシュテーブルが検索されます。

ワイルドカード名のハッシュテーブルの検索は、名前がドメイン部分ごとに検索されるため、完全一致名のハッシュテーブルの検索よりも遅くなります。「.example.org」という特別なワイルドカード形式は、完全一致名のハッシュテーブルではなく、ワイルドカード名のハッシュテーブルに格納されていることに注意してください。

正規表現は順次テストされるため、最も遅い方法であり、スケーラブルではありません。

これらの理由から、可能であれば完全一致名を使用する方が良いでしょう。たとえば、サーバの最も頻繁に要求される名前がexample.orgとwww.example.orgの場合、明示的に定義する方が効率的です。

server {
    listen       80;
    server_name  example.org  www.example.org  *.example.org;
    ...
}

簡略化された形式を使用するよりも

server {
    listen       80;
    server_name  .example.org;
    ...
}

多数のサーバ名が定義されている場合、または異常に長いサーバ名が定義されている場合、httpレベルでserver_names_hash_max_sizeおよびserver_names_hash_bucket_sizeディレクティブを調整する必要がある場合があります。server_names_hash_bucket_sizeディレクティブのデフォルト値は、CPUキャッシュラインサイズに応じて、32または64、または別の値になる場合があります。デフォルト値が32で、サーバ名が「too.long.server.name.example.org」として定義されている場合、nginxは起動に失敗し、エラーメッセージが表示されます。

could not build the server_names_hash,
you should increase server_names_hash_bucket_size: 32

この場合、ディレクティブの値を次の2の累乗に増やす必要があります。

http {
    server_names_hash_bucket_size  64;
    ...

多数のサーバ名が定義されている場合、別のエラーメッセージが表示されます。

could not build the server_names_hash,
you should increase either server_names_hash_max_size: 512
or server_names_hash_bucket_size: 32

そのような場合は、まずserver_names_hash_max_sizeをサーバ名の数に近い数値に設定してみてください。それでも効果がない場合、またはnginxの起動時間が許容できないほど長い場合にのみ、server_names_hash_bucket_sizeを増やしてみてください。

サーバがリッスンポートの唯一のサーバである場合、nginxはサーバ名をまったくテストしません（そして、リッスンポートのハッシュテーブルを作成しません）。ただし、例外が1つあります。サーバ名がキャプチャを含む正規表現の場合、nginxはキャプチャを取得するために式を実行する必要があります。

互換性

著者：Igor Sysoev
編集：Brian Mercer