Nginx設定ファイル(nginx.conf)の設定詳細

Nginxの設定ファイルnginx.confは、以下のように詳細に設定されています。

ユーザー nginx nginx ;

Nginxのユーザーとグループ：ユーザーグループ。ウィンドウが指定されていません。

worker_processes 8;

worker_processes: 数値。ハードウェアによりますが、通常はCPUの数と同じか、CPUの数の2倍です。

error_log logs/error.log。  

error_log logs/error.logのお知らせです。  

error_log logs/error.log info;  

エラーログ：ストアへのパス。

pid logs/nginx.pid。

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

worker_rlimit_nofile 204800 です。

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

このディレクティブは、nginx プロセスがオープンされているときに開くことができるファイル記述子の最大数を指します。理論的には、開いているファイルの最大数 (ulimit -n) を nginx プロセスの数で割った値になるはずですが、nginx の割り当て要求はそれほど均等ではないので、ulimit -n と値を一致させておくとよいでしょう。

linux 2.6 ではオープンファイルの数が 65535 になっているので、それに合わせて worker_rlimit_nofile も 65535 にしてください。

これは、nginx がスケジューリング時にリクエストをバランスよくプロセスに割り当てないためで、10240 と記入すると、総コンカレント数が3～4万になったときに一部のプロセスが10240を超えてしまい、502エラーが返されます。

イベント

{ <未定義

epollを使用します。

linuxはepollを、FreeBSDはkqueueを推奨、windowは指定なし。

追加メモです。

apache と同様、nginx は OS によってイベントモデルが異なります。

<スパン A) 標準的なイベントモデル

select と poll は標準的なイベントモデルの一部であり、nginx は現在のシステムでより効率的な方法が存在しない場合、select か poll を選択します。

B) 効率的なイベントモデル

Kqueue。FreeBSD 4.1+, OpenBSD 2.9+, NetBSD 2.0, MacOS X で使用されています。デュアルプロセッサの MacOS X システムで kqueue を使用すると、カーネルがクラッシュすることがあります。

エポール 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を超えることはありませんが、一般的なシステムのページングは1kより大きいので、ここではページングサイズに設定されています。

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

[ルート@web001 ~]# getconf PAGESIZE

4096

ただし、client_header_buffer_sizeが4kを超える場合がありますが、client_header_buffer_sizeには"system paging size"の整数倍を設定する必要があります。

open_file_cache max=65535 inactive=60s;

max はキャッシュの数を指定しますが、オープンファイルの数と同じにすることを推奨します。また、inactive は、ファイルが要求されなかった後にキャッシュを削除するのにかかる時間を指します。

open_file_cache_valid 80s;

これは、有効な情報があるかどうかキャッシュをチェックする頻度を指します。

open_file_cache_min_uses 1;

open_file_cache指示文のinactiveパラメータ時間における、ファイルの最小使用回数です。この数値を超えると、上の例のように、ファイルディスクリプタは常にキャッシュで開かれ、非活動時間内に一度もファイルが使用されないと、削除されるようになります。

}

## httpサーバーのリバースプロキシ機能を使って、負荷分散をサポートするように設定します。

http

{ <未定義

mime.typesをインクルードします。

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

default_type application/octet-stream;

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

'$status $body_bytes_sent "$http_referer" '

'"$http_user_agent" "$http_x_forwarded_for" ';

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

ログフォーマットの設定。

クライアントのIPアドレスを記録するための $remote_addr と $http_x_forwarded_for を指定します。

$remote_user: クライアントのユーザー名を記録するために使用されます。

time_local: アクセス時刻とタイムゾーンを記録するために使用されます。

$request: リクエストのURLとhttpプロトコルを記録するために使用されます。

status: リクエストのステータスを記録するために使用します; 成功は 200

$body_bytes_sent : クライアントに送信されたファイルのボディコンテンツのサイズを記録するため。

$http_referer: そのページリンクからの訪問を記録するため。

$http_user_agent: クライアントのブラウザに関する情報を記録します。

通常、ウェブサーバはリバースプロキシの背後に置かれ、クライアントのIPアドレスを取得できないようになっています。remote_addで取得したIPアドレスは、リバースプロキシサーバのiPアドレスになります。リバースプロキシサーバは、転送されたリクエストの http ヘッダに x_forwarded_for 情報を追加して、元のクライアントの IP アドレスと、元のクライアントのリクエストのサーバアドレスを記録することができます。

access_log logs/host.access.log main;

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

log_format ディレクティブでログのフォーマットを設定した後、 access_log ディレクティブでログファイルへのパスを指定する必要があります。 は、その

server_names_hash_bucket_size 128です。

サーバ名を保持する #hash テーブルは、ディレクティブ server_names_hash_max_size と server_names_hash_bucket_size で制御します。パラメータのハッシュバケットサイズは常にハッシュテーブルのサイズと等しく、 プロセッサキャッシュサイズの倍数であることを終始一貫して示します。これにより、メモリへのアクセス回数を減らした上で、プロセッサでのハッシュテーブルのキーのルックアップを高速化することができる。ハッシュバケットのサイズがプロセッサキャッシュのサイズと等しい場合、キーを検索する際のメモリでのルックアップ回数は最悪2回となる。1回目はメモリセルのアドレスを決定すること、2回目はメモリセル内のキー値を検索することである。したがって、Nginx がハッシュの最大サイズやハッシュバケットのサイズを大きくする必要があるというヒントを出した場合、まず優先されるのは直前の引数のサイズを大きくすることです。

client_header_buffer_size 4k;

クライアントリクエストヘッダーのバッファサイズです。これはシステムのページングサイズに応じて設定できます。一般にリクエストのヘッダーサイズは1kを超えることはありませんが、一般的なシステムのページングは1kより大きいので、ここではページングサイズに設定されています。ページングサイズは、getconf PAGESIZEコマンドで取得することができます。

large_client_header_buffers 8 128kです。

クライアントリクエストのヘッダーバッファーのサイズ。

ヘッダが大きすぎる場合、large_client_header_buffers を使用して読み取ります。

open_file_cache max=102400 inactive=20s;

このディレクティブは、キャッシュを有効にするかどうかを指定します。
例  open_file_cache max=1000 inactive=20s; 

open_file_cache_valid 30s; 

open_file_cache_min_uses 2; 

open_file_cache_errors をオンにします。

open_file_cache_errors
Syntax:open_file_cache_errors on | off Default:open_file_cache_errors off Use fields:http, server, location このディレクティブは、ファイル検索時にキャッシュエラーを記録するかどうかを設定します。

オープンファイル キャッシュの最小使用数

Syntax: open_file_cache_min_uses number Default: open_file_cache_min_uses 1 Used fields: http, server, location open_file_cache 指令の無効なパラメータに対して、ある時間内に使用できる最小のファイル数を指定する。これより大きな値を指定すると、ファイルディスクリプタは常にキャッシュで開かれることになります。
open_file_cache_valid

Syntax:open_file_cache_valid time Default:open_file_cache_valid 60 Used fields:http, server, location このディレクティブは、open_file_cache にキャッシュされたアイテムの有効情報をいつ確認するかを指定し ます。

client_max_body_size 300m;

でclient_max_body_sizeのサイズを設定します。 nginx アップロードファイルのサイズ

sendfile をオンにします。

sendfile ディレクティブは、nginx が sendfile 関数（ゼロコピー方式）を呼び出してファイルを出力するかどうかを指定します。通常のアプリケーションでは on、ダウンロードなどディスク IO の負荷が高いアプリケーションでは off に設定し、ディスクとネットワークの IO 処理速度をバランスさせてシステムのアップタイムを短縮する必要があります。

tcp_nopush をオンにします。

このオプションは、socke の TCP_CORK オプションの使用を許可または禁止するもので、sendfile を使用する場合にのみ使用されます。

proxy_connect_timeout 90です。 
バックエンドサーバの接続タイムアウト_ハンドシェイクを開始し、応答を待つまでのタイムアウト時間

proxy_read_timeout 180です。

接続に成功した後、_wait_for_backend_server_response_time_has_actually_entered_the_backend_queue_for_processing_（これは、バックエンド・サーバーがリクエストを処理する時間でもある）。

proxy_send_timeout 180 です。

backend_send_timeout は、バックエンドのサーバーが定義された時間内にすべてのデータを通過させなければならないことを意味します。

proxy_buffer_size 256k です。

プロキシサーバから読み込まれる、通常は小さなアンサーヘッダを含む最初の部分の バッファサイズを設定します。デフォルトではこの値は proxy_buffers ディレクティブで指定されたバッファのサイズですが、 もっと小さいサイズに設定することも可能です。

proxy_buffers 4 256kです。

(プロキシサーバからの) 応答を読み込むために使用するバッファの数とサイズを設定します。

proxy_busy_buffers_size 256k;

proxy_temp_file_write_size 256k;

proxy_temp_path に書き込む際のデータサイズを設定し、ワーカープロセスがファイルを渡す際に長くブロックされるのを防ぎます。

proxy_temp_path /data0/proxy_temp_dir;

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

proxy_cache_path /data0/proxy_cache_dir levels=1:2 keys_zone=cache_one:200m inactive=1d max_size=30g;
# インメモリキャッシュスペースサイズを200MBに設定し、1日分の未アクセスコンテンツは自動的にクリアされ、ハードドライブキャッシュスペースサイズは30GBに設定されます。

keepalive_timeout 120です。

キープアライブタイムアウトを指定します。

tcp_nodelay をオンにします。

client_body_buffer_size 512kです。
もし、これを大きな値、例えば256kに設定すれば、FirefoxでもInternet Explorerでも、256kより小さい画像を投稿しても、問題なく動作するようになります。ディレクティブをコメントアウトして、OSのページサイズの2倍である8kまたは16kのデフォルトclient_buffer_sizeの設定を使用すると、問題が発生するのです。
firefox 4.0でもIE 8.0でも、200k前後の比較的大きな画像を送信すると、500 Internal Server Errorのエラーが返ってくる。

proxy_intercept_errors をオンにします。

アンサーコードが400以上のHTTPレスポンスをnginxにブロックさせることを示します。

アップストリーム <スパン バケンド <スパン { <未定義

サーバ 127.0.0.1:8027 に接続します。

サーバー127.0.0.1:8028。

サーバー127.0.0.1:8029。

ハッシュ $request_uri。

}

nginx のアップストリームは現在 4 種類のアロケーションをサポートしています。

<スパン 1.ポーリング(デフォルト)

各リクエストは時系列に1つずつ異なるバックエンドサーバーに割り当てられ、バックエンドサーバーがダウンした場合は自動的にカリングされることがあります。

2.重量
ポーリングレートを指定します。weightはアクセス比率に比例し、バックエンドサーバーの性能にばらつきがある場合に使用されます。
例
アップストリームバケンド { <未定義
サーバー 192.168.0.14 weight=10;
サーバー 192.168.0.15 weight=10;
}

2. ip_hash
各リクエストは、訪問したIPのハッシュ結果によって割り当てられ、各ビジターが1つのバックエンドサーバーを訪問するように固定され、セッションの問題を解決することができます。
<スパン 例
アップストリームバケンド { <未定義
ip_hash。
サーバー 192.168.0.14:88;
サーバー 192.168.0.15:80;
}

3.公正（サードパーティ）
バックエンドサーバーの応答時間に応じてリクエストが割り当てられ、応答時間の短いものから順に割り当てられます。
アップストリームバックエンド { <未定義
サーバーserver1です。
サーバーserver2です。
フェアを開催します。
}

4. url_hash（サードパーティ製）

アクセスしたURLのハッシュ結果によってリクエストを分散し、各URLが同じバックエンドサーバーに向かうようにする。バックエンドサーバーがキャッシュされている場合に有効である。

例：upstreamにhash文を追加、server文にはweightなど他のパラメータは書けない、hash_methodには使用するハッシュアルゴリズムを書く

アップストリームバックエンド { <未定義
サーバーsquid1:3128。
サーバーsquid2:3128。
ハッシュ $request_uri;
hash_method crc32;
}

のヒントがあります。

upstream bakend{#ロードバランサー装置のIPとデバイスの状態を定義します。 } { <未定義
ip_hash。
サーバー 127.0.0.1:9090 がダウンしています。
サーバー 127.0.0.1:8080 weight=2;
サーバー127.0.0.1:6060。
サーバー127.0.0.1:7070のバックアップです。
}
ロードバランシングを使用する必要があるサーバーに追加する
proxy_pass http://bakend/。

各デバイスの状態を:
1.ダウンとは、シングル前のサーバーが一時的に負荷に参加していないことを意味します
2.重量は大きければ大きいほど、負荷が大きくなる。
3. max_fails。失敗したリクエストの数 デフォルトは 1 です。最大数を超えた場合、proxy_next_upstream モジュールで定義されたエラーが返されます。
4. fail_timeout：max_failsが何回発生したら一時停止するかを指定します。
5.バックアップ バックアップマシンは、他の非バックアップマシンがすべてダウンしているかビジー状態であるときに要求されます。そのため、このマシンが最もストレスを感じないようになります。

nginx は、同時に複数のグループのロードバランシングを設定することをサポートしており、使用していないサーバーを使用することができます。

client_body_in_file_only を On に設定すると、デバッグ用にクライアントポストのデータをファイルに記録することができます。
client_body_temp_path は、ファイルが記録されるディレクトリを最大3階層まで設定します。

URLにマッチする場所を指定します。リダイレクトや新規プロキシも可能 ロードバランシングも可能

## 仮想マシンを設定する

サーバー

{ <未定義

は、80をリッスンしてください。

リスニングポートの設定

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

アクセスドメインの設定

location ~* \. (mp3|exe)$ { <未定義

mp3 または exe" で終わるアドレスのロードバランシングを行います。

proxy_pass http:// イメージリレー $request_uriを指定します。

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

proxy_set_header ホスト $host;

proxy_set_header X-Real-IP $remote_addr;

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

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

}

場所 /face { <未定義

if ($http_user_agent ~* "xnp") {。 <未定義

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

}

proxy_pass http:// イメージリレー $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;

}

場所 @fetch { <未定義

access_log /data/logs/face.log log404;

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

}

場所 /image { <未定義

if ($http_user_agent ~* "xnp") {。 <未定義

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

}

proxy_pass http:// イメージリレー $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;

}

場所 @fetch { <未定義

access_log /data/logs/image.log log404;

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

}

}

##その他の例

サーバー

{ <未定義

は、80をリッスンしてください。

server_name *. ***.com *. ***.cn;

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;

}

場所 / { <未定義

if ($http_user_agent ~* "xnp") {。 <未定義

rewrite ^(. *)$ 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 502 = @fetch;

}

場所 @fetch { <未定義

access_log /data/logs/baijiaqi.log log404;

rewrite ^(. *)$ http://i1.****img.com/help/noimg.gif リダイレクトしてください。

}

}

サーバー

{ <未定義

は、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;

}

場所 / { <未定義

if ($http_user_agent ~* "xnp") {。 <未定義

rewrite ^(. *)$ 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 を実行します。

場所 @fetch { <未定義

access_log /data/logs/baijiaqi.log log404;

rewrite ^(. *)$ http://i1.****img.com/help/noimg.gif リダイレクトしてください。

}

}

サーバー

{ <未定義

8080をリッスンしてください。

サーバー名 ngx-ha.****img.com;

場所 / { <未定義

stub_status をオンにします。

access_logをオフにします。

}

}

サーバー <未定義

は80をリッスンしてください。

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

のルートhtmlです。

}

サーバー <未定義

は80をリッスンしてください。

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

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

場所 / { <未定義

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

}

}

サーバー <未定義

は80をリッスンしてください。

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

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

場所 / { <未定義

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

}

}

サーバー <未定義

は80をリッスンしてください。

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

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

場所 / { <未定義

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

}

}

場所 /NginxStatus { <未定義
stub_status をオンにします。
access_logをオンにします。
auth_basic "NginxStatus"。
auth_basic_user_file conf/htpasswd;
}

# Nginxの状態を見るためのアドレスを設定します。

location ~ /³³.ht {. <未定義
をすべて拒否します。
}

#.htxxx ファイルへのアクセスをブロックします。

}

注：変数

Ngx_http_core_module モジュールは組み込み変数をサポートしており、 その名前は apache の組み込み変数と同じです。

1つ目は、$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" となります。

リモートアドレスのクライアントIP

リモートポートクライアントポート

リモートユーザは、 ngx_http_auth_basic_module で認証されたユーザ名と同じです。

$request_filename 現在リクエストされているファイルのパス名、ルートまたはエイリアスとURIリクエストの組み合わせ

$request_body_file

パラメータを含む$request_uriの完全な初期URI

query_string は $args と同じです。

リクエストに含まれる$sheeme httpスキーマ(http,https)が評価される例です。

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

server_protocol はリクエストのプロトコルと同等で、 "HTTP/ または "HTTP/ を使用します。

$server_addr リクエストが到着したサーバーのip。一般に、この変数の値を取得する目的は、システムコール を行うことである。システムコールを避けるためには、listen ディレクティブで ip を指定し、 bind パラメータを使用する必要があります。

server_name が到達することを要求するサーバー名

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

uri は現在のリクエストの URI と同じで、内部でリダイレクトするときやインデックスを使うときなど、初期値とは異なる値になります。