Nginx設定ファイルの詳しい説明

Nginx 設定ファイルの詳細な説明

user nginx ;

#ユーザー

worker_processes 8;

#ワーカープロセス、以下に従って調整ハードウェアに、cpuコア番号

以上 error_log logs/nginx_error.log crit;

#エラーログ

pid logs/nginx.pid;

#pidプレースメント

worker_rlimit_nofile 204800;

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

このコマンドは、ng inxプロセス開くことができる理論値は、開いているファイルの最大数

(ulimit -n) を nginx の数で割った値になります。 プロセスを実行しますが、nginx リクエストの分散はそれほど均等ではないため、ulimit を使用するのが最善です -n の値は一貫したままです。

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

これは、nginxプロセスへのリクエストの分散がスケジュール中にあまりバランスが取れていないためです。 10240 , 合計同時実行数がに達すると、プロセスは10240を超える可能性があります。 エラーが返されます。 。

イベント

{

の

I/O

Model

追加メモ

: と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+ (イベントポート)、IRIX 6.5.15+ および Tru64 UNIX 5.1A+。

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

worker_connections 204800;

# ワーカープロセスの最大接続数はハードウェアに応じて調整され、前のワーカープロセスと組み合わせて使用​​されます。できるだけ大きくしますが、は使用しないでください。CPUを100%まで実行してください

プロセスごとに許可される接続数理論的には、nginxごとに最大サーバー接続数はworker_processes*worker_connections

keepalive_timeout 60;

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

client_header_buffer_size 4k;

クライアントリクエストヘッダー バッファーサイズ、これはシステムのページング サイズに応じて設定できます。通常、リクエスト ヘッダーのサイズは 1k を超えませんが、一般的なシステム ページングは​​ 1k より大きいため、これはページング サイズに設定されます。

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

[root@web001 ~]# getconf PAGESIZE

4096

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

open_file_cache max=65535 inactive=60s;

これは、開いているファイルのキャッシュを指定します。max は、開いているファイルの数と一致するように指定します。 は、ファイルが要求されなくなってからキャッシュを削除するまでの時間を指します。

open_file_cache_valid 80年代;

これはどれくらいの期間を意味しますか? キャッシュされた情報を毎回確認します。

open_file_cache_min_uses 1;

open_file_cache

コマンドの は、パラメーター時間内でのファイルの最小使用回数です。上記と同様に、ファイル記述子は常にキャッシュ内で開かれます。たとえば、 inactiveにファイルがある場合、時間内に一度も使用されなかった場合、そのファイルは削除されます。

) http

サーバーをセットアップし、その逆を利用するプロキシ機能が負荷分散サポートを提供します

http

{

mime.typesを含める;

#設定

mime type

、 type by

m ime.type ファイル定義

default_type application/octet-stream; log_format main '$host $status [$time_local] $remote_addr [$time_local] $request_uri '

'"$http_referer" "$http_user_agent" _x_forwarded_for" '

'$bytes_sent $ request_time $sent_http_x_cache_hit';

log_format log404 '$status [$time_local] $remote_addr $host $request_uri $sent_http_location';

$remote_addr

with

$http_x_ forwarded_forは、クライアントの

を記録するために使用されますip

アドレス; $remote_user: クライアントのユーザー名を記録するために使用されます。 $time_local: アクセス時刻とタイムゾーンを記録するために使用されます リクエストの記録に使用される

url

および http プロトコル。

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

、

$body_bytes_s ent : ファイルのメインコンテンツを記録しますクライアントに送信されます サイズ $http_referer: そのページからアクセスされたリンクを記録するために使用されます。

$http_user_agent

: 顧客のブラウザの関連情報を記録します。通常、サーバーはリバースプロキシの背後に配置されているため、顧客のIPを取得できません。 アドレスは

$remote_add

を通じて取得されます。 IP アドレス は、リバース プロキシ サーバー iP

です。 住所。リバース プロキシ サーバーは、転送されたリクエストの

ヘッダー情報に x_forwarded_for 情報を追加して、元のクライアントの

IP

アドレスとオリジナルサーバークライアントによって要求されたアドレス; access_log /dev/null; Usedlog_format

コマンドでログ形式を設定した後、access_ログ

ログファイルの保存パスを指定するコマンド# access_log /usr/local/nginx/ logs /access_log main; server_names_hash_bucket_size 128;

#サーバー名を保持するhashテーブルは、ディレクティブservernames_hash_max_sizeによって作成されますserver_names_hash_bucket_sizeによって制御されます。パラメータハッシュ バケット サイズ は常に hash テーブルのサイズと等しく、プロセッサ キャッシュ サイズの倍数です。メモリ内のアクセス数を減らした後、プロセッサ内のhashテーブルのキー値の検索を高速化することができます。 ハッシュの場合 バケットサイズはプロセッサキャッシュのサイズと等しく、キーを検索する際のメモリ内の検索回数は最悪の場合2になります。 1 回目はストレージ ユニットのアドレスを決定し、2 回目はストレージ ユニット内のキーを見つけます。 価値。したがって、Nginxハッシュを増やす必要がある場合、 最大サイズ または ハッシュバケットサイズ のヒントを使用するには、最初に前のパラメータのサイズを大きくします。 client_header_buffer_size 4k;

これは、システムのページング サイズに応じて設定できます。通常、リクエストのヘッダー サイズは超えません。

1k

ですが、一般的なシステムのページングは​​1kより大きいため、ページングのサイズはここで設定されます。ページング サイズは、コマンド

getconf を使用して決定できます。 ページサイズ

を取得しました。 large_client_header_buffers 8 128k;

顧客リクエストヘッダーバッファサイズ

nginx

デフォルトの使用client_header_buffer_size

thisbuffer

header
の値を読み取る場合header大きすぎるので使用します設定が小さすぎる場合は、large_client_header_buffersを読み取ってくださいHTTP

header

/Cookie 大きすぎる 400 エラーnginxを報告します 400 bad requestリクエストがbufferを超える場合、報告されますHTTP 414Error(URI Too Long)nginx
最長の HTTP を受け入れます ヘッダーのサイズは の 1 つより大きくなければなりませんバッファ が大きい場合、400
HTTPエラーが報告されます(悪い リクエスト）。 open_file_cache max 102400

使用フィールド: http、サーバー、 location

このコマンドは、キャッシュが有効かどうかを指定します、 有効にすると、は次の情報をファイル

に記録します: ·開かれたファイル記述子

、サイズ情報と変更時間

。 ·既存のディレクトリ情報

。 ·ファイル検索中のエラーメッセージ--そのようなファイルはありません、を正しく読み取ることができません、 リファレンスopen_file_cache_errorsディレクティブオプション:·max -キャッシュの最大数を指定します、キャッシュがオーバーフローした場合は 、最長使用ファイル (LRU)は削除されます例: open_file_cache max=1000 inactive=20s; open_file_cache_min_uses 2; open_file_cache_errors オン;

open_file_cache_errors
構文:open_file_cache_errors オン | オフ デフォルト :open_file_cache_errors オフ 使用フィールド : http、サーバー、場所 このディレクティブは、ファイルの検索をログに記録するかどうかを指定します cacheerror

open_cache_min_uses

構文:open_file_cache_min_uses数値 デフォルト値: open_file_cache_min_uses 1 フィールドを使用します: http、サーバー、場所このディレクティブは、open_file_cacheディレクティブが無効ですファイルの数、など。 より大きな値を使用すると、 ファイル記述子が常に cache.open_file_c で開かれます。 ache_有効

構文

:open_file_cache_valid時間デフォルト値:open_file_cache_valid 60 使用フィールド: http、server、location このディレクティブは、open_file_cacheのキャッシュされたアイテムに関する有効な情報をいつチェックするかを指定します。

client_max_body_size 300m;

によって設定nginx

アップロードファイルサイズ

sendfile on;

コマンドは次のように指定しますnginx

を呼び出す必要があるかどうか sendfile

関数 (ゼロ) copy

メソッド) を出力ファイルに追加します。通常のアプリケーションの場合、 は on に設定する必要があります。 IOのダウンロードなどの高負荷アプリケーションにディスクが使用される場合、ディスクとネットワークIOの処理速度のバランスをとるためにオフに設定できます。システム 稼働時間を削減します。 tcp_nopush on;このオプションは、sockの使用を許可または禁止しますe

の TCP_CORK

オプション、このオプションは sendfile

proxy_connect_timeout を使用する場合にのみ使用されます; #

バックエンドサーバー接続タイムアウト _

ハンドシェイクを開始し、応答を待ちます タイムアウト

proxy_read_timeout 180; #成功後に接続する_

バックエンドサーバーの応答時間を待っています

_実際には、処理を待っているバックエンドキューに入っています（バックエンドサーバーが応答を待つのにかかる時間とも言えます）リクエストを処理します)

proxy_send_timeout 180;#バックエンドサーバーのデータ返却時間_

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

proxy_buffer_size 256k;

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

proxy_buffers 4 256k;

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

proxy_busy_buffers_size 256k;

proxy_temp_file_write_size 256k;

# ファイル転送時にワーカープロセスが長時間ブロックされないように

proxy_temp_path proxy_temp_パス /data0 /proxy_temp_dir;

#proxy_temp_path

とproxy_cache_path

指定されたパスは同じパーティション内にある必要があります proxy_cache_path /data0/proxy_cache_dir レベル=1:2 キーゾーン =cache_one :200m 非アクティブ = 1 日 max_size=30g;#メモリキャッシュスペースサイズを200MB、
1に設定します 数日間アクセスされていないコンテンツは、ハードドライブから自動的に消去されます。キャッシュスペースのサイズは30GBです。 keepalive_timeout 120;

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

tcp_nodelay on;

client_body_buffer_size 512k;

256kなど、より大きな値に設定した場合🎙

の写真はすべて正常です。このディレクティブがコメントアウトされている場合、デフォルトの client_body_buffer_size
設定が使用されます。これは、オペレーティング システムのページ サイズの 2 倍、8k または 16k 、質問が現れました。 firefox4.0またはIE8.0のどちらを使用する場合でも、より大きなもの、200kを送信してください 周りの写真は返品しました 500 内部サーバーエラーエラーproxy_intercept_errors on; nginxをブロックHTTPにする手段 レスポンスコードは400以上です。 img_relay

{

サーバー127.0 .0.1:8027;

サーバー127.0.0.1:8028; サーバー127.0.0.1:8029;

ハッシュ$ request_uri;

}

nginx

のアップストリーム

は現在4をサポートしています配布方法

1 、ポーリング (デフォルト)

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

2、weight
ポーリング確率、weightを指定し、アクセスします比率 不均一なパフォーマンスの場合、バックエンド サーバーに比例します。 例:
アップストリームベイクエンド{
server 192.168.0.14weight=10;
server 192.168.0.15weight=10;
}

2 、ip_hash
各リクエストはipの結果に従って割り当てられるため、各訪問者は解決できるバックエンドサーバーへの固定アクセス権を持ちます セッション 問題。 例: アップストリームベイクエンド{ip_hash;
server 192.168.0.14:88;
server 192.168.0.15:80;
}

3

、fair (サードパーティ) リクエストはバックエンドサーバーの応答時間に応じて割り当てられ、応答時間の短いリクエストが最初に割り当てられます。 アップストリーム バックエンド {サーバー サーバー1;
サーバー サーバー2;
フェア;
}

4

、url_hash (サードパーティ)

url の結果にアクセスして、各

url に送信されます。同じバックエンドサーバーであれば、より効果的ですバックエンドサーバーがキャッシュされるとき。 例: hashステートメント、

serverを

upstreamに追加明細書には記載できません体重他のパラメータについては、hash_methodはhashアルゴリズムアップストリームバックエンド{サーバーイカ1:3128;サーバーイカ2: 3128 ;

hash $request_uri;hash_method crc32;

}


ヒント:

アップストリームベイクエンド{#

ロードバランシングデバイスのIp

とデバイスステータスを定義しますip_hash;

server 127.0.0.1:9090 down;server 127.0.0.1:8080 Weight=2 ; サーバー 127.0.0.1:6060;サーバー 127.0.0.1:7070 バックアップ;}

を使用する必要がある
サーバー
に
を追加しました負荷分散 proxy_pass http:/ /bakend /;

各デバイスのステータスはに設定されます:
1.downは前の

serverを意味します

は一時的に参加していません荷物の 2.weight
デフォルトは 1.weight 大きいほど荷物の重量が大きくなります。 3.max_fails
: 許可されるリクエスト失敗回数のデフォルトは1です。最大回数を超えると、モジュールによって定義されたproxy_next_upstreamエラーが返されます。
4.fail_timeout: max_fails 回の失敗後の一時停止時間。 5.backup: バックアップ
以外のすべてのマシンダウンの場合、またはビジー状態の場合は、
バックアップをリクエストしてください。 マシン。したがって、このマシンの圧力は最も少なくなります。 nginxは、未使用のサーバー

で使用するために、同時に複数の負荷分散グループを設定することをサポートしています。

client_body_in_file_onlyはオンに設定されていますは話すことができますクライアント postのデータをdebug
client_body_temp_pathのファイルに記録する 記録ファイルのディレクトリを3レイヤーディレクトリ

まで設定できます。

locationはURLと一致します。はリダイレクトまたは新しいプロキシを作成できます 負荷分散

サーバー

#仮想マシンを構成する

{

80を聞いてください;

#リスニングポートを構成する

server_name image.***.com;

#アクセスドメイン名を設定する

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

# for "mp3 または exe" で終わるアドレスは負荷分散に使用されます

proxy_pass http://img_relay$request_uri;

#セットプロキシされるポートまたはソケット、および URL

proxy_set_header Host $host;

proxy_set_header

# 上記3行の目的は、プロキシサーバーが受け取ったユーザー情報をリアルサーバーに送信することです

}

location /face {

if ($http_user_agent ~* "xnp") {

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

}

proxy_pass http://img_relay$request_uri;

proxy_set_header ホスト $host;

proxy_set_header X-Real-IP $remote_addr ;

pro xy_set_header error_page 404 502 = @fetch;

}

location @fetch {

access_log /data/logs/ face.log log404;

#

このサーバーのアクセスログを設定します

書き直し^( .* )$ http://211.151.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 ホスト $host;

proxy_set_header X-Real-IP $remote_addr;

proxy_set_header X-Forwarded-For $ proxy_add_x_forwarded_for;

error_page 404 502 = @fetch;

}

location @fetch {

access_log /data/logs/image.log log404;

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

}

}

サーバー

{

80を聞いてください;

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

location ~* |exe)$ {

proxy_pass http://img_relay$request_uri;

プロキシ_set_header ホスト $host;

proxy_set_header X-Real-IP $remote_addr;

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for ;

}

location / {

if ($http_user_agent ~* "xnp") {

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

}

proxy_pass http://img_relay$request_uri;

proxy_set_header ホスト $host;

proxy_set_header X-Real-IP $remote_addr;

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

#error _404 ページ http://i1.***img.com/help/ noimg.gif;

error_page 404 502 = @fetch;

}

場所@ fetch {

access_log /data/logs/baijiaqi.log log404;

rewrite ^ (.*)$ http://i1. ***img.com/help/noimg.gif リダイレクト;

}

#access_log off;

}

サーバー

{

80を聞いてください;

server_name *.***img.com;

location ~* .(mp3|exe)$ {

proxy_pass http://img_relay$request_uri;

proxy_set_header ホスト $host;

proxy_set_header X-Real-IP $remote_addr;

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

}

location / {

if ($http_user_agent ~* "xnp") {

書き換えます^(.*)$ http://i1.***img.com/help/noimg.gif;

}

proxy_pass http://img_relay$request_uri;

proxy_set_header ホスト $host;

proxy_set_header X-Real-IP $remote_addr;

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

#error_page 404 http://i1.***img.com/help/noimg.gif;

error_page 404 = @fetch;

}

#access_log off;

location @fetch {

access_log /data/logs/baijiaqi.log log404;

リライト^(.*)$ http://i1.***im g. com/help/noimg.gif リダイレクト;

}

}

サーバー

{

8080を聞いてください;

server_name ngx-ha.***img.com;

location / {

stub_status オン;

access_log off;

}

}

サーバー{

80を聞く;

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

root html;

}

サーバー{

80を聞く;

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

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

location / {

http ：//www. ***.com/ ;

}

}

サーバー{

80を聞いてください;

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

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

location / {

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

}

}

サーバー{

80を聞いてください;

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

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

location / {

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

}

}

場所 /NginxStatus {
stub_status on;
access_log on;
auth_basic "NginxStatus";
auth_basic_user_file conf/htpasswd;
}

#設定監視Nginx状態の地址

場所 ~ /.ht {
すべて拒否;
}

#禁止访问.htxxx 文件

}

注释：变量

Ngx_http_core_module モ块サポート内置变量、他们的名字和apache の内部量は一致しています。

中の行程、例:

$http_user_agent,$http_cookie等。いくつかの变量 $argsこの量と请要求実行中のパラメータ相等

$content_length

等请求行の「」

Content_Length”の値。 等と请求头部の”

Content_Type”

の值$document_root等要求された

root

命令指定的值$document_uri与

$uri

一样

$hostは、リクエストヘッダーの値または リクエスト到着するサーバーの名前 (ホストは除く) OK)同じ $limit_rate

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

$request_method

は

リクエストと同等ですメソッドの、通常は「GET」 または「投稿」 $remote_addr

クライアント

ip $remote_port

クライアント

port$remote_user

は、次のように表されるユーザー名に相当します。

ngx_http_auth_basic_module認証 $request_filename

現在リクエストされているファイルのパス名 (

) ルート または エイリアスとURI request結合$request_body_file

$request_uri

にはパラメータが含まれていますイニシャル

URI$query_string

with

$args同じ ~ ) 次のようなすべての要件が評価されます。 requestへ、「

HTTP/

」または「」を使用HTTP/ $server_addrリクエスト

が到着しました

server

ip、一般的に取得される値の目的この変数はシステムコールを行うためのものです。システムコールを回避するには、ディレクティブにipを指定し、を使用する必要があります。 バインド パラメーター。

$server_nameリクエストが到着したサーバー名 $server_port request 到着サーバーのポート番号

$uriは、現在のrequestのと同等ですウリ、はい 内部的にリダイレクトする場合や

を使用する場合など、初期値とは異なります

nginx 中文Wikipedia

http://wiki.nginx.org/NginxChs

http://www.queryer.cn/DOC/nginxCHS/index.html 上記では、Nginx 設定ファイルの詳細な説明を、関連する内容も含めて紹介しています。PHP チュートリアルに興味のある友人に役立つことを願っています。