Nginx を Web サーバーとして構成する方法を本当に理解していますか?

Nginx を Web サーバーとして構成する方法を本当に理解していますか
読む前に、「初めての Nginx 入門」を読むことをお勧めします。 次に、Nginx の構成を見てみましょう。
抽象的に言えば、Nginx を Web サーバーとして構成することは、どの URL を処理するか、およびこれらの URL に対応するリクエストをどのように処理するかを定義することです。具体的には、特定の IP 名とドメイン名でリクエストを制御するための仮想サーバー (Virtual Server) をいくつか定義します。
より具体的には、Nginx は一連の場所を定義することによって URIS の選択を制御します。各場所は、それ自体にマップされたリクエストの処理シナリオを定義します。つまり、ファイルまたはプロキシ リクエストを返すか、異なるエラー コードに基づいて異なるエラー ページを返すかです。さらに、URI に応じて、リクエストを他のサーバーまたは場所にリダイレクトすることもできます。
仮想サーバーをセットアップする
聞いてください：
Nginx 構成ファイルには、仮想サーバーを定義するために使用されるサーバー コマンドが少なくとも 1 つ含まれています。リクエストが来ると、Nginx はまずリクエストを処理する仮想サーバーを選択します。
仮想サーバーは http コンテキストのサーバーで定義されます:
http { サーバー { # サーバー設定
}
}
注: http
では複数のサーバーを定義できます サーバー設定ブロックは、listen コマンドを使用してローカル IP とポート番号 (Unix ドメインのソケットとパスを含む) を監視します。IPv6 アドレスは角かっこで囲む必要があります。 サーバー { listen 127.0.0.1:8080; # IPv4 アドレス、ポート 8080
# listen [2001:3CA1:10F:1A:121B:0:0:10]:80; # IPv6 アドレス、ポート 80
# listen [::]:80; # このマシンのすべての IPv4 および IPv6 アドレスをリッスンします、ポート 80
# 残りのサーバー構成}
上記の構成では、ポート番号が書き込まれない場合、デフォルトでポート 80 が使用され、IP が書き込まれない場合、ローカル マシンのすべての IP が監視されます。
サーバー名：
複数のサーバーのリッスン IP とポート番号がまったく同じである場合、Nginx はリクエスト ヘッダーでホストを渡します
Nginx を Web サーバーとして構成する方法を本当に理解していますか

server_name で定義されたホスト名と比較して、リクエストを処理する適切な仮想サーバーを選択します。
サーバー { 80 を聞いてください;
サーバー名 lufficc.com www.lufficc.com;
...
}
server_name のパラメータは次のとおりです:
完全なホスト名 (api.lufficc.com など)。
*.lufficc.com や api.* などのワイルドカード (* を含む) が含まれます。
~ で始まる正規表現。
ワイルドカード文字は先頭または末尾にのみ使用でき、 の隣にのみ使用できます。 www.*.example.org も w*.example.org も無効です。 ただし、 ~^www..+.example.org$ や ~^w.*.example.org$ などの正規表現を使用して、これらの名前と一致させることができます。 また、* は複数の部分に一致する可能性があります。 名前 *.example.org は、www.example.org だけでなく www.sub.example.org にも一致します。
正規表現の場合: Nginx で使用される正規表現は、Perl プログラミング言語 (PCRE) で使用される正規表現と互換性があります。 正規表現を使用するには、~ で始まる必要があります。
名前付き正規表現は変数をキャプチャして使用できます:
サーバー { サーバー名 ~^(www.)?(?<ドメイン>.+)$ 場所 / { root /sites/$domain;
}
}
括弧 () で囲まれた内容は後で $1 によって参照することもでき、$2 は 2 つ前の () の内容を表します。したがって、上記の内容は次のように書くこともできます:
サーバー { サーバー名 ~^(www.)?(.+)$ 場所 / { root /sites/$2;
}
}
server_name の例:
サーバー { 80 を聞いてください;
サーバー名 api.lufficc.com *.lufficc.com;
...
}
同様に、複数の名前が Host ヘッダーに一致する場合、Nginx は次の順序で選択します。 完全なホスト名 (api.lufficc.com など)。
* で始まる最長のワイルドカード名 (*.lufficc.com など)。
* で終わる最長のワイルドカード名 (api.* など)。
最初に一致した正規表現。 (設定ファイルの順序に従います)
つまり、優先度: api.lufficc.com > api.* >
Host ヘッダーがどのserver_nameにも一致しない場合、Nginx はリクエストをデフォルトの仮想サーバーにルーティングします。デフォルトの仮想サーバーは、nginx.conf ファイル内の最初のサーバー、またはdefault_server で明示的に宣言されたサーバーを参照します:
サーバー { 80 デフォルトサーバーをリッスンします;
...
}
場所を設定する
URIと位置パラメータのマッチング
サーバーを選択すると、Nginx は URI に基づいて適切な場所を選択し、リクエストをプロキシするかファイルを返すかを決定します。
location ディレクティブは 2 種類のパラメータを受け入れます:
プレフィックス文字列 (パス名)
正規表現
プレフィックス文字列パラメーターの場合、URI は厳密にプレフィックス文字列パラメーターで始まる必要があります。たとえば、/some/path/ パラメータの場合、/some/path/document.html には一致しますが、/my-site/some/path は /some で始まっていないため、/my-site/some/path には一致しません。 /パス/。
location /some/path/ {
...
}
正規表現の場合、~ で始まる場合は大文字と小文字が区別され、~* で始まる場合は大文字と小文字が区別されません。パス内の . は と記述する必要があることに注意してください。たとえば、.html または .htm で終わる URI に一致する場所:
場所 ~ .html {
? ...
}
正規表現はプレフィックス文字列よりも優先されます。一致するプレフィックス文字列が見つかった場合、正規表現の検索は引き続き続行されますが、プレフィックス文字列が ^~ で始まる場合、正規表現はチェックされません。
具体的な検索とマッチングのプロセスは次のとおりです:
URI をすべてのプレフィックス文字列と比較します。
= 修飾子は、URI がプレフィックス文字列と等しい (開始ではなく等しい) 必要があることを示し、見つかった場合は検索を停止します。
見つかった最長のプレフィックス一致文字列が ^~ で始まる場合、正規表現による一致の検索は行われなくなります。
一致する最長のプレフィックス文字列を格納します。
URI を正規表現と比較してテストします。
最初に一致する正規表現が見つかった後に停止します。
一致する正規表現がない場合は、4 に格納されたプレフィックス文字列に対応する場所が使用されます。
= 修飾子は最も高い優先順位を持ちます。 Web サイトのホームページに頻繁にアクセスする場合は、場所を具体的に定義して検索一致の数を減らし (= で変更して一致する場所を検索すると検索が停止するため)、速度を向上させることができます。
場所 = / {
...
}
静的ファイルとプロキシ
この場所は、一致するリクエストの処理方法 (静的ファイルを返すか、プロキシ サーバーに渡すか) も定義します。以下の例では、最初の場所は /data ディレクトリ内の静的ファイルを返し、2 番目の場所は処理のために https://lufficc.com ドメイン名のサーバーにリクエストを渡します。 サーバー { location /images/ { root /data;
} location / { proxy_pass https://lufficc.com;
}
}
ルート ディレクティブは静的ファイルのルート ディレクトリを定義し、URI と連結されて最終的なローカル ファイル パスを形成します。たとえば、/images/example.png が要求された場合、ローカル サーバー ファイル /data/images/example.png がスプライシング後に返されます。
proxy_pass ディレクティブは、URL が指すプロキシ サーバーにリクエストを渡します。プロキシ サーバーからの応答はクライアントに転送されます。 上の例では、/images/ で始まらない URI に対するすべてのリクエストは、処理のためにプロキシ サーバーに渡されます。
たとえば、proxy_pass を https://www.baidu.com/ に設定すると、http://search.lufficc.com/ にアクセスすると、Baidu ホームページと同じ応答 (ページ) が表示されます (興味のある子供用の靴は検索してみてください)独自) 機能、Baidu と変わりません):
サーバー{
聞いてください80;
サーバー名 search.lufficc.com;
場所 / {
proxy_pass https://www.baidu.com;
}
}
変数の使用
変数を使用すると、Nginx がさまざまなリクエストを異なる方法で処理できるようになります。変数は実行時に計算され、命令への引数として使用されます。 変数は $ で始まる記号で表されます。 変数は、現在処理されているリクエストのプロパティなど、Nginx の状態に基づいた情報を定義します。
コア HTTP 変数など、事前定義された変数が多数あり、set、map、geo ディレクティブを使用してカスタム変数を定義することもできます。 ほとんどの変数は実行時に計算され、特定のリクエストに関連する情報が含まれます。 たとえば、$remote_addr にはクライアント IP アドレスが含まれ、$uri には現在の URI 値が含まれます。
よく使用される変数は次のとおりです:
変数名関数
$uri リクエスト内の現在の URI (リクエスト パラメータなし)。これは、内部リダイレクトまたはインデックス ディレクティブを使用して変更できます。$uri には、/foo/bar.html などのホスト名が含まれません。
$arg_name はリクエスト内のパラメーター名です。つまり、「?」の後の arg_name=arg_value の形式の arg_name です
$hostname ホスト名
$args リクエスト内のパラメータ値
$query_string $args と同じ
$request はクライアントのリクエストアドレスを表します
$request_uri この変数は、一部のクライアント リクエスト パラメーターを含む元の URI と等しく、変更できず、ホスト名 (/cnphp/test.php?arg=freemouse など) は含まれません。
... ...
簡単なアプリケーションは、パス情報を使用して http から https にリダイレクトすることです:
サーバー{
...リターン 301 https://lufficc.com$request_uri;
...
}
特定のステータス コードを返す
Web サイト上の一部のリソースが完全に削除された場合、最も速くて簡潔な方法は、return コマンドを使用して直接戻ることです:
location /wrong/url { return 404;
}
戻り値の最初のパラメータは応答コードです。オプションの 2 番目のパラメーターは、リダイレクトの URL (コード 301、302、303、および 307 に対応)、または応答本文で返されるテキストにすることができます。 例:
location /permanently/moved/url { return 301 http://www.example.com/moved/here;
}
return ディレクティブは、場所とサーバーのコンテキストに含めることができます:
サーバー{
場所 / { return 404;
}
}
または:
サーバー{
...リターン 404;
場所 / {
...
}
}
エラー処理
error_page コマンドは、特定のエラー コードのエラー ページを構成したり、他のページにリダイレクトしたりできます。次の例では、404 エラーが発生したときに /404.html ページが返されます。
エラーページ 404 /404.html;
error_page コマンドはエラーの処理方法を定義するため、コマンドは直接戻りませんが、return はすぐに戻ります。プロキシ サーバーまたは Nginx が処理中に対応するエラー コードを生成すると、対応するエラー ページが返されます。
以下の例では、Nginx がページを見つけられない場合、コード 404 をコード 301 に置き換え、クライアントを http://example.com/new/path.html にリダイレクトします。 この構成は、たとえば、クライアントが依然として古い URI でページにアクセスしようとしている場合に、ページが完全に削除され、返された新しいアドレスに自動的に置き換える必要があることをブラウザに通知します。
location /old/path.html { error_page 404 =301 http:/example.com/new/path.html;
}
URIを書き換える
rewrite ディレクティブは、要求された URI を複数回変更できます。 rewrite の最初のパラメータは、URI が一致する必要がある正規表現で、2 番目のパラメータは置換される URI です。 3 番目のパラメータはオプションで、引き続きオーバーライドするか、リダイレクト コード (301 または 302) を返すかを示します。例:
location /users/ { rewrite ^/users/(.*)$ /show?user=$1 Break;
}
サーバーおよび場所のコンテキストに複数の書き換えディレクティブを含めることができます。 Nginx は命令を発生順に 1 つずつ実行します。 サーバーを選択すると、サーバー内の書き換えディレクティブが 1 回実行されます。
Nginx は一連の書き換えディレクティブを処理した後、新しい URI に基づいて場所を選択します。 選択した場所に書き換えディレクティブがまだ含まれている場合、それらは順番に実行されます。 URI がすべて一致する場合、定義されたすべての書き換えディレクティブが処理された後で新しい場所が検索されます。
次の例では、rewrite ディレクティブと return ディレクティブを使用しています。 サーバー{
...
^(/download/.*)/media/(.*)..*$ $1/mp3/$2.mp3 last;
を書き換えます ^(/download/.*)/audio/(.*)..*$ $1/mp3/$2.ra last を書き換えます;
...
}
/download/some/media/file などの URI は、 /download/some/mp3/file.mp3 に変更されます。 最後のフラグにより​​、後続の命令 (2 番目の書き換えディレクティブとリターン ディレクティブ) はスキップされますが、Nginx は変更された URI でリクエストの処理を続行します。 同様に、/download/some/audio/file などの URI は、/download/some/mp3/file.ra に置き換えられます。 URI が書き換えディレクティブと一致しない場合、Nginx はクライアントに 403 エラー コードを返します。
last と Break の違いは次のとおりです:
last : 現在のサーバーまたは場所のコンテキストで書き換えディレクティブの実行を停止しますが、Nginx は書き換えられた URI に一致する場所の検索を続行し、新しい場所に書き換えディレクティブを適用します (つまり、URI が再び変更される可能性があります)。
Break : 現在のコンテキストでの書き換えディレクティブの処理を停止し、新しい URI に一致する場所の検索をキャンセルします。 新しい場所の書き換えディレクティブは実行されません。
付録
よく使用される通常のルール
. : 改行を除く任意の文字に一致します
?: 0回または1回繰り返します
+ : 1 回以上繰り返します
*: 0 回以上繰り返します
d: 数字を一致させる
^ : 文字列の先頭と一致します
$: 文字列マッチングの紹介
{n}: n 回繰り返します
{n,}: n 回以上繰り返します
[c]: 単一文字 c
と一致します [a-z]: 小文字の a-z のいずれかと一致します
グローバル変数
$args: #この変数は、$query_string
と同じ、リクエストラインのパラメータと同じです $content_length: リクエストヘッダーのコンテンツ長フィールド。
$content_type: リクエストヘッダーの Content-Type フィールド。
$document_root: 現在のリクエストのルート ディレクティブで指定された値。
$host : リクエスト ホスト ヘッダー フィールド、それ以外の場合はサーバー名。
$http_user_agent: クライアントエージェント情報
$http_cookie: クライアントの Cookie 情報
$limit_rate: この変数は接続速度を制限できます。
$request_method: クライアントによって要求されたアクション (通常は GET または POST)。
$remote_addr: クライアントの IP アドレス。
$remote_port: クライアントのポート。
$remote_user: Auth Basic Module によって認証されたユーザー名。
$request_filename: 現在のリクエストのファイル パス。ルートまたはエイリアス ディレクティブと URI リクエストによって生成されます。
$scheme: HTTP メソッド (http、https など)。
$server_protocol: リクエストで使用されるプロトコル。通常は HTTP/1.0 または HTTP/1.1。
$server_addr: サーバー アドレス。この値はシステム コールの完了後に決定できます。
$server_name: サーバー名。
$server_port: リクエストがサーバーに到達するポート番号。
$request_uri: /foo/bar.php?arg=baz など、ホスト名を除く、リクエスト パラメーターを含む元の URI。
$uri: リクエスト パラメーターを含まない現在の URI。$uri にはホスト名 (/foo/bar.html など) が含まれません。
$document_uri: $uri と同じ。
リクエスト例: http://localhost:88/test1/test2/test.php
$host: ローカルホスト
$サーバーポート：88
$request_uri: http://localhost:88/test1/test2/test.php
$document_uri：/test1/test2/test.php
$document_root:/var/www/html
$request_filename：/var/www/html/test1/test2/test.php