NGINXとNGINXPlusをWebサーバーとして構成する

NGINXおよびNGINXPlusをWebサーバーとして構成し、仮想サーバーのマルチテナンシー、URIと応答の書き換え、変数、およびエラー処理をサポートします。

この記事では、NGINXオープンソースとNGINX PlusをWebサーバーとして構成する方法について説明し、次のセクションを含みます。

仮想サーバーのセットアップ
場所の構成
- 場所の優先順位
変数の使用
特定のステータスコードを返す
リクエストのURIを書き換える
HTTP応答の書き換え
エラーの処理

NGINX PlusとNGINXオープンソースを調整する方法の詳細については、無料のウェビナーをオンデマンドでNGINXのインストールと調整をご覧ください。

注：この記事の情報は、NGINXオープンソースとNGINXPlusの両方に適用されます。読みやすくするために、この記事の残りの部分ではNGINXPlusのみを参照しています。

大まかに言えば、NGINX PlusをWebサーバーとして構成するには、処理するURLと、それらのURLでリソースに対するHTTP要求を処理する方法を定義する必要があります。下位レベルでは、構成は特定のドメインまたはIPアドレスの要求の処理を制御する一連の仮想サーバーを定義します。構成ファイルの詳細については、「NGINXPlus構成ファイルの作成」を参照してください。

HTTPトラフィックの各仮想サーバーは、特定のURIセットの処理を制御するロケーションと呼ばれる特別な構成インスタンスを定義します。各場所は、この場所にマップされたリクエストに何が起こるかについての独自のシナリオを定義します。NGINX Plusは、このプロセスを完全に制御します。各場所でリクエストをプロキシしたり、ファイルを返したりできます。さらに、URIを変更して、リクエストが別の場所または仮想サーバーにリダイレクトされるようにすることができます。また、特定のエラーコードを返すことができ、各エラーコードに対応するように特定のページを構成できます。

仮想サーバーのセットアップ

NGINX Plus構成ファイルには、仮想サーバーを定義するために少なくとも1つのサーバーディレクティブが含まれている必要があります。NGINX Plusがリクエストを処理するとき、最初にリクエストを処理する仮想サーバーを選択します。

仮想サーバーは、コンテキストserver内のディレクティブによって定義されます。次に例を示します。http

http {
    server {
        # Server configuration
    }
}

server複数のディレクティブをコンテキストに追加して、http複数の仮想サーバーを定義することができます。

server構成ブロックには通常、サーバーが要求をリッスンするIPアドレスとポート（またはUnixドメインソケットとパス）を指定するlistenディレクティブが含まれています。IPv4アドレスとIPv6アドレスの両方が受け入れられます。IPv6アドレスを角かっこで囲みます。

次の例は、IPアドレス127.0.0.1とポート8080でリッスンするサーバーの構成を示しています。

server {
    listen 127.0.0.1:8080;
    # Additional server configuration
}

ポートを省略すると、標準ポートが使用されます。同様に、アドレスが省略された場合、サーバーはすべてのアドレスをリッスンします。listenディレクティブがまったく含まれていない場合、スーパーユーザーの権限に応じて、「標準」ポートが含まれ80/tcp、「デフォルト」ポートが含まれます。8000/tcp

リクエストのIPアドレスとポートに一致するサーバーが複数ある場合、NGINX Plusは、ブロック内のserver_nameディレクティブに対してリクエストのHostヘッダーフィールドをテストします。のパラメーターは、完全な（正確な）名前、ワイルドカード、または正規表現にすることができます。ワイルドカードは、先頭、末尾、またはその両方にアスタリスク（）を含む文字列です。アスタリスクは、任意の文字シーケンスに一致します。NGINX Plusは、正規表現にPerl構文を使用します。それらの前にチルダ（）を付けます。この例は、正確な名前を示しています。serverserver_name*~

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

複数の名前がHostヘッダーに一致する場合、NGINX Plusは次の順序で名前を検索し、最初に一致したものを使用して1つを選択します。

正確な名前
アスタリスクで始まる最長のワイルドカード（例：*.example.org
アスタリスクで終わる最長のワイルドカード（例：mail.*
最初に一致する正規表現（構成ファイルに表示される順序）

Hostヘッダーフィールドがサーバー名と一致しない場合、NGINX Plusは、リクエストが到着したポートのデフォルトサーバーにリクエストをルーティングします。サーバーをデフォルトとして明示的に指定するパラメーターをディレクティブに含めない限り、デフォルトサーバーはnginx.confファイルにリストされている最初のサーバーです。default_serverlisten

server {
    listen 80 default_server;
    #...
}

場所の構成

NGINX Plusは、リクエストURIに基づいて、トラフィックをさまざまなプロキシに送信したり、さまざまなファイルを提供したりできます。これらのブロックは、ディレクティブ内に配置されたロケーションディレクティブを使用して定義されますserver。

たとえば、3つのlocationブロックを定義して、あるプロキシサーバーにいくつかのリクエストを送信し、別のプロキシサーバーに他のリクエストを送信し、ローカルファイルシステムからファイルを配信することで残りのリクエストを処理するように仮想サーバーに指示できます。

NGINX Plusは、すべてのディレクティブのパラメーターに対してリクエストURIをテストlocationし、一致する場所で定義されたディレクティブを適用します。通常、各locationブロック内に（いくつかの例外を除いて）さらに多くのlocationディレクティブを配置して、特定の要求グループの処理をさらに絞り込むことができます。

注：このガイドでは、場所という言葉は単一の場所のコンテキストを指します。

locationディレクティブのパラメーターには、プレフィックス文字列（パス名）と正規表現の2種類があります。リクエストURIがプレフィックス文字列と一致するには、プレフィックス文字列で始まる必要があります。

次のpathnameパラメーターを持つサンプルの場所は、 / some / path /で始まるリクエストURI （ /some/path/document.htmlなど）と一致します。（ / some / pathはそのURIの先頭で発生しないため、/ my-site / some / pathとは一致しません。）

location /some/path/ {
    #...
}

正規表現の前には、大文字と小文字を区別しない一致の場合はチルダ（）、大文字と小文字を区別しない一致の場合~はチルダ-アスタリスク（）が付きます。次の例は、任意の位置に文字列.htmlまたは.htm~*を含むURIに一致します。

location ~ \.html? {
    #...
}

NGINXロケーションの優先順位

URIに最も一致する場所を見つけるために、NGINXPlusは最初にURIをプレフィックス文字列のある場所と比較します。次に、正規表現を使用して場所を検索します。

^~修飾子を使用しない限り、正規表現が優先されます。プレフィックス文字列の中から、NGINX Plusは最も具体的な文字列（つまり、最も長く完全な文字列）を選択します。リクエストを処理する場所を選択するための正確なロジックを以下に示します。

すべてのプレフィックス文字列に対してURIをテストします。
（=等号）修飾子は、URIとプレフィックス文字列の完全一致を定義します。完全一致が見つかった場合、検索は停止します。
^~（caret-tilde）修飾子が最長一致のプレフィックス文字列の前にある場合、正規表現はチェックされません。
最長一致のプレフィックス文字列を格納します。
正規表現に対してURIをテストします。
最初に一致する正規表現が見つかったら処理を停止し、対応する場所を使用します。
正規表現が一致しない場合は、保存されているプレフィックス文字列に対応する場所を使用してください。

修飾子の一般的な使用例は、/（スラッシュ）=の要求です。/の要求が頻繁に発生する場合は、ディレクティブのパラメーターとして指定すると、最初の比較後に一致の検索が停止するため、処理が高速化されます。= /location

location = / {
    #...
}

コンテキストには、リクエストを解決する方法を定義するディレクティブを含めることができます。location静的ファイルを提供するか、プロキシサーバーにリクエストを渡します。次の例では、最初のlocationコンテキストに一致するリクエストは/ dataディレクトリから提供されるファイルであり、2番目に一致するリクエストはwww.example.comドメインのコンテンツをホストするプロキシサーバーに渡されます。

server {
    location /images/ {
        root /data;
    }

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

rootディレクティブは、提供する静的ファイルを検索するファイルシステムパスを指定します。場所に関連付けられたリクエストURIがパスに追加され、提供する静的ファイルのフルネームが取得されます。上記の例では、/ images / example.pngのリクエストに応じて、 NGINXPlusはファイル/data/images/example.pngを配信します。

proxy_passディレクティブは、構成されたURLでアクセスされるプロキシサーバーに要求を渡します。次に、プロキシされたサーバーからの応答がクライアントに返されます。上記の例では、 /images/で始まらないURIを持つすべてのリクエストがプロキシサーバーに渡されます。

変数の使用

構成ファイルの変数を使用して、定義された状況に応じてNGINXPlusが異なる方法でリクエストを処理するようにすることができます。変数は、実行時に計算され、ディレクティブのパラメーターとして使用される名前付きの値です。変数は$、名前の先頭にある（ドル）記号で示されます。変数は、現在処理されているリクエストのプロパティなど、NGINXの状態に基づいて情報を定義します。

コアHTTP変数など、事前定義された変数がいくつかあり、 set、map、およびgeoディレクティブを使用してカスタム変数を定義できます。ほとんどの変数は実行時に計算され、特定のリクエストに関連する情報が含まれています。たとえば$remote_addr、クライアントIPアドレスを含み、$uri現在のURI値を保持します。

特定のステータスコードを返す

一部のWebサイトURIでは、ページが一時的または永続的に移動された場合など、特定のエラーまたはリダイレクトコードを含む応答をすぐに返す必要があります。これを行う最も簡単な方法は、returnディレクティブを使用することです。例えば：

location /wrong/url {
    return 404;
}

の最初のパラメータreturnは応答コードです。オプションの2番目のパラメーターは、リダイレクトのURL（コード、、、、301およびの302場合）または応答本文で返すテキストにすることができます。例えば：303307

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

returnディレクティブは、locationとserverコンテキストの両方に含めることができます。

リクエストのURIを書き換える

リクエストURIは、1つのオプションパラメータと2つの必須パラメータを持つrewriteディレクティブを使用して、リクエスト処理中に複数回変更できます。最初の（必須の）パラメーターは、要求URIが一致する必要がある正規表現です。2番目のパラメーターは、一致するURIの代わりに使用するURIです。オプションの3番目のパラメーターは、以降のrewriteディレクティブの処理を停止したり、リダイレクト（コード301または302）を送信したりできるフラグです。例えば：

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

この例が示すように、2番目のパラメーターusersは正規表現のマッチングを介してキャプチャします。

とコンテキストの両方に複数のrewriteディレクティブを含めることができます。NGINX Plusは、ディレクティブを発生順に1つずつ実行します。コンテキスト内のディレクティブは、そのコンテキストが選択されたときに1回実行されます。serverlocationrewriteserver

NGINXは一連の書き換え命令を処理した後location、新しいURIに従ってコンテキストを選択します。選択した場所にrewriteディレクティブが含まれている場合、それらは順番に実行されます。URIがこれらのいずれかに一致する場合、定義されたすべてのrewriteディレクティブが処理された後、新しい場所の検索が開始されます。

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

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

この設定例では、2セットのURIを区別しています。/ download / some / media/fileなどのURIは/download/some/mp3/file.mp3に変更されます。フラグが原因でlast、後続のディレクティブ（2番目rewriteとreturnディレクティブ）はスキップされますが、NGINX Plusはリクエストの処理を続行します。これにより、URIが異なります。同様に、/ download / some / audio/fileなどのURIは/download/some/mp3/file.raに置き換えられます。URIがどちらのディレクティブとも一致しない場合rewrite、NGINXPlusは403エラーコードをクライアントに返します。

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

last–rewrite現在serverまたはlocationコンテキストでのディレクティブの実行を停止しますが、NGINX Plusは書き換えられたURIに一致する場所を検索rewriteし、新しい場所のすべてのディレクティブが適用されます（つまり、URIを再度変更できます）。
break– breakディレクティブと同様に、現在のコンテキストでのディレクティブの処理を停止rewriteし、新しいURIに一致する場所の検索をキャンセルします。新しい場所のrewriteディレクティブは実行されません。

HTTP応答の書き換え

場合によっては、HTTP応答のコンテンツを書き直したり変更したりして、ある文字列を別の文字列に置き換える必要があります。sub_filterディレクティブを使用して、適用する書き換えを定義できます。ディレクティブは変数と置換のチェーンをサポートし、より複雑な変更を可能にします。

たとえば、プロキシ以外のサーバーを参照する絶対リンクを変更できます。

location / {
    sub_filter      /blog/ /blog-staging/;
    sub_filter_once off;
}

別の例では、スキームをからhttp://に変更し、アドレスをリクエストヘッダーフィールドのホスト名にhttps://置き換えます。localhostsub_filter_onceディレクティブは、場所内でsub_filterディレクティブを連続して適用するようにNGINXに指示します。

location / {
    sub_filter     'href="http://127.0.0.1:8080/'    'href="https://$host/';
    sub_filter     'img src="http://127.0.0.1:8080/' 'img src="https://$host/';
    sub_filter_once on;
}

すでに変更された応答の一部は、別の一致が発生sub_filterした場合に再度置き換えられないことに注意してください。sub_filter

エラーの処理

error_pageディレクティブを使用すると、NGINX Plusを構成して、エラーコードとともにカスタムページを返すか、応答で別のエラーコードに置き換えるか、ブラウザーを別のURIにリダイレクトできます。次の例では、ディレクティブはエラーコードとともに返すerror_pageページ（/404.html）を指定します。404

error_page 404 /404.html;

このディレクティブは、エラーがすぐに返されることを意味するのではなく（returnディレクティブがそれを行う）、エラーが発生したときにエラーを処理する方法を指定するだけであることに注意してください。エラーコードは、プロキシされたサーバーから発生するか、NGINX Plusによる処理中に発生する可能性があります（たとえば、404NGINX Plusがクライアントから要求されたファイルを見つけられなかった場合の結果）。

次の例では、NGINX Plusがページを見つけることができない場合、コード301をコードに置き換え、クライアントをhttp：/example.com/new/path.html404にリダイレクトします。この構成は、クライアントがまだ古いURIのページにアクセスしようとしている場合に役立ちます。このコードは、ページが永続的に移動したことをブラウザに通知し、戻ったときに古いアドレスを新しいアドレスに自動的に置き換える必要があります。301

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

次の構成は、ファイルが見つからない場合にバックエンドにリクエストを渡す例です。ディレクティブの等号の後にステータスコードが指定されていないため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、ファイルが見つからない場合に内部リダイレクトを行うようにNGINXPlusに指示します。ディレクティブのfinalパラメーターの$uri変数はerror_page、リダイレクトで渡される現在のリクエストのURIを保持します。

たとえば、/ images / some / fileが見つからない場合は、/ fetch / images / some / fileに置き換えられ、場所の新しい検索が開始されます。その結果、リクエストは2番目のlocationコンテキストで終了し、 http：//backend/にプロキシされます。

open_file_cache_errorsディレクティブは、ファイルが見つからない場合にエラーメッセージを書き込まないようにします。欠落しているファイルは正しく処理されるため、ここではこれは必要ありません。

ソース：https ：//docs.nginx.com/nginx/admin-guide/web-server/web-server/

#nginx #web

仮想サーバーのセットアップ
場所の構成
- 場所の優先順位
変数の使用
特定のステータスコードを返す
リクエストのURIを書き換える
HTTP応答の書き換え
エラーの処理

NGINX PlusとNGINXオープンソースを調整する方法の詳細については、無料のウェビナーをオンデマンドでNGINXのインストールと調整をご覧ください。

仮想サーバーのセットアップ

仮想サーバーは、コンテキストserver内のディレクティブによって定義されます。次に例を示します。http

http {
    server {
        # Server configuration
    }
}

server複数のディレクティブをコンテキストに追加して、http複数の仮想サーバーを定義することができます。

次の例は、IPアドレス127.0.0.1とポート8080でリッスンするサーバーの構成を示しています。

server {
    listen 127.0.0.1:8080;
    # Additional server configuration
}

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

複数の名前がHostヘッダーに一致する場合、NGINX Plusは次の順序で名前を検索し、最初に一致したものを使用して1つを選択します。

正確な名前
アスタリスクで始まる最長のワイルドカード（例：*.example.org
アスタリスクで終わる最長のワイルドカード（例：mail.*
最初に一致する正規表現（構成ファイルに表示される順序）

server {
    listen 80 default_server;
    #...
}

場所の構成

注：このガイドでは、場所という言葉は単一の場所のコンテキストを指します。

location /some/path/ {
    #...
}

location ~ \.html? {
    #...
}

NGINXロケーションの優先順位

すべてのプレフィックス文字列に対してURIをテストします。
（=等号）修飾子は、URIとプレフィックス文字列の完全一致を定義します。完全一致が見つかった場合、検索は停止します。
^~（caret-tilde）修飾子が最長一致のプレフィックス文字列の前にある場合、正規表現はチェックされません。
最長一致のプレフィックス文字列を格納します。
正規表現に対してURIをテストします。
最初に一致する正規表現が見つかったら処理を停止し、対応する場所を使用します。
正規表現が一致しない場合は、保存されているプレフィックス文字列に対応する場所を使用してください。

location = / {
    #...
}

server {
    location /images/ {
        root /data;
    }

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

変数の使用

特定のステータスコードを返す

location /wrong/url {
    return 404;
}

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

returnディレクティブは、locationとserverコンテキストの両方に含めることができます。

リクエストのURIを書き換える

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

この例が示すように、2番目のパラメーターusersは正規表現のマッチングを介してキャプチャします。

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

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

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

last–rewrite現在serverまたはlocationコンテキストでのディレクティブの実行を停止しますが、NGINX Plusは書き換えられたURIに一致する場所を検索rewriteし、新しい場所のすべてのディレクティブが適用されます（つまり、URIを再度変更できます）。
break– breakディレクティブと同様に、現在のコンテキストでのディレクティブの処理を停止rewriteし、新しいURIに一致する場所の検索をキャンセルします。新しい場所のrewriteディレクティブは実行されません。

HTTP応答の書き換え

たとえば、プロキシ以外のサーバーを参照する絶対リンクを変更できます。

location / {
    sub_filter      /blog/ /blog-staging/;
    sub_filter_once off;
}

location / {
    sub_filter     'href="http://127.0.0.1:8080/'    'href="https://$host/';
    sub_filter     'img src="http://127.0.0.1:8080/' 'img src="https://$host/';
    sub_filter_once on;
}

すでに変更された応答の一部は、別の一致が発生sub_filterした場合に再度置き換えられないことに注意してください。sub_filter

エラーの処理

error_page 404 /404.html;

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

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/;
    }
}

ソース：https ：//docs.nginx.com/nginx/admin-guide/web-server/web-server/

#nginx #web

NGINXとNGINXPlusをWebサーバーとして構成する

仮想サーバーのセットアップ

場所の構成

NGINXロケーションの優先順位

変数の使用

特定のステータスコードを返す

リクエストのURIを書き換える

HTTP応答の書き換え

エラーの処理

What is GEEK

Buddha Community