Nginx設定ファイル(nginx.conf)の構成の詳細説明

Nginx 設定ファイル nginx.conf 設定の詳細は次のとおりです:

ユーザー nginx nginx;

Nginx ユーザーとグループ: ユーザー グループ。ウィンドウ

worker_processes 8 では指定されていません。

ワーカー プロセス: 番号。ハードウェアの調整に応じて、通常は CPU の数と同じか、CPU の 2 倍になります。

error_log logs/error.log;

error_log logs/error.log 情報;

エラー ログ: ストレージ パス。

pid logs/nginx.pid;

pid (プロセス識別子): ストレージ パス。

worker_rlimit_nofile 204800;

プロセスが開くことができる記述子の最大数を指定します。

このコマンドは、nginx プロセスによって開かれるファイル記述子の最大数を指します。理論値は、開いているファイルの最大数 (ulimit -n) を nginx プロセスの数で割ったものである必要があります。 ulimit -n の値は一貫したままです。

現在、Linux 2.6 カーネルでは、開いているファイルの数は 65535 であり、worker_rlimit_nofile にはそれに応じて 65535 を入力する必要があります。

これは、nginx のスケジューリング中のプロセスへのリクエストの分散がそれほどバランスが取れていないためです。そのため、10240 を入力し、合計同時実行数が 30,000 ～ 40,000 に達すると、10240 を超えるプロセスが存在する可能性があり、502 エラーが返されます。

イベント

{

epoll を使用します。

epoll の I/O モデルを使用します。 Linux は epoll を推奨し、FreeBSD は kqueue を推奨しますが、window では指定されません。

追加説明:

Apacheと同様に、nginxにはオペレーティングシステムごとに異なるイベントモデルがあります

A)標準イベントモデル

標準イベントモデルに属する選択とポーリング 現在のシステムにこれ以上有効な方法がない場合、nginxは選択します。選択またはポーリング

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+ で使用されます。

イベントポート: Solaris 10 で使用されます。 カーネルクラッシュを防ぐためには、セキュリティパッチをインストールする必要があります。

worker_connections 204800;

ワーカー プロセスごとの最大接続数。ハードウェアに応じて調整し、前の作業プロセスと組み合わせて使用​​してください。ただし、CPU を 100% で実行しないでください。理論上、nginx サーバーあたりの最大接続数はプロセスごとに許可されます。 worker_processes*worker_connections

keepalive_timeout 60;

キープアライブ タイムアウト。

client_header_buffer_size 4k;

クライアントリクエストヘッダーのバッファサイズ。これは、システムのページング サイズに応じて設定できます。通常、リクエスト ヘッダーのサイズは 1k を超えることはありません。ただし、システムのページング サイズはここで設定されます。

ページング サイズは getconf PAGESIZE コマンドで取得できます。

[root@web001 ~]# getconf PAGESIZE

4096

ただし、client_header_buffer_size が 4k を超える場合もありますが、client_header_buffer_size の値は「システム ページング サイズ」の整数倍に設定する必要があります。

open_file_cache max=65535 inactive=60s;

これは、開いているファイルのキャッシュを指定します。最大値は、開いているファイルの数と一致するように指定します。キャッシュが要求されなかった場合、ファイルは削除されます。

open_file_cache_valid 80s;

これは、キャッシュされた有効な情報を確認する頻度を指します。

open_file_cache_min_uses 1; open_file_cache ディレクティブの非アクティブなパラメーター時間内でのファイルの最小使用回数。上記の例のように、ファイルがキャッシュ内で開かれます。非アクティブな時間内に一度使用されると、削除されます。

}

##http サーバーを設定し、そのリバース プロキシ機能を使用して負荷分散サポートを提供します

http

{

mime.types を含む

MIME タイプを設定します。タイプは mime.type ファイルによって定義されます

default_type application/オクテットストリーム;

log_format main '$remote_addr - $remote_user [$time_local] "$request" '

'$status $body_bytes_sent "$http_referer" '

'"$http_user_agent" "$http_x_forwarded_for"'; status [ $time_local ] $remote_addr $host$request_uri $sent_http_location';

ログ形式の設定。

$remote_addr と $http_x_forwarded_for はクライアントの IP アドレスを記録するために使用されます。

$remote_user: クライアントのユーザー名を記録するために使用されます。 URL と http プロトコル;

$status: リクエストのステータスを記録するために使用されます。成功は 200 です。

$body_bytes_sent: クライアントに送信されたファイルの本文のサイズを記録します。

$http_referer: アクセスされたページのリンクを記録するために使用されます。 from;

$http_user_agent: 顧客のブラウザに関する関連情報を記録します。

通常、Web サーバーはリバース プロキシの背後に配置されるため、$remote_add を通じて取得される IP アドレスはリバース プロキシの IP アドレスです。プロキシサーバー。リバース プロキシ サーバーは、転送されたリクエストの http ヘッダー情報に x_forwarded_for 情報を追加して、元のクライアントの IP アドレスと元のクライアントのリクエストのサーバー アドレスを記録できます。

access_log logs/host.access.log main;

access_log logs/host.access.404.log log404;

log_format ディレクティブを使用してログ形式を設定した後、access_log ディレクティブを使用して、ログ ファイル;

server_names_hash_bucket_size 128;

#サーバー名を保存するハッシュ テーブルは、server_names_hash_max_size およびserver_names_hash_bucket_size の命令によって制御されます。パラメータのハッシュ バケット サイズは常にハッシュ テーブルのサイズと等しく、プロセッサ キャッシュ サイズの倍数です。メモリ内のアクセス数を減らした後、プロセッサ内のハッシュ テーブルのキー値の検索を高速化することができます。ハッシュ バケット サイズがプロセッサ キャッシュのサイズと等しい場合、キーを検索するとき、メモリ内の検索回数は最悪の場合 2 回になります。 1 回目はストレージ ユニットのアドレスを決定し、2 回目はストレージ ユニット内のキー値を見つけます。したがって、Nginx がハッシュ最大サイズまたはハッシュ バケット サイズを増やす必要があるというプロンプトを表示した場合、最初に行うことは、前のパラメーターのサイズを増やすことです。

クライアント リクエスト ヘッダーのバッファ サイズです。これは、システムのページング サイズに応じて設定できます。通常、リクエストのヘッダー サイズは 1k を超えないため、ページング サイズはここで設定されます。ページング サイズは、getconf PAGESIZE コマンドで取得できます。

large_client_header_buffers 8 128k;

クライアントリクエストヘッダーバッファサイズ。デフォルトでは、nginx は client_header_buffer_size バッファーを使用してヘッダー値を読み取ります。ヘッダーが大きすぎる場合は、large_client_header_buffers を使用してそれを読み取ります。

open_file_cache max=102400 inactive=20s;

このディレクティブは、キャッシュが有効かどうかを指定します。

例: open_file_cache max=1000 inactive=20s;

open_file_cache_errors 2;
open_file_cache_errors on | off open_file_cache_errors off 使用フィールド: http、server、location このディレクティブは、次のいずれかを指定します。ファイル ログの検索のキャッシュ エラー

open_file_cache_min_uses

構文: open_file_cache_min_uses 数値 デフォルト値: open_file_cache_min_uses 1 使用フィールド: http、server、location このディレクティブは、無効なパラメーターで特定の時間範囲内で使用できるファイルの最小数を指定します。 open_file_cache ディレクティブ。より大きな値を使用すると、ファイル記述子は常にキャッシュ内で開かれます。

open_file_cache_valid time デフォルト値: open_file_cache_valid 60 使用フィールド: http、server、location このディレクティブは、open_file_cache でキャッシュがいつ開かれるかを指定します。プロジェクトの有効な情報を確認する必要があります。

client_max_body_size 300m;
nginx を通じてアップロードされるファイルのサイズを設定します。

sendfile コマンドは、nginx がファイルを出力するために sendfile 関数を呼び出すかどうかを指定します。通常のアプリケーションでは、オンに設定する必要があります。ダウンロードなどのディスク IO 負荷の高いアプリケーションに使用する場合は、オフに設定して、ディスクとネットワーク IO の処理速度のバランスをとり、システムの稼働時間を減らすことができます。

tcp_nopush on; このオプションは、sendfile の使用時にのみ使用されます。
proxy_read_timeout 180;成功した場合、バックエンド サーバーが応答するまでの待機時間は、実際に処理を待機しているバックエンド キューに入っています (バックエンド サーバーがリクエストを処理する時間とも言えます)

proxy_send_timeout 180;

バックエンドサーバーのデータ返却時間が指定されます。バックエンドサーバーは時間内にすべてのデータを送信する必要があります。

proxy_buffer_size 256k;

通常、プロキシサーバーから読み取られる応答の最初の部分のバッファサイズを設定します。デフォルトでは、この値のサイズは proxy_buffers ディレクティブで指定されたバッファーのサイズですが、より小さい値に設定できます

proxy_buffers 4 256k; 応答の読み取りに使用されるバッファーの数とサイズを設定します。 (プロキシサーバーから)、デフォルト 状況はページングサイズでもあり、オペレーティングシステムに応じて 4k または 8k になります

proxy_busy_buffers_size 256k;

proxy_temp_file_write_size 256k;

ワーカープロセスが書き込みを行わないように、データのサイズを設定しますファイルを渡すときのブロック時間が長すぎます
proxy_temp_path /data0 /proxy_temp_dir;

proxy_temp_path と proxy_cache_path で指定されたパスは同じパーティション内にある必要があります

proxy_cache_path /data0/proxy_cache_dir level=1:2keys_zone=cache_one:200m inactive=1d max_size=30g ;

#メモリ キャッシュ スペース サイズを 200MB に設定します。1 日は利用できません。アクセスされたコンテンツは自動的にクリアされ、ハードディスク キャッシュ スペースは 30GB になります。

keepalive_timeout 120;

キープアライブタイムアウト。

tcp_nolay on;

client_body_buffer_size 512k;

256k などの比較的大きな値に設定した場合、Firefox または IE ブラウザを使用して 256k より小さい画像を送信するのは通常のことです。このディレクティブをコメント アウトし、オペレーティング システムのページ サイズの 2 倍 (8k または 16k) であるデフォルトの client_body_buffer_size 設定を使用すると、問題が発生します。
firefox4.0 または IE8.0 を使用している場合でも、約 200k の比較的大きな画像を送信すると、500 内部サーバー エラーが返されます。

proxy_intercept_errors on; nginx が 400 以上の HTTP 応答コードで応答をブロックすることを示します。 Bupstream ベイクエンド {

Server 127.0.0.1:8028;

hash $Request_uri (デフォルト)

各リクエストは異なるバックエンド サーバーに割り当てられます。バックエンドサーバーがダウンした場合は、時系列で 1 つずつ削除できます。

2. Weight

ポーリング確率を指定します。重みはアクセス率に比例し、バックエンドサーバーのパフォーマンスが不均一な場合に使用されます。

例:

upstream bakend {

server 192.168.0.14weight=10;

server 192.168.0.15weight=10;

}

2. 各リクエストはアクセスされたIPのハッシュ結果に従って割り当てられるため、それぞれ訪問者は、バックエンド サーバーがセッションの問題を解決できる固定の 1 つにアクセスします。
例:
upstream bakend {
ip_hash;
server 192.168.0.14:88;
server 192.168.0.15:80;
}

3. フェア (サードパーティ)
の応答時間に従ってリクエストと応答時間を割り当てます。バックエンドサーバー 短いものが最初に割り当てられます。
アップストリーム バックエンド {
server server1;
server server2;
fair;
}
4. url_hash (サードパーティ)

各 URL が同じバックエンド サーバーに向けられるように、アクセスされた URL のハッシュ結果に従ってリクエストを分散します。バックエンド サーバーがキャッシュされている場合、より効果的です。
例: アップストリームにハッシュ ステートメントを追加します。サーバー ステートメントには重みなどの他のパラメーターを記述することはできません。 hash_method は使用されるハッシュ アルゴリズムです。
hash_method crc32;
}
ヒント:
アップストリーム bakend{#負荷分散デバイスの IP とデバイスのステータスを定義する}{
ip_hash;

server 127.0.0.1:9090 down;

server 127.0.0.1:8080 Weight=2;

server 127.0 .0.1:6060;

server 127.0.0.1:7070 Backup;
}
負荷分散を使用する必要があるサーバーに、
proxy_pass http://bakend/ を追加します
各デバイスのステータスは次のように設定されます。
1.down はシングルを意味します。前のサーバーは当分の間負荷に参加しません。

2.Weight は、重みが大きいほど負荷の重さが大きくなることを意味します。

3.max_fails: 許可されるリクエスト失敗の数のデフォルトは 1 です。最大数を超えると、proxy_next_upstream モジュールによって定義されたエラーが返されます。
4.fail_timeout: max_fails 失敗後の一時停止時間。
5.バックアップ: バックアップ以外の他のすべてのマシンがダウンしているかビジー状態の場合、バックアップ マシンを要求します。したがって、このマシンの圧力は最も少なくなります。
nginx は、未使用のサーバーで使用するために、負荷分散の複数のグループを同時にセットアップすることをサポートしています。

client_body_in_file_only は、デバッグ用にクライアントのポストからファイルに記録できます。
ディレクトリの場所は URL と一致するように設定できます。または、新しいプロキシ ロードを実行します。

##仮想マシンを構成します

{

listen 80;

リスニング ポートを構成します

server_name image.***.com;

アクセス ドメイン名を構成します

location ~* .(mp3|exe) )$ {

負荷分散のために「mp3 または exe」とペアリング

proxy_pass http://img_relay$request_uri;

プロキシ サーバーのポートまたはソケット、および URL を設定

proxy_set_header ホスト

proxy_set_header X-Real-IP; $remote_addr;

proxy_set_header リライト ^(.*)$ http://211.151.188.190:8080/face.jpg リダイレクト

}

proxy_set_header ホスト $host; -IP $remote_addr;

proxy_set_header .188.190:8080/face.jpg リダイレクト

}

location /image {

if ($http_user_agent ~* "xnp") {

rewrite ^(.*)$ http://211.151. 188.190:8080/face.jpg リダイレクト

}

proxy_pass http://img_relay$request_uri;

proxy_set_header X-Real-IP $remote_addr;

location @fetch;

アクセスログ/data/logs/image.log log404;

rewrite ^(.*)$ http://211.151.188.190:8080/face.jpg リダイレクト;

}

}

##その他の例

サーバー

{

listen 80;

サーバー名 *.***.com *.***.cn;

location ~* .(mp3|exe)$ {

proxy_pass http://img_relay$request_uri;

proxy_set_header ホスト $ host; -IP $remote_addr;

proxy_set_header //i1.***img.com/help/noimg.gif リダイレクト

}

proxy_set_header ホスト $host; $remote_addr;

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

error_page 404 502 = @fetch; {

access_log /data/logs /baijiaqi.log log404;

書き換え ^(.*)$ http://i1.***img.com/help/noimg.gif リダイレクト

}

}

サーバー

{

リッスン 80;

サーバー名 *.***img.com;

場所 ~* .(mp3|exe)$ {

proxy_set_header ホスト $host;

proxy_set_header X-Forwarded -$proxy_add_x_forwarded_for

}

location / {

if ($http_user_agent ~* "xnp") {

rewrite ^(.*)$ http://i1.***img.com /help/noimg.gif;

proxy_pass http://img_relay$request_uri;

proxy_set_header X-Real-IP $remote_addr;

error_page 404 = @fetch;

#access_log off;

access_log /data/logs/baijiaqi.log log404; http://i1.***img.com/ help/noimg.gif リダイレクト

}

}

server_name ngx-ha.***img.com

location / {

access_log off; {

サーバー名 imgsrc1.***.net;

サーバー {

サーバー名 ***.com

# access_log /usr/local /nginx/logs/access_log main;

location / {

rewrite ^(.*)$ http://www.***.com/

}

}

server {

server_name **** ***.com w.*******.com;

# access_log /usr/local/nginx/logs/access_log main;

書き換え ^(.*)$ http://www. *******.com/;

}

}

server {

server_name ******.com

# access_log / usr/local/nginx/logs/access_log main; / {

書き換え ^(.*)$ http://www.******.com/;

}

}

location /NginxStatus {

stub_status on;

access_log on;

auth_basic "NginxStatus";

auth_basic_user_file conf/htpasswd;

}

#Nginxステータスを表示するアドレスを設定します

location ~ /.ht {

すべてを拒否します;

}

#.htxxxファイルへのアクセスを無効にします

}

注: 変数

Ngx_http_core_moduleモジュールは、ビルドされた変数内にあり、その名前は Apache の組み込み変数と一致しています。

まず、$http_user_agent、$http_cookie など、顧客リクエストのタイトルの行について説明します。

さらに、他の変数もあります

$args この変数はリクエストラインのパラメータと等しくなります

$content_length はリクエストラインの「Content_Length」の値と等しくなります。

$content_type はリクエストヘッダーの「Content_Type」の値と等しい

$document_root は現在のリクエストの root ディレクティブで指定された値と等しい

$document_uri は $uri と同じ

$host はで指定された値リクエストヘッダーの「Host」行、またはリクエストによって到達したサーバーの名前と同じです (Host 行なし)

$limit_rate は制限された接続速度を許可します

$request_method は通常、リクエストのメソッドと同等です"GET" または "POST"

$remote_addr クライアント IP

$remote_port クライアント ポート

$remote_user は、ngx_http_auth_basic_module によって認証されたユーザー名と同等です

$request_filename ルートまたはエイリアスと URI リクエストで構成される、現在リクエストされているファイルのパス名

$request_body_file

$request_uri パラメータ

$query_string と $args を含む完全な初期 URI は、

$sheeme http モード (http、https) と同じです。たとえば、

Rewrite ^(.+)$ $sheme:/ です。 /example.com$; Redirect;

$server_protocol はリクエストのプロトコルに相当し、「HTTP/」または「HTTP/

$server_addr リクエストはこの変数の値を取得することが目的です。」システムコールを行うことです。システムコールを回避するには、listen コマンドで ip を指定し、bind パラメータを使用する必要があります。

$server_name リクエストが到着するサーバーの名前

$server_port リクエストが到着するサーバーのポート番号

$uri は現在のリクエストの URI に相当します。内部などの初期値とは異なる場合があります。リダイレクトまたはインデックスの使用