サーバ名

ワイルドカード名
正規表現名
その他の名前
国際化ドメイン名
Virtual server selection
Optimization
互換性

サーバ名は、server_name ディレクティブで定義することができ、指定されたリクエストにどのserverブロックが使われるかを決定します。"How nginx processes a request"も見てください。それらは、正確な名前、ワイルドカード名、あるいは正規表現を使って定義されるでしょう: 

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.com"
  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_nameがserver ブロックで定義されていなければ、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;
}

この名前は何も特別なものではありません。それは単純にどのような現実の名前の邪魔をしないような不正なドメイン名の数ある中の一つです。"--" と"!@#"のような他の不正な名前が同様に使われるかもしれません。

バージョン0.6.25までのnginxは、包括的な名前と誤って解釈される特別な名前"*"をサポートしていました。それは、包括的あるいはワイルドカードサーバ名として機能しません。その提供されていた機能の代わりに、今ではserver_name_in_redirect ディレクティブが提供されています。特別な名前"*"は今は非推奨で、server_name_in_redirectディレクティブが使われるべきです。server_name ディレクティブを使って、包括的な名前やデフォルトサーバを指定する方法は無いことに注意してください。これは listen ディレクティブのプロパティで、server_name ディレクティブのプロパティではありません。"How nginx processes a request"も見てください。ポート *:80と *:8080をlistenするサーバを定義し、一方をポート *:8080のデフォルトサーバに、他方をポート*:80のデフォルトになるように定義することができます: 

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

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

国際化ドメイン名

国際化ドメイン名(IDNs) はserver_name ディレクティブ内でASCII (Punycode)表現を使って指定されなければなりません: 

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

Virtual serverの選択

最初に、デフォルトサーバコンテキストで接続が作成されます。次に、サーバー名は、サーバ設定選択に関係する次のリクエスト処理ステージで決定できます:

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

最適化

正確な名前、アスタリスクで始まるワイルドカード名、アスタリスクで終わるワイルドカード名は、listenポートに紐付いた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は起動に失敗してエラーメッセージを表示するでしょう: 

server_names_hashを構築できなかった場合、
server_names_hash_bucket_size: 32 を増やすべきです。

この場合、ディレクティブの値は次の2のべき乗の値まで増やす必要があります: 

http {
    server_names_hash_bucket_size  64;
    ...

大量のサーバ名が定義された場合は、また別のエラーメッセージが表示されるでしょう: 

server_names_hashを構築できなかった場合、
server_names_hash_max_size: 512 あるいは
server_names_hash_bucket_size: 32 のどちらかを増やすべきです。

この場合、まずは server_names_hash_max_sizeをサーバ名の数に近い数字に設定してみましょう。これでは役に立たない場合やnginxの起動時間が耐えられないほど長い場合は、 server_names_hash_bucket_sizeを増やしてみてください。

サーバがlistenポートを見ている唯一のサーバのであれば、nginxはサーバ名を全くテストしないでしょう(そして、listeポートのハッシュテーブルをビルドしないでしょう)。しかし、一つ例があります。もしサーバ名がキャプチャーのある正規表現の場合、nginxはキャプチャを取得するために表現を実行しなければならないでしょう。

互換性

written by Igor Sysoev
edited by Brian Mercer
TOP
inserted by FC2 system