Log In Buy Online Free Trial Contact Sales
Free Trial Contact Sales

NGINX Web サーバ

NGINX Web サーバ

このセクションでは以下を説明します:

  • webサーバの最も一般的な設定
  • バーチャルサーバの設定とリクエスト処理の場所の定義の仕方
  • 変数の使い方
  • 特定のステータスコードの返し方
  • リクエストのURIのrewriteの仕方
  • HTTPエラーページの設定方法

結局は、webサーバとしてのNGINXの設定は、どのURLを処理できるか、そしてそれらをどう処理するかを定義するかの問題です。低レベルでは、設定は特定のドメインまたはIPアドレスのためにリクエストを処理する責任があるバーチャルサーバのセットからできています。

それぞれのバーチャルサーバはURLの特定のセットを処理を制御するlocation と呼ばれる特別な設定インスタンスを定義します。それぞれのlocationはこのlocationに割り当てられたリクエストに何が起こるかの個々のシナリオを定義します。NGINXはこの処理に完全な制御を提供します。それぞれのlocationはリクエストを代理するかファイルを返すことができます。さらに、URIは修正することができ、それによりリクエストは他のlocationまたはバーチャルサーバにリダイレクトされます。また、特定のエラーコードを返すことができ、それぞれのエラーコードに対して特定のページを設定することができます。

設定ファイル

NGINXの設定は、特定の書式でテキストベースの設定ファイルという点で他のサービスと似ています。デフォルトのファイル名はnginx.confです。 nginx.conf の場所はNGINXをインストールするために利用したパッケージシステムとOSに依存します。代表的には、/usr/local/nginx/conf, /etc/nginxまたは /usr/local/etc/nginx ディレクトリのどれかです。

設定ファイルはディレクティブとパラメータを使って作成されます。それぞれのディレクティブはセミコロンで終了します。大括弧内に追加の指示を追加するかも知れません。以下は幾つかの例です。

user             nobody;
error_log        logs/error.log notice;
worker_processes 1;

includeを使って、設定をファイルの階層に分けることもできます。ファイルの内容は中に含まれます。

include mime.types;

コンテキストとして参照される特別なディレクティブがあります。events, http, server そして location コンテキストです。

コンテキスト外に置かれているディレクティブはmain コンテキストにあると見なされます。以下の例では、コンテキストを使った完全な設定を示します。

user nobody; # a directive in the 'main' context

events {
    # configuration of events
}

http {

    # Configuration specific to HTTP and affecting all virtual servers

    server {
        # configuration of virtual server 1

        location /one {
            # configuration for processing URIs with '/one'
        }

        location /two {
            # configuration for processing URIs with '/two'
        }
    }

    server {
        # configuration of virtual server 2
    }
}

気づいたかも知れませんが、HTTPに関係する設定はhttp コンテキストの中にあります。server コンテキストは、http コンテキストの中で特定のバーチャルサーバを設定します。最後に、location コンテキストはserver コンテキストの中でNGINXに特定のURLセットを処理する事を教えるために使われます。

多くの場合において、他のコンテキストの中で定義されているコンテキストは、そのディレクティブを継承するでしょう。そのような場合に現在のレベルに同じディレクティブを定義すると、継承したディレクティブは現在のレベルのディレクティブで上書きされるでしょう。コンテキストの継承について更に詳しい情報は、 proxy_set_header documentationを見てください。

設定ファイルの変更が有効になるには、2つの方法があります。ひとつ目は、単純にnginxをrestart します。その他の方法としては、現在のリクエストの処理を中断せずに設定をアップグレードするリロードシグナルを送信することができます。

バーチャルサーバの設定

HTTPリクエストを処理するには、NGINX設定ファイルに少なくとも1つのバーチャルサーバを定義する必要があります。NGINXがリクエストを処理するときに、リクエストに応えるバーチャルサーバを最初に選択します。

サーバはserver ディレクティブを使って定義され、次の例のようにhttp コンテキストの中に配置されます:

http {
    server {
        # Server configuration
    }
}

複数のバーチャルサーバを定義するために複数のserverディレクティブを http コンテキストに追加することができます。

サーバディレクティブはまたlisten ディレクティブを含む必要があります。このディレクティブはサーバがlistenするIPアドレスとポート番号(あるいはドメインソケットとパス)を指定します。IPアドレスはIPv4またはIPv6のどちらでも構いません。IPv6は角括弧の中に指定する必要があることに注意してください。

次の例は127.0.0.1 アドレスと8080 ポートでlistenするサーバの設定を示しています。

server {
    listen 127.0.0.1:8080;
    # The rest of server configuration
}

ポートが省略された場合は、標準のポートが使われるでしょう。同様に、アドレスが省略された場合は、サーバは全てのアドレスでlistenするでしょう。listen ディレクティブが指定されていない場合、"standard" ポートは80/tcp で、"default" ポートは8000/tcpです。

リクエストのIPアドレスとポートに合致するサーバが幾つかあった場合、NGINXはリクエストの"Host"ヘッダフィールドとserverブロックのserver_nameディレクティブとをテストします。このディレクティブのパラメータは、正確な名前、ワイルドカード、または正規表現 が有り得ます。ワイルドカード名は名前の最初または最後にアスタリスクを含む、どのような文字も合致します。 正規表現は最初にチルダ (~) を配置する必要があります。以下の例は正確な名前の場合を表現しています。

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

幾つかの名前が"Host"ヘッダと一致した場合は、NGINXは次の順番でひとつを選びます:

  1. 正確な名前
  2. アスタリスクで始まる最も長いワイルドカードの名前。例えば*.example.org。
  3. アスタリスクで終わる最も長いワイルドカードの名前。例えばmail.*。
  4. 最初に一致した正規表現(設定ファイル中の表示順)。

もし"Host"ヘッダフィールドがサーバ名と合致しない場合は、NGINXはリクエストをこのポートのデフォルトサーバへと送ります。デフォルトサーバはnginx.confファイルの中の最初のものです。もしserver コンテキスト内のlistenディレクティブにdefault_serverパラメータが設定されている場合は上書きされるでしょう。次に例を示します。

server {
    listen      80 default_server;
    ...
}

locationの設定

NGINXがバーチャルサーバの設定においてもっている一つの特徴として、リクエストURLに応じてトラフィックを異なるプロキシに送ったり、または異なるファイルを提供できることがあります。これらのブロックはserverディレクティブ内のlocation ディレクティブを使って定義されます。

例えば、リクエストの一部をプロキシされているサーバに送ったり、別の一部を異なるプロキシされているサーバに送ったり、その残りのリクエストをローカルファイルシステムから提供するように、バーチャルサーバを設定することができます。. これをするには、バーチャルサーバにそれぞれの場合に応じて3つのlocationブロックを設定します。

NGINXは全てのlocationディレクティブのパラメータに対してURIをテストし、選択されたlocationに存在するディレクティブを適用します。それぞれのlocationブロックの中で、リクエストの特定のグループに関連した部分に設定を分割してもっと多くのlocationを配置することが(幾つかの例外はありますが)可能です。

注意: このガイドでは、"location"は一つのlocationディレクティブとその内容を意味します。

locationディレクティブのパラメータはプリフィックスの文字列または正規表現が可能です。URIは照合するために前置文字列で開始する必要があります。

以下はプリフィックス文字列パラメータのlocationの例です。 /some/path/document.htmlのようなリクエストが合致するでしょう。

location /some/path/ {
    ...
}

正規表現は最初にチルダ (~) が配置されます。次の例では、パラメータに正規表現を含むlocationが".html"または".htm"を含むURIに合致します。

location ~ \.html? {
    ...
}

"^~"修飾子が使われない場合は、正規表現に高い優先度が与えられます。プリフィックスの文字列のうちNGINXは最も限定されたものを選択します(つまり、もっとも長く、もっとも揃っているもの)。リクエストを処理するlocationを選択するための正確なロジックは次のようになります:

  1. 全てのプリフィックス文字列に対してURIをテストします。
  2. "=" 修飾子はURIとプリフィックス文字列が完全に一致することを定義します。もし完全に一致するものが見つかった場合は、検索が終わります。
  3. もし、もっとも長く合致したプリフィックス文字列に"^~" 修飾子がついている場合は、正規表現はチェックされません。
  4. 最も長く合致したプリフィックス文字列を保存します。
  5. URIと正規表現のテストを開始します。
  6. 一番最初に合致した正規表現で中断し、対応するlocationを利用します。
  7. もし正規表現が合致しなかった場合は、保存されているプリフィックス文字列に対応するlocationを利用します。

"=" 修飾子を使う典型的な例は、"/"と一緒にある場合です。もし"/" リクエストへの提供が必要な事が多い場合は、locationのパラメータに "= /" を指定することでこれらのリクエストの処理が高速化されるでしょう。上で述べたように、これは最初の比較の後で検索が中断されるからです。 

location = / {
    ...
}

locationにはリクエストをどのように解決するか、つまり静的なファイルを提供するかプロキシにリクエストを渡すか、を定義する事ができるようなディレクティブを含むことができます。次の例ではバーチャルサーバにそれぞれの解決方法を示している二つのlocationがあります。

server {
    location / {
        proxy_pass http://www.example.com;
    }

    location /images/ {
        root /data;
    }
}

proxy_pass ディレクティブは、あなたが指定したURLにあるプロキシされたサーバにリクエストを渡します。プロキシされたサーバからの応答はクライアントに送り返されるでしょう。上の例では、"/images/"で始まらないURLへの全てのリクエストを、プロキシされたサーバに渡します。

root ディレクティブは静的なファイルが存在するファイルシステムパスを指示します。locationに関連づけられたリクエストのURIは、次に静的なファイルを取得するためにパスに追加されます。上の例では、"/images/example.png"のURIへの応答として、NGINXは"/data/images/example.png"ファイルを送信するでしょう。

変数

nginx.confファイルは変数を設定することができます。変数を使うことで、定義された環境に応じて異なる動きをする設定を作ることができます。変数は実行時に計算される名前がある変数で、ディレクティブのパラメータに使われます。変数名の最初の"$"記号が変数の印です。変数は、現在処理しているリクエストのプロパティのように、nginxの状況に基づく情報を定義します。

core HTTP 変数のように、たくさんの定義済みの変数がありますが、 set, map そして geo ディレクティブを使って独自の変数を定義することもできます。ほとんどの変数は実行時に算出され、特定のリクエストに関係する情報を含んでいます。例えば、$remote_addr にはクライアントのIPアドレスが含まれ、$uri は現在のURIの値を持っています。

特定のコードの返し方

特定のエラーやリダイレクトをすぐに返す必要があるwebサイトのURLがあるかも知れません。この例のように、ページが一時的あるいは永久に移動してしまうことがあるでしょう。これをする最も簡単な方法は return ディレクティブを使うことです。例えば:

location /wrong/url {
    return 404;
}

子リターンの最初のパラメータはリスポンスコードです。さらに、ディレクティブはリダイレクト(コード 301,302,303と307)のURLまたはリスポンスボディの中で返すテキストを、二つ目のパラメータを持つことができます。例えば:

location /permanently/moved/url {
    return 301 http://www.example.com/moved/here;
}

returnディレクティブはlocationまたはseverコンテキストのどちらの中でも指定することができます。

URIのrewrite

リクエストのURIはrewriteを使ってリクエスト処理の間に何回も変更することができます。このディレクティブは二つの必須パラメータと一つの任意のパラメータを持ちます。最初のパラメータはリクエストのURIをテストするための正規表現です。二つ目のパラメータは、正規表現が合致した場合に現在のURIを置き換えるURIです。任意の三つ目のパラメータはそれ以上のrewriteディレクティブの処理の停止を指示することができるフラグです。例えば:

location /users/ {
    rewrite ^/users/(.*)$ /show?user=$1 break;
}

この例が示すように、二つのパラメータ users は正規表現のマッチの間に捕らえられます。

rewrite ディレクティブはserver と location レベルの両方で使うことができます。複数個の rewrite ディレクティブを同じserver またはlocation で使うことができます。rewrite ディレクティブは出現順に一つずつ実行されます。バーチャルサーバレベルのrewrite ディレクティブは、バーチャルサーバが選択されたときに一度だけ実行されます。

一旦このrewrite命令のセットが処理されると、新しいURIにしたがってlocation が選択されます。その後、もし選択されたlocation が rewrite ディレクティブを含んでいれば、次はそれらが実行されます。URIがそれらのどれかに合致した場合は、全てのrewriteディレクティブが処理された後で、新しいlocationの検索が始まります。

次の例は、returnディレクティブと組み合わせのrewriteディレクティブを示しています。

server {
    ...
    rewrite ^(/download/.*)/media/(.*)\..*$ $1/mp3/$2.mp3 last;
    rewrite ^(/download/.*)/audio/(.*)\..*$ $1/mp3/$2.ra  last;
    return  403;
    ...
}

この例の設定は、二つの種類のURIを区別します。/download/some/media/file のようなURIは /download/some/mp3/file.mp3 に変更されます。二つ目のrewriteとreturnは(lastフラグにより)スキップされますが、NGINXはもう異なるURIとなったリクエストを処理し続けます。同様に、/download/some/audio/file のようなURIは /download/some/mp3/file.raと置き換えられます。URI がどの場合とも異なる場合は、returnディレクティブが活動をはじめ、403エラーコードを返します。

rewriteディレクティブの処理を中断させる二つのパラメータがあります。

  • last は 現在のバーチャルサーバまたはlocationのrewrite ディレクティブの実行を停止しますが、locationの検索は続きます。そして、新しいlocationの rewrite ディレクティブは実行されるでしょう。
  • break パラメータはbreakディレクティブと同様に 現在のレベルの rewrite ディレクティブの処理を停止し、locationの検索を停止します。そして 新しいlocationのrewrite ディレクティブは実行されないでしょう。

エラーページの設定

特定のエラーコードで返されるページを設定するには、 error_page ディレクティブを使います。このディレクティブにより、特定のエラーコードの応答として返すページのURIのような、特定のエラーコードのためのルールを設定することができます。エラーコードを別のものの代わりとして設定することもできます。次の例では、error_pageディレクティブが404エラーのときに返すページを設定しています。

error_page 404 /404.html;

このディレクティブは即座にエラーを返す事を意味するのではなく、単にそれらが起きた時にエラーを扱う設定を提供していることに注意してください。(即座にエラーを返すのはreturnがすることです)エラーコードはプロキシしたサーバから来ることやNGINXによるリクエストの処理結果で現れるかも知れません。(例えば、NGINXがクライアントによってリクエストされたファイルを見つけられない時に404が現れる)

次の例では、ページが見つからない場合に、404コードを301コードに置き換えて異なるURIにリダイレクトします。

location /old/path.html {
    error_page 404 =301 http:/example.com/new/path.html;
}

ページが新しいURIを持つが、まだクライアントが古いアドレスでアクセスしようとする場合に、この種類の置き換えは便利かも知れません。301コードはブラウザにページが永久に移動した事を伝えます。301コードの設定は、リターン時にブラウザに古いアドレスを新しいものに自動的に置き換えるように伝えます。

次の設定は、ファイルが見つからない時にバックエンドへリクエストを渡す例です。下のerror_page ディレクティブは イコール記号の後にステータスコードを指定していないため、クライアントが取得する応答にはプロキシされたサーバが返すステータスコード(404の必要はありません)が入っているでしょう。

server {
    ...
    location /images/ {
        # Set the root directory to search for the file
        root                   /data/www;

        # Disable logging of errors related to file existence
        open_file_cache_errors off;

        # Make an internal redirect if the file is not found
        error_page             404 = /fetch$uri;
    }

    location /fetch/ {
        proxy_pass             http://backend/;
    }
}

ここでのerror_page ディレクティブに設定されているパラメータに $uri 変数が含まれ、その変数には現在のリクエストのURIが保持されていることに注意してください。open_file_cache_errors ディレクティブは、ファイルが見つからないときにエラーメッセージを書くことを妨げます。ファイルが見つからない場合に正しく扱われるため、ここでは必要ではありません。 handled. error_page ディレクティブの利用により、ファイルが見つからない場合にはNGINXは内部的なリダイレクトを起こします。もっと厳密に言えば、/images/some/file URI は /fetch/images/some/file に置き換えられ、locationの新しい検索が開始されます。結果として、リクエストは二つ目のlocationになり、 proxiedされます。

Free Trial
NGINX Plus is the commercially-supported version of NGINX, offering:

… backed by Nginx, Inc. dedicated support.

TOP
inserted by FC2 system