優れたソフトウェアと実用的なチュートリアル
エングス 設定ファイルは主に4つの部分に分かれています。メイン（グローバル設定）、サーバー（ホスト設定）、アップストリーム（アップストリームサーバー設定、主にリバースプロキシ、負荷分散関連の設定）、ロケーション（URLが特定の場所に一致した後の設定）です。メイン部分に設定された指示は、他のすべての部分の設定に影響します。サーバー部分の指示は、主に仮想ホストのドメイン名、IP、ポート番号の設定に使用されます。アップストリーム部分の指示は、一連のバックエンドサーバーの設定、リバースプロキシの設定、バックエンドサーバーの負荷分散に使用されます。ロケーション部分は、Webページの位置（ルートディレクトリ「/」、「/images」など）の一致に使用されます。これらの関係は、サーバーがメインを継承し、ロケーションがサーバーを継承します。アップストリームは指示を継承することも、継承されることもありません。
nginx.conf 設定ファイル
以下はnginx.conf設定ファイルの詳細な説明です（以下の設定パラメータは必ずしも多くのケースで使用されるわけではなく、設定パラメータの説明の参考としてのみ使用されます。一般的なバージョンの紹介は以下で確認できます）
#はNginxが実行するユーザーとユーザーグループを定義します
ユーザー www www;
#nginxプロセス番号。通常はCPUの数と同じに設定されます。
ワーカープロセス数 4;
# グローバルエラーログ定義タイプ、[デバッグ | 情報 | 通知 | 警告 | エラー | クリティカル]
#error_log ログ/error.log;
#error_log ログ/error.log 通知;
#error_log ログ/error.log 情報;
#プロセスPIDファイル
#pid ログ/nginx.pid;
# は、プロセスが開くことができる記述子の最大数を指定します。
#動作モードと接続数の上限
## この命令は、nginxプロセスが開くファイルディスクリプタの最大数を指定します。理論上の値は、開いているファイルの最大数（ulimit -n）をnginxプロセス数で割った値になりますが、nginxはリクエストをそれほど均等に割り当てるわけではないため、ulimit -nの値と一致させるのが最適です。
#これは、nginxがスケジューリング時にリクエストをプロセスに均等に割り当てないためです。そのため、10240と入力した場合、総同時実行数が30,000～40,000に達したときにプロセス数が10240を超える可能性があり、502エラーが返されます。
ワーカー_rlimit_nofile 65535;
イベント {
# 参照イベントモデル、[ kqueue | rtsig | epoll | /dev/poll | select | poll ] を使用します。epoll モデル
#は、Linuxカーネルバージョン2.6以降で動作する高性能ネットワークI/Oモデルです。Linuxではepollが推奨されています。FreeBSDで実行する場合は、kqueueモデルを使用してください。
# 追加指示:
#はApacheに似ています。Nginxはオペレーティングシステムごとに異なるイベントモデルを備えています。
#A) 標準イベントモデル
#Selectとpollは標準イベントモデルに属します。現在のシステムでより効果的な方法がない場合、nginxはselectまたはpollを選択します。
#B) 効率的なイベントモデル
#Kqueue: FreeBSD 4.1+、OpenBSD 2.9+、NetBSD 2.0、MacOS X で使用されます。デュアルプロセッサを搭載した MacOS X システムで kqueue を使用すると、カーネル パニックが発生する可能性があります。
#Epoll: Linux カーネル バージョン 2.6 以降で使用されます。
#/dev/poll: Solaris 7 11/99+、HP/UX 11.22+ (eventport)、IRIX 6.5.15+、および Tru64 UNIX 5.1A+ で使用されます。
#Eventport: Solaris 10 で使用されます。カーネルのクラッシュを防ぐには、セキュリティ パッチをインストールする必要があります。
epollを使用する
# 単一プロセスの最大接続数（最大接続数 = 接続数 + プロセス数）
#はハードウェアに合わせて調整し、前の作業工程と組み合わせて使用します。可能な限り大きくする必要がありますが、カップを100%まで動かさないでください。
ワーカー接続 1024;
#キープアライブタイムアウト
キープアライブタイムアウト 60;
# クライアント要求ヘッダーバッファサイズ。システムのページングサイズに応じて設定できます。通常、要求ヘッダーのサイズは1KBを超えることはありません。ただし、システムのページングサイズは通常1KBを超えるため、ここではページングサイズに設定します。
# ページング サイズは、getconf PAGESIZE コマンドを使用して取得できます。
#[root@web001 ~]# getconf ページサイズ
# ただし、client_header_buffer_size が 4k を超える場合もありますが、client_header_buffer_size の値は「システム ページング サイズ」の整数倍に設定する必要があります。
クライアント_ヘッダー_バッファ_サイズ 4k;
#は開いているファイルのキャッシュを指定します。デフォルトでは有効になっていません。maxはキャッシュの数を指定します。開いているファイルの数と一致させることを推奨します。inactiveは、ファイルが要求されない場合にキャッシュが削除されるまでの時間を指します。
open_file_cache 最大=65535 非アクティブ=60秒;
# は、キャッシュされた情報の有効性をチェックする頻度を示します。
# 構文: open_file_cache_valid time デフォルト値: open_file_cache_valid 60 使用場所: http、server、location このディレクティブは、open_file_cache 内のキャッシュ項目の有効性をいつチェックするかを指定します。
open_file_cache_valid 80秒;
#open_file_cache ディレクティブの非アクティブパラメータ時間内にファイルが使用される最小回数。この回数を超えた場合、ファイル記述子は常にキャッシュ内で開かれます。例えば、非アクティブ時間内に一度も使用されなかったファイルは削除されます。
# 構文: open_file_cache_min_uses 数値 デフォルト値: open_file_cache_min_uses 1 適用範囲: http、server、location このディレクティブは、open_file_cache ディレクティブが無効な場合に、一定時間内に使用できるファイルの最小数を指定します。より大きな値を使用すると、ファイル記述子は常にキャッシュ内で開かれます。
オープンファイルキャッシュの最小使用数は 1 です。
# 構文: open_file_cache_errors on | off デフォルト値: open_file_cache_errors off コンテキスト: http、server、location このディレクティブは、ファイルを検索するときにキャッシュ エラーをログに記録するかどうかを指定します。
open_file_cache_errors をオン;
}
#はhttpサーバーをセットアップし、そのリバースプロキシ機能を使用して負荷分散サポートを提供します。
http{
#ファイル拡張子とファイルタイプのマッピングテーブル
mime.types をインクルードします。
# デフォルトのファイルタイプ
デフォルトタイプはアプリケーション/オクテットストリームです。
# デフォルトエンコーディング
文字セット utf-8;
# サーバー名ハッシュテーブルのサイズ
サーバー名を格納するハッシュテーブルは、server_names_hash_max_sizeディレクティブとserver_names_hash_bucket_sizeディレクティブによって制御されます。パラメータhash bucket sizeは常にハッシュテーブルのサイズと等しく、プロセッサキャッシュのサイズの倍数です。これにより、プロセッサ内でのハッシュテーブルキーの検索を高速化し、メモリへのアクセス回数を削減できます。hash bucket sizeがプロセッサキャッシュのサイズと等しい場合、キーの検索時にメモリ検索の回数は最悪の場合でも2回になります。1回目はストレージユニットのアドレスを決定するため、2回目はストレージユニット内のキー値を見つけるためです。したがって、Nginxからハッシュ最大サイズまたはハッシュバケットサイズを増やす必要があるというヒントが表示された場合、まず前者のパラメータのサイズを増やす必要があります。
サーバー名ハッシュバケットサイズ 128;
# クライアントリクエストヘッダーのバッファサイズ。システムのページングサイズに応じて設定できます。通常、リクエストヘッダーのサイズは1KBを超えることはありません。ただし、システムのページングサイズは通常1KBより大きいため、ここではページングサイズに設定します。ページングサイズは、コマンドgetconf PAGESIZEで取得できます。
クライアント_ヘッダー_バッファ_サイズ 32k;
# クライアントリクエストヘッダーバッファサイズ。デフォルトでは、nginx は client_header_buffer_size バッファを使用してヘッダー値を読み取ります。ヘッダーが大きすぎる場合は、large_client_header_buffers を使用して読み取ります。
large_client_header_buffers 4 64k;
#はnginx経由でアップロードされるファイルのサイズを設定します
クライアントの最大ボディサイズは8mです。
#は効率的なファイル転送モードをオンにします。sendfileディレクティブは、nginxがファイル出力時にsendfile関数を呼び出すかどうかを指定します。通常のアプリケーションではオンに設定されていますが、ダウンロードなどディスクIO負荷の高いアプリケーションで使用する場合はオフに設定することで、ディスクとネットワークI/Oの処理速度のバランスを取り、システム負荷を軽減できます。注：画像が正常に表示されない場合は、オフに変更してください。
#sendfileディレクティブは、nginxがファイルを出力するためにsendfile関数（ゼロコピーモード）を呼び出すかどうかを指定します。一般的なアプリケーションでは、オンに設定する必要があります。ダウンロードなど、ディスクIO負荷の高いアプリケーションで使用する場合は、ディスクとネットワークIOの処理速度のバランスを取り、システムの稼働時間を短縮するためにオフに設定できます。
ファイル送信オン;
# は、ダウンロード サーバーに適したディレクトリ リスト アクセスを開きますが、デフォルトでは閉じられています。
自動インデックスオン;
# このオプションは、sockeのTCP_CORKオプションの使用を有効または無効にします。このオプションはsendfileを使用する場合にのみ使用されます。
tcp_nopush オン;
tcp_nodelay オン;
# 長い接続タイムアウト（秒）
キープアライブタイムアウト 120;
#FastCGI関連のパラメータは、ウェブサイトのパフォーマンスを向上させるために使用され、リソース使用量を削減し、アクセス速度を向上させます。以下のパラメータは、その文字通りの意味を理解することで理解できます。
fastcgi_connect_timeout 300;
fastcgi_send_timeout 300;
fastcgi_read_timeout 300;
fastcgi_buffer_size 64k;
fastcgi_buffers 4 64k;
fastcgi_busy_buffers_size 128k;
fastcgi_temp_file_write_size 128k;
#gzipモジュールの設定
gzip オン; # は gzip 圧縮出力をオンにします
gzip_min_length 1k; # 最小圧縮ファイルサイズ
gzip_buffers 4 16k; #圧縮バッファ
gzip_http_version 1.0; # 圧縮バージョン (デフォルト 1.1、フロントエンドが squid2.5 の場合は 1.0 を使用してください)
gzip_comp_level 2; # 圧縮レベル
gzip_types text/plain application/x-javascript text/css application/xml; #圧縮タイプ、textmlはデフォルトで含まれているので、以下に記述する必要はありません。記述しても問題はありませんが、警告が表示されます。
gzip_vary オン;
IP接続数を制限する場合は#を使用する必要があります
#limit_zoneクローラー $binary_remote_addr 10m;
#負荷分散構成
アップストリーム piao.jd.com {
1TP5上流負荷分散において、重みはマシン構成に応じて定義できる重みです。重みパラメータは重みを表し、重みが高いほど割り当てられる確率が高くなります。
サーバー 192.168.80.121:80 重み=3;
サーバー 192.168.80.122:80 重み=2;
サーバー 192.168.80.123:80 重み=3;
#nginxのアップストリームは現在4種類のディストリビューションをサポートしています
#1、ポーリング（デフォルト）
# 各リクエストは時系列順に異なるバックエンドサーバーに順次割り当てられます。バックエンドサーバーがダウンしている場合は、自動的に削除できます。
#2、重量
#はポーリング確率を指定します。重みはアクセス率に比例し、バックエンドサーバーのパフォーマンスが不均一な場合に使用されます。
#例えば:
1TP5上流ベークエンド{
# サーバー 192.168.0.14 重み = 10;
# サーバー 192.168.0.15 重み = 10;
#}
#2、ip_hash
# 各リクエストはアクセス IP のハッシュ結果に従って割り当てられるため、各訪問者は固定のバックエンド サーバーにアクセスし、セッションの問題を解決できます。
#例えば:
1TP5上流ベークエンド{
# ip_ハッシュ;
# サーバー 192.168.0.14:88;
# サーバー 192.168.0.15:80;
#}
#3、公正（第三者）
# は、バックエンド サーバーの応答時間に基づいてリクエストを分散し、応答時間が最も短いサーバーを優先します。
#upstreamバックエンド{
# サーバー server1;
# サーバー server2;
# フェア;
#}
#4、url_hash（サードパーティ）
# は、アクセスされた URL のハッシュ結果に応じてリクエストを分散し、各 URL が同じバックエンド サーバーに送信されるようにします。これにより、バックエンド サーバーがキャッシュされている場合に、より効果的です。
# 例: アップストリームにハッシュステートメントを追加します。重みなどの他のパラメータはサーバーステートメントに記述できません。hash_method は使用するハッシュアルゴリズムです。
#upstreamバックエンド{
# サーバー squid1:3128;
# サーバー squid2:3128;
# ハッシュ $ request_uri;
# ハッシュメソッド crc32;
#}
#ヒント:
#upstream bakend{#は負荷分散デバイスのIPとデバイスステータスを定義します}{
# ip_ハッシュ;
# サーバー 127.0.0.1:9090 がダウンしています。
# サーバー 127.0.0.1:8080 重み = 2;
# サーバー 127.0.0.1:6060;
# サーバー 127.0.0.1:7070 バックアップ;
#}
#負荷分散を使用する必要があるサーバーにproxy_pass http://bakend/を追加します。
# 各デバイスのステータスは次のように設定されます。
#1.downは、注文の前のサーバーが一時的に負荷に参加していないことを意味します。
#2.weight 重量が大きいほど、荷物の重量も大きくなります。
#3.max_fails: 許容されるリクエスト失敗のデフォルトの数は 1 です。最大数を超えると、proxy_next_upstream モジュールで定義されたエラーが返されます。
#4.fail_timeout: max_fails 回の失敗後の一時停止時間。
#5.backup: バックアップ以外のマシンがすべてダウンまたはビジー状態の場合、バックアップマシンが要求されます。そのため、このマシンへの負荷は最も低くなります。
#nginx は、異なるサーバーで使用するために複数の負荷分散グループを同時に設定することをサポートしています。
#client_body_in_file_only は、クライアントが投稿したデータをデバッグ用にファイルに記録するためにオンに設定されています。
#client_body_temp_pathは記録ファイルのディレクトリを設定します。最大3階層のディレクトリを設定できます。
#locationはURLと一致します。リダイレクトまたは新しいプロキシ負荷分散を実行できます。
}
#仮想ホスト構成
サーバー {
#リスニングポート
聞く 80;
#ドメイン名はスペースで区切って複数指定できます。
サーバー名 www.jd.com jd.com;
# デフォルトのエントリファイル名
インデックス index.html index.htm index.php;
ルート /data/www/jd;
#は******で負荷分散を実行します
場所 ~ .*.(php|php5)?$
{
fastcgi_pass 127.0.0.1:9000;
fastcgi_index インデックス.php;
fastcgi.conf をインクルードします。
}
#ピクチャキャッシュ時間設定
場所 ~ .*.(gif|jpg|jpeg|png|bmp|swf)$
{
有効期限は10日です。
}
#JSとCSSのキャッシュ時間設定
場所 ~ .*.(js|css)?$
{
1時間で期限切れになります。
}
#ログフォーマット設定
#$remote_addr と $http_x_forwarded_for は、クライアントの IP アドレスを記録するために使用されます。
#$remote_user: クライアントのユーザー名を記録するために使用されます。
#$time_local: アクセス時間とタイムゾーンを記録するために使用されます。
#$Request: 要求された URL と http プロトコルを記録するために使用されます。
#$status: リクエストステータスを記録するために使用されます。成功は200です。
#$body_bytes_sent: クライアントに送信されたファイル本体のサイズを記録します。
#$http_referer: 訪問元のページリンクを記録するために使用されます。
#$http_user_agent: クライアントブラウザの関連情報を記録します。
1TP5通常、Webサーバーはリバースプロキシの背後に配置されているため、クライアントのIPアドレスを取得できません。$remote_addによって取得されるIPアドレスは、リバースプロキシサーバーのIPアドレスです。リバースプロキシサーバーは、転送されたリクエストのHTTPヘッダー情報にx_forwarded_for情報を追加することで、元のクライアントのIPアドレスと、元のクライアントが要求したサーバーアドレスを記録することができます。
ログフォーマット アクセス '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" $http_x_forwarded_for';
#はこの仮想ホストのアクセスログを定義します
access_log /usr/local/nginx/logs/host.access.log メイン;
access_log /usr/local/nginx/logs/host.access.404.log log404;
# 「/connect-controller」のリバースプロキシを有効にする
場所 /connect-controller {
proxy_pass http://127.0.0.1:88; #ここでのポート番号は、仮想ホストがリッスンするポート番号（つまり、サーバーがリッスンするポート）と同じにはできないことに注意してください。
proxy_redirect オフ;
proxy_set_header X-Real-IP $remote_addr;
#バックエンドウェブサーバーはX-Forwarded-Forを通じてユーザーの実際のIPを取得できる
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
# 以下はオプションのリバース プロキシ構成です。
proxy_set_header ホスト $host;
# クライアントが要求できる単一ファイルの最大バイト数
クライアントの最大ボディサイズは10mです。
# プロキシがクライアント要求に対してバッファリングする最大バイト数。
#256KBなどの比較的大きな値に設定すると、FirefoxまたはIEブラウザを使用して256KB未満の画像を送信しても正常に動作します。このディレクティブをコメントアウトし、デフォルトのclient_body_buffer_size設定（オペレーティングシステムのページサイズの2倍、つまり8KBまたは16KB）を使用すると問題が発生します。
# Firefox 4.0 または IE 8.0 を使用している場合でも、約 200k の比較的大きな画像を送信すると、500 内部サーバーエラーが返されます。
クライアント_body_バッファサイズ 128k;
# は、nginx に 400 以上の HTTP 応答コードをブロックするように指示します。
proxy_intercept_errors をオン;
# バックエンドサーバ接続タイムアウト_ハンドシェイクを開始し、応答タイムアウトを待つ
バックエンド サーバーとの Nginx 接続タイムアウト (プロキシ接続タイムアウト)
プロキシ接続タイムアウト 90;
バックエンドサーバーのデータ転送時間（エージェント送信タイムアウト）
#バックエンドサーバデータ送信時間_は、バックエンドサーバが指定された時間内にすべてのデータを送信する必要があることを意味します。
プロキシ送信タイムアウト 90;
接続が成功した後、バックエンドサーバーの応答時間（プロキシ受信タイムアウト）
# が正常に接続した後、バックエンド サーバーが応答するまでの待機時間は、実際にはバックエンド キューに入って処理を待っている時間です (バックエンド サーバーが要求を処理するのにかかる時間とも言えます)。
プロキシ_読み取りタイムアウト 90;
#はプロキシサーバー（nginx）にユーザーヘッダー情報を保存するためのバッファサイズを設定します。
#は、プロキシサーバーから読み取られるレスポンスの最初の部分のバッファサイズを設定します。通常、レスポンスのこの部分には小さなレスポンスヘッダーが含まれます。デフォルトでは、この値はproxy_buffersディレクティブで指定されたバッファサイズですが、より小さいサイズに設定することもできます。
プロキシバッファサイズ 4k;
#proxy_buffersバッファ、平均的なウェブページは32k以下に設定されます
#は、プロキシサーバーからのレスポンスの読み取りに使用するバッファの数とサイズを設定します。デフォルトはページングサイズで、オペレーティングシステムに応じて4KBまたは8KBになります。
プロキシバッファ 4 32k;
高負荷時の#バッファサイズ（proxy_buffers*2）
proxy_busy_buffers_size 64k;
#は、ファイルを渡すときにワーカープロセスが長時間ブロックされるのを防ぐために、proxy_temp_pathに書き込む際のデータのサイズを設定します。
# キャッシュフォルダのサイズを設定します。この値より大きい場合は、上流サーバーから転送されます。
proxy_temp_file_write_size 64k;
}
#ローカル動的および静的分離リバースプロキシ構成
# すべてのJSPページはTomcatまたはResinによって処理されます
場所 ~ .(jsp|jspx|do)?$ {
proxy_set_header ホスト $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
プロキシパス http://127.0.0.1:8080;
}
}
}
Nginx の一般的な設定ファイル (Windows システム上の nginx1.14.2 の nginx.conf 設定はこちら)
次の nginx.conf は、フロントエンドで nginx をリバース プロキシ サーバーとして実装し、js や png などの静的ファイルを処理し、jsp などの動的リクエストを他のサーバーに転送する例を示しています (関連する構成パラメータの詳細な説明については、上記の説明を参照してください)。
ワーカープロセス 1;
#error_log ログ/error.log;
#error_log ログ/error.log 通知;
#error_log ログ/error.log 情報;
#pid ログ/nginx.pid;
イベント {
ワーカー接続 1024;
}
http {
mime.types をインクルードします。
デフォルトタイプはアプリケーション/オクテットストリームです。
#log_format main '$remote_addr - $remote_user [$time_local] "$request" '
# '$status $body_bytes_sent "$http_referer" '
# '"$http_user_agent" "$http_x_forwarded_for"';
access_log ログ/access.log メイン;
error_log ログ/ssl.error.log crit;
ファイル送信オン;
#tcp_nopush オン;
#キープアライブタイムアウト 0;
キープアライブタイムアウト 65;
#gzip オン;
サーバー {
聞く 8088;
サーバー名 ローカルホスト;
文字セット utf-8;
#access_log ログ/host.access.log メイン;
#エントリファイルの設定
位置 / {
ルート D:/vueWork/dentalFactory/dist; # エントリファイルディレクトリ
インデックス index.html index.htm; # デフォルトのエントリファイル名
}
# tomcatリバースプロキシ設定
場所 /場所名/ {
proxy_pass http://192.168.1.10:8080; # http://127.0.0.1:8080/サービス名（プロジェクト名）/
#proxy_set_header ホスト $host;
proxy_set_header Host $host:$server_port; //注: 現在のプロジェクトのポート番号が8080でない場合は、この設定が必要です。そうでない場合、バックエンドは正しいポート番号を取得できません。
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
静的リソースの#プロキシ構成（通常は構成は必要ありませんが、ここでは画像リソースの構成例を示します）
#場所/画像/{
# ルート D:/A-studySpace/nginxDemo;
#}
1TP5ここで404ページを設定します
#error_ページ 404 /404.html;
# これはリクエストステータスに対応するページ設定場所です
エラーページ 500 502 503 504 /50x.html;
場所 = /50x.html {
ルート html;
}
# PHPリバースプロキシ設定
#はすべてのPHPページリクエストを処理のためにphp-fpmに転送します。
#場所 ~\.php$ {
# ルート html;
# fastcgi_pass 127.0.0.1:9000;
# fastcgi_index index.php;
# fastcgi_param SCRIPT_FILENAME /scripts$fastcgi_script_name; #fastcgi_paramには多くの設定パラメータがあり、必要に応じて調整してください。
# には fastcgi_params が含まれます。
#}
}
# IP、名前、ポートベースの設定を組み合わせた別の仮想ホスト
#
#サーバー{
# リスン 8000;
#はsomename:8080を聞きます。
# server_name somename alias another.alias;
# の場所 / {
# ルート html;
# インデックス index.html index.htm;
# }
#}
# HTTPSサーバー
#
#サーバー{
# 443 ssl をリッスンします。
# サーバー名 ローカルホスト;
# ssl_証明書 cert.pem;
# ssl_certificate_key cert.key;
# ssl_session_cache 共有:SSL:1m;
# ssl_session_timeout 5分;
# ssl_ciphers HIGH:!aNULL:!MD5;
# ssl_prefer_server_ciphers オン;
# の場所 / {
# ルート html;
# インデックス index.html index.htm;
# }
#}
}
