Nginx設定ファイルを解析する

Nginx がインストールされると、前のインストール パスに従って、Nginx 構成ファイルのパスは /opt/nginx/conf になります。ここで、nginx.conf は Nginx のメイン構成ファイルです。ここでは、nginx.conf 構成ファイルに焦点を当てます。
Nginx 設定ファイルは主に、メイン (グローバル設定)、サーバー (ホスト設定)、アップストリーム (負荷分散サーバー設定)、およびロケーション (特定の場所の設定に一致する URL) の 4 つの部分に分かれています。メイン部分で設定された命令は、他のすべての設定に影響します。サーバー部分の命令は主にホストとポートを指定するために使用され、アップストリーム命令は主に一連のバックエンド サーバーの設定に使用されます。 location 部分は、Web ページの場所を照合するために使用されます。サーバーはメインを継承、ロケーションはサーバーを継承、アップストリームは他の設定を継承することも継承されることもありません。これらの 4 つの部分のうち、各部分にはいくつかの命令が含まれています。これらの命令には主に Nginx のメイン モジュール命令、イベント モジュール命令、HTTP コア モジュール命令が含まれており、各部分は Http SSL モジュールなどの他の HTTP モジュール命令も使用できます。 、HttpGzip 静的モジュール、Http 追加モジュールなど。
以下では、Nginx の設定例を使用して、nginx.conf の各命令の意味を詳しく紹介します。 Nginx の構造と各設定オプションの意味をより明確に理解するために、Nginx 設定ファイルを機能ポイントに応じて 7 つの部分に分けて、1 つずつ説明します。
1. Nginxのグローバル設定 以下の内容はNginxのグローバル属性設定です:

[html]ビュー 普通のコピー

ユーザー誰も誰もいない;

1. error_logログ/error.log通知
;
2. worker_rlimit_nofile 65535;
3. events{
4. use epoll;
5. work_connections 65536;
6. 上記のコードの各構成オプションの意味は次のように説明されます。
7. ユーザーはmaster モジュール ディレクティブ。Nginx Worker プロセスを実行するためのユーザーとユーザー グループを指定します。デフォルトでは、nobody アカウントによって実行されます。
worker_processes は、Nginx によってオープンされるプロセスの数を指定するメインモジュールの命令です。各 Nginx プロセスは平均 10M ～ 12M のメモリを消費します。経験上、通常は 1 つのプロセスを指定するだけで十分です。マルチコア CPU の場合は、CPU の数と同じ数のプロセスを指定することをお勧めします。
8. error_log は、グローバル エラー ログ ファイルを定義するために使用されるメイン モジュール ディレクティブです。ログ出力レベルには、デバッグ、情報、通知、警告、エラー、クリティカルが含まれており、その中でデバッグ出力ログが最も詳細であり、クリティカル出力ログが最も詳細です。
9. pid はメインモジュールの命令で、プロセス ID の保存ファイルの場所を指定するために使用されます。

worker_rlimit_nofile は、nginx プロセスで開くことができるファイル記述子の最大数を指定するために使用されます。ここでは 65535 です。これを設定するには、「ulimit -n 65535」コマンドを使用する必要があります。
events コマンドは、Nginx の動作モードと接続数の上限を設定します。

[html] ビュー 普通のコピー

イベント{
epoll を使用します

}

useは、Nginxの動作モードを指定するために使用されるイベントモジュールコマンドです。 Nginx でサポートされている動作モードは、select、poll、kqueue、epoll、rtsig、および /dev/poll です。このうち、select と poll は標準の動作モードであり、kqueue と epoll は効率的な動作モードです。違いは、epoll が Linux プラットフォームで使用されるのに対し、kqueue は BSD システムで使用されることです。 Linux システムの場合、epoll 動作モードが最初の選択肢です。
worker_connections もイベント モジュール ディレクティブであり、各 Nginx プロセスの最大接続数を定義するために使用されます。デフォルトは 1024 です。クライアント接続の最大数は、worker_processes と worker_connections によって決まります。つまり、Max_client=worker_processes*worker_connections です。リバース プロキシとして機能する場合、max_clients は次のようになります。 = ワーカープロセス * ワーカー接続/4。
プロセスの最大接続数は、Linux システム プロセスの開いているファイルの最大数によって制限されます。worker_connections の設定は、オペレーティング システム コマンド「ulimit -n 65536」を実行した後にのみ有効になります。

2.HTTPサーバーの設定
次に、HTTPサーバーの設定を開始します。
以下の内容はNginxのHTTPサーバー関連の属性の設定です。コードは次のとおりです:

[html]ビュー 普通のコピー

1. http{
2. include conf/mime.types;
3. default_type application/octet-stream '$remote_addr - $remote_ユーザー [$time_local] '
4. '"$request" $status $bytes_sent ' '"$http_referer" "$http_user_agent" ' '"$gzip_ratio"' '$remote_addr - $remote_user [ $time_local] ';
5. log_form '"$request" $status $bytes_sent '
6. '"$http_referer" "$http_user_agent" '
7. '"$http_range" "$sent_http_content_range" '
8. client_max_body_size 20ま、
9. client_header_buffer_size 32K;
10. Sendfile オン
11. tcp_nolay ;
12. keepalive_timeout 60;
13. client_body_timeout 10;
14. send_timeout 10;
15. 以下は、このコードの意味における各構成オプションの詳細な紹介です。
include は、構成ファイルに含まれるファイルの設定を可能にするメインモジュール命令であり、これによりメイン構成ファイルの複雑さを軽減できます。 Apache の include メソッドに似ています。
16. default_type は HTTP コア モジュール ディレクティブに属します。ここでは、デフォルトのタイプはバイナリ ストリームに設定されます。これは、たとえば、PHP 環境が設定されていない場合に使用されます。今回は「参照」を使用します。サーバーから PHP ファイルにアクセスすると、ダウンロード ウィンドウが表示されます。 次のコードは、ログ形式の設定を実装します。
17. [html] ビュー 普通のコピー MLog_Format Main '$ Remote_Addr-$ Remote_user [$ Time_local]'
'"$ Request" $ Status $ Bytes_SENT' "$ http_referr" "'
'"$gzip_ratio"';
log_formatダウンロード '$remote_addr - $remote_user [$time_local] '
'"$request" $status $bytes_sent '

'"$http_referer" " $http_user_agent" '



'"$http_range" " $sent_http_content_range"';

log_format は Nginx の HttpLog モジュール命令で、Nginx ログの出力形式を指定するために使用されます。 main このログ出力形式の名前。以下の access_log ディレクティブで参照できます。
client_max_body_size は、クライアントがリクエストできる単一ファイルの最大バイト数を設定するために使用されます。
client_header_buffer_size は、クライアントリクエストヘッダーからのヘッダーバッファーのサイズを指定するために使用されます。ほとんどのリクエストでは、バッファ サイズは 1K で十分です。メッセージ ヘッダーをカスタマイズする場合や、より大きな Cookie がある場合は、バッファ サイズを増やすことができます。これは 32K に設定されています。
large_client_header_buffers は、クライアント要求の大きなメッセージ ヘッダーのキャッシュの最大数とサイズを指定するために使用されます。「4」は数、「128K」はサイズ、最大キャッシュ量は 4 128K です。
sendfile パラメーターは、効率的なファイル転送モードを有効にするために使用されます。ネットワークのブロックを防ぐには、tcp_nopush 命令と tcp_nolay 命令を on に設定します。
keepalive_timeout は、クライアント接続が存続するためのタイムアウトを設定します。この時間が経過すると、サーバーは接続を閉じます。
client_header_timeout は、クライアントのリクエストヘッダーの読み取りタイムアウトを設定します。この時間を超えてもクライアントがデータを送信していない場合、Nginx は「リクエスト タイムアウト (408)」エラーを返します。
client_body_timeout は、クライアントのリクエスト本文の読み取りタイムアウトを設定します。この時間を超えてクライアントがデータを送信しない場合、Nginx は「リクエスト タイムアウト (408)」エラーを返します。デフォルト値は 60 です。
send_timeout は、クライアントに応答するためのタイムアウト時間を指定します。このタイムアウトは、2 つの接続アクティビティの間の時間に制限されます。クライアント上で何もアクティビティがないままこの時間を超えると、Nginx は接続を閉じます。

3.HttpGzipモジュールの設定
以下のNginxのHttpGzipモジュールを設定します。このモジュールは、出力データ ストリームのオンライン リアルタイム圧縮をサポートします。このモジュールがインストールされているかどうかを確認するには、次のコマンドを使用する必要があります:

[html] view 普通のコピー

1. [root@localhost conf]＃/opt/nginx/sbin/nginx -v - with-http_gzip_static_module --prefix
=/opt/nginx
3. /opt/nginx/sbin/nginx -V コマンドを使用して Nginx をインストールするときにコンパイル オプションを確認できます。 HttpGzip モジュールがインストールされていることがわかります。 以下は、Nginx 構成の HttpGzip モジュールの関連する属性設定です:

[html] ビュー 普通のコピー
gzip 上;

gzip_min_length 1k;

g zip_http_version 1.1;
1. gzip_comp_level 2;
2. gzip_types テキスト/プレーンアプリケーション/ x -javascript text/css application/xml;
3. gzip_vary on;
4. gzip は、GZIP 圧縮をオンにして出力データ ストリームを圧縮することを意味します。リアルタイムで。
5. gzip_min_length は、圧縮が許可されるページの最小バイト数を設定します。ページのバイト数はヘッダーの Content-Length から取得されます。デフォルト値は 0 で、サイズに関係なくページを圧縮します。バイト数は 1K より大きく設定することをお勧めします。1K 未満の場合、バイト数がどんどん大きくなる可能性があります。
6. gzip_buffers は、圧縮結果ストリーム キャッシュとして 4 ユニットの 16K メモリを適用することを意味します。デフォルト値は、gzip 圧縮結果を保存するために元のデータ サイズと同じメモリ領域を適用することです。
gzip_http_version は、HTTP プロトコルのバージョンを設定および識別するために使用されます。現在、ほとんどのブラウザーはすでに GZIP 解凍をサポートしているため、デフォルトを使用してください。
7. gzip_comp_level は、GZIP 圧縮率を指定するために使用されます。1 は圧縮率が最も小さく、処理速度が最も速くなります。9 は、圧縮率が最も大きく、転送速度が速くなりますが、処理が最も遅くなり、より多くの CPU リソースを消費します。

gzip_typesは圧縮タイプの指定に使用されます。指定の有無に関わらず、常に「text/html」タイプが圧縮されます。
gzip_vary オプションを使用すると、Squid を使用して Nginx 圧縮データをキャッシュするなど、フロントエンド キャッシュ サーバーが GZIP 圧縮されたページをキャッシュできるようになります。
4. 負荷分散設定 以下の負荷分散サーバーリストを設定します。

[html]ビュー 普通のコピー

1. アップストリームixdba.net{
2. サーバー192.168.12.133:80; 68.12.134:80
3. サーバー 192.168.12.135 : 8009 max_fails
=
4. 3
5. fail_timeout=20sサーバー192.168.12。 36:8080; } アップストリームこれは Nginx HTTP アップストリーム モジュールからのもので、このモジュールは単純なスケジューリング アルゴリズムを使用して、クライアント IP からバックエンド サーバーまでの負荷分散を実現します。上記の設定では、upstream ディレクティブを通じてロード バランサー ixdba.net の名前が指定されています。この名前は任意に指定でき、後で必要なときに直接呼び出すことができます。
Nginx の負荷分散モジュールは現在 4 つのスケジューリング アルゴリズムをサポートしており、最後の 2 つはサードパーティのスケジューリング方法です。
6. ポーリング (デフォルト)。各リクエストは時系列に 1 つずつ異なるバックエンド サーバーに割り当てられ、バックエンド サーバーがダウンした場合、障害のあるシステムは自動的に排除されるため、ユーザーのアクセスに影響はありません。
7. 体重。ポーリング重みを指定します。重みの値が大きいほど、より高いアクセス確率が割り当てられます。主に、各バックエンド サーバーのパフォーマンスが不均一な場合に使用されます。

ip_hash。各リクエストは訪問者 IP のハッシュ結果に従って割り当てられるため、同じ IP からの訪問者は常にバックエンド サーバーにアクセスし、動的 ​​Web ページのセッション共有の問題を効果的に解決します。
まあまあ。上記 2 つよりもインテリジェントな負荷分散アルゴリズム。このアルゴリズムは、ページ サイズと読み込み時間に基づいて負荷分散をインテリジェントに実行できます。つまり、バックエンド サーバーの応答時間に基づいてリクエストを割り当て、応答時間の短いリクエストを優先します。 Nginx 自体はフェアをサポートしていません。このスケジューリング アルゴリズムを使用する必要がある場合は、Nginx のupstream_fair モジュールをダウンロードする必要があります。
url_hash。アクセス URL のハッシュ結果に従ってリクエストを分散し、各 URL が同じバックエンド サーバーに向けられるようにすると、バックエンド キャッシュ サーバーの効率をさらに向上させることができます。 Nginx 自体は url_hash をサポートしていません。このスケジューリング アルゴリズムを使用する必要がある場合は、Nginx ハッシュ ソフトウェア パッケージをインストールする必要があります。
HTTP アップストリーム モジュールでは、server コマンドを使用してバックエンド サーバーの IP アドレスとポートを指定でき、負荷分散スケジュールで各バックエンド サーバーのステータスを設定することもできます。一般的に使用される状態は次のとおりです:
down。これは、現在のサーバーが当面負荷分散に参加しないことを意味します。
 バックアップ、予約されたバックアップ マシン。バックアップ マシンは、バックアップ以外の他のすべてのマシンに障害が発生するかビジー状態になると要求されるため、このマシンへの負担は最も少なくなります。
 max_fails (許可されるリクエスト失敗の数) のデフォルトは 1 です。最大回数を超えると、proxy_next_upstream モジュールで定義されたエラーが返されます。
fail_timeout、max_fails 回の失敗後にサービスを一時停止する時間。 max_fails は、fail_timeout と一緒に使用できます。
注: 負荷スケジューリング アルゴリズムが ip_hash の場合、負荷分散スケジューリングにおけるバックエンド サーバーのステータスを重みとバックアップにすることはできません。
5.server仮想ホストの構成 以下に仮想ホストの構成について説明します。仮想ホストの構成内容を別のファイルに書き込んで、 include ディレクティブを使用して含めることをお勧めします。これにより、保守と管理が容易になります。

[html] ビュー 普通のコピー

server{

server_name 192.168.12.188 www.ixdba.net;

listen 80; tm インデックス.jsp

1. ルート/web/wwwroot/www.ixdba.net charset gb2312;
   サーバー フラグは仮想ホストの開始を定義し、listen は仮想ホストのサービス ポートを指定するために使用され、server_name は IP アドレスまたはドメイン名を指定するために使用され、複数のドメイン名はスペースで区切られます。 Index はアクセス用のデフォルトのホームページ アドレスを設定するために使用され、root コマンドは仮想ホストの Web ページのルート ディレクトリを指定するために使用されます。このディレクトリは相対パスまたは絶対パスで指定できます。 Charset は、Web ページのデフォルトのエンコード形式を設定するために使用されます。
   access_log logs/www.ixdba.net.access.log main;
   access_log は、この仮想ホストのアクセス ログの保存パスを指定するために使用され、最後の main は、アクセス ログの出力形式を指定するために使用されます。 。

   6.URL マッチング設定
   URL アドレス マッチングは、Nginx 設定の最も柔軟な部分です。 Location は正規表現マッチングと条件判定マッチングをサポートしており、ユーザーは location ディレクティブを使用して動的 Web ページと静的 Web ページの Nginx フィルタリングを実装できます。
   次の設定では、location ディレクティブを使用して Web ページ URL を分析および処理します。拡張子が .gif、.jpg、.jpeg、.png、.bmp、および .swf であるすべての静的ファイルは、処理のために nginx に渡されます。および期限切れ 静的ファイルの有効期限を指定するために使用されます。ここでは 30 日です。
   

   [html] ビュー 普通のコピー

   1. location ~ .*.(gif|jpg|jpeg|png|bmp|swf)$ {
   这}
   4. 以下の設定はすべてのファイルに引き継がれますもちろん、UPLOAD と HTML は /web/wwwwroot/www.ixdba.net ディレクトリの真ん中にあります。 普通のコピー
   
   

   
   location ~ ^/(upload|html)/

   {有効期限は 30 日です
   最後の設定では、場所はこの仮想ホストの下の動的 Web ページのフィルタリング プロセスです。 .jsp サフィックスが付いたファイルは、処理のためにローカル マシンの 8080 ポートに渡されます。
   1. [html] ビュー 普通のコピー
   location ~ .*.jsp$ {
   4. インデックスindex.jsp;
   proxy_pass http://localhost:8080}
   

   
   

   7. StubStatus モジュールの設定
   StubStatus モジュールは、前回の起動以降の Nginx の動作ステータスを取得できます。このモジュールはコア モジュールではないため、この機能を使用するには Nginx のコンパイルおよびインストール時に手動で指定する必要があります。
   1. 以下のコマンドは実際にNginxの動作状態を取得する機能を有効にするよう指定しています。 普通のコピー
   1. location /NginxStatus {
   2. access_log logs/NginxStatus.log htpasswd;
   3. }
   5. stub_status は次のように設定されます。 「on」にすると、StubStatus の動作状況統計機能が有効になります。 access_log は、StubStatus モジュールのアクセス ログ ファイルを指定するために使用されます。 auth_basic は Nginx の認証メカニズムです。 auth_basic_user_file は認証用のパスワード ファイルを指定するために使用されます。Nginx の auth_basic 認証は Apache と互換性のあるパスワード ファイルを使用するため、Apache の htpasswd コマンドを使用してパスワード ファイルを生成する必要があります。たとえば、webadmin ユーザーを追加するには、次のようにします。次の方法でパスワード ファイルを生成します:/usr/local/apache/bin/htpasswd -c /opt/nginx/conf/htpasswd webadmin次のプロンプト メッセージが表示されます:
   新しいパスワード:
   6. パスワードを入力すると、を選択すると、システムはパスワードを再度入力するように求めます。確認後、ユーザーは正常に追加されました。
   Nginx の実行ステータスを確認するには、http://ip/NginxStatus と入力し、作成したばかりのユーザー名とパスワードを入力すると、次の情報が表示されます:
   アクティブな接続数: 1 サーバーは処理されたリクエストを受け入れます
   393411 393411 393799 読み取り: 0 書き込み: 1 待機: 0

   
   アクティブな接続は、現在アクティブな接続の数を示します。 3 行目の 3 つの数字は、Nginx が現在合計 393411 の接続を処理し、393411 のハンドシェイクが正常に作成され、処理されたことを示します。合計 393799 件のリクエスト。最後の行の読み取りは、Nginx によって読み取られたクライアント ヘッダー情報の数を示します。書き込みは、Nginx によってクライアントに返されたヘッダー情報の数を示します。「待機中」は、Nginx が処理を完了して待機している常駐接続の数を示します。次のリクエスト命令。
   
   
   最後の設定では、仮想ホストのエラー メッセージのリターン ページを設定します。error_page コマンドを使用して、さまざまなエラー メッセージのリターン ページをカスタマイズできます。デフォルトでは、Nginx はホーム ディレクトリの html ディレクトリで指定されたリターン ページを検索します。特に重要なのは、これらのエラー メッセージのリターン ページのサイズが 512K を超える必要があり、そうでない場合は IE ブラウザに置き換えられます。デフォルトのエラーページ。
   

   
   
   [html] ビュー 普通のコピー エラーページ 404 /404.html;
   
   
   

   エラーページ 500 502 503 504/50x.html;
   

   
   場所

   = /50x.html {
   ルート html;
   1. 1/ 790611
   上記では、内容の側面も含めて Nginx 設定ファイルの解析について紹介しています。PHP チュートリアルに興味のある友人に役立つことを願っています。