コア機能

user www www;
worker_processes 2;

error_log /var/log/nginx-error.log info;

events {
    use kqueue;
    worker_connections 2048;
}

...

accept_mutex off;

accept_mutex が有効な場合、ワーカープロセスは順番に新しい接続を受け入れます。それ以外の場合は、すべてのワーカープロセスに新しい接続が通知され、新しい接続の量が低い場合、一部のワーカープロセスはシステムリソースを無駄にする可能性があります。

EPOLLEXCLUSIVE フラグ (1.11.3) をサポートするシステム上、または reuseport を使用している場合は、accept_mutex を有効にする必要はありません。

バージョン 1.11.3 より前は、デフォルト値は on でした。

accept_mutex_delay 500ms;

accept_mutex が有効な場合、別のワーカープロセスが現在新しい接続を受け入れている場合に、ワーカープロセスが新しい接続の受け入れを再開しようとする最大時間を指定します。

daemon on;

nginx がデーモンになるかどうかを決定します。主に開発中に使用されます。

選択されたクライアント接続のデバッグログを有効にします。その他の接続は、error_log ディレクティブで設定されたログレベルを使用します。デバッグされる接続は、IPv4 または IPv6 (1.3.0、1.2.1) アドレスまたはネットワークで指定されます。接続はホスト名を使用して指定することもできます。UNIX ドメインソケット (1.3.0、1.2.1) を使用する接続の場合、「unix:」パラメーターでデバッグログが有効になります。

events {
    debug_connection 127.0.0.1;
    debug_connection localhost;
    debug_connection 192.0.2.0/24;
    debug_connection ::1;
    debug_connection 2001:0db8::/32;
    debug_connection unix:;
    ...
}

このディレクティブを機能させるには、nginx を --with-debug でビルドする必要があります。「デバッグログ」を参照してください。

このディレクティブはデバッグに使用されます。

内部エラーが検出された場合（たとえば、ワーキングプロセスの再起動時のソケットのリーク）、debug_points を有効にすると、コアファイルの作成 (abort) またはプロセスの停止 (stop) が行われ、システムデバッガーを使用してさらに分析されます。

env TZ;

デフォルトでは、nginx は親プロセスから継承された環境変数をすべて削除します（TZ 変数を除く）。このディレクティブを使用すると、継承された変数のいくつかを保持したり、値を変更したり、新しい環境変数を追加したりできます。これらの変数は次に

• 実行ファイルのライブアップグレード中に継承されます。
• ngx_http_perl_module モジュールで使用されます。
• ワーカープロセスで使用されます。この方法でシステムライブラリを制御することは常に可能とは限りません。ライブラリは初期化時にのみ変数をチェックすることが一般的であり、このディレクティブを使用して設定できるずっと前にチェックが行われるためです。例外は、上記の実行ファイルのライブアップグレードです。

TZ 変数は常に継承され、明示的に設定されていない限り、ngx_http_perl_module モジュールで使用できます。

使用例

env MALLOC_OPTIONS;
env PERL5LIB=/data/site/modules;
env OPENSSL_ALLOW_PROXY_CERTS=1;

NGINX 環境変数は nginx によって内部的に使用され、ユーザーが直接設定することはできません。

error_log logs/error.log error;

ロギングを設定します。同じ設定レベルで複数のログを指定できます (1.5.2)。main 設定レベルでファイルへのログ書き込みが明示的に定義されていない場合、デフォルトファイルが使用されます。

最初の引数は、ログを保存するファイルを定義します。特別な値stderrは標準エラーファイルを選択します。「syslog:」プレフィックスを指定することで、syslogへのロギングを設定できます。「memory:」プレフィックスとバッファサイズを指定することで、循環メモリバッファへのロギングを設定でき、一般的にデバッグに使用されます (1.7.11)。

2 番目の引数はロギングのレベルを決定し、debug、info、notice、warn、error、crit、alert、emerg のいずれかになります。ログレベルは重大度の昇順にリストされています。特定のログレベルを設定すると、指定されたログレベルとそれ以上の重大度のすべてのメッセージがログに記録されます。たとえば、デフォルトレベルのerrorは、error、crit、alert、emerg メッセージがログに記録されるようになります。この引数が省略された場合は、error が使用されます。

debug ロギングを機能させるには、nginx を --with-debug でビルドする必要があります。「デバッグログ」を参照してください。

このディレクティブは、バージョン 1.7.11 から stream レベルで、バージョン 1.9.0 から mail レベルで指定できます。

接続処理に影響するディレクティブが指定されている設定ファイルのコンテキストを提供します。

別のファイル、または指定されたマスクに一致するファイルを、設定に含めます。含まれるファイルは、構文的に正しいディレクティブとブロックで構成されている必要があります。

使用例

include mime.types;
include vhosts/*.conf;

動的モジュールをロードします。

例

load_module modules/ngx_mail_module.so;

lock_file logs/nginx.lock;

nginx はロックメカニズムを使用して accept_mutex を実装し、共有メモリへのアクセスを直列化します。ほとんどのシステムでは、ロックはアトミック演算を使用して実装され、このディレクティブは無視されます。その他のシステムでは、「ロックファイル」メカニズムが使用されます。このディレクティブは、ロックファイル名のプレフィックスを指定します。

master_process on;

ワーカープロセスが開始されるかどうかを決定します。このディレクティブは nginx 開発者向けです。

multi_accept off;

multi_accept が無効な場合、ワーカープロセスは一度に 1 つの新しい接続を受け入れます。それ以外の場合は、ワーカープロセスは一度にすべての新しい接続を受け入れます。

kqueue 接続処理方法が使用されている場合、このディレクティブは無視されます。これは、受け入れ待ちの新しい接続数を報告するためです。

pcre_jit off;

設定解析時に認識されている正規表現に対して「Just-In-Time コンパイル」(PCRE JIT) の使用を有効または無効にします。

PCRE JIT は、正規表現の処理速度を大幅に向上させることができます。

JIT は、--enable-jit 設定パラメーターでビルドされたバージョン 8.20 以降の PCRE ライブラリで使用できます。PCRE ライブラリが nginx (--with-pcre=) でビルドされている場合、JIT サポートは --with-pcre-jit 設定パラメーターで有効になります。

pid logs/nginx.pid;

メインプロセスのプロセスIDを保存するファイルを定義します。

ハードウェア SSL アクセラレータの名前を定義します。

thread_pool default threads=32 max_queue=65536;

ワーカープロセスをブロックせずにファイルのマルチスレッド読み取りと送信に使用されるスレッドプールの名前とパラメーターを定義します。

threads パラメーターは、プール内のスレッド数を定義します。

プール内のすべてのスレッドがビジー状態の場合、新しいタスクはキューで待ちます。max_queue パラメーターは、キューで待機できるタスクの数を制限します。デフォルトでは、最大 65536 個のタスクがキューで待機できます。キューがオーバーフローすると、タスクはエラーで完了します。

ワーカープロセスでのタイマー解像度を下げ、gettimeofday() システムコールの回数を減らします。デフォルトでは、カーネルイベントが受信されるたびに gettimeofday() が呼び出されます。解像度を下げると、gettimeofday() は指定された間隔ごとに 1 回だけ呼び出されます。

例

timer_resolution 100ms;

間隔の内部実装は、使用される方法によって異なります。

• kqueue が使用されている場合、EVFILT_TIMER フィルター。
• eventport が使用されている場合、timer_create()。
• それ以外の場合は、setitimer()。

使用する接続処理メソッドを指定します。nginx はデフォルトで最も効率的なメソッドを使用するため、通常は明示的に指定する必要はありません。

user nobody nobody;

ワーカープロセスで使用されるユーザーとグループのクレデンシャルを定義します。グループが省略された場合、ユーザーと同じ名前のグループが使用されます。

worker_aio_requests 32;

aio を epoll 接続処理方法で使用する場合、単一のワーカープロセスに対する未処理の非同期 I/O 操作の最大数を設定します。

worker_connections 512;

ワーカープロセスで開くことができる同時接続の最大数を設定します。

この数値には、すべての接続（たとえば、プロキシされたサーバーとの接続など）が含まれ、クライアントとの接続のみが含まれるわけではないことに注意してください。もう 1 つの考慮事項として、実際の同時接続数は、worker_rlimit_nofile で変更できる、開いているファイルの最大数の現在の制限を超えることはできません。

ワーカープロセスをCPUセットにバインドします。各CPUセットは、許可されるCPUのビットマスクで表されます。各ワーカープロセスに対して個別のセットを定義する必要があります。デフォルトでは、ワーカープロセスは特定のCPUにバインドされません。

たとえば、

worker_processes    4;
worker_cpu_affinity 0001 0010 0100 1000;

各ワーカープロセスを個別のCPUにバインドしますが、

worker_processes    2;
worker_cpu_affinity 0101 1010;

最初のワーカープロセスをCPU0/CPU2に、2番目のワーカープロセスをCPU1/CPU3にバインドします。2番目の例は、ハイパースレッディングに適しています。

特別な値auto (1.9.10) を使用すると、利用可能なCPUにワーカープロセスを自動的にバインドできます。

worker_processes auto;
worker_cpu_affinity auto;

オプションのマスクパラメーターを使用して、自動バインディングに使用できるCPUを制限できます。

worker_cpu_affinity auto 01010101;

このディレクティブは、FreeBSDとLinuxでのみ使用できます。

worker_priority 0;

nice コマンドと同様に、ワーカープロセスのスケジューリング優先度を定義します。負の数は、優先度が高いことを意味します。許可される範囲は通常 -20 から 20 です。

例

worker_priority -10;

worker_processes 1;

ワーカープロセスの数を定義します。

最適な値は、CPUコアの数、データを格納するハードディスクドライブの数、ロードパターンなど、多くの要因によって異なります。疑問がある場合は、利用可能なCPUコアの数に設定することをお勧めします（値「auto」は自動検出を試みます）。

auto パラメーターは、バージョン 1.3.8 および 1.2.5 以降でサポートされています。

ワーカープロセスのコアファイルの最大サイズ (RLIMIT_CORE) の制限を変更します。メインプロセスを再起動せずに制限を増やすために使用します。

ワーカープロセスの最大オープンファイル数（RLIMIT_NOFILE）の制限を変更します。メインプロセスを再起動せずに制限を増やすために使用します。

ワーカープロセスのグレースフルシャットダウンのタイムアウトを設定します。timeが経過すると、nginxはシャットダウンを容易にするために現在開いているすべての接続を閉じようとします。

ワーカープロセスのカレントワーキングディレクトリを定義します。主にコアファイルの書き込みに使用され、その場合、ワーカープロセスは指定されたディレクトリに対する書き込み権限を持っている必要があります。