nginxのシンプル転送リクエストのサーバーとロケーション設定の詳しい説明

nginx のサーバーと場所の構成を簡単に整理してみましょう。

たとえば、URL: www.mask_dev2.com:9999/login/

サーバー パイプの前半部分、つまり www.mask_dev2.com:9999

場所は後半部分を制御します。つまり、/login/

1 つの nginx を複数のサーバーで構成できます。

各サーバーは複数の場所で構成できます。

URL の前半はどのサーバーを選択するかを制御し、後半はどの場所を選択するかを制御します。これにより、最終的にリクエストが送信される場所が決まります。

サーバー構成

サーバー{
 9999を聞く;
 サーバー名 www.mask_dev2.cn;
 位置 / {
  デフォルトタイプはtext/htmlです。
  コンテンツbylua
   ngx.say("<p>最初</p>")
  ';
 }
}

サーバー{
 9999を聞く;
 サーバー名 www.mask_dev2.*;
 位置 / {
  デフォルトタイプはtext/htmlです。
  コンテンツbylua
   ngx.say("<p>2番目</p>")
  ';    
 }
}

サーバー{
 聞く 9998;
 サーバー名_;
 位置 / {
  デフォルトタイプはtext/htmlです。
  コンテンツbylua
   ngx.say("<p>3番目</p>")
  ';

 }
}

まず、nginx に要求されるアドレスは、要求された nginx が配置されているサーバーである必要があります。つまり、IP アドレスは固定です。

つまり、server_name が何であるかは関係なく、現在のサーバーを参照します。

では、現在のサーバーは複数のドメイン名にどのように対応しているのでしょうか？これは、対応するDNSサーバーに追加するだけで済みます。たとえば、ローカルマシンを一時的にDNSサーバーとして扱い、ホストを変更します。

127.0.0.1 ローカルホスト
127.0.0.1 www.mask_dev2.cn
127.0.0.1 www.mask_dev2.com

サーバーマッチング順序

server_name と host の一致する優先順位は次のとおりです。

1. 完全一致
2. ワイルドカードを先頭に付ける（例：*.test.com）
3. 最初の URL の後（例: www.test.*）
4. ~^\.www\.test\.com$ などの正規の一致

どれも一致しない場合

1. listen設定項目の後にdefaultまたはdefault_serverを優先する
2. リスンポートに一致する最初のサーバーブロックを見つける

場所の設定

サーバーを見つけたら、特定の場所を見つけます

サーバー{
 聞く 9998;
 サーバー名_;
 場所 = / { 
  #ルールA 
 } 
 場所 = /ログイン { 
  #ルールB 
 } 
 場所 ^~ /static/ { 
  #ルールC 
 } 
 場所 ~ \.(gif|jpg|png|js|css)$ { 
  #ルールD 
 } 
 場所 ~* \.png$ { 
  #ルールE 
 } 
 場所 !~ \.xhtml$ { 
  #ルールF 
 } 
 場所 !~* \.xhtml$ { 
  #ルールG 
 } 
 位置 / { 
  #ルール H 
 }

構文規則:

場所 [=||*|^~] uri { … }

1. 先頭の=は完全一致を示します
2. 先頭の ^~ は、URI が通常の文字列で始まることを意味し、URL パスに一致するものとして理解できます。 Nginx は URL をエンコードしないため、リクエストは /static/20%/aa となり、ルール ^~ static /aa (スペースに注意) に一致します。
3. ~ は大文字と小文字を区別する正規表現で始まります
4. ~*は大文字と小文字を区別しない正規表現で始まります
5. ! と !* は、それぞれ大文字と小文字を区別する正規表現と大文字と小文字を区別しない正規表現です。
6. / ユニバーサルマッチ、どんなリクエストもマッチします。
7. 複数の場所が設定されている場合、一致する順序は次のようになります (参考資料に基づきますが、実際にはまだ検証されていません。試してみるとわかります。これに縛られることはありません。あくまでも参考用です)。

まず、= に一致し、次に ^~ に一致し、次にファイル内の順序で正規表現に一致し、最後に / の一般的な一致に一致します。一致が成功した場合、一致を停止し、現在の一致ルールに従ってリクエストを処理します。

しかし、一般的にはそれほど複雑ではなく、ポイントは 3 つあります。

1. デフォルトのリクエスト。
2. ページリクエスト。
3. バックグラウンド ロジック要求。

#ウェブサイトのルートと直接一致します。ドメイン名を介してウェブサイトのホームページにアクセスする方が頻繁になります。これを使用すると、処理が高速化されると公式サイトは述べています。 
#これはバックエンドアプリケーションサーバーに直接転送されるか、静的ホームページになる場合があります# 最初に必要なルールの場所 = / { 
  proxy_pass http://tomcat:8080/index 
} 

# 2 番目の必須ルールは、静的ファイル要求を処理することです。これは、http サーバーとしての nginx の強みです。# ディレクトリ マッチングとサフィックス マッチングの 2 つの構成モードがあり、どちらかを選択するか、両方を使用します。location ~* \.(gif|jpg|jpeg|png|css|js|ico)$ { 
  ルート /webroot/res/; 
} 

#3 番目のルールは一般的なルールで、動的なリクエストをバックエンド アプリケーション サーバーに転送するために使用されます。#非静的ファイル リクエストはデフォルトで動的なリクエストであり、実際の状況に応じて把握できます。#結局のところ、人気のあるフレームワークの中には、.php や .jsp のサフィックスが付いているものはほとんどありません。location / { 
  プロキシパス http://127.0.0.1:8080/ 
}

要約する

たとえば、フロントエンド システムとバックエンド システムを同時に起動する場合、2 つのサーバーを使用できます (ホストを api、admin に設定したり、ポートを直接変更したりできます)。各サーバーには、特定のページ要求を判断するための 3 つの場所があります。

以上がこの記事の全内容です。皆様の勉強のお役に立てれば幸いです。また、123WORDPRESS.COM を応援していただければ幸いです。