nginx

日本語ドキュメントについて

このドキュメントは nginx 公式サイトに記載されている英語ドキュメントを日本語に翻訳したものである。

はじめに

nginx [engine x] は、HTTP およびリバースプロキシサーバ、メールプロキシサーバ、汎用 TCP/UDP プロキシサーバで、元々は Igor Sysoev によって書かれたものです。長い間、Yandex, Mail.Ru, VK, Rambler を含む多くのロシアの高負荷サイトで動作していました。Netcraftによると、2020年5月の時点で、nginxは25.62%の最も忙しいサイトにサービスを提供またはプロキシしています。成功事例の一部をご紹介します。Dropbox、Netflix、Wordpress.com、FastMail.FM。

ソースとドキュメントは2項BSDライクなライセンスで配布されています。

商用サポートは Nginx, Inc.

基本的なHTTPサーバーの機能

静的ファイルとインデックスファイルのサーブ、自動インデックス化、オープンファイル記述子キャッシュ キャッシングによる高速化されたリバースプロキシ、負荷分散とフォールトトレランス。 FastCGI、uwsgi、SCGI、memcached サーバのキャッシュによる高速化サポート、負荷分散とフォールトトレランス。 モジュラーアーキテクチャ。フィルタには、gzipipping、バイト範囲、チャンク化された応答、XSLT、SSI、画像変換フィルタが含まれます。プロキシドサーバまたは FastCGI/uwsgi/SCGI サーバで処理される場合、単一ページ内の複数の SSI インクルードを並行して処理することができます。 SSLとTLS SNIをサポートしています。 重み付けと依存関係ベースの優先順位付けを備えたHTTP/2をサポートします。

その他のHTTPサーバーの機能

ネームベースおよびIPベースの仮想サーバー キープアライブおよびパイプライン接続をサポートします。 アクセスログフォーマット、バッファ付きログ書き込み、高速ログローテーション、および syslog ロギング 3xx-5xx エラーコードのリダイレクト リライトモジュール 正規表現を使用した URI の変更。 クライアントアドレスに応じて異なる関数を実行する。 クライアントのIPアドレス、パスワード(HTTP基本認証)、サブリクエストの結果によるアクセス制御。 HTTP リファラの検証 PUT、DELETE、MKCOL、COPY、MOVEメソッド FLV と MP4 ストリーミング 応答速度の制限 1 つのアドレスからの同時接続またはリクエストの数を制限します。 IPベースのジオロケーション A/B テスト。 リクエストのミラーリング 組み込みのPerl。 njs スクリプト言語

メールプロキシサーバーの機能

外部 HTTP 認証サーバを使用した IMAP または POP3 サーバへのユーザリダイレクション。 外部HTTP認証サーバを使用したユーザ認証と内部SMTPサーバへの接続リダイレクト 認証方法。 POP3：USER/PASS、APOP、AUTH LOGIN/PLAIN/CRAM-MD5。 IMAP: USER/PASS、APOP、AUTH LOGIN/PLAIN/CRAM-MD5。LOGIN、AUTH LOGIN/PLAIN/CRAM-MD5。 SMTP: AUTH LOGIN/PLAIN/CRAM-MD5。 SSLサポート。 STARTTLSおよびSTLSサポート。

TCP/UDPプロキシサーバの機能

TCP および UDP の汎用プロキシ TCP の SSL および TLS SNI サポート ロードバランシングとフォールトトレランス クライアントアドレスに基づいたアクセス制御 クライアントアドレスに応じて異なる機能を実行する。 1 つのアドレスからの同時接続数を制限する。 アクセスログフォーマット、バッファ付きログ書き込み、高速ログローテーション、および syslog ロギング。 IP ベースのジオロケーション A/B テスト。 njs スクリプト言語

アーキテクチャとスケーラビリティ

1つのマスターと複数のワーカープロセス。ワーカープロセスは特権のないユーザの下で実行されます。

柔軟なコンフィグレーション

クライアントサービスを中断することなく、実行ファイルの再設定とアップグレードを行うことができます。

kqueue (FreeBSD 4.1+)、epoll (Linux 2.6+)、/dev/poll (Solaris 7 11/99+)、イベントポート (Solaris 10)、select および poll をサポート。

EV_CLEAR、EV_DISABLE(イベントを一時的に無効にする)、NOTE_LOWAT、EV_EOF、利用可能なデータ数、エラーコードを含む様々なkqueue機能のサポート。 EPOLLRDHUP (Linux 2.6.17+, glibc 2.8+) や EPOLLEXCLUSIVE (Linux 4.5+, glibc 2.24+) を含む様々な epoll 機能のサポート。 sendfile (FreeBSD 3.1+, Linux 2.2+, macOS 10.5+), sendfile64 (Linux 2.4.21+) および sendfilev (Solaris 8 7/01+) のサポート。 ファイル AIO (FreeBSD 4.3+, Linux 2.6.22+). DIRECTIO (FreeBSD 4.4+, Linux 2.4+, Solaris 2.6+, macOS)。 Accept-filters (FreeBSD 4.1+, NetBSD 5.0+) および TCP_DEFER_ACCEPT (Linux 2.4+) をサポート。 10,000 の非アクティブな HTTP キープアライブ接続には約 250 万のメモリが必要です。 データのコピー作業は最小限に抑えられています。 テスト済みのOSとプラットフォーム FreeBSD 3 - 12 / i386; FreeBSD 5 - 12 / amd64; FreeBSD 11 / ppc; FreeBSD 12 / ppc64。 Linux 2.2 - 4 / i386; Linux 2.6 - 5 / amd64; Linux 3 - 4 / armv6l, armv7l, aarch64, ppc64le。 Solaris 9 / i386、sun4u、Solaris 10 / i386、amd64、sun4v、Solaris 11 / x86。 AIX 7.1 / powerpc. HP-UX 11.31 / ia64。 macOS / ppc、i386、x86_64。 Windows XP、Windows Server 2003、Windows 7、Windows 10。

 

ドキュメント

nginxのインストール

nginxはOSによってインストール方法が異なります。

Linuxへのインストール Linux では nginx.org の nginx パッケージが利用できます。

FreeBSD でのインストール FreeBSD では、nginx はパッケージからでも ports システムからでもインストールすることができます。ports システムはより柔軟性があり、幅広いオプションの中から選択することができます。ports は指定されたオプションで nginx をコンパイルしてインストールします。

ソースからのビルド パッケージやポートでは利用できない特別な機能が必要な場合は、ソースファイルからコンパイルすることもできます。より柔軟性がありますが、この方法は初心者には複雑かもしれません。詳細については、ソースからnginxをビルドする を参照してください。

 

ソースからnginxを構築する

ビルドは configure コマンドを使って設定します。nginx が接続処理に使用することを許可されている方法など、システムの様々な側面を定義します。最後にMakefileを作成します。

configure コマンドは以下のパラメータをサポートしています。

--help

ヘルプメッセージを表示します。

--prefix=path

サーバファイルを保存するディレクトリを定義します。このディレクトリは、configure で設定された相対パス（ライブラリのソースへのパスを除く）や nginx.conf の設定ファイルでも使用されます。デフォルトでは /usr/local/nginx ディレクトリに設定されています。

--sbin-path=path

はnginxの実行ファイル名を設定します。この名前はインストール時にのみ使用されます。デフォルトでは、ファイル名は prefix/sbin/nginx です。

--modules-path=path

は nginx の動的モジュールをインストールするディレクトリを定義します。デフォルトでは prefix/modules ディレクトリが使用されます。

--conf-path=path

は nginx.conf 設定ファイルの名前を設定します。必要に応じて、コマンドラインパラメータ -c file で設定ファイルを指定することで、常に異なる設定ファイルで nginx を起動することができます。デフォルトでは prefix/conf/nginx.conf という名前になっています。

--error-log-path=path

プライマリエラー、警告、診断ファイルの名前を設定します。インストール後、ファイル名は常に nginx.conf 設定ファイルで error_log ディレクティブを使って変更することができます。デフォルトでは、ファイル名は prefix/logs/error.log です。

--pid-path=path

メインプロセスのプロセス ID を格納する nginx.pid ファイルの名前を設定します。インストール後、ファイル名は nginx.conf 設定ファイルで pid ディレクティブを使っていつでも変更することができます。デフォルトでは、ファイル名は prefix/logs/nginx.pid です。

--lock-path=path

はロックファイル名のプレフィックスを設定します。インストール後は、nginx.conf の設定ファイルで lock_file ディレクティブを使っていつでも値を変更することができます。デフォルトでは prefix/logs/nginx.lock です。

--user=name

は、ワーカープロセスで使用される権限のないユーザの名前を設定します。インストール後、この名前は常に nginx.conf の設定ファイルで user ディレクティブを使って変更することができます。デフォルトのユーザ名は nobody です。

--group=name

はワーカープロセスで使用されるグループの名前を設定します。インストール後、この名前は常に nginx.conf の設定ファイルで user ディレクティブを使って変更することができます。デフォルトでは、グループ名は非特権ユーザの名前に設定されます。

--build=name

オプションのnginxビルド名を設定します。

--builddir=path

ビルドディレクトリを設定します。

--with-select_module
--without-select_module

サーバが select() メソッドで動作するようにするモジュールのビルドを有効にするか無効にするかを指定します。このモジュールは、プラットフォームが kqueue, epoll, /dev/poll などのより適切なメソッドをサポートしていないと思われる場合に自動的にビルドされます。

--with-poll_module
--without-poll_module

は、サーバが poll() メソッドで動作するようにするモジュールの構築を有効にするか無効にするかを指定します。このモジュールは、プラットフォームが kqueue, epoll, /dev/poll のようなより適切なメソッドをサポートしていないと思われる場合に自動的にビルドされます。

--with-threads

はスレッドプールの使用を可能にします。

--with-file-aio

は、FreeBSD と Linux で非同期ファイル I/O (AIO) を使用できるようにします。

--with-http_ssl_module

は、HTTP サーバに HTTPS プロトコルのサポートを追加するモジュールを構築することを可能にします。このモジュールはデフォルトではビルドされません。このモジュールをビルドして実行するには OpenSSL ライブラリが必要です。

--with-http_v2_module

はHTTP/2のサポートを提供するモジュールを構築することを可能にします。このモジュールはデフォルトではビルドされません。

--with-http_realip_module

クライアントのアドレスを、指定したヘッダフィールドで送信されたアドレスに変更する ngx_http_realip_module モジュールをビルドすることを有効にします。このモジュールはデフォルトではビルドされません。

--with-http_addition_module

レスポンスの前後にテキストを追加する ngx_http_addition_module モジュールをビルドできるようにします。このモジュールはデフォルトではビルドされません。

--with-http_xslt_module
--with-http_xslt_module=dynamic

を使用して XML レスポンスを変換する ngx_http_xslt_module モジュールをビルドできるようにします。このモジュールはデフォルトではビルドされません。このモジュールをビルドして実行するには libxml2 および libxslt ライブラリが必要です。

--with-http_image_filter_module
--with-http_image_filter_module=dynamic

JPEG、GIF、PNG、WebP 形式の画像を変換する ngx_http_image_filter_module モジュールをビルドできるようにします。このモジュールはデフォルトではビルドされていません。

--with-http_geoip_module
--with-http_geoip_module=dynamic

クライアントの IP アドレスとコンパイル済みの MaxMind データベースに応じて変数を作成する ngx_http_geoip_module モジュールをビルドできるようにします。このモジュールはデフォルトではビルドされていません。

--with-http_sub_module

指定した文字列を別の文字列に置き換えることでレスポンスを変更する ngx_http_sub_module モジュールをビルドできるようにします。このモジュールはデフォルトではビルドされません。

--with-http_dav_module

は、WebDAV プロトコルを介したファイル管理の自動化を提供する ngx_http_dav_module モジュールの構築を有効にします。このモジュールはデフォルトではビルドされません。

--with-http_flv_module

は、Flash Video (FLV) ファイルの擬似ストリーミングをサーバサイドでサポートする ngx_http_flv_module モジュールをビルドできるようにします。このモジュールはデフォルトではビルドされません。

--with-http_mp4_module

は、MP4 ファイルの擬似ストリーミングをサーバサイドでサポートする ngx_http_mp4_module モジュールをビルドできるようにします。このモジュールはデフォルトではビルドされません。

--with-http_gunzip_module

gzip" エンコーディング方式に対応していないクライアントのために、レスポンスを "Content-Encoding: gzip" で展開する ngx_http_gunzip_module モジュールをビルドできるようにします。このモジュールはデフォルトではビルドされません。

--with-http_gzip_static_module

これにより、通常のファイルの代わりに ".gz" というファイル名の拡張子で圧縮前のファイルを送信できるようにする ngx_http_gzip_static_module モジュールをビルドできるようになります。このモジュールはデフォルトではビルドされません。

--with-http_auth_request_module

サブリクエストの結果に基づくクライアントの認証を実装する ngx_http_auth_request_module モジュールをビルドできるようにします。このモジュールはデフォルトではビルドされません。

--with-http_random_index_module

このモジュールは、スラッシュ文字 ('/') で終わるリクエストを処理し、 ディレクトリ内のランダムなファイルを選んでインデックスファイルとして使用するものです。このモジュールはデフォルトではビルドされません。

--with-http_secure_link_module

ngx_http_secure_link_module モジュールの構築を有効にします。このモジュールはデフォルトではビルドされません。

--with-http_degradation_module

ngx_http_degradation_moduleモジュールの構築を有効にします。このモジュールはデフォルトではビルドされません。

--with-http_slice_module

を使用すると、リクエストをサブリクエストに分割し、それぞれが特定の範囲のレスポンスを返す ngx_http_slice_module モジュールを構築できるようになります。このモジュールは、大きなレスポンスをより効果的にキャッシュします。このモジュールはデフォルトではビルドされません。

--with-http_stub_status_module

基本的なステータス情報へのアクセスを提供する ngx_http_stub_status_module モジュールの構築を有効にします。このモジュールはデフォルトではビルドされません。

--without-http_charset_module

指定した文字セットを "Content-Type" レスポンスヘッダフィールドに追加し、さらにデータをある文字セットから別の文字セットに変換することができる ngx_http_charset_module モジュールの構築を無効にします。

--without-http_gzip_module

は、HTTPサーバのレスポンスを圧縮するモジュールの構築を無効にします。このモジュールをビルドして実行するには zlib ライブラリが必要です。

--without-http_ssi_module

ngx_http_ssi_module モジュールを通過するレスポンスで SSI (Server Side Includes) コマンドを処理する ngx_http_ssi_module モジュールの構築を無効にします。

--without-http_userid_module

クライアントの識別に適したクッキーを設定する ngx_http_userid_module モジュールの構築を無効にします。

--without-http_access_module

特定のクライアントアドレスへのアクセスを制限する ngx_http_access_module モジュールの構築を無効にします。

--without-http_auth_basic_module

HTTP Basic Authentication "プロトコルを使用してユーザー名とパスワードを検証することで、リソースへのアクセスを制限できるようにする ngx_http_auth_basic_module モジュールの構築を無効にします。

--without-http_mirror_module

バックグラウンドミラーサブリクエストを作成して元のリクエストのミラーリングを実装する ngx_http_mirror_module モジュールの構築を無効にします。

--without-http_autoindex_module

スラッシュ文字 ('/') で終わるリクエストを処理する ngx_http_autoindex_module モジュールの構築を無効にし、 ngx_http_index_module モジュールがインデックスファイルを見つけられない場合にディレクトリリストを作成します。

--without-http_geo_module

クライアントの IP アドレスに応じた値を持つ変数を作成する ngx_http_geo_module モジュールの構築を無効にします。

--without-http_map_module

他の変数の値に依存した値を持つ変数を作成する ngx_http_map_module モジュールのビルドを無効にします。

--without-http_split_clients_module

A/Bテスト用の変数を作成する ngx_http_split_clients_module モジュールの構築を無効にします。

--without-http_referer_module

Referer" ヘッダーフィールドに無効な値が含まれるリクエストに対してサイトへのアクセスをブロックする ngx_http_referer_module モジュールの構築を無効にします。

--without-http_rewrite_module

は、HTTP サーバがリクエストをリダイレクトしたりリクエストの URI を変更したりできるようにするモジュールの構築を無効にします。このモジュールをビルドして実行するには PCRE ライブラリが必要です。

--without-http_proxy_module

HTTP サーバプロキシモジュールの構築を無効にします。

--without-http_fastcgi_module

FastCGI サーバーにリクエストを渡す ngx_http_fastcgi_module モジュールの構築を無効にします。

--without-http_uwsgi_module

リクエストを uwsgi サーバに渡す ngx_http_uwsgi_module モジュールの構築を無効にします。

--without-http_scgi_module

リクエストを SCGI サーバに渡す ngx_http_scgi_module モジュールの構築を無効にします。

--without-http_grpc_module

gRPC サーバーにリクエストを渡す ngx_http_grpc_module モジュールの構築を無効にします。

--without-http_memcached_module

memcached サーバからの応答を取得する ngx_http_memcached_module モジュールの構築を無効にします。

--without-http_limit_conn_module

キーごとの接続数を制限する ngx_http_limit_conn_module モジュールの構築を無効にします。

--without-http_limit_req_module

キーごとのリクエスト処理速度を制限する ngx_http_limit_req_module モジュールの構築を無効にします。

--without-http_empty_gif_module

シングルピクセルの透過GIFを出力するモジュールの構築を無効にします。

--without-http_browser_module

User-Agent "リクエストヘッダフィールドの値に依存する変数を作成する ngx_http_browser_module モジュールの構築を無効にします。

--without-http_upstream_hash_module

ハッシュ負荷分散メソッドを実装したモジュールの構築を無効にします。

--without-http_upstream_ip_hash_module

ip_hash負荷分散メソッドを実装したモジュールの構築を無効にします。

--without-http_upstream_least_conn_module

は、最小負荷分散メソッドを実装したモジュールの構築を無効にします。

--without-http_upstream_keepalive_module

アップストリームサーバへの接続のキャッシュを提供するモジュールの構築を無効にします。

--without-http_upstream_zone_module

上流グループのランタイム状態を共有メモリゾーンに格納できるようにするモジュールの構築を無効にします。

--with-http_perl_module
--with-http_perl_module=dynamic

は、組み込みPerlモジュールの構築を有効にします。このモジュールはデフォルトではビルドされません。

--with-perl_modules_path=path

はPerlモジュールを保存するディレクトリを定義します。

--with-perl=path

Perlのバイナリ名を設定します。

--http-log-path=path

は HTTP サーバのプライマリリクエストログファイルの名前を設定します。インストール後、ファイル名は常に nginx.conf の設定ファイルで access_log ディレクティブを使って変更することができます。デフォルトでは、ファイル名は prefix/logs/access.log です。

--http-client-body-temp-path=path

は、クライアントのリクエストボディを保持する一時ファイルを保存するディレクトリを定義します。インストール後、ディレクトリは nginx.conf の設定ファイルで client_body_temp_path ディレクティブを使っていつでも変更することができます。デフォルトでは、ディレクトリは prefix/client_body_temp という名前になっています。

--http-proxy-temp-path=path

は、プロキシされたサーバから受信したデータを一時的に保存するためのディレクトリを定義します。インストール後、ディレクトリは nginx.conf の設定ファイルで proxy_temp_path ディレクティブを使っていつでも変更することができます。デフォルトでは、ディレクトリは prefix/proxy_temp という名前になっています。

--http-fastcgi-temp-path=path

は、FastCGI サーバから受信したデータの一時ファイルを保存するためのディレクトリを定義します。インストール後、ディレクトリは nginx.conf 設定ファイルで fastcgi_temp_path ディレクティブを使っていつでも変更することができます。デフォルトでは、ディレクトリは prefix/fastcgi_temp という名前になっています。

--http-uwsgi-temp-path=path

は uwsgi サーバから受信したデータを一時的に保存するためのディレクトリを定義します。インストール後、nginx.confの設定ファイルでuwsgi_temp_pathディレクティブを使っていつでもディレクトリを変更できます。デフォルトでは、ディレクトリ名は prefix/uwsgi_temp です。

--http-scgi-temp-path=path

は SCGI サーバから受信したデータを一時的に保存するためのディレクトリを定義します。インストール後、ディレクトリは nginx.conf の設定ファイルで scgi_temp_path ディレクティブを使っていつでも変更することができます。デフォルトではディレクトリ名は prefix/scgi_temp です。

--without-http

はHTTPサーバを無効にします。

--without-http-cache

HTTP キャッシュを無効にします。

--with-mail
--with-mail=dynamic

POP3/IMAP4/SMTP メールプロキシサーバーを有効にします。

--with-mail_ssl_module

はメールプロキシサーバに SSL/TLS プロトコルのサポートを追加するモジュールをビルドすることを可能にします。このモジュールはデフォルトではビルドされません。このモジュールをビルドして実行するには OpenSSL ライブラリが必要です。

--without-mail_pop3_module

メールプロキシサーバのPOP3プロトコルを無効にします。

--without-mail_imap_module

メールプロキシサーバのIMAPプロトコルを無効にします。

--without-mail_smtp_module

メールプロキシサーバのSMTPプロトコルを無効にします。

--with-stream
--with-stream=dynamic

は、一般的な TCP/UDP プロキシとロードバランシングのためのストリームモジュールを構築することを可能にします。このモジュールはデフォルトではビルドされません。

--with-stream_ssl_module

は、ストリームモジュールに SSL/TLS プロトコルのサポートを追加するモジュールをビルドすることを可能にします。このモジュールはデフォルトではビルドされません。このモジュールをビルドして実行するには OpenSSL ライブラリが必要です。

--with-stream_realip_module

は、クライアントのアドレスを PROXY プロトコルヘッダで送信されるアドレスに変更する ngx_stream_realip_module モジュールの構築を有効にします。このモジュールはデフォルトではビルドされません。

--with-stream_geoip_module
--with-stream_geoip_module=dynamic

クライアントの IP アドレスとコンパイル済みの MaxMind データベースに応じて変数を作成する ngx_stream_geoip_module モジュールをビルドできるようにします。このモジュールはデフォルトではビルドされません。

--with-stream_ssl_preread_module

は、SSL/TLS を終了させずに ClientHello メッセージから情報を抽出できるようにする ngx_stream_ssl_preread_module モジュールをビルドすることを有効にします。このモジュールはデフォルトではビルドされません。

--without-stream_limit_conn_module

キーごとの接続数を制限する ngx_stream_limit_conn_module モジュールの構築を無効にします。

--without-stream_access_module

特定のクライアントアドレスへのアクセスを制限する ngx_stream_access_module モジュールの構築を無効にします。

--without-stream_geo_module

クライアントの IP アドレスに応じた値を持つ変数を作成する ngx_stream_geo_module モジュールの構築を無効にします。

--without-stream_map_module

他の変数の値に依存する値を持つ変数を作成する ngx_stream_map_module モジュールのビルドを無効にします。

--without-stream_split_clients_module

A/Bテスト用の変数を作成する ngx_stream_split_clients_module モジュールの構築を無効にします。

--without-stream_return_module

指定した値をクライアントに送信してから接続を閉じる ngx_stream_return_module モジュールの構築を無効にします。

--without-stream_upstream_hash_module

ハッシュ負荷分散メソッドを実装したモジュールの構築を無効にします。

--without-stream_upstream_least_conn_module

は、最小負荷分散メソッドを実装したモジュールの構築を無効にします。

--without-stream_upstream_zone_module

上流グループのランタイム状態を共有メモリゾーンに格納できるようにするモジュールの構築を無効にします。

--with-google_perftools_module

は、Google Performance Tools を使用して nginx ワーカープロセスのプロファイリングを可能にする ngx_google_perftools_module モジュールをビルドできるようにします。このモジュールは nginx 開発者向けであり、デフォルトではビルドされません。

--with-cpp_test_module

ngx_cpp_test_moduleモジュールのビルドを有効にします。

--add-module=path

外部モジュールを有効にします。

--add-dynamic-module=path

外部ダイナミックモジュールを有効にします。

--with-compat

ダイナミックモジュールの互換性を実現します。

--with-cc=path

Cコンパイラの名前を設定します。

--with-cpp=path

Cプリプロセッサの名前を設定します。

--with-cc-opt=parameters

は、CFLAGS 変数に追加される追加パラメータを設定します。FreeBSD でシステム PCRE ライブラリを使う場合は --with-cc-opt="-I /usr/local/include" を指定してください。select() でサポートするファイルの数を増やす必要がある場合は、ここで次のように指定します。--with-cc-opt="-D FD_SETSIZE=2048" のように指定することもできます。

--with-ld-opt=parameters

は、リンク時に使用する追加のパラメータを設定します。FreeBSDでシステムPCREライブラリを使用する場合は、 --with-ld-opt="-L /usr/local/lib "を指定してください。

--with-cpu-opt=cpu

指定された CPU ごとに構築を可能にします: pentium, pentiumpro, pentium3, pentium4, athlon, opteron, sparc32, sparc64, ppc64。

--without-pcre

PCRE ライブラリの使用を無効にします。

--with-pcre

は、PCRE ライブラリを強制的に使用します。

--with-pcre=path

PCRE ライブラリのソースへのパスを設定します。ライブラリのディストリビューション(バージョン4.4 - 8.43)はPCREのサイトからダウンロードして解凍する必要があります。後はnginxの./configureとmakeで行います。このライブラリは、location ディレクティブでの正規表現のサポートと ngx_http_rewrite_module モジュールに必要です。

--with-pcre-opt=parameters

PCREの追加ビルドオプションを設定します。

--with-pcre-jit

ジャストインタイムコンパイル "をサポートするPCREライブラリをビルドします (1.1.12, pcre_jitディレクティブ)。

--with-zlib=path

は、zlibライブラリのソースへのパスを設定します。ライブラリの配布物(バージョン1.1.3～1.2.11)は、zlibサイトからダウンロードして解凍する必要があります。後はnginxの./configureとmakeで行います。ngx_http_gzip_moduleモジュールに必要なライブラリです。

--with-zlib-opt=parameters

zlibの追加ビルドオプションを設定します。

--with-zlib-asm=cpu

pentium、pentiumpro のいずれかの CPU に最適化された zlib アセンブラソースの使用を可能にします。

--with-libatomic

は libatomic_ops ライブラリを強制的に使用します。

--with-libatomic=path

libatomic_opsライブラリのソースへのパスを設定します。

--with-openssl=path

はOpenSSLライブラリのソースへのパスを設定します。

--with-openssl-opt=parameters

OpenSSL の追加ビルドオプションを設定します。

--with-debug

デバッグログを有効にします。 パラメータの使用例 (これらはすべて一行で入力する必要があります)。

設定後、makeを使ってnginxをコンパイルしてインストールします。

ビギナーズガイド

このガイドでは、nginx の基本的な紹介と、nginx でできる簡単な作業について説明します。なお、読者のマシンには既に nginx がインストールされていることを前提としています。インストールされていない場合は、nginx のインストールのページを参照してください。

このガイドでは、nginxの起動・停止方法、設定のリロード方法、設定ファイルの構造の説明、静的コンテンツを配信するためのnginxの設定方法、プロキシサーバーとしてのnginxの設定方法、FastCGIアプリケーションとの接続方法などを説明します。

nginx には、マスタープロセスとワーカープロセスがあります。マスタープロセスの主な目的は、設定の読み込みと評価、ワーカープロセスのメンテナンスです。ワーカープロセスは、実際のリクエストの処理を行います。nginx は、イベントベースのモデルと OS に依存した機構を採用し、ワーカープロセス間でリクエストを効率的に分配します。ワーカープロセスの数は設定ファイルで定義されており、設定に応じて固定されている場合と、利用可能な CPU コア数に応じて自動的に調整されている場合があります (worker_processes を参照してください)。

nginx とそのモジュールがどのように動作するかは、設定ファイルで決定されます。デフォルトでは、設定ファイルは nginx.conf という名前で、/usr/local/nginx/conf, /etc/nginx, /usr/local/etc/nginx のいずれかのディレクトリに置かれます。

設定の開始、停止、およびリロード

nginx を起動するには、実行ファイルを実行します。nginx が起動したら、-s パラメータを指定して実行ファイルを起動することで制御することができます。以下の構文を使用します。

ここではシグナルは以下のいずれかであってもよい。

stop — fast shutdown quit — graceful shutdown reload — reloading the configuration file reopen — reopening the log files

例えば、ワーカープロセスが現在のリクエストの処理を終了するのを待って nginx プロセスを停止させるには、以下のコマンドを実行します。

このコマンドは nginx を起動したユーザーと同じユーザーで実行してください。 設定ファイルの変更は、設定を再読み込みするコマンドが nginx に送信されるか、再起動されるまで適用されません。設定をリロードするには、以下のコマンドを実行します。

マスタプロセスが設定をリロードするシグナルを受信すると、新しい設定ファイルの構文の妥当性をチェックし、その中で提供されている設定を適用しようとします。これが成功した場合、マスタープロセスは新しいワーカープロセスを起動し、古いワーカープロセスにメッセージを送信して、それらをシャットダウンするように要求します。そうでなければ、マスタープロセスは変更をロールバックし、古い設定で作業を続けます。古いワーカープロセスは、シャットダウンするコマンドを受け取ると、新しい接続の受け入れを停止し、そのような要求がすべてサー ビスされるまで、現在の要求にサービスを提供し続ける。その後、古いワーカープロセスは終了します。

kill ユーティリティのような Unix ツールの助けを借りて、nginx プロセスにシグナルを送ることもできます。この場合、シグナルは指定されたプロセス ID を持つプロセスに直接送られます。nginx マスタープロセスのプロセス ID は、デフォルトでは /usr/local/nginx/logs または /var/run にある nginx.pid に書き込まれます。例えば、マスタープロセスIDが1628の場合、nginxのグレースフルシャットダウンの結果としてQUITシグナルを送信するには、以下のように実行します。

起動している全ての nginx プロセスのリストを取得するには、例えば以下のように ps ユーティリティを使用します。

nginx へのシグナル送信についての詳細は nginx の制御 を参照してください。

設定ファイルの構造

nginxは設定ファイルで指定されたディレクティブによって制御されるモジュールで構成されています。ディレクティブはシンプルディレクティブとブロックディレクティブに分けられます。シンプルディレクティブは、名前とパラメータをスペースで区切り、セミコロン(;)で終わります。ブロックディレクティブは単純なディレクティブと同じ構造ですが、セミコロンの代わりに中括弧 ({ と }) で囲まれた追加の命令で終わります。ブロックディレクティブが中括弧の中に他のディレクティブを持つことができる場合、それはコンテキストと呼ばれます (例: events, http, server, location)。

コンテキストの外側の設定ファイルに配置されたディレクティブは、メインコンテキストにあるとみなされます。イベントと http ディレクティブはメインコンテキストに、http は server に、location は server に存在します。

記号の後の行の残りはコメントとみなされます。

静的なコンテンツの提供

ウェブサーバの重要なタスクは、ファイル(画像や静的な HTML ページなど)を提供することです。リクエストに応じて、異なるローカルディレクトリからファイルが提供される例を実装します。/data/www (HTML ファイルを含む場合があります) と /data/images (画像を含む場合があります) という異なるローカルディレクトリからファイルが提供される例を実装します。これには、設定ファイルを編集し、http ブロック内に 2 つのロケーションブロックを持つサーバブロックを設定する必要があります。

まず、/data/wwwディレクトリを作成し、そこに任意のテキストコンテンツを含むindex.htmlファイルを入れ、/data/imagesディレクトリを作成し、そこに画像をいくつか配置します。

次に、設定ファイルを開きます。デフォルトの設定ファイルには、すでにいくつかのサーバブロックの例が含まれていますが、ほとんどがコメントアウトされています。今のところ、そのようなブロックをすべてコメントアウトして、新しいサーバーブロックを開始してください。

一般的に、設定ファイルはいくつかのサーバブロックを含み、それらがリッスンするポートとサーバ名によって区別されます。nginx がリクエストを処理するサーバを決定すると、リクエストのヘッダに指定された URI をサーバブロック内に定義された location ディレクティブのパラメータと比較してテストします。

以下のロケーションブロックをサーバーブロックに追加します。

このロケーションブロックは、リクエストからのURIと比較した "/"接頭辞を指定します。一致するリクエストに対しては、URI は root ディレクティブで指定されたパス、つまり /data/www に追加され、ローカルファイルシステム上でリクエストされたファイルへのパスを形成します。複数のマッチするロケーションブロックがある場合、nginx は最も長いプレフィックスを持つものを選択します。上記のロケーションブロックは、最短のプレフィックスである長さ1を提供しています。

次に、2つ目のロケーションブロックを追加します。

これは /images/ で始まるリクエストにマッチします (location / もそのようなリクエストにマッチしますが、プレフィックスが短いです)。

結果としてのサーバブロックの設定は以下のようになるはずです。

これは、標準ポート80でリッスンし、ローカルマシンの http://localhost/ でアクセス可能なサーバーの動作設定がすでに行われています。images/で始まるURIを持つリクエストに応答して、サーバは/data/imagesディレクトリからファイルを送信します。例えば、http://localhost/images/example.png のリクエストに対して、nginx は /data/images/example.png ファイルを送信します。このようなファイルが存在しない場合は、404エラーを示すレスポンスを送信します。images/ で始まらない URI を持つリクエストは、/data/www ディレクトリにマップされます。例えば、http://localhost/some/example.html のリクエストに対して、nginx は /data/www/some/example.html ファイルを送信します。

新しい設定を適用するには、nginxがまだ起動していない場合はnginxを起動するか、nginxのマスタープロセスにリロードシグナルを送信してください。

何かが期待通りに動かない場合は、/usr/local/nginx/logs や /var/log/nginx ディレクトリにある access.log や error.log ファイルで原因を調べてみてください。

簡易プロキシサーバの設定

nginx のよく使われる使い方の一つに、プロキシサーバとしての設定があります。これはリクエストを受け取り、プロキシサーバにリクエストを渡し、プロキシサーバからレスポンスを取得してクライアントに送信するサーバを意味します。

ここでは、ローカルディレクトリからのファイルを含む画像のリクエストを処理し、それ以外のすべてのリクエストをプロキシサーバに送信する基本的なプロキシサーバを設定します。この例では、両方のサーバを単一の nginx インスタンス上で定義します。

まず、nginx の設定ファイルに以下の内容のサーバブロックを追加して、プロキシサーバを定義します。

これは、8080番ポート(以前は標準の80番ポートを使用していたため、listenディレクティブは指定されていませんでした)でリスンし、すべてのリクエストをローカルファイルシステム上の/data/up1ディレクトリにマッピングするだけの簡単なサーバになります。このディレクトリを作成し、そこに index.html ファイルを入れます。root ディレクティブはサーバのコンテキストに置かれていることに注意してください。このようなルートディレクティブは、リクエストを提供するために選択されたロケーションブロックに自分のルートディレクティブが含まれていない場合に使用されます。

次に、前節のサーバ設定を使い、プロキシサーバの設定になるように修正します。最初のロケーションブロックには、パラメータで指定したプロキシサーバのプロトコル、名前、ポート(ここでは http://localhost:8080)を指定した proxy_pass ディレクティブを配置します。

現在は /images/ のプレフィックスを持つリクエストを /data/images ディレクトリ以下のファイルにマップしていますが、2 番目のロケーションブロックを修正して、一般的なファイル拡張子を持つ画像のリクエストにマッチするようにします。変更後のロケーションブロックは次のようになります。

このパラメータは、.gif、.jpg、または.pngで終わるすべてのURIにマッチする正規表現です。正規表現の前には ~ をつけなければなりません。対応するリクエストは /data/images ディレクトリにマップされます。

nginx がリクエストに対応するロケーションブロックを選択するとき、まずプレフィックスを指定するロケーションディレクティブをチェックし、最も長いプレフィックスを持つロケーションを記憶してから、正規表現をチェックします。正規表現にマッチするものがあれば、nginx はその場所を選択し、そうでなければ以前に記憶されていたものを選択します。

結果として、プロキシサーバの設定は以下のようになります。

このサーバは、.gif, .jpg, .png で終わるリクエストをフィルタリングして /data/images ディレクトリにマッピングし (root ディレクティブのパラメータに URI を追加することで)、それ以外のすべてのリクエストを上記で設定したプロキシサーバに渡します。

新しい設定を適用するには、前のセクションで説明したように、リロードシグナルを nginx に送ります。

プロキシ接続をさらに設定するために使用できる記述内容は他にもたくさんあります。

FastCGI プロキシの設定

nginx は、PHP のような様々なフレームワークやプログラミング言語で構築されたアプリケーションを実行する FastCGI サーバーへのリクエストをルーティングするために使用することができます。

FastCGI サーバを動作させるための最も基本的な nginx の設定には、proxy_pass ディレクティブの代わりに fastcgi_pass ディレクティブを使用し、FastCGI サーバに渡されるパラメータを設定するために fastcgi_param 記述内容を使用することが含まれています。FastCGI サーバが localhost:9000 でアクセスできるとします。前節のプロキシ設定を基に、proxy_passディレクティブをfastcgi_passディレクティブに置き換え、パラメータをlocalhost:9000に変更します。PHPでは、SCRIPT_FILENAMEパラメータがスクリプト名の決定に使用され、 QUERY_STRINGパラメータがパラメータ要求:を渡すために使用されます。結果としての設定は次のようになります。

これは、FastCGIプロトコルを介してlocalhost:9000上で動作するproxiedサーバに、静的画像のリクエスト以外のすべてのリクエストをルーティングするサーバを設定します。

nginx の制御

nginxはシグナルで制御することができます。マスタープロセスのプロセスIDはデフォルトで/usr/local/nginx/logs/nginx.pidというファイルに書き込まれます。この名前は設定時に変更するか、nginx.conf で pid ディレクティブを使用して変更することができます。マスタープロセスは以下のシグナルをサポートしています。

シグナル内容
TERM, INT高速シャットダウン
QUITgraceful シャットダウン
HUP設定変更、変更されたタイムゾーンへの対応 (FreeBSD と Linux のみ)、新しい設定での新しいワーカープロセスの起動、古いワーカープロセスの優雅なシャットダウン
USR1のログファイルの再オープン
USR2の実行ファイルのアップグレード
WINCHワーカープロセスを graceful シャットダウンします。

必須ではありませんが、個々のワーカープロセスをシグナルで制御することも可能です。サポートされているシグナルは以下の通りです。 デバッグ時のWINCH異常終了(debug_pointsを有効にする必要があります)

Changing Configuration

nginx が設定ファイルを再読込するためには、マスタープロセスに HUP シグナルを送信しなければなりません。マスタープロセスは最初に構文の妥当性をチェックし、新しい設定を適用しようとします。これが失敗した場合、変更をロールバックし、古い設定で作業を続けます。これが成功した場合、新しいワーカープロセスを起動し、古いワーカープロセスに、 優雅にシャットダウンするように要求するメッセージを送信します。古いワーカープロセスはリスンソケットを閉じ、古いクライアントへのサービスを継続します。すべてのクライアントがサービスされた後、古いワーカープロセスはシャットダウンされます。

例を挙げて説明しましょう。nginx が FreeBSD 上で実行されていて

マスタープロセスにHUPを送ると出力になります。

PID 33129 を持つ古いワーカープロセスの 1 つは、まだ動作を続けています。しばらくすると終了します。

Rotating Log-files

ログファイルを回転させるためには、まずログファイルの名前を変更する必要があります。その後、USR1 シグナルがマスタープロセスに送信されます。その後、マスタープロセスは、現在開いている全てのログファイルを再オープンし、ワーカープロセスが実行している非特権ユーザを所有者として割り当てます。再オープンに成功した後、マスタープロセスは、開いているすべてのファイルを閉じ、ワーカープロセスにファイルを再オープンするように求めるメッセージを送信します。ワーカープロセスはまた、新しいファイルを開き、古いファイルをすぐに閉じます。その結果、古いファイルは圧縮などの後処理のためにほぼすぐに利用できるようになります。

Upgrading Executable on the Fly

サーバの実行ファイルをアップグレードするためには、まず古いファイルの代わりに新しい実行ファイルを置く必要があります。その後、マスタープロセスに USR2 シグナルが送られます。マスタプロセスはまず、プロセス ID を持つファイルの名前を .oldbin の新しいファイル、例えば /usr/local/nginx/logs/nginx.pid.oldbin に変更してから、新しい実行ファイルを起動します。

その後、すべてのワーカープロセス(古いものと新しいもの)はリクエストを受け入れ続けます。最初のマスタープロセスに WINCH シグナルが送信された場合、そのワーカープロセスにメッセージを送信し、優雅にシャットダウンするように要求し、終了を開始します。

しばらくすると、新しいワーカープロセスのみがリクエストを処理するようになります。

古いマスタープロセスはそのリッスンソケットを閉じず、必要に応じてワーカープロセスを再び起動するように管理できることに注意してください。何らかの理由で新しい実行ファイルが受け入れられずに動作した場合は、以下のいずれかを実行することができます。

古いマスタープロセスにHUP信号を送信します。古いマスタープロセスは、設定を再読み込みすることなく、新しいワーカープロセスを開始します。その後、新しいマスタープロセスにQUITシグナルを送ることで、すべての新しいプロセスを潔くシャットダウンすることができます。

新しいマスタープロセスに TERM シグナルを送ります。その後、そのワーカープロセスに直ちに終了するように要求するメッセージを送信し、それらはすべてほぼ直ちに終了します。(新しいプロセスが何らかの理由で終了しない場合は、強制的に終了させるために KILL シグナルを送るべきです)。新しいマスタープロセスが終了すると、古いマスタープロセスは自動的に新しいワーカープロセスを開始します。

新しいマスタープロセスが終了した場合、古いマスタープロセスはプロセスIDを持つファイル名から.oldbinサフィックスを破棄します。

アップグレードが成功した場合、古いマスタープロセスに QUIT シグナルが送られ、新しいプロセスだけが残ります。

接続処理方法

nginxは様々な接続処理方法をサポートしています。特定のメソッドが利用できるかどうかは、使用するプラットフォームに依存します。複数のメソッドをサポートしているプラットフォームでは、通常 nginx は最も効率的なメソッドを自動的に選択します。しかし、必要に応じて use ディレクティブで明示的に接続処理方法を選択することができます。

以下の接続処理方法に対応しています。

select - 標準メソッド。サポートするモジュールは、より効率的な方法を持たないプラットフォーム上で自動的にビルドされます。with-select_module および --without-select_module 設定パラメータを使用して、このモジュールのビルドを強制的に有効にしたり無効にしたりすることができます。

poll - 標準メソッド。サポートするモジュールは、より効率的な方法がないプラットフォーム上で自動的にビルドされます。with-poll_module および --without-poll_module 設定パラメータを使用して、このモジュールのビルドを強制的に有効にしたり無効にしたりすることができます。

kqueue - FreeBSD 4.1+、OpenBSD 2.9+、NetBSD 2.0、および macOS で使用される効率的なメソッド。

epoll - Linux 2.6+ で使用される効率的なメソッド。

EPOLLRDHUP (Linux 2.6.17, glibc 2.8) および EPOLLEXCLUSIVE (Linux 4.5, glibc 2.24) フラグは 1.11.3 からサポートされています。 SuSE 8.2 のような古いディストリビューションでは、2.4 カーネルに epoll サポートを追加するパッチが提供されています。 /dev/poll - Solaris 7 11/99+、HP/UX 11.22+ (eventport)、IRIX 6.5.15+、Tru64 UNIX 5.1A+ で使用される効率的なメソッド。

eventport - イベントポート、Solaris 10+ で使用されるメソッド (既知の問題があるため、代わりに /dev/poll メソッドを使用することをお勧めします)。

ハッシュの設定

サーバ名、マップディレクティブの値、MIME タイプ、リクエストヘッダ文字列の名前などの静的なデータを高速に処理するために、nginx はハッシュテーブルを使用します。nginx は起動時と再設定時に、同一のハッシュ値を持つキーを格納するバケットサイズが設定されたパラメータ (ハッシュバケットサイズ) を超えないように、ハッシュテーブルの最小サイズを選択します。テーブルのサイズはバケットで表されます。この調整は、テーブルサイズがハッシュ最大サイズパラメータを超えるまで続けられます。ほとんどのハッシュには対応する記述内容があり、これらのパラメータを変更することができます。例えば、サーバ名ハッシュの場合はserver_names_hash_max_sizeとserver_names_hash_bucket_sizeです。

ハッシュのバケットサイズパラメータは、プロセッサのキャッシュラインサイズの倍数のサイズに整列します。これにより、最新のプロセッサでは、メモリアクセス数を減らすことでハッシュ内のキー検索を高速化することができます。もしハッシュのバケットサイズが1つのプロセッサのキャッシュラインサイズと同じであれば、鍵探索中のメモリアクセス数は最悪の場合2回になります - 1回目はバケットアドレスを計算するため、2回目はバケット内の鍵探索中です。そのため、もし nginx がハッシュ最大サイズかハッシュバケットサイズのどちらかを増やすように要求するメッセージを出した場合は、最初のパラメータを増やすべきです。

デバッグログ

選択したクライアントのデバッグログ サイクリックメモリバッファへのロギング デバッグログを有効にするには、ビルド中にデバッグをサポートするように nginx を設定する必要があります。

./configure --with-debug ...

そして、デバッグレベルを error_log ディレクティブで設定する必要があります。

error_log /path/to/log debug;

nginx がデバッグをサポートするように設定されていることを確認するには、nginx -V コマンドを実行します。

configure arguments: --with-debug ...

構築済みの Linux パッケージは nginx-debug バイナリ (1.9.8) でログをデバッグするためのサポートを提供しています。

service nginx stop

サービス nginx-debug 開始 でデバッグレベルを設定します。Windows 版の nginx バイナリ版は常にデバッグログをサポートしていますので、デバッグレベルの設定だけで十分です。

デバッグレベルを指定せずにログを再定義すると、デバッグログが無効になりますので注意してください。以下の例では、サーバレベルでログを再定義すると、このサーバのデバッグログが無効になります。

これを避けるためには、ログを再定義する行をコメントアウトするか、デバッグレベルの指定を追加する必要があります。

選択したクライアントのデバッグログ また、特定のクライアントアドレスのみデバッグログを有効にすることも可能です。

サイクリックメモリバッファへのロギング デバッグログはサイクリックメモリバッファに書き込むことができます。

error_log memory:32m debug; デバッグレベルでメモリバッファにログを記録しても、高負荷時でもパフォーマンスに大きな影響はありません。この場合、以下のようなgdbスクリプトを使ってログを抽出することができます。

Logging to syslog

error_log と access_log 記述内容は、syslog へのロギングをサポートしています。以下のパラメータは、syslogへのロギングを設定します。

server=address

syslogサーバのアドレスを定義する。アドレスは、ドメイン名またはIPアドレス、オプションのポート、または "unix: "接頭辞の後に指定されるUNIXドメインのソケットパスとして指定することができる。ポートが指定されていない場合は、UDPポート514が使用されます。ドメイン名が複数のIPアドレスに解決されている場合、最初に解決されたアドレスが使用される。

facility=string

RFC3164で定義されているsyslogメッセージのファシリティを設定する。ファシリティは "kern", "user", "mail", "daemon", "auth", "intern", "lpr", "news", "uucp", "clock", "authpriv", "ftp", "ntp", "audit", "alert", "cron", "local0"... "local7 "のいずれかである。デフォルトは "local7 "です。

severity=string

RFC 3164 で定義されているように、access_log の syslog メッセージの深刻度を設定します。設定可能な値は、error_log ディレクティブの 2 番目のパラメータ (level) と同じです。デフォルトは "info" です。 エラーメッセージの深刻度は nginx によって決定されるので、このパラメータは error_log ディレクティブでは無視されます。

tag=string

syslogメッセージのタグを設定します。デフォルトは "nginx "です。 ホスト名なし syslogメッセージヘッダに "hostname "フィールドを追加しないようにします(1.9.7)。 syslogの設定例。

情報を組み合わせたものです。 syslogへのロギングはバージョン1.7.1から利用可能です。商用サブスクリプションの一部として、バージョン1.5.3以降、syslogへのロギングが利用可能になりました。

Configuration file measurement units

サイズは、バイト、キロバイト（接尾辞 k と K）、またはメガバイト（接尾辞 m と M）で指定することができ、例えば、"1024"、"8k"、"1m "などです。

オフセットは、接尾辞 g または G を使用してギガバイト単位で指定することもできます。

時間間隔は、以下の接尾辞を使用して、ミリ秒、秒、分、時間、日などで指定することができます。

記号内容
msmilliseconds
sseconds
mminutes
hhours
ddays
wweeks
Mmonths, 30 days
yyears, 365 days

複数の単位を1つの値にまとめるには、最も大きいものから最も小さいものまでの順に指定し、オプションで空白で区切ることができます。例えば、"1h 30m "は "90m "や "5400s "と同じ時間を指定します。サフィックスのない値は秒を意味します。常にサフィックスを指定することをお勧めします。

時間間隔の中には、秒単位でしか指定できないものもあります。

コマンドラインパラメータ

nginx は以下のコマンドラインパラメータをサポートしています。

-? | -h — コマンドラインパラメータのヘルプを表示します。 -c file — デフォルトファイルの代わりに別の設定ファイルを使用します。 -g 記述内容 — を設定して、例えばグローバル設定の記述内容を設定します。 nginx -g "pid /var/run/nginx.pid; worker_processes sysctl -n hw.ncpu;" -p prefix - nginx のパスプレフィックス、つまりサーバーファイルを保存するディレクトリを設定します (デフォルト値は /usr/local/nginx です)。 -q - 設定テスト中にエラー以外のメッセージを表示しないようにします。 -s signal - マスタープロセスにシグナルを送信します。引数のシグナルは以下のいずれかです。 stop - 速やかにシャットダウンします。 quit - Shutdown Gracefully reload - 設定を再読み込みし、新しい設定で新しいワーカープロセスを起動し、古いワーカープロセスを優雅にシャットダウンします。 reopen - ログファイルを再開する t -t - 設定ファイルをテストします: nginx は設定が正しい構文であるかどうかをチェックし、設定で参照されたファイルを開こうとします。 T -T - -tと同じですが、追加で設定ファイルを標準出力にダンプします (1.9.2)。 -v — nginxのバージョンを表示します。 -V — nginxのバージョン、コンパイラのバージョン、設定パラメータを表示します。

nginx for Windows

Known issues Possible future enhancements Windows版nginxは、ネイティブのWin32 APIを使用しています（Cygwinエミュレーションレイヤーではありません）。現在は select() と poll() (1.15.9) の接続処理メソッドのみを使用しており、高いパフォーマンスとスケーラビリティは期待できません。このため、Windows 版 nginx はベータ版とみなされています。現時点では、XSLT フィルタ、画像フィルタ、GeoIP モジュール、Perl 言語の組み込み以外は、UNIX 版 nginx とほぼ同じ機能を提供しています。

nginx/Windows をインストールするには、最新のメインライン版 (1.19.0) をダウンロードしてください。その後、ディストリビューションを解凍し、nginx-1.19.0ディレクトリに移動し、nginxを実行してください。ここでは、C ドライブのルートディレクトリの例を示します。

タスクリストコマンドラインユーティリティを実行してnginxプロセスを確認します。

プロセスの一つがマスタープロセスで、もう一つがワーカープロセスです。nginx が起動しない場合は、エラーログファイル logs\error.log で原因を探してください。ログファイルが作成されていない場合は、その理由を Windows イベントログで報告してください。エラーページが期待したページではなく表示された場合は、logs_error.logファイルで理由を探してください。

nginx/Windows は、実行したディレクトリを設定の相対パスのプレフィックスとして使用します。上の例では、プレフィックスは C:\nginx-1.19.0 です。設定ファイル内のパスは、UNIX 形式でフォワードスラッシュを使用して指定しなければなりません。

nginx/Windows は標準のコンソールアプリケーション（サービスではありません）として動作し、以下のコマンドで管理することができます。

nginx -s stop fast shutdown nginx -s quit graceful shutdown nginx -s 設定変更のリロード、新しい設定で新しいワーカープロセスの起動、古いワーカープロセスの緩やかなシャットダウン nginx -s reopen ログファイルの再オープン

既知の問題

複数のワーカーを起動することができますが、実際に作業を行うのは1つのワーカーのみです。 UDP プロキシ機能はサポートされていません。 将来の可能性のある機能拡張 サービスとして動作させる。 接続処理の方法としてI/O補完ポートを使用する 1つのワーカープロセス内で複数のワーカースレッドを使用する。

How nginx processes a request

サーバー名が未定義のリクエストを処理しないようにする方法 名前ベースとIPベースの混在した仮想サーバー シンプルなPHPサイトの構成 名前ベースの仮想サーバー nginx は最初にどのサーバーがリクエストを処理するかを決定します。まずは、3つの仮想サーバがすべてポート*:80でリッスンするシンプルな設定から始めてみましょう。

この設定では、nginx はリクエストのヘッダフィールド "Host" のみをテストして、リクエストがどのサーバにルーティングされるべきかを判断します。その値がサーバ名と一致しない場合、またはリクエストにこのヘッダフィールドが全く含まれていない場合、nginx はリクエストをこのポートのデフォルトサーバにルーティングします。上記の設定では、デフォルトのサーバが最初のサーバになります - これがnginxの標準的なデフォルトの動作です。listen ディレクティブの default_server パラメータで、どのサーバをデフォルトにするかを明示的に設定することもできます。

default_server パラメータはバージョン 0.8.21 以降で利用可能です。それ以前のバージョンでは、代わりに default パラメータを使用しなければなりません。 default server は listen ポートのプロパティであり、サーバ名のプロパティではないことに注意してください。これについては後述します。

未定義のサーバ名でリクエストを処理しないようにする方法 もし "Host" ヘッダフィールドを持たないリクエストを許可してはいけない場合は、リクエストを削除するだけのサーバを定義することができます。

ここでは、サーバ名を空文字列に設定して、「Host」ヘッダフィールドのないリクエストにマッチするようにし、接続を閉じる特殊なnginxの非標準コード444を返しています。

バージョン0.8.48以降は、これがサーバ名のデフォルト設定となっているため、サーバ名「」は省略できます。それ以前のバージョンでは、マシンのホスト名がデフォルトのサーバ名として使用されていました。 名前ベースの仮想サーバーとIPベースの仮想サーバーの混在 いくつかの仮想サーバーが異なるアドレスをリッスンする、より複雑な設定を見てみましょう。

この設定では、nginx は最初にサーバブロックの listen 記述内容に対してリクエストの IP アドレスとポートをテストします。次に、リクエストの "Host" ヘッダフィールドを IP アドレスとポートにマッチしたサーバブロックの server_name エントリと比較します。サーバ名が見つからない場合、リクエストはデフォルトのサーバで処理されます。例えば、192.168.1.1.1:80 ポートで受信した www.example.com のリクエストは、192.168.1.1.1:80 ポートのデフォルトサーバ、つまり最初のサーバで処理されます。

すでに述べたように、デフォルトサーバは listen ポートのプロパティであり、異なるポートに対して異なるデフォルトサーバを定義することができます。

シンプルなPHPサイトの構成 では、典型的なシンプルな PHP サイトのリクエストを処理するために nginx がどのように場所を選択するかを見てみましょう。

nginx は最初に、リテラル文字列で与えられた最も特定のプレフィックス位置を、リストの順序に関係なく検索します。上記の設定では、プレフィックスの位置は"/"のみであり、どのようなリクエストにもマッチするため、最後の手段として使用されます。そして、設定ファイルに記載されている順番で正規表現で指定された場所をチェックします。最初の正規表現にマッチした場合は検索を停止し、nginx はこの場所を使用します。正規表現がリクエストにマッチしなかった場合、nginx は先に見つかった最も特定のプレフィックスの場所を使用します。

すべての型のロケーションは、引数のないリクエスト行のURI部分のみをテストすることに注意してください。これは、クエリ文字列の引数がいくつかの方法で与えられる可能性があるためです。

その上、誰もがクエリ文字列の中で何かを要求することができます。

では、上記の設定でリクエストがどのように処理されるかを見てみましょう。

リクエスト"/logo.gif "は最初にプレフィックス"/"の位置にマッチし、その後に正規表現"..(gif|jpg|png)$"がマッチしますので、後者の位置で処理されます。root /data/www" ディレクティブを使うと、リクエストはファイル /data/www/logo.gif にマップされ、そのファイルがクライアントに送られます。 リクエスト"/index.php "もまた、最初にプレフィックスの位置"/"と正規表現"..(php)$"でマッチします。したがって、後者の位置で処理され、リクエストは localhost:9000 でリスニングしている FastCGI サーバに渡されます。fastcgi_paramディレクティブは、FastCGIパラメータSCRIPT_FILENAMEを"/data/www/index.php "に設定し、FastCGIサーバがファイルを実行します。変数$document_rootはルートディレクティブの値に等しく、変数$fastcgi_script_nameはリクエストURI、つまり"/index.php "に等しくなります。 リクエスト「/about.html」は、プレフィックス位置「/」のみでマッチするので、この位置で処理されます。ディレクティブ「root /data/www」を使用して、リクエストはファイル /data/www/about.htmlにマップされ、そのファイルはクライアントに送られる。

リクエスト"/"を扱うのは、より複雑です。これはプレフィックスの場所"/"のみでマッチするので、この場所で処理されます。そして、index ディレクティブは、そのパラメータと "root /data/www" ディレクティブに従ってインデックスファイルが存在するかどうかをテストします。もし /data/www/index.html というファイルが存在せず、/data/www/index.php というファイルが存在する場合、このディレクティブは内部で "/index.php" へのリダイレクトを行い、nginx はあたかもクライアントからのリクエストであるかのように、再度その場所を検索します。前に見たように、リダイレクトされたリクエストは最終的に FastCGI サーバによって処理されます。

written by Igor Sysoev edited by Brian Mercer

Server names

 

Wildcard names

 

Regular expressions names

その他の名称 国際化された名前 最適化 互換性 サーバ名は server_name ディレクティブを使って定義され、与えられたリクエストにどのサーバブロックが使われるかを決定します。nginx がリクエストを処理する方法」も参照してください。サーバ名は、正確な名前、ワイルドカード名、正規表現を使って定義することができます。

名前で仮想サーバーを検索する際に、ワイルドカード名と正規表現の両方にマッチするなど、指定した variant の中から複数の variant にマッチする名前があった場合は、最初にマッチする variant を優先して選択します。

exact name

アスタリスクで始まる最長のワイルドカード名、例：".example.org" アスタリスクで終わる最も長いワイルドカード名、例："mail." 最初にマッチする正規表現 (設定ファイル内での出現順)

Wildcard names

ワイルドカード名には、名前の先頭または末尾にのみアスタリスクを含めることができ、ドットボーダーにのみアスタリスクを含めることができます。www..example.org」および「w.example.org」という名前は無効です。しかし、これらの名前は正規表現を使用して指定することができます。例えば、"~^www.+.example.org$"と"~^w..example.org$"です。アスタリスクは、複数の名前の部分と一致させることができます。例えば、".example.org "という名前は、www.example.org だけでなく、www.sub.example.org にもマッチします。

.example.org」という形式の特別なワイルドカード名は、正確な名前「example.org」とワイルドカード名「*.example.org」の両方にマッチするように使用することができます。

Regular expressions names

nginx で使用される正規表現は、Perl プログラミング言語 (PCRE) で使用される正規表現と互換性があります。正規表現を使用するには、サーバ名がチルダ文字で始まる必要があります。

server_name ~^www\d+.example.net$; そうでない場合は正確な名前として扱われ、式にアスタリスクが含まれている場合はワイルドカード名として扱われます(そして、ほとんどの場合は無効な名前として扱われます)。アンカーに "^" と "$" を設定することを忘れないでください。これらは構文的には必須ではありませんが、論理的には必須です。また、ドメイン名のドットはバックスラッシュでエスケープされるべきであることにも注意してください。文字"{"と"}"を含む正規表現は引用符で囲む。

server_name "~^(?<名前>\w\d{1,3}+).example.net$". そうしないとnginxの起動に失敗してエラーメッセージが表示されます。

directive "server_name" is not terminated by ";" in ... 名前付き正規表現のキャプチャは、後で変数として使うことができます。

PCRE ライブラリは、以下の構文を使用した名前付きキャプチャをサポートしています。

Perl 5.10互換構文、PCRE-7.0以降でサポートされています。 ?name' Perl 5.10互換構文、PCRE-7.0以降でサポートされています。 P Python互換構文、PCRE-4.0以降でサポートされています。 nginxが起動に失敗してエラーメッセージが表示された場合 pcre_compile() failed: unrecognized character after (?< in ... これは PCRE ライブラリが古いものであり、代わりに "?P" という構文を試すべきであることを意味します。キャプチャはデジタル形式でも使用できます。

ただし、このような使用法は、デジタル参照は簡単に上書きされてしまうので、単純な場合（上記のような場合）に限定すべきです。

その他の名称 特別に扱われるサーバ名がいくつかあります。

デフォルトではないサーバブロックで "Host "ヘッダフィールドを持たないリクエストを処理する必要がある場合は、空の名前を指定する必要があります。

サーバブロックにserver_nameが定義されていない場合、nginxは空の名前をサーバ名として使用します。

0.8.48 までの nginx では、この場合はマシンのホスト名をサーバ名として使用していました。 サーバー名が "$hostname" (0.9.4) で定義されている場合は、マシンのホスト名が使用されます。

誰かがサーバ名の代わりにIPアドレスを使ってリクエストをした場合、"Host "リクエストヘッダフィールドにはIPアドレスが含まれ、そのIPアドレスをサーバ名として使ってリクエストを処理することができます。

キャッチオールサーバーの例では、「_」という奇妙な名前が見られます。

この名前には何も特別なことはなく、実名と交差することのない無数の無効なドメイン名の一つに過ぎません。他にも"--"や"！@#"のような無効な名前も同様に使用されることがあります。

nginx の 0.6.25 までのバージョンでは、特殊な名前 "" がサポートされていましたが、これがキャッチオール名として誤って解釈されていました。これはキャッチオール名やワイルドカードサーバー名としては機能しませんでした。代わりに、現在 server_name_in_redirect ディレクティブで提供されている機能を提供していました。特別な名前 "" は非推奨となり、 server_name_in_redirect ディレクティブを使うべきです。server_name ディレクティブを使ってキャッチオール名やデフォルトのサーバを指定する方法はないことに注意してください。これは listen ディレクティブのプロパティであり、server_name ディレクティブのプロパティではありません。nginx がリクエストを処理する方法」も参照してください。ポート *:80 と *:8080 を listen しているサーバを定義することができ、一方をポート *:8080 のデフォルトサーバとし、他方をポート *:80 のデフォルトサーバとすることができます。

国際化された名前

国際化されたドメイン名 (IDN) は server_name ディレクティブで ASCII (Punycode) を使って指定しなければなりません。

最適化

厳密な名前、アスタリスクで始まるワイルドカード名、アスタリスクで終わるワイルドカード名は、リスナーポートにバインドされた3つのハッシュテーブルに格納されます。ハッシュテーブルのサイズは設定段階で最適化されており、CPUキャッシュのミスを最小限に抑えて名前を見つけることができます。ハッシュテーブルの設定の詳細は別のドキュメントに記載されています。

最初に正確な名前のハッシュテーブルが検索されます。名前が見つからない場合は、アスタリスクで始まるワイルドカード名のハッシュテーブルが検索されます。名前が見つからない場合は、アスタリスクで終わるワイルドカード名のハッシュテーブルが検索されます。

ワイルドカード名のハッシュテーブルの検索は、ドメイン部分で検索されるため、正確な名前のハッシュテーブルの検索よりも時間がかかります。特殊なワイルドカード形式の".example.org "はワイルドカード名ハッシュテーブルに格納されており、正確な名前のハッシュテーブルには格納されていないことに注意してください。

正規表現は順次テストされるため、最も遅い方法であり、スケーラブルではありません。

これらの理由から、可能な限り正確な名前を使用した方が良いでしょう。例えば、サーバーの最も頻繁に要求される名前が example.org と www.example.org の場合、それらを明示的に定義した方が効率的です。

多数のサーバ名が定義されていたり、異常に長いサーバ名が定義されている場合は、http レベルで server_names_hash_max_size と server_names_hash_bucket_size 記述内容を調整する必要があるかもしれません。server_names_hash_bucket_size ディレクティブのデフォルト値は、CPU キャッシュラインのサイズに応じて、32 と等しくしてもよいし、64 と等しくしてもよいし、別の値にしてもよい。デフォルト値が32で、サーバ名が "too.long.server.name.example.org "と定義されている場合、nginxの起動に失敗してエラーメッセージが表示されます。

server_names_hash をビルドできませんでした。 server_names_hash_bucket_sizeを32にする必要があります。 この場合、指令値は2の次のべき乗に増加させる必要があります。

サーバー名が多数定義されている場合は、別のエラーメッセージが表示されます。

server_names_hash をビルドできませんでした。 server_names_hash_max_size: 512 のどちらかを増やすべきです。 または server_names_hash_bucket_size: 32

このような場合は、まず server_names_hash_max_size をサーバ名の数に近い値に設定してみてください。それでも効果がない場合や、nginx の起動時間が許容できないほど長い場合にのみ、server_names_hash_bucket_size を増やしてみてください。 リスナーポートに対してサーバが唯一のサーバである場合、nginx はサーバ名のテストを一切行いません (そして、リスナーポートのハッシュテーブルを構築しません)。しかし、一つの例外があります。サーバ名がキャプチャを含む正規表現である場合、nginx はキャプチャを取得するために式を実行しなければなりません。

互換性

特別なサーバ名「$hostname」は0.9.4からサポートされています。 0.8.48 以降、デフォルトのサーバー名の値は空の名前 "" です。 0.8.25 以降、名前付き正規表現サーバ名のキャプチャがサポートされるようになりました。 0.7.40 以降、正規表現サーバー名のキャプチャがサポートされました。 空のサーバ名 "" が 0.7.12 以降でサポートされました。 0.6.25 以降、ワイルドカードサーバ名または正規表現を最初のサーバ名として使用することがサポートされました。 0.6.7 以降、正規表現サーバ名がサポートされました。 ワイルドカード形式の example.* は 0.6.0 以降でサポートされています。 特殊な形式の .example.org は 0.3.18 以降でサポートされています。 ワイルドカード形式 *.example.org は 0.1.13 以降でサポートされています。

written by Igor Sysoev edited by Brian Mercer

###Using nginx as HTTP load balancer

複数のアプリケーションインスタンス間でのロードバランシングは、リソース利用の最適化、スループットの最大化、レイテンシの低減、フォールトトレラントな構成を確保するために一般的に使用されている技術です。

nginxを非常に効率的なHTTPロードバランサーとして使用することで、複数のアプリケーションサーバにトラフィックを分散させ、nginxを使用してWebアプリケーションのパフォーマンス、スケーラビリティ、信頼性を向上させることができます。

負荷分散の方法

nginx では以下の負荷分散メカニズム（またはメソッド）がサポートされています。

round-robin - アプリケーションサーバへのリクエストはラウンドロビン方式で分散されます。 最少接続 - 次のリクエストは、アクティブな接続数が最も少ないサーバに割り当てられます。 ip-hash - ハッシュ関数は、(クライアントの IP アドレスに基づいて) 次のリクエストでどのサーバーを選択するかを決定するために使用されます。 デフォルトのロードバランシング設定 nginxで負荷分散を行うための最もシンプルな設定は以下のようになります。

上の例では、同じアプリケーションが srv1-srv3 上で 3 つのインスタンスで動作しています。負荷分散方法が特に設定されていない場合、デフォルトはラウンドロビンです。全てのリクエストはmyapp1というサーバグループにプロキシされ、nginxはHTTP負荷分散を適用してリクエストを分散します。

nginx のリバースプロキシ実装では、HTTP、HTTPS、FastCGI、uwsgi、SCGI、memcached、gRPC のロードバランシングが可能です。

HTTP の代わりに HTTPS のロードバランシングを設定するには、プロトコルとして "https" を使用します。

FastCGI、uwsgi、SCGI、memcached、またはgRPCのロードバランシングを設定する場合は、それぞれfastcgi_pass、uwsgi_pass、scgi_pass、memcached_pass、grpc_passディレクティブを使用します。

最小接続のロードバランシング もう一つの負荷分散の規律は、最小接続型です。Least-connected は、リクエストの一部が完了するまでに時間がかかる状況で、アプリケーションインスタンスの負荷をより公平に制御することができます。

最小接続のロードバランシングを使用すると、nginx は忙しいアプリケーションサーバーに過剰なリクエストを与えないようにして、新しいリクエストを代わりに忙しくないサーバーに分散させます。

nginx の Least-connected ロードバランシングは、サーバグループ設定の一部として least_conn ディレクティブが使用されている場合に有効になります。

セッションの持続性

ラウンドロビンまたは最小接続のロードバランシングでは、後続の各クライアントのリクエストが別のサーバーに分散される可能性があることに注意してください。同じクライアントが常に同じサーバーに誘導されるという保証はありません。

クライアントを特定のアプリケーションサーバーに結びつける必要がある場合、言い換えれば、クライアントのセッションを常に特定のサーバーを選択しようとするという点で「粘着性のある」または「持続性のある」ものにする必要がある場合、ip-hash負荷分散メカニズムを使用することができます。

ip-hash を使うと、クライアントの IP アドレスがハッシュキーとして使われ、 クライアントのリクエストに対してサーバグループのどのサーバを選択すべきかを決定します。この方法により、同じクライアントからのリクエストは、このサーバが利用できない場合を除いて、常に同じサーバに誘導されます。

ip-hash ロードバランシングを設定するには、サーバ (アップストリーム) グループの設定に ip_hash ディレクティブを追加するだけです。

重み付けされた負荷分散

また、サーバーウェイトを使用することで、nginx の負荷分散アルゴリズムにさらに影響を与えることも可能です。

上記の例では、サーバーウェイトは設定されていませんが、これは指定されたすべてのサーバーが特定の負荷分散方法に対して等しく扱われることを意味します。

特にラウンドロビンでは、十分なリクエストがあり、リクエストが均一な方法で処理され、十分な速さで完了していれば、サーバー間で多かれ少なかれリクエストが均等に分配されることを意味します。

サーバにウェイトパラメータが指定されている場合、ウェイトは負荷分散の判断の一部として考慮されます。

この設定では、5つの新しいリクエストは以下のようにアプリケーションインスタンスに分散されます。3つのリクエストは srv1 に、1つのリクエストは srv2 に、そしてもう1つのリクエストは srv3 に送られます。

最近の nginx のバージョンでは、最低接続数と ip-hash の負荷分散で重み付けを行うことも同様に可能です。

Health checks

nginx のリバースプロキシの実装には、インバンド(またはパッシブ)サーバーのヘルスチェックが含まれています。特定のサーバからのレスポンスがエラーで失敗した場合、nginx はこのサーバを失敗したものとしてマークし、その後のインバウンドリクエストでこのサーバを選択しないようにします。

max_fails ディレクティブは、fail_timeout の間に起こるはずのサーバとの通信に連続して失敗する回数を設定します。デフォルトでは、max_fails は 1 に設定されています。0 に設定されている場合、このサーバのヘルスチェックは無効になります。fail_timeout パラメータは、サーバが失敗とマークされる時間も定義します。fail_timeout 間隔の後、nginx はライブクライアントからのリクエストに応じて、サーバを優雅にプローブし始めます。プローブが成功した場合、サーバーはライブサーバーとしてマークされます。

Further reading

さらに、proxy_next_upstream、backup、down、keepalive など、nginx のサーバの負荷分散を制御する記述内容やパラメータがあります。詳細については、リファレンスドキュメントを参照してください。

最後になりましたが、アプリケーションの負荷分散、アプリケーションの健全性チェック、アクティビティの監視、サーバーグループのオンザフライ再構成は、有料のNGINX Plusサブスクリプションの一部として利用可能です。

以下の記事では、NGINX Plusでの負荷分散について詳しく説明しています。

Load Balancing with NGINX and NGINX Plus Load Balancing with NGINX and NGINX Plus part 2

Configuring HTTPS servers

HTTPS サーバを構成するには、サーバブロック内のリスニングソケットで ssl パラメータを有効にし、サーバ証明書と秘密鍵ファイルの場所を指定する必要があります。

サーバ証明書はパブリックエンティティです。サーバ証明書は、サーバに接続するすべてのクライアントに送信されます。秘密鍵は安全な実体であり、アクセスが制限されたファイルに保存されるべきですが、nginx のマスタープロセスが読み取れるようにしなければなりません。秘密鍵は証明書と同じファイルに保存することもできます。

の場合は、ファイルへのアクセス権も制限しなければなりません。証明書と鍵は一つのファイルに格納されていますが、クライアントには証明書のみが送信されます。

ssl_protocols と ssl_ciphers は、SSL/TLS の強力なバージョンと暗号のみを含む接続を制限するために使用できます。デフォルトでは nginx は "ssl_protocols TLSv1 TLSv1.1 TLSv1.2" と "ssl_ciphers HIGH:!aNULL:!MD5" を使用します。これらのディレクティブのデフォルト値は何度か変更されていることに注意してください。

HTTPS サーバの最適化

SSL 操作は余分な CPU リソースを消費します。マルチプロセッサシステムでは、利用可能なCPUコア数以上のワーカープロセスを実行する必要があります。最もCPUを消費する操作はSSLハンドシェイクです。1つ目はキープアライブ接続を有効にして1つの接続を介して複数のリクエストを送信する方法、2つ目はSSLセッションパラメータを再利用して並列接続やそれ以降の接続でのSSLハンドシェイクを回避する方法です。セッションはワーカー間で共有される SSL セッションキャッシュに保存され、ssl_session_cache ディレクティブで設定されます。1メガバイトのキャッシュには約4000個のセッションが格納されます。デフォルトのキャッシュタイムアウトは 5 分です。これは ssl_session_timeout ディレクティブを使うことで増やすことができます。ここでは、10メガバイトの共有セッションキャッシュを持つマルチコアシステムに最適化した設定例を示します。

worker_processes auto;

SSL certificate chains

ブラウザによっては、有名な証明書局が署名した証明書に文句を言う場合もありますが、他のブラウザでは問題なくその証明書を受け入れる場合もあります。これは、発行局が特定のブラウザで配布されている有名な信頼された証明書局の証明書ベースには存在しない中間証明書を使ってサーバ証明書に署名しているために起こります。この場合、発行局は署名されたサーバ証明書に連結すべき連結証明書の束を提供します。サーバ証明書は、結合されたファイルの中で連鎖した証明書の前に現れなければなりません。

サーバ証明書とバンドルの連結順序が間違っていると、nginxの起動に失敗してエラーメッセージが表示されます。

SSL_CTX_use_PrivateKey_file("... /www.example.com.key") が失敗しました。 (SSL:エラー:0B080074:x509証明書ルーチン。 X509_check_private_key:キー値の不一致) なぜなら、nginx がサーバ証明書の代わりにバンドルの最初の証明書で秘密鍵を使おうとしたからです。

ブラウザは通常、受信した中間証明書を保存しており、信頼された機関によって署名されているので、積極的に利用するブラウザはすでに必要な中間証明書を持っているかもしれませんし、チェーン化されたバンドルなしで送られてきた証明書でも文句を言わないかもしれません。サーバが完全な証明書チェーンを送信するようにするには、例えば openssl コマンドラインユーティリティを使うことができます。

SNI を使用した設定をテストする場合、openssl はデフォルトで SNI を使用しないため、-servername オプションを指定することが重要です。

この例では、www.GoDaddy.com サーバ証明書 #0 のサブジェクト ("s") は、それ自体が証明書 #1 のサブジェクトである発行者 ("i") によって署名されており、それ自体が証明書 #2 のサブジェクトである発行者によって署名されています。

その証明書がブラウザの組み込み証明書ベース（ジャックが建てた家の中にある）に保存されている有名な発行者である ValiCert, Inc. によって署名されました。

証明書バンドルが追加されていない場合は、サーバ証明書#0のみが表示されます。

単一の HTTP/HTTPS サーバ

HTTPとHTTPSの両方のリクエストを処理するサーバを1台で構成することが可能です。

0.7.14 より前のバージョンでは、上記のように個々のリスニングソケットに対して SSL を選択的に有効にすることはできませんでした。SSL は ssl ディレクティブを使ってサーバ全体に対してのみ有効にすることができ、単一の HTTP/HTTPS サーバを設定することができませんでした。この問題を解決するために listen ディレクティブの ssl パラメータが追加されました。このため、最新のバージョンでは ssl ディレクティブの使用はお勧めしません。

名前ベースの HTTPS サーバ

1 つの IP アドレスでリスンする 2 つ以上の HTTPS サーバを設定すると、よくある問題が発生します。

この設定では、ブラウザは要求されたサーバ名に関係なくデフォルトのサーバの証明書、すなわち www.example.com を受け取ります。これは SSL プロトコルの動作に起因しています。SSL 接続はブラウザが HTTP リクエストを送信する前に確立され、nginx はリクエストされたサーバ名を知りません。そのため、デフォルトのサーバの証明書のみを提供する場合があります。

問題を解決するための最も古くて堅牢な方法は、HTTPS サーバごとに個別の IP アドレスを割り当てることです。

 

複数の名前を持つSSL証明書

他にも、複数の HTTPS サーバ間で単一の IP アドレスを共有する方法もある。しかし、いずれの方法にも欠点がある。1 つの方法は、SubjectAltName 証明書フィールドに複数の名前を持つ証明書、例えば www.example.com と www.example.org を使用することである。しかし、SubjectAltName フィールドの長さには制限があります。

別の方法としては、ワイルドカード名の証明書を使用する方法があります。ワイルドカード証明書は、指定されたドメインのすべてのサブドメインを保護しますが、1 つのレベルでのみ保護します。この証明書は www.example.org と一致しますが、example.org と www.sub.example.org とは一致しません。これら 2 つの方法を組み合わせることもできます。証明書は、SubjectAltName フィールドに、example.org と *.example.org のように、正確な名前とワイルドカード名を含めることができます。

複数の名前を持つ証明書ファイルとその秘密鍵ファイルを http レベルの設定に配置して、それらの単一のメモリコピーをすべてのサーバに継承する方が良いでしょう。

Server Name Indication

1 つの IP アドレス上で複数の HTTPS サーバを実行するためのより一般的なソリューションは、TLS Server Name Indication extension（SNI、RFC 6066）である。SNI は現在ほとんどの最新ブラウザでサポートされていますが、一部の古いクライアントや特殊なクライアントでは使用できない場合があります。

SNI ではドメイン名のみを渡すことができますが、リテラル IP アドレスを含むリクエストの場合、ブラウザによってはサーバの IP アドレスを誤って名前として渡してしまうことがあります。これに頼るべきではありません。 nginx で SNI を使用するには、nginx バイナリがビルドされている OpenSSL ライブラリと、実行時に動的にリンクされているライブラリの両方で SNI がサポートされている必要があります。OpenSSL は 0.9.8f 以降、config オプション "--enable-tlsext" でビルドされていれば SNI をサポートしています。OpenSSL 0.9.8j 以降はデフォルトで有効になっています。もし nginx が SNI をサポートしてビルドされていた場合は、"-V" スイッチで実行したときにこのオプションが表示されます。

...

TLS SNI support enabled

... しかし、SNI対応のnginxがSNIをサポートしていないOpenSSLライブラリに動的にリンクされている場合、nginxは警告を表示します。

nginx は SNI サポートで構築されていましたが、現在はリンクされています。 tlsext をサポートしていない OpenSSL ライブラリに動的に接続します。 したがって、SNIは利用できません。

Compatibility

0.8.21 および 0.7.62 以降、SNI のサポート状況が "-V" スイッチで表示されるようになりました。 listen ディレクティブの ssl パラメータは 0.7.14 以降サポートされています。0.8.21 以前はデフォルトのパラメータと一緒にしか指定できませんでした。 SNI は 0.5.23 以降でサポートされています。 共有 SSL セッションキャッシュは 0.5.6 以降でサポートされています。 バージョン 1.9.1 以降: デフォルトの SSL プロトコルは TLSv1、TLSv1.1、TLSv1.2 (OpenSSL ライブラリでサポートされている場合) です。 バージョン 0.7.65, 0.8.19 以降: デフォルトの SSL プロトコルは SSLv3, TLSv1, TLSv1.1, TLSv1.2 です (OpenSSL ライブラリでサポートされている場合)。 バージョン 0.7.64, 0.8.18 以前: デフォルトの SSL プロトコルは SSLv2, SSLv3, TLSv1 です。 バージョン1.0.5以降: デフォルトのSSL暗号は "HIGH:!aNULL:!MD5 "です。 バージョン 0.7.65, 0.8.20 以降: デフォルトの SSL 暗号化方式は "HIGH:!ADH:!MD5" です。 バージョン0.8.19: デフォルトのSSL暗号は "ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM "です。 バージョン 0.7.64, 0.8.18 以前: デフォルトの SSL 暗号は以下の通りです。 "ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP"。

nginxがTCP/UDPセッションを処理する方法

クライアントからのTCP/UDPセッションは、フェーズと呼ばれる連続したステップで処理されます。

Post-accept

クライアント接続を受け付けた後の最初のフェーズ。このフェーズでは ngx_stream_realip_module モジュールが呼び出されます。

Pre-access

アクセスの予備チェックを行います。このフェーズでは ngx_stream_limit_conn_module モジュールが呼び出されます。

Access

実際のデータ処理の前にクライアントのアクセス制限を行います。このフェーズでは ngx_stream_access_module モジュールが呼び出されます。

SSL

TLS/SSL の終了。このフェーズでは ngx_stream_ssl_module モジュールが呼び出されます。

Preread

ngx_stream_ssl_preread_module のようなモジュールが処理前にデータを解析できるようにするために、データの初期バイトを preread バッファに読み込みます。

Content

データが実際に処理される必須フェーズで、通常はアップストリームサーバにプロキシされるか、指定された値がクライアントに返されます。

Log

クライアントセッションの処理結果を記録する最終フェーズ。このフェーズでは ngx_stream_log_module モジュールが呼び出されます。

Modules reference

記述内容

accept_mutex を有効にすると、ワーカープロセスは順番に新しい接続を受け入れます。そうしないと、すべてのワーカープロセスに新しい接続が通知され、新しい接続の量が少ない場合、一部のワーカープロセスはシステムリソースを浪費するだけになるかもしれません。

EPOLLEXCLUSIVEフラグ(1.11.3)をサポートしているシステムやreuseportを使用しているシステムでは、accept_mutexを有効にする必要はありません。 バージョン1.11.3以前では、デフォルト値はonでした。

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

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

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

このディレクティブを動作させるためには、nginx を --with-debug でビルドする必要があります。

内部エラーが検出された場合、例えば、作業プロセスの再起動時にソケットの漏洩が検出された場合、debug_points を有効にすると、コアファイルの作成 (アボート) またはシステムデバッガを使用した更なる解析のためのプロセスの停止 (ストップ) が行われます。

デフォルトでは、nginx は TZ 変数を除いて親プロセスから継承した環境変数を全て削除します。このディレクティブは、継承された変数の一部を保存したり、値を変更したり、新しい環境変数を作成したりすることができます。これらの変数は

実行ファイルのライブアップグレード時に継承されます。 ngx_http_perl_module モジュールで使用されます。 ワーカープロセスで使用されます。システムライブラリをこのように制御することは、このディレクティブを使って変数を設定する前に、 ライブラリが初期化時にのみ変数をチェックするのが一般的なので、 必ずしも可能であるとは限らないことを覚えておく必要があります。例外としては、前述の実行ファイルのライブアップグレードがあります。 TZ 変数は、明示的に設定されていない限り、常に ngx_http_perl_module モジュールに継承され、利用可能です。

使用例

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

ログを設定します。同一レベル(1.5.2)で複数のログを指定することができます。メイン構成レベルでログをファイルに書き込むことが明示的に定義されていない場合は、既定のファイルが使用されます。

最初のパラメータは、ログを保存するファイルを定義します。特別な値 stderr は標準エラーファイルを選択します。syslogへのログ記録は、"syslog: "という接頭辞を指定して設定することができます。サイクリックメモリバッファへのログ記録は、"memory: "接頭辞とバッファサイズを指定して設定することができ、一般的にはデバッグ用に使用されます(1.7.11)。

2 番目のパラメータはログのレベルを決定し、debug, info, notice, warn, error, crit, alert, emerg のいずれかを指定します。上記のログレベルは、深刻度の高い順にリストアップされています。特定のログレベルを設定すると、指定された、より深刻なログレベルのすべてのメッセージがログに記録されます。たとえば、デフォルトのレベル error は、error、crit、alert、および emerg のメッセージをログに記録します。このパラメータを省略すると、error が使用されます。

デバッグログを機能させるためには、nginx を --with-debug でビルドする必要があります。 このディレクティブは、バージョン 1.7.11 以降のストリームレベルとバージョン 1.9.0 以降のメールレベルで指定できます。

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

別のファイル、または指定されたマスクにマッチするファイルを設定に含める。含まれるファイルは、構文的に正しい記述内容とブロックで構成されている必要があります。

使用例

ダイナミックモジュールをロードします。

使用例

load_module modules/ngx_mail_module.so;

nginx は accept_mutex を実装し、共有メモリへのアクセスをシリアライズするためにロック機構を使用します。ほとんどのシステムでは、ロックはアトミックオペレーションを使って実装されており、このディレクティブは無視されます。他のシステムでは "lock file" 機構が使われています。このディレクティブはロックファイルの名前の接頭辞を指定します。

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

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

kqueue コネクション処理メソッドが使われている場合、このディレクティブは無視されます。

設定パース時までに判明している正規表現に対して、「ジャストインタイムコンパイル」（PCRE JIT）を使用することを有効または無効にします。

PCRE JIT は正規表現の処理を大幅に高速化します。

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

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

このディレクティブはバージョン 1.7.11 で登場しました。

ワーカープロセスをブロックせずにファイルをマルチスレッドで読み込んだり送信したりするために使用する名前付きスレッドプールを定義します。

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

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

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

Example:

インターバルの内部実装は、使用する方法に依存します。

kqueueが使用されている場合はEVFILT_TIMERフィルタを使用します。 eventportが使用されている場合は timer_create()。 それ以外の場合は setitimer()

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

ワーカープロセスが使用するユーザーとグループの資格情報を定義します。groupが省略された場合は、ユーザと同じ名前のグループが使用されます。

epoll接続処理メソッドでaioを使用する場合、1つのワーカープロセスに対して、未処理の非同期I/O操作の最大数を設定します。

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

この数には、クライアントとの接続だけでなく、すべての接続 (特にプロキシされたサーバとの接続など) が含まれていることに注意してください。もう一つの考慮点は、実際の同時接続数が現在の最大オープンファイル数の制限を超えてはならないということです。

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

使用例

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

は、第１のワーカープロセスをＣＰＵ０／ＣＰＵ２に、第２のワーカープロセスをＣＰＵ１／ＣＰＵ３にバインドする。第２の例は、ハイパースレッディングに適している。

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

オプションの mask パラメータを使用して、自動バインディングで使用可能な CPU を制限することができます。

worker_cpu_affinity auto 01010101. このディレクティブは FreeBSD と Linux でのみ使用可能です。

ワーカープロセスのスケジューリングの優先度を nice コマンドと同じように定義します。許容範囲は通常 -20 から 20 までです。

Example:

最適な値は、CPUコア数、データを保存するハードディスクドライブの数、負荷パターンなど、多くの要因に依存します（ただし、これらに限定されません）。疑問がある場合は、利用可能なCPUコアの数に設定するのが良いスタートになるでしょう(値 "auto "はそれを自動検出しようとします)。

自動パラメータはバージョン1.3.8と1.2.5からサポートされています。

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

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

This directive appeared in version 1.11.11.

ワーカープロセスを優雅にシャットダウンするためのタイムアウトを設定します。タイムアウトすると、nginx は現在開いているすべての接続を閉じてシャットダウンを促進しようとします。

ワーカープロセスの現在の作業ディレクトリを定義します。これは主にコアファイルを書くときに使用され、その場合、ワーカープロセスは指定されたディレクトリへの書き込み権限を持っていなければなりません。

Module ngx_http_core_module

記述内容

このディレクティブはバージョン 1.11.8 で登場しました。

無効にすると、nginx が発行するリダイレクトは相対的なものになります。

server_name_in_redirect と port_in_redirect 記述内容も参照してください。

FreeBSD および Linux での非同期ファイル入出力 (AIO) の使用を有効または無効にします。

FreeBSD では、FreeBSD 4.3 から AIO が使用できます。FreeBSD 11.0 より前のバージョンでは、AIO はカーネルに静的にリンクすることもできます。

オプション VFS_AIO またはカーネルロード可能なモジュールとして動的にロードされます。

kldload aio Linux では、カーネルバージョン 2.6.22 から AIO を使用することができます。また、directioを有効にしないと読み込みがブロックされてしまいます。

Linuxでは、directioは512バイト境界（XFSの場合は4K）で整列されたブロックの読み込みにのみ使用できます。ファイルのアラインメントされていない端はブロッキングモードで読み込まれます。同じことがバイトレンジリクエストやファイルの先頭からではない FLV リクエストにも当てはまります: ファイルの先頭と末尾でアラインメントされていないデータの読み込みはブロッキングになります。

Linux で AIO と sendfile の両方が有効になっている場合、AIO は directio ディレクティブで指定されたサイズ以上のファイルに使用され、sendfile はそれより小さいサイズのファイルや directio が無効になっている場合に使用されます。

最後に、ワーカープロセスをブロックすることなく、マルチスレッド(1.7.11)を使用してファイルを読み込んだり、送信したりすることができます。

ファイルの読み込みと送信の操作は、指定されたプールのスレッドにオフロードされます。プール名を省略した場合は、"default "という名前のプールが使用されます。プール名は変数で設定することもできます。

aio threads=pool$disk。 デフォルトでは、マルチスレッドは無効になっていますが、--with-threads構成パラメータで有効にする必要があります。現在のところ、マルチスレッドは epoll、kqueue、および eventport メソッドとのみ互換性があります。マルチスレッドでのファイル送信は Linux でのみサポートされています。

sendfile ディレクティブも参照してください。

aioを有効にした場合、ファイルの書き込みに使用するかどうかを指定します。現在のところ、これは aio スレッドを使用している場合にのみ動作し、プロキシされたサーバから受信したデータを使って一時的なファイルを書き込むことに限定されています。

指定した場所の置換を定義します。例えば、次のような設定の場合

のリクエストがあった場合、ファイル /data/w3/images/top.gif を送信します。

パスの値は変数を含むことができますが、 $document_root と $realpath_root を除く。

正規表現で定義された場所の中でエイリアスが使われる場合、そのような正規表現はキャプチャを含んでいなければならず、エイリアスはこれらのキャプチャ (0.7.40) を参照しなければなりません。

位置がディレクティブの値の最後の部分と一致した場合。

ではなく、root ディレクティブを使った方が良いでしょう。

パスワードによるアクセス制限、サブリクエストの結果によるアクセス制限、JWTによるアクセス制限などのタイミング攻撃を防ぐために、401のレスポンスコードで不正なリクエストの処理を遅延させます。

HTTP/1.1 でチャンクされた転送エンコーディングを無効にすることができます。これは、標準の要件にもかかわらず chunked エンコーディングをサポートしていないソフトウェアを使用している場合に便利かもしれません。

クライアントのリクエストボディを読み込むためのバッファサイズを設定します。バッファサイズよりもリクエストボディが大きい場合は、ボディ全体またはその一部のみを一時ファイルに書き出します。デフォルトでは、バッファサイズは2メモリページ分になります。これは、x86、他の32ビットプラットフォーム、x86-64では8Kです。他の64ビットプラットフォームでは通常16Kです。

nginx がクライアントのリクエストボディ全体をファイルに保存するかどうかを指定します。このディレクティブは、デバッグ中や、変数 $request_body_file や ngx_http_perl_module の $r->request_body_file メソッドを使用する際に使用できます。

値がonに設定されている場合、リクエスト処理後に一時ファイルは削除されません。

値が clean に設定されていると、リクエスト処理後に残った一時ファイルが削除されます。

nginx がクライアントのリクエストボディ全体を単一のバッファに保存するかどうかを決定します。このディレクティブは $request_body 変数を使用する際に推奨されます。

クライアントリクエストボディを保持するテンポラリファイルを格納するディレクトリを定義します。指定したディレクトリの下には、最大3階層までのサブディレクトリ階層を使用することができます。例えば、次のような構成の場合

client_body_temp_path /spool/nginx/client_temp 1 2. 一時ファイルへのパスは次のようになります。

/spool/nginx/client_temp/7/45/00000123457

クライアントのリクエストボディを読み込むためのタイムアウトを定義します。タイムアウトは2つの連続した読み込み操作の間の期間のみに設定され、リクエストボディ全体の送信には設定されない。クライアントがこの時間内に何も送信しなかった場合、リクエストは408(Request Time-out)エラーで終了する。

クライアントのリクエストヘッダを読み込むためのバッファサイズを設定します。ほとんどのリクエストでは、1Kバイトのバッファで十分である。しかし、長いクッキーを含むリクエストや、WAP クライアントからのリクエストの場合は、1K バイトのバッファに収まらない場合がある。リクエスト行やリクエストヘッダフィールドがこのバッファに収まらない場合は、 large_client_header_buffers ディレクティブで設定したより大きなバッファが割り当てられます。

クライアントのリクエストヘッダを読み込むためのタイムアウトを定義する。クライアントがこの時間内にヘッダ全体を送信しなかった場合、リクエストは408(Request Time-out)エラーで終了する。

Content-Length」リクエストヘッダーフィールドで指定されたクライアントリクエストボディの最大許容サイズを設定します。リクエストのサイズが設定された値を超えた場合、413 (Request Entity Too Large) エラーがクライアントに返されます。ブラウザはこのエラーを正しく表示できませんのでご注意ください。sizeを0に設定すると、クライアントのリクエストボディサイズのチェックができなくなります。

接続ごとのメモリ割り当てを正確に調整することができます。このディレクティブはパフォーマンスへの影響は最小限であり、一般的には使用すべきではありません。デフォルトでは、32 ビットプラットフォームでは 256 バイト、64 ビットプラットフォームでは 512 バイトになります。

バージョン1.9.8以前では、すべてのプラットフォームでデフォルト値は256でした。

レスポンスのデフォルトの MIME タイプを定義します。ファイル名拡張子の MIME タイプへのマッピングは types ディレクティブで設定できます。

指定したサイズ以上のファイルを読み込む際に、 O_DIRECT フラグ (FreeBSD, Linux)、F_NOCACHE フラグ (macOS)、 directio() 関数 (Solaris) を使用できるようにします。このディレクティブは (0.7.15) 与えられたリクエストに対する sendfile の使用を自動的に無効にします。これは大きなファイルを扱うのに便利です。

directio 4m; またはLinux上でaioを使用する場合。

directio のアライメントを設定します。ほとんどの場合、512バイトのアラインメントで十分です。ただし、LinuxでXFSを使用する場合は4Kに増やす必要があります。

ファイルを開くときにシンボリックリンクがどのように扱われるかを指定します。

off

パス名のシンボリックリンクは許可され、チェックされません。これがデフォルトの動作です。

on

パス名のいずれかのコンポーネントがシンボリックリンクである場合、ファイルへのアクセスは拒否されます。

if_not_owner

パス名のいずれかのコンポーネントがシンボリックリンクであり、リンクとそのリンクが指すオブジェクトの所有者が異なる場合、ファイルへのアクセスは拒否されます。

from=part

シンボ リ ッ ク リ ン ク をチ ェ ッ ク す る 際には （引数 on と if_not_owner）、 パス名のすべての構成要素を通常チ ェ ッ ク し ます。パス名の初期部分でのシンボリックリンクのチェックは、 from=part パラ メータを追加で指定することで回避できます。この場合、 指定した初期部分に続くパス名の構成要素からのみシンボリックリンクがチェックされます。値が検査対象のパス名の初期部分でない場合は、このパラ メータが全く指定されていないかのようにパス名全体が検査されます。値がファイル名全体と一致する場合、シンボリックリンクはチェックされません。パラメータの値には変数を含めることができます。

Example:

from=$document_root で disable_symlinks を無効にします。 このディレクティブは openat() と fstatat() インターフェースを持つシステムでのみ利用可能です。このようなシステムには、最新版の FreeBSD, Linux, Solaris が含まれます。

パラメータ on と if_not_owner は処理のオーバーヘッドを追加します。

検索だけのディレクトリのオープンをサポートしていないシステムでは、 これらのパラメータを使用するには、ワーカープロセスがチェック対象のすべての ディレクトリの読み取り権限を持っている必要があります。 ngx_http_autoindex_module、ngx_http_random_index_module、ngx_http_dav_module モジュールは現在このディレクティブを無視しています。

指定されたエラーに対して表示されるURIを定義します。uriの値には変数を含めることができます。

Example:

error_page 404 /404.html;

error_page 500 502 503 504 /50x.html. これにより、クライアントのリクエストメソッドが "GET "に変更され、指定されたURIへの内部リダイレクトが発生します("GET "と "HEAD "以外のすべてのメソッド)。

さらに、例えば"=response "構文を使って、レスポンスコードを別のものに変更することも可能です。

error_page 404 =200 /empty.gif;

エラー応答がプロキシされたサーバまたはFastCGI/uwsgi/SCGI/gRPCサーバによって処理され、サーバが異なる応答コード（例えば、200、302、401、404）を返す可能性がある場合、それが返すコードで応答することが可能である。

error_page 404 = /404.php;

内部リダイレクト中にURIやメソッドを変更する必要がない場合は、エラー処理を名前付きの場所に渡すことが可能です。

uri処理でエラーが発生した場合、最後に発生したエラーのステータスコードがクライアントに返されます。 また、エラー処理にURLリダイレクトを使用することも可能です。

この場合、デフォルトでは、応答コード302がクライアントに返されます。リダイレクトステータスコード(301、302、303、307、308)のいずれかにのみ変更可能です。

コード307はバージョン1.1.16と1.0.13まではリダイレクトとして扱われませんでした。 コード308はバージョン1.13.0まではリダイレクトとして扱われませんでした。 これらの記述内容は、現在のレベルで定義されている error_page 記述内容がない場合に限り、前のレベルから継承されます。

静的リソースの「ETag」応答ヘッダーフィールドの自動生成を有効または無効にします。

HTTP サーバの記述内容が指定されている設定ファイルのコンテキストを提供します。

応答の修正時間と "If-Modified-Since "リクエストヘッダフィールドの時間を比較する方法を指定します。

off

If-Modified-Since」リクエストヘッダーフィールドは無視される(0.7.34)。

exact

正確に一致します。

before

応答の修正時間は、「If-Modified-Since」リクエストヘッダーフィールドの時間以下である。

無効な名前のヘッダフィールドを無視するかどうかを制御します。有効な名前は英字、数字、ハイフン、そして場合によってはアンダースコア (underscores_in_headers ディレクティブで制御されます) で構成されています。

ディレクティブがサーバレベルで指定されている場合、その値はサーバがデフォルトの場合にのみ使用されます。指定された値は、同じアドレスとポートを listen しているすべての仮想サーバにも適用されます。

指定された場所が内部要求にのみ使用できることを指定します。外部リクエストの場合、クライアント エラー 404 (Not Found) が返されます。内部リクエストは以下の通りです。

error_page, index, random_index, try_files 記述内容によってリダイレクトされたリクエスト。 アップストリームサーバからの "X-Accel-Redirect" レスポンスヘッダフィールドによってリダイレクトされたリクエスト。 ngx_http_ssi_module モジュールの "include virtual" コマンド、 ngx_http_addition_module モジュールの記述内容、 auth_request と mirror の記述内容によって形成されるサブリクエスト。 リクエストは、rewrite ディレクティブで変更されます。

Example:

不適切な構成で発生する可能性のあるリクエスト処理サイクルを防ぐために、1リクエストあたり10個の内部リダイレクトの制限があります。この制限に達すると、エラー500(Internal Server Error)が返されます。このような場合、エラーログに「書き換えまたは内部リダイレクトのサイクル」というメッセージが表示されます。

不正な動作をするブラウザとのキープアライブ接続を無効にします。ブラウザパラメータは、影響を受けるブラウザを指定します。値 msie6 は、古いバージョンの MSIE とのキープアライブ接続を無効にします。値 safari は、macOS および macOS ライクなオペレーティングシステム上の Safari および Safari ライクなブラウザとの接続のキープアライブを無効にします。値noneは、すべてのブラウザとの接続をキープアライブにします。 バージョン 1.1.1.18 より前のバージョンでは、safari の値はすべてのオペレーティングシステム上のすべての Safari および Safari ライクなブラウザにマッチし、それらのブラウザとの keep-alive 接続はデフォルトで無効になっていました。

1 つのキープアライブ接続で提供できるリクエストの最大数を設定します。最大数のリクエストが行われた後、接続は閉じられます。

定期的に接続を閉じることは、接続ごとのメモリ割り当てを解放するために必要です。そのため、高すぎる最大リクエスト数を使用するとメモリを過剰に使用することになりますので、お勧めできません。

最初のパラメータは、サーバ側でキープアライブクライアント接続が開いたままになるタイムアウトを設定します。ゼロの値は、キープアライブクライアント接続を無効にします。オプションの 2 番目のパラメータは、「Keep-Alive: timeout=time」応答ヘッダーフィールドに値を設定します。2つのパラメータは異なる場合があります。

Keep-Alive: timeout=time」ヘッダフィールドは、MozillaやKonquerorで認識されます。MSIEは約60秒でキープアライブ接続を自分で閉じます。

大規模なクライアントリクエストヘッダの読み込みに使用するバッファの最大数とサイズを設定します。リクエスト行は1つのバッファのサイズを超えることができないか、414 (Request-URI Too Large) エラーがクライアントに返されます。リクエストヘッダフィールドも同様に1つのバッファのサイズを超えることができないか、400 (Bad Request) エラーがクライアントに返されます。バッファは要求に応じてのみ割り当てられます。デフォルトでは、バッファサイズは8Kバイトです。リクエスト処理の終了後に接続がキープアライブ状態に移行した場合、これらのバッファは解放される。

ロケーション内で許可される HTTP メソッドを制限します。メソッドパラメータは以下のいずれかになります。GET、HEAD、POST、PUT、DELETE、MKCOL、COPY、MOVE、OPTIONS、PROPFIND、PROPPATCH、LOCK、UNLOCK、PATCH。GET メソッドを許可すると、HEAD メソッドも許可されます。他のメソッドへのアクセスは、ngx_http_access_module、ngx_http_auth_basic_module、ngx_http_auth_jwt_module (1.13.10) 記述内容モジュールを使用して制限することができます。

これにより、GETとHEAD以外のすべてのメソッドへのアクセスが制限されることに注意してください。

クライアントへの応答送信速度を制限します。レートは 1 秒あたりのバイト数で指定します。ゼロの値はレート制限を無効にします。制限はリクエストごとに設定されるため、クライアントが同時に 2 つの接続を開いた場合、全体のレートは指定された制限の 2 倍になります。

パラメータ値には変数を含めることができます（1.17.0）。ある条件によってはレートを制限する必要がある場合に便利かもしれません。

のように、$limit_rateを使用することができます。 レートリミットは$limit_rate変数にも設定できますが、バージョン1.17.0以降では、この方法は推奨されていません。

レート制限は、プロキシされたサーバ応答の "X-Accel-Limit-Rate "ヘッダフィールドで設定することもできる。この機能は、proxy_ignore_headers、fastcgi_ignore_headers、 uwsgi_ignore_headers、およびscgi_ignore_headers 記述内容を使用して無効にすることができる。

クライアントへの応答のさらなる送信がレート制限される最初の量を設定します。パラメータ値には変数を含めることができます(1.17.0)。

Example:

nginx がクライアントの接続をどのように閉じるかを制御します。

デフォルト値 "on "は、接続を完全に閉じる前にクライアントからの追加データを待ち、処理するように指示します。

always" は、無条件にクライアントからの追加データを待ち、処理します。

値 "off" は nginx に追加データを待たせず、直ちに接続を終了させます。この動作はプロトコルを破りますので、通常の状況では使用しないでください。

lingering_close が有効な場合、このディレクティブは nginx がクライアントからの追加データを処理（読み込み、無視）する最大時間を指定します。それ以降は、たとえ追加のデータがあったとしても、接続は閉じられます。

lingering_close が有効な場合、このディレクティブはより多くのクライアントデータが 到着するまでの最大の待ち時間を指定します。この時間内にデータが届かない場合、接続は閉じられます。そうでなければ、データは読み込まれて無視され、nginx は再びデータを待ち始めます。wait-read-ignore" のサイクルが繰り返されますが、lingering_time ディレクティブで指定された時間より長くはなりません。

IP のアドレスとポート、またはサーバがリクエストを受け付ける UNIX ドメインソケットのパスを設定します。アドレスとポートの両方、またはアドレスのみ、ポートのみを指定することもできます。アドレスには、例えばホスト名を指定することもできます。

IPv6アドレス(0.7.36)は角括弧で指定しています。

UNIX ドメインソケット (0.8.21) は "unix:" 接頭辞で指定します。

アドレスのみを指定した場合は、80番ポートが使用されます。

ディレクティブが存在しない場合は、nginx がスーパーユーザ権限で動作している場合は *:80 が、そうでない場合は *:8000 が使用されます。

default_server パラメータがあれば、指定されたアドレス:ポートのペアのデフォルトサーバになります。記述内容に default_server パラメータがない場合は、指定されたアドレス:ポートペアの最初のサーバがそのペアのデフォルトサーバとなります。

0.8.21 より前のバージョンでは、このパラメータは単に default と名付けられています。 ssl パラメータ (0.7.14) では、このポートで受け入れられるすべての接続が SSL モードで動作するように指定することができます。これにより、HTTP と HTTPS の両方のリクエストを処理するサーバのために、よりコンパクトな設定が可能になります。

http2 パラメータ (1.9.5) は、HTTP/2 接続を受け入れるようにポートを設定します。通常、これを動作させるためにはsslパラメータも指定しなければなりませんが、nginxはSSLなしでHTTP/2接続を受け入れるように設定することもできます。

spdy パラメータ (1.3.15-1.9.4) は、このポートで SPDY 接続を受け入れるようにします。通常はsslパラメータも指定しなければなりませんが、nginxはSSLなしでSPDY接続を受け入れるように設定することもできます。

proxy_protocolパラメータ(1.5.12)は、このポートで受け入れられるすべての接続がPROXYプロトコルを使用することを指定することができます。

PROXY プロトコルのバージョン 2 はバージョン 1.13.11 以降でサポートされています。 listen ディレクティブはソケット関連のシステムコールに特化したいくつかの追加パラメータを持つことができます。これらのパラメータはどの listen ディレクティブでも指定できますが、指定されたアドレス:ポートのペアに対して一度だけ指定します。

0.8.21 より前のバージョンでは、デフォルトのパラメータと一緒に listen ディレクティブで指定することができます。

setfib=数

このパラメータ (0.8.44) は、リスニングソケットのルーティングテーブル FIB (SO_SETFIB オプション) を設定します。これは現在 FreeBSD でのみ動作します。

fastopen=数値

リスニングソケット (1.5.8) で "TCP Fast Open" を有効にし、3 者間ハンドシェイクが完了していないコネクションのキューの最大長を制限します。 サーバがデータを含む同じSYNパケットを複数回受信することに対応できる場合を除き、この機能は有効にしないでください。

バックログ=数

は listen() コールの backlog パラメータを設定し、保留中の接続のキューの最大長を制限します。デフォルトでは、 FreeBSD, DragonFly BSD, macOS では backlog は -1 に、その他のプラットフォームでは 511 に設定されています。

rcvbuf=サイズ

リスニングソケットの受信バッファサイズ(SO_RCVBUFオプション)を設定する。

sndbuf=サイズ

リスニングソケットの送信バッファサイズ(SO_SNDBUFオプション)を設定する。

accept_filter=フィルター

は、 accept() に渡す前に着信接続をフィルタリングする listening ソケットの accept filter (SO_ACCEPTFILTER オプション) の名前を設定します。これは FreeBSD と NetBSD 5.0+ でのみ動作します。指定可能な値は dataready と httpready です。

deferred

Linux で deferred accept() (TCP_DEFER_ACCEPT ソケットオプション) を使用するように指示します。

バインド

は、指定されたアドレス:ポートのペアに対して個別に bind() を呼び出すように指示します。これは、同じポートで異なるアドレスを持つ複数の listen 記述内容があり、そのうちの一つが指定されたポート (*:port) のすべてのアドレスを listen している場合、nginx は *:port にのみ bind() を行うので便利です。この場合、接続を受け付けたアドレスを決定するために getsockname() システムコールが行われることに注意が必要です。setfib, backlog, rcvbuf, sndbuf, accept_filter, deferred, ipv6only, so_keepalive パラメータが使用されている場合は、指定されたアドレス:ポートのペアに対して、常に個別の bind() コールが行われます。

ipv6only=on|off

このパラメータ(0.7.42)は、ワイルドカードアドレス[::]をリッスンしているIPv6ソケットがIPv6接続のみを受け入れるか、IPv6とIPv4の両方を受け入れるかを(IPV6_V6ONLY socketオプションで)決定します。このパラメータはデフォルトでオンになっています。設定できるのは起動時に一度だけです。 バージョン1.3.4より前のバージョンでは、このパラメータを省略した場合、オペレーティングシステムの設定がソケットに対して有効になります。

再利用ポート

ワーカープロセス間での接続を行うことができるようになりました。これは現在、Linux 3.9+、DragonFly BSD、FreeBSD 12+ (1.15.1) でのみ動作します。 このオプションを不適切に使用すると、セキュリティに影響を及ぼす可能性があります。 so_keepalive=on|off|[keepidle]:[keepintvl]:[keepcnt] このパラメータ(1.1.11)は、リスニングソケットのTCPキープアライブの動作を設定します。このパラメータが省略された場合、オペレーティングシステムの設定がソケットに対して有効になります。このパラメータが "on "に設定されている場合、SO_KEEPALIVEオプションがソケットに対して有効になる。オフに設定した場合、SO_KEEPALIVEオプションはソケットに対してオフになる。一部のオペレーティングシステムでは、TCP_KEEPIDLE, TCP_KEEPINTVL, TCP_KEEPCNT ソケットオプションを使用して、ソケットごとに TCP keepalive パラメータの設定をサポートしている。このようなシステム (現在のところ Linux 2.4+, NetBSD 5+, FreeBSD 9.0-STABLE) では、keepidle, keepintvl, および keepcnt パラメータを使用して設定することができます。1つまたは2つのパラメータを省略した場合、対応するソケットオプションのシステムデフォルト設定が有効になります。例えば、以下のようになります。

はアイドルタイムアウト(TCP_KEEPIDLE)を30分に設定し、プローブ間隔(TCP_KEEPINTVL)をシステムデフォルトのままにして、プローブ数(TCP_KEEPCNT)を10プローブに設定します。

Example:

listen 127.0.0.0.1 default_server accept_filter=dataready backlog=1024.

リクエストURIに応じて設定を設定する。

マッチングは、"%XX "形式でエンコードされたテキストをデコードした後、相対パス構成要素". "と"... "への参照を解決した後、正規化されたURIに対して実行され、2つ以上の隣接するスラッシュを1つのスラッシュに圧縮する可能性がある。

ロケーションは、接頭辞文字列か正規表現で定義することができます。正規表現は、前の "~*" 修飾子 (大文字小文字を区別しないマッチングの場合)、または "~" 修飾子 (大文字小文字を区別しないマッチングの場合) で指定します。指定されたリクエストにマッチする場所を見つけるために、nginx は最初にプレフィックス文字列を使って定義された場所をチェックします (プレフィックスロケーション)。その中から、最も長くマッチするプレフィックスを持つ場所が選択され、記憶されます。次に、設定ファイルに現れた順に正規表現をチェックします。正規表現の検索は最初に一致したもので終了し、対応する設定が使用されます。正規表現にマッチするものが見つからなかった場合は、以前に記憶されていたプレフィックスの位置の設定が使用されます。

ロケーションブロックは入れ子にすることができます。

macOSやCygwinのような大文字小文字を区別しないオペレーティングシステムでは、プレフィックス文字列とのマッチングは大文字小文字を無視します(0.7.7)。ただし、比較は半角ロケールに限定されます。

正規表現には、後で他の記述内容で使用できるキャプチャ(0.7.40)を含めることができます。

最も長くマッチする接頭辞の位置に "^~" 修飾子がある場合、正規表現はチェックされません。

また、"="修飾子を使用して、URIと場所の完全一致を定義することも可能である。完全一致が見つかった場合、検索は終了する。例えば、"/"リクエストが頻繁に発生する場合、"location = /"を定義すると、最初の比較の直後に検索が終了するので、これらのリクエストの処理が速くなります。このようなロケーションは、明らかに入れ子になったロケーションを含むことはできません。

0.7.1 から 0.8.41 までのバージョンでは、"=" と "^~" 修飾子を使わずにプレフィックスの場所にマッチするリクエストがあった場合、 検索も終了し、正規表現はチェックされませんでした。 上記を例に説明してみましょう。

"/" リクエストは設定 A に、"/index.html" リクエストは設定 B に、"/documents/document.html" リクエストは設定 C に、"/images/1.gif" リクエストは設定 D に、"/documents/1.jpg" リクエストは設定 E にマッチします。

接頭辞「@」は名前付きの場所を定義します。このような場所は通常のリクエスト処理には使われず、 代わりにリクエストのリダイレクトに使われます。ネストすることはできず、ネストされたロケーションを含むことはできません。

ロケーションがスラッシュ文字で終わる接頭辞文字列で定義され、 リクエストがproxy_pass、fastcgi_pass、uwsgi_pass、scgi_pass、memcached_pass、 grpc_passのいずれかで処理されている場合、特別な処理が行われる。この文字列と同じURIを持つが最後のスラッシュがないリクエストに 対して、コード301を持つ恒久的なリダイレクトが、スラッシュを付加して リクエストされたURIに返される。これが望まれない場合、URIとロケーションの完全一致を以下のように 定義することができる。

見つからなかったファイルに関するエラーをerror_logに記録することを有効または無効にします。

サブリクエストのaccess_logへのロギングを有効または無効にします。

バイト範囲リクエストで許可される範囲の最大数を制限します。制限を超えるリクエストは、指定されたバイト範囲がなかったものとして処理されます。既定では、範囲の数は制限されません。ゼロ値を指定すると、バイト範囲のサポートが完全に無効になります。

URI内の2つ以上の隣接するスラッシュを1つのスラッシュに圧縮することを有効または無効にします。

圧縮は、プレフィックス文字列と正規表現の位置を正しくマッチさせるために不可欠であることに注意してください。これがないと、"//scripts/one.php "リクエストは

と静的ファイルとして処理される可能性があります。そのため、"/scripts/one.php "に変換されます。

base64は内部的に"/"文字を使用するので、URIにbase64エンコードされた名前が含まれている場合、圧縮をオフにすることが必要になることがあります。しかし、セキュリティを考慮すると、圧縮をオフにしない方が良いでしょう。

ディレクティブがサーバレベルで指定された場合、その値はサーバがデフォルトの場合にのみ使用されます。指定された値は、同じアドレスとポートで聞いているすべての仮想サーバにも適用されます。

ステータスが 400 を超える MSIE クライアントの応答にコメントを追加して、応答サイズを 512 バイトに増やすことを有効または無効にします。

MSIEクライアントのリダイレクトの代わりにリフレッシュを発行することを有効または無効にします。

保存できるキャッシュを設定します。

開いているファイル記述子、そのサイズ、変更時間。 ディレクトリの存在に関する情報 ファイルが見つかりませんでした "や "読み取り許可がありません "などのファイル検索エラー。 エラーのキャッシュは open_file_cache_errors ディレクティブで個別に有効にする必要があります。 このディレクティブのパラメータは以下の通りです。

max

キャッシュの最大要素数を設定します。キャッシュがオーバーフローした場合には、最近使用された (LRU) 要素が削除されます。 非アクティブな は、この時間内にアクセスされなかった場合にキャッシュから要素が削除される時間を定義します; デフォルトでは60秒です。 オフ はキャッシュを無効にします。

Example:

open_file_cache ディレクティブの inactive パラメータで設定された期間中に、 ファイルディスクリプタがキャッシュで開いたままでいるために必要な 最小のファイルアクセス数を設定します。

open_file_cache 要素を検証する時間を設定します。

ディスクからの応答の読み込みに使用するバッファの数とサイズを設定します。

バージョン1.9.5以前のデフォルト値は1 32kでした。

 

nginx が発行するアブソリュートリダイレクトでポートを指定することを有効または無効にします。

リダイレクトでのプライマリサーバ名の使用は server_name_in_redirect ディレクティブで制御されます。

可能であれば、クライアントデータの送信は nginx が送信するデータのサイズバイト数以上になるまで延期されます。ゼロの値はデータ送信の延期を無効にします。

ファイルを扱う際のカーネルの事前読み込み量を設定します。

Linux では、posix_fadvise(0, 0, 0, POSIX_FADV_SEQUENTIAL) システムコールを使用しているため、size パラメータは無視されます。

FreeBSD では、FreeBSD 9.0-CURRENT 以降でサポートされている fcntl(O_READAHEAD, size) システムコールが使われています。FreeBSD 7 にはパッチを当てる必要があります。

error_page ディレクティブを使って複数のリダイレクトを行うことを有効または無効にします。このようなリダイレクトの数は制限されています。

リクエストごとのメモリ割り当てを正確に調整することができます。このディレクティブは性能への影響は最小限で、一般的には使用しないでください。

タイムアウトした接続および非標準コード444（1.15.2）で閉じた接続のリセットを有効または無効にします。リセットは以下のように実行される。ソケットを閉じる前に、ソケットにSO_LINGERオプションをタイムアウト値0で設定し、ソケットが閉じられると、TCP RSTをクライアントに送信し、このソケットで占有していたすべてのメモリを解放します。これにより、既に閉じられているソケットでバッファがいっぱいになっている状態を長時間 FIN_WAIT1 状態で保持することを防ぐことができる。

タイムアウトしたキープアライブ接続は正常に閉じられることに注意してください。

アップストリームサーバの名前をアドレスなどに解決するために使用するネームサーバを設定します。

resolver 127.0.0.1 [::1]:5353;

アドレスはドメイン名またはIPアドレスとして指定でき、オプションでポート（1.3.1、1.2.2）を指定することができます。ポートを指定しない場合は、53番ポートが使用されます。ネームサーバはラウンドロビン方式で照会されます。

バージョン1.1.7以前では、1台のネームサーバしか設定できませんでした。IPv6 アドレスを使用したネームサーバの指定は、バージョン 1.3.1 および 1.2.2 からサポートされています。 デフォルトでは、nginx は IPv4 アドレスと IPv6 アドレスの両方を検索して解決します。IPv6 アドレスを検索したくない場合は、ipv6=off パラメータを指定することができます。

IPv6 アドレスへの名前解決はバージョン 1.5.8 よりサポートされています。 デフォルトでは、nginx はレスポンスの TTL 値を使って回答をキャッシュします。オプションの有効なパラメータを指定することで、これを上書きすることができます。

resolver 127.0.0.0.1 [::1]:5353 valid=30s.

バージョン 1.1.1.9 より前のバージョンでは、キャッシュ時間の調整ができず、nginx は常に 5 分間の回答をキャッシュしていました。 DNSスプーフィングを防ぐには、適切に保護された信頼できるローカルネットワークにDNSサーバを設定することをお勧めします。 オプションの status_zone パラメータ (1.17.1) を使用すると、指定したゾーンのリクエストとレスポンスの DNS サーバーの統計情報を収集することができます。このパラメータは、当社の商用サブスクリプションの一部として利用できます。

名前解決のタイムアウトを設定します。

resolver_timeout 5s;

リクエストのルートディレクトリを設定します。例えば、次のような設定の場合

data/w3/i/top.gifファイルは、"/i/top.gif "リクエストに応答して送信されます。

パスの値は、$document_root と $realpath_root 以外の変数を含むことができます。

ファイルへのパスは、単に root ディレクティブの値に URI を追加するだけで構築されます。URI を変更しなければならない場合は、エイリアスディレクティブを使用しなければなりません。

ngx_http_access_module、ngx_http_auth_basic_module、ngx_http_auth_request_module、ngx_http_auth_jwt_module のうち、すべて (すべて) または少なくとも 1 つ (いずれか) がアクセスを許可している場合にアクセスを許可します。

Example:

 

このディレクティブが0以外の値に設定されている場合、nginxはkqueueメソッドのNOTE_LOWATフラグかSO_SNDLOWATソケットオプションを使用して、クライアントソケットの送信操作の数を最小化しようとします。どちらの場合も指定されたサイズが使用されます。

このディレクティブは Linux, Solaris, Windows では無視されます。

応答をクライアントに送信するためのタイムアウトを設定します。タイムアウトは、2 つの連続した書き込み操作の間にのみ設定され、応答全体の送信には設定されません。クライアントがこの時間内に何も受信しない場合、接続は閉じられます。

sendfile() の使用を有効または無効にします。

nginx 0.8.12 および FreeBSD 5.2.1 以降では、aio を使って sendfile() のデータをプリロードすることができます。

この設定では、sendfile() は SF_NODISKIO フラグを指定して呼び出され、ディスク I/O をブロックせず、代わりにデータがメモリにないことを報告します。最初の読み込みでは、FreeBSD カーネルはファイルの最初の 128K バイトをメモリにロードしますが、次の読み込みでは 16K のチャンクでしかデータをロードしません。これは read_ahead ディレクティブを使って変更することができます。

バージョン 1.7.11 より前のバージョンでは、aio sendfile; でプリロードを有効にすることができました。

0 以外の値に設定すると、1 回の sendfile() コールで転送できるデータ量を制限します。この制限がない場合は、高速な接続がワーカープロセスを完全に停止させてしまう可能性があります。

仮想サーバーの設定を行います。IP ベースの (IP アドレスに基づく) 仮想サーバと名前ベースの (Host リクエストヘッダフィールドに基づく) 仮想サーバの間には明確な区別はありません。その代わりに、listen 記述内容はサーバへの接続を受け入れるすべてのアドレスとポートを記述し、 server_name ディレクティブはすべてのサーバ名をリストアップします。設定例は "nginx がリクエストを処理する方法" で提供されています。

仮想サーバーの名前を設定します。

最初の名前がプライマリサーバー名になります。

サーバー名には、名前の最初の部分または最後の部分をアスタリスク ("*") で置き換えることができます。

このような名前は、ワイルドカード名と呼ばれています。

上述した名前のうち、最初の2つを1つにまとめることができます。

サーバ名の前にチルダ ("~") を付けて正規表現を使用することも可能です。

正規表現は、後で他の記述内容で使用できるキャプチャー（0.7.40）を含むことができます。

正規表現での名前付きキャプチャは、後で他の記述内容で使用できる変数(0.8.25)を作成します。

ディレクティブのパラメータに "$hostname" (0.9.4) を指定すると、マシンのホスト名が挿入されます。

空のサーバ名を指定することも可能です (0.7.11)。

これにより、指定されたアドレス:ポートのペアに対して、このサーバがデフォルトのサーバの代わりに 「ホスト」ヘッダフィールドなしでリクエストを処理することができるようになります。これがデフォルトの設定です。

0.8.48 より前のバージョンでは、デフォルトではマシンのホスト名が使用されていました。 名前で仮想サーバーを検索する際に、名前が指定した variant の中で複数にマッチする場合 (ワイルドカード名と正規表現の両方にマッチする場合など)、 最初にマッチする variant が優先度の高い順に選択されます。

the exact name アスタリスクで始まる最も長いワイルドカード名、例：".example.com" アスタリスクで終わる最も長いワイルドカード名、例："mail." 最初にマッチする正規表現 (設定ファイルの出現順) サーバー名の詳細な説明は、別のサーバー名のドキュメントに記載されています。

nginx が発行するアブソリュートリダイレクトにおいて、server_name ディレクティブで指定されたプライマリサーバ名の使用を有効または無効にします。プライマリサーバ名の使用を無効にした場合、リクエストヘッダの "Host" フィールドの名前が使用されます。このフィールドがない場合は、サーバの IP アドレスが使用されます。

リダイレクトでのポートの使用は、port_in_redirect ディレクティブで制御されます。

サーバ名ハッシュテーブルのバケットサイズを設定します。デフォルト値はプロセッサのキャッシュラインのサイズに依存します。ハッシュテーブルの設定の詳細については、別のドキュメントを参照してください。

サーバ名のハッシュテーブルの最大サイズを設定します。ハッシュテーブルの設定の詳細については、別のドキュメントを参照してください。

エラーページと "Server "レスポンスヘッダフィールドにnginxのバージョンを表示するかどうかを設定します。

buildパラメータ(1.11.10)では、nginxのバージョンと一緒にビルド名を表示することができます。

さらに、私たちの商用サブスクリプションの一部として、バージョン1.9.13から、エラーページの署名と "Server "応答ヘッダーフィールドの値は、変数を持つ文字列を使用して明示的に設定することができます。空の文字列は、"Server "フィールドの発行を無効にします。

サブリクエストのレスポンスボディを格納するために使用するバッファのサイズを設定します。デフォルトでは、バッファサイズは1メモリページに相当します。これは、プラットフォームに応じて、4K または 8K のいずれかです。しかし、これより小さくすることもできます。

このディレクティブは、メモリに保存されたレスポンスボディを持つサブリクエストにのみ適用されます。例えば、そのようなサブリクエストは SSI によって作成されます。

TCP_NODELAY オプションの使用を有効または無効にします。このオプションは、接続がキープアライブ状態に移行したときに有効になります。さらに、SSL 接続、バッファなしプロキシ、および WebSocket プロキシでも有効になります。

FreeBSD では TCP_NOPUSH ソケットオプション、Linux では TCP_CORK ソケットオプションの使用を有効または無効にします。これらのオプションは sendfile を使用している場合にのみ有効になります。このオプションを有効にすると

レスポンスヘッダとファイルの先頭を 1 つのパケットにまとめて送信します。 フルパケットでファイルを送信します。

指定された順番でファイルが存在するかどうかをチェックし、最初に見つかったファイルを リクエスト処理に使用します; 処理は現在のコンテキストで実行されます。ファイルへのパスは、ルートとエイリアスの記述内容に応じてfileパラメータから構築される。名前の最後にスラッシュを指定することで、ディレクトリの存在を確認することができます。どのファイルも見つからなかった場合は、最後のパラメータで指定された uriへの内部リダイレクトが行われます。例えば、以下のようになります。

以下の例に示すように、最後のパラメータは名前付きの場所を指すこともできます。バージョン 0.7.51 以降、最後のパラメータにはコードを指定することもできます。

以下の例では

try_files ディレクティブは

そして、ここです。

try_files は、FastCGI サーバーにリクエストを渡す前に PHP ファイルの存在をチェックします。

Wordpress と Joomla の例。

ファイル名の拡張子をレスポンスの MIME タイプにマップします。拡張子は大文字小文字を区別しません。複数の拡張子を 1 つのタイプにマップすることができます。

十分に完全なマッピングテーブルは conf/mime.types ファイルで nginx で配布されています。

特定の場所がすべてのリクエストに対して "application/octet-stream" MIME タイプをエミットするようにするには、以下の設定を使用します。

種類のハッシュテーブルのバケットサイズを設定します。ハッシュテーブルの設定の詳細は別のドキュメントに記載されています。

バージョン 1.5.13 より前のバージョンでは、デフォルト値はプロセッサのキャッシュラインのサイズに依存していました。

種類のハッシュテーブルの最大サイズを設定します。ハッシュテーブルの設定の詳細は別のドキュメントで説明します。

クライアントのリクエストヘッダフィールドでのアンダースコアの使用を有効または無効にします。アンダースコアの使用を無効にすると、 アンダースコアを含む名前のリクエストヘッダフィールドは無効とマークされ、 ignore_invalid_headers ディレクティブの対象となります。

このディレクティブがサーバレベルで指定されている場合、その値はサーバがデフォルトの場合にのみ使用されます。指定された値は、同じアドレスとポートで listen しているすべての仮想サーバにも適用されます。

変数のハッシュテーブルのバケットサイズを設定します。ハッシュテーブルの設定の詳細は別のドキュメントで説明しています。

変数のハッシュテーブルの最大サイズを設定します。ハッシュテーブルの設定の詳細は別のドキュメントに記載しています。

バージョン1.5.13以前では、デフォルト値は512でした。 埋め込み変数 ngx_http_core_module モジュールでは、Apache サーバの変数と一致する名前の埋め込み変数をサポートしています。まず、$http_user_agent や $http_cookie などのクライアントリクエストのヘッダフィールドを表す変数です。その他にも、以下のような変数があります。

$arg_name

リクエスト行の引数名

$args

リクエスト行の引数

$binary_remote_addr

バイナリ形式のクライアントアドレス、値の長さは IPv4 アドレスの場合は常に 4 バイト、IPv6 アドレスの場合は 16 バイトです。

$body_bytes_sent

この変数は Apache の mod_log_config モジュールの "%B" パラメータと互換性があります。

$bytes_sent

クライアントへの送信バイト数（1.3.8, 1.2.5

$connection

コネクションシリアル番号

$connection_requests

現在の接続によるリクエスト数

$content_length

"Content-Length "リクエストヘッダフィールド

$content_type

"Content-Type "リクエストヘッダフィールド

$cookie_name

名前クッキー

$document_root

現在のリクエストのルートまたはエイリアスディレクティブの値

$document_uri

$uri と同じ

$host

リクエスト行からのホスト名、"Host" リクエストヘッダフィールドからのホスト名、 リクエストにマッチするサーバ名の順です。

$hostname

ホスト名

$http_name

任意のリクエストヘッダフィールド; 変数名の最後の部分は、フィールド名を小文字に変換したもので、 ダッシュはアンダースコアで置き換えられます。

$https

接続がSSLモードで動作している場合は "on"、そうでない場合は空文字列

$is_args

リクエスト行に "?" 引数がある場合は空の文字列。

$limit_rate

この変数を設定すると応答速度の制限が可能になります。

$msec

現在の時刻をミリ秒単位の分解能で秒単位で表示 (1.3.9, 1.2.6)

$nginx_version

nginxバージョン

$pid

作業者プロセスのPID

$pipe

リクエストがパイプライン化されていれば "p"、そうでなければ"." (1.3.12, 1.2.7)

$proxy_protocol_addr

PROXY プロトコルヘッダからのクライアントアドレス (1.5.12) PROXY プロトコルは listen ディレクティブで proxy_protocol パラメータを設定することで事前に有効にしておく必要があります。

$proxy_protocol_port

クライアントポートを PROXY プロトコルヘッダ (1.11.0) から指定します。 PROXY プロトコルは、 listen ディレクティブで proxy_protocol パラメータを設定することで事前に有効にしておく必要があります。

$proxy_protocol_server_addr

サーバのアドレスを PROXY プロトコルヘッダから取得します (1.17.6)。 PROXY プロトコルは、 listen ディレクティブで proxy_protocol パラメータを設定することで事前に有効にしておく必要があります。

$proxy_protocol_server_port

サーバのポートを PROXY プロトコルヘッダから指定します (1.17.6)。 PROXY プロトコルは、 listen ディレクティブで proxy_protocol パラメータを設定することで事前に有効にしておく必要があります。

$query_string

$args と同じ

$realpath_root

現在のリクエストのルートまたはエイリアスディレクティブの値に対応する絶対パス名で、 シンボリックリンクはすべて実パスに解決されます。

$remote_addr

クライアントアドレス

$remote_port

ポートクライアント

$remote_user

基本認証で提供されるユーザ名

$request

フルオリジナルリクエスト行

$request_body

request body この変数の値は、リクエストボディがメモリバッファに読み込まれたときに、proxy_pass, fastcgi_pass, uwsgi_pass, scgi_pass 記述内容によって処理された場所で利用可能になります。

$request_body_file

要求本体付きの一時ファイル名 処理の最後に、ファイルを削除する必要があります。リクエストボディを常にファイルに書き込むには、client_body_in_file_only を有効にする必要があります。proxy_pass_request_body off、fastcgi_pass_request_body off、uwsgi_pass_request_body off、scgi_pass_request_body off 記述内容によって、一時ファイル名を渡す場合、リクエストボディを渡すことを無効にしなければなりません。

$request_completion

リクエストが完了した場合は "OK"、そうでない場合は空文字列

$request_filename

現在のリクエストのためのファイルパスで、ルートまたはエイリアス 記述内容とリクエストのURIに基づいています。

$request_id

16進数(1.11.0)のランダムな16バイトから生成された一意のリクエスト識別子

$request_length

リクエスト長 (リクエスト行、ヘッダ、リクエストボディを含む) (1.3.12, 1.2.7)

$request_method

リクエストメソッド、通常は "GET" または "POST" です。

$request_time

リクエストの処理時間をミリ秒単位で表したもの (1.3.9, 1.2.6); クライアントから最初のバイトが読み込まれてからの経過時間

$request_uri

完全な元のリクエスト URI (引数付き)

$scheme

リクエストスキーム、"http" または "https"

$sent_http_name

任意のレスポンスヘッダフィールド; 変数名の最後の部分は、フィールド名を小文字に変換したもので、ダッシュはアンダースコアに置き換えられます。

$sent_trailer_name

応答の最後に送信される任意のフィールド (1.13.2)。変数名の最後の部分は、フィールド名を小文字に変換したもので、ダッシュはアンダースコアで置き換えられます。

$server_addr

リクエストを受け付けたサーバのアドレス この変数の値を計算するには、通常、1回のシステムコールが必要です。システムコールを避けるために、listen 記述内容はアドレスを指定して bind パラメータを使用しなければなりません。

$server_name

リクエストを受け付けたサーバ名

$server_port

リクエストを受け付けたサーバのポート

$server_protocol

リクエストプロトコル、通常は "HTTP/1.0", "HTTP/1.1", "HTTP/2.0" です。

$status

応答 status (1.3.2, 1.2.2)

$tcpinfo_rtt, $tcpinfo_rttvar, $tcpinfo_snd_cwnd, $tcpinfo_rcv_space

クライアントのTCP接続に関する情報; TCP_INFOソケットオプションをサポートしているシステムで利用できます。

$time_iso8601

ISO 8601標準形式（1.3.12, 1.2.7）の現地時間

$time_local

コモンログ形式のローカルタイム (1.3.12, 1.2.7)

$uri

リクエスト中の現在の URI、正規化された uri の値は、内部リダイレクトやインデックスファイルを使用しているときなど、 リクエスト処理中に変更される可能性があります。

###Module ngx_http_access_module

ngx_http_access_module モジュールでは、特定のクライアントアドレスへのアクセスを制限することができます。

また、パスワードによるアクセス制限、サブリクエストの結果によるアクセス制限、 JWT によるアクセス制限も可能です。アドレスによるアクセスとパスワードによるアクセスの同時制限は、 satisfy ディレクティブで制御します。

設定例

ルールは、最初に一致するものが見つかるまで順番にチェックされます。この例では、IPv4 ネットワーク 10.1.1.1.0/16 と 192.168.1.1.1 を除く 192.168.1.0/24 と IPv6 ネットワーク 2001:0db8::/32 のみアクセスを許可しています。ルールが多い場合は ngx_http_geo_module モジュール変数の使用が望ましい。

記述内容

指定したネットワークまたはアドレスへのアクセスを許可します。特別な値 unix: を指定した場合 (1.5.1)、すべての UNIX ドメインソケットに対するアクセスを許可します。

指定したネットワークまたはアドレスへのアクセスを拒否します。特別な値 unix: を指定した場合 (1.5.1)、すべての UNIX ドメインソケットに対するアクセスを拒否します。

Module ngx_http_addition_module

ngx_http_addition_module は、レスポンスの前後にテキストを追加するフィルタです。このモジュールはデフォルトではビルドされていないので、 --with-http_addition_module 設定パラメータで有効にしなければなりません。

設定例

記述内容

指定されたサブリクエストを処理した結果として返されたテキストを、応答本文の前に追加します。パラメータとして空の文字列 ("") を指定すると、前の構成レベルから継承された追加をキャンセルします。

指定されたサブリクエストを処理した結果として返されるテキストを、応答本文の後に追加します。パラメータとして空の文字列 ("") を指定すると、前の構成レベルから継承された追加をキャンセルします。

指定したMIMEタイプのレスポンスに、"text/html "に加えて、指定したMIMEタイプのテキストを追加できるようにします。特別な値 "*" は任意の MIME タイプにマッチします (0.8.29)。

Module ngx_http_api_module

ngx_http_api_module モジュール (1.13.3) は、nginx を再設定することなく、各種ステータス情報へのアクセス、アップストリームサーバグループのオンザフライ設定、鍵と値のペアの管理を行うための REST API を提供します。

ngx_http_status_module および ngx_http_upstream_conf_module の後継モジュールです。 PATCH メソッドや POST メソッドを使用する場合は、ペイロードがクライアントのリクエストボディを読み込むためのバッファサイズを超えないように注意してください。

このモジュールは、当社の商用サブスクリプションの一部としてご利用いただけます。

設定例

すべての API リクエストは URI にサポートされている API のバージョンを含みます。この設定のAPIリクエストの例。

http://127.0.0.1/api/6/ http://127.0.0.1/api/6/nginx http://127.0.0.1/api/6/connections http://127.0.0.1/api/6/http/requests http://127.0.0.1/api/6/http/server_zones/server_backend http://127.0.0.1/api/6/http/caches/cache_backend http://127.0.0.1/api/6/http/upstreams/backend http://127.0.0.1/api/6/http/upstreams/backend/servers/ http://127.0.0.1/api/6/http/upstreams/backend/servers/1 http://127.0.0.1/api/6/http/keyvals/one?key=arg1 http://127.0.0.1/api/6/stream/ http://127.0.0.1/api/6/stream/server_zones/server_backend http://127.0.0.1/api/6/stream/upstreams/ http://127.0.0.1/api/6/stream/upstreams/backend http://127.0.0.1/api/6/stream/upstreams/backend/servers/1

記述内容

周囲の場所のREST APIインターフェイスをオンにします。この場所へのアクセスは制限されている必要があります。

writeパラメータは、APIを読み取り専用にするか、読み取り書き込みにするかを決定します。デフォルトでは、APIは読み取り専用です。

すべてのAPIリクエストは、URIにサポートされているAPIバージョンを含む必要があります。リクエストURIがロケーションプレフィックスと等しい場合、サポートされているAPIバージョンのリストが返されます。現在のAPIバージョンは「6」である。

リクエスト行のオプションの "fields "引数は、リクエストされたオブジェクトのどのフィールドを出力するかを指定する。

http://127.0.0.1/api/6/nginx?fields=version,build

指定されたゾーン内の仮想 http サーバまたはストリームサーバのステータス情報を収集できるようにします。複数のサーバが同じゾーンを共有することができます。

1.17.0 以降では、ロケーションごとにステータス情報を収集することができます。特別な値 off は、入れ子になったロケーションブロックでの統計情報の収集を無効にします。統計情報は、処理が終了する場所のコンテキストで収集されることに注意してください。リクエスト処理中に内部リダイレクトが発生した場合、元のロケーションとは異なる可能性があります。

Compatibility

バージョン6では、/stream/limit_conns/のデータが追加されました。 バージョン 6 で、/http/limit_conns/のデータが追加されました。 バージョン 6 で、/http/limit_reqs/ が追加されました。 バージョン 5 より、キーと値のペアの "expire" パラメータを設定・変更できるようになりました。 バージョン 5 で /resolvers/ データが追加されました。 バージョン 5 で /http/location_zones が追加されました。 nginx エラーオブジェクトの path と method フィールドはバージョン 4 で削除されました。これらのフィールドは以前のバージョンでも存在しますが、空の値を表示します。 バージョン 3 で /stream/zone_sync/ データが追加されました。 ドレインパラメータはバージョン2で追加されました。 バージョン 2 で /stream/keyvals/ データが追加されました。

Endpoints

/

サポートされている方法:

GET - Return list of root endpoints Returns a list of root endpoints.

応答可能:

200 - Success, returns an array of strings 404 - Unknown version (UnknownVersion), returns Error

/nginx

サポートされている方法:

GET - Return status of nginx running instance Returns nginx version, build name, address, number of configuration reloads, IDs of master and worker processes.

パラメータ要求::

fields (string, optional) Limits which fields of nginx running instance will be output. 応答可能:

200 - Success, returns nginx 404 - Unknown version (UnknownVersion), returns Error

/processes

サポートされている方法:

GET - Return nginx processes status Returns the number of abnormally terminated and respawned child processes.

応答可能:

200 - Success, returns Processes 404 - Unknown version (UnknownVersion), returns Error DELETE - Reset nginx processes statistics Resets counters of abnormally terminated and respawned child processes.

応答可能:

204 - Success 404 - Unknown version (UnknownVersion), returns Error 405 - Method disabled (MethodDisabled), returns Error

/connections

サポートされている方法:

GET - Return client connections statistics Returns statistics of client connections.

パラメータ要求::

fields (string, optional) Limits which fields of the connections statistics will be output. 応答可能:

200 - Success, returns Connections 404 - Unknown version (UnknownVersion), returns Error DELETE - Reset client connections statistics Resets statistics of accepted and dropped client connections.

応答可能:

204 - Success 404 - Unknown version (UnknownVersion), returns Error 405 - Method disabled (MethodDisabled), returns Error

/slabs/

サポートされている方法:

GET - Return status of all slabs Returns status of slabs for each shared memory zone with slab allocator.

パラメータ要求::

fields (string, optional) Limits which fields of slab zones will be output. If the “fields” value is empty, then only zone names will be output. 応答可能:

200 - 成功すると、すべてのスラブの "slab allocatorで共有されたメモリゾーン "オブジェクトのコレクションを返します。 404 - Unknown version (UnknownVersion), returns Error

/slabs/{slabZoneName}

すべてのメソッドに共通のパラメータ。 slabZoneName (文字列、必須) スラブアロケータを持つ共有メモリゾーンの名前です。 サポートされている方法:

GET - Return status of a slab Returns status of slabs for a particular shared memory zone with slab allocator.

パラメータ要求::

fields (string, optional) Limits which fields of the slab zone will be output. 応答可能:

200 - Success, returns Shared memory zone with slab allocator 404 - Slab not found (SlabNotFound), unknown version (UnknownVersion), returns Error DELETE - Reset slab statistics Resets the “reqs” and “fails” metrics for each memory slot.

応答可能:

204 - Success 404 - Slab not found (SlabNotFound), unknown version (UnknownVersion), returns Error 405 - Method disabled (MethodDisabled), returns Error

/http/

サポートされている方法:

GET - Return list of HTTP-related endpoints Returns a list of first level HTTP endpoints.

応答可能:

200 - Success, returns an array of strings 404 - Unknown version (UnknownVersion), returns Error

/http/requests

サポートされている方法:

GET - HTTP リクエストの統計情報を返します。 Returns status of client HTTP requests.

パラメータ要求::

fields (string, optional) Limits which fields of client HTTP requests statistics will be output. 応答可能:

200 - 成功すると、HTTP リクエストを返します。 404 - 不明なバージョン(UnknownVersion)の場合、エラーを返します。 DELETE - HTTP リクエストの統計情報をリセットします。 クライアントの総HTTPリクエスト数をリセットします。

応答可能:

204 - Success 404 - Unknown version (UnknownVersion), returns Error 405 - Method disabled (MethodDisabled), returns Error

/http/server_zones/
サポートされている方法:

GET - すべての HTTP サーバーゾーンのステータスを返します。

各HTTPサーバーゾーンのステータス情報を返します。

パラメータ要求::

フィールド (string, optional) サーバゾーンのどのフィールドを出力するかを制限する。fields "の値が空の場合、サーバーゾーン名のみが出力されます。

応答可能:

200 - 成功、すべての HTTP サーバーゾーンの "HTTP サーバーゾーン" オブジェクトのコレクションを返します。 404 - 不明なバージョン (UnknownVersion)、エラーを返します。 /http/server_zones/{httpServerZoneName}を使用します。 すべてのメソッドに共通のパラメータ。 httpServerZoneName (文字列、必須) HTTP サーバーゾーンの名前です。

サポートされている方法:

GET - HTTP サーバゾーンのステータスを返す 特定の HTTP サーバゾーンの状態を返します。

パラメータ要求:.

フィールド (文字列、オプション) サーバゾーンのどのフィールドを出力するかを制限します。

応答可能:

200 - 成功、HTTP サーバーゾーンを返します。 404 - サーバーゾーンが見つかりませんでした (ServerZoneNotFound)、バージョンが不明です (UnknownVersion)、エラーを返します。 DELETE - HTTP サーバゾーンの統計情報をリセットする 特定の HTTP サーバゾーンで受け入れられたリクエストと破棄されたレスポンス、受信されたバイト数、送信されたバイト数の統計情報をリセットします。

応答可能。

204 - 成功 404 - サーバーゾーンが見つかりませんでした (ServerZoneNotFound)、バージョンが不明です (UnknownVersion)、エラーを返します。 405 - メソッドが無効 (MethodDisabled)、エラーを返します。

/http/location_zones/
サポートされている方法:

GET - すべての HTTP ロケーションゾーンのステータスを返す HTTPロケーションゾーンごとのステータス情報を返します。

パラメータ要求::

フィールド(string, optional) ロケーションゾーンのどのフィールドを出力するかを制限する。fields "の値が空の場合、ゾーン名のみが出力されます。 応答可能。

200 - 成功、すべての HTTP ロケーションゾーンの "HTTP Location Zone" オブジェクトのコレクションを返します。 404 - 不明なバージョン (UnknownVersion)、エラーを返します。 /http/location_zones/{httpLocationZoneName}。 すべてのメソッドに共通のパラメータ。 httpLocationZoneName (文字列、必須) HTTPロケーションゾーンの名前です。

サポートされている方法:

GET - HTTP ロケーションゾーンのステータスを返す 特定の HTTP ロケーションゾーンのステータスを返します。

パラメータ要求:.

フィールド (文字列、オプション) ロケーションゾーンのどのフィールドを出力するかを制限します。 応答可能。

200 - 成功、HTTPロケーションゾーンを返します。 404 - ロケーションゾーンが見つかりませんでした (LocationZoneNotFound)、バージョンが不明です (UnknownVersion)、エラーを返します。 DELETE - ロケーションゾーンの統計情報をリセットします。 特定のロケーションゾーンで受け入れられたリクエストと破棄されたリクエスト、レスポンス、受信したバイト、送信したバイトの統計情報をリセットします。

応答可能:

204 - 成功 404 - ロケーションゾーンが見つからない (LocationZoneNotFound)、バージョンが不明 (UnknownVersion)、エラーを返します。 405 - メソッドが無効（MethodDisabled）になった場合、エラーを返します。

/http/caches/
サポートされている方法。

GET - すべてのキャッシュのステータスを返します proxy_cache_path およびその他の "*_cache_path" 記述内容によって設定された各キャッシュの状態を返します。

パラメータ要求:.

フィールド (文字列、オプション) キャッシュゾーンのどのフィールドを出力するかを制限します。fields" 値が空の場合、キャッシュゾーンの名前だけが出力されます。 応答可能:

200 - 成功、すべての HTTP キャッシュの "HTTP Cache" オブジェクトのコレクションを返します。 404 - 不明なバージョン (UnknownVersion)、エラーを返します。 /http/caches/{httpCacheZoneName}の場合 すべてのメソッドに共通のパラメータ。 httpCacheZoneName (文字列、必須) キャッシュゾーンの名前。

サポートされている方法:

GET - キャッシュのステータスを返す 特定のキャッシュの状態を返します。

パラメータ要求:.

フィールド (文字列、オプション) キャッシュゾーンのどのフィールドを出力するかを制限します。 応答可能。

200 - 成功、HTTP キャッシュを返します。 404 - キャッシュが見つかりませんでした (CacheNotFound)、バージョンが不明です (UnknownVersion)、エラーを返します。 DELETE - キャッシュ統計情報をリセットする 特定のキャッシュゾーンのキャッシュヒット/ミスの統計情報をリセットします。

応答可能。

204 - 成功 404 - キャッシュが見つかりませんでした (CacheNotFound)、バージョンが不明です (UnknownVersion)、エラーを返します。 405 - メソッドが無効 (MethodDisabled)、エラーを返します。

/http/limit_conns/
サポートされている方法:

GET - すべての HTTP limit_conn ゾーンのステータスを返す 各 HTTP limit_conn ゾーンのステータス情報を返します。

パラメータ要求:.

フィールド (文字列、オプション) limit_connゾーンのどのフィールドを出力するかを制限する。fields" の値が空の場合、ゾーン名のみが出力されます。 応答可能。

200 - 成功し、すべての HTTP リミットコンズの "HTTP Connections Limiting" オブジェクトのコレクションを返します。 404 - 不明なバージョン (UnknownVersion)、エラーを返します。 /http/limit_conns/{httpLimitConnZoneName}を使用します。 すべてのメソッドに共通のパラメータ。 httpLimitConnZoneName (文字列、必須) limit_connゾーンの名前。 サポートされている方法。

GET - HTTP limit_conn ゾーンのステータスを返します。 特定の HTTP limit_conn ゾーンの状態を返します。

パラメータ要求:.

フィールド (文字列、オプション) limit_connゾーンのどのフィールドを出力するかを制限します。 応答可能。

200 - 成功、HTTP 接続の制限を返します。 404 - Limit_conn not found (LimitConnNotFound)、バージョン不明 (UnknownVersion)、エラーを返します。 DELETE - HTTP limit_conn ゾーンの統計情報をリセットする 接続制限の統計情報をリセットします。

応答可能:

204 - 成功 404 - Limit_conn not found (LimitConnNotFound)、バージョン不明 (UnknownVersion)、エラーを返します。 405 - メソッドが無効 (MethodDisabled)、エラーを返します。

/http/limit_reqs/

サポートされている方法。

GET - すべての HTTP limit_req ゾーンのステータスを返します。 HTTP limit_reqゾーンごとのステータス情報を返します。

パラメータ要求:.

フィールド (文字列、オプション) limit_reqゾーンのどのフィールドを出力するかを制限する。fields" の値が空の場合、ゾーン名のみが出力されます。 応答可能。

200 - 成功、すべての HTTP リミットリクエストの "HTTP Requests Rate Limiting" オブジェクトのコレクションを返します。 404 - 不明なバージョン (UnknownVersion)、エラーを返します。 /http/limit_reqs/{httpLimitReqZoneName}の場合 すべてのメソッドに共通のパラメータ。 httpLimitReqZoneName (文字列、必須) limit_reqゾーンの名前。

サポートされている方法:

GET - HTTP limit_req ゾーンのステータスを返す 特定の HTTP limit_req ゾーンの状態を返します。

パラメータ要求:.

フィールド (文字列、オプション) limit_reqゾーンのどのフィールドを出力するかを制限します。 応答可能。

200 - 成功、HTTP リクエストレートの制限を返します。 404 - limit_req が見つかりませんでした (LimitReqNotFound)、バージョンが不明です (UnknownVersion)、エラーを返します。 DELETE - HTTP limit_req ゾーンの統計情報をリセットする リクエスト制限の統計情報をリセットします。

応答可能。

204 - 成功 404 - limit_req が見つかりませんでした (LimitReqNotFound)、バージョンが不明です (UnknownVersion)、エラーを返します。 405 - メソッドが無効 (MethodDisabled)、エラーを返します。

/http/upstreams/
サポートされている方法:

GET - すべての HTTP アップストリームサーバグループのステータスを返します。 各 HTTP アップストリームサーバグループとそのサーバの状態を返します。

パラメータ要求:.

フィールド (文字列、オプション) アップストリームサーバグループのどのフィールドを出力するかを制限する。fields" の値が空の場合、アップストリームの名前のみが出力される。 応答可能。

200 - 成功、すべての HTTP アップストリームの "HTTP Upstream" オブジェクトのコレクションを返します。 404 - 不明なバージョン (UnknownVersion)、エラーを返します。 /http/upstreams/{httpUpstreamName}///。 すべてのメソッドに共通のパラメータ。 httpUpstreamName (文字列、必須) HTTPアップストリームサーバーグループの名前です。

サポートされている方法:

GET - HTTP アップストリームサーバグループのステータスを返す 特定の HTTP アップストリームサーバグループとそのサーバの状態を返します。

パラメータ要求:.

フィールド (文字列、オプション) アップストリームサーバグループのどのフィールドを出力するかを制限します。 応答可能。

200 - 成功、HTTP アップストリームを返します。 400 - アップストリームが静的 (UpstreamStatic)、エラーを返します。 404 - 不明なバージョン (UnknownVersion)、アップストリームが見つからない (UpstreamNotFound)、エラーを返します。 DELETE - HTTP アップストリームサーバグループの統計情報をリセットする アップストリームサーバグループ内の各アップストリームサーバの統計情報とキューの統計情報をリセットします。

応答可能:

204 - 成功 400 - アップストリームが静的 (UpstreamStatic)、エラーを返します。 404 - 不明なバージョン (UnknownVersion)、アップストリームが見つからない (UpstreamNotFound)、エラーを返します。 405 - メソッドが無効 (MethodDisabled)、エラーを返します。 /http/upstreams/{httpUpstreamName}/servers/ すべてのメソッドに共通のパラメータ。 httpUpstreamName (文字列、必須) 上流のサーバーグループの名前です。

サポートされている方法:

GET - HTTP アップストリームサーバグループ内のすべてのサーバの構成を返す 特定のHTTPアップストリームサーバグループ内の各サーバの設定を返します。

応答可能。

200 - 成功、HTTP アップストリームサーバーの配列を返します。 400 - アップストリームが静的 (UpstreamStatic)、エラーを返します。 404 - 不明なバージョン (UnknownVersion)、アップストリームが見つからない (UpstreamNotFound)、エラーを返します。 POST - HTTP アップストリームサーバーグループにサーバーを追加する HTTP アップストリーム サーバー グループに新しいサーバーを追加します。サーバパラメータは JSON 形式で指定します。

パラメータ要求::

postHttpUpstreamServer（HTTPアップストリームサーバ、必須 新サーバーのアドレスとその他のオプションパラメータをJSON形式で指定します。ID」、「バックアップ」、「サービス」のパラメータは変更できません。 応答可能:

201 - Created, returns HTTP Upstream Server 400 - Upstream が静的 (UpstreamStatic)、無効な "パラメータ" 値 (UpstreamConfFormatError)、"サーバー" 引数が見つからない (UpstreamConfFormatError)、パラメータ "名前" が不明 (UpstreamConfFormatError)、入れ子になったオブジェクトまたはリスト (UpstreamConfFormatError)。"error" while parsing (UpstreamBadAddress), service upstream "host" may not have port (UpstreamBadAddress), service upstream "host" requires domain name (UpstreamBadAddress), invalid "weight" (UpstreamBadWeight)。invalid "max_conns" (UpstreamBadMaxConns), invalid "max_fails" (UpstreamBadMaxFails), invalid "fail_timeout" (UpstreamBadFailTimeout), invalid "slow_start" (UpstreamBadSlowStart), read request body failed BodyReadError)。ルートが長すぎます (UpstreamBadRoute), "service" が空です (UpstreamBadService), リゾルバが定義されていません (UpstreamConfNoResolver), 上流の "name" にバックアップがありません (UpstreamNoBackup), 上流の "name" のメモリが枯渇しました (UpstreamOutOfMemory), エラーを返します。 405 - メソッドが無効 (MethodDisabled)、エラーを返します。 409 - エントリが存在します (EntryExists)、エラーを返します。 415 - JSON エラー (JsonError)、エラーを返します。 /http/upstreams/{httpUpstreamName}/servers/{httpUpstreamServerId}/servers/{httpUpstreamServerId}。 すべてのメソッドに共通のパラメータ。 httpUpstreamName (文字列、必須) アップストリームサーバグループの名前。 httpUpstreamServerId (文字列、必須) サーバーのIDです。

サポートされている方法:

GET - HTTP アップストリームサーバグループ内のサーバの構成を返す HTTPアップストリームサーバグループ内の特定のサーバの設定を返します。

応答可能。

200 - 成功、HTTP アップストリームサーバを返します 400 - アップストリームが静的です (UpstreamStatic)、サーバ ID が無効です (UpstreamBadServerId)、エラーを返します。 404 - ID "id" を持つサーバーが存在しません (UpstreamServerNotFound)、不明なバージョン (UnknownVersion)、アップストリームが見つかりません (UpstreamNotFound)、エラーを返します。 PATCH - HTTP アップストリームサーバーグループのサーバーを変更する HTTP アップストリームサーバーグループ内の特定のサーバーの設定を変更します。サーバパラメータはJSON形式で指定します。

パラメータ要求::

patchHttpUpstreamServer (HTTPアップストリームサーバ、必須) JSON形式で指定されたサーバーパラメータ。ID」「backup」「service」パラメータは変更できません。 応答可能:

200 - Success, returns HTTP Upstream Server 400 - Upstream is static (UpstreamStatic)、無効な "パラメータ" 値 (UpstreamConfFormatError)、不明なパラメータ "名前" (UpstreamConfFormatError)、入れ子になったオブジェクトまたはリスト (UpstreamConfFormatError)、解析中の "エラー" (UpstreamBadAddress)。無効な "server" 引数 (UpstreamBadAddress)、無効なサーバ ID (UpstreamBadServerId)、無効な "weight" (UpstreamBadWeight)、無効な "max_conns" (UpstreamBadMaxConns)、無効な "max_fails" (UpstreamBadMaxFails)。無効な "fail_timeout" (UpstreamBadFailTimeout)、無効な "slow_start" (UpstreamBadSlowStart)、リクエストボディの読み込みに失敗した BodyReadError)、ルートが長すぎる (UpstreamBadRoute)、"service" が空 (UpstreamBadService)。サーバの "ID "アドレスが不変 (UpstreamServerImmutable)、サーバの "ID "重量が不変 (UpstreamServerWeightImmutable)、上流の "name "メモリが枯渇 (UpstreamOutOfMemory)、エラーを返します。 404 - ID "id" を持つサーバーが存在しません (UpstreamServerNotFound)、不明なバージョン (UnknownVersion)、アップストリームが見つかりません (UpstreamNotFound)、エラーを返します。 405 - メソッドが無効 (MethodDisabled)、エラーを返します。 415 - JSON エラー (JsonError)、エラーを返します。 DELETE - HTTP アップストリームサーバーグループからサーバーを削除する HTTP アップストリーム サーバー グループからサーバーを削除します。

応答可能:

200 - 成功、HTTP アップストリームサーバーの配列を返します。 400 - Upstream is static (UpstreamStatic), invalid server ID (UpstreamBadServerId), server "id" not removable (UpstreamServerImmutable), returns Error. 404 - ID "id" を持つサーバーが存在しません (UpstreamServerNotFound)、不明なバージョン (UnknownVersion)、アップストリームが見つかりません (UpstreamNotFound)、エラーを返します。 405 - メソッドが無効 (MethodDisabled)、エラーを返します。 /http/keyvals/

サポートされている方法:

GET - すべての HTTP keyval ゾーンからキーと値のペアを返す HTTP keyval 共有メモリゾーンごとに、キーと値のペアを返します。

パラメータ要求:.

フィールド (文字列、オプション) fields "の値が空の場合は、HTTP keyvalゾーン名のみが出力されます。

応答可能:

200 - 成功した場合、すべての HTTP キーバルの "HTTP Keyval Shared Memory Zone" オブジェクトのコレクションを返します。 404 - 不明なバージョン (UnknownVersion)、エラーを返します。 /http/keyvals/{httpKeyvalZoneName}。 すべてのメソッドに共通のパラメータ。 httpKeyvalZoneName (文字列、必須) HTTP keyval 共有メモリゾーンの名前。 サポートされている方法:

GET - HTTP keyval ゾーンからキーと値のペアを返す 特定の HTTP keyval 共有メモリゾーンに格納されているキーと値のペアを返します。

パラメータ要求:.

キー (文字列、オプション) HTTP keyvalゾーンから特定のキーと値のペアを取得します。

応答可能:

200 - 成功、HTTP Keyval 共有メモリゾーンを返します。 404 - Keyval が見つかりません (KeyvalNotFound)、keyval key が見つかりません (KeyvalKeyNotFound)、不明なバージョン (UnknownVersion)、エラーを返します。 POST - HTTP keyval ゾーンにキーと値のペアを追加する HTTP keyval 共有メモリゾーンに新しい key-value ペアを追加します。HTTP keyval 共有メモリゾーンが空の場合、複数のキー値ペアを入力することができます。

パラメータ要求:.

キー値 (HTTP Keyval 共有メモリゾーン、必須) キーと値のペアは、JSON形式で指定されます。HTTP keyval共有メモリゾーンが空の場合は、複数の鍵と値のペアを入力することができます。有効期限をミリ秒単位で指定するには、 keyval_zone ディレクティブの timeout パラメータを上書きする expire パラメータを使用します。

応答可能:

201 - 作成 400 - 無効な JSON (KeyvalFormatError)、無効なキー形式 (KeyvalFormatError)、キーが必要です (KeyvalFormatError)、keyval タイムアウトが有効になっていません (KeyvalFormatError)、1 つのキーしか追加できません (KeyvalFormatError)、要求本文の読み取りに失敗しました BodyReadError)、エラーを返します。 404 - Keyval が見つかりませんでした (KeyvalNotFound)、バージョンが不明です (UnknownVersion)、エラーを返します。 405 - メソッドが無効 (MethodDisabled)、エラーを返します。 409 - エントリが存在します (EntryExists)、キーが既に存在します (KeyvalKeyExists)、エラーを返します。 413 - 要求エンティティが大きすぎます。 415 - JSON エラー(JsonError)、エラーを返します。 PATCH - キー値を変更したり、キーを削除したりする キーと値のペアで選択されているキーの値を変更したり、キーの値を NULL に設定してキーを削除したり、キーと値のペアの有効期限を変更したりします。クラスタ内のキーバリューゾーンの同期を有効にしている場合は、対象となるクラスタノードのキーのみを削除します。鍵と値のペアの有効期限をミリ秒単位で指定するには、 keyval_zone ディレクティブの timeout パラメータを上書きする expire パラメータを使用します。

パラメータ要求::

httpKeyvalZoneKeyValue (HTTP Keyval共有メモリゾーン、必須) キーの新しい値をJSON形式で指定します。

応答可能:

204 - 成功 400 - 無効な JSON (KeyvalFormatError)、キーが必要です (KeyvalFormatError)、keyval タイムアウトが有効になっていません (KeyvalFormatError)、1 つのキーしか更新できません (KeyvalFormatError)、要求本文の読み取りに失敗しました BodyReadError)、エラーを返します。 404 - Keyval が見つかりません (KeyvalNotFound)、keyval key が見つかりません (KeyvalKeyNotFound)、不明なバージョン (UnknownVersion)、エラーを返します。 405 - メソッドが無効 (MethodDisabled)、エラーを返します。 413 - 要求エンティティが大きすぎます。 415 - JSON エラー (JsonError)、エラーを返します。 DELETE - HTTP keyval ゾーンを空にする HTTP keyval 共有メモリゾーンからすべてのキーと値のペアを削除します。クラスタ内の keyval ゾーンの同期化が有効な場合、ターゲットのクラスタノード上でのみ keyval ゾーンを空にします。

応答可能:

204 - 成功 404 - Keyval が見つかりませんでした (KeyvalNotFound)、バージョンが不明です (UnknownVersion)、エラーを返します。 405 - メソッドが無効 (MethodDisabled)、エラーを返します。

/stream/
サポートされている方法:

GET - ストリーム関連のエンドポイントのリストを返す 最初のレベルのストリームエンドポイントのリストを返します。

応答可能:

200 - 成功、文字列の配列を返します。 404 - 不明なバージョン (UnknownVersion)、エラーを返します。

/stream/server_zones/
サポートされている方法:

GET - すべてのストリームサーバゾーンのステータスを返します 各ストリームサーバーゾーンのステータス情報を返します。

パラメータ要求:

フィールド サーバゾーンのどのフィールドを出力するかを制限する。fields "の値が空の場合、サーバーゾーン名のみが出力されます。

応答可能:

200 - 成功、すべてのストリームサーバーゾーンの "Stream Server Zone" オブジェクトのコレクションを返します。 404 - 不明なバージョン (UnknownVersion)、エラーを返します。 /stream/server_zones/{streamServerZoneName}を使用します。 すべてのメソッドに共通のパラメータ。 streamServerZoneName (文字列、必須) ストリームサーバーゾーンの名前です。 サポートされている方法。

GET - ストリームサーバーゾーンのステータスを返します。 特定のストリームサーバーゾーンの状態を返します。

パラメータ要求:

フィールド サーバゾーンのどのフィールドを出力するかを制限します。 応答可能。

200 - 成功、ストリームサーバゾーンを返します。 404 - サーバーゾーンが見つかりませんでした (ServerZoneNotFound)、バージョンが不明です (UnknownVersion)、エラーを返します。 DELETE - ストリームサーバゾーンの統計情報をリセットする 特定のストリームサーバーゾーンでの、受け入れられた接続、破棄された接続、セッション、受信および送信されたバイト数の統計をリセットします。

応答可能:

204 - 成功 404 - サーバーゾーンが見つかりませんでした (ServerZoneNotFound)、バージョンが不明です (UnknownVersion)、エラーを返します。 405 - メソッドが無効 (MethodDisabled)、エラーを返します。

/stream/limit_conns/
サポートされている方法:

GET - すべてのストリーム limit_conn ゾーンのステータスを返す ストリーム limit_conn ゾーンごとのステータス情報を返します。

パラメータ要求::

fields (string, optional) limit_connゾーンのどのフィールドを出力するかを制限する。fields" の値が空の場合、ゾーン名のみが出力されます。

応答可能:

200 - 成功、すべてのストリーム制限接続に対して "Stream Connections Limiting" オブジェクトのコレクションを返します。 404 - 不明なバージョン (UnknownVersion)、エラーを返します。 /stream/limit_conns/{streamLimitConnZoneName}を使用します。 すべてのメソッドに共通のパラメータ。 streamLimitConnZoneName (文字列、必須) LIMIT_CONNゾーンの名前。

サポートされている方法:

GET - ストリーム limit_conn ゾーンのステータスを返す 特定のストリーム limit_conn ゾーンの状態を返します。

パラメータ要求::

fields (string, optional) limit_connゾーンのどのフィールドを出力するかを制限します。

応答可能:

200 - 成功した場合は、ストリーム接続の制限を返します。 404 - Limit_conn not found (LimitConnNotFound)、バージョン不明 (UnknownVersion)、エラーを返します。 DELETE - ストリーム limit_conn ゾーンの統計情報をリセットする 接続制限の統計情報をリセットします。

応答可能:

204 - 成功 404 - Limit_conn not found (LimitConnNotFound)、バージョン不明 (UnknownVersion)、エラーを返します。 405 - メソッドが無効 (MethodDisabled)、エラーを返します。

/stream/upstreams/
サポートされている方法:

GET - すべてのストリームアップストリームサーバグループのステータスを返します。 各ストリームアップストリームサーバーグループとそのサーバーの状態を返します。

パラメータ要求::

fields (string, optional) アップストリームサーバグループのどのフィールドを出力するかを制限する。fields" の値が空の場合、アップストリームの名前のみが出力される。

応答可能。

200 - 成功、すべてのストリームアップストリームの "Stream Upstream" オブジェクトのコレクションを返します。 404 - 不明なバージョン (UnknownVersion)、エラーを返します。 /stream/upstreams/{streamUpstreamName}/////////. すべてのメソッドに共通のパラメータ。 streamUpstreamName (文字列、必須) ストリームアップストリームサーバーグループの名前です。

サポートされている方法:

GET - ストリーム上流サーバグループのステータスを返す 特定のストリームアップストリームサーバーグループとそのサーバーの状態を返します

パラメータ要求::

fields (string, optional) アップストリームサーバグループのどのフィールドを出力するかを制限します。 応答可能。

200 - 成功、ストリーム アップストリームを返します。 400 - アップストリームが静的 (UpstreamStatic)、エラーを返します。 404 - 不明なバージョン (UnknownVersion)、アップストリームが見つからない (UpstreamNotFound)、エラーを返します。 DELETE - ストリームアップストリームサーバーグループの統計情報をリセットする アップストリームサーバーグループ内の各アップストリームサーバーの統計情報をリセットします。

応答可能:

204 - 成功 400 - アップストリームが静的 (UpstreamStatic)、エラーを返します。 404 - 不明なバージョン (UnknownVersion)、アップストリームが見つからない (UpstreamNotFound)、エラーを返します。 405 - メソッドが無効 (MethodDisabled)、エラーを返します。

/stream/upstreams/{streamUpstreamName}/servers/

すべてのメソッドに共通のパラメータ。 streamUpstreamName (文字列、必須) 上流のサーバーグループの名前です。 サポートされている方法:

GET - ストリームアップストリームサーバグループ内のすべてのサーバの構成を返す 特定のストリームアップストリームサーバーグループ内の各サーバーの設定を返します

応答可能:

200 - 成功、Stream Upstream Servers の配列を返します。 400 - アップストリームが静的 (UpstreamStatic)、エラーを返します。 404 - 不明なバージョン (UnknownVersion)、アップストリームが見つからない (UpstreamNotFound)、エラーを返します。 POST - ストリーム上流のサーバーグループにサーバーを追加する ストリームアップストリームのサーバーグループに新しいサーバーを追加します。サーバーのパラメータは JSON 形式で指定します。

パラメータ要求::

postStreamUpstreamServer（ストリームアップストリームサーバー、必須 新サーバーのアドレスとその他のオプションパラメータをJSON形式で指定します。ID」、「バックアップ」、「サービス」のパラメータは変更できません。 応答可能:

201 - 作成され、ストリームアップストリームサーバーを返します。 400 - Upstream is static (UpstreamStatic)、無効な "parameter" 値 (UpstreamConfFormatError)、"server" 引数の欠落 (UpstreamConfFormatError)、不明なパラメータ "name" (UpstreamConfFormatError)、入れ子になったオブジェクトまたはリスト (UpstreamConfFormatError)。"error" while parsing (UpstreamBadAddress)、サーバ "host" にポートがない (UpstreamBadAddress)、サービス上流の "host" にポートがない可能性がある (UpstreamBadAddress)、サービス上流の "host" にドメイン名が必要 (UpstreamBadAddress)。無効な "weight" (UpstreamBadWeight), 無効な "max_conns" (UpstreamBadMaxConns), 無効な "max_fails" (UpstreamBadMaxFails), 無効な "fail_timeout" (UpstreamBadFailTimeout), 無効な "slow_start" (UpstreamBadSlowStart)。"service" が空です (UpstreamBadService)、解決するリゾルバが定義されていません (UpstreamConfNoResolver)、上流の "name" にバックアップがありません (UpstreamNoBackup)、上流の "name" のメモリが枯渇しました (UpstreamOutOfMemory)、リクエストボディの読み取りに失敗しました BodyReadError)、エラーを返します。 404 - 不明なバージョン (UnknownVersion)、アップストリームが見つからない (UpstreamNotFound)、エラーを返します。 405 - メソッドが無効 (MethodDisabled)、エラーを返します。 409 - エントリが存在します (EntryExists)、エラーを返します。 415 - JSON エラー (JsonError)、エラーを返します。 /stream/upstreams/{streamUpstreamName}/servers/{streamUpstreamServerId}を使用します。 すべてのメソッドに共通のパラメータ。 streamUpstreamName (文字列、必須) アップストリームサーバーグループの名前。 streamUpstreamServerId (文字列、必須) サーバーのIDです。 サポートされている方法:

GET - ストリーム上流のサーバグループ内のサーバの構成を返します。 ストリームアップストリームサーバーグループ内の特定のサーバーの設定を返します。

応答可能:

200 - 成功、Stream Upstream Server を返します。 400 - アップストリームが静的です (UpstreamStatic)、サーバ ID が無効です (UpstreamBadServerId)、エラーを返します。 404 - 不明なバージョン (UnknownVersion)、アップストリームが見つからない (UpstreamNotFound)、ID "id" を持つサーバーが存在しない (UpstreamServerNotFound)、エラーを返します。 PATCH - ストリーム上流のサーバーグループ内のサーバーを変更する ストリームアップストリームのサーバーグループ内の特定のサーバーの設定を変更します。サーバパラメータはJSON形式で指定します。

パラメータ要求::

patchStreamUpstreamServer (Stream Upstream Server、必須) JSON形式で指定されたサーバーパラメータ。ID"、"backup"、"service "パラメータは変更できません。 応答可能。

200 - 成功、Stream Upstream Server を返します。 400 - アップストリームが静的 (UpstreamStatic)、無効な "パラメータ" 値 (UpstreamConfFormatError)、不明なパラメータ "名前" (UpstreamConfFormatError)、入れ子になったオブジェクトまたはリスト (UpstreamConfFormatError)、解析中の "エラー" (UpstreamBadAddress)。無効な "server" 引数 (UpstreamBadAddress)、サーバ "host" にポートがない (UpstreamBadAddress)、無効なサーバ ID (UpstreamBadServerId)、無効な "weight" (UpstreamBadWeight)、無効な "max_conns" (UpstreamBadMaxConns)。無効な "max_fails" (UpstreamBadMaxFails)、無効な "fails_timeout" (UpstreamBadFailTimeout)、無効な "slow_start" (UpstreamBadSlowStart)、リクエストボディの読み取りに失敗しました BodyReadError)、"service" が空です (UpstreamBadService)。サーバの "ID "アドレスが不変 (UpstreamServerImmutable)、サーバの "ID "重量が不変 (UpstreamServerWeightImmutable)、上流の "name "メモリが枯渇 (UpstreamOutOfMemory)、エラーを返します。 404 - ID "id" を持つサーバーが存在しません (UpstreamServerNotFound)、不明なバージョン (UnknownVersion)、アップストリームが見つかりません (UpstreamNotFound)、エラーを返します。 405 - メソッドが無効 (MethodDisabled)、エラーを返します。 415 - JSON エラー (JsonError)、エラーを返します。 DELETE - ストリーム上流のサーバーグループからサーバーを削除する ストリームサーバーグループからサーバーを削除します。

応答可能:

200 - 成功、Stream Upstream Servers の配列を返します。 400 - Upstream is static (UpstreamStatic), invalid server ID (UpstreamBadServerId), server "id" not removable (UpstreamServerImmutable), returns Error. 404 - ID "id" を持つサーバーが存在しません (UpstreamServerNotFound)、不明なバージョン (UnknownVersion)、アップストリームが見つかりません (UpstreamNotFound)、エラーを返します。 405 - メソッドが無効 (MethodDisabled)、エラーを返します。 /ストリーム/keyvals/ サポートされている方法:

GET - すべてのストリームキーvalゾーンからキーと値のペアを返す ストリーム keyval 共有メモリゾーンごとに、キーと値のペアを返します。

パラメータ要求:.

フィールド (文字列、オプション) fields "の値が空の場合は、ストリームキーバルのゾーン名のみが出力される。

応答可能:

200 - 成功、すべてのストリームキーバルの "Stream Keyval Shared Memory Zone" オブジェクトのコレクションを返します。 404 - 不明なバージョン (UnknownVersion)、エラーを返します。 /stream/keyvals/{streamKeyvalZoneName}を使用します。 すべてのメソッドに共通のパラメータ。 streamKeyvalZoneName (文字列、必須) ストリームキーバルの共有メモリゾーンの名前。 サポートされている方法:

GET - ストリームの keyval ゾーンからキーと値のペアを返す 特定のストリーム keyval 共有メモリゾーンに格納されているキーと値のペアを返します。

パラメータ要求::

key (string, optional) ストリームのkeyvalゾーンから特定のキーと値のペアを取得します。

応答可能。

200 - 成功、ストリームキーバル共有メモリゾーンを返します。 404 - Keyval が見つかりません (KeyvalNotFound)、keyval key が見つかりません (KeyvalKeyNotFound)、不明なバージョン (UnknownVersion)、エラーを返します。 POST - ストリームの keyval ゾーンにキーと値のペアを追加する ストリームの keyval 共有メモリゾーンに新しいキーと値のペアを追加します。ストリームの keyval 共有メモリゾーンが空の場合、複数のキー値ペアを入力することができます。

パラメータ要求::

キー値（ストリームキーバル共有メモリゾーン、必須 キーと値のペアは、JSON形式で指定されます。ストリームのkeyval共有メモリゾーンが空の場合は、複数の鍵と値のペアを入力することができます。keyval_zone ディレクティブの timeout パラメータを上書きする expire パラメータを使用して、キーと値のペアにミリ秒単位の有効期限を指定することができます。

応答可能:

201 - 作成 400 - 無効な JSON (KeyvalFormatError)、無効なキー形式 (KeyvalFormatError)、キーが必要です (KeyvalFormatError)、keyval タイムアウトが有効になっていません (KeyvalFormatError)、1 つのキーしか追加できません (KeyvalFormatError)、要求本文の読み取りに失敗しました BodyReadError)、エラーを返します。 404 - Keyval が見つかりませんでした (KeyvalNotFound)、バージョンが不明です (UnknownVersion)、エラーを返します。 405 - メソッドが無効 (MethodDisabled)、エラーを返します。 409 - エントリが存在します (EntryExists)、キーが既に存在します (KeyvalKeyExists)、エラーを返します。 413 - 要求エンティティが大きすぎます。 415 - JSON エラー (JsonError)、エラーを返します。 PATCH - キー値を変更したり、キーを削除したりする キーと値のペアで選択されているキーの値を変更したり、キーの値をNULLに設定してキーを削除したり、キーと値のペアの有効期限を変更したりします。クラスタ内のKeyvalゾーンの同期を有効にしている場合は、対象のクラスタノードのみで鍵を削除します。有効期限は、keyval_zone ディレクティブの timeout パラメータを上書きする expire パラメータでミリ秒単位で指定します。

パラメータ要求::

streamKeyvalZoneKeyValue（ストリームKeyval共有メモリゾーン、必須 キーの新しい値をJSON形式で指定します。

応答可能:

204 - 成功 400 - 無効な JSON (KeyvalFormatError)、キーが必要です (KeyvalFormatError)、keyval タイムアウトが有効になっていません (KeyvalFormatError)、1 つのキーしか更新できません (KeyvalFormatError)、要求本文の読み取りに失敗しました BodyReadError)、エラーを返します。 404 - Keyval が見つかりません (KeyvalNotFound)、keyval key が見つかりません (KeyvalKeyNotFound)、不明なバージョン (UnknownVersion)、エラーを返します。 405 - メソッドが無効 (MethodDisabled)、エラーを返します。 413 - 要求エンティティが大きすぎます。 415 - JSON エラー (JsonError)、エラーを返します。 DELETE - ストリームキーバルゾーンを空にする ストリームの keyval 共有メモリゾーンからすべての key-value ペアを削除します。クラスタ内の keyval ゾーンの同期化が有効な場合、ターゲットのクラスタノード上でのみ keyval ゾーンを空にします。

応答可能:

204 - 成功 404 - Keyval が見つかりませんでした (KeyvalNotFound)、バージョンが不明です (UnknownVersion)、エラーを返します。 405 - メソッドが無効 (MethodDisabled)、エラーを返します。 /ストリーム/zone_sync/ サポートされている方法:

GET - ノードの同期状態を返す クラスタノードの同期状態を返します。

応答可能:

200 - 成功、Stream Zone Sync Node を返します。 404 - 不明なバージョン (UnknownVersion)、エラーを返します。 /resolvers/ サポートされている方法:

GET - Return status for all resolver zones Returns status information for each resolver zone.

パラメータ要求::

GET - すべてのリゾルバゾーンのステータスを返します。 各リゾルバゾーンのステータス情報を返します。

応答可能:

200 - 成功すると、すべてのリゾルバの "リゾルバゾーン "オブジェクトのコレクションを返します。 404 - 不明なバージョン (UnknownVersion)、エラーを返します。 /resolvers/{resolverZoneName}を使用します。 すべてのメソッドに共通のパラメータ。 resolverZoneName (文字列、必須) リゾルバゾーンの名前。 サポートされている方法:

GET - リゾルバゾーンの統計情報を返す 特定のリゾルバゾーンに保存されている統計情報を返します。

パラメータ要求:.

フィールド (文字列、オプション) リゾルバゾーンのどのフィールドを出力するか(リクエスト、レスポンス、またはその両方)を制限する。

応答可能。

200 - 成功、リゾルバゾーンを返す 404 - リゾルバゾーンが見つかりません (ResolverZoneNotFound)、バージョン不明 (UnknownVersion)、エラーを返します。 DELETE - リゾルバゾーンの統計情報をリセットします。 特定のリゾルバゾーンの統計情報をリセットします。

応答可能:

204 - 成功 404 - リゾルバゾーンが見つかりません (ResolverZoneNotFound)、バージョン不明 (UnknownVersion)、エラーを返します。 405 - メソッドが無効 (MethodDisabled)、エラーを返します。 /エスエルエル

サポートされている方法。

GET - SSL 統計情報を返す SSL 統計情報を返します。

パラメータ要求:.

フィールド (文字列、オプション) SSL統計情報のどのフィールドを出力するかを制限します。

応答可能:

200 - 成功、SSLを返します。 404 - 不明なバージョン (UnknownVersion)、エラーを返します。 DELETE - SSL統計情報をリセットする SSLハンドシェイクとセッション再利用のカウンタをリセットします。

応答可能。

204 - 成功 404 - 不明なバージョン (UnknownVersion)、エラーを返します。 405 - メソッドが無効 (MethodDisabled)、エラーを返します。 レスポンスオブジェクト nginx:

nginxに関する一般的な情報です。 version (文字列) nginx のバージョン。 build nginxのビルド名。 address(文字列) ステータス要求を受け付けたサーバのアドレス。 generation (整数) 設定のリロードの総数。 load_timestamp (文字列) 設定を最後にリロードした時刻を、ISO 8601 形式でミリ秒単位で指定します。 timestamp (文字列) 現在の時刻を ISO 8601 形式でミリ秒単位で表示します。 pid (整数) ステータス要求を処理したワーカープロセスの ID。 ppid (整数) ワーカープロセスを開始したマスタープロセスのID。 example

Processes:

respawned (integer) 異常終了してレスポーンされた子プロセスの総数。

Example:

Connections:

受理された接続、ドロップされた接続、アクティブな接続、アイドル接続の数。 アクセプト済み (整数) 受け付けたクライアント接続の総数。 ドロップ (整数) ドロップされたクライアント接続の総数。 アクティブ (整数) アクティブなクライアント接続の現在の数。 アイドル (整数) アイドル状態のクライアント接続の現在の数。

Example:
SSL:

handshake 成功した SSL ハンドシェイクの総数。 handshakes_failed (整数) 失敗した SSL ハンドシェイクの総数。 session_reuses (整数) SSLハンドシェイク中にセッションを再利用する回数の合計。 Example:

スラブアロケータとの共有メモリゾーン。

page 空きメモリと使用済みメモリのページ数。 used (integer) 現在の使用メモリページ数。 free (integer) 現在の空きメモリページ数。 slots メモリスロット（8、16、32、64、128など）のステータスデータ

メモリスロット」オブジェクトのコレクション Example:

Memory Slot:
used (integer)

現在使用されているメモリスロットの数です。

free (integer)

現在の空きメモリスロット数。

reqs (integer)

指定したサイズのメモリを割り当てようとした回数の合計。

fails (integer)

指定したサイズのメモリの割り当てに失敗した回数。

HTTP Requests:
total (integer)

クライアントリクエストの総数。

current (integer)

現在のクライアントリクエスト数。

Example:
HTTP Server Zone:
processing (integer)

現在処理中のクライアントリクエスト数。

requests (integer)

クライアントから受けたクライアントリクエストの総数。

responses

クライアントに送信された回答の総数と、ステータスコードが「1xx」「2xx」「3xx」「4xx」「5xx」の回答数。

1xx (integer)

ステータスコードが "1xx "の回答数。

2xx (integer)

ステータスコードが "2xx "の回答数。

3xx (integer)

ステータスコードが "3xx "の回答数。

4xx (integer)

ステータスコードが "4xx "の回答数。

5xx (integer)

ステータスコードが "5xx "の回答数。

total (integer)

クライアントに送信された回答の総数。

discarded (integer)

レスポンスを送信せずに完了したリクエストの総数。

received (integer)

クライアントから受信したバイト数の合計。

sent (integer)

クライアントに送信された総バイト数。

Example:

HTTP Location Zone:
requests (integer)

クライアントから受けたクライアントリクエストの総数。

responses

クライアントに送信された回答の総数と、ステータスコードが「1xx」「2xx」「3xx」「4xx」「5xx」の回答数。

1xx (integer)

ステータスコードが "1xx "の回答数。

2xx (integer)

ステータスコードが "2xx "の回答数。

3xx (integer)

ステータスコードが "3xx "の回答数。

4xx (integer)

ステータスコードが "4xx "の回答数。

5xx (integer)

ステータスコードが "5xx "の回答数。

total (integer)

クライアントに送信された回答の総数。

discarded (integer)

レスポンスを送信せずに完了したリクエストの総数。

received (integer)

クライアントから受信したバイト数の合計。

sent (integer)

クライアントに送信された総バイト数。

Example:
HTTP Cache:
size (integer)

現在のキャッシュのサイズ。

max_size (integer)

設定で指定したキャッシュの最大サイズの制限。

cold (boolean)

キャッシュローダー" プロセスがまだディスクからキャッシュにデータをロードしているかどうかを示す boolean 値。 hit

responses (integer)

キャッシュから読み込んだ有効な応答の総数。

bytes (integer)

キャッシュから読み込んだ総バイト数。 stale

responses (integer)

キャッシュから読み込まれた期限切れの応答の総数 (proxy_cache_use_stale および他の "*_cache_use_stale" 記述内容を参照)。

bytes (integer)

キャッシュから読み込んだ総バイト数。 更新

responses (integer)

応答が更新されている間にキャッシュから読み込まれた期限切れの応答の総数 (proxy_cache_use_stale および他の "*_cache_use_stale" 記述内容を参照)。

bytes (integer)

キャッシュから読み込んだ総バイト数。 再検証済み

responses (integer)

キャッシュから読み込まれた有効期限切れの応答と再検証された応答の合計数 (proxy_cache_revalidate および他の "*_cache_revalidate" 記述内容を参照してください)。

bytes (integer)

キャッシュから読み込んだ総バイト数。 miss

responses (integer)

キャッシュに見つからなかった応答の総数。

bytes (integer)

プロキシされたサーバから読み込んだバイト数の合計。

responses_written (integer)

キャッシュに書き込まれたレスポンスの総数。

bytes_written (integer)

キャッシュに書き込まれた総バイト数。 期限切れ expired

responses (integer)

キャッシュから取り込まれなかった期限切れのレスポンスの総数。

bytes (integer)

プロキシされたサーバから読み込んだバイト数の合計。

responses_written (integer)

キャッシュに書き込まれたレスポンスの総数。

bytes_written (integer)

キャッシュに書き込まれた総バイト数。 bypass

responses (integer)

proxy_cache_bypass などの「*_cache_bypass」記述内容により、キャッシュで検索されなかったレスポンスの総数。

bytes (integer)

プロキシされたサーバから読み込んだバイト数の合計。

responses_written (integer)

キャッシュに書き込まれたレスポンスの総数。

bytes_written (整数)

キャッシュに書き込まれた総バイト数。 Example:

HTTP Connections Limiting:
passed (integer)

制限されていない、または制限されていると説明されていない接続の総数。

rejected (integer)

拒否された接続の総数。

rejected_dry_run (integer)

ドライランモードで不合格とされた接続数の合計。 Example:

HTTP Requests Rate Limiting:
passed (integer)

制限されていない、または制限されていると説明されていないリクエストの総数。

delayed (integer)

遅延したリクエストの総数。

rejected (integer)

拒否されたリクエストの総数。

delayed_dry_run (integer)

ドライランモードで遅延したとみなされたリクエストの総数。

rejected_dry_run (integer)

ドライランモードで拒否されたとみなされたリクエストの総数。 Example:

HTTP Upstream:
peers

の配列。

id (整数)

サーバのID。

server (string)

サーバのアドレス。

service (string)

サーバディレクティブのサービスパラメータの値。

name (string)

server ディレクティブで指定されたサーバの名前。

backup (boolean)

サーバがバックアップサーバであるかどうかを示すブール値。

weight (integer)

サーバーの重さ。

state (string)

現在の状態。"up"、"draining"、"down"、"unavail"、"checking"、"unhealthy" のいずれか。

active (integer)

現在のアクティブな接続数。

max_conns (integer)

サーバの max_conns の制限値。

requests (integer)

このサーバーに転送されたクライアント要求の総数。

responses

1xx (整数) ステータスコードが "1xx "の回答数。 2xx (整数) 2xx」のステータスコードを持つ回答数。 3xx (整数) 3xx」のステータスコードを持つ回答数。 4xx (整数) 4xx」のステータスコードを持つ回答数。 5xx (整数) ステータスコードが "5xx "の回答数。

total (integer)

このサーバから取得した応答の総数。

sent (integer)

このサーバに送信された総バイト数。

received (integer)

このサーバから受信した総バイト数。

fails (integer)

サーバとの通信に失敗した回数の合計。

unavail (integer)

失敗した試行の数がmax_failsのしきい値に達したために、サーバがクライアント要求に対して利用できなくなった回数(状態 "unavail")。

health_checks
checks (integer)

ヘルスチェック要求の総数。

fails (integer)

ヘルスチェックに失敗した数。

unhealthy (integer)

サーバーが不健康になった回数（状態 "不健康"）。

last_passed (boolean)

最後のヘルスチェック要求が成功し、テストに合格したかどうかを示すブール値。

downtime (integer)

サーバーが「利用できない」「チェックしている」「不健康な」状態になっていた時間の合計。

downstart (string)

サーバーが「使用不能」「チェック中」「不健全」になった時間を、ISO 8601形式でミリ秒単位の分解能で表したもの。

selected (string)

リクエストを処理するためにサーバが最後に選択された時刻。

header_time (integer)

サーバからレスポンスヘッダを取得するまでの平均時間。

response_time (integer)

サーバーから完全なレスポンスを得るまでの平均時間。

keepalive (integer)

現在のアイドルキープアライブ接続数。

zombies (integer)

グループから削除されたが、まだアクティブなクライアント要求を処理しているサーバーの現在の数。

zone (string)

グループの設定と実行時の状態を保持する共有メモリゾーンの名前です。

queue

リクエストキューには、以下のデータが用意されています。

size (integer)

キュー内の現在のリクエスト数。

max_size (integer)

同時にキューに入ることができるリクエストの最大数。

overflows (integer)

キューオーバーフローにより拒否されたリクエストの総数。

Example:
HTTP Upstream Server:

HTTPアップストリームサーバの動的に設定可能なパラメータ。

id (integer)

HTTPアップストリームサーバのIDです。ID は自動的に割り当てられ、変更することはできません。

server (string)

HTTPアップストリームサーバのアドレスパラメータと同じです。サーバを追加する際に、ドメイン名として指定することも可能です。この場合、ドメイン名に対応するIPアドレスの変更を監視し、nginxを再起動しなくてもアップストリームの設定に自動的に適用されます。このためには、"http" ブロックのリゾルバディレクティブが必要です。HTTPアップストリームサーバのresolveパラメータも参照してください。

service (string)

HTTPアップストリームサーバのサービスパラメータと同じです。このパラメータは変更できません。

weight (integer)

HTTP アップストリームサーバの weight パラメータと同じ。

max_conns (integer)

HTTP アップストリームサーバの max_conns パラメータと同じです。

max_fails (integer)

HTTP アップストリームサーバの max_fails パラメータと同じです。

fail_timeout (文字列)

HTTP アップストリームサーバの fail_timeout パラメータと同じです。

slow_start (文字列)

HTTP アップストリームサーバの slow_start パラメータと同じです。

route (string)

HTTPアップストリームサーバのルートパラメータと同じです。

backup (boolean)

true の場合、バックアップ サーバーを追加します。このパラメータは変更できません。

down (ブール値)

HTTPアップストリームサーバのダウンパラメータと同じです。

ドレイン (ブール値)

HTTPアップストリームサーバのドレインパラメータと同じです。

parent (string)

解決したサーバの親サーバID。ID は自動的に割り当てられ、変更することはできません。

host (string)

解決したサーバーのホスト名。ホスト名は自動的に割り当てられ、変更することはできません。

Example:

HTTP Keyval Shared Memory Zone:

GETメソッドを使用した場合のHTTP keyval共有メモリゾーンの内容。

Example:

HTTP Keyval Shared Memory Zone:

POSTまたはPATCHメソッドを使用した場合のHTTP keyval共有メモリゾーンの内容。

Example:
Stream Server Zone:

processing (integer) 現在処理中のクライアント接続の数。 connections (integer) クライアントから受け入れた接続の総数。 sessions 完了したセッションの総数、およびステータスコード「2xx」、「4xx」、または「5xx」で完了したセッションの数。 2xx (integer) ステータスコード「2xx」で完了したセッションの総数。 4xx (integer) ステータスコード「4xx」で完了したセッションの総数。 5xx (integer) ステータスコード「5xx」で完了したセッションの総数。 total (integer) 完了したクライアントセッションの総数。 discarded (integer) セッションを作成せずに完了した接続の総数。 received (integer) クライアントから受信した総バイト数。 sent (integer) クライアントに送信された総バイト数。 Example:

流れの接続が制限されている。

passed (integer) 限定されたものでも、限定されたものとして計上されたものでもない接続数の合計。 rejected (integer) 拒否された接続の総数。 rejected_dry_run (integer) ドライランモードで不合格とされた接続数の合計。

Example:

Stream Upstream:

peers の配列。 id (integer) サーバのID。 server (string) サーバのアドレス。 service (string) サーバディレクティブのサービスパラメータの値。 name (string) server ディレクティブで指定されたサーバの名前。 backup (boolean) サーバがバックアップサーバであるかどうかを示すブール値。 weight (integer) サーバーの重さ。 state (string) 現在の状態。"up"、"down"、"unavail"、"checking"、"unhealthy" のいずれか。 active (integer) 現在の接続数。 max_conns (integer) サーバの max_conns の上限。 connections (integer) このサーバーに転送されたクライアント接続の総数。 connect_time (integer) 上流のサーバに接続するまでの平均時間。 first_byte_time (integer) データの最初のバイトを受信するまでの平均時間。 response_time (integer) データの最後のバイトを受信する平均時間。 sent (integer) このサーバーに送信された総バイト数。 received (integer) このサーバから受信した総バイト数。 fails (integer) サーバーとの通信に失敗した回数の合計。 unavail (integer) 失敗した試行回数がmax_failsのしきい値に達したために、サーバがクライアント接続で利用できなくなった回数(状態 "unavail")。 health_checks

checks (integer) 健康診断の依頼件数の合計。

fails (integer) 健康診断に失敗した回数。

unhealthy (integer) サーバーが不健康になった回数（「不健康になった」の状態）。

last_passed (boolean) 最後のヘルスチェック要求が成功し、テストに合格したかどうかを示すブール値。

downtime (integer) サーバーが「利用できない」「チェックしている」「不健康な」状態になっていた時間の合計。

downstart (string) サーバーが「使用不能」「チェック中」「不健全」になった時間を、ISO 8601形式でミリ秒単位の分解能で表したもの。

selected (string) サーバーが最後に接続を処理するために選択された時刻を、ISO 8601形式でミリ秒単位の分解能で表示しています。

zombies (integer) グループから削除されたが、アクティブなクライアント接続を処理しているサーバーの現在の数。

zone (string) グループの設定と実行時の状態を保持する共有メモリゾーンの名前です。

Example:
Stream Upstream Server:

ストリームアップストリームサーバのパラメータを動的に設定可能。

id (integer) ストリームアップストリームサーバの ID です。ID は自動的に割り当てられ、変更することはできません。

server (string) ストリーム上流サーバのアドレスパラメータと同じです。サーバーを追加する際に、ドメイン名として指定することも可能です。この場合、ドメイン名に対応するIPアドレスの変更を監視し、nginxを再起動することなく、ストリームの設定に自動的に適用されます。このためには、"stream" ブロックの resolver ディレクティブが必要です。ストリームアップストリームサーバの resolve パラメータも参照してください。

service (string) ストリームアップストリームサーバのサービスパラメータと同じです。このパラメータは変更できません。

weight (integer) ストリーム上流サーバのウェイトパラメータと同じ。

max_conns (integer) ストリームアップストリームサーバの max_conns パラメータと同じです。

max_fails (integer) ストリームアップストリームサーバの max_fails パラメータと同じです。

fail_timeout (string) ストリームアップストリームサーバの fail_timeout パラメータと同じです。

slow_start (string) ストリームアップストリームサーバの slow_start パラメータと同じです。

backup (boolean) ストリームアップストリームサーバの slow_start パラメータと同じです。

down (boolean) ストリームアップストリームサーバのダウンパラメータと同じです。

parent (string) 解決したサーバの親サーバID。ID は自動的に割り当てられ、変更することはできません。

host (string) 解決したサーバーのホスト名。ホスト名は自動的に割り当てられ、変更することはできません。

Example:

ストリームキーバル共有メモリゾーン。

GETメソッドを使用した場合のストリームキーval共有メモリゾーンの内容。 例。

ストリームキーバル共有メモリゾーン:

POSTメソッドまたはPATCHメソッドを使用した場合のストリームKEYVAL共有メモリゾーンの内容。

Example:

Stream Zone Sync Node:

zones 各共有メモリゾーンごとの同期情報。

同期ゾーン」オブジェクトのコレクション

status クラスタ内のノードごとの同期情報。

bytes_in (integer) このノードが受信したバイト数。

msgs_in (integer) このノードが受信したメッセージの数。

msgs_out (integer) このノードが送信したメッセージの数。

bytes_out (integer) このノードが送信したバイト数。

nodes_online (integer) このノードが接続しているピアの数。

Example:

Sync Zone:

共有メモリゾーンの同期状態。 records_pending (integer) クラスタに送信する必要があるレコードの数。 records_total (integer) 共有メモリゾーンに保存されているレコードの総数。 Resolver Zone:

特定のリゾルバゾーンごとのDNSリクエストとレスポンスの統計。 name (integer) 名前をアドレスに解決するためのリクエストの総数。 srv (integer) SRV レコードを解決するためのリクエストの総数。 addr (integer) アドレスを名前に解決するためのリクエストの総数。 responses noerror (integer) 成功した回答の総数。 formerr (integer) FORMERR (フォーマットエラー) レスポンスの総数。 servfail (integer) SERVFAIL (サーバ障害) 応答の総数。 nxdomain (integer) NXDOMAIN (Host not found) 応答の総数。 notimp (integer) NOTIMP(未実装)の総回答数。 refused (integer) REFUSED（操作拒否）の回答数の合計。

timedout (integer) タイムアウトしたリクエストの総数。

unknown (integer) 不明なエラーで完了したリクエストの総数。

Example:

Error:

nginxのエラーオブジェクト。 error status (integer) HTTPエラーコードです。 text (string) エラーの説明。 code (string) 内部的な nginx のエラーコード。 request_id (string) リクエストのIDで、変数$request_idの値と同じです。 href (string) 参考資料へのリンクです。

Module ngx_http_auth_basic_module

ngx_http_auth_basic_module モジュールでは、「HTTP Basic Authentication」プロトコルを用いてユーザ名とパスワードを検証し、リソースへのアクセスを制限することができます。

また、アドレスによるアクセス制限、サブリクエストの結果によるアクセス制限、JWTによるアクセス制限も可能です。アドレスによるアクセス制限とパスワードによるアクセス制限を同時に行う場合は、satisfaction ディレクティブで制御します。

設定例

記述内容

HTTP Basic Authentication」プロトコルを使用して、ユーザー名とパスワードの検証を有効にします。指定したパラメータをレルムとして使用します。パラメータの値には変数(1.3.10, 1.2.7)を含めることができます。特別な値offは、前の設定レベルから継承されたauth_basicディレクティブの効果をキャンセルすることを可能にします。

記述内容

HTTP Basic Authentication」プロトコルを使用して、ユーザー名とパスワードの検証を有効にします。指定したパラメータをレルムとして使用します。パラメータの値には変数(1.3.10, 1.2.7)を含めることができます。特別な値offは、前の設定レベルから継承されたauth_basicディレクティブの効果をキャンセルすることを可能にします。

ユーザー名とパスワードを保持するファイルを次の形式で指定します。

以下のパスワードがサポートされています。

これは、Apache HTTP Server ディストリビューションの "htpasswd" ユーティリティや "openssl passwd" コマンドを使って生成することができます。

MD5 ベースのパスワードアルゴリズム (apr1) の Apache バリアントでハッシュ化されています。 現在実装されているスキームには PLAIN (一例です。使ってはいけません)、SHA (1.3.13) (プレーンな SHA-1 ハッシュ、使ってはいけません)、SSHA (塩漬けの SHA-1 ハッシュ、OpenLDAP や Dovecot などいくつかのソフトウェアパッケージで使われています) があります。 SHA スキームのサポートは、他のウェブサーバからの移行を支援するためだけに追加されました。これは新しいパスワードには使用すべきではありません。

Module ngx_http_auth_jwt_module

ngx_http_auth_jwt_module モジュール (1.11.3) は、指定されたキーを使用して提供された JSON Web Token (JWT) を検証することで、クライアントの認証を実装しています。JWT クレームは JSON Web Signature (JWS) 構造体でエンコードされている必要があります。このモジュールは OpenID Connect 認証に使用できます。

このモジュールは、satisfaction ディレクティブを介して、 ngx_http_access_module、ngx_http_auth_basic_module、ngx_http_auth_request_module などの他のアクセスモジュールと組み合わせることができます。

このモジュールは、以下の暗号アルゴリズムをサポートしています。

HS256, HS384, HS512 RS256, RS384, RS512 ES256, ES384, ES512 EdDSA (Ed25519およびEd448署名) (1.15.7) バージョン1.13.7以前では、HS256、RS256、ES256アルゴリズムのみがサポートされていました。

このモジュールは、当社の商用サブスクリプションの一部としてご利用いただけます。 設定例

記述内容

JSON Web Token の検証を有効にします。指定した文字列がレルムとして使用されます。パラメータ値には変数を含めることができます。

オプションのtokenパラメータは、JSON Web Tokenを含む変数を指定します。デフォルトでは、JWTはBearer Tokenとして "Authorization "ヘッダに渡されます。JWTは、クッキーやクエリ文字列の一部として渡されることもあります。

auth_jwt "closed site" token=$cookie_auth_token. 特別な値offは、以前の設定レベルから継承されたauth_jwtディレクティブの効果をキャンセルします。

キー名で識別される JWT クレーム パラメータに変数を設定します。名前の照合は、JSON ツリーの最上位レベルから開始されます。配列の場合、変数はカンマで区切られた配列要素のリストを保持します。

auth_jwt_claim_set $email info e-mail. auth_jwt_claim_set $job info "job title". バージョン1.13.7以前では、キー名は1つしか指定できず、結果は配列では未定義でした。

キー名で識別されるJOSEヘッダパラメータに変数を設定します。名前のマッチングは、JSON ツリーの最上位レベルから開始されます。配列の場合、変数はカンマで区切られた配列要素のリストを保持します。

バージョン1.13.7以前では、キー名は1つしか指定できず、結果は配列では未定義でした。

JWT署名を検証するためのJSON Webキーセット形式のファイルを指定します。パラメータ値には変数を含めることができます。

JWT署名を検証するためのサブリクエストからJSON Web Key Setファイルを取得し、サブリクエストの送信先のURIを設定することができます。検証のオーバーヘッドを避けるために、キーファイルをキャッシュすることを推奨します。

exp および nbf JWT クレームを検証する際に、クロックスキューを補正するために許容される最大の余裕を設定します。

埋め込み変数 ngx_http_auth_jwt_moduleモジュールは組み込み変数をサポートしています。

jwt_header_name 指定されたJOSEヘッダの値を返します。 jwt_claim_name 指定されたJWTクレームの値を返します。 入れ子になったクレームやドット(".")を含むクレームでは、変数の値を評価することはできません; 代わりに auth_jwt_claim_set ディレクティブを使用しなければなりません。

Module ngx_http_auth_request_module

ngx_http_auth_request_module モジュール (1.5.4+) は、サブリクエストの結果に基づくクライアントの認証を実装しています。サブリクエストが 2xx レスポンスコードを返した場合は、アクセスを許可します。401 あるいは 403 を返した場合は、そのアクセスは拒否され、対応するエラーコードが返されます。それ以外の応答コードがサブリクエストから返された場合は、エラーとみなされます。

401エラーの場合、クライアントはサブリクエスト応答から "WWW-Authenticate "ヘッダも受け取ります。

このモジュールはデフォルトではビルドされていないので、 --with-http_auth_request_module 設定パラメータで有効にしなければなりません。

このモジュールは、satisfaction ディレクティブを使って ngx_http_access_module、ngx_http_auth_basic_module、ngx_http_auth_jwt_module などの他のアクセスモジュールと組み合わせることができます。

バージョン 1.7.3 より前のバージョンでは、認証サブリクエストに対する応答を (proxy_cache、proxy_store などを使用して) キャッシュすることができませんでした。

設定例
記述内容

サブリクエストの結果に基づく認証を有効にし、サブリクエストが送信されるURIを設定します。

認証要求が完了した後、要求変数を指定した値に設定します。この値には、$upstream_http_* のような認可要求からの変数が含まれている可能性があります。

Module ngx_http_autoindex_module

ngx_http_autoindex_module は、スラッシュ文字 ('/') で終わるリクエストを処理し、ディレクトリの一覧を作成します。通常、ngx_http_autoindex_module モジュールがインデックスファイルを見つけられない場合は、 ngx_http_autoindex_module モジュールにリクエストを渡します。

設定例
記述内容

ディレクトリリストの出力を有効または無効にします。

HTML形式の場合、ディレクトリリストに正確なファイルサイズを出力するか、キロバイト、メガバイト、ギガバイトに丸めて出力するかを指定します。

This directive appeared in version 1.7.9.

ディレクトリ一覧のフォーマットを設定します。

JSONP形式を使用する場合は、コールバック関数名をコールバックリクエスト引数に設定します。引数が欠落している場合や値が空の場合は、JSON形式が使用されます。

XML出力は、ngx_http_xslt_moduleモジュールを使用して変換することができます。

HTMLフォーマットでは、ディレクトリリストの時刻をローカルタイムゾーンで出力するかUTCで出力するかを指定します。

Module ngx_http_browser_module

ngx_http_browser_moduleモジュールは、"User-Agent "リクエストヘッダフィールドの値に依存する変数を作成します。

$modern_browser ブラウザがモダンであることが確認された場合は、 modern_browser_value ディレクティブで設定された値と等しくなります。

$ancient_browser ブラウザが古代のものであることが確認された場合は、 ancient_browser_value ディレクティブで設定された値と等しくなります。

$msie ブラウザがいずれかのバージョンの MSIE として識別された場合は、"1" に等しくなります。

設定例

Choosing an index file:

modern_browser_value "modern.";

modern_browser msie 5.5; modern_browser gecko 1.0.0; modern_browser opera 9.0; modern_browser safari 413; modern_browser konqueror 3.0;

index index.${modern_browser}html index.html. 古いブラウザへのリダイレクト。

modern_browser msie 5.0; modern_browser gecko 0.9.1; modern_browser opera 8.0; modern_browser safari 413; modern_browser konqueror 3.0;

modern_browser unlisted;

ancient_browser Links Lynx netscape4;

記述内容

指定された部分文字列のいずれかが "User-Agent "リクエストヘッダフィールドに見つかった場合、そのブラウザは古代のものとみなされます。特殊文字列「netscape4」は正規表現「^Mozilla/[1-4]」に対応します。

ancient_browser 変数の値を設定します。

ブラウザがモダンとみなされるバージョンから始まるバージョンを指定します。ブラウザは msie, gecko (Mozilla ベースのブラウザ)、 opera, safari, konqueror のいずれかになります。

バージョンは、以下のフォーマットで指定できます。それぞれのフォーマットの最大値は、それぞれ4000、4000.99、4000.99.99、4000.99.99です。

特別な値 unlisted は、modern_browser と ancient_browser ディレクティブでリストされていないブラウザを モダンとみなすように指定します。そうでなければ、そのようなブラウザは古いものとみなされます。リクエストがヘッダに "User-Agent" フィールドを提供しない場合、ブラウザはリストされていないものとして扱われます。

変数 $modern_browser の値を設定します。

Module ngx_http_charset_module

ngx_http_charset_module モジュールは、指定した文字セットを "Content-Type" レスポンスヘッダフィールドに追加します。さらに、このモジュールはある文字セットから別の文字セットにデータを変換することができますが、いくつかの制限があります。

変換は、サーバからクライアントへの一方通行で実行されます。 半角文字セットのみ変換可能 またはシングルバイト文字セットをUTF-8との間で、またはUTF-8との間で使用します。

設定例
記述内容

指定された charset を "Content-Type" レスポンスヘッダフィールドに追加します。この charset が source_charset ディレクティブで指定された charset と異なる場合、変換が行われます。

パラメータ off は、"Content-Type" レスポンスヘッダフィールドへの charset の追加をキャンセルします。

文字セットは変数で定義することができます。

charset $charset; このような場合、変数のすべての可能な値が、charset_map, charset, source_charset ディレクティブの形で少なくとも一度は設定に含まれている必要があります。utf-8, windows-1251, koi8-r の文字セットについては、conf/koi-win, conf/koi-utf, conf/win-utf を設定に含めるだけで十分です。他の文字セットでは、例えば、架空の変換テーブルを作成するだけで動作します。

charset_map iso-8859-5 _ { } さらに、「X-Accel-Charset」応答ヘッダーフィールドにcharsetを設定できる。この機能は、proxy_ignore_headers、fastcgi_ignore_headers、uwsgi_ignore_headers、scgi_ignore_headers、および grpc_ignore_headers ディレクティブを使って無効にすることができる。

ある文字セットから別の文字セットへの変換テーブルについて説明します。逆変換テーブルは同じデータを使用して構築されます。文字コードは16進数で与えられます。80～FFの範囲で欠落している文字は"? "に置き換えられます。UTF-8から変換する場合、半角文字セットで欠落している文字は「 &#XXXXXX;」に置き換えられます。.

Example:

UTF-8への変換テーブルを記述する場合、UTF-8文字セットのコードは、例えば2番目の列に記述しなければなりません。

koi8-r から windows-1251 へ、また koi8-r と windows-1251 から utf-8 への完全な変換表は conf/koi-win, conf/koi-utf, conf/win-utf にあります。

text/html」に加えて、指定されたMIMEタイプを持つレスポンスでのモジュール処理を有効にします。特別な値 "*"は任意のMIMEタイプにマッチします (0.8.29)。

バージョン1.5.4までは、"application/javascript "の代わりに "application/x-javascript "がデフォルトのMIMEタイプとして使用されていましたが、バージョン1.5.4では、"application/javascript "の代わりに "application/x-javascript "が使用されるようになりました。

回答が「Content-Type」応答ヘッダーフィールドで既に文字セットを持っている場合に、プロキシドまたはFastCGI/uwsgi/SCGI/gRPCサーバーから受信した回答に対して変換を実行するかどうかを決定します。変換が有効な場合、受信した応答で指定された文字セットがソース文字セットとして使用されます。

応答がサブリクエストで受信された場合、応答の文字セットからメインリクエストの文字セットへの変換は override_charset ディレクティブの設定に関係なく常に実行されることに注意してください。

レスポンスのソース文字セットを定義します。この文字セットが charset ディレクティブで指定された文字セットと異なる場合、変換が行われます。

Module ngx_http_dav_module

ngx_http_dav_module モジュールは、WebDAV プロトコルによるファイル管理の自動化を目的としています。このモジュールは、HTTP および WebDAV メソッドの PUT、DELETE、MKCOL、COPY、MOVE を処理します。

このモジュールはデフォルトではビルドされていませんので、 --with-http_dav_module 構成パラメータで有効にしてください。

動作するために追加の WebDAV メソッドを必要とする WebDAV クライアントは、このモジュールでは動作しません。

設定例
記述内容

WebDAV 仕様では、既存のディレクトリにしかファイルを作成することができません。このディレクティブは、必要とされるすべての中間ディレクトリを作成することができます。

新しく作成されたファイルやディレクトリのアクセス権限を設定します。

dav_access user:rw group:rw all:r. グループまたはすべてのアクセス許可が指定されている場合は、ユーザーのアクセス許可は省略することができます。

dav_access group:rw all:r;

指定された HTTP および WebDAV メソッドを許可します。パラメータ off は、このモジュールが処理するすべてのメソッドを拒否します。以下のメソッドがサポートされています。PUT、DELETE、MKCOL、COPY、およびMOVEです。

PUT メソッドでアップロードされたファイルは、最初に一時ファイルに書き込まれ、その後ファイル名が変更されます。バージョン0.8.9からは、一時ファイルと永続ストアを別のファイルシステムに置くことができます。しかし、この場合、ファイルは安価なリネーム操作ではなく、2つのファイルシステムにまたがってコピーされることに注意してください。したがって、任意の場所に保存されたファイルと client_body_temp_path ディレクティブで設定された一時ファイルを保持するディレクトリの両方を同じファイルシステムに置くことが推奨されます。

PUTメソッドでファイルを作成する際に、Dateヘッダフィールドに修正日を指定することができます。

リクエストパスの要素数が指定された数よりも少なくない場合に、 ファイルを削除する DELETE メソッドを許可します。例えば

allows removing files on requests

and denies the removal of

Module ngx_http_empty_gif_module

ngx_http_empty_gif_moduleモジュールは、シングルピクセルの透過GIFを出力します。

設定例

記述内容

周囲の場所でのモジュール処理をオンにします。

Module ngx_http_f4f_module

ngx_http_f4f_module モジュールは、Adobe HTTP Dynamic Streaming (HDS) のサーバーサイドサポートを提供します。

このモジュールは、"/videoSeg1-Frag1 "形式のHTTP Dynamic Streamingリクエストの処理を実装しており、videoSeg1.f4xインデックスファイルを使ってvideoSeg1.f4fファイルから必要なフラグメントを抽出します。このモジュールは、Apache 用の Adobe の f4f モジュール (HTTP Origin モジュール) の代替モジュールです。

Adobeのf4fpackagerを使った通常の前処理が必要です。

このモジュールは、当社の商用サブスクリプションの一部としてご利用いただけます。

設定例

記述内容

周囲の位置でのモジュール処理をオンにします。

.f4xインデックスファイルの読み込みに使用するバッファのサイズを設定します。

Module ngx_http_fastcgi_module

FastCGI サーバーに渡されるパラメータ 埋め込み変数 ngx_http_fastcgi_module モジュールは、FastCGI サーバーにリクエストを渡すことを可能にします。

設定例

記述内容

FastCGI サーバーへの発信接続を、オプションのポート(1.11.2)を使用して指定されたローカル IP アドレスから発信します。パラメータ値には変数を含めることができます(1.3.12)。特別な値 off (1.3.12) は、以前の設定レベルから継承された fastcgi_bind ディレクティブの効果をキャンセルし、システムがローカル IP アドレスとポートを自動的に割り当てることを可能にします。

transparent パラメータ (1.11.0) は、FastCGI サーバへの発信接続をローカルではない IP アドレス、例えば、クライアントの実際の IP アドレスから発信することを可能にします。

fastcgi_bind $remote_addr transparent. このパラメータを動作させるためには、通常、スーパーユーザ権限でnginxワーカープロセスを実行する必要があります。Linux では、transparent パラメータが指定されている場合、ワーカープロセスはマスタープロセスから CAP_NET_RAW 機能を継承するため、必要ありません (1.13.8)。また、FastCGI サーバからのネットワークトラフィックを傍受するために、カーネルルーティングテーブルを設定する必要があります。

FastCGI サーバーから受信した応答の最初の部分を読み込むために使用するバッファのサイズを設定します。この部分には通常、小さな応答ヘッダーが含まれています。デフォルトでは、バッファサイズは1メモリページに相当します。これは、プラットフォームに応じて、4K または 8K のどちらかです。ただし、これより小さくすることもできます。

FastCGI サーバーからのレスポンスのバッファリングを有効または無効にします。

バッファリングが有効な場合、nginx は FastCGI サーバからのレスポンスをできるだけ早く受信し、fastcgi_buffer_size と fastcgi_buffers 記述内容で設定されたバッファに保存します。レスポンス全体がメモリに収まらない場合は、その一部をディスク上の一時ファイルに保存することができます。一時ファイルへの書き込みは fastcgi_max_temp_file_size と fastcgi_temp_file_write_size 記述内容によって制御される。

バッファリングが無効になっている場合、レスポンスは受信した直後に同期的にクライアントに渡されます。nginx がサーバから一度に受信できるデータの最大サイズは fastcgi_buffer_size ディレクティブで設定されます。

バッファリングは、"X-Accel-Buffering" レスポンスヘッダフィールドに "yes" または "no" を渡すことで有効または無効にすることができます。この機能は fastcgi_ignore_headers ディレクティブで無効にすることができます。

FastCGI サーバーからの応答を読み取るために使用するバッファの数とサイズを設定します。デフォルトでは、バッファサイズは1メモリページに相当します。これは、プラットフォームに応じて、4K または 8K のいずれかになります。

FastCGI サーバーからの応答のバッファリングを有効にすると、応答がまだ完全に読み込まれていない間、クライアントに応答を送信するためにビジー状態になるバッファの合計サイズを制限します。その間、残りのバッファは応答を読み取るために使用し、必要に応じて応答の一部を一時ファイルにバッファリングすることができます。デフォルトでは、サイズは fastcgi_buffer_size と fastcgi_buffers 記述内容によって設定された 2 つのバッファのサイズによって制限されます。

キャッシングに使用する共有メモリゾーンを定義します。同じゾーンを複数の場所で使用することができます。パラメータ値には変数を含めることができます（1.7.9）。off パラメータは、前の構成レベルから継承されたキャッシングを無効にします。

このディレクティブはバージョン 1.11.10 で登場しました。

期限切れのキャッシュアイテムを更新するためのバックグラウンドサブリクエストを開始して、 古いキャッシュのレスポンスをクライアントに返すことを許可します。更新中に古いキャッシュのレスポンスを使用できるようにする必要があることに注意してください。

レスポンスがキャッシュから取得されない条件を定義します。文字列パラメータのうち少なくとも一つの値が空でなく、かつ "0" でない場合、レスポンスはキャッシュから取得されません。

fastcgi_cache_bypass $cookie_nocache $arg_nocache$arg_comment. fastcgi_cache_bypass $http_pragma $http_authorization。 fastcgi_no_cache ディレクティブと一緒に使うことができます。

fastcgi_cache_key localhost:9000$request_uri;

このディレクティブはバージョン 1.1.12 で登場しました。

有効にすると、FastCGI サーバにリクエストを渡すことで、 fastcgi_cache_key ディレクティブで指定された新しいキャッシュ要素を一度に一つのリクエストだけが許可されます。同じキャッシュ要素の他のリクエストは、キャッシュに応答が現れるのを待つか、この要素のキャッシュロックが解除されるのを fastcgi_cache_lock_timeout ディレクティブで設定された時間まで待ちます。

このディレクティブはバージョン 1.7.8 で登場しました。

新しいキャッシュ要素を生成するために FastCGI サーバに渡された最後のリクエストが指定された時間内に完了しなかった場合、もう一つのリクエストを FastCGI サーバに渡すことができます。

このディレクティブはバージョン 1.1.12 で登場しました。

fastcgi_cache_lock のタイムアウトを設定します。タイムアウトすると、リクエストは FastCGI サーバに渡されますが、レスポンスはキャッシュされません。

1.7.8以前では、レスポンスはキャッシュされる可能性がありました。

このディレクティブはバージョン 1.11.6 で登場しました。

バイト範囲リクエストのオフセットをバイト単位で設定します。範囲がオフセットを超えている場合、範囲リクエストは FastCGI サーバに渡され、レスポンスはキャッシュされません。

このディレクティブはバージョン 0.7.59 で登場しました。

クライアントのリクエストメソッドがこのディレクティブにリストアップされている場合、 レスポンスはキャッシュされます。"GET" と "HEAD" メソッドは常にリストに追加されますが、明示的に指定することをお勧めします。fastcgi_no_cache ディレクティブも参照してください。

応答がキャッシュされるまでのリクエスト数を設定します。

キャッシュのパスなどを設定します。キャッシュデータはファイルに格納されます。キャッシュ内のキーとファイル名は、プロキシされた URL に MD5 関数を適用した結果です。levels パラメータはキャッシュの階層レベルを定義します。例えば、以下の設定では

fastcgi_cache_path /data/nginx/cache levels=1:2 keys_zone=one:10m.

キャッシュ内のファイル名は次のようになります。

/data/nginx/cache/c/29/b7f54b2df7773722d382f4809d65029c

キャッシュされたレスポンスは最初に一時ファイルに書き込まれ、その後ファイル名が変更されます。バージョン 0.8.9 以降、一時ファイルとキャッシュは異なるファイルシステムに置くことができます。しかし、この場合、ファイルは安価なリネーム操作の代わりに 2 つのファイルシステムにコピーされることに注意してください。したがって、どのような場所でも、キャッシュと一時ファイルを保持するディレクトリの両方を同じファイルシステムに置くことをお勧めします。一時ファイルを格納するディレクトリは use_temp_path パラメータ(1.7.10)に基づいて設定される。このパラメータが省略された場合、または on に設定された場合は、指定された場所の fastcgi_temp_path ディレクティブで設定されたディレクトリが使用されます。値がoffに設定されている場合、一時ファイルは直接キャッシュディレクトリに置かれます。

さらに、すべてのアクティブな鍵とデータに関する情報は共有メモリゾーンに保存され、その名前とサイズは keys_zoneパラメータで設定される。1メガバイトのゾーンには、約8,000個の鍵を格納することができる。

商用サブスクリプションの一部として、共有メモリゾーンには拡張キャッシュ情報も格納されるため、 同じ数の鍵に対してより大きなゾーンサイズを指定する必要がある。例えば、1メガバイトのゾーンには約4,000個の鍵を格納することができます。 inactiveパラメータで指定された時間内にアクセスされなかったキャッシュデータは、その鮮度に関係なくキャッシュから削除されます。デフォルトでは、inactiveは10分に設定されている。

特別な「キャッシュマネージャ」プロセスは、max_sizeパラメータで設定された最大キャッシュサイズを監視します。このサイズを超えると、最近使用されたデータを削除します。データは manager_files、manager_threshold、manager_sleep パラメータ (1.11.5) で設定された繰り返しで削除されます。1回のイテレーションの間に削除されるのは、 manager_filesの項目を超えてはなりません (デフォルトでは100)。1回の反復の期間は、 manager_thresholdパラメータによって制限されます (デフォルトでは、200ミリ秒)。反復の間には、 manager_sleep パラメータで設定された一時停止が行われます (デフォルトでは 50 ミリ秒)。

起動から1分後に特別な「キャッシュローダー」プロセスが起動します。ファイルシステムに保存されている以前にキャッシュされたデータの情報をキャッシュゾーンにロードします。ロードは反復して行われます。1 回の繰り返しの間に loader_files の項目がロードされるのはそれ以上ではありません (デフォルトでは 100)。さらに、1 回の反復の期間は loader_threshold パラメータによって制限されます（デフォルトでは 200 ミリ秒）。反復の間には、loader_sleepパラメータ（デフォルトでは50ミリ秒）で設定された一時停止が行われます。

さらに、以下のパラメータは商用サブスクリプションの一部として利用できます。

purger=on|off

ワイルドカードキーに一致するキャッシュエントリをキャッシュパージ機能 (1.7.12) でディスクから削除するかどうかを指定します。パラメータを on (デフォルトは off) に設定すると、すべてのキャッシュエントリを恒久的に反復処理し、ワイルドカードキーにマッチするエントリを削除する「キャッシュパージ」プロセスが有効になります。

purger_files=number

1 回の繰り返しでスキャンするアイテムの数を設定します (1.7.12)。デフォルトでは、Purger_files は 10 に設定されています。

purger_threshold=number

1 回の反復の持続時間を設定します (1.7.12)。デフォルトでは、purger_threshold は 50 ミリ秒に設定されています。

purger_sleep=数

反復の間の一時停止を設定します (1.7.12)。デフォルトでは、purger_sleep は 50 ミリ秒に設定されています。 バージョン 1.7.3、1.7.7、および 1.11.10 では、キャッシュヘッダの形式が変更されました。新しいバージョンの nginx にアップグレードすると、以前にキャッシュされたレスポンスは無効とみなされます。

リクエストがキャッシュパージリクエストとみなされる条件を定義します。文字列パラメータの少なくとも一つの値が空ではなく、"0" に等しくない場合、対応するキャッシュキーを持つキャッシュエントリが削除されます。操作が成功した結果は 204 (No Content) 応答を返すことで示される。

パージ要求のキャッシュキーがアスタリスク ("*") で終わる場合、ワイルドカードキーにマッチするすべてのキャッシュエントリがキャッシュから削除されます。しかし、これらのエントリは、非活動状態で削除されるか、キャッシュパージ機能 (1.7.12) によって処理されるか、クライアントがアクセスしようとするまで、ディスク上に残ります。

設定例:

この機能は、当社の商用サブスクリプションの一部としてご利用いただけます。

If-Modified-Since" および "If-None-Match" ヘッダーフィールドを持つ条件付きリクエストを使用して、期限切れのキャッシュアイテムの再バリデーションを有効にします。

FastCGI サーバとの通信中にエラーが発生した場合に、どのような場合にスタ イルキャッシュされたレスポンスを使用できるかを決定します。このディレクティブのパラメータは fastcgi_next_upstream ディレクティブのパラメータと一致します。

error パラメータは、リクエストを処理する FastCGI サーバが選択できない場合に、古いキャッシュされた応答を使用することも可能にします。

さらに、更新パラメータは、現在更新中の場合、古いキャッシュ応答を使用することを許可します。これにより、キャッシュされたデータを更新するときに FastCGI サーバーへのアクセス数を最小限に抑えることができます。

スタールキャッシュされた応答を使用することは、応答がスタールになってから指定された秒数の間、応答ヘッダーで直接有効にすることもできます（1.11.10）。これはディレクティブのパラメータを使うよりも優先度が低いです。

Cache-Control」ヘッダフィールドの「stale-while-revalidate」拡張は、現在更新中の場合、古いキャッシュされた 応答を使用することを許可します。 Cache-Control" ヘッダ・フィールドの "stale-if-error" 拡張子は、エラーが発生した場合に古いキャッシュ・レスポンスの使用を許可します。 新しいキャッシュ要素を生成する際に、FastCGI サーバーへのアクセス数を最小限にするために、fastcgi_cache_lock ディレクティブを使用することができます。

異なるレスポンスコードのキャッシュ時間を設定します。例えば、次のような記述

内容

コード200と302のレスポンスには10分間、コード404のレスポンスには1分間のキャッシュ時間を設定します。

キャッシング時間のみを指定した場合

fastcgi_cache_valid 5m;

の場合、200、301、および302応答のみがキャッシュされます。

さらに、any パラメータを指定することで、任意のレスポンスをキャッシュすることができます。

キャッシングのパラメータはレスポンスヘッダで直接設定することもできます。これはディレクティブを使ったキャッシング時間の設定よりも優先度が高くなります。

X-Accel-Expires」ヘッダーフィールドは、応答のキャッシング時間を秒単位で設定する。ゼロの値は応答のキャッシングを無効にする。値が@接頭辞で始まる場合、Epochからの絶対時間を秒単位で設定します。

ヘッダに "X-Accel-Expires "フィールドが含まれていない場合、キャッシングのパラメータは、ヘッダフィールド "Expires "または "Cache-Control "に設定されてもよい。

ヘッダに「Set-Cookie」フィールドが含まれている場合、そのような応答はキャッシュされません。 ヘッダーが特別な値「*」を持つ「Vary」フィールドを含む場合、そのような応答はキャッシュされない(1.7.7)。ヘッダーが別の値を持つ「Vary」フィールドを含む場合、そのような応答は 対応するリクエストヘッダーフィールドを考慮してキャッシュされる(1.7.7)。 これらの応答ヘッダフィールドのうち一つ以上の処理は fastcgi_ignore_headers ディレクティブを使って無効にすることができます。

FastCGI サーバーから受信した応答のエラー ストリームで検索する文字列を設定します。文字列が見つかった場合、FastCGI サーバーは無効な応答を返したと見なされます。これにより、例えばnginxでアプリケーションエラーを処理することができます。

FastCGI サーバーとの接続を確立するためのタイムアウトを定義します。このタイムアウトは通常 75 秒を超えることはできないことに注意してください。

このディレクティブはバージョン 1.7.7 で登場しました。

FastCGI サーバからのキャッシュされた応答とキャッシュされていない応答の両方で、これらの応答の "Accept-Ranges" フィールドに関係なくバイトレンジのサポートを有効にします。

デフォルトでは、nginx は FastCGI サーバのレスポンスから "Status" と "X-Accel-..." というヘッダフィールドをクライアントに渡しません。fastcgi_hide_header ディレクティブは、渡さない追加のフィールドを設定します。逆に、フィールドを渡すことを許可する必要がある場合は、 fastcgi_pass_header ディレクティブを使用することができます。

クライアントが応答を待たずに接続を閉じるときに、FastCGI サーバーとの接続を閉じるかどうかを決定します。

FastCGI サーバーからの特定の応答ヘッダーフィールドの処理を無効にします。以下のフィールドは無視できます。"X-Accel-Redirect"、"X-Accel-Expires"、"X-Accel-Limit-Rate" (1.1.6), "X-Accel-Buffering" (1.1.6), "X-Accel-Charset" (1.1.6), "Expires"、"Cache-Control"、"Set-Cookie" (0.8.44), "Vary" (1.7.7)。

無効化されていない場合、これらのヘッダフィールドの処理は以下の効果を持つ。

"X-Accel-Expires"、"Expires"、"Cache-Control"、"Set-Cookie"、および "Vary "はレスポンスキャッシングのパラメータを設定する。 "X-Accel-Redirect" は、指定された URI への内部リダイレクトを実行します。 "X-Accel-Limit-Rate」は、クライアントへの応答送信のレート制限を設定します。 "X-Accel-Buffering」は、応答のバッファリングを有効または無効にします。 "X-Accel-Charset」は、レスポンスの希望する文字セットを設定します。

fastcgi_script_name変数の値に、スラッシュで終わるURIの後に追加されるファイル名を設定します。たとえば、以下の設定では、次のようになります。

fastcgi_index index.php。 fastcgi_param SCRIPT_FILENAME /home/www/scripts/php$fastcgi_script_name. と"/page.php "リクエストでは、SCRIPT_FILENAMEパラメータは"/home/www/scripts/php/page.php "と等しくなり、"/"リクエストでは"/home/www/scripts/php/index.php "と等しくなります。

300 以上のコードを持つ FastCGI サーバのレスポンスをクライアントに渡すか、 傍受して nginx にリダイレクトして error_page ディレクティブで処理するかを決定します。

このディレクティブはバージョン 1.1.4 で登場しました。

デフォルトでは、FastCGI サーバは応答を送信した直後に接続を閉じます。しかし、このディレクティブが on に設定されている場合、nginx は FastCGI サーバに接続を開いたままにするように指示します。これは特に、FastCGI サーバへの keepalive 接続が機能するために必要です。

このディレクティブはバージョン 1.7.7 で登場しました。

FastCGI サーバからのレスポンスの読み込み速度を制限します。レートは 1 秒あたりのバイト数で指定します。ゼロの値は速度制限を無効にします。制限はリクエストごとに設定されているため、nginx が同時に FastCFI サーバーへの 2 つの接続を開いた場合、全体のレートは指定された制限の 2 倍になります。この制限は、FastCGI サーバーからの応答のバッファリングが有効な場合にのみ機能します。

FastCGI サーバからの応答のバッファリングが有効で、応答全体が fastcgi_buffer_size と fastcgi_buffers 記述内容で設定したバッファに収まらない場合、応答の一部を一時ファイルに保存することができます。このディレクティブは一時ファイルの最大サイズを設定します。一度に一時ファイルに書き込まれるデータのサイズは fastcgi_temp_file_write_size ディレクティブで設定します。

ゼロの値は一時ファイルへの応答のバッファリングを無効にします。

この制限は、キャッシュされたりディスクに保存されたりするレスポンスには適用されません。

どのような場合にリクエストを次のサーバに渡すかを指定します。

error

サーバとの接続の確立、サーバへのリクエストの受け渡し、またはレスポンスヘッダの読み込み中にエラーが発生しました。

timeout

サーバーとの接続を確立している間、リクエストをサーバーに渡している間、または応答ヘッダーを読んでいる間にタイムアウトが発生しました。

invalid_header

サーバが空か無効な応答を返しました。

http_500

サーバがコード500のレスポンスを返しました。

http_503

はコード503のレスポンスを返しました。

http_403

サーバはコード403で応答を返しました。

http_404

サーバーはコード 404 で応答を返しました。

http_429

サーバーはコード429 (1.11.13)のレスポンスを返しました。 非親和性の

通常、リクエストがアップストリームサーバ (1.9.13) に送られた場合、非親和的なメソッド (POST, LOCK, PATCH) を持つリクエストは次のサーバに渡されません。

off

は次のサーバへのリクエストの受け渡しを無効にします。 次のサーバへのリクエストの受け渡しは、まだクライアントに何も送信されていない場合にのみ可能であることを覚えておくべきです。つまり、レスポンスの転送中にエラーやタイムアウトが発生した場合、 これを修正することは不可能です。

このディレクティブでは、サーバとの通信の試みが失敗したとみなされるものも定義しています。error, timeout, invalid_header の場合は、たとえディレクティブで指定されていなくても、 常に失敗したとみなされます。http_500, http_503, http_429 の場合は、ディレクティブで指定されている場合に限り、 失敗したとみなされます。http_403 と http_404 の場合は、失敗したとみなされることはありません。

次のサーバへのリクエストの受け渡しは、試行回数と時間によって制限されます。

このディレクティブはバージョン 1.7.5 で登場しました。

リクエストを次のサーバに渡す時間を制限します。0 の値はこの制限を無効にします。

このディレクティブはバージョン 1.7.5 で登場しました。

次のサーバにリクエストを渡すための試行回数を制限します。0 の値はこの制限を無効にします。

レスポンスがキャッシュに保存されない条件を定義します。文字列パラメータのうち少なくとも一つの値が空でなく、かつ "0" でない場合、レスポンスは保存されません。

fastcgi_cache_bypass ディレクティブと一緒に使うことができます。

FastCGI サーバーに渡すパラメータを設定します。値には、テキスト、変数、およびそれらの組み合わせを含めることができます。これらの記述内容は、現在のレベルで定義されている fastcgi_param 記述内容がない場合にのみ、前のレベルから継承されます。

次の例は、PHP で必要最低限の設定を示しています。

PHPではスクリプト名を決定するために SCRIPT_FILENAME パラメータを使用し、 パラメータ要求: を渡すために QUERY_STRING パラメータを使用します。

POSTリクエストを処理するスクリプトの場合は、以下の3つのパラメータも必要です。

PHP が --enable-force-cgi-redirect 設定パラメータでビルドされている場合は、 REDIRECT_STATUS パラメータにも値 "200" を指定しなければなりません。

fastcgi_param REDIRECT_STATUS 200;

ディレクティブが if_not_empty (1.1.11) で指定されている場合は、 その値が空でない場合にのみサーバに渡されます。

fastcgi_param HTTPS $https if_not_empty;

FastCGI サーバーのアドレスを設定します。アドレスは、ドメイン名またはIPアドレス、ポートを指定することができます。

fastcgi_pass localhost:9000。

または、UNIX ドメインのソケットパスとして指定できます。

fastcgi_pass unix:/tmp/fastcgi.socket。

ドメイン名が複数のアドレスに解決された場合、すべてのアドレスがラウンドロビン方式で使用されます。また、サーバーグループとしてアドレスを指定することもできます。

パラメータ値には変数を含めることができます。この場合、ドメイン名としてアドレスを指定すると、記述されたサーバグループの中から検索し、見つからなければリゾルバを用いて決定します。

FastCGI サーバーから client.t ヘッダーフィールドに、そうでなければ無効なヘッダーフィールドを渡すことを許可します。

元のリクエストボディを FastCGI サーバに渡すかどうかを示します。fastcgi_pass_request_headers ディレクティブも参照してください。

元のリクエストのヘッダフィールドを FastCGI サーバに渡すかどうかを示します。fastcgi_pass_request_body ディレクティブも参照してください。

FastCGI サーバーからの応答を読み込むためのタイムアウトを定義します。タイムアウトは、2 つの連続した読み取り操作の間にのみ設定され、応答全体の送信には設定されません。FastCGI サーバーがこの時間内に何も送信しない場合、接続は閉じられます。

このディレクティブはバージョン 1.7.11 で登場しました。

クライアントのリクエストボディのバッファリングを有効または無効にします。

バッファリングを有効にすると、要求を FastCGI サーバに送信する前に、クライアントから要求本文全体が読み込まれます。

バッファリングを無効にすると、要求本文は受信するとすぐに FastCGI サーバーに送信されます。この場合、nginx が既にリクエストボディの送信を開始している場合、次のサーバーにリクエストを渡すことはできません。

このディレクティブが 0 以外の値に設定されている場合、nginx は、kqueue メソッドの NOTE_LOWAT フラグか SO_SNDLOWAT ソケットオプションを指定したサイズで使用して、FastCGI サーバへの送信操作の数を最小限に抑えようとします。

このディレクティブは Linux、Solaris、Windows では無視されます。

FastCGI サーバーに要求を送信するためのタイムアウトを設定します。タイムアウトは、2 つの連続した書き込み操作の間にのみ設定され、要求全体の送信には設定されません。FastCGI サーバーがこの時間内に何も受信しない場合、接続は閉じられます。

このディレクティブはバージョン 1.15.6 で登場しました。

FastCGI サーバへの送信接続の "TCP keepalive" 動作を設定します。デフォルトでは、オペレーティングシステムの設定がソケットに対して有効になっています。このディレクティブが値 "on" に設定されている場合、SO_KEEPALIVE ソケットオプションがソケットに対して有効になります。

変数 $fastcgi_path_info の値をキャプチャする正規表現を定義します。正規表現は2つのキャプチャを持つ必要があります: 1つ目は$fastcgi_script_name変数の値になり、2つ目は$fastcgi_path_info変数の値になります。例えば、以下の設定では

と"/show.php/article/0001 "リクエスト、SCRIPT_FILENAMEパラメータは"/path/to/php/show.php "と同じになり、PATH_INFOパラメータは"/article/0001 "と同じになります。

ファイルのディスクへの保存を有効にします。on パラメータを指定すると、記述内容エイリアスまたはルートに対応するパスでファイルを保存します。off パラメータを指定すると、ファイルの保存を無効にします。また，ファイル名は変数付きの文字列を用いて明示的に設定することができます．

fastcgi_store /data/www$original_uri;

ファイルの修正時間は、受信した "Last-Modified "応答ヘッダフィールドに応じて設定される。レスポンスは最初に一時ファイルに書き込まれ、その後ファイル名が変更されます。バージョン0.8.9からは、一時ファイルと永続ストアを別のファイルシステムに置くことができます。しかし、この場合、ファイルは安価なリネーム操作ではなく、2つのファイルシステムにまたがってコピーされることに注意してください。したがって、任意の場所では、保存されたファイルと fastcgi_temp_path ディレクティブで設定された一時ファイルを保持するディレクトリの両方を同じファイルシステムに置くことが推奨されています。

このディレクティブは、静的で変更不可能なファイルのローカルコピーを作成するために使われます。

新しく作成されたファイルやディレクトリのアクセス権限を設定します。

fastcgi_store_access user:rw group:rw all:r. グループまたはすべてのアクセス権限が指定されている場合は、ユーザー権限は省略することができます。

fastcgi_store_access group:rw all:r;

FastCGI サーバからの応答の一時ファイルへのバッファリングが有効な場合、一度に一時ファイルに書き込まれるデータのサイズを制限します。デフォルトでは、サイズは fastcgi_buffer_size と fastcgi_buffers 記述内容で設定された 2 つのバッファによって制限される。一時ファイルの最大サイズは fastcgi_max_temp_file_size ディレクティブで設定します。

FastCGI サーバから受信したデータを一時ファイルとして保存するためのディレクトリを定義します。指定したディレクトリの下には、3階層までのサブディレクトリ階層を使用することができます。例えば、次の設定では

fastcgi_temp_path /spool/nginx/fastcgi_temp 1 2.

一時ファイルは次のようになります。

/spool/nginx/fastcgi_temp/7/45/00000123457

fastcgi_cache_path ディレクティブの use_temp_path パラメータも参照してください。

Parameters Passed to a FastCGI Server

HTTP リクエストヘッダーフィールドは、パラメータとして FastCGI サーバーに渡されます。FastCGI サーバーとして実行されているアプリケーションやスクリプトでは、これらのパラメータは通常、環境変数として利用可能になります。例えば、「User-Agent」ヘッダーフィールドは、HTTP_USER_AGENT パラメータとして渡されます。HTTP リクエストヘッダフィールドに加えて、fastcgi_param ディレクティブを使って任意のパラメータを渡すことができます。

埋め込み変数

ngx_http_fastcgi_module モジュールは、fastcgi_param ディレクティブを使用してパラメータを設定するために使用できる埋め込み変数をサポートしています。

fastcgi_script_name

リクエストURI、あるいはURIがスラッシュで終わっている場合は、 fastcgi_index ディレクティブで設定したインデックスファイル名を付加したリクエストURIを指定します。この変数は、PHP のスクリプト名を決定する SCRIPT_FILENAME および PATH_TRANSLATED パラメータを設定するために使用できます。例えば、以下のような "/info/" リクエストの場合、以下のようになります。

記述内容

fastcgi_index index.php。 fastcgi_param SCRIPT_FILENAME /home/www/scripts/php$fastcgi_script_name。 SCRIPT_FILENAMEパラメータは"/home/www/scripts/php/info/index.php "と同じになります。 fastcgi_split_path_info ディレクティブを使用する場合、$fastcgi_script_name 変数は、ディレクティブによって設定された最初のキャプチャの値と等しくなります。

fastcgi_split_path_info ディレクティブを使用する場合は、 $fastcgi_script_name 変数はディレクティブによって設定された最初のキャプチャの値と等しくなります。 fastcgi_split_path_info ディレクティブで設定された 2 番目のキャプチャの値。この変数はPATH_INFOパラメータを設定するために使用できます。

Module ngx_http_flv_module

ngx_http_flv_module モジュールは、Flash Video (FLV) ファイルの擬似ストリーミングをサーバサイドでサポートします。

リクエストURIの問い合わせ文字列の中に start 引数を持つリクエストを特別に扱い、リクエストされたバイトオフセットから始まるファイルの内容を、前もって付加された FLV ヘッダと共に送り返すことで、リクエストを処理します。

このモジュールはデフォルトではビルドされていないので、 --with-http_flv_module 設定パラメータで有効にする必要があります。

設定例

記述内容

周囲の場所でのモジュール処理をオンにします。

Module ngx_http_geo_module

ngx_http_geo_moduleモジュールは、クライアントのIPアドレスに応じた値を持つ変数を作成します。

設定例

記述内容

指定した変数の値のクライアントIPアドレスへの依存性を記述します。デフォルトでは、アドレスは $remote_addr 変数から取得されますが、別の変数 (0.7.27) から取得することもできます。

変数は使用時にのみ評価されるので、宣言された「ジオ」変数が多数存在しても、 リクエスト処理のための余分なコストは発生しない。 変数の値が有効なIPアドレスを表さない場合、「255.255.255.255.255」アドレスが使用される。

アドレスは、CIDR表記のプレフィックス(個々のアドレスを含む)または範囲(0.7.23)のいずれかで指定されます。

IPv6プレフィックスはバージョン1.3.10および1.2.7からサポートされています。 以下の特別なパラメータもサポートされています。

delete

指定したネットワークを削除します (0.7.23)。

default

クライアントアドレスが指定されたアドレスのいずれとも一致しない場合に変数に設定される値。アドレスがCIDR表記で指定されている場合、デフォルトの代わりに "0.0.0.0.0/0 "と"::/0 "を使用することができます。defaultが指定されていない場合、デフォルト値は空文字列となります。

include

には、アドレスと値を含むファイルが含まれています。いくつかのインクルードがあります。

proxy

は信頼されたアドレス(0.8.7, 0.7.63)を定義する。リクエストが信頼されたアドレスから来る場合、"X-Forwarded-For" リクエストヘッダーフィールドのアドレスが代わりに使用される。通常のアドレスとは対照的に、信頼されたアドレスは順次チェックされる。 トラステッドされたIPv6アドレスはバージョン1.3.0と1.2.1からサポートされています。

proxy_recursive

再帰的なアドレス検索を有効にします(1.3.0, 1.2.1)。再帰検索が無効になっている場合、信頼されているアドレスの1つに一致する元のクライアントアドレスの代わりに、「X-Forwarded-For」で送信された最後のアドレスが使用されます。再帰検索が有効な場合、信頼されたアドレスの1つに一致する元のクライアントアドレスの代わりに、「X-Forwarded-For」で送信された最後の非信頼されたアドレスが使用されます。

ranges

は、アドレスが範囲指定されていることを示します（0.7.23）。このパラメータは最初に指定する必要があります。ジオベースの読み込みを高速化するために、アドレスは昇順に配置する必要があります。

Example:

conf/geo.confファイルには以下の行が含まれている可能性があります。

最も特定の一致する値が使用されます。例えば、127.0.0.0.1のアドレスでは、"US "ではなく "RU "が選択されます。

Example with ranges:

Module ngx_http_geoip_module

ngx_http_geoip_module モジュール (0.8.6+) は、コンパイル済みの MaxMind データベースを使用して、クライアントの IP アドレスに応じた値を持つ変数を作成します。

IPv6 対応のデータベース (1.3.12, 1.2.7) を使用している場合、IPv4 アドレスは IPv4 マップされた IPv6 アドレスとして検索されます。

このモジュールはデフォルトではビルドされていませんので、 --with-http_geoip_module 設定パラメータで有効にしてください。

This module requires the MaxMind GeoIP library. 設定例

記述内容

クライアントの IP アドレスに応じて国を決定するために使用するデータベースを指定します。このデータベースを使用する際には、以下の変数を使用できます。

$geoip_country_code

2文字の国コード、例えば "RU", "US "など。

$geoip_country_code3

3文字の国コード、例えば "RUS", "USA "など。

国コードは、"RUS"、"USA "などです。

国名、例えば "ロシア連邦", "アメリカ合衆国 "など。

クライアントの IP アドレスに応じて国、地域、および都市を決定するために使用するデータベースを指定します。このデータベースを使用する際には、以下の変数を使用できます。

$geoip_area_code

電話番号の市外局番(米国のみ)です。 対応するデータベースフィールドが非推奨なので、この変数には古い情報が含まれている可能性があります。

$geoip_city_continent_code

2文字の大陸コード、例えば "EU", "NA "など。

$geoip_city_country_code

2文字の国コード、例えば "RU", "US "など。

$geoip_city_country_code3

3文字の国コード、例えば "RUS", "USA "など。

$geoip_city_country_name

国名、例えば "ロシア連邦"、"アメリカ合衆国 "など。

$geoip_dma_code

Google AdWords APIのジオターゲティングによると、米国のDMAリージョンコード（別名「メトロコード」）。

$geoip_latitude

latitude.

$geoip_longitude

longitude.

$geoip_region

二文字国地域コード (地域、領土、州、州、連邦地など)例えば「48」、「DC」など。

$geoip_region_name

国の地域名（地域、領土、州、州、連邦の土地など）、例えば「モスクワ市」、「コロンビア特別区」など。

$geoip_city

都市名、例えば "モスクワ"、"ワシントン "など。

$geoip_postal_code

postal code.

クライアントの IP アドレスに応じて組織を決定するために使用するデータベースを指定します。このデータベースを使用する場合は、次の変数を指定します。

$geoip_org

組織名、例えば "The University of Melbourne "など。

信頼できるアドレスを定義する。リクエストが信頼されたアドレスから来る場合、"X-Forwarded-For" リクエストヘッダーフィールドのアドレスが代わりに使用されます。

再帰検索が無効になっている場合、信頼されたアドレスの1つに一致する元のクライアントアドレスの代わりに、「X-Forwarded-For」で送信された最後のアドレスが使用されます。再帰検索が有効な場合、信頼されたアドレスの1つに一致する元のクライアントアドレスの代わりに、「X-Forwarded-For」で送信された最後の非信頼されたアドレスが使用されます。

###Module ngx_http_grpc_module ngx_http_grpc_module モジュールを使用すると、gRPC サーバ (1.13.10) にリクエストを渡すことができます。このモジュールには ngx_http_v2_module モジュールが必要です。

設定例

gRPC サーバへの発信接続を、オプションのポートを指定して、指定したローカル IP アドレスから発信するようにします。パラメータ値には変数を含めることができます。特別な値 off は、以前の構成レベルから継承された grpc_bind ディレクティブの効果をキャンセルし、システムがローカル IP アドレスとポートを自動的に割り当てることを可能にします。

透過パラメータを指定すると、gRPC サーバへの発信接続を、ローカルではない IP アドレス、例えば、クライアントの実在の IP アドレスから発信することができます。

このパラメータを動作させるためには、通常、スーパーユーザ権限でnginxワーカープロセスを実行する必要があります。Linux では、transparent パラメータが指定されている場合、ワーカープロセスはマスタープロセスから CAP_NET_RAW 機能を継承するため、必要ありません。また、gRPC サーバからのネットワークトラフィックを遮断するために、カーネルルーティングテーブルを設定する必要があります。

gRPC サーバから受信したレスポンスを読み込むために使用するバッファのサイズを設定します。レスポンスは、受信するとすぐに同期的にクライアントに渡されます。

gRPC サーバとの接続を確立するためのタイムアウトを定義します。このタイムアウトは通常75秒を超えることはできないことに注意してください。

デフォルトでは、nginx は gRPC サーバのレスポンスから "Date", "Server", "X-Accel-..." というヘッダフィールドをクライアントに渡しません。grpc_hide_header ディレクティブは、渡さない追加のフィールドを設定します。逆に、フィールドの受け渡しを許可する必要がある場合は、 grpc_pass_header ディレクティブを使用することができます。

gRPC サーバーからの特定の応答ヘッダーフィールドの処理を無効にします。以下のフィールドは無視することができます。"X-Accel-Redirect" および "X-Accel-Charset"。

無効化されていない場合、これらのヘッダフィールドの処理は以下の効果を持つ。

"X-Accel-Redirect」は指定されたURIへの内部リダイレクトを実行する。 "X-Accel-Charset」は応答の希望する文字セットを設定する。

300 以上のコードを持つ gRPC サーバの応答をクライアントに渡すか、 傍受して nginx にリダイレクトして error_page ディレクティブで処理するかを決定します。

どのような場合にリクエストを次のサーバに渡すかを指定します。

error サーバとの接続の確立、サーバへのリクエストの受け渡し、またはレスポンスヘッダの読み込み中にエラーが発生しました。 timeout サーバーとの接続を確立している間、リクエストをサーバーに渡している間、または応答ヘッダーを読んでいる間にタイムアウトが発生しました。 invalid_header サーバが空か無効な応答を返しました。 http_500 サーバがコード 500 のレスポンスを返しました。 http_502 サーバはコード 502 のレスポンスを返しました。 http_503 はコード503のレスポンスを返しました。 http_504 サーバーからコード504のレスポンスが返ってきました。 http_403 サーバーはコード404で応答を返しました。 http_404 a server returned a response with the code 404; http_429 サーバーからコード429の応答が返ってきました。 non_idempotent 通常は、非親和的なメソッド (POST, LOCK, PATCH) を持つリクエストは、リクエストがアップストリームサーバに 送られた場合、次のサーバには渡されません。

off は、次のサーバへのリクエストの受け渡しを無効にします。 次のサーバへのリクエストの受け渡しは、まだクライアントに何も送られていない場合にのみ可能であることを心に留めておくべきです。つまり、レスポンスの転送中にエラーやタイムアウトが発生した場合、これを修正することは不可能です。

このディレクティブでは、サーバとの通信の試みが失敗したとみなされるものも定義しています。error, timeout, invalid_header の場合は、たとえディレクティブで指定されていなくても、 常に失敗したとみなされます。http_500, http_502, http_503, http_504, http_429 の場合は、ディレクティブで指定されている場合のみ、 失敗したとみなされます。http_403 と http_404 の場合は、失敗したとみなされることはありません。

次のサーバへのリクエストの受け渡しは、試行回数や時間によって制限されます。

リクエストを次のサーバーに渡すことができる時間を制限します。0 の値はこの制限をオフにします。

次のサーバーにリクエストを渡すための試行回数を制限します。0 の値はこの制限を無効にします。

gRPC サーバのアドレスを設定します。アドレスは、ドメイン名またはIPアドレス、ポートを指定できます。

grpc_pass localhost:9000。

または、UNIX ドメインのソケットパスとして指定できます。

grpc_pass unix:/tmp/grpc.socket。

あるいは、"grpc://" スキームを使用することもできます。

grpc_pass grpc://127.0.0.0.1:9000。

SSL 上で gRPC を使用するには、"grpcs://" スキームを使用する必要があります。

grpc_pass grpcs://127.0.0.0.1:443。

ドメイン名が複数のアドレスに解決する場合は、その全てがラウンドロビン方式で使用されます。また、サーバーグループとしてアドレスを指定することもできます。

パラメータ値には変数を含めることができます（1.17.8）。この場合、ドメイン名としてアドレスが指定された場合は、記述されたサーバグループの中から検索し、見つからない場合はリゾルバを用いて決定する。

そうでなければ無効になっているヘッダフィールドを gRPC サーバからクライアントに渡すことを許可します。

gRPC サーバから応答を読み込む際のタイムアウトを定義します。タイムアウトは、2つの連続した読み込み操作の間にのみ設定され、応答全体の送信に対しては設定されません。gRPC サーバがこの時間内に何も送信しない場合、接続は閉じられます。

リクエストを gRPC サーバに送信するためのタイムアウトを設定します。タイムアウトは2つの連続した書き込み操作の間にのみ設定され、リクエスト全体の送信には設定されません。gRPCサーバがこの時間内に何も受信しない場合、接続は閉じられます。

gRPC サーバーに渡されたリクエストヘッダーにフィールドを再定義または追加することができます。値には、テキスト、変数、およびそれらの組み合わせを含めることができます。これらのディレクティブは、現在のレベルで定義されている grpc_set_header ディレクティブがない場合にのみ、前のレベルから継承されます。

ヘッダ・フィールドの値が空文字列の場合、このフィールドは gRPC サーバに渡されません。

gRPCサーバへの送信接続の「TCP keepalive」動作を設定します。デフォルトでは、オペレーティングシステムの設定がソケットに対して有効になっています。ディレクティブの値が "on" に設定されている場合、SO_KEEPALIVE ソケットオプションがソケットに対して有効になります。

gRPC SSL サーバへの認証に使用する証明書を PEM 形式で指定します。

gRPC SSL サーバへの認証に使用する PEM 形式の秘密鍵のファイルを指定します。

ファイルの代わりに engine:name:id を指定すると、OpenSSL エンジン名から指定された id の秘密鍵を読み込みます。

gRPC SSL サーバへのリクエストで有効な暗号化方式を指定します。暗号化方式は OpenSSL ライブラリで理解される形式で指定されます。

完全なリストは "openssl ciphers" コマンドで見ることができます。

gRPC SSL サーバの証明書を検証するために使用する PEM 形式の失効した証明書 (CRL) を含むファイルを指定します。

gRPC SSL サーバとの接続を確立する際に、gRPC SSL サーバの証明書を検証し、SNI に渡すために使用するサーバ名をオーバーライドすることができます。

デフォルトでは、grpc_pass のホスト部分が使用されます。

秘密鍵のパスフレーズを含むファイルを指定し、各パスフレーズを別の行で指定します。パスフレーズは、鍵の読み込み時に順番に試行されます。

gRPC SSLサーバへのリクエストに指定されたプロトコルを有効にします。

gRPC SSL サーバーとの接続を確立する際に、TLS Server Name Indication extension (SNI, RFC 6066) を通じてサーバー名を渡すことを有効または無効にします。

gRPCサーバで作業する際にSSLセッションを再利用できるかどうかを決定します。ログに「SSL3_GET_FINISHED:digest check failed」というエラーが表示された場合は、セッションの再利用を無効にしてみてください。

gRPC SSL サーバの証明書を検証するために使用する PEM 形式の信頼できる CA 証明書を含むファイルを指定します。

gRPC SSLサーバ証明書の検証を有効または無効にします。

gRPC SSLサーバ証明書チェーンの検証深度を設定します。

Module ngx_http_gunzip_module

ngx_http_gunzip_moduleモジュールは、エンコーディング方式が "gzip "に対応していないクライアントに対して、レスポンスを "Content-Encoding: gzip "で解凍するフィルタです。省スペース化やI/Oコスト削減のために圧縮してデータを保存したい場合に便利なモジュールです。

このモジュールはデフォルトではビルドされていないので、 --with-http_gunzip_module設定パラメータで有効にする必要があります。

設定例

記述内容

gzip をサポートしていないクライアントに対して、 gzip で圧縮された応答の展開を有効または無効にします。有効にすると、クライアントが gzip をサポートしているかどうかを判断する際に、 以下のディレクティブも考慮されます: gzip_http_version, gzip_proxied, gzip_disable。gzip_vary ディレクティブも参照してください。

レスポンスの解凍に使用するバッファの数とサイズを設定します。デフォルトでは、バッファサイズは1メモリページに相当します。これは、プラットフォームに応じて 4K または 8K のいずれかになります。

Module ngx_http_gzip_module

ngx_http_gzip_module モジュールは、レスポンスを "gzip" 方式で圧縮するフィルタです。これにより、送信データのサイズを半分、あるいはそれ以上に減らすことができます。

SSL/TLS プロトコルを使用している場合、圧縮されたレスポンスは BREACH 攻撃を受ける可能性があります。

設定例

記述内容

レスポンスの圧縮を有効または無効にします。

レスポンスの圧縮に使用するバッファの数とサイズを設定します。デフォルトでは、バッファのサイズは1メモリページに相当します。これは、プラットフォームに応じて 4K または 8K のどちらかになります。

バージョン 0.7.28 までは、デフォルトで 4K または 8K のバッファが 4 つ使用されていました。

レスポンスの gzip 圧縮レベルを設定します。受け入れ可能な値は 1 から 9 の範囲です。

指定された正規表現のいずれかにマッチする "User-Agent" ヘッダフィールドを持つリクエストに対する応答の gzip 化を無効にする。

特別なマスク「msie6」(0.7.12)は正規表現「MSIE [4-6].」に対応するが、より速く動作する。バージョン0.8.11より、「MSIE 6.0; ... SV1」を除外しています。SV1 "はこのマスクから除外されています。

レスポンスを圧縮するために必要なリクエストのHTTPバージョンの最小値を設定します。

gzip されるレスポンスの最小長を設定します。この長さは "Content-Length" レスポンスヘッダフィールドからのみ決定されます。

リクエストと応答に応じて、プロキシされたリクエストに対する応答の gzip 化を有効または無効にします。リクエストがプロキシされているかどうかは、"Via" リクエストヘッダフィールドの存在によって判断されます。このディレクティブは複数のパラメータを受け付けます。

off は、他のパラメータを無視して、すべてのプロキシされたリクエストの圧縮を無効にします。 expired は、応答ヘッダーにキャッシュを無効にする値を持つ「Expires」フィールドが含まれている場合、圧縮を有効にする。 no-cache は、レスポンスヘッダに "Cache-Control" フィールドに "no-cache" パラメータが含まれている場合に圧縮を有効にします。 no-store は、レスポンスヘッダに "no-store" パラメータを持つ "Cache-Control" フィールドが含まれている場合に圧縮を有効にします。 private は、応答ヘッダに "Cache-Control" フィールドに "private" パラメータが含まれている場合に圧縮を有効にします。 no_last_modified は、レスポンスヘッダに "Last-Modified" フィールドが含まれていない場合に圧縮を有効にします。 no_etag は、レスポンスヘッダに "ETag" フィールドが含まれていない場合に圧縮を有効にします。 auth は、リクエストヘッダに "Authorization" フィールドが含まれている場合に圧縮を有効にします。 any は、すべてのプロキシされたリクエストに対して圧縮を有効にします。

text/html」に加えて、指定したMIMEタイプのレスポンスのgzip化を有効にします。特別な値 "*" は任意の MIME タイプにマッチします (0.8.29)。text/html」タイプのレスポンスは常に圧縮されます。

Vary.Accept-Encoding" レスポンスヘッダフィールドの挿入を有効または無効にする。gzip, gzip_static, gunzip ディレクティブがアクティブな場合に、 "Accept-Encoding" 応答ヘッダフィールドを挿入することを有効または無効にする。

Embedded Variables $gzip_ratio 達成された圧縮率。元の応答サイズと圧縮された応答サイズの間の比率として計算されます。

Module ngx_http_gzip_static_module

ngx_http_gzip_static_module モジュールを使用すると、通常のファイルの代わりに ".gz" という拡張子で圧縮前のファイルを送信することができます。

このモジュールはデフォルトではビルドされていないので、 --with-http_gzip_static_module 設定パラメータで有効にしなければなりません。

設定例 gzip_static on; gzip_proxied expired no-cache no-store private auth.

記述内容

圧縮前のファイルの存在を確認することを有効(「on」)、または無効(「off」)にする。gzip_http_version, gzip_proxied, gzip_disable, gzip_vary の各ディレクティブも考慮されています。

always" を指定すると (1.3.6)、クライアントがサポートしているかどうかを確認することなく、すべての場合で gzipped ファイルが使用されます。いずれにしてもディスク上に圧縮されていないファイルがない場合や、ngx_http_gunzip_module を使用している場合に便利です。

ファイルの圧縮には gzip コマンドやその他の互換性のあるものを使用します。元のファイルと圧縮されたファイルの更新日時は同じにすることをお勧めします。

Module ngx_http_headers_module

設定例

記述内容 add_header add_trailer expires

ngx_http_headers_module モジュールを使用すると、レスポンスヘッダに "Expires" および "Cache-Control" ヘッダフィールド、および任意のフィールドを追加することができます。

設定例 expires 24h; expires modified +24h; expires @24h; expires 0; expires -1; expires epoch; expires $expires; add_header Cache-Control private; 記述内容

応答コードが 200、201 (1.3.10)、204、206、301、302、303、304、307 (1.1.16、1.0.13)、または 308 (1.13.0) である場合に、指定されたフィールドを応答ヘッダーに追加します。パラメータ値には変数を含めることができます。

add_header 記述内容はいくつかあります。これらの記述内容は、現在のレベルに add_header 記述内容が定義されていない場合にのみ、前のレベルから継承されます。

always パラメータが指定されている場合 (1.7.5)、レスポンス・コードに関係なくヘッダ・フィールドが追加されます。

応答コードが 200、201 (1.3.10)、204、206、301、302、303、304、307 (1.1.16、1.0.13)、または 308 (1.13.0) である場合に、指定されたフィールドを応答ヘッダーに追加します。 パラメータ値には変数を含めることができます。

add_header 記述内容はいくつかあります。 これらの記述内容は、レスポンスコードが 200, 201, 206, 301, 302, 303, 307, 308 に等しい場合に、指定されたフィールドをレスポンスの最後に追加する前置修飾子から継承されます。

パラメータ値には変数を含めることができます。

応答コードが 200、201 (1.3.10)、204、206、301、302、303、304、307 (1.1.16、1.0.13)、または 308 (1.13.0) である場合、「Expires」および「Cache-Control」応答ヘッダーフィールドの追加または変更を有効または無効にします。パラメータは、正の時間または負の時間であることができる。

Expires "フィールドの時間は、現在の時間とディレクティブで指定された時間の合計として計算されます。もし変更されたパラメータ (0.7.0, 0.6.32) が使用されている場合は、ファイルの変更時刻とディレクティブで指定された時刻の合計として計算されます。

また、接頭辞「@」を使って時間帯を指定することも可能です（0.7.9、0.6.34）。

expires @15h30m; Cache-Control」フィールドの内容は、指定した時間の符号に依存します。

time is negative — “Cache-Control: no-cache”. time は正またはゼロ - "Cache-Control: max-age=t" で、t はディレクティブで指定された時間 (秒単位) です。 epoch パラメータは、"Expires" を "Thu, 01 Jan 1970 00:00:01 GMT" に、"Cache-Control" を "no-cache" に設定します。

maxパラメータは、"Expires "を "Thu, 31 Dec 2037 23:55:55 GMT "の値に、"Cache-Control "を10年に設定します。

off パラメータは、"Expires" および "Cache-Control" レスポンス・ヘッダ・フィールドの追加または変更を無効にします。

最後のパラメータ値には変数を含めることができます (1.7.9)。

Module ngx_http_hls_module

ngx_http_hls_module モジュールは、MP4 および MOV メディアファイルの HTTP ライブ ストリーミング (HLS) サーバーサイドのサポートを提供します。これらのファイルは通常、.mp4、.m4v、.m4a、.mov、または .qt ファイル名の拡張子を持ちます。モジュールは、H.264 ビデオコーデック、AAC および MP3 オーディオコーデックをサポートしています。

各メディアファイルに対して、2 つの URI がサポートされています。

.m3u8」というファイル名の拡張子を持つプレイリストのURI。このURIはオプションの引数を受け取ることができます。 "start" と "end" はプレイリストの境界を秒単位で定義する (1.9.0)。 "offset "は初期再生位置を秒単位の時間オフセットにシフトする(1.9.0)。正の値を指定すると、プレイリストの先頭からの時間オフセットが設定されます。負の値を指定すると、プレイリストの最後のフラグメントの終わりからの時間オフセットが設定されます。 "len" は、フラグメントの長さを秒単位で定義する。 フラグメント URI は、ファイル名拡張子 ".ts" を持つ。このURIはオプションの引数を受け取ることができます。 "start" と "end" はフラグメントの境界を秒単位で定義します。 このモジュールは商用サブスクリプションの一部として利用可能です。

設定例

この設定では、"/var/video/test.mp4 "ファイルに対して以下のURIがサポートされています。

 

記述内容

周囲の場所でのHLSストリーミングをオンにします。

データフレームの読み書きに使用するバッファの最大数とサイズを設定します。

プレイリストリクエストの引数をフラグメントの URI に追加します。これは、フラグメントをリクエストした瞬間にクライアントの認証を行ったり、 ngx_http_secure_link_module モジュールで HLS ストリームを保護したりする際に便利です。

例えば、クライアントがプレイリスト http://example.com/hls/test.mp4.m3u8?a=1&b=2 をリクエストした場合、引数 a=1 と b=2 は、引数の開始と終了の後にフラグメントの URI に追加されます。

HLS ストリームが ngx_http_secure_link_module モジュールで保護されている場合は、 secure_link_md5 式で $uri を使用すべきではありません。URI は、$uri (例では $hls_uri) の代わりに Base URI を使用する必要があります。

len" 引数なしでリクエストされたプレイリスト URI のデフォルトのフラグメント長を定義する。

MP4 および MOV ファイルの処理に使用するバッファの初期サイズを設定します。

メタデータの処理中に、より大きなバッファが必要になることがあります。そのサイズが指定されたサイズを超えることはできません。そうでない場合、nginx はサーバエラー 500 (Internal Server Error) を返し、以下のメッセージをログに残します。

Module ngx_http_image_filter_module

ngx_http_image_filter_module モジュール (0.7.54+) は、JPEG, GIF, PNG, WebP 形式の画像を変換するフィルタです。

このモジュールはデフォルトではビルドされていないので、 --with-http_image_filter_module 設定パラメータで有効にしなければなりません。

本モジュールは libgd ライブラリを利用しています。最新版の利用を推奨します。 WebP フォーマットのサポートはバージョン 1.11.6 で登場しました。このフォーマットで画像を変換するには、libgd ライブラリを WebP サポートでコンパイルする必要があります。

設定例

記述内容

画像に対して実行する変換の種類を設定します。

off

周囲の場所でのモジュール処理をオフにします。

test

は、応答が JPEG、GIF、PNG、または WebP 形式の画像であることを保証します。そうでない場合は 415 (Unsupported Media Type) エラーが返されます。

size

は、画像に関する情報をJSON形式で出力します。 { "img" : { "width". 100, "height" : { "width": 100, "height" : { "width": 100, "height" : { "width": 100, "height" : { "width": 100, "height" : { "width": 100, "height" : { "width": 100, "height" : { "width": 100, "height" : { "width": 100, "height" : { "width": 100, "height" : { "width": 100, "height" : 100, "width": 100, "height" : { "width": 100, "height" : 100, "width": 100 100, "type" "gif" } } エラーが発生した場合は、以下のように出力されます。

{}

rotate 90|180|270 画像を反時計回りに指定された角度だけ回転させます。パラメータ値には変数を含めることができます。このモードは単独で使用することも、リサイズやクロップ変換と一緒に使用することもできます。 resize width height 画像を指定したサイズに比例して縮小します。一次元だけ縮小するには、別の次元を"-"として指定することができます。エラーが発生した場合、サーバはコード415(Unsupported Media Type)を返します。パラメータ値には、変数を含めることができます。rotateパラメータと一緒に使用すると、縮小後に回転が行われます。 crop width height は、画像を大きな側面サイズに比例して縮小し、不要なエッジを別の側面で切り取ります。一次元だけ縮小するには、別の次元を"-"として指定することができます。エラーが発生した場合、サーバはコード415（サポートされていないメディアタイプ）を返します。パラメータ値には変数を含めることができます。rotateパラメータと一緒に使用すると、縮小の前に回転が行われます。

画像の読み込みに使用するバッファの最大サイズを設定します。サイズを超えると、サーバーはエラー415（サポートされていないメディアタイプ）を返します。

このオプションを有効にすると、最終画像はインターレースされます。JPEGの場合、最終画像は「プログレッシブJPEG」形式になります。

変換されたJPEG画像の希望する品質を設定します。設定可能な値は1～100の範囲です。値が小さいほど、通常は画像品質が低く、転送するデータ量も少ないことを意味します。最大推奨値は 95 です。パラメータの値には変数を含めることができます。

最終画像のシャープネスを向上させます。シャープネスの割合は100を超えることができます。ゼロの値はシャープネスを無効にします。パラメータの値には変数を含めることができます。

GIF 画像や PNG 画像をパレットで指定した色で変換するときに透明度を保つかどうかを定義します。透過性が失われると、より高品質な画像が得られます。PNG のアルファチャンネルの透明度は常に保持されます。

変換されたWebP画像の希望する品質を設定します。許容される値は、1 から 100 の範囲です。値が小さい場合は、通常、画像品質が低く、転送するデータが少ないことを意味します。パラメータ値には変数を含めることができます。

Module ngx_http_index_module

ngx_http_index_module モジュールは、スラッシュ文字 ('/') で終わるリクエストを処理します。このようなリクエストは、 ngx_http_autoindex_module および ngx_http_random_index_module モジュールでも処理できます。

設定例

location / { index index.$geo.html index.html; } 記述内容

インデックスとして使用するファイルを定義します。ファイル名には変数を含めることができます。ファイルは指定した順番でチェックされます。リストの最後の要素には、絶対パスを持つファイルを指定することができます。例

index index.$geo.html index.0.html /index.html。

インデックスファイルを使用すると内部リダイレクトが発生し、リクエストは別の場所で処理されることに注意する必要があります。例えば、以下のような設定の場合。

 

Module ngx_http_js_module

ngx_http_js_module モジュールは、JavaScript 言語のサブセットである njs で位置情報や変数のハンドラを実装するために使用します。

ダウンロードとインストールの手順はこちらをご覧ください。

設定例 この例は0.4.0から動作します。

The http.js file:

記述内容

njs関数をロケーションコンテンツハンドラとして設定します。0.4.0以降、モジュール関数を参照できるようになりました。

njsでロケーションハンドラと変数ハンドラを実装したモジュールをインポートします。export_nameはモジュールの関数にアクセスするための名前空間として使用されます。export_nameが指定されていない場合は、モジュール名が名前空間として使用されます。

js_import http.jsです。 ここでは、エクスポートにアクセスする際に、モジュール名のhttpが名前空間として使用されます。インポートしたモジュールに foo() が含まれている場合は、http.foo を参照するために使用します。

js_import 記述内容はいくつか指定できます。

njsのロケーションハンドラと変数ハンドラを実装したファイルを指定します。

nginx.conf:

http.js:

このディレクティブは 0.4.0 以降では非推奨となっており、代わりに js_import ディレクティブを使うべきです。

njsモジュールの追加パスを設定します。

指定した変数にnjs関数を設定します。0.4.0以降、モジュール関数を参照できるようになりました。

Request Argument Each HTTP njs handler receives one argument, a request object.

Module ngx_http_keyval_module

ngx_http_keyval_moduleモジュール(1.13.3)は、APIで管理されているキーと値のペアから取得した値を持つ変数や、 njsでも設定可能な変数(1.15.10)を作成します。

このモジュールは、当社の商用サブスクリプションの一部としてご利用いただけます。

設定例

記述内容

新しい $variable を作成し、その値が key-value データベースのキーによって検索されるようにします。一致するルールは keyval_zone ディレクティブの type パラメータで定義されます。データベースはzoneパラメータで指定した共有メモリゾーンに格納されます。

キー値データベースを保持する共有メモリゾーンの名前とサイズを設定します。キーと値のペアはAPIによって管理されます。

オプションのstateパラメータは、キー値データベースの現在の状態をJSON形式で保持し、nginxの再起動時に永続化するファイルを指定します。

Examples:

keyval_zone zone=one:32k state=/var/lib/nginx/state/one.keyval; # Linux のパス keyval_zone zone=one:32k state=/var/db/nginx/state/one.keyval; # FreeBSD のパス オプションの timeout パラメータ (1.15.0) は、キーと値のペアがゾーンから削除されるまでの時間を設定します。

オプションの type パラメータ (1.17.1) は、特定の型のキーのマッチングに最適化された追加のインデックスを有効にし、 keyval $variable を評価する際のマッチングルールを定義します。

インデックスは同じ共有メモリゾーンに格納されているため、追加のストレージが必要になります。 タイプ=文字列 変数の検索は、レコードキーと検索キーの完全一致を使用して実行されます。 タイプ レコードキーと一致するためには、検索キーはレコードキーで指定されたサブネットに属するか、IPアドレスと正確に一致しなければなりません。 タイプ=プレフィックス 変数の検索は、レコードキーと検索キーの接頭辞マッチを使用して行われます (1.17.5)。レコードキーにマッチするには、レコードキーが検索キーの接頭辞でなければなりません。 オプションのsyncパラメータ(1.15.0)を使用すると、共有メモリゾーンの同期が可能になります。同期化にはタイムアウト・パラメータの設定が必要です。

Module ngx_http_limit_conn_module

ngx_http_limit_conn_module モジュールは、定義されたキーごとの接続数、特に単一の IP アドレスからの接続数を制限するために使用します。

すべての接続がカウントされるわけではありません。接続がカウントされるのは、サーバで処理中のリクエストがあり、 リクエストヘッダ全体が既に読み込まれている場合に限られます。

設定例

記述内容

共有メモリゾーンと、指定されたキー値に対して許可される最大接続数を設定します。この制限を超えると、サーバはリクエストに応答してエラーを返します。例えば

limit_conn_zone $binary_remote_addr zone=addr:10m.

は一度に一つの IP アドレスに対して一つの接続しか許可しません。

HTTP/2 と SPDY では、それぞれの同時リクエストは別々の接続とみなされます。 いくつかの limit_conn ディレクティブがあるかもしれません。例えば、次の設定では、クライアント IP あたりのサーバーへの接続数を制限すると同時に、仮想サーバーへの接続数の合計を制限します。

これらのディレクティブは、現在のレベルに limit_conn ディレクティブが存在しない場合にのみ、前のレベルから継承されます。

ドライランモードを有効にします。このモードでは接続数に制限はありませんが、共有メモリゾーンでは通常通り過剰接続数を処理します。

サーバーが接続数を制限している場合のロギングレベルを設定します。

このディレクティブはバージョン 1.3.15 で登場しました。

拒否されたリクエストに対して返すステータスコードを設定します。

様々なキーの状態を保持する共有メモリゾーンのパラメータを設定します。特に、状態には現在の接続数が含まれます。キーには、テキスト、変数、およびそれらの組み合わせを含めることができます。空のキー値を持つリクエストは考慮されません。

バージョン 1.7.6 より前のバージョンでは、1 つのキーに正確に 1 つの変数を含めることができました。 使用例

limit_conn_zone $binary_remote_addr zone=addr:10m.

ここでは、クライアントの IP アドレスがキーとして機能します。ここでは、$remote_addr の代わりに $binary_remote_addr 変数が使用されていることに注意してください。変数 $remote_addr のサイズは、7 バイトから 15 バイトの範囲で指定できます。保存された状態は、32 ビット・プラットフォームでは 32 バイトまたは 64 バイトのメモリを占有し、64 ビット・プラットフォームでは常に 64 バイトのメモリを占有します。binary_remote_addr変数のサイズは、IPv4アドレスの場合は常に4バイト、IPv6アドレスの場合は常に16バイトです。保存された状態は、32ビット・プラットフォームでは常に32バイトまたは64バイト、64ビット・プラットフォームでは64バイトを占有します。1メガバイトのゾーンは、約32,000個の32バイトの状態、または約16,000個の64バイトの状態を保持することができる。ゾーンのストレージが枯渇した場合、サーバはそれ以降のすべてのリクエストに対してエラーを返します。

さらに、当社の商用サブスクリプションの一部として、1.17.7以降のAPIを使用して、各共有メモリゾーンの状態情報を取得またはリセットすることができます。.

このディレクティブはバージョン 1.1.8 で廃止され、バージョン 1.7.6 で削除されました。代わりに、構文を変更した同等の limit_conn_zone ディレクティブを使うべきです。

接続数を制限した結果を保持します(1.17.6)。PASSED、REJECTED、またはREJECTED_DRY_RUN

Module ngx_http_limit_req_module

ngx_http_limit_req_module モジュール (0.7.21) は、定義されたキーごとのリクエストの処理速度、特に単一の IP アドレスからのリクエストの処理速度を制限するために使用します。この制限は "leaky bucket" 方式を用いて行われます。

設定例

 

共有メモリゾーンとリクエストの最大バーストサイズを設定します。リクエストのレートがゾーンに設定されたレートを超えると、その処理が遅延し、定義されたレートで処理されるようになります。過度のリクエストは、その数が最大バーストサイズを超えるまで遅延され、その場合、リクエストはエラーで終了します。デフォルトでは、最大バーストサイズはゼロに等しい。例えば

は平均して 1 秒間に 1 リクエストを超えないようにし、バーストは 5 リクエストを超えないようにします。

リクエストが制限されている間に過剰なリクエストを遅延させたくない場合は、パラメータ nodelay を使うべきです。

limit_req zone=one burst=5 nodelay。

delayパラメータ(1.15.7)は、過剰なリクエストが遅延する限界を指定する。デフォルト値はゼロ、つまりすべての過剰なリクエストが遅延される。

いくつかの limit_req 記述内容があるかもしれない。例えば、次の設定では、単一の IP アドレスからのリクエストの処理速度を制限すると同時に、仮想サーバーによるリクエストの処理速度を制限します。

これらの記述内容は、現在のレベルに limit_req 記述内容が存在しない場合にのみ、前のレベルから継承されます。

ドライランモードを有効にします。このモードでは、リクエストの処理速度は制限されませんが、共有メモリゾーンでは通常通り過剰なリクエスト数が処理されます。

サーバがレートを超えてリクエストの処理を拒否した場合や、リクエストの処理が遅延した場合のロギングレベルを設定します。例えば、"limit_req_log_level notice "を指定した場合、遅延はinfoレベルで記録されます。

拒否されたリクエストに応答して返すステータスコードを設定します。

様々な鍵の状態を保持する共有メモリゾーンのパラメータを設定します。特に、状態は、現在の過剰な要求の数を保存します。キーには、テキスト、変数、およびそれらの組み合わせを含めることができます。空のキー値を持つリクエストは考慮されません。

バージョン 1.7.6 より前のバージョンでは、キーには正確に 1 つの変数を含めることができました。 使用例。

limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s.

ここでは、状態は10メガバイトのゾーン「one」に保持され、このゾーンの平均リクエスト処理速度は1秒あたり1リクエストを超えることはできません。

クライアントの IP アドレスがキーとなります。ここでは、$remote_addr の代わりに $binary_remote_addr 変数が使用されることに注意してください。binary_remote_addr変数のサイズは、IPv4アドレスの場合は常に4バイト、IPv6アドレスの場合は16バイトです。保存される状態は、32ビットプラットフォームでは常に64バイト、64ビットプラットフォームでは128バイトを占有します。1メガバイトのゾーンには、約16,000の64バイト、または約8,000の128バイトの状態を保持することができます。

ゾーンストレージが枯渇した場合、最近使用された状態が削除される。その後も新しい状態を作成できない場合、リクエストはエラーで終了する。

レートはリクエスト毎秒(r/s)で指定されます。1 秒間に 1 リクエスト未満のレートを希望する場合は、1 分間あたりのリクエスト (r/m) で指定します。例えば、1 秒あたりの半分のリクエストは 30r/m です。

syncパラメータ(1.15.3)は、共有メモリゾーンの同期を可能にします。

同期パラメータは、当社の商用サブスクリプションの一部として利用可能です。 さらに、当社の商用サブスクリプションの一部として、1.17.7以降のAPIを使用して、各共有メモリゾーンのステータス情報を取得またはリセットすることができます。 埋め込み変数 limit_req_status リクエスト処理速度を制限した結果を保持します(1.17.6)。PASSED, DELAYED, REJECTED, DELAYED_DRY_RUN, または REJECTED_DRY_RUN

Module ngx_http_log_module

ngx_http_log_moduleモジュールは、指定した形式でリクエストのログを書き込みます。

リクエストは、処理が終了した場所のコンテキストで記録されます。リクエスト処理中に内部リダイレクトが発生した場合は、元の場所とは異なる場合があります。

設定例

記述内容

バッファ付きログ書き込みのパス、フォーマット、および構成を設定します。同一レベルで複数のログを指定することができます。syslog へのログ記録は、最初のパラメータに "syslog:" 接頭辞を指定することで構成できます。特別な値 off は、現在のレベルのすべての access_log ディレクティブをキャンセルします。フォーマットが指定されていない場合は、事前に定義された "combined" フォーマットが使用されます。

buffer または gzip (1.3.10, 1.2.7) パラメータが使用されている場合、ログへの書き込みはバッファリングされます。

バッファのサイズは、ディスクファイルへのアトミックライトのサイズを超えてはなりません。FreeBSD では、このサイズは無制限です。 バッファリングを有効にすると、データはファイルに書き込まれます。

次のログ行がバッファに収まらない場合。 バッファに保存されたデータが flush パラメータ (1.3.10, 1.2.7) で指定されたものよりも古い場合。 ワーカープロセスがログファイルを再オープンしているか、シャットダウンしている場合。 gzip パラメータが使用されている場合、バッファリングされたデータはファイルに書き込む前に圧縮されます。圧縮レベルは、1 (最も速い、圧縮が少ない) から 9 (最も遅い、最高の圧縮) の間で設定することができます。デフォルトでは、バッファサイズは64Kバイトで、圧縮レベルは1に設定されています。 データはアトミックブロックで圧縮されているので、ログファイルはいつでも "zcat "によって解凍したり、読み込んだりすることができます。

Example:

gzip圧縮を動作させるためには、nginxをzlibライブラリでビルドする必要があります。

ファイルパスには変数を含むことができますが(0.7.6+)、そのようなログにはいくつかの制約があります。

は、ワーカープロセスが使用する資格情報を持つユーザが、そのようなログを持つディレクトリにファイルを作成する権限を持っていなければなりません。 バッファリングされた書き込みは動作しません。 バッファリングされた書き込みは動作しません。しかし、頻繁に使われるファイルの記述子はキャッシュに保存されるので、 古いファイルへの書き込みは open_log_file_cache ディレクティブの有効なパラメータで指定された時間の間は続けることができます。 はそれぞれのログ書き込みの間にリクエストのルートディレクトリの存在をチェックし、 存在しない場合はログを作成しません。したがって、root と access_log の両方を同じレベルで指定するのが良い考えです。

if パラメータ (1.7.0) は条件付きロギングを有効にします。条件が「0」と評価されるか空の文字列の場合、リクエストはログに記録されません。次の例では、レスポンスコード 2xx と 3xx のリクエストはログに記録されません。

access_log /path/to/access.log combined if=$loggable;

ログ形式を指定します。

escapeパラメータ(1.11.8)では、変数内のjsonまたはデフォルト文字のエスケープを設定することができます。none (1.13.10) はエスケープを無効にします。

デフォルトのエスケープでは、"""", "", その他の文字で、値が 32 (0.7.0)以下、または 126 (1.1.6)以上のものは、"\xXX "としてエスケープされます。変数値が見つからない場合は、ハイフン("-")がログに記録されます。

jsonエスケープのために、JSON文字列で許可されていないすべての文字がエスケープされます: characters """ and "" are escaped as """ and "\", characters with values less than 32 is escaped as "\n", "\r", "\t", "\b", "\f", or "\u00XX".

ログフォーマットには、共通の変数や、ログ書き込み時にのみ存在する変数を含めることができます。

$bytes_sent

クライアントに送信されるバイト数

$connection

コネクションシリアル番号

$connection_requests

接続を介して行われた現在のリクエスト数 (1.1.18)

$msec

ログ書き込み時にミリ秒単位の分解能を持つ秒単位の時間

$pipe

リクエストがパイプライン化されている場合は "p"、そうでない場合は "." です。

$request_length

リクエスト長 (リクエスト行、ヘッダ、リクエストボディを含む)

$request_time

クライアントから最初のバイトが読み込まれてから、最後のバイトがクライアントに送信された後にログが書き込まれるまでの経過時間。

$status

response status

$time_iso8601

local time in the ISO 8601 standard format

$time_local

コモンログフォーマットのローカルタイム 最近のnginxのバージョンでは、変数 $status (1.3.2, 1.2.2), $bytes_sent (1.3.8, 1.2.5), $connection (1.3.8, 1.2.5), $connection_requests (1.3.8, 1.2.5), $msec (1.3.9, 1.2.6) 6)、$request_time (1.3.9, 1.2.6)、$pipe (1.3.12, 1.2.7)、$request_length (1.3.12, 1.2.7)、$time_iso8601 (1.3.12, 1.2.7)、$time_local (1.3.12, 1.2.7)も共通変数として使用できます。 クライアントに送信されるヘッダ行には、「sent_http_」という接頭辞が付き、例えば「$sent_http_content_range」というようになります。

設定には、常に事前に定義された "combined "形式が含まれています。

 

名前に変数が含まれているよく使うログのファイルディスクリプタを保存するキャッシュを定義します。このディレクティブのパラメータは以下の通りです。

max

キャッシュが一杯になった場合，最近使用された(LRU)ディスクリプタはクローズされます． inactive この時間内にアクセスがなかった場合に、キャッシュされたディスクリプタがクローズされる時間を設定します。

min_uses

は、記述子をキャッシュで開いたままにするために、inactiveパラメータで定義された時間内のファイル使用数の最小値を設定します。

valid

は、同じ名前のファイルがまだ存在することを確認する時間を設定します。

off

キャッシングを無効化 使用例。

 

Module ngx_http_map_module

ngx_http_map_moduleモジュールは、他の変数の値に依存する変数を作成します。

設定例

記述内容

最初のパラメータで指定された1つ以上のソース変数の値に依存する値を持つ新しい変数を作成します。

バージョン0.9.0以前では、最初のパラメータには単一の変数しか指定できませんでした。 変数は使用されたときにのみ評価されるので、大量の "マップ "変数を宣言しても、リクエスト処理に余分なコストはかかりません。 マップブロック内のパラメータは、ソース値と結果の値の間のマッピングを指定する。

元の値は文字列か正規表現(0.9.6)で指定されます。

文字列は大文字小文字を無視してマッチします。

正規表現は、大文字小文字を区別しないマッチングの場合は"~"シンボルから始まるか、大文字小文字を区別しないマッチングの場合は"~*"シンボル(1.0.4)から始まるかのいずれかでなければなりません。正規表現には、名前付きのキャプチャと位置のキャプチャを含めることができ、それは後で結果の変数と一緒に他の記述内容で使用することができます。

ソース値が、以下に説明する特別なパラメータの名前の一つに一致する場合、それは""シンボルの前に接頭辞を付けるべきである。

結果として得られる値は、テキスト、変数(0.9.0)、およびそれらの組み合わせ(1.11.0)を含むことができます。

また、以下の特殊パラメータもサポートしています。

default value は、元の値が指定されたバリアントのどれにも一致しない場合に、結果の値を設定します。default が指定されていない場合、結果のデフォルト値は空の文字列となります。

hostname は、ソース値が接頭辞または接尾辞マスクを持つホスト名であることを示しています。

以下の二つのレコード

can be combined:

このパラメータは、値のリストの前に指定する必要があります。 インクルードファイル には値を含むファイルが含まれます。いくつかのインクルードがあります。 揮発性の は、その変数がキャッシュできないことを示します (1.11.7)。 ソース値が指定されたバリアントのうちの1つ以上にマッチした場合、例えばマスクと正規表現の両方にマッチした場合、最初にマッチしたバリアントが優先度の高い順に選択されます。

マスクなしの文字列値 プレフィックスマスクを持つ最長の文字列の値、例：".example.com" サフィックスマスクを持つ最長の文字列値、例えば "mail." 最初にマッチする正規表現 (設定ファイル内での出現順)

default value

マップ変数ハッシュテーブルのバケットサイズを設定します。デフォルト値はプロセッサのキャッシュラインサイズに依存します。ハッシュテーブルの設定の詳細については、別のドキュメントを参照してください。

マップ変数のハッシュテーブルの最大サイズを設定します。ハッシュテーブルの設定の詳細は別ドキュメントに記載しています。

モジュール ngx_http_memcached_module

ngx_http_memcached_module モジュールは、memcached サーバからのレスポンスを取得するために使用します。キーは$memcached_key変数に設定します。レスポンスは、あらかじめnginxの外部の手段でmemcachedに入れておく必要があります。

設定例

記述内容

memcached サーバへの発信接続を、オプションのポート (1.11.2) を使用して指定されたローカル IP アドレスから発信します。パラメータの値は変数を含むことができます(1.3.12)。特別な値 off (1.3.12) は、以前の設定レベルから継承された memcached_bind ディレクティブの効果をキャンセルし、システムがローカル IP アドレスとポートを自動的に割り当てることを可能にします。

transparent パラメータ (1.11.0) は、memcached サーバへの発信接続を、クライアントの実際の IP アドレスなどの非ローカル IP アドレスから発信することを可能にします。

memcached_bind $remote_addr transparent; このパラメータを動作させるためには、通常、スーパーユーザ権限で nginx ワーカープロセスを実行する必要があります。Linux では、transparent パラメータが指定されている場合、ワーカープロセスはマスタープロセスから CAP_NET_RAW 機能を継承するため、必要ありません (1.13.8)。また、memcached サーバからのネットワークトラフィックを遮断するために、カーネルルーティングテーブルを設定する必要があります。

memcached サーバから受信したレスポンスを読み込むために使用するバッファのサイズを設定します。レスポンスは、受信するとすぐに同期的にクライアントに渡されます。

memcached サーバとの接続を確立するためのタイムアウトを定義します。このタイムアウトは通常 75 秒を超えることはできないことに注意してください。

これらの応答の "Accept-Ranges" フィールドに関係なく、memcached サーバからのキャッシュされた応答とキャッシュされていない応答の両方でバイトレンジのサポートを有効にします。

memcached サーバのレスポンスにフラグがあるかどうかのテストを有効にし、フラグが設定されている場合は、"Content-Encoding" レスポンスヘッダフィールドを "gzip" に設定します。

どのような場合にリクエストを次のサーバーに渡すかを指定します。

error

サーバーとの接続を確立しているとき、リクエストをサーバーに渡しているとき、またはレスポンスヘッダを読んでいるときにエラーが発生しました。

timeout

サーバーとの接続を確立している間、リクエストをサーバーに渡している間、または応答ヘッダーを読んでいる間にタイムアウトが発生しました。

invalid_response

サーバーが空か無効な応答を返しました。

not_found

a response was not found on the server;

off

は、次のサーバへのリクエストの受け渡しを無効にします。 次のサーバへのリクエストの受け渡しは、まだクライアントに何も送られていない場合にのみ可能であることを心に留めておくべきです。つまり、レスポンスの転送中にエラーやタイムアウトが発生した場合、これを修正することは不可能です。

このディレクティブは、サーバとの通信の失敗とみなされるものも定義しています。error, timeout, invalid_response の場合は、たとえディレクティブで指定されていなくても、常に失敗したとみなされます。not_found の場合は失敗したとはみなされません。

次のサーバへのリクエストの受け渡しは、試行回数や時間によって制限されます。

リクエストを次のサーバーに渡すことができる時間を制限します。0 の値はこの制限をオフにします。

次のサーバーにリクエストを渡すための試行回数を制限します。0 の値はこの制限をオフにします。

memcached サーバのアドレスを設定します。アドレスは、ドメイン名またはIPアドレス、ポートを指定できます。

memcached_pass localhost:11211; or as a UNIX-domain socket path:

memcached_pass unix:/tmp/memcached.socket。 ドメイン名が複数のアドレスに解決された場合、すべてのアドレスがラウンドロビン方式で使用されます。また、サーバーグループとしてアドレスを指定することもできます。

memcached サーバから応答を読み込む際のタイムアウトを定義します。タイムアウトは、2 つの連続した読み込み操作の間にのみ設定され、応答全体の送信に対しては設定されません。memcached サーバがこの時間内に何も送信しない場合、接続は閉じられます。

memcached サーバにリクエストを送信するためのタイムアウトを設定します。タイムアウトは 2 回の連続した書き込み操作の間にのみ設定され、リクエスト全体の送信には設定されません。この時間内に memcached サーバが何も受信しない場合、接続は閉じられます。

memcached サーバへの送信接続の "TCP keepalive" 動作を設定します。デフォルトでは、オペレーティングシステムの設定がソケットに対して有効になっています。ディレクティブの値が "on" に設定されている場合、SO_KEEPALIVE ソケットオプションがソケットに対して有効になります。

埋め込み変数 メモリキャッシュされたキー memcached サーバからレスポンスを取得するためのキーを定義します。

Module ngx_http_mirror_module

ngx_http_mirror_module モジュール (1.13.4) は、バックグラウンドミラーサブリクエストを作成することで、 オリジナルのリクエストのミラーリングを実装しています。ミラーサブリクエストに対するレスポンスは無視されます。

設定例

記述内容

オリジナルのリクエストがミラーリングされる URI を設定します。同じレベルで複数のミラーを指定することができます。

クライアント要求本文がミラーリングされているかどうかを示します。有効にすると、クライアントリクエストボディはミラーサブリクエストを作成する前に読み込まれます。この場合、proxy_request_buffering、fastcgi_request_buffering、scgi_request_buffering、および uwsgi_request_buffering ディレクティブで設定されたバッファリングされていないクライアント リクエストボディのプロキシは無効になります。

Module ngx_http_perl_module

SSIからPerlを呼び出す r リクエストオブジェクトメソッド ngx_http_perl_module モジュールは、Perl で位置情報や変数のハンドラを実装したり、SSI に Perl の呼び出しを挿入したりするために使用します。

このモジュールはデフォルトではビルドされていないので、 --with-http_perl_module 設定パラメータで有効にする必要があります。

このモジュールは Perl バージョン 5.6.1 以上が必要です。C コンパイラは Perl のビルドに使用されるものと互換性がある必要があります。 既知の問題 このモジュールは実験的なものであり、caveat emptorが適用されます。

Perl が再構成時に変更されたモジュールを再コンパイルするためには、-Dusemultiplicity=yes または -Dusethreads=yes パラメータを指定してビルドする必要があります。また、Perl の実行時のメモリリークを少なくするために、-Dusemymalloc=no パラメータを指定してビルドする必要があります。すでにビルドされているPerlでこれらのパラメータの値を確認するには（例では好ましい値が指定されています）、実行してください。

perl -V:usemultiplicity -V:usemymalloc usemultiplicity='define'. usemymalloc='n'です。 新しい -Dusemultiplicity=yes または -Dusethreads=yes パラメータで Perl を再構築した後、すべてのバイナリ Perl モジュールも再構築する必要があることに注意してください。

再構成のたびにメインプロセスとその後のワーカープロセスのサイズが大きくなる可能性があります。メインプロセスが許容できない大きさに成長した場合、実行ファイルを変更せずにライブアップグレード手順を適用することができます。

Perl モジュールがドメイン名の解決、別のサーバへの接続、データベースへの問い合わせなど、長時間実行される操作を実行している間は、現在のワーカープロセスに割り当てられた他の要求は処理されません。したがって、ローカルファイルシステムへのアクセスなど、予測可能で実行時間が短い操作のみを実行することをお勧めします。

設定例

perl/lib/hello.pmモジュール。

記述内容

指定された場所のPerlハンドラを設定します。

Perl モジュールの追加パスを設定します。

再構成のたびにロードされるモジュールの名前を定義します。perl_require 記述内容が複数存在する可能性があります。

指定された変数のPerlハンドラをインストールします。

SSIからPerlを呼び出す Perlを呼び出すSSIコマンドは、以下のような形式になっています。

r リクエストオブジェクトメソッド r->args リクエストの引数を返します。 r->ファイル名 は、リクエストのURIに対応するファイル名を返します。 r->has_request_body(handler) は、リクエストにボディがなければ0を返します。ボディがある場合は、指定されたハンドラが設定され、1が返されます。リクエストのボディを読み込んだ後、nginx は指定されたハンドラを呼び出します。ハンドラ関数は参照で渡す必要があることに注意してください。例としては、以下のようになります。 パッケージ hello.

$r->allow_ranges

レスポンスを送信する際にバイト単位の範囲を使用できるようにします。

レスポンスを送信する際にバイト単位の範囲を使用できるようにします。

は nginx にリクエストの本文を破棄するように指示します。

$r->header_in(field)

は、指定したクライアントリクエストのヘッダフィールドの値を返します。

$r->header_only

は、 レスポンス全体をクライアントに送信するのかヘッダのみをクライアントに送信するのかを決定します。

$r->header_out(field, value)

は、指定されたレスポンスヘッダーフィールドの値を設定します。

$r->internal_redirect(uri)

は、指定された URI への内部リダイレクトを行います。実際のリダイレクトは Perl ハンドラの実行が完了した後に行われます。 バージョン 1.17.2 以降、このメソッドはエスケープされた URI を受け付け、指定された場所へのリダイレクトをサポートしています。

$r->log_error(errno, message)

は、指定したメッセージをerror_logに書き込みます。errnoが0以外の場合は、エラーコードとその説明がメッセージに追加されます。

エラーコードとその説明がメッセージに付加されます。

データをクライアントに渡します。 r->request_body は、一時ファイルに書き込まれていない場合は、クライアントリクエストボディを返します。クライアントのリクエストボディがメモリ内にあることを保証するために、そのサイズは client_max_body_size で制限し、client_body_buffer_size を使用して十分なバッファサイズを設定しなければなりません。

クライアントのリクエストボディをメモリに保存するには、そのサイズを client_max_body_size に制限し、client_body_buffer_size を使用して十分なバッファサイズを設定しなければなりません。

は、クライアント要求本文を持つファイル名を返します。処理後、そのファイルは削除されなければなりません。常にファイルにリクエストボディを書き込むには、client_body_in_file_onlyを有効にする必要があります。

リクエストボディを常にファイルに書き込むためには、client_body_in_file_onlyを有効にしておく必要があります。

はクライアントリクエストのHTTPメソッドを返します。

$r->remote_addr

クライアントのIPアドレスを返します。

はすぐにクライアントにデータを送信します。

$r->sendfile(name[, offset[, length]])

は、指定されたファイルの内容をクライアントに送信します。オプションのパラメータは、送信するデータの初期オフセットと長さを指定します。実際のデータ送信は、Perl ハンドラの処理が完了した後に行われます。

$r->send_http_header([type])

レスポンスヘッダをクライアントに送信します。オプションのtypeパラメータは、"Content-Type "応答ヘッダフィールドの値を設定します。値が空文字列の場合、"Content-Type "ヘッダフィールドは送信されません。

$r->status(code)

レスポンスコードを設定します。

は指定されたハンドラを設定し、指定された時間だけリクエストの処理を停止します。その間、nginx は他のリクエストの処理を続けます。指定された時間が経過した後、nginx はインストールされたハンドラを呼び出します。ハンドラ関数は参照で渡す必要があることに注意してください。ハンドラ間でデータを渡すには $r->variable() を使用します。ハンドラ間のデータの受け渡しには $r->variable() を使用します。 パッケージ hello.

r->unescape(text) は、"%XX" 形式でエンコードされたテキストをデコードします。 r->uri はリクエストURIを返します。 r->変数(name[, value]) は指定された変数の値を返すか設定します。変数は各リクエストに対してローカルです。

Module ngx_http_proxy_module

ngx_http_proxy_module モジュールは、リクエストを別のサーバに渡すことを可能にします。

設定例

記述内容

プロキシされたサーバへの発信接続を、オプションのポート(1.11.2)を使用して指定されたローカルIPアドレスから発信するようにします。パラメータ値には変数(1.3.12)を含めることができます。特別な値 off (1.3.12) は、以前の構成レベルから継承された proxy_bind ディレクティブの効果をキャンセルし、システムがローカル IP アドレスとポートを自動的に割り当てることを可能にします。

transparent パラメータ (1.11.0) は、プロキシサーバへの発信接続を、非ローカル IP アドレス (例えば、クライアントの実際の IP アドレス) から発信することを可能にします。

proxy_bind $remote_addr transparent;

このパラメータを動作させるためには、通常、スーパーユーザ権限で nginx ワーカープロセスを実行する必要があります。Linux では、transparent パラメータが指定されている場合、ワーカープロセスはマスタープロセスから CAP_NET_RAW 機能を継承するため、このパラメータは必須ではありません (1.13.8)。また、プロキシされたサーバからのネットワークトラフィックを傍受するために、カーネルルーティングテーブルを設定する必要があります。

プロキシされたサーバから受信したレスポンスの最初の部分を読み込むために使用するバッファのサイズを設定します。この部分には通常、小さなレスポンスヘッダが含まれています。デフォルトでは、バッファサイズは1メモリページに相当します。これはプラットフォームに応じて4Kか8Kのどちらかになります。しかし、これより小さくすることもできます。

プロキシされたサーバからのレスポンスのバッファリングを有効または無効にします。

バッファリングが有効になっている場合、nginx はプロキシされたサーバからのレスポンスをできるだけ早く受信し、proxy_buffer_size と proxy_buffers 記述内容で設定されたバッファに保存します。レスポンス全体がメモリに収まらない場合、その一部をディスク上の一時ファイルに 保存することができます。一時ファイルへの書き込みはproxy_max_temp_file_sizeとproxy_temp_file_write_size 記述内容によって制御される。

バッファリングが無効になっている場合、レスポンスは受信した直後に同期的にクライアントに渡されます。nginx が一度にサーバから受け取ることができるデータの最大サイズは proxy_buffer_size ディレクティブで設定されます。

バッファリングは "X-Accel-Buffering" レスポンスヘッダフィールドに "yes" か "no" を渡すことで有効にしたり無効にしたりすることもできます。この機能は proxy_ignore_headers ディレクティブを使って無効にすることができます。

1 つの接続に対して、プロキシされたサーバーからの応答を読み取るために使用するバッファの数とサイズを設定します。デフォルトでは、バッファサイズは1メモリページに相当します。これは、プラットフォームに応じて 4K または 8K のいずれかになります。

プロキシされたサーバからの応答のバッファリングが有効になっている場合、応答がまだ完全に読み込まれていない間、クライアントに応答を送信するためにビジー状態になるバッファの合計サイズを制限します。その間、残りのバッファはレスポンスの読み込みに使用され、必要に応じてレスポンスの一部を一時ファイルにバッファリングすることができます。デフォルトでは、サイズは proxy_buffer_size と proxy_buffers ディレクティブで設定された二つのバッファのサイズで制限されます。

キャッシングに使用する共有メモリゾーンを定義します。同じゾーンを複数の場所で使用することができます。パラメータ値には変数を含めることができます（1.7.9）。off パラメータは、前の構成レベルから継承されたキャッシングを無効にします。

期限切れのキャッシュアイテムを更新するためのバックグラウンドサブリクエストを開始し、古いキャッシュレスポンスをクライアントに返すことを許可します。更新されているときに古いキャッシュ応答を使用できるようにする必要があることに注意してください。

レスポンスがキャッシュから取得されない条件を定義します。文字列パラメータの少なくとも一つの値が空でなく "0" でない場合、レスポンスはキャッシュから取得されません。

 

キャッシュのための "HEAD "メソッドの "GET "への変換を有効にするか無効にするかを指定します。変換を無効にする場合は、キャッシュキーに$request_methodを含めるように設定する必要があります。

キャッシング用のキーを定義します。

proxy_cache_key "$host$request_uri $cookie_user"。 デフォルトでは、ディレクティブの値は

有効にすると、proxied サーバにリクエストを渡すことで proxy_cache_key ディレクティブで指定された新しいキャッシュ要素を生成するリクエストが一度に一つだけ許可されます。同じキャッシュ要素に対する他のリクエストは、キャッシュにレスポンスが現れるのを待つか、 この要素のキャッシュロックが解除されるのを、 proxy_cache_lock_timeout ディレクティブで設定された時間まで待ちます。

新しいキャッシュ要素を生成するためにプロキシされたサーバに渡された最後のリクエストが、指定された時間の間に完了しなかった場合、さらに１つのリクエストがプロキシされたサーバに渡されてもよい。

proxy_cache_lock のタイムアウトを設定します。タイムアウトした場合、リクエストはプロキシされたサーバに渡されますが、 レスポンスはキャッシュされません。

1.7.8 より前のバージョンでは、レスポンスはキャッシュされていました。

バイト範囲リクエストのオフセットをバイト単位で設定します。範囲がオフセットを超えている場合、範囲リクエストはプロキシされたサーバに渡され、レスポンスはキャッシュされません。

クライアントのリクエストメソッドがこのディレクティブにリストアップされている場合、 レスポンスはキャッシュされます。"GET" と "HEAD" メソッドは常にリストに追加されますが、明示的に指定することが推奨されます。proxy_no_cache ディレクティブも参照してください。

応答がキャッシュされるまでのリクエスト数を設定します。

キャッシュのパスなどを設定します。キャッシュデータはファイルに格納されます。キャッシュ内のファイル名は、キャッシュキーに MD5 関数を適用した結果です。levels パラメータは、キャッシュの階層レベルを定義します。例えば、以下の設定では

proxy_cache_path /data/nginx/cache levels=1:2 keys_zone=one:10m.

キャッシュ内のファイル名は次のようになります。

/data/nginx/cache/c/29/b7f54b2df7773722d382f4809d65029c

キャッシュされたレスポンスは最初に一時ファイルに書き込まれ、その後ファイル名が変更されます。バージョン 0.8.9 以降、一時ファイルとキャッシュは異なるファイルシステムに置くことができます。しかし、この場合、ファイルは安価なリネーム操作の代わりに 2 つのファイルシステムにコピーされることに注意してください。したがって、どのような場所でも、キャッシュと一時ファイルを保持するディレクトリの両方を同じファイルシステムに置くことをお勧めします。一時ファイルを格納するディレクトリは use_temp_path パラメータ(1.7.10)に基づいて設定される。このパラメータが省略された場合、または on に設定された場合は、指定された場所の proxy_temp_path ディレクティブで設定されたディレクトリが使用されます。値がoffに設定されている場合、一時ファイルは直接キャッシュディレクトリに置かれます。

さらに、すべてのアクティブな鍵とデータに関する情報は共有メモリゾーンに保存され、その名前とサイズは keys_zoneパラメータで設定される。1メガバイトのゾーンには、約8,000個の鍵を格納することができる。

商用サブスクリプションの一部として、共有メモリゾーンには拡張キャッシュ情報も格納されるため、 同じ数の鍵に対してより大きなゾーンサイズを指定する必要がある。例えば、1メガバイトのゾーンには約4,000個の鍵を格納することができます。 inactiveパラメータで指定された時間内にアクセスされなかったキャッシュデータは、その鮮度に関係なくキャッシュから削除されます。デフォルトでは、inactiveは10分に設定されている。

特別な「キャッシュマネージャ」プロセスは、max_sizeパラメータで設定された最大キャッシュサイズを監視します。このサイズを超えると、最近使用されたデータを削除します。データは manager_files、manager_threshold、manager_sleep パラメータ (1.11.5) で設定された繰り返しで削除されます。1回のイテレーションの間に削除されるのは、 manager_filesの項目を超えてはなりません (デフォルトでは100)。1回の反復の期間は、 manager_thresholdパラメータによって制限されます (デフォルトでは、200ミリ秒)。反復の間には、 manager_sleep パラメータで設定された一時停止が行われます (デフォルトでは 50 ミリ秒)。

起動から1分後に特別な「キャッシュローダー」プロセスが起動します。ファイルシステムに保存されている以前にキャッシュされたデータの情報をキャッシュゾーンにロードします。読み込みは反復して行われます。1 回の繰り返しの間に loader_files の項目がロードされるのはそれ以上ではありません (デフォルトでは 100)。さらに、1 回の反復の期間は loader_threshold パラメータによって制限されます（デフォルトでは 200 ミリ秒）。反復の間には、loader_sleepパラメータ（デフォルトでは50ミリ秒）で設定された一時停止が行われます。

さらに、以下のパラメータは商用サブスクリプションの一部として利用できます。

パージオン

ワイルドカードキーに一致するキャッシュエントリをキャッシュパージ機能 (1.7.12) でディスクから削除するかどうかを指定します。このパラメータを on (デフォルトは off) に設定すると、すべてのキャッシュエントリを恒久的に反復処理し、 ワイルドカードキーにマッチするエントリを削除する "cache purger" プロセスが有効になります。

purger_files=数

1 回の繰り返しでスキャンするアイテムの数を設定します (1.7.12)。デフォルトでは、purger_files は 10 に設定されています。 purger_threshold=number 1 回の反復の持続時間を設定します (1.7.12)。デフォルトでは、purger_threshold は 50 ミリ秒に設定されています。

purger_sleep=数

反復の間の一時停止を設定します (1.7.12)。デフォルトでは、purger_sleep は 50 ミリ秒に設定されています。 バージョン 1.7.3、1.7.7、および 1.11.10 では、キャッシュヘッダの形式が変更されました。新しいバージョンの nginx にアップグレードすると、以前にキャッシュされたレスポンスは無効とみなされます。

リクエストがキャッシュパージリクエストとみなされる条件を定義します。文字列パラメータの少なくとも一つの値が空ではなく、"0" に等しくない場合、対応するキャッシュキーを持つキャッシュエントリが削除されます。操作が成功した結果は 204 (No Content) 応答を返すことで示されます。

パージリクエストのキャッシュキーがアスタリスク ("*") で終わる場合、ワイルドカードキーにマッチするすべてのキャッシュエントリがキャッシュから削除されます。しかし、これらのエントリは非アクティブ状態で削除されるか、キャッシュパージ機能 (1.7.12) によって処理されるか、クライアントがアクセスしようとするまでディスク上に残ります。

設定例:

この機能は、当社の商用サブスクリプションの一部としてご利用いただけます。

If-Modified-Since" および "If-None-Match" ヘッダーフィールドを持つ条件付きリクエストを使用して、期限切れのキャッシュアイテムの再バリデーションを有効にします。

プロキシされたサーバとの通信中に、どのような場合に古いキャッシュされた応答が 使えるかを決定します。このディレクティブのパラメータは proxy_next_upstream ディレクティブのパラメータと一致します。

error パラメータはまた、リクエストを処理するプロキシサーバが選択できない場合に、 古いキャッシュされた応答を使うことを許可します。

さらに、updateパラメータは、現在更新中であれば、古いキャッシュされた 応答を使うことを許可する。これにより、キャッシュされたデータを更新する際に、 プロキシされたサーバへのアクセス数を最小限に抑えることができます。

スタールキャッシュされた応答を使用することは、応答がスタールになってから指定された秒数だけ応答ヘッダで直接有効にすることもできます (1.11.10)。これはディレクティブのパラメータを使うよりも優先度が低いです。

Cache-Control」ヘッダフィールドの「stale-while-revalidate」拡張は、現在更新中の場合、古いキャッシュされた 応答を使用することを許可します。 Cache-Control" ヘッダ・フィールドの "stale-if-error" 拡張子は、エラーが発生した場合に古いキャッシュ・レスポンスの使用を許可します。 新しいキャッシュ要素を生成する際に、プロキシされたサーバへのアクセス数を 最小限にするために、proxy_cache_lock ディレクティブを使用することができます。

異なるレスポンスコードのキャッシュ時間を設定します。例えば、次のような記述内容

コード 200 と 302 の応答に対しては 10 分間、コード 404 の応答に対しては 1 分間のキャッシング時間を設定します。

キャッシング時間のみを指定した場合

proxy_cache_valid 5m;

の場合、200、301、および302応答のみがキャッシュされます。

さらに、any パラメータを指定することで、任意のレスポンスをキャッシュすることができます。

キャッシングのパラメータはレスポンスヘッダで直接設定することもできます。これはディレクティブを使ったキャッシング時間の設定よりも優先度が高くなります。

X-Accel-Expires」ヘッダーフィールドは、応答のキャッシング時間を秒単位で設定する。ゼロの値は応答のキャッシングを無効にする。値が@接頭辞で始まる場合、Epochからの絶対時間を秒単位で設定します。

ヘッダに "X-Accel-Expires "フィールドが含まれていない場合、キャッシングのパラメータは、ヘッダフィールド "Expires "または "Cache-Control "に設定されてもよい。 ヘッダに「Set-Cookie」フィールドが含まれている場合、そのような応答はキャッシュされません。 ヘッダーが特別な値「*」を持つ「Vary」フィールドを含む場合、そのような応答はキャッシュされない(1.7.7)。ヘッダーに別の値を持つ「Vary」フィールドが含まれている場合、そのような応答は、対応する要求ヘッダー フィールドを考慮してキャッシュされる(1.7.7)。 これらの応答ヘッダフィールドの処理は、proxy_ignore_headers ディレクティブを使って無効にすることができます。

プロキシされたサーバとの接続を確立するためのタイムアウトを定義します。このタイムアウトは通常 75 秒を超えることはできないことに注意してください。

プロキシされたサーバのレスポンスの "Set-Cookie "ヘッダフィールドの domain 属性に変更するテキストを設定します。プロキシされたサーバが "Set-Cookie" ヘッダフィールドに "domain=localhost" という属性をつけて返してきたとします。ディレクティブは

proxy_cookie_domain localhost example.org.

はこの属性を "domain=example.org" に書き換えます。

ドメインと置換文字列の先頭にドットがあり、ドメイン属性は無視されます。マッチングは大文字小文字を区別しません。

ドメインと置換文字列は変数を含むことができます。

proxy_cookie_domain www.$host $host.

ディレクティブは正規表現を使って指定することもできます。この場合、 domain は "~" 記号で始まる必要があります。正規表現には、名前付きキャプチャと位置キャプチャを含めることができ、置換文字列にはそれらを参照することができます。

proxy_cookie_domain ~.

いくつかのproxy_cookie_domain 記述内容があるかもしれません。

proxy_cookie_domain localhost example.org.

proxy_cookie_domain ~. offパラメータは、現在のレベルのすべてのproxy_cookie_domain 記述内容の効果をキャンセルします。

proxy_cookie_domain off. proxy_cookie_domain off; proxy_cookie_domain localhost example.org. proxy_cookie_domain www.example.org example.org。

プロキシされたサーバのレスポンスの "Set-Cookie" ヘッダフィールドの path 属性を変更するテキストを設定します。プロキシされたサーバが "Set-Cookie" ヘッダフィールドに "path=/two/some/uri/" という属性をつけて返してきたとします。ディレクティブは

パスと置換文字列は変数を含むことができます。

proxy_cookie_path $uri /some$uri. このディレクティブは正規表現を使って指定することもできます。この場合、path は大文字小文字を区別しないマッチの場合は "~" シンボルから始まるか、大文字小文字を区別しないマッチの場合は "~*" シンボルから始まるかのどちらかでなければなりません。正規表現には、名前付きキャプチャと位置指定キャプチャを含めることができ、置換はそれらを参照することができます。

off パラメータは、現在のレベルでのすべての proxy_cookie_path 記述内容の効果をキャンセルします。

これらの応答の「Accept-Ranges」フィールドに関係なく、プロキシされたサーバーからのキャッシュされた応答とキャッシュされていない応答の両方のバイト範囲のサポートを有効にする。

proxy_hide_header と proxy_set_header 記述内容で使用するハッシュテーブルのバケットサイズを設定します。ハッシュテーブルの設定の詳細は別のドキュメントにあります。

proxy_hide_header と proxy_set_header 記述内容で使用するハッシュテーブルの最大サイズを設定します。ハッシュテーブルの設定の詳細は別のドキュメントにあります。

デフォルトでは、nginx はプロキシされたサーバのレスポンスからクライアントに "Date", "Server", "X-Pad", "X-Accel-..." というヘッダフィールドを渡さないようになっています。proxy_hide_header ディレクティブは、渡されない追加のフィールドを設定します。逆に、フィールドを渡すことを許可する必要がある場合は、 proxy_pass_header ディレクティブを使うことができます。

プロキシするHTTPプロトコルのバージョンを設定します。デフォルトでは、バージョン 1.0 が使用されます。keepalive 接続や NTLM 認証で使用する場合は、バージョン 1.1 を推奨します。

クライアントが応答を待たずに接続を閉じた場合に、プロキシされたサーバとの接続を閉じるべきかどうかを決定します。

プロキシされたサーバーからの特定の応答ヘッダーフィールドの処理を無効にします。以下のフィールドは無視することができます。"X-Accel-Redirect」、「X-Accel-Expires」、「X-Accel-Limit-Rate」(1.1.6)、「X-Accel-Buffering」(1.1.6)、「X-Accel-Charset」(1.1.6)、「Expires」、「Cache-Control」、「Set-Cookie」(0.8.44)、および「Vary」(1.7.7)。

無効にしていない場合、これらのヘッダーフィールドの処理は以下のような効果があります。

"X-Accel-Expires"、"Expires"、"Cache-Control"、"Set-Cookie"、および "Vary "は、レスポンスキャッシングのパラメータを設定する。 "X-Accel-Redirect" は、指定された URI への内部リダイレクトを実行します。 "X-Accel-Limit-Rate」は、クライアントへの応答送信のレート制限を設定します。 "X-Accel-Buffering」は、応答のバッファリングを有効または無効にします。 "X-Accel-Charset」は、レスポンスの希望する文字セットを設定します。

300 以上のコードを持つプロキシされた応答をクライアントに渡すか、 傍受して nginx にリダイレクトして error_page ディレクティブで処理するかを決定します。

プロキシされたサーバーからの応答の読み取り速度を制限します。レートは 1 秒あたりのバイト数で指定します。ゼロの値はレートの制限を無効にします。制限はリクエストごとに設定されるため、nginx が同時に 2 つの接続をプロキシドサーバーに開いた場合、全体のレートは指定された制限の 2 倍になります。この制限は、プロキシされたサーバからの応答のバッファリングが有効な場合にのみ機能します。

プロキシされたサーバからの応答のバッファリングが有効で、応答全体が proxy_buffer_size と proxy_buffers ディレクティブで設定されたバッファに収まらない場合、応答の一部を一時ファイルに保存することができます。このディレクティブは一時ファイルの最大サイズを設定します。一度に一時ファイルに書き込まれるデータのサイズは proxy_temp_file_write_size ディレクティブで設定されます。

ゼロの値は、一時ファイルに対する応答のバッファリングを無効にします。

この制限は、キャッシュまたはディスクに保存される応答には適用されません。

クライアント要求からのメソッドではなく、プロキシされたサーバーに転送される要求で使用する HTTP メソッドを指定します。パラメータ値には変数を含めることができます(1.11.6)。

どのような場合にリクエストを次のサーバーに渡すかを指定します。

error サーバーとの接続を確立しているとき、リクエストをサーバーに渡しているとき、またはレスポンスヘッダを読んでいるときにエラーが発生しました。 timeout サーバーとの接続を確立している間、リクエストをサーバーに渡している間、または応答ヘッダーを読んでいる間にタイムアウトが発生しました。 invalid_header サーバが空か無効な応答を返しました。 http_500 サーバがコード500のレスポンスを返しました。 http_502 サーバはコード 502 のレスポンスを返しました。 http_503 はコード503のレスポンスを返しました。 http_504 はコード504のレスポンスを返しました。 http_403 サーバはコード403で応答を返しました。 http_404 サーバーはコード 404 で応答を返しました。 http_429 サーバーはコード429 (1.11.13)の応答を返しました。 non_idempotent 通常、リクエストがアップストリームサーバ (1.9.13) に送られた場合、非親和的なメソッド (POST, LOCK, PATCH) を持つリクエストは次のサーバに渡されません。 off は次のサーバへのリクエストの受け渡しを無効にします。 次のサーバへのリクエストの受け渡しは、まだクライアントに何も送信されていない場合にのみ可能であることを覚えておくべきです。つまり、レスポンスの転送中にエラーやタイムアウトが発生した場合、 これを修正することは不可能です。

このディレクティブでは、サーバとの通信の試みが失敗したとみなされるものも定義しています。error, timeout, invalid_header の場合は、たとえディレクティブで指定されていなくても、 常に失敗したとみなされます。http_500, http_502, http_503, http_504, http_429 の場合は、ディレクティブで指定されている場合のみ、 失敗したとみなされます。http_403 と http_404 の場合は、失敗したとみなされることはありません。

次のサーバへのリクエストの受け渡しは、試行回数や時間によって制限されます。

リクエストを次のサーバーに渡すことができる時間を制限します。0 の値はこの制限をオフにします。

次のサーバーにリクエストを渡すための試行回数を制限します。0 の値はこの制限をオフにします。

レスポンスがキャッシュに保存されない条件を定義します。文字列パラメータの少なくとも一つの値が空でなく、かつ "0" でない場合、レスポンスは保存されません。

proxy_cache_bypass ディレクティブと一緒に使うことができます。

プロキシされたサーバのプロトコルとアドレス、およびロケーションがマッピングされるべきオプションのURIを設定します。プロトコルとしては、"http "または "https "を指定することができる。アドレスは、ドメイン名またはIPアドレス、オプションでポートを指定することができます。

proxy_pass http://localhost:8000/uri/。 または、"unix" の後にコロンで囲んだ UNIX ドメインのソケットパスを指定します。

proxy_pass http://unix:/tmp/backend.socket:/uri/。 ドメイン名が複数のアドレスに解決された場合、そのすべてのアドレスが ラウンドロビン方式で使用されます。また、サーバグループとしてアドレスを指定することもできます。

パラメータ値には変数を含めることができます。この場合、ドメイン名としてアドレスが指定された場合、記述されたサーバグループの中から検索し、見つからなければリゾルバを用いて決定する。

リクエストURIは以下のようにしてサーバに渡されます。

URIでproxy_pass指示文が指定されている場合，リクエストをサーバに渡す際に，その場所にマッチする正規化されたリクエストURIの一部が指示文で指定されたURIに置き換えられます．

バージョン1.1.12以前では、proxy_passがURIなしで指定された場合、 場合によっては変更されたURIの代わりに元のリクエストURIが渡されるかも しれない。 場合によっては、置き換えられるリクエストURIの一部がわからないことがある。

locationが正規表現を使用して指定された場合や、名前のついたlocationの中でも 指定された場合など、置換されるリクエストURIの一部を決定できない 場合がある。 このような場合、proxy_passはURIなしで指定されるべきである。

プロキシされた場所の内部でrewriteディレクティブを使ってURIを変更した場合、 同じ設定でリクエストを処理することになります(break)。

この場合、ディレクティブで指定されたURIは無視され、変更された完全なリクエストURIが サーバに渡されます。

proxy_pass で変数を使う場合。

この場合、URI が指定されていれば、元のリクエスト URI を置き換えてそのままサーバに渡されます。 WebSocket プロキシは特別な設定が必要で、バージョン 1.3.13 以降でサポートされています。

そうでなければ無効なヘッダフィールドをプロキシされたサーバからクライアントに渡すことを許可します。

元のリクエストボディがプロキシされたサーバーに渡されるかどうかを示す。

proxy_set_header と proxy_pass_request_headers 記述内容も参照のこと。

オリジナルのリクエストのヘッダーフィールドがプロキシされたサーバーに 渡されるかどうかを示す。

proxy_set_header と proxy_pass_request_body 記述内容も参照してください。

プロキシされたサーバから応答を読み込む際のタイムアウトを定義します。タイムアウトは、2 つの連続した読み込み操作の間にのみ設定され、応答全体の送信に対しては設定されません。プロキシされたサーバがこの時間内に何も送信しなかった場合、接続は閉じられます。

プロキシドサーバのレスポンスの "Location" および "Refresh" ヘッダフィールドで変更するテキストを設定します。プロキシされたサーバが "Location: http://localhost:8000/two/some/uri/" というヘッダフィールドを返してきたとします。このような場合には

proxy_redirect http://localhost:8000/two/ http://frontend/one/。 はこの文字列を "Location: http://frontend/one/some/uri/" に書き換えます。

置換文字列ではサーバ名を省略することができます。

proxy_redirect http://localhost:8000/two/ /. の場合、プライマリサーバの名前とポート(80と異なる場合)が挿入されます。

default パラメータで指定されたデフォルトの置換は、 location と proxy_pass 記述内容のパラメータを使用します。したがって、以下の二つの設定は同等です。

変数を使ってproxy_passが指定されている場合、デフォルトのパラメータは許可されません。

置換文字列には変数を含めることができます。

proxy_redirect http://localhost:8000/ http://$host:$server_port/. リダイレクトには (1.1.11) 変数を含めることもできます。

proxy_redirect http://$proxy_host:8000/ /. このディレクティブは正規表現を使って(1.1.11)指定することができます。この場合、リダイレクトは大文字小文字を区別しないマッチの場合は"~"記号で始まるか、大文字小文字を区別しないマッチの場合は"~*"記号で始まる必要があります。正規表現には名前付きキャプチャと位置情報キャプチャを含めることができ、置換はそれらを参照することができます。

proxy_redirect 記述内容はいくつかあるかもしれません。

off パラメータは、現在のレベルでのすべての proxy_redirect 記述内容の効果をキャンセルする。

このディレクティブを使うことで、プロキシされたサーバが発行する相対リダイレクトに ホスト名を追加することも可能です。

proxy_redirect / /;

Enables or disables buffering of a client request body.

バッファリングが有効な場合、リクエストをプロキシされたサーバーに送る前に、 クライアントからリクエストボディ全体が読み込まれます。

バッファリングが無効になっている場合、リクエストボディは受信後すぐにプロキシ先のサーバに送信されます。この場合、nginx が既にリクエストボディの送信を開始している場合、リクエストを次のサーバに渡すことはできません。

HTTP/1.1 のチャンク化された転送エンコーディングを使用して元のリクエストボディを送信する場合、HTTP/1.1 がプロキシ化を有効にしていない限り、ディレクティブの値に関係なくリクエストボディはバッファリングされます。

このディレクティブが 0 以外の値に設定されている場合、 nginx は kqueue メソッドの NOTE_LOWAT フラグか SO_SNDLOWAT ソケットオプションを指定したサイズで使用することで、 プロキシサーバへの送信接続での送信操作の回数を最小化しようとします。

このディレクティブは Linux, Solaris, Windows では無視されます。

プロキシされたサーバにリクエストを送信するためのタイムアウトを設定します。タイムアウトは 2 つの連続した書き込み操作の間にのみ設定され、リクエスト全体の送信には設定されません。プロキシされたサーバがこの時間内に何も受信しなかった場合、接続は閉じられます。

プロキシされたサーバに渡されるリクエストボディを再定義することができます。値には、テキスト、変数、およびそれらの組み合わせを含めることができます。

プロキシされたサーバーに渡されたリクエストヘッダーにフィールドを再定義したり追加したりすることができます。値には、テキスト、変数、それらの組み合わせを含めることができます。これらのディレクティブは、現在のレベルで定義されている proxy_set_header ディレクティブがない場合にのみ、前のレベルから継承される。デフォルトでは、2つのフィールドのみが再定義される。

proxy_set_header ホスト $proxy_host. proxy_set_header 接続を終了します。 キャッシングが有効な場合、元のリクエストのヘッダフィールド "If-Modified-Since", "If-Unmodified-Since", "If-None-Match", "If-Match", "Range", "If-Range" はプロキシされたサーバには渡されません。

変更されていない "Host "リクエストヘッダフィールドは、以下のように渡すことができます。

proxy_set_header Host $http_host;

しかし、このフィールドがクライアントのリクエストヘッダに存在しない場合は、 何も渡されません。その値は "Host" リクエストヘッダフィールドにあるサーバ名と等しく、もしこのフィールドが存在しない場合はプライマリサーバ名になります。

proxy_set_header Host $host;

また、サーバ名は、プロキシされたサーバのポートと一緒に渡すことができます。

proxy_set_header Host $host:$proxy_port; ヘッダフィールドの値が空文字列の場合、このフィールドはプロキシされたサーバには渡されません。

プロキシされたサーバーへの発信接続の「TCP keepalive」動作を設定します。デフォルトでは、オペレーティングシステムの設定がソケットに対して有効になっています。ディレクティブの値が "on" に設定されている場合、SO_KEEPALIVE ソケットオプションがソケットに対して有効になります。

プロキシされた HTTPS サーバへの認証に使用される PEM 形式の証明書を含むファイルを指定します。

プロキシされた HTTPS サーバへの認証に使用される PEM 形式の秘密鍵を含むファイルを指定します。

ファイル (1.7.9) の代わりに engine:name:id を指定することもでき、OpenSSL エンジン名から指定された id を持つ秘密鍵をロードします。

プロキシされた HTTPS サーバへのリクエストに対して有効な暗号化方式を指定します。暗号化方式は、OpenSSL ライブラリが理解できる形式で指定されます。

完全なリストは "openssl ciphers" コマンドを使用して表示することができます。

プロキシされた HTTPS サーバの証明書を検証するために使用される PEM 形式の失効した証明書 (CRL) を含むファイルを指定します。

プロキシ先の HTTPS サーバとの接続を確立する際に、プロキシ先の HTTPS サーバの証明書を検証し、SNI に渡すために使用されるサーバ名をオーバーライドすることができます。

デフォルトでは、proxy_pass URL のホスト部分が使用されます。

秘密鍵のパスフレーズを含むファイルを指定し、各パスフレーズを別の行で指定します。パスフレーズは、鍵の読み込み時に順番に試行されます。

プロキシされた HTTPS サーバへの要求に対して指定されたプロトコルを有効にします。

プロキシされた HTTPS サーバとの接続を確立する際に、TLS Server Name Indication extension (SNI, RFC 6066) を通じてサーバ名を渡すことを有効または無効にします。

プロキシされたサーバで作業する際にSSLセッションを再利用できるかどうかを決定します。ログに「SSL3_GET_FINISHED:digest check failed」というエラーが表示された場合は、セッションの再利用を無効にしてみてください。

プロキシされた HTTPS サーバの証明書を検証するために使用される PEM 形式の信頼された CA 証明書を含むファイルを指定します。

プロキシされた HTTPS サーバ証明書の検証を有効または無効にします。

プロキシされた HTTPS サーバ証明書チェーンの検証深度を設定します。

ファイルのディスクへの保存を有効にします。on パラメータを指定すると、記述内容エイリアスまたはルートに対応するパスでファイルを保存します。off パラメータを指定すると、ファイルの保存を無効にします。また，ファイル名は変数付きの文字列を用いて明示的に設定することができます．

proxy_store /data/www$original_uri;

ファイルの修正時間は、受信した "Last-Modified "応答ヘッダフィールドに応じて設定される。レスポンスは最初に一時ファイルに書き込まれ、その後ファイル名が変更されます。バージョン0.8.9からは、一時ファイルと永続ストアを別のファイルシステムに置くことができます。しかし、この場合、ファイルは安価なリネーム操作ではなく、2つのファイルシステムにまたがってコピーされることに注意してください。したがって、任意の場所では、保存されたファイルと proxy_temp_path ディレクティブで設定された一時ファイルを保持するディレクトリの両方を同じファイルシステムに置くことが推奨されます。

このディレクティブは、例えば、静的で変更不可能なファイルのローカルコピーを作成するために使うことができます。

or like this:

新しく作成されたファイルやディレクトリのアクセス権限を設定します。

proxy_store_access user:rw group:rw all:r. グループまたはすべてのアクセス権限が指定されている場合は、ユーザ権限を省略することができます。

proxy_store_access group:rw all:r;

プロキシされたサーバからの応答の一時ファイルへのバッファリングが有効な場合に、 一度に一時ファイルに書き込まれるデータのサイズを制限します。デフォルトでは、サイズはproxy_buffer_sizeとproxy_buffers 記述内容によって設定された2つのバッファによって制限される。一時ファイルの最大サイズは proxy_max_temp_file_size ディレクティブで設定されます。

プロキシされたサーバから受信したデータを一時ファイルとして格納するためのディレクトリを定義します。指定したディレクトリの下には、3階層までのサブディレクトリ階層を使用することができます。例えば、次のような構成の場合

proxy_temp_path /spool/nginx/proxy_temp 1 2.

一時ファイルは次のようになります。

/spool/nginx/proxy_temp/7/45/00000123457

proxy_cache_path ディレクティブの use_temp_path パラメータも参照してください。

埋め込み変数 ngx_http_proxy_module モジュールは、proxy_set_header ディレクティブを使用してヘッダを作成するために使用できる埋め込み変数をサポートしています。

プロキシホスト proxy_pass ディレクティブで指定されたプロキシサーバの名前とポート。 プロキシポート proxy_pass ディレクティブで指定されたプロキシサーバのポート、 あるいはプロトコルのデフォルトポート。 のポート、またはプロトコルのデフォルトポート。 X-Forwarded-For" クライアントリクエストヘッダフィールドに $remote_addr 変数をカンマで区切って追加したものです。X-Forwarded-For" フィールドがクライアントリクエストヘッダに存在しない場合、 $proxy_add_x_forwarded_for 変数は $remote_addr 変数と等しくなります。

Module ngx_http_random_index_module

ngx_http_random_index_module モジュールは、スラッシュ文字 ('/') で終わるリクエストを処理し、 ディレクトリ内のランダムなファイルを選んでインデックスファイルとして使用します。このモジュールは ngx_http_index_module モジュールよりも前に処理されます。

このモジュールはデフォルトではビルドされていないので、 --with-http_random_index_module 設定パラメータで有効にする必要があります。

設定例

記述内容

周囲の場所でのモジュール処理を有効または無効にします。

Module ngx_http_realip_module

ngx_http_realip_module は、クライアントのアドレスとオプションのポートを、指定されたヘッダフィールドで送信されるものに変更するために使用します。

このモジュールはデフォルトではビルドされていないので、 --with-http_realip_module 設定パラメータで有効にする必要があります。

設定例

記述内容

正しい置換アドレスを送信することが知られている信頼されたアドレスを定義します。特別な値 unix: が指定された場合、すべての UNIX ドメインソケットが信頼されます。信頼されるアドレスは、ホスト名 (1.13.1) を使用して指定することもできます。

IPv6 アドレスはバージョン 1.3.0 および 1.2.1 からサポートされています。

クライアントアドレスを置き換えるために使用されるリクエストヘッダーフィールドを定義します。

オプションのポートを含むリクエストヘッダーフィールドの値は、クライアントポート(1.11.0)を 置き換えるためにも使用される。アドレスとポートはRFC 3986に従って指定しなければならない。

proxy_protocol パラメータ (1.5.12) は、クライアントアドレスを PROXY プロトコルヘッダのものに変更します。PROXY プロトコルは listen ディレクティブで proxy_protocol パラメータを設定することで事前に有効にしておく必要があります。

This directive appeared in versions 1.3.0 and 1.2.1.

再帰検索が無効な場合、信頼されたアドレスの一つにマッチする元のクライアントアドレスは、 real_ip_header ディレクティブで定義されたリクエストヘッダフィールドで送られてきた最後のアドレスで置き換えられます。再帰検索が有効な場合、信頼されたアドレスの一つにマッチする元のクライアントアドレスは、 リクエストヘッダフィールドで送られた最後の非信頼されたアドレスで置き換えられます。

Embedded Variables

$realip_remote_addr は元のクライアントアドレス (1.9.7) を保持します。 $realip_remote_port 元のクライアントポート (1.11.0) を保持します。

Module ngx_http_referer_module

ngx_http_referer_module モジュールは、"Refererer" ヘッダフィールドの値が無効なリクエストに対して サイトへのアクセスをブロックするために使用します。適切な "Refererer" フィールドの値を持つリクエストを作成することは非常に簡単なので、このモジュールの目的はこのようなリクエストを徹底的にブロックすることではなく、通常のブラウザから送られてくる大量のリクエストをブロックすることです。また、通常のブラウザは有効なリクエストであっても "Refererer" フィールドを送らないかもしれないことを考慮に入れるべきである。

設定例

記述内容

このディレクティブはバージョン 1.0.5 で登場しました。

有効な参照元ハッシュテーブルのバケットサイズを設定します。ハッシュテーブルの設定の詳細は別のドキュメントにあります。

有効な参照元ハッシュテーブルの最大サイズを設定します。ハッシュテーブルの設定の詳細については、別のドキュメントを参照してください。

埋め込まれた $invalid_referer 変数が空の文字列に設定されるようになる "Refererer" リクエストヘッダーフィールドの値を指定します。それ以外の場合は、変数は "1 "に設定されます。一致するかどうかの検索は、大文字小文字を区別しません。

パラメータは以下の通りです。

none リクエストヘッダに "Refererer" フィールドがありません。

blocked Referer」フィールドはリクエストヘッダーに存在するが、その値はファイアウォールやプロキシサーバーによって削除されている; そのような値は「http://」や「https://」で始まらない文字列である。

server_names Referer」リクエストヘッダフィールドには、サーバ名のいずれかが含まれています。

arbitrary string はサーバ名とオプションのURI接頭辞を定義します。サーバ名は、先頭または末尾に「*」を付けることができる。検査中は、「Refererer」フィールドのサーバのポートは無視される。

regular expression の場合、最初の記号は"~"でなければなりません。式は、"http://" または "https://" の後に始まるテキストと照合されることに注意してください。

Example:

Embedded Variables $invalid_referer Empty string, if the “Referer” request header field value is considered valid, otherwise “1”.

Module ngx_http_rewrite_module

ngx_http_rewrite_moduleモジュールは、PCRE正規表現を使用したリクエストURIの変更、リダイレクトを返す、条件付きで設定を選択するために使用されます。

break, if, return, rewrite, set 記述内容は以下の順番で処理されます。

サーバレベルで指定された本モジュールの記述内容を順次実行します。 を繰り返し実行します。 繰り返し：リクエスト URI を元に場所を検索する。 見つかった場所の内部で指定された本モジュールの記述内容を順次実行する。 ループはリクエストURIが書き換えられた場合には10回以内に繰り返し行われる。

記述内容

ngx_http_rewrite_module 記述内容 現在のセットの処理を停止します。

その場所の中でディレクティブが指定された場合は、その場所でリクエストの処理を継続します。

Example:

指定された条件を評価します。true の場合、中括弧内のモジュール記述内容が実行され、 リクエストには if ディレクティブ内の設定が割り当てられます。if 記述内容の中の設定は前の設定レベルから継承されます。

条件は以下のいずれかです。

変数の値が空の文字列か "0 "の場合はfalseです。 バージョン1.0.1以前では、"0 "で始まる文字列はすべて偽の値とみなされていました。 バージョン1.0.1以前では、"0 "で始まる文字列は偽値とみなされていましたが、バージョン1.0.1以前では、"0 "で始まる文字列は偽値とみなされていました。 (大文字小文字を区別するマッチングの場合) "~" と "~" を使用した正規表現に対する変数のマッチング。(大文字小文字を区別しないマッチングのための) オペレータを使用することができます。正規表現は、$1～$9変数で後で再利用できるようにするためのキャプチャを含むことができます。負の演算子 "!~" および "!~" も利用できます。正規表現に "}" または ";" 文字が含まれている場合は、式全体を一重引用符または二重引用符で囲む必要があります。 演算子 "-f" および "!-f" でファイルの存在をチェックすることができます。 d」および「!-d」演算子でディレクトリの存在をチェックする。 e」および「!-e」演算子による、ファイル、ディレクトリ、またはシンボリックリンクの存在のチェック。 x」および「!-x」演算子による実行可能ファイルのチェック。

Examples:

A value of the $invalid_referer embedded variable is set by the valid_referers directive.

処理を停止し、指定されたコードをクライアントに返します。非標準コード444は、応答ヘッダを送信せずに接続を閉じる。

バージョン 0.8.42 以降、リダイレクト URL (コード 301、302、303、307、308) またはレスポンス本文 (その他のコード) のいずれかを指定することができます。応答本文とリダイレクトURLは変数を含むことができます。この場合、完全なリダイレクト URL はリクエストスキーム ($scheme) と server_name_in_redirect および port_in_redirect ディレクティブに従って形成されます。

また、唯一のパラメータとして、コード302で一時的にリダイレクトするためのURLを指定することができます。そのようなパラメータは、"http://"、"https://"、または"$scheme "の文字列で始まるべきである。URL は変数を含むことができます。

バージョン0.7.51以前では、204、400、402 - 406、408、410、411、413、416、および500 - 504のコードのみが返されていました。 コード307はバージョン1.1.16と1.0.13まではリダイレクトとして扱われませんでした。 コード 308 はバージョン 1.13.0 まではリダイレクトとして扱われませんでした。 error_page ディレクティブも参照してください。

指定された正規表現がリクエストURIと一致した場合、置換文字列で指定された通りにURIが変更されます。記述内容の書き換えは，設定ファイルに出現した順に順次実行される．記述内容の更なる処理をフラグを用いて終了させることができます。置換文字列が "http://", "https://", "$scheme "で始まる場合は処理を停止し、リダイレクトをクライアントに返す。

An optional flag parameter can be one of:

last は、ngx_http_rewrite_module 記述内容の現在のセットの処理を停止し、変更されたURIに一致する新しい場所の検索を開始します。 break は、break ディレクティブと同様に ngx_http_rewrite_module 記述内容の現在のセットの処理を停止します。 redirect 置換文字列が "http://"、"https://"、"$scheme" で始まらない場合に使用されます。 permanent は301コードのパーマネントリダイレクトを返します。 完全なリダイレクト URL は、リクエストスキーム ($scheme) と server_name_in_redirect および port_in_redirect 記述内容に従って形成されます。

Example:

しかし、これらのディレクティブが "/download/" の中に置かれている場合、最後のフラグは break で置き換える必要があり、そうしないと nginx は 10 サイクルして 500 エラーを返します。

置換文字列が新しいリクエスト引数を含む場合、前のリクエスト引数はそれらの後に追加されます。これが望ましくない場合は、置換文字列の最後にクエスチョンマークをつけることで、例えば、それらの追加を避けることができます。

正規表現に"}"や"; "が含まれている場合は、式全体を一重引用符または二重引用符で囲む必要があります。

ngx_http_rewrite_module モジュールの記述内容処理結果を通知レベルの error_log に記録するか否かを設定します。

指定した変数に値を設定します。値には、テキスト、変数、およびそれらの組み合わせを含めることができます。

初期化されていない変数に関する警告をログに記録するかどうかを制御します。

内部実装 ngx_http_rewrite_module モジュールの記述内容は、設定段階でリクエスト処理時に解釈される内部命令にコンパイルされます。インタプリタは単純な仮想スタックマシンです。

For example, the 記述内容

は、これらの説明書に翻訳されます。

上記の limit_rate ディレクティブは ngx_http_rewrite_module モジュールとは無関係なので指示はありません。if ブロック用に別の設定を作成します。条件が真であれば、リクエストには limit_rate が 10k に等しいこの設定が割り当てられます。

The directive

rewrite ^/(download/.)/media/(.)..*$ /$1/mp3/$2.mp3 break; は、正規表現の最初のスラッシュを括弧の中に入れれば、1命令で小さくすることができます。

rewrite ^(/download/.)/media/(.)..*$ $1/mp3/$2.mp3 break; すると、対応する指示は次のようになります。

正規表現一致

Module ngx_http_scgi_module

ngx_http_scgi_module モジュールは、リクエストを SCGI サーバに渡すことを可能にします。

設定例

記述内容

オプションのポート(1.11.2)を指定して、指定されたローカル IP アドレスから SCGI サーバへの発信接続を行います。パラメータ値には変数(1.3.12)を含めることができます。特別な値 off (1.3.12) は、以前の設定レベルから継承された scgi_bind ディレクティブの効果をキャンセルし、システムがローカル IP アドレスとポートを自動的に割り当てることを可能にします。

transparent パラメータ (1.11.0) は、SCGI サーバへの接続を非ローカル IP アドレス、例えばクライアントの実在の IP アドレスから発信することを許可します。

scgi_bind $remote_addr transparent. このパラメータを動作させるためには、通常、スーパーユーザ権限で nginx ワーカープロセスを実行する必要があります。Linux では、transparent パラメータが指定されている場合、ワーカープロセスはマスタープロセスから CAP_NET_RAW 機能を継承するため、これは必須ではありません (1.13.8)。また、SCGI サーバからのネットワークトラフィックを傍受するために、カーネルルーティングテーブルを設定する必要があります。

SCGI サーバから受信したレスポンスの最初の部分を読み込むために使用するバッファのサイズを設定します。この部分には通常小さなレスポンスヘッダが含まれます。デフォルトでは、バッファサイズは 1 メモリページに相当します。これはプラットフォームに応じて 4K または 8K のどちらかになります。しかし、これより小さくすることもできます。

SCGI サーバからのレスポンスのバッファリングを有効または無効にします。

バッファリングが有効な場合、nginx は SCGI サーバからのレスポンスをできるだけ早く受信し、scgi_buffer_size と scgi_buffers 記述内容で設定されたバッファに保存します。レスポンス全体がメモリに収まらない場合は、その一部をディスク上の一時ファイルに保存することができます。一時ファイルへの書き込みは scgi_max_temp_file_size と scgi_temp_file_write_size 記述内容によって制御されます。

バッファリングが無効になっている場合、レスポンスは受信した直後に同期的にクライアントに渡されます。nginx がサーバから一度に受け取ることができるデータの最大サイズは scgi_buffer_size ディレクティブで設定されます。

バッファリングは "X-Accel-Buffering" レスポンスヘッダフィールドに "yes" か "no" を渡すことで有効にしたり無効にしたりすることができます。この機能は scgi_ignore_headers ディレクティブで無効にすることができます。

1 つの接続に対して、SCGI サーバからの応答を読み込むために使用するバッファの数とサイズを設定します。デフォルトでは、バッファサイズは 1 メモリページに相当します。これは、プラットフォームに応じて 4K または 8K のどちらかになります。

SCGI サーバからの応答のバッファリングが有効になっている場合、応答がまだ完全に読み込まれていない間にクライアントへの応答の送信がビジーになるバッファの合計サイズを制限します。その間、残りのバッファはレスポンスの読み込みに使用され、必要に応じてレスポンスの一部を一時ファイルにバッファリングすることができます。デフォルトでは、サイズは scgi_buffer_size と scgi_buffers 記述内容によって設定された 2 つのバッファのサイズによって制限されます。

キャッシングに使用する共有メモリゾーンを定義します。同じゾーンを複数の場所で使用することができます。パラメータ値には変数を含めることができます（1.7.9）。off パラメータは、前の構成レベルから継承されたキャッシングを無効にします。

期限切れのキャッシュアイテムを更新するためのバックグラウンドサブリクエストを開始し、古いキャッシュレスポンスをクライアントに返すことを許可します。更新されているときに古いキャッシュ応答を使用できるようにする必要があることに注意してください。

レスポンスがキャッシュから取得されない条件を定義します。文字列パラメータの少なくとも一つの値が空でなく "0" でない場合、レスポンスはキャッシュから取得されません。

scgi_no_cache ディレクティブと一緒に使うことができます。

キャッシング用のキーを定義します。

scgi_cache_key localhost:9000$request_uri;

有効にすると、SCGI サーバにリクエストを渡すことで scgi_cache_key ディレクティブで指定された新しいキャッシュ要素に一度に一つのリクエストだけが許可されます。同じキャッシュ要素に対する他のリクエストは、 scgi_cache_lock_timeout ディレクティブで設定された時間まで、キャッシュにレスポンスが現れるのを待つか、 この要素のキャッシュロックが解除されるのを待ちます。

新しいキャッシュ要素を生成するために SCGI サーバに渡された最後のリクエストが、指定された時間の間に完了しなかった場合、SCGI サーバにさらに 1 つのリクエストを渡すことができます。

scgi_cache_lock のタイムアウトを設定します。タイムアウトした場合、リクエストは SCGI サーバに渡されますが、レスポンスはキャッシュされません。

1.7.8 より前のバージョンでは、レスポンスはキャッシュされていました。

バイト範囲リクエストのオフセットをバイト単位で設定します。範囲がオフセットを超えている場合、範囲リクエストは SCGI サーバに渡され、レスポンスはキャッシュされません。

クライアントのリクエストメソッドがこのディレクティブにリストアップされている場合、 レスポンスはキャッシュされます。"GET" と "HEAD" メソッドは常にリストに追加されますが、明示的に指定することが推奨されます。scgi_no_cache ディレクティブも参照してください。

応答がキャッシュされるまでのリクエスト数を設定します。

キャッシュのパスなどを設定します。キャッシュデータはファイルに格納されます。キャッシュ内のファイル名は、キャッシュキーに MD5 関数を適用した結果です。levels パラメータは、キャッシュの階層レベルを定義します。例えば、以下の設定では

scgi_cache_path /data/nginx/cache levels=1:2 keys_zone=one:10m; file names in a cache will look like this:

/data/nginx/cache/c/29/b7f54b2df7773722d382f4809d65029c

キャッシュされたレスポンスは最初に一時ファイルに書き込まれ、その後ファイル名が変更されます。バージョン 0.8.9 以降、一時ファイルとキャッシュは異なるファイルシステムに置くことができます。しかし、この場合、ファイルは安価なリネーム操作の代わりに 2 つのファイルシステムにコピーされることに注意してください。したがって、どのような場所でも、キャッシュと一時ファイルを格納するディレクトリの両方を同じファイルシステムに置くことをお勧めします。一時ファイルを格納するディレクトリは use_temp_path パラメータ(1.7.10)に基づいて設定される。このパラメータが省略された場合、または on に設定された場合は、指定された場所の scgi_temp_path ディレクティブで設定されたディレクトリが使用されます。値がoffに設定されている場合、一時ファイルは直接キャッシュディレクトリに置かれます。

さらに、すべてのアクティブな鍵とデータに関する情報は共有メモリゾーンに保存され、その名前とサイズは keys_zoneパラメータで設定される。1メガバイトのゾーンには、約8,000個の鍵を格納することができる。

商用サブスクリプションの一環として、共有メモリゾーンには拡張キャッシュ情報も格納されているため、同じ数の鍵に対してより大きなゾーンサイズを指定する必要があります。例えば、1メガバイトのゾーンには約4,000個の鍵を格納することができます。 inactiveパラメータで指定された時間内にアクセスされなかったキャッシュデータは、その鮮度に関係なくキャッシュから削除されます。デフォルトでは、inactiveは10分に設定されている。

特別な「キャッシュマネージャ」プロセスは、max_sizeパラメータで設定された最大キャッシュサイズを監視します。このサイズを超えると、最近使用されたデータを削除します。データは manager_files、manager_threshold、manager_sleep パラメータ (1.11.5) で設定された繰り返しで削除されます。1回のイテレーションの間に削除されるのは、 manager_filesの項目を超えてはなりません (デフォルトでは100)。1回の反復の期間は、 manager_thresholdパラメータによって制限されます (デフォルトでは、200ミリ秒)。反復の間には、 manager_sleep パラメータで設定された一時停止が行われます (デフォルトでは 50 ミリ秒)。

起動から1分後に特別な「キャッシュローダー」プロセスが起動します。ファイルシステムに保存されている以前にキャッシュされたデータの情報をキャッシュゾーンにロードします。ロードは反復して行われます。1 回の繰り返しの間に loader_files の項目がロードされるのはそれ以上ではありません (デフォルトでは 100)。さらに、1 回の反復の期間は loader_threshold パラメータによって制限されます（デフォルトでは 200 ミリ秒）。反復の間には、loader_sleep パラメータ（デフォルトでは 50 ミリ秒）で設定した一時停止が行われます。

さらに、以下のパラメータは、当社の商用サブスクリプションの一部として、 keys_zoneパラメータで利用可能です。1メガバイトのゾーンには、約8,000個の鍵を格納することができる。

purger=on|off

ワイルドカードキーに一致するキャッシュエントリをキャッシュパージ機能 (1.7.12) でディスクから削除するかどうかを指定します。パラメータを on (デフォルトは off) に設定すると、すべてのキャッシュエントリを恒久的に反復処理し、ワイルドカードキーにマッチするエントリを削除する「キャッシュパージ」プロセスが有効になります。

purger_files=number

1 回の繰り返しでスキャンするアイテムの数を設定します (1.7.12)。デフォルトでは、Purger_files は 10 に設定されています。

purger_threshold=number

1 回の反復の持続時間を設定します (1.7.12)。デフォルトでは、Purger_threshold は 50 ミリ秒に設定されています。

purger_sleep=number

反復の間の一時停止を設定します (1.7.12)。デフォルトでは、purger_sleep は 50 ミリ秒に設定されています。 バージョン 1.7.3、1.7.7、および 1.11.10 では、キャッシュヘッダの形式が変更されました。新しいバージョンの nginx にアップグレードすると、以前にキャッシュされたレスポンスは無効とみなされます。

リクエストがキャッシュパージリクエストとみなされる条件を定義します。文字列パラメータの少なくとも一つの値が空ではなく、"0" に等しくない場合、対応するキャッシュキーを持つキャッシュエントリが削除されます。操作が成功した結果は 204 (No Content) 応答を返すことで示される。

パージ要求のキャッシュキーがアスタリスク ("*") で終わる場合、ワイルドカードキーにマッチする全てのキャッシュエントリがキャッシュから削除されます。しかし、これらのエントリは、非活動状態で削除されるか、キャッシュパージ機能 (1.7.12) によって処理されるか、クライアントがアクセスしようとするまで、ディスク上に残ります。

設定例:

この機能は、当社の商用サブスクリプションの一部としてご利用いただけます。

If-Modified-Since" および "If-None-Match" ヘッダーフィールドを持つ条件付きリクエストを使用して、期限切れのキャッシュアイテムの再バリデーションを有効にします。

SCGI サーバとの通信中にエラーが発生した場合に、 どのような場合に古いキャッシュされたレスポンスを使用できるかを決定します。このディレクティブのパラメータは scgi_next_upstream ディレクティブのパラメータと一致します。

error パラメータは、リクエストを処理する SCGI サーバが選択できない場合にキャッシュされた古いレスポンスを使用することもできます。

さらに、update パラメータでは、現在更新中の場合は古いキャッシュされたレスポンスを使用することができます。これにより、キャッシュされたデータを更新する際に、 SCGI サーバへのアクセス数を最小限に抑えることができます。

スタールキャッシュされた応答を使用することは、応答がスタールになってから指定された秒数だけ応答ヘッダで直接有効にすることもできます (1.11.10)。これはディレクティブのパラメータを使うよりも優先度が低いです。

Cache-Control」ヘッダフィールドの「stale-while-revalidate」拡張は、現在更新中の場合、古いキャッシュされた 応答を使用することを許可します。 Cache-Control" ヘッダ・フィールドの "stale-if-error" 拡張子は、エラーが発生した場合に古いキャッシュ・レスポンスの使用を許可します。 新しいキャッシュ要素を生成する際に SCGI サーバへのアクセス数を最小限にするために、 scgi_cache_lock ディレクティブを使用することができます。

異なるレスポンスコードのキャッシュ時間を設定します。例えば、次のような記述内容

キャッシング時間のみを指定した場合

scgi_cache_valid 5m;

の場合、200、301、および302応答のみがキャッシュされます。

さらに、any パラメータを指定することで、任意のレスポンスをキャッシュすることができます。

キャッシングのパラメータはレスポンスヘッダで直接設定することもできます。これはディレクティブを使ったキャッシュ時間の設定よりも優先度が高くなります。

X-Accel-Expires" ヘッダフィールドは応答のキャッシュ時間を秒単位で設定します。ゼロの値は応答のキャッシュを無効にします。接頭辞 @ で始まる値は、Epoch からの絶対時間を秒単位で設定します。 ヘッダーが「X-Accel-Expires」フィールドを含まない場合、キャッシングのパラメータは ヘッダーフィールド「Expires」または「Cache-Control」で設定できる。 ヘッダが「Set-Cookie」フィールドを含む場合、そのような応答はキャッシュされない。 ヘッダーが特別な値「*」を持つ「Vary」フィールドを含む場合、そのような応答は キャッシュされない(1.7.7)。ヘッダーが別の値を持つ「Vary」フィールドを含む場合、そのような応答は 対応するリクエストヘッダーフィールドを考慮に入れてキャッシュされる(1.7.7)。 これらの応答ヘッダフィールドのうちの一つ以上の処理は scgi_ignore_headers ディレクティブを使って無効にすることができます。

SCGI サーバとの接続を確立するためのタイムアウトを定義します。このタイムアウトは通常 75 秒を超えることはできないことに注意してください。

SCGI サーバからのキャッシュされた応答とキャッシュされていない応答の両方に対して、これらの応答の "Accept-Ranges" フィールドに関係なくバイトレンジのサポートを有効にします。

デフォルトでは、nginx は SCGI サーバのレスポンスから "Status" と "X-Accel-..." というヘッダフィールドをクライアントに渡しません。scgi_hide_header ディレクティブは、渡さない追加のフィールドを設定します。逆に、フィールドを渡すことを許可する必要がある場合は、 scgi_pass_header ディレクティブを使用することができます。

クライアントが応答を待たずに接続を閉じた場合に、SCGI サーバとの接続を閉じるかどうかを決定します。

SCGI サーバからの特定のレスポンスヘッダフィールドの処理を無効にします。以下のフィールドは無視することができます。"X-Accel-Redirect"、"X-Accel-Expires"、"X-Accel-Limit-Rate" (1.1.6), "X-Accel-Buffering" (1.1.6), "X-Accel-Charset" (1.1.6), "Expires"、"Cache-Control"、"Set-Cookie" (0.8.44), "Vary" (1.7.7)。

無効にしていない場合、これらのヘッダーフィールドの処理は以下のような効果があります。

"X-Accel-Expires"、"Expires"、"Cache-Control"、"Set-Cookie"、および "Vary "は、レスポンスキャッシングのパラメータを設定する。 "X-Accel-Redirect" は、指定された URI への内部リダイレクトを実行します。 "X-Accel-Limit-Rate」は、クライアントへの応答送信のレート制限を設定します。 "X-Accel-Buffering」は、応答のバッファリングを有効または無効にします。 "X-Accel-Charset」は、レスポンスの希望する文字セットを設定します。

300 以上のコードを持つ SCGI サーバのレスポンスをクライアントに渡すか、 傍受して nginx にリダイレクトして error_page ディレクティブで処理するかを決定します。

SCGI サーバからのレスポンスの読み込み速度を制限します。レートは 1 秒あたりのバイト数で指定します。ゼロの値はレートの制限を無効にします。制限はリクエストごとに設定されるので、nginx が同時に SCGI サーバーに 2 つの接続を開いた場合、全体のレートは指定された制限の 2 倍になります。この制限は SCGI サーバからのレスポンスのバッファリングが有効な場合にのみ機能します。

SCGI サーバからの応答のバッファリングが有効で、 scgi_buffer_size と scgi_buffers ディレクティブで設定されたバッファに応答全体が収まらない場合、 応答の一部を一時ファイルに保存することができます。このディレクティブは一時ファイルの最大サイズを設定します。一度に一時ファイルに書き込まれるデータのサイズは scgi_temp_file_write_size ディレクティブで設定されます。

ゼロの値は、一時ファイルに対する応答のバッファリングを無効にします。

この制限は、キャッシュまたはディスクに保存される応答には適用されません。

どのような場合にリクエストを次のサーバーに渡すかを指定します。 error サーバーとの接続を確立しているとき、リクエストをサーバーに渡しているとき、またはレスポンスヘッダを読んでいるときにエラーが発生しました。 timeout サーバーとの接続を確立している間、リクエストをサーバーに渡している間、または応答ヘッダーを読んでいる間にタイムアウトが発生しました。 invalid_header サーバが空か無効な応答を返しました。 http_500 サーバがコード500のレスポンスを返しました。 http_503 はコード503のレスポンスを返しました。 http_403 サーバはコード403で応答を返しました。 http_404 サーバーはコード 404 で応答を返しました。 http_429 サーバーはコード429 (1.11.13)の応答を返しました。 non_idempotent 通常、リクエストがアップストリームサーバ (1.9.13) に送られた場合、非親和的なメソッド (POST, LOCK, PATCH) を持つリクエストは次のサーバに渡されません。 off disables passing a request to the next server. 次のサーバへのリクエストの受け渡しは、まだクライアントに何も送られていない場合にのみ可能であることを心に留めておくべきです。つまり、レスポンスの転送中にエラーやタイムアウトが発生した場合、これを修正することは不可能です。

このディレクティブでは、サーバとの通信の試みが失敗したとみなされるものも定義しています。error, timeout, invalid_header の場合は、たとえディレクティブで指定されていなくても、 常に失敗したとみなされます。http_500, http_503, http_429 の場合は、ディレクティブで指定されている場合に限り、 失敗したとみなされます。http_403 と http_404 の場合は、失敗したとみなされることはありません。

次のサーバへのリクエストの受け渡しは、試行回数と時間によって制限されます。

リクエストを次のサーバーに渡すことができる時間を制限します。0 の値はこの制限をオフにします。

次のサーバーにリクエストを渡すための試行回数を制限します。0 の値はこの制限をオフにします。

レスポンスがキャッシュに保存されない条件を定義します。文字列パラメータの少なくとも一つの値が空でなく、かつ "0" でない場合、レスポンスは保存されません。

scgi_no_cache $cookie_nocache $arg_nocache$arg_comment; scgi_no_cache $http_pragma $http_authorization; Can be used along with the scgi_cache_bypass directive.

SCGI サーバに渡すパラメータを設定します。値には、テキスト、変数、およびそれらの組み合わせを含めることができます。これらの記述内容は、現在のレベルに scgi_param 記述内容が定義されていない場合にのみ、前のレベルから継承されます。

標準 CGI 環境変数は SCGI ヘッダとして提供されなければなりません。

ディレクティブが if_not_empty (1.1.11) で指定されている場合は、その値が空でない場合にのみ、そのようなパラメータがサーバに渡されます。

scgi_param HTTPS $https if_not_empty.

SCGI サーバのアドレスを設定します。アドレスはドメイン名または IP アドレス、ポートを指定します。

scgi_pass localhost:9000; or as a UNIX-domain socket path:

scgi_pass unix:/tmp/scgi.socket; ドメイン名が複数のアドレスに解決された場合、すべてのアドレスがラウンドロビン方式で使用されます。また、サーバーグループとしてアドレスを指定することもできます。

パラメータ値には変数を含めることができます。この場合、ドメイン名としてアドレスが指定された場合には、記述されたサーバグループの中から検索され、見つからなければリゾルバを用いて決定される。

無効なヘッダフィールドを SCGI サーバからクライアントに渡すことを許可します。.

元のリクエストボディを SCGI サーバに渡すかどうかを示します。scgi_pass_request_headers ディレクティブも参照してください。

元のリクエストのヘッダフィールドを SCGI サーバに渡すかどうかを示します。scgi_pass_request_body ディレクティブも参照してください。

SCGI サーバから応答を読み込む際のタイムアウトを定義します。タイムアウトは 2 つの連続した読み込み操作の間にのみ設定され、応答全体の送信には設定されません。SCGI サーバがこの時間内に何も送信しなかった場合、接続は閉じられます。

クライアントリクエストボディのバッファリングを有効または無効にします。

バッファリングが有効な場合は、リクエストを SCGI サーバに送信する前にクライアントからリクエストボディ全体を読み込みます。

バッファリングが無効になっている場合、リクエストボディは受信した時点ですぐに SCGI サーバに送信されます。この場合、nginx が既にリクエストボディの送信を開始している場合、次のサーバにリクエストを渡すことはできません。

HTTP/1.1 のチャンク化された転送エンコーディングを使用して元のリクエストボディを送信する場合は、ディレクティブの値に関係なくリクエストボディがバッファリングされます。

リクエストを SCGI サーバに送信する際のタイムアウトを設定します。タイムアウトは 2 回の連続した書き込み操作の間にのみ設定され、リクエスト全体の送信には設定されません。この時間内に SCGI サーバが何も受信しなかった場合、接続は閉じられます。

SCGI サーバへの送信接続における "TCP keepalive" の動作を設定します。デフォルトでは、オペレーティングシステムの設定がソケットに対して有効になっています。ディレクティブの値が "on" に設定されている場合、SO_KEEPALIVE ソケットオプションがソケットに対して有効になります。

ファイルのディスクへの保存を有効にします。on パラメータを指定すると、エイリアスまたはルートに対応するパスでファイルを保存します。off パラメータはファイルの保存を無効にします。また、変数付きの文字列を使用して、ファイル名を明示的に設定することができます。

scgi_store /data/www$original_uri; ファイルの修正時間は、受信した "Last-Modified "応答ヘッダフィールドに応じて設定される。レスポンスは最初に一時ファイルに書き込まれ、その後ファイル名が変更されます。バージョン0.8.9からは、一時ファイルと永続ストアを別のファイルシステムに置くことができます。しかし、この場合、ファイルは安価なリネーム操作ではなく、2つのファイルシステムにまたがってコピーされることに注意してください。したがって、どのような場所でも、保存されたファイルと scgi_temp_path ディレクティブで設定された一時ファイルを保持するディレクトリの両方を同じファイルシステムに置くことが推奨されます。

このディレクティブは、静的で変更不可能なファイルのローカルコピーを作成するために使われます。

新しく作成されたファイルやディレクトリのアクセス権限を設定します。

scgi_store_access user:rw group:rw all:r. グループまたはすべてのアクセス権限が指定されている場合は、ユーザ権限を省略することができます。

scgi_store_access group:rw all:r;

SCGI サーバからの応答の一時ファイルへのバッファリングが有効な場合、一度に一時ファイルに書き込まれるデータのサイズを制限します。デフォルトでは、サイズは scgi_buffer_size と scgi_buffers 記述内容で設定された 2 つのバッファによって制限される。一時ファイルの最大サイズは scgi_max_temp_file_size ディレクティブで設定されます。

SCGI サーバから受信したデータを一時的に保存するためのディレクトリを定義します。指定したディレクトリの下には、3階層までのサブディレクトリ階層を使用することができます。例えば、次のような構成の場合

scgi_temp_path /spool/nginx/scgi_temp 1 2; a temporary file might look like this:

/spool/nginx/scgi_temp/7/45/00000123457 See also the use_temp_path parameter of the scgi_cache_path directive.

Module ngx_http_secure_link_module

ngx_http_secure_link_module モジュール (0.7.18) は、要求されたリンクの真正性の確認、不正アクセスからのリソースの保護、およびリンクの有効期間の制限に使用されます。

要求されたリンクの真正性は、リクエストで渡されたチェックサムの値と、 リクエストに対して計算された値を比較することで検証されます。リンクの有効期間が制限されており、時間が経過している場合、そのリンクは古いものとみなされます。これらのチェックの状態は $secure_link 変数で確認できます。

このモジュールは二つの代替動作モードを提供しています。最初のモードは secure_link_secret ディレクティブで有効になり、要求されたリンクの真正性をチェックしたり、 不正なアクセスからリソースを保護したりするために使用されます。二つ目のモード (0.8.50) は secure_link と secure_link_md5 記述内容によって有効になり、リンクの寿命を制限するためにも使用されます。

このモジュールはデフォルトではビルドされていませんので、 --with-http_secure_link_module 設定パラメータで有効にする必要があります。

記述内容

リンクのチェックサム値とライフタイムが抽出される変数を持つ文字列を定義します。

式の中で使われる変数は通常リクエストに関連付けられています。

文字列から抽出されたチェックサム値は、 secure_link_md5 ディレクティブで定義された式の MD5 ハッシュ値と比較されます。チェックサムの値が異なる場合、$secure_link 変数には空の文字列が設定されます。チェックサムが同じ場合は、リンクの有効期限をチェックします。リンクの有効期限が限られていて、期限が切れている場合は、 $secure_link 変数に "0" が設定されます。それ以外の場合は "1 "が設定されます。リクエストで渡されたMD5ハッシュ値はbase64urlでエンコードされます。

リンクの有効期限が制限されている場合、有効期限はエポック(Thu, 01 Jan 1970 00:00:00 GMT)からの秒数で設定されます。値は MD5 ハッシュの後の式で指定され、カンマで区切られます。リクエストで渡された有効期限は、secure_link_md5 ディレクティブで使用するために $secure_link_expires 変数を通して利用できます。有効期限が指定されていない場合、リンクは無制限の有効期限を持ちます。

MD5 ハッシュ値を計算し、リクエストで渡された値と比較する式を定義します。

式には、リンク(リソース)の保護された部分と秘密の成分を含めなければなりません。リンクの有効期限が限られている場合、式には $secure_link_expires も含まれなければなりません。

不正なアクセスを防ぐために、式にはクライアントのアドレスやブラウザのバージョンなど、 クライアントに関する情報が含まれているかもしれません。

Example:

"/s/link?md5=_e4Nc3iduzkWRm01TBBNYw&expires=2147483647 "リンクは、IPアドレス127.0.0.1のクライアントに対して「/s/link」へのアクセスを制限しています。また、このリンクは2038年1月19日(GMT)までの有効期限が制限されています。

UNIXでは、md5リクエストの引数値は次のように取得できます。

要求されたリンクの信頼性をチェックするために使われる秘密の単語を定義します。

要求されたリンクの完全なURIは以下のようになります。

/prefix/hash/link hashはリンクとシークレットワードを連結するために計算されたMD5ハッシュの16進数表現であり、 prefixはスラッシュを含まない任意の文字列です。

リクエストされたリンクが真正性チェックに合格した場合、 $secure_link変数にはリクエストURIから抽出されたリンクが設定されます。そうでなければ、$secure_link 変数には空の文字列が設定されます。

Example:

"/p/5e814704a28d9bc1914ff19fa0c4a00a/link" のリクエストは内部的に "/secure/link" にリダイレクトされます。

UNIXでは、この例のハッシュ値は次のように取得できます。

埋め込み変数 セキュアリンク リンクチェックの状態です。具体的な値は、選択された動作モードに依存します。 SECURE_LINK_EXPIRES リクエストで渡されたリンクの有効期限。

Module ngx_http_session_log_module

ngx_http_session_log_module モジュールを使用すると、個々の HTTP リクエストではなく、セッション (複数の HTTP リクエストの集合体) をログに記録することができます。

このモジュールは、当社の商用サブスクリプションの一部としてご利用いただけます。

設定例

以下の設定では、セッションログを設定し、リクエストクライアントアドレスと "User-Agent "リクエストヘッダーフィールドに応じてリクエストをセッションにマッピングします。

記述内容

指定したセッション・ログの使用を有効にします。特別な値 off は、前の構成レベルから継承されたすべての session_log 記述内容をキャンセルします。

ログの出力形式を指定します。body_bytes_sent 変数の値は、セッション内のすべてのリクエストを集約します。ログ出力に使用できる他のすべての変数の値は、セッション内の最初のリクエストに対応します。

ログファイルのパスを設定し、現在アクティブなセッションを保存するために使用する共有メモリゾーンを設定します。

セッションの最後のリクエストからの経過時間が指定されたタイムアウト(デフォルトでは30秒)を超えない限り、セッションはアクティブとみなされます。セッションがアクティブでなくなると、ログに書き込まれます。

idパラメータはリクエストがマップされるセッションを識別します。id パラメータは MD5 ハッシュの 16 進表現に設定されます(例えば、変数を使ってクッキーから取得されます)。このパラメータが指定されていないか、有効な MD5 ハッシュを表していない場合、nginx は md5 パラメータの値から MD5 ハッシュを計算し、このハッシュを使って新しいセッションを作成します。id と md5 パラメータはどちらも変数を含むことができます。

format パラメータは、session_log_format ディレクティブで設定されたカスタムのセッションログフォーマットを設定します。format が指定されていない場合は、定義済みの "combined" フォーマットが使用されます。

埋め込み変数 ngx_http_session_log_moduleモジュールは、2つの埋め込み変数をサポートしています。 $session_log_id 現在のセッションID。 $session_log_binary_id バイナリ形式の現在のセッション ID (16 バイト)。

Module ngx_http_slice_module

ngx_http_slice_module モジュール (1.9.8) は、リクエストをサブリクエストに分割し、 それぞれが一定の範囲のレスポンスを返すフィルタです。このフィルタは、大きなレスポンスをより効果的にキャッシュします。

このモジュールはデフォルトではビルドされていないので、 --with-http_slice_module 設定パラメータで有効にしなければなりません。

設定例

この例では、レスポンスは1メガバイトのキャッシュ可能なスライスに分割されます。

記述内容

スライスのサイズを設定します。0 の値を指定すると、応答をスライスに分割することができなくなります。あまりにも低い値を指定すると、 メモリを過剰に使用したり、大量のファイルを開いたりする可能性があることに注意してください。

サブリクエストが必要な範囲を返すためには、$slice_range 変数を Range リクエストヘッダーフィールドとしてプロキシサーバに渡さなければなりません。キャッシュが有効になっている場合は、$slice_rangeをキャッシュキーに追加し、206のステータスコードを持つレスポンスのキャッシュを有効にする必要があります。

Embedded Variables ngx_http_slice_moduleモジュールは、以下の埋め込み変数をサポートしています。

slice_range 現在のスライス範囲をHTTPバイトレンジ形式で指定します。

ngx_http_spdy_module モジュールは SPDY を実験的にサポートしています。現在、SPDY プロトコルのドラフト 3.1 が実装されています。

バージョン 1.5.10 以前は SPDY プロトコルのドラフト 2 が実装されていました。 このモジュールはデフォルトではビルドされていませんので、 --with-http_spdy_module設定パラメータで有効にする必要があります。

このモジュールは、1.9.5 で ngx_http_v2_module モジュールに置き換えられました。 既知の問題 このモジュールは実験的なものです。

現在の SPDY プロトコルの実装は "server push" をサポートしていません。

1.5.9 より前のバージョンでは、SPDY 接続のレスポンスはレート制限されませんでした。

proxy_request_buffering, fastcgi_request_buffering, uwsgi_request_buffering, scgi_request_buffering ディレクティブの値に関わらず、クライアントのリクエストボディの バッファリングを無効にすることはできません。

設定例

なお、同一ポートでHTTPSとSPDYの両方の接続を同時に受け付けるためには、OpenSSLのバージョン1.0.1以降で利用可能なTLS拡張 "Next Protocol Negotiation "をサポートしている必要があります。

記述内容

応答ボディがスライスされるチャンクの最大サイズを設定します。値が低すぎるとオーバーヘッドが大きくなります。値が高すぎると、HOL ブロッキングによる優先順位付けが損なわれます。

応答のヘッダー圧縮レベルを、1 (最速、低圧縮) から 9 (最遅、最高圧縮) までの範囲で設定します。特別な値 0 は、ヘッダ圧縮をオフにします。

埋め込まれた変数

ngx_http_spdy_moduleモジュールは、以下の組み込み変数をサポートしています。

$spdy

SPDY接続の場合はSPDYプロトコルのバージョン、それ以外の場合は空文字列。

SPDY接続のためのSPDYプロトコルのバージョン、そうでない場合は空文字列、そうでない場合は空文字列。

SPDY 接続のリクエスト優先度、そうでなければ空文字列。

Module ngx_http_split_clients_module

ngx_http_split_clients_moduleモジュールは、スプリットテストとも呼ばれるA/Bテストに適した変数を作成します。

設定例

記述内容

例えば、A/Bテスト用の変数を作成します。

元の文字列の値を MurmurHash2 でハッシュ化します。この例では、0 から 21474835 (0.5%) までのハッシュ値が $variant 変数の値 ".one" に、21474836 から 107374180 (2%) までのハッシュ値が値 ".two" に、107374181 から 4294967295 までのハッシュ値が値 "" (空の文字列) に対応しています。

Module ngx_http_ssi_module

ngx_http_ssi_module モジュールは、このモジュールを通過するレスポンスの SSI (Server Side Includes) コマンドを処理するフィルタです。現在のところ、サポートされている SSI コマンドのリストは不完全です。

設定例

記述内容

レスポンスでの SSI コマンドの処理を有効または無効にします。

SSI 処理中に元のレスポンスの「Last-Modified」ヘッダーフィールドを保存して、レスポンスのキャッシングを容易にすることを許可します。

デフォルトでは、レスポンスの内容が処理中に変更されると、ヘッダーフィールドは削除され、元のレスポンスとは独立して変更される動的に生成された要素や部分を含むことがあります。

ディスクに保存されているレスポンスの部分の最小サイズを設定します。

有効にすると、SSI処理中にエラーが発生した場合、"[an error occurred during processing the directive]"文字列の出力を抑制します。

text/html」に加えて、指定されたMIMEタイプを持つレスポンスでのSSIコマンドの処理を有効にします。特別な値 "*" は任意の MIME タイプにマッチします (0.8.29)。

SSI コマンドのパラメータ値の最大長を設定します。

SSI Commands SSI コマンドには、以下のような汎用的なフォーマットがあります。

以下のコマンドに対応しています。

block

include コマンドのスタブとして使用できるブロックを定義します。このブロックには他のSSIコマンドを含めることができます。コマンドには以下のパラメータがあります。

name

ブロック名を指定します。 例 ブロック名を指定します。 扣え <! config SSI 処理中に使用されるいくつかのパラメータを設定します。 errmsg SSI 処理中にエラーが発生した場合に出力される文字列。デフォルトでは以下の文字列が出力されます。 ディレクティブの処理中にエラーが発生しました。 timefmt 日付と時刻を出力するために使用する strftime() 関数に渡される書式文字列。デフォルトでは、以下のフォーマットが使用されます。 "%A, %d-%b-%Y %H:%M:%S:%Z" 時間を秒単位で出力する場合は、"%s "形式が適しています。

echo

変数の 値を出力します。コマンドには以下のパラメータがあります。

var

変数名を指定します。

encoding

エンコーディング方法を指定します。指定可能な値は、none、url、および entity です。デフォルトでは、 entity が使用されます。

default

変数が未定義の場合に出力される文字列を設定する非標準のパラメータ。デフォルトでは、"(none) "が出力されます。コマンド は、以下の一連のコマンドに置き換えられます。 no if 条件付き包含を実行します。以下のコマンドがサポートされています。 ... ... ... 現在、1 つのレベルの入れ子のみがサポートされています。コマンドには以下のパラメータがあります。 expr 式を使用することができます。式は次のようなことができます。 変数の存在チェック。 変数とテキストの比較 変数と正規表現の比較。 テキストに変数が含まれている場合は、その値が代入されます。正規表現は、例えば、後に変数を通して使用することができる位置と名前付きのキャプチャを含むことができます。 include 別のリクエストの結果をレスポンスに含めます。コマンドには以下のパラメータがあります。 file はインクルードされたファイルを指定します。 virtual specifies an included request, for example: 1 ページに指定されたいくつかのリクエストは、proxied または FastCGI/uwsgi/SCGI/gRPC サーバーによって処理され、並列に実行されます。順次処理したい場合は wait パラメータを使用します。 stub 標準ではないパラメータで、含まれるリクエストの結果が空のボディであった場合や、リクエスト処理中にエラーが発生した場合などに、その内容が出力されるブロックの名前を指定します。   置換ブロックコンテンツは、含まれるリクエストコンテキストで処理されます。

wait は、例えばSSI処理を続ける前にリクエストが完全に完了するまで待つように指示する非標準のパラメータです。

set リクエスト処理の成功結果を指定された変数に書き込むように指示する非標準のパラメータ。 レスポンスの最大サイズは subrequest_output_buffer_size ディレクティブ (1.13.10) で設定されます。

バージョン 1.13.10 より前のバージョンでは、ngx_http_proxy_module、ngx_http_memcached_module、ngx_http_fastcgi_module (1.5.6), ngx_http_uwsgi_module (1.5.6), ngx_http_scgi_module (1.5.6) で取得したレスポンスの結果のみを変数に書き込むことができました。proxy_buffer_size, memcached_buffer_size, fastcgi_buffer_size, uwsgi_buffer_size, scgi_buffer_size 記述内容でレスポンスの最大サイズを設定した。 set 変数の値を設定します。コマンドには以下のパラメータがあります。 var 変数名を指定します。 value 変数の値を指定します。代入された値に変数が含まれている場合は、その値が代入されます。 Embedded Variables ngx_http_ssi_moduleモジュールは、2つの埋め込み変数をサポートしています。

date_local ローカルタイムゾーンの現在時刻を指定します。フォーマットはconfigコマンドでtimefmtパラメータを指定して設定します。 日付の書式を設定します。 現在の時刻をGMTで表示します。フォーマットはconfigコマンドでtimefmtパラメータを指定して設定します。

Module ngx_http_ssl_module

ngx_http_ssl_module は、HTTPS に必要なサポートを提供します。

このモジュールはデフォルトではビルドされていないので、 --with-http_ssl_module 設定パラメータで有効にする必要があります。

このモジュールには OpenSSL ライブラリが必要です。

設定例

プロセッサの負荷を軽減するには

ワーカープロセスの数をプロセッサの数と同じに設定します。 キープアライブ接続を有効にします。 共有セッションキャッシュを有効にします。 内蔵のセッションキャッシュを無効にします。 また、セッションの有効時間を増やすこともできます (デフォルトでは 5 分)。

worker_processes auto.

 

記述内容

このディレクティブはバージョン 1.15.0 で廃止されました。代わりに listen ディレクティブの ssl パラメータを使うべきです。

データ送信に使用するバッファのサイズを設定します。

デフォルトでは、バッファサイズは 16k で、大きなレスポンスを送信する際のオーバーヘッドを最小限に抑えることができます。最初のバイトまでの時間を最小にするには、例えば、より小さな値を使用することが有益かもしれません。

指定した仮想サーバーの PEM 形式の証明書のファイルを指定します。プライマリ証明書に加えて中間証明書を指定する場合は、プライマリ証明書を先に、中間証明書を先に指定します。PEM 形式の秘密鍵を同じファイルに記述してもかまいません。

バージョン 1.11.0 以降では、このディレクティブを複数回指定して、RSA や ECDSA などの異なるタイプの証明書を読み込むことができます。

OpenSSL 1.0.2 以降では、異なる証明書に対して別々の証明書チェーンをサポートしています。それ以前のバージョンでは、1つの証明書チェーンしか使用できません。 バージョン1.15.9以降、OpenSSL 1.0.2以上では、ファイル名に変数を使用できるようになりました。

ssl_certificate $ssl_server_name.crt; ssl_certificate_key $ssl_server_name.key;

変数を使うと、SSLハンドシェイクのたびに証明書が読み込まれることになり、パフォーマンスに悪影響を及ぼす可能性があることに注意してください。

ファイル (1.15.10) の代わりに data:$variable という値を指定することができますが、これは中間ファイルを使わずに変数から証明書をロードします。この構文の不適切な使用は、秘密鍵データをエラーログに書き込むなどのセキュリティ上の意味合いを持つ可能性があることに注意してください。

相互運用性を最大化するためには、HTTPS プロトコルの制限により、仮想サーバーは異なる IP アドレスでリッスンする必要があることに留意してください。

指定した仮想サーバーの秘密鍵のファイルを PEM 形式で指定します。

ファイル (1.7.9) の代わりに engine:name:id を指定すると、 OpenSSL エンジン名から指定した id で秘密鍵をロードします。

ファイル (1.15.10) の代わりに data:$variable を指定すると、中間ファイルを使用せずに変数から秘密鍵をロードします。この構文を不適切に使用すると、秘密鍵のデータをエラーログに書き込むなどのセキュリティ上の問題が生じる可能性があることに注意してください。

バージョン 1.15.9 以降、OpenSSL 1.0.2 以降では、ファイル名に変数を使用できるようになりました。

有効な暗号化方式を指定します。暗号化方式は、例えば OpenSSL ライブラリが理解する形式で指定します。

ssl_ciphers ALL:!aNULL:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP. 完全なリストは "openssl ciphers "コマンドで確認できます。

以前のバージョンのnginxはデフォルトで異なる暗号を使用していました。

ssl_stapling が有効な場合、クライアント証明書と OCSP レスポンスを検証するために使用される PEM 形式の信頼済み CA 証明書を含むファイルを指定します。

証明書のリストがクライアントに送られます。これを望まない場合は、ssl_trusted_certificate ディレクティブを使用することができます。

クライアント証明書の検証に使用される PEM 形式の失効した証明書 (CRL) を含むファイルを指定します。

DHE 暗号用の DH パラメータを持つファイルを指定します。

デフォルトではパラメータは設定されていないため、DHE 暗号は使用されません。

バージョン 1.11.0 より前のバージョンでは、組み込みのパラメータがデフォルトで使用されていました。

TLS 1.3 の初期データを有効または無効にします。

アーリーデータ内で送信されたリクエストはリプレイ攻撃の対象となります。アプリケーション層でこのような攻撃から保護するために、 変数 $ssl_early_data を使用しなければなりません。 proxy_set_header アーリーデータ $ssl_early_data. このディレクティブは、OpenSSL 1.1.1.1 以降 (1.15.4) と BoringSSL を使用している場合にサポートされます。

ECDHE暗号用のカーブを指定します。

OpenSSL 1.0.2以上を使用している場合、例えば1.11.0のように複数のカーブを指定することが可能です。

ssl_ecdh_curve prime256v1:secp384r1. 特別な値 auto (1.11.0) は、OpenSSL 1.0.2 以上、またはそれ以前のバージョンの prime256v1 を使用している場合に、nginx に OpenSSL ライブラリに組み込まれたリストを使用するように指示します。

バージョン 1.11.0 より前のバージョンでは、デフォルトで prime256v1 の曲線が使用されていました。

クライアント証明書チェインの OCSP 検証を有効にする。leaf パラメータはクライアント証明書の検証のみを有効にします。

OCSP の検証を有効にするには、ssl_verify_client ディレクティブを on に設定するか、オプションで設定する必要があります。

OCSP レスポンダのホスト名を解決するには、resolver ディレクティブも指定する必要があります。

Example:

 

OCSP 検証のためのクライアント証明書ステータスを格納するキャッシュの名前とサイズを設定します。キャッシュはすべてのワーカープロセスで共有されます。同じ名前のキャッシュを複数の仮想サーバーで使用することができます。

The off parameter prohibits the use of the cache.

Syntax: ssl_ocsp_responder url;

クライアント証明書の検証のための証明書拡張機能「Authority Information Access」で指定された OCSP レスポンダの URL をオーバーライドします。

http://」OCSP レスポンダのみサポートされています。

ssl_ocsp_responder http://ocsp.example.com/;

秘密鍵のパスフレーズを含むファイルを指定し、各パスフレーズを別の行で指定します。パスフレーズは、鍵の読み込み時に順番に試行されます。

Example:

SSLv3 および TLS プロトコルを使用する際に、クライアントの暗号化方式よりもサーバの暗号化方式を優先することを指定します。

指定したプロトコルを有効にします。

TLSv1.1 および TLSv1.2 パラメータ (1.1.1.13, 1.0.12) は OpenSSL 1.0.1 以降を使用している場合にのみ動作します。 TLSv1.3 パラメータ (1.13.0) は、TLSv1.3 をサポートして構築された OpenSSL 1.1.1 を使用している場合にのみ動作します。

セッションパラメータを保存するキャッシュのタイプとサイズを設定します。キャッシュは以下のタイプのいずれかになります。

off

セッションキャッシュの使用は厳密に禁止されています: nginx は明示的にクライアントにセッションを再利用してはならないと伝えています。

none

セッションキャッシュの使用は緩やかに禁止されています: nginx はクライアントにセッションを再利用することを伝えますが、実際にはセッションパラメータをキャッシュに保存しません。

builtin

OpenSSL で構築されたキャッシュで、1 つのワーカープロセスでのみ使用されます。キャッシュのサイズはセッション単位で指定します。サイズが指定されていない場合は、20480 セッションに相当します。ビルトインキャッシュを使用すると、メモリの断片化を引き起こす可能性があります。

shared

はすべてのワーカープロセス間で共有されるキャッシュです。キャッシュのサイズはバイト単位で指定され、1メガバイトで約4000セッションを保存できます。各共有キャッシュには任意の名前を付ける必要があります。同じ名前のキャッシュを複数の仮想サーバーで使用することができます。 例えば、両方のキャッシュタイプを同時に使用することができます。

ssl_session_cache builtin:1000 shared:SSL:10m. のように、組み込みキャッシュを使用せずに共有キャッシュのみを使用した方が効率が良いはずです。

TLS セッションチケットの暗号化と復号化に使われる秘密鍵をファイルに設定します。このディレクティブは複数のサーバ間で同じ鍵を共有する必要がある場合に必要です。デフォルトでは、ランダムに生成された鍵が使われます。

複数の鍵が指定された場合は、最初の鍵のみが TLS セッションチケットの暗号化に使われます。これにより、例えば鍵のローテーションを設定することができます。

ファイルには80バイトまたは48バイトのランダムデータが含まれている必要があり、以下のコマンドを使用して作成することができます。

openssl rand 80 > ticket.key ファイルサイズに応じて、暗号化には AES256 (80 バイト鍵、1.11.8) または AES128 (48 バイト鍵) を使用します。

TLS セッションチケットによるセッション再開を有効または無効にします。

サーバによる OCSP レスポンスのステープリングを有効または無効にします。例。

ssl_stapling on; resolver 192.0.2.1; OCSP ステープリングが機能するためには、サーバ証明書発行者の証明書がわかっている必要がある。ssl_certificate ファイルに中間証明書が含まれていない場合、サーバ証明書発行者の証明書が ssl_trusted_certificate ファイルに存在する必要がある。

OCSP レスポンダのホスト名を解決するためには、リゾルバ指示文も指定する。

この設定をすると、サーバ証明書で指定された OCSP レスポンダを問い合わせる代わりに、指定されたファイルからステープルされた OCSP レスポンスが取得されます。

ファイルは "openssl ocsp" コマンドで生成されたDER形式でなければなりません。

Authority Information Access" 証明書拡張子で指定された OCSP レスポンダの URL を上書きします。

http://」OCSP レスポンダのみサポートされています。

ssl_stapling_responder http://ocsp.example.com/。

サーバによる OCSP レスポンスの検証を有効または無効にします。

検証が機能するためには、サーバ証明書発行者の証明書、ルート証明書、すべての中間証明書が ssl_trusted_certificate ディレクティブを使って信頼されるように設定されている必要があります。

ssl_stapling が有効な場合、クライアント証明書と OCSP レスポンスの検証に使用される PEM 形式の信頼された CA 証明書を含むファイルを指定します。

ssl_client_certificate で設定された証明書とは対照的に、これらの証明書のリストはクライアントには送信されません。

クライアント証明書の検証を有効にします。検証結果は $ssl_client_verify 変数に格納されます。

オプションのパラメータ (0.8.7+) は、クライアント証明書を要求し、証明書が存在する場合はそれを検証します。

optional_no_ca パラメータ (1.3.8, 1.2.5) はクライアント証明書を要求しますが、信頼できる CA 証明書によって署名される必要はありません。これは、実際の証明書検証を nginx の外部サービスが行う場合に使用することを意図しています。証明書の内容は $ssl_client_cert 変数からアクセスできます。

Sets the verification depth in the client certificates chain.

Error Processing ngx_http_ssl_module モジュールは、error_page ディレクティブを使用したリダイレクトに使用できる非標準のエラーコードをいくつかサポートしています。

495 クライアント証明書の検証中にエラーが発生しました。 496 クライアントが必要な証明書を提示していない場合 497 の場合、通常のリクエストが HTTPS ポートに送信されました。 リダイレクトはリクエストが完全に解析された後に行われ、$request_uri, $uri, $args などの変数が利用可能になります。

埋め込まれた変数 ngx_http_ssl_moduleモジュールは組み込み変数をサポートしています。

$ssl_cipher

は、確立されたSSL接続に使用された暗号の名前を返します。

$ssl_ciphers

はクライアント (1.11.7) がサポートしている暗号化方式のリストを返します。既知の暗号は名前で表示され、未知の暗号は16進数で表示されます。 例：AES128-SHA:AES256-SHA:0x00ff この変数はOpenSSLバージョン1.0.2以上を使用している場合にのみ完全にサポートされます。古いバージョンでは、この変数は新しいセッションでのみ利用可能で、既知の暗号のみをリストアップします。

$ssl_client_escaped_cert

確立されたSSL接続(1.13.5)のPEM形式(urlencoded)のクライアント証明書を返します。

$ssl_client_cert

これは proxy_set_header ディレクティブで使用するためのものです。 この変数は非推奨です。代わりに $ssl_client_client_escaped_cert 変数を使うべきです。

$ssl_client_fingerprint

確立されたSSL接続(1.7.1)のクライアント証明書のSHA1フィンガープリントを返します。

$ssl_client_i_dn

は、RFC 2253 (1.11.6)に基づいて確立されたSSL接続のクライアント証明書の "発行者DN "文字列を返します。

$ssl_client_i_dn_legacy

は、確立された SSL 接続のクライアント証明書の "発行者 DN" 文字列を返します。 バージョン1.11.6以前では、変数名は$ssl_client_i_dnでした。

1.11.6以前は、変数名は$ssl_client_i_dnでした。

は、確立されたSSL接続のクライアント証明書をPEM形式で返します。

$ssl_client_sdn

は、RFC 2253 (1.11.6) に基づいて確立された SSL 接続のクライアント証明書の "サブジェクト DN" 文字列を返します。

$ssl_client_s_dn_legacy

は、確立されたSSL接続のクライアント証明書の "subject DN" 文字列を返します。 バージョン1.11.6以前では、変数名は$ssl_client_s_dnでした。

$ssl_client_serial

は、確立されたSSL接続のクライアント証明書のシリアル番号を返します。

$ssl_client_v_end

クライアント証明書の終了日(1.11.7)を返す。

$ssl_client_v_remain

クライアント証明書の有効期限が切れるまでの日数を返す(1.11.7)。

$ssl_client_v_start

クライアント証明書の開始日を返します (1.11.7)。

$ssl_client_verify

は、クライアント証明書の検証結果を返します。証明書が存在しない場合は、"SUCCESS"、"FAILED:reason"、証明書が存在しない場合は "NONE "を返します。 バージョン1.11.7より前のバージョンでは、"FAILED "の結果には理由が含まれていませんでした。

$ssl_curves

はクライアント(1.11.7)がサポートしている曲線のリストを返します。既知のカーブは名前でリストアップされ、未知のカーブは16進数で表示されます。 0x001d:prime256v1:secp521r1:secp384r1 この変数は OpenSSL バージョン 1.0.2 以降でのみサポートされています。それ以前のバージョンでは、変数の値は空の文字列になります。 この変数は新しいセッションでのみ使用可能です。

$ssl_early_data

TLS 1.3の初期データを使用しており、ハンドシェイクが完了していない場合は "1 "を返し、そうでない場合は"" (1.15.3)を返します。

$ssl_protocol

は、確立されたSSL接続のプロトコルを返します。

$ssl_server_name

SNI (1.7.0) で要求されたサーバ名を返す。

$ssl_session_id

は、確立されたSSL接続のセッション識別子を返します。

$ssl_session_reused

SSLセッションが再利用された場合は "r "を、そうでない場合は". "を返します (1.5.11)。

Module ngx_http_status_module

ngx_http_status_module モジュールは、さまざまなステータス情報へのアクセスを提供します。

このモジュールは、1.13.10 まで商用サブスクリプションの一部として利用可能でした。1.13.3 で ngx_http_api_module モジュールに取って代わられました。

設定例

この設定でのステータス要求の例

http://127.0.0.1/status http://127.0.0.1/status/nginx_version http://127.0.0.1/status/caches/cache_backend http://127.0.0.1/status/upstreams http://127.0.0.1/status/upstreams/backend http://127.0.0.1/status/upstreams/backend/peers/1 http://127.0.0.1/status/upstreams/backend/peers/1/weight http://127.0.0.1/status/stream http://127.0.0.1/status/stream/upstreams http://127.0.0.1/status/stream/upstreams/backend http://127.0.0.1/status/stream/upstreams/backend/peers/1 http://127.0.0.1/status/stream/upstreams/backend/peers/1/weight シンプルなモニタリングページはこのディストリビューションに同梱されており、デフォルトの設定では"/status.html "としてアクセスできます。上記のように "/status" と "/status.html" の場所を設定する必要があります。

記述内容

ステータス情報は周辺の場所からアクセスできるようになります。この場所へのアクセスは制限されるべきである。

デフォルトでは、ステータス情報はJSON形式で出力されます。

または、JSONPとして出力することもできます。callbackパラメータは、コールバック関数の名前を指定します。パラメータ値には変数を含めることができます。パラメータを省略した場合、または計算値が空文字列の場合は "ngx_status_jsonp_callback "が使用されます。

指定されたゾーンの仮想 http またはストリーム (1.7.11) サーバのステータス情報の収集を有効にします。複数のサーバが同じゾーンを共有することができます。

Data

以下のようなステータス情報を提供しています。

version

提供されたデータセットのバージョン。現在のバージョンは8です。

nginx_version

nginxのバージョン。

nginx_build

nginxのビルド名。

address

ステータス要求を受け付けたサーバーのアドレス。

generation

設定のリロード数の合計。

load_timestamp

エポックから最後に設定をリロードした時刻をミリ秒単位で表示しています。

timestamp

エポックからの現在時刻をミリ秒単位で表示しています。

pid

ステータス要求を処理したワーカープロセスのID。

ppid

ワーカープロセスを起動したマスタープロセスのID。

responce

異常終了してレスポーンされた子プロセスの総数。

connections
accept

受け付けたクライアント接続の総数。

drop

ドロップされたクライアント接続の総数。

active

現在のアクティブなクライアント接続数。

idle

現在のアクティブなクライアント接続の数。

SSL
handshake

成功したSSLハンドシェイクの総数。

handshakes_failed

ハンドシェイクの失敗数

session_reuses

SSLハンドシェイク中にセッションを再利用する回数の合計。

requests
total

クライアントリクエストの総数。

current

現在のクライアントリクエスト数。

server_zones

各status_zoneに対して

processing

現在処理中のクライアントリクエストの数。

requests

クライアントから受けたクライアント依頼の総数。

responses
total

クライアントに送信された回答の総数。

1xx、2xx、3xx、4xx、5xx

ステータスコードが1xx、2xx、3xx、4xx、5xxの回答数。

discarded

レスポンスを送信せずに完了したリクエストの総数。

recieved

クライアントから受信した総バイト数。

sent

クライアントに送信された総バイト数。

slabs

スラブアロケータを使用する共有メモリゾーンごとに

page
used

現在使用しているメモリページ数。

free

現在の空きメモリページ数。

slots

各メモリスロットサイズ（８、１６、３２、６４、１２８など）ごとに、以下のデータが用意されています。

used

現在使用しているメモリスロットの数。

free

現在の空きメモリスロット数。

reqs

指定したサイズのメモリを割り当てようとした回数の合計。

fails

指定したサイズのメモリの割り当てに失敗した回数。

upstream

動的に設定可能なグループごとに、以下のデータが提供されます。

pears

各サーバについては、以下のデータを提供します。

ID

サーバーのID。

server

サーバのアドレス。

name

サーバディレクティブで指定されたサーバの名前。

service

サーバディレクティブのサービスパラメータの値。

backup

サーバがバックアップサーバであるかどうかを示すブール値。

weight

サーバーの重さ。

state

現在の状態は、「上昇」、「消耗」、「下降」、「使用不能」、「チェック」、「不健康」のいずれかである可能性があります。

active

現在のアクティブな接続数。

max_conns

サーバの max_conns の制限値。

request

このサーバに転送されたクライアントリクエストの総数。

response
total

このサーバーから取得した応答の総数。

1xx、2xx、3xx、4xx、5xx

ステータスコードが1xx、2xx、3xx、4xx、および5xxの応答数。

sent

このサーバーに送信された総バイト数。

recieve

このサーバーから受信したバイト数の合計。

fails

サーバーとの通信に失敗した回数の合計。

unavail

失敗した試行の数が max_fails のしきい値に達したために、クライアントのリクエストに対してサーバが利用できなくなった回数 (状態 "unavail")

health_checks
checks

健康診断の依頼件数の合計。

fails

健康診断に失敗した回数。

unhealthy

サーバーが不健康になった回数（「不健康になった」の状態）。

last_passed

最後のヘルスチェック要求が成功し、テストに合格したかどうかを示すブール値。

downtime

サーバーが「利用できない」「チェックしている」「不健康な」状態になっていた時間の合計。

downstart

サーバーが「使用不能」「チェック中」「不健全」になった時間（エポックからのミリ秒単位）。

selected

リクエストを処理するためにサーバが最後に選択された時間(エポックからのミリ秒単位) (1.7.5)。

header_time

サーバからレスポンスヘッダを取得するまでの平均時間（1.7.10）。バージョン 1.11.6 より前のバージョンでは、このフィールドは least_time ロードバランシングメソッドを使用している場合にのみ利用可能でした。

response_time

サーバーからフルレスポンスを取得するまでの平均時間（1.7.10）。バージョン 1.11.6 より前のバージョンでは、このフィールドは least_time ロードバランシングメソッドを使用している場合にのみ利用可能でした。

keepalive

現在のアイドルキープアライブ接続数。

zombies

グループから削除されたが、まだアクティブなクライアント要求を処理しているサーバーの現在の数。

zone

グループの設定と実行時の状態を保持する共有メモリゾーンの名前です。

queue

リクエストキューについては、以下のデータを提供しています。

size

キュー内の現在のリクエスト数。

max_size

同時にキューに入ることができるリクエストの最大数。

overflows

キューのオーバーフローにより拒否されたリクエストの総数。

caches

各キャッシュ（proxy_cache_pathとLikesで設定したもの）に対して。

size

現在のキャッシュのサイズ。

max_size

設定で指定したキャッシュの最大サイズの制限。

cold

キャッシュローダー」プロセスがまだディスクからキャッシュにデータをロードしているかどうかを示すブール値。 ヒット、スタール、更新、再検証済み

responses

キャッシュから読み込まれたレスポンスの総数 (ヒットしたレスポンス、または proxy_cache_use_stale および likes による陳腐なレスポンス)。

bytes

キャッシュから読み込んだ総バイト数。 ミス、期限切れ、バイパス

responses

キャッシュから取られなかった応答の総数（proxy_cache_bypassと同類によるミス、期限切れ、バイパス）。

bytes

プロキシされたサーバから読み込まれた総バイト数。

responses_written

キャッシュに書き込まれたレスポンスの総数。 書き込まれたバイト数 キャッシュに書き込まれた総バイト数。

stream

サーバーゾーン 各status_zoneについて。

processing

現在処理中のクライアント接続数。

connections

クライアントから受け入れた接続の総数。

sessions
total

完了したクライアントセッションの総数。

2xx、4xx、5xx

ステータスコード2xx、4xx、または5xxで完了したセッション数。

discarded

セッションを作成せずに完了した接続の総数。

received

クライアントから受信した総バイト数。

sent

クライアントに送信された総バイト数。

upstreams

動的に設定可能なグループごとに、以下のデータが提供されます。

peers

各サーバについて、以下のデータを提供します。

id

サーバーのIDです。

server

サーバのアドレス。

name

サーバディレクティブで指定されたサーバの名前。

service

サーバディレクティブのサービスパラメータの値。

backup

サーバがバックアップサーバであるかどうかを示すブール値。

weight

サーバーの重さ。

state

現在の状態は、"up"、"down"、"unavail"、"checking"、または "unhealthy "のいずれかである可能性があります。

active

現在の接続数。

max_conns

サーバの max_conns の制限値。

connect_time

このサーバーに転送されたクライアント接続の総数。

connection_time

上流サーバーに接続するまでの平均時間。バージョン 1.11.6 より前のバージョンでは、このフィールドは least_time ロードバランシング方式を使用している場合にのみ使用可能でした。

first_byte_time

データの最初のバイトを受信する平均時間。バージョン 1.11.6 より前のバージョンでは、このフィールドは least_time ロードバランシング方式を使用している場合にのみ利用可能でした。

response_time

データの最後のバイトを受信する平均時間。バージョン 1.11.6 より前のバージョンでは、このフィールドは least_time ロードバランシングメソッドを使用している場合にのみ利用可能でした。

sent

このサーバーに送信された総バイト数。

received

このサーバーから受信したバイト数の合計。

fails

サーバーとの通信に失敗した回数の合計。

unavail

失敗した試行回数が max_fails しきい値に達したために、サーバーがクライアント接続で利用できなくなった回数 (状態 "unavail")。

health_check
checks

ヘルスチェックのリクエスト数の合計。

fails

health_check に失敗した回数。

unhealthy

サーバーが不健康になった回数（「不健康」の状態）。

last_passed

最後のヘルスチェック要求が成功し、テストに合格したかどうかを示すブール値。

downtime

サーバーが「使用不能」、「チェック中」、「不健康」の状態になっていた時間の合計。

downstart

サーバーが「使用不能」「チェック中」「不健全」になった時間（エポックからのミリ秒単位）。

selected

サーバーが最後に接続を処理するために選択された時間（エポックからのミリ秒単位）。

zombies

グループから削除されたが、アクティブなクライアント接続を処理しているサーバーの現在の数。

zone

グループの設定と実行時の状態を保持する共有メモリゾーンの名前です。

互換性 バージョン8で、httpとストリームアップストリームのゾーンフィールドを追加しました。 バージョン8で、スラブの状態データを追加しました。 バージョン8で、チェック状態を追加した。 バージョン 8 で、http とストリームアップストリームの name と service フィールドを追加した。 バージョン 8 で nginx_build と ppid フィールドを追加しました。 バージョン 7 で、ストリーム server_zones のセッションステータスデータと廃棄フィールドが追加されました。 バージョン 6 でゾンビフィールドを nginx デバッグバージョンから移動しました。 バージョン6で、sslのステータスデータを追加しました。 バージョン6で、server_zonesのdiscardedフィールドを追加した。 バージョン6でキューのステータスデータを追加した。 バージョン6にpidフィールドを追加した。 バージョン6で、アップストリームのサーバリストをピアに移動した。 バージョン 5 で、上流サーバの keepalive フィールドを削除した。 バージョン 5 でストリームステータスデータを追加した。 バージョン5で生成フィールドを追加した。 バージョン 5 でプロセスの respawned フィールドを追加した。 バージョン 5 でアップストリームの header_time と response_time フィールドが追加された。 バージョン4でアップストリームのselectedフィールドが追加された。 バージョン4で、アップストリームのドレイン状態が追加された。 バージョン 3 でアップストリームの id と max_conns フィールドが追加された。 バージョン 3 でキャッシュの revalidated フィールドが追加された。 バージョン 2 で server_zones, caches, load_timestamp ステータスデータが追加されました。.

Module ngx_http_stub_status_module

ngx_http_stub_status_module は、基本的なステータス情報へのアクセスを提供します。

このモジュールはデフォルトではビルドされていないので、 --with-http_stub_status_module 設定パラメータで有効にしなければなりません。

設定例

この設定では、以下のような基本的なステータスデータを持つシンプルなWebページが作成されます。

アクティブな接続。291 サーバは処理された要求を受け付ける 16630948 16630948 31070465 読むこと。ライティング：6 179 ウェイティング 106

記述内容

基本的なステータス情報は、周囲の場所からアクセスできるようになります。

1.7.5以前のバージョンでは、ディレクティブの構文は任意の引数、例えば "stub_status on "を必要としていました。 データ 以下のようなステータス情報を提供しています。

アクティブな接続

待機中の接続を含む、現在のアクティブなクライアント接続数。 を受け入れます。 受け付けたクライアント接続の総数。 処理された 処理された接続の総数。一般的に、リソースの制限 (たとえば worker_connections の制限) に達していない限り、パラメータの値は accepts と同じです。

requests

クライアントリクエストの総数。

nginx がリクエストヘッダを読み込んでいる現在の接続数。

Writing

nginx がクライアントにレスポンスを書き戻している現在の接続数。

Waiting

リクエストを待っているアイドルクライアント接続の現在の数。 埋め込み変数 ngx_http_stub_status_moduleモジュールは、以下の組み込み変数をサポートしています (1.3.14)。

接続がアクティブな場合 アクティブな接続の値と同じです。 の値と同じです。 Readingの値と同じです。 の値と同じです。 書き込み値と同じです。 の値と同じです。 待機中の値と同じです。

Module ngx_http_sub_module

ngx_http_sub_module は、指定した文字列を別の文字列に置き換えることでレスポンスを変更するフィルタです。

このモジュールはデフォルトではビルドされていないので、 --with-http_sub_module 設定パラメータで有効にしなければなりません。

設定例

記述内容

置換する文字列と置換文字列を設定します。置換する文字列は、大文字小文字を無視してマッチします。置換する文字列 (1.9.4) と置換文字列には、変数を含めることができます。1 つの構成レベル (1.9.4) で複数の sub_filter ディレクティブを指定できます。これらのディレクティブは、現在のレベルで定義されている sub_filter ディレクティブがない場合にのみ、前のレベルから継承されます。

このディレクティブはバージョン 1.5.1 で登場しました。

レスポンスのキャッシュを容易にするために、元のレスポンスの "Last-Modified" ヘッダフィールドを 置換時に保存することを許可します。

デフォルトでは、処理中にレスポンスの内容が変更されるとヘッダフィールドは削除されます。

置換する文字列を一度だけ探すか、繰り返し探すかを指定します。

レスポンスで「text/html」に加えて、指定されたMIMEタイプでの文字列置換を有効にします。特別な値 "*" は任意の MIME タイプにマッチします (0.8.29)。

Module ngx_http_upstream_module

埋め込み変数

ngx_http_upstream_module モジュールは、proxy_pass、fastcgi_pass、uwsgi_pass、scgi_pass、memcached_pass、および grpc_pass 記述内容によって参照可能なサーバのグループを定義するために使用されます。

設定例

定期的なヘルスチェックを備えた動的に構成可能なグループは、当社の商用サブスクリプションの一部としてご利用いただけます。

resolver 10.0.0.1;

記述内容

サーバーのグループを定義します。サーバは異なるポートでリッスンすることができます。さらに、TCPとUNIXドメインのソケットをリッスンするサーバを混在させることができます。

Example:

デフォルトでは、リクエストは加重ラウンドロビン分散方式を使用してサーバ間で分散されます。上記の例では、7つのリクエストは以下のように分散されます。5つのリクエストはbackend1.example.comに行き、2番目と3番目のサーバーにそれぞれ1つのリクエストを行います。サーバとの通信中にエラーが発生した場合は、そのリクエストを次のサーバに渡すなどして、すべてのサーバが動作するまで試行します。いずれのサーバからも成功した応答が得られなかった場合、クライアントは最後のサーバとの通信結果を受け取る。

サーバのアドレスとその他のパラメータを定義する。アドレスは、ドメイン名またはIPアドレス、オプションのポート、または "unix: "接頭辞の後に指定されるUNIXドメインのソケットパスとして指定することができる。ポートを指定しない場合は、80番ポートが使用される。複数のIPアドレスに解決するドメイン名は、一度に複数のサーバを定義する。

以下のパラメータを定義することができます。

プロキシされたサーバへの同時アクティブ接続の最大数を制限します (1.11.5)。デフォルト値はゼロで、制限はありません。サーバーグループが共有メモリに存在しない場合、制限は各ワーカープロセスごとに機能します。 アイドル状態のキープアライブ接続、複数のワーカー、共有メモリが有効になっている場合、プロキシ先サーバへのアクティブ接続とアイドル接続の合計数がmax_conns値を超える可能性があります。 バージョン 1.5.9 およびそれ以前のバージョン 1.11.5 から、このパラメータは商用サブスクリプションの一部として利用可能になりました。

max_fails=number

は、fail_timeout パラメータで設定された持続時間内にサーバーとの通信に失敗した試行回数を設定します。デフォルトでは、失敗した試行の数は1に設定されています。 ゼロの値は試行の会計を無効にします。何が失敗したとみなされるかは、proxy_next_upstream、fastcgi_next_upstream、uwsgi_next_upstream、scgi_next_upstream、memcached_next_upstream、および grpc_next_upstream 記述内容によって定義されます。

fail_timeout=time
sets

指定された回数のサーバーとの通信に失敗した場合に、サーバーが利用できないと判断されるまでの時間。 サーバーが利用できないとみなされる期間。 デフォルトでは、このパラメータは10秒に設定されています。

backup

は、そのサーバをバックアップサーバとしてマークします。プライマリサーバが利用できない場合にリクエストが渡されます。 このパラメータは、ハッシュ、ip_hash、ランダムロードバランシングのメソッドと一緒に使用することはできません。

down

は、サーバーを恒久的に利用できない状態にします。 さらに、以下のパラメータは、当社の商用サブスクリプションの一部として利用可能です。

resolve

は、サーバのドメイン名に対応するIPアドレスの変更を監視し、nginx(1.5.12)を再起動することなく、上流側の設定を自動的に変更します。サーバグループは共有メモリに存在する必要があります。 このパラメータを動作させるためには、http ブロックまたは対応するアップストリームブロックでリゾルバディレクティブを指定しなければなりません。

route=string sets the server route name. service=name

DNS SRV レコードの解決を有効にし、サービス名を設定します (1.9.13)。このパラメータを動作させるためには、サーバの resolve パラメータを指定し、ポート番号を含まないホスト名を指定する必要があります。 サービス名にドット(".")が含まれていない場合は、RFC準拠の名前が構築され、サービスのプレフィックスにTCPプロトコルが追加されます。例えば、http.tcp.backend.example.comのSRVレコードを調べるには、ディレクティブを指定する必要があります。

server backend.example.com service=http resolve.

サービス名に1つ以上のドットが含まれている場合、サービス名はサービスプレフィックスとサーバー名を結合して作成されます。例えば、http.tcp.backend.example.comとserver1.backend.example.comのSRVレコードを検索するには、記述内容を指定する必要があります。

server backend.example.com service=http.tcp resolve. server example.com service=server1.backend resolve. 優先度の高いSRVレコード（同じ最下位の優先度値を持つレコード）はプライマリサーバとして解決され、それ以外のSRVレコードはバックアップサーバとして解決されます。サーバにbackupパラメータが指定されている場合、優先度の高いSRVレコードはバックアップサーバとして解決され、残りのSRVレコードは無視されます。

slow_start=time

は、不健康なサーバーが健康になったとき、または利用できないと考えられていた期間の後にサーバーが利用可能になったときに、サーバーがゼロから公称値に回復する時間を設定します。デフォルト値はゼロで、スロースタートは無効になっています。 このパラメータは、ハッシュ、ip_hash、およびランダムな負荷分散方法と一緒に使用することはできません。

drain

はサーバを "draining" モード (1.13.6) にします。このモードでは、サーバにバインドされたリクエストのみがサーバにプロキシされます。 バージョン 1.13.6 より前のバージョンでは、API モジュールでのみパラメータを変更することができました。 グループ内に単一のサーバーしかない場合、max_fails、fail_timeout、slow_start パラメータは無視され、そのようなサーバーは決して利用できないとは考えられません。

ワーカープロセス間で共有されるグループの設定とランタイム状態を保持する共有メモリゾーンの名前とサイズを定義します。複数のグループが同じゾーンを共有することがあります。この場合、サイズは一度だけ指定すれば十分です。

さらに、商用サブスクリプションの一部として、このようなグループは nginx を再起動することなく、グループのメンバーシップを変更したり、特定のサーバーの設定を変更したりすることができます。設定は API モジュール (1.13.3) からアクセスできます。

バージョン 1.13.3 より前のバージョンでは、設定は upstream_conf が扱う特別な場所からしかアクセスできませんでしたが、バージョン 1.13.3 より前のバージョンでは、設定は upstream_conf が扱う特別な場所からしかアクセスできませんでした。

動的に構成可能なグループの状態を保持するファイルを指定します。

Examples:

state /var/lib/nginx/state/servers.conf; # path for Linux state /var/db/nginx/state/servers.conf; # path for FreeBSD

現在の状態は、パラメータを持つサーバーのリストに限定されています。ファイルは設定を解析する際に読み込まれ、上流の設定が変更されるたびに更新されます。ファイルの内容を直接変更することは避けるべきです。このディレクティブはサーバディレクティブと一緒に使うことはできません。

設定のリロードやバイナリのアップグレード中に行われた変更は失われる可能性があります。 このディレクティブは商用の購読の一部として利用できます。

クライアントとサーバーのマッピングがハッシュ化されたキー値に基づいて行われるサーバーグループのロードバランシング方法を指定します。キーには、テキスト、変数、およびそれらの組み合わせを含めることができます。グループからサーバを追加または削除すると、キーの大部分が異なるサーバにリマッピングされる可能性があることに注意してください。このメソッドは、Cache::Memcached Perl ライブラリと互換性があります。

一貫性パラメータを指定すると、代わりに ketama 一貫性ハッシュ・メソッドが使用されます。このメソッドは、サーバがグループに追加されたり、グループから削除されたりしたときに、少数のキーのみが異なるサーバにリマップされるようにします。これにより、キャッシュサーバのキャッシュヒット率を高めることができます。このメソッドは、ketama_points パラメータを 160 に設定した Cache::Memcached::Fast Perl ライブラリと互換性があります。

クライアントIPアドレスに基づいてサーバー間でリクエストを分散させるロードバランシング方法をグループで使用することを指定します。クライアントの IPv4 アドレスの最初の 3 オクテット、または IPv6 アドレス全体がハッシュキーとして使用されます。この方法により、同じクライアントからのリクエストは、このサーバが利用できない場合を除き、常に同じサーバに渡されます。後者の場合、クライアントのリクエストは別のサーバに渡されます。ほとんどの場合、同じサーバが常に同じサーバであることになります。

IPv6 アドレスはバージョン 1.3.2 および 1.2.2 からサポートされています。 サーバを一時的に削除する必要がある場合は、クライアントIPアドレスの現在のハッシュを維持するために、 downパラメータを付けなければなりません。

Example:

バージョン1.3.1、1.2.2までは、ip_hashの負荷分散方式を利用したサーバの重み指定ができませんでしたが、バージョン1.3.1、1.2.2では、負荷分散方式を利用したサーバの重み指定が可能になりました。

アップストリーム サーバーへの接続のキャッシュを有効にします。

connections パラメータは、各ワーカープロセスのキャッシュに保存されるアップストリームサーバーへのアイドルキープアライブ接続の最大数を設定します。この数を超えると、最近使用されたコネクションは閉じられます。

keepalive ディレクティブは、nginx ワーカープロセスが開くことができるアップストリームサーバへの接続の総数を制限するものではないことに注意してください。connections パラメータは、アップストリームサーバが新しい接続を処理できるように十分小さい値に設定する必要があります。 keepalive接続を持つmemcachedアップストリームの設定例。

HTTP の場合、proxy_http_version ディレクティブを "1.1" に設定し、"Connection" ヘッダフィールドをクリアする必要があります。

別の方法として、HTTP/1.0 の持続的接続を使用するには、"Connection. Keep-Alive" ヘッダーフィールドをアップストリームサーバーに渡すことで、HTTP/1.0 の持続的接続を使用することができますが、この方法は推奨されていません。 FastCGI サーバーの場合、キープアライブ接続を動作させるには fastcgi_keep_conn を設定する必要があります。

デフォルトのラウンドロビン方式以外のロードバランサ方式を使用する場合は、 keepalive ディレクティブの前にそれらを有効にする必要があります。 SCGI と uwsgi プロトコルには keepalive 接続の概念がありません。

1 つの keepalive 接続で提供できるリクエストの最大数を設定します。最大数のリクエストが行われた後、接続は閉じられます。

定期的に接続を閉じることは、接続ごとのメモリ割り当てを解放するために必要です。そのため、高すぎる最大リクエスト数を使用すると、過剰なメモリ使用になる可能性があり、お勧めできません。

上流サーバーへのアイドル状態のキープアライブ接続が開いたままになるタイムアウトを設定します。

NTLM 認証を用いたリクエストのプロキシを許可する。クライアントが "Negotiate" または "NTLM" で始まるヘッダフィールド値 "Authorization" を持つリクエストを送信すると、アップストリーム接続はクライアント接続にバインドされる。それ以降のクライアントからのリクエストは、認証コンテキストを保持したまま、同じアップストリーム接続を経由してプロキシされる。

NTLM 認証を動作させるためには、アップストリームサーバとの keepalive 接続を有効にする必要があります。proxy_http_version ディレクティブを "1.1" に設定し、"Connection" ヘッダフィールドをクリアしなければならない。

デフォルトのラウンドロビン方式以外のロードバランサ方式を使用する場合は、 ntlm ディレクティブの前にそれらを有効化する必要があります。 このディレクティブは商用サブスクリプションの一部として利用できます。

グループが、サーバーの重みを考慮して、アクティブな接続数が最も少ないサーバーにリクエストを渡す負荷分散方法を使用することを指定します。このようなサーバーが複数ある場合は、重み付きラウンドロビン分散方式を使って順番に試されます。

グループが、サーバーの重みを考慮して、平均応答時間とアクティブな接続数が最小の サーバーにリクエストを渡す負荷分散方法を使用することを指定します。このようなサーバーが複数ある場合は、重み付きラウンドロビンバランシング法を 使用して順番に試行される。

headerパラメータが指定された場合、応答ヘッダを受信するまでの時間が使用されます。last_byte パラメータが指定された場合は、フルレスポンスを受信するまでの時間を使用する。機内パラメータが指定された場合(1.11.6)、不完全なリクエストも考慮されます。

バージョン 1.11.6 より前のバージョンでは、不完全なリクエストも考慮されます。 このディレクティブは商用サービスの一部として提供されています。

リクエストの処理中にアップストリームサーバがすぐに選択できなかった場合、 リクエストはキューに入れられます。このディレクティブは、同時にキューに入れることができる最大数を指定します。キューが一杯になった場合や、timeout パラメータで指定した時間内にリクエストを渡すサーバが選択できなかった場合は、502 (Bad Gateway) エラーがクライアントに返されます。

timeoutパラメータのデフォルト値は60秒です。

デフォルトのラウンドロビン方式以外のロードバランサ方式を使用する場合は、 queue ディレクティブの前にそれらを有効にする必要があります。 このディレクティブは商用サービスの一部として提供されています。

グループがサーバーの重みを考慮してランダムに選択されたサーバーにリクエストを渡すロードバランシング方法を使用することを指定します。

オプションの 2 パラメータは nginx に 2 台のサーバーをランダムに選択し、指定された方法でサーバーを選択するように指示します。デフォルトのメソッドは least_conn で、アクティブな接続数が最も少ないサーバーにリクエストを渡します。

least_time メソッドは、平均応答時間とアクティブな接続数が最も少ないサーバーにリクエストを渡します。least_time=headerが指定された場合は、応答ヘッダを受信するまでの時間が使用されます。least_time=last_byte が指定された場合、完全なレスポンスを受信する時間が使用されます。

least_time メソッドは、当社の商用サブスクリプションの一部として利用できます。

アップストリームサーバの名前をアドレスなどに解決するために使用するネームサーバを設定します。

resolver 127.0.0.1 [::1]:5353;

アドレスはドメイン名またはIPアドレスとして指定でき、オプションでポートを指定することができます。ポートが指定されていない場合は、53番ポートが使用されます。ネームサーバはラウンドロビン方式で問い合わせを行います。

デフォルトでは、nginx は IPv4 と IPv6 の両方のアドレスを検索して解決します。IPv6 アドレスを検索したくない場合は、ipv6=off パラメータを指定することができます。

デフォルトでは、nginx は応答の TTL 値を使って回答をキャッシュします。オプションの有効なパラメータを指定することで、これを上書きすることができます。

resolver 127.0.0.0.1 [::1]:5353 valid=30s. DNSスプーフィングを防ぐには、適切に保護された信頼できるローカルネットワークでDNSサーバーを構成することをお勧めします。 オプションの status_zone パラメータは、指定されたゾーンでのリクエストとレスポンスの DNS サーバの統計情報を収集することを可能にします。

このディレクティブは商用の購読の一部として利用できます。

名前解決のタイムアウトを設定します。

This directive is available as part of our commercial subscription.

セッションアフィニティを有効にします。これにより、同じクライアントからのリクエストが、サーバーのグループ内の同じサーバーに渡されるようになります。3つの方法があります。

クッキー クッキー方式を使用した場合、指定されたサーバの情報はnginxが生成するHTTPクッキーに渡されます。

特定のサーバーにまだバインドされていないクライアントから来るリクエストは、設定されたバランシング方法で選択されたサーバーに渡されます。このクッキーを使った更なるリクエストは指定されたサーバーに渡されます。指定されたサーバがリクエストを処理できない場合、クライアントがまだバインドされていないかのように新しいサーバが選択されます。

最初のパラメータは、設定または検査するクッキーの名前を設定します。クッキーの値は、IPアドレスとポート、またはUNIXドメインのソケットパスのMD5ハッシュを16進数で表したものである。ただし、サーバディレクティブの "route" パラメータが指定されている場合は、クッキーの値は "route" パラメータの値になります。

この場合、"srv_id "クッキーの値はaかbのどちらかになります。

追加のパラメータは以下のようにしてもよい。

expires=time ブラウザがクッキーを保持する時間を設定します。特別な値 max を指定すると、クッキーは "31 Dec 2037 23:55:55:55 GMT" で期限切れになります。パラメータが指定されていない場合は、ブラウザセッションの終了時にクッキーの有効期限が切れます。

domain=domain クッキーが設定されるドメインを定義します。パラメータ値は変数を含むことができます(1.11.5)。

httponly HttpOnly 属性をクッキーに追加しました (1.7.11)。

secure クッキーにSecure属性を追加します(1.7.11)。

path=path クッキーが設定されるパスを定義します。 パラメータが省略された場合、対応するクッキーのフィールドは設定されません。

route routeメソッドが使用されている場合、proxiedサーバは最初のリクエストの受信時に クライアントにルートを割り当てる。このクライアントからのそれ以降のすべてのリクエストは、クッキーか URI でルーティング情報を保持します。この情報は、リクエストがプロキシされるべきサーバを特定するために、 server ディレクティブの "route" パラメータと比較されます。route" パラメータが指定されていない場合、ルート名は IP アドレスとポート、あるいは UNIX ドメインのソケットパスの MD5 ハッシュを 16 進数で表したものになります。指定されたサーバーがリクエストを処理できない場合、リクエストにルーティング情報が ない場合と同様に、設定されたバランシング方法で新しいサーバーが選択される。

routeメソッドのパラメータは、ルーティング情報を含む可能性のある変数を指定します。最初の空でない変数は、マッチするサーバを見つけるために使用されます。

Example:

ここでは、リクエストに「JSESSIONID」クッキーが存在する場合、ルートは 「JSESSIONID」クッキーから取得される。そうでなければ、URIからのルートが使われる。

学ぶ 学習メソッド(1.7.1)を使用すると、nginxは上流のサーバのレスポンスを解析し、通常はHTTPクッキーで渡されるサーバ主導のセッションを学習します。

この例では、アップストリームサーバはレスポンスに「EXAMPLECOOKIE」というクッキーを設定してセッションを作成しています。このクッキーを持つ更なるリクエストは、同じサーバーに渡されます。サーバがリクエストを処理できない場合、クライアントがまだバインドされていないかのように、新しいサーバが選択されます。

createとlookupというパラメータは、それぞれ新しいセッションがどのように作成され、 既存のセッションがどのように検索されるかを示す変数を指定します。両方のパラメータを複数回指定することができ、その場合は最初の空でない変数が使用されます。

セッションは共有メモリゾーンに保存され、その名前とサイズはゾーンパラメータで設定されます。64ビットプラットフォームでは、1メガバイトのゾーンに約4000のセッションを格納できます。timeoutパラメータで指定した時間内にアクセスされなかったセッションは、ゾーンから削除されます。デフォルトでは、タイムアウトは10分に設定されています。

headerパラメータ(1.13.1)では、アップストリームサーバーから応答ヘッダーを受信した直後にセッションを作成することができます。

sync パラメータ (1.13.8) は共有メモリゾーンの同期を可能にします。

このディレクティブは商用サブスクリプションの一部として利用できます。

このディレクティブはバージョン 1.5.7 以降では廃止されています。代わりに、新しい構文を持つ同等のstickyディレクティブを使うべきです。

スティッキークッキー名 [expires=time] [domain=domain] [path=path]。 埋め込み変数 ngx_http_upstream_moduleモジュールは、以下の組み込み変数をサポートしています。

$upstream_addr

は、IP アドレスとポート、またはアップストリームサーバの UNIX ドメインソケットへのパスを保持します。リクエスト処理中に複数のサーバから連絡があった場合、それらのアドレスはカンマで区切られます。X-Accel-Redirect "やerror_pageによって、あるサーバグループから別のサーバグループへの内部リダイレクトが発生した場合、異なるグループのサーバアドレスはコロンで区切られます。サーバを選択できなかった場合、変数はサーバグループの名前を保持します。

$upstream_bytes_received

アップストリームサーバから受信したバイト数 (1.11.4)。複数の接続からの値は、変数 $upstream_addr のアドレスのようにカンマとコロンで区切られています。

$upstream_bytes_sent

アップストリームサーバに送信されたバイト数 (1.15.8)。複数の接続からの値は、変数 $upstream_addr のアドレスのようにカンマとコロンで区切られています。

$upstream_cache_status

レスポンスキャッシュ(0.8.3)へのアクセスのステータスを保持します。ステータスは、"MISS"、"BYPASS"、"EXPIRED"、"STALE"、"UPDATING"、"REVALIDATED"、"HIT "のいずれかです。

$upstream_connect_time

アップストリームサーバ(1.9.1)との接続確立に要した時間を保持します。SSLの場合は、ハンドシェイクにかかった時間も含みます。複数の接続の時間は、変数 $upstream_addr のアドレスのようにカンマとコロンで区切っています。

$upstream_cookie_name

のレスポンスヘッダフィールド「Set-Cookie」で、上流サーバから送信された指定された名前のクッキー（1.7.1）を保存します。最後のサーバのレスポンスのクッキーのみが保存されます。

$upstream_header_time

は、アップストリームサーバ (1.7.10) からのレスポンスヘッダの受信にかかった時間を保持します。複数のレスポンスの時間は、変数 $upstream_addr のアドレスのようにカンマとコロンで区切られています。

$upstream_http_name

サーバのレスポンスヘッダフィールドを保持します。例えば、"Server" レスポンスヘッダーフィールドは、$upstream_http_server 変数を通して利用できます。ヘッダーフィールド名を変数名に変換するルールは、接頭辞「$http_」で始まる変数の場合と同じです。最後のサーバのレスポンスのヘッダフィールドだけが保存されます。

$upstream_queue_time

は、リクエストがアップストリームキュー (1.13.9) で使用した時間を保持します。複数のレスポンスの時間は、変数 $upstream_addr のアドレスのようにカンマとコロンで区切られています。

$upstream_response_length

はアップストリームサーバ (0.7.27) から取得したレスポンスの長さを保持します。複数のレスポンスの長さは、$upstream_addr 変数のアドレスのようにカンマとコロンで区切られています。

$upstream_response_time

は、アップストリームサーバからのレスポンスを受信するのにかかった時間を保持します。複数のレスポンスの時間は、変数 $upstream_addr のアドレスのようにカンマとコロンで区切られています。

$upstream_status

は、アップストリームサーバから取得したレスポンスのステータスコードを保持します。複数のレスポンスのステータスコードは、$upstream_addr変数のアドレスのようにカンマとコロンで区切られています。サーバを選択できなかった場合、変数は 502 (Bad Gateway) ステータスコード。 アップストリーム・トレイラー名 は、アップストリームサーバ(1.13.10)から取得したレスポンスの末尾のフィールドを保持します。

Module ngx_http_upstream_conf_module

ngx_http_upstream_conf_module モジュールを使用すると、nginx を再起動することなく、シンプルな HTTP インターフェースを介してアップストリームサーバグループをその場で設定することができます。http サーバグループまたはストリームサーバグループは共有メモリに存在しなければなりません。

このモジュールは 1.13.10 まで商用サブスクリプションの一部として提供されていました。1.13.3 で ngx_http_api_module モジュールに取って代わられました。

設定例

記述内容

周囲の場所のアップストリーム構成のHTTPインターフェイスをオンにします。この場所へのアクセスを制限する必要があります。

設定コマンドを使用することができます。

グループ構成を表示します。 サーバーを表示、変更、または削除します。 新しいサーバの追加。 グループ内のアドレスは一意である必要はないので、グループ内の特定のサーバーはそのIDで参照されます。ID は自動的に割り当てられ、新しいサーバーを追加するとき、またはグループ構成を表示するときに表示されます。 設定コマンドは、例えば、リクエスト引数として渡されたパラメータで構成されています。

http://127.0.0.1/upstream_conf?upstream=backend The following parameters are supported:

stream=

ストリームのアップストリーム・サーバ・グループを選択します。このパラメータを指定しない場合は、http アップストリームサーバグループを選択します。

upstream=name

一緒に作業するグループを選択します。このパラメータは必須です。

id=数字

閲覧、修正、削除するサーバーを選択します。

remove=削除

グループからサーバーを削除します。

add=

新しいサーバーをグループに追加します。

backup=

バックアップサーバーの追加が必要です。 バージョン1.7.2以前では、既存のバックアップサーバを表示、変更、削除するには、backup=も必要でした。

server=address

httpまたはストリームアップストリームサーバの「address」パラメータと同じです。 サーバを追加する際に、ドメイン名として指定することも可能です。この場合、ドメイン名に対応するIPアドレスの変更を監視し、nginx(1.7.2)を再起動することなく、アップストリームの設定に自動的に適用されます。このためには、http またはストリームブロックの "resolver" ディレクティブが必要です。http またはストリームアップストリームサーバの "resolve" パラメータも参照してください。

サービス名

http またはストリームアップストリームサーバ (1.9.13) の "service" パラメータと同じ。

weight=数

http またはストリームアップストリームサーバの "weight" パラメータと同じ。

max_conns=数

http またはストリームアップストリームサーバの "max_conns" パラメータと同じ。

max_fails=数

http またはストリームアップストリームサーバの "max_fails" パラメータと同じ。

fail_timeout=time

httpまたはストリームアップストリームサーバの "fail_timeout "パラメータと同じ。

slow_start=time

http またはストリームアップストリームサーバの "slow_start" パラメータと同じ。

down=

httpまたはストリームアップストリームサーバの "down "パラメータと同じ。

drain=

http アップストリームサーバを "draining" モード (1.7.5) にします。このモードでは、サーバにバインドされたリクエストのみが プロキシされます。

u6p= http またはストリームアップストリームサーバの "down" パラメータの反対。

route=string

httpアップストリームサーバの "route "パラメータと同じです。 最初の三つのパラメータはオブジェクトを選択します。これは、http またはストリームアップストリームサーバグループ全体か、 特定のサーバのどちらかになります。他のパラメータがない場合は、選択されたグループまたはサーバの設定が表示されます。

例えば、グループ全体の設定を表示するには、次のように送信します。

http://127.0.0.1/upstream_conf?upstream=backend 特定のサーバーの設定を表示するには、そのサーバーのIDも指定します。

http://127.0.0.1/upstream_conf?upstream=backend&id=42 新しいサーバを追加するには、"server=" パラメータにそのアドレスを指定します。他のパラメータを指定しないと、サーバは他のパラメータをデフォルト値に設定して 追加されます (http やストリームの "server" ディレクティブを参照してください)。

例えば、新しいプライマリサーバを追加するには、以下のように送信します。

http://127.0.0.1/upstream_conf?add=&upstream=backend&server=127.0.0.1:8080 新しいバックアップサーバーを追加するには、送信します。

例えば、新しいプライマリサーバを追加するには、次のように送信します。

http://127.0.0.1/upstream_conf?add=&upstream=backend&server=127.0.0.1:8080 新しいバックアップサーバーを追加するには、次のように送信します。

http://127.0.0.1/upstream_conf?add=&upstream=backend&backup=&server=127.0.0.1:8080 新しいプライマリサーバを追加するには、そのパラメータをデフォルト以外の値に設定し、「down」とマークして送信します。

http://127.0.0.1/upstream_conf?add=&upstream=backend&server=127.0.0.1:8080&weight=2&down= サーバーを削除するには、そのサーバーのIDを指定します。

http://127.0.0.1/upstream_conf?remove=&upstream=backend&id=42 既存のサーバーを「ダウン」にするには、次のように送信します。

http://127.0.0.1/upstream_conf?upstream=backend&id=42&down= 既存のサーバーのアドレスを変更するには、次のように送信します。

http://127.0.0.1/upstream_conf?upstream=backend&id=42&server=192.0.2.3:8123 既存のサーバーの他のパラメータを変更するには、送信します。

http://127.0.0.1/upstream_conf?upstream=backend&id=42&max_fails=3&weight=4 上記の例は、httpアップストリームサーバグループの例です。ストリームアップストリームサーバグループの同様の例は、"stream=" パラメータを必要とします。

Module ngx_http_upstream_hc_module

ngx_http_upstream_hc_moduleモジュールを使用すると、周囲の場所で参照されているグループ内のサーバの定期的なヘルスチェックが可能になります。サーバグループは共有メモリ内に存在する必要があります。

ヘルスチェックに失敗した場合、そのサーバは不健康とみなされます。同じグループのサーバに対して複数のヘルスチェックが定義されている場合、いずれかのチェックが一度でも失敗すると、対応するサーバは不健康とみなされます。クライアントのリクエストは、不健康なサーバや「チェック中」の状態のサーバには渡されません。

ヘルスチェックで使用する場合、ほとんどの変数は空の値を持つことに注意してください。 このモジュールは商用サブスクリプションの一部として提供されています。

設定例

この設定では、nginx はバックエンドグループ内の各サーバに 5 秒ごとに "/" リクエストを送信します。通信エラーやタイムアウトが発生したり、プロキシされたサーバが 2xx や 3xx 以外のステータスコードで応答した場合、ヘルスチェックは失敗し、そのサーバは不健康であるとみなされます。

ヘルスチェックは応答のステータスコード、特定のヘッダフィールドとその値の存在、 ボディの内容をテストするように設定することができます。テストは match ディレクティブを使って個別に設定され、 health_check ディレクティブの match パラメータで参照されます。

この設定は、ヘルスチェックが通過するためには、ヘルスチェックリクエストに対するレスポンスが成功し、ステータスが200で、本文に "Welcome to nginx!"が含まれている必要があることを示しています。

記述内容

周囲の場所で参照されるグループ内のサーバーの定期的なヘルスチェックを有効にします。

以下のオプションのパラメータがサポートされています。

interval=time

は、2 つの連続したヘルスチェックの間隔を設定します。

jitter=time

は、各ヘルスチェックがランダムに遅延する時間を設定します。

fails=number

特定のサーバのヘルスチェックに連続して失敗した回数を設定します。

passes=number

は、特定のサーバのヘルスチェックに連続して合格した回数を設定します。

uri=uri

は、ヘルスチェックリクエストで使用されるURIを定義します。

mandatory

は、最初のヘルスチェックが完了するまでの間、サーバの最初の「チェック」状態を設定します (1.11.7)。クライアントリクエストは、「検査中」状態のサーバーには渡されません。パラメータが指定されていない場合、サーバーは最初に健康であるとみなされます。

match=name

は、ヘルスチェックが通過するためにレスポンスが通過すべきテストを構成するマッチブロックを指定します。デフォルトでは、レスポンスはステータスコード 2xx または 3xx でなければなりません。

port=number

は、ヘルスチェックを実行するためにサーバに接続する際に使用するポートを定義します (1.9.7)。既定では、サーバのポートに等しくなります。

ヘルスチェック要求に対する応答の検証に使用する名前付きテストセットを定義します。

レスポンスでテストできる項目は以下のとおりです。

は、すべての指定された変数が空ではなく、"0" (1.15.9) に等しくないことを意味します。 複数のテストが指定されている場合、レスポンスはすべてのテストにマッチする場合にのみマッチします。

Only the first 256k of the response body are examined. Examples:

Module ngx_http_userid_module

ngx_http_userid_moduleモジュールは、クライアントの識別に適したクッキーを設定します。受信したクッキーと設定したクッキーは、埋め込み変数 $uid_got と $uid_set を使って記録することができます。このモジュールは Apache の mod_uid モジュールと互換性があります。

設定例

記述内容

クッキーの設定と受信したクッキーの記録を有効または無効にします。

on

バージョン2のクッキーの設定と受信したクッキーのロギングを有効にします。

v1

バージョン1のクッキーの設定と受信したクッキーのログを有効にします。

log

はクッキーの設定を無効にしますが、受信したクッキーのロギングを有効にします。

off

クッキーの設定と受信したクッキーのログを無効にします。

クッキーが設定されるドメインを定義します。none パラメータはクッキーのドメインの設定を無効にします。

ブラウザがクッキーを保持する時間を設定します。パラメータ max はクッキーの有効期限を "31 Dec 2037 23:55:55 GMT" にします。パラメータ off は、ブラウザ・セッションの終了時にクッキーの有効期限が切れます。

パラメータがオフでない場合、クッキーのマーキングメカニズムを有効にし、マークとして使用される文字を設定します。このメカニズムは、クライアント識別子を保持しながら、userid_p3pおよび/またはクッキーの有効期限を追加または変更するために使用されます。マークは英字アルファベット(大文字小文字を区別する)、数字、または「=」文字のいずれかです。

マークが設定されている場合、それはクッキーで渡されたクライアント識別子のbase64表現の最初のパディング記号と比較されます。それらが一致しない場合、クッキーは指定されたマーク、有効期限時間、「P3P」ヘッダーで再送されます。

Sets the cookie name.

クッキーと一緒に送られる "P3P" ヘッダフィールドの値を設定します。ディレクティブが特別な値noneに設定されている場合、"P3P "ヘッダは応答では送信されません。

クッキーが設定されるパスを定義します。

識別子が複数のサーバ（サービス）から発行される場合は、クライアントの識別子が一意であることを保証するために、各サービスに独自の番号を割り当てる必要があります。バージョン1のクッキーでは、デフォルト値は0です。バージョン2のクッキーのデフォルト値は、サーバのIPアドレスの最後の4オクテットからなる番号です。

Embedded Variables

ngx_http_userid_moduleモジュールは、以下の組み込み変数をサポートしています。

$uid_got

クッキー名と受信したクライアント識別子。

$uid_reset

この変数に "0" 以外の空でない文字列が設定されている場合、クライアントの識別子はリセットされます。特別な値 "log" は、リセットされた識別子に関するメッセージを error_log に出力します。

$uid_set

クッキー名と送信されたクライアント識別子。

Module ngx_http_uwsgi_module

ngx_http_uwsgi_module モジュールは、リクエストを uwsgi サーバに渡すことができます。

設定例

記述内容

uwsgiサーバへの発信接続を、オプションのポート(1.11.2)を指定して、指定したローカルIPアドレスから発信するようにします。パラメータ値には変数(1.3.12)を含めることができます。特別な値 off (1.3.12) は、以前の設定レベルから継承された uwsgi_bind ディレクティブの効果をキャンセルし、システムがローカル IP アドレスとポートを自動的に割り当てることを可能にします。

transparent パラメータ (1.11.0) は、クライアントの実際の IP アドレスなど、ローカルではない IP アドレスから uwsgi サーバへの発信接続を許可します。

uwsgi_bind $remote_addr transparent;

このパラメータを動作させるためには、通常、スーパーユーザ権限で nginx ワーカープロセスを実行する必要があります。Linux では、transparent パラメータが指定されている場合、ワーカープロセスはマスタープロセスから CAP_NET_RAW 機能を継承するため、必要ありません (1.13.8)。また、uwsgi サーバからのネットワークトラフィックを傍受するために、カーネルルーティングテーブルを設定する必要があります。

uwsgi サーバから受信したレスポンスの最初の部分を読み込むために使用するバッファのサイズを設定します。この部分には通常、小さなレスポンスヘッダが含まれています。デフォルトでは、バッファサイズは1メモリページに相当します。これはプラットフォームに応じて4Kか8Kのどちらかになります。しかし、これより小さくすることもできます。

uwsgi サーバからの応答のバッファリングを有効または無効にします。

バッファリングが有効な場合、nginx は uwsgi サーバからのレスポンスをできるだけ早く受け取り、uwsgi_buffer_size と uwsgi_buffers 記述内容で設定されたバッファに保存します。レスポンス全体がメモリに収まらない場合は、その一部をディスク上の一時ファイルに保存することができます。一時ファイルへの書き込みは uwsgi_max_temp_file_size と uwsgi_temp_file_write_size 記述内容によって制御されます。

バッファリングが無効になっている場合、レスポンスは受信した直後に同期的にクライアントに渡されます。nginx が一度にサーバから受け取ることができるデータの最大サイズは uwsgi_buffer_size ディレクティブで設定されます。

バッファリングは "X-Accel-Buffering" レスポンスヘッダフィールドに "yes" か "no" を渡すことで有効または無効にすることができます。この機能は uwsgi_ignore_headers ディレクティブで無効にすることができます。

uwsgi サーバからの応答を読み込むために使用するバッファの数とサイズを設定します。デフォルトでは、バッファサイズは1メモリページに相当します。これは、プラットフォームに応じて、4K または 8K のどちらかになります。

uwsgi サーバからの応答のバッファリングを有効にすると、応答がまだ完全に読み込まれていない間、クライアントに応答を送信するためにビジー状態になるバッファの合計サイズを制限します。その間、残りのバッファはレスポンスの読み込みに使われ、必要に応じてレスポンスの一部を一時ファイルにバッファリングすることができます。デフォルトでは、サイズは uwsgi_buffer_size と uwsgi_buffers 記述内容で設定された 2 つのバッファのサイズによって制限されます。

キャッシングに使用する共有メモリゾーンを定義します。同じゾーンを複数の場所で使用することができます。パラメータ値には変数を含めることができます（1.7.9）。off パラメータは、前の構成レベルから継承されたキャッシングを無効にします。

期限切れのキャッシュアイテムを更新するためのバックグラウンドサブリクエストを開始し、古いキャッシュレスポンスをクライアントに返すことを許可します。更新されているときに古いキャッシュ応答を使用できるようにする必要があることに注意してください。

レスポンスがキャッシュから取得されない条件を定義します。文字列パラメータの少なくとも一つの値が空でなく "0" でない場合、レスポンスはキャッシュから取得されません。

uwsgi_no_cache ディレクティブと一緒に使うことができます。

キャッシング用のキーを定義します。

uwsgi_cache_key localhost:9000$request_uri;

この機能を有効にすると、uwsgi サーバにリクエストを渡すことで、 uwsgi_cache_key ディレクティブで指定された新しいキャッシュ要素を生成するリクエストが一度に一つだけ許可されます。同じキャッシュ要素に対する他のリクエストは、キャッシュにレスポンスが現れるのを待つか、この要素のキャッシュロックが解除されるのを、 uwsgi_cache_lock_timeout ディレクティブで設定された時間まで待ちます。

新しいキャッシュ要素を生成するために uwsgi サーバに渡された最後のリクエストが指定された時間内に完了していない場合、さらに 1 つのリクエストが uwsgi サーバに渡されることがあります。

uwsgi_cache_lockのタイムアウトを設定します。タイムアウトした場合、リクエストは uwsgi サーバに渡されますが、レスポンスはキャッシュされません。

1.7.8以前のバージョンでは、レスポンスはキャッシュされていました。

バイト範囲リクエストのオフセットをバイト単位で設定します。範囲がオフセットを超えている場合、範囲リクエストは uwsgi サーバに渡され、レスポンスはキャッシュされません。

クライアントのリクエストメソッドがこのディレクティブにリストアップされている場合、 レスポンスはキャッシュされます。"GET" と "HEAD" メソッドは常にリストに追加されますが、明示的に指定することをお勧めします。uwsgi_no_cache ディレクティブも参照してください。

応答がキャッシュされるまでのリクエスト数を設定します。

キャッシュのパスなどを設定します。キャッシュデータはファイルに格納されます。キャッシュ内のファイル名は、キャッシュキーに MD5 関数を適用した結果です。levels パラメータは、キャッシュの階層レベルを定義します。例えば、以下の設定では

uwsgi_cache_path /data/nginx/cache levels=1:2 keys_zone=one:10m; file names in a cache will look like this:

/data/nginx/cache/c/29/b7f54b2df7773722d382f4809d65029c

キャッシュされたレスポンスは最初に一時ファイルに書き込まれ、その後ファイル名が変更されます。バージョン 0.8.9 以降、一時ファイルとキャッシュは異なるファイルシステムに置くことができます。しかし、この場合、ファイルは安価なリネーム操作の代わりに 2 つのファイルシステムにコピーされることに注意してください。したがって、どのような場所でも、キャッシュと一時ファイルを保持するディレクトリの両方を同じファイルシステムに置くことをお勧めします。一時ファイルを格納するディレクトリは use_temp_path パラメータ(1.7.10)に基づいて設定される。このパラメータが省略された場合、または on に設定された場合は、指定された場所の uwsgi_temp_path ディレクティブで設定されたディレクトリが使用されます。offに設定されている場合、一時ファイルは直接キャッシュディレクトリに置かれます。

さらに、すべてのアクティブな鍵とデータに関する情報は共有メモリゾーンに保存され、その名前とサイズは keys_zoneパラメータで設定される。1メガバイトのゾーンには、約8,000個の鍵を格納することができる。

商用サブスクリプションの一部として、共有メモリゾーンには拡張キャッシュ情報も格納されるため、 同じ数の鍵に対してより大きなゾーンサイズを指定する必要がある。例えば、1メガバイトのゾーンには約4,000個の鍵を格納することができます。 inactiveパラメータで指定された時間内にアクセスされなかったキャッシュデータは、その鮮度に関係なくキャッシュから削除されます。デフォルトでは、inactiveは10分に設定されている。

特別な「キャッシュマネージャ」プロセスは、max_sizeパラメータで設定された最大キャッシュサイズを監視します。このサイズを超えると、最近使用されたデータを削除します。データは manager_files、manager_threshold、manager_sleep パラメータ (1.11.5) で設定された繰り返しで削除されます。1回のイテレーションの間に削除されるのは、 manager_filesの項目を超えてはなりません (デフォルトでは100)。1回の反復の期間は、 manager_thresholdパラメータによって制限されます (デフォルトでは、200ミリ秒)。反復の間には、 manager_sleep パラメータで設定された一時停止が行われます (デフォルトでは 50 ミリ秒)。

起動から1分後に特別な「キャッシュローダー」プロセスが起動します。ファイルシステムに保存されている以前にキャッシュされたデータの情報をキャッシュゾーンにロードします。読み込みは反復して行われます。1 回の繰り返しの間に loader_files の項目がロードされるのはそれ以上ではありません (デフォルトでは 100)。さらに、1 回の反復の期間は loader_threshold パラメータによって制限されます（デフォルトでは 200 ミリ秒）。反復の間には、loader_sleep パラメータ（デフォルトでは 50 ミリ秒）で設定した一時停止が行われます。

さらに、以下のパラメータは、当社の商用サブスクリプションの一部として利用可能です。

purger=on|off

ワイルドカードキーに一致するキャッシュエントリをキャッシュパージ機能 (1.7.12) でディスクから削除するかどうかを指定します。パラメータを on (デフォルトは off) に設定すると、すべてのキャッシュエントリを恒久的に反復処理し、ワイルドカードキーにマッチするエントリを削除する「キャッシュパージ」プロセスが有効になります。

purger_files=number

1 回の繰り返しでスキャンするアイテムの数を設定します (1.7.12)。デフォルトでは、Purger_files は 10 に設定されています。

purger_threshold=number

1 回の反復の持続時間を設定します (1.7.12)。デフォルトでは、Purger_threshold は 50 ミリ秒に設定されています。

purger_sleep=number

反復の間の一時停止を設定します (1.7.12)。デフォルトでは、purger_sleep は 50 ミリ秒に設定されています。 バージョン 1.7.3、1.7.7、および 1.11.10 では、キャッシュヘッダの形式が変更されました。新しいバージョンの nginx にアップグレードすると、以前にキャッシュされたレスポンスは無効とみなされます。

リクエストがキャッシュパージリクエストとみなされる条件を定義します。文字列パラメータの少なくとも一つの値が空ではなく、"0" に等しくない場合、対応するキャッシュキーを持つキャッシュエントリが削除されます。操作が成功した結果は 204 (No Content) 応答を返すことで示されます。

パージリクエストのキャッシュキーがアスタリスク ("*") で終わる場合、ワイルドカードキーにマッチするすべてのキャッシュエントリがキャッシュから削除されます。しかし、これらのエントリは非アクティブ状態で削除されるか、キャッシュパージ機能 (1.7.12) によって処理されるか、クライアントがアクセスしようとするまでディスク上に残ります。

設定例:

この機能は、当社の商用サブスクリプションの一部としてご利用いただけます。

If-Modified-Since" および "If-None-Match" ヘッダーフィールドを持つ条件付きリクエストを使用して、期限切れのキャッシュアイテムの再バリデーションを有効にします。

uwsgi サーバとの通信中にエラーが発生した場合に、 どのような場合に古いキャッシュされたレスポンスを使うことができるかを決定します。このディレクティブのパラメータは uwsgi_next_upstream ディレクティブのパラメータと一致します。

error パラメータは、リクエストを処理する uwsgi サーバが選択できない場合に、古いキャッシュされたレスポンスを使うこともできます。

さらに、update パラメータでは、現在更新中の場合は古いキャッシュされたレスポンスを使うことができます。これにより、キャッシュされたデータを更新する際に、 uwsgi サーバへのアクセス数を最小限に抑えることができます。

スタールキャッシュされた応答を使用することは、応答がスタールになってから指定された秒数だけ応答ヘッダで直接有効にすることもできます (1.11.10)。これはディレクティブのパラメータを使うよりも優先度が低いです。

Cache-Control」ヘッダフィールドの「stale-while-revalidate」拡張は、現在更新中の場合、古いキャッシュされた 応答を使用することを許可します。 Cache-Control" ヘッダ・フィールドの "stale-if-error" 拡張子は、エラーが発生した場合に古いキャッシュ・レスポンスの使用を許可します。 新しいキャッシュ要素を生成する際に uwsgi サーバへのアクセス数を最小限にするために、 uwsgi_cache_lock ディレクティブを使用することができます。

異なるレスポンスコードのキャッシュ時間を設定します。例えば、次のような記述内容

コード 200 および 302 の応答に対して 10 分間、コード 404 の応答に対して 1 分間のキャッシングを設定します。

キャッシング時間のみを指定した場合

uwsgi_cache_valid 5m。

の場合、200、301、302 のレスポンスのみがキャッシュされます。

さらに、any パラメータを指定することで、任意のレスポンスをキャッシュすることができます。

キャッシングのパラメータはレスポンスヘッダで直接設定することもできます。これはディレクティブを使ったキャッシュ時間の設定よりも優先度が高くなります。

X-Accel-Expires" ヘッダフィールドは応答のキャッシュ時間を秒単位で設定します。ゼロの値は応答のキャッシュを無効にします。接頭辞 @ で始まる値は、Epoch からの絶対時間を秒単位で設定します。 ヘッダーが「X-Accel-Expires」フィールドを含まない場合、キャッシングのパラメータは ヘッダーフィールド「Expires」または「Cache-Control」で設定できる。 ヘッダに「Set-Cookie」フィールドが含まれている場合、そのような応答はキャッシュされない。 ヘッダに特別な値「*」を持つ「Vary」フィールドが含まれている場合、そのような応答はキャッシュされない(1.7.7)。ヘッダーが別の値を持つ「Vary」フィールドを含む場合、そのような応答は 対応するリクエストヘッダーフィールドを考慮してキャッシュされる(1.7.7)。 これらの応答ヘッダフィールドの一つ以上の処理は uwsgi_ignore_headers ディレクティブを使って無効にすることができます。

uwsgi サーバとの接続を確立するためのタイムアウトを定義します。このタイムアウトは通常 75 秒を超えることはできないことに注意してください。

これらの応答の「Accept-Ranges」フィールドに関係なく、uwsgiサーバからのキャッシュされた応答とキャッシュされていない応答の両方でバイトレンジのサポートを有効にします。

デフォルトでは、nginx は uwsgi サーバのレスポンスから "Status" と "X-Accel-..." というヘッダフィールドをクライアントに渡しません。uwsgi_hide_header ディレクティブは、渡さない追加のフィールドを設定します。逆に、フィールドを渡すことを許可する必要がある場合は、 uwsgi_pass_header ディレクティブを使うことができます。

クライアントが応答を待たずに接続を閉じた場合に、uwsgi サーバとの接続を閉じるかどうかを決定します。

uwsgi サーバーからの特定の応答ヘッダーフィールドの処理を無効にします。以下のフィールドは無視できます。"X-Accel-Redirect"、"X-Accel-Expires"、"X-Accel-Limit-Rate" (1.1.6)、"X-Accel-Buffering" (1.1.6)、"X-Accel-Charset" (1.1.6)、"Expires"、"Cache-Control"、"Set-Cookie" (0.8.44)、"Vary" (1.7.7)。

無効化されていない場合、これらのヘッダフィールドの処理は以下の効果を持つ。

"X-Accel-Expires"、"Expires"、"Cache-Control"、"Set-Cookie"、および "Vary "はレスポンスキャッシングのパラメータを設定する。 "X-Accel-Redirect" は、指定された URI への内部リダイレクトを実行します。 "X-Accel-Limit-Rate」は、クライアントへの応答送信のレート制限を設定します。 "X-Accel-Buffering」は、応答のバッファリングを有効または無効にします。 "X-Accel-Charset」は、レスポンスの希望する文字セットを設定します。

300 以上のコードを持つ uwsgi サーバのレスポンスをクライアントに渡すか、 傍受して nginx にリダイレクトして error_page ディレクティブで処理するかを決定します。

uwsgi サーバからのレスポンスの読み込み速度を制限します。レートは1秒あたりのバイト数で指定します。ゼロの値はレートの制限を無効にします。制限はリクエストごとに設定されるので、nginx が同時に uwsgi サーバに 2 つの接続を開いた場合、全体のレートは指定された制限の 2 倍になります。この制限は uwsgi サーバからのレスポンスのバッファリングが有効になっている場合にのみ機能します。

uwsgi サーバからの応答のバッファリングが有効で、 uwsgi_buffer_size と uwsgi_buffers 記述内容で設定したバッファに応答全体が収まらない場合、応答の一部を一時ファイルに保存することができます。このディレクティブは一時ファイルの最大サイズを設定します。一度に一時ファイルに書き込まれるデータのサイズはuwsgi_temp_file_write_sizeで設定します。

ゼロの値は一時ファイルへの応答のバッファリングを無効にします。

この制限は、キャッシュされたりディスクに保存されたりするレスポンスには適用されません。

uwsgi パケットヘッダの modifier1 フィールドの値を設定します。

uwsgi パケットヘッダの modifier2 フィールドの値を設定します。

どのような場合にリクエストを次のサーバーに渡すかを指定します。

error

サーバーとの接続を確立しているとき、リクエストをサーバーに渡しているとき、またはレスポンスヘッダを読んでいるときにエラーが発生しました。

timeout

サーバーとの接続を確立している間、リクエストをサーバーに渡している間、または応答ヘッダーを読んでいる間にタイムアウトが発生しました。

invalid_header

サーバが空か無効な応答を返しました。

http_500

サーバがコード500のレスポンスを返しました。

http_503

はコード503のレスポンスを返しました。

http_403

サーバはコード403で応答を返しました。

http_404

サーバーはコード 404 で応答を返しました。

http_429

サーバーはコード429 (1.11.13)の応答を返しました。

non_idempotent

通常、リクエストがアップストリームサーバ (1.9.13) に送られた場合、非親和的なメソッド (POST, LOCK, PATCH) を持つリクエストは次のサーバに渡されません。

off

は次のサーバへのリクエストの受け渡しを無効にします。 次のサーバへのリクエストの受け渡しは、まだクライアントに何も送信されていない場合にのみ可能であることを覚えておくべきです。つまり、応答の転送の途中でエラーやタイムアウトが発生した場合、 これを修正することは不可能です。

このディレクティブでは、サーバとの通信に失敗したとみなされるものも定義しています。error, timeout, invalid_header の場合は、たとえディレクティブで指定されていなくても、 常に失敗したとみなされます。http_500, http_503, http_429 の場合は、ディレクティブで指定されている場合に限り、 失敗したとみなされます。http_403 と http_404 の場合は、失敗したとみなされることはありません。

次のサーバへのリクエストの受け渡しは、試行回数と時間によって制限されます。

リクエストを次のサーバーに渡すことができる時間を制限します。0 の値はこの制限をオフにします。

次のサーバーにリクエストを渡すための試行回数を制限します。0 の値はこの制限をオフにします。

レスポンスがキャッシュに保存されない条件を定義します。文字列パラメータの少なくとも一つの値が空でなく、かつ "0" でない場合、レスポンスは保存されません。

uwsgi_no_cache $cookie_nocache $arg_nocache$arg_comment; uwsgi_no_cache $http_pragma $http_authorization; uwsgi_cache_bypass ディレクティブと一緒に使うことができます。

uwsgi サーバに渡すパラメータを設定します。値には、テキスト、変数、およびそれらの組み合わせを含めることができます。これらの記述内容は、現在のレベルに uwsgi_param 記述内容が定義されていない場合に限り、前のレベルから継承されます。

標準 CGI 環境変数は uwsgi ヘッダとして提供されなければなりません。

ディレクティブが if_not_empty (1.1.11) で指定されている場合は、 その値が空でない場合にのみサーバに渡されます。

uwsgiサーバのプロトコルとアドレスを設定します。プロトコルとしては、"uwsgi "または "suwsgi" (secured uwsgi, uwsgi over SSL)を指定することができます。アドレスはドメイン名またはIPアドレス、ポートを指定できます。

またはUNIXドメインのソケットパスとして使用します。

uwsgi_pass unix:/tmp/uwsgi.socket; ドメイン名が複数のアドレスに解決された場合、すべてのアドレスがラウンドロビン方式で使用されます。また、サーバーグループとしてアドレスを指定することもできます。

パラメータ値には変数を含めることができます。この場合、ドメイン名としてアドレスが指定された場合には、記述されたサーバグループの中から検索され、見つからなければリゾルバを用いて決定される。

安全な uwsgi プロトコルはバージョン 1.5.8 からサポートされています。

そうでなければ無効になっているヘッダフィールドを uwsgi サーバからクライアントに渡すことを許可します。

オリジナルのリクエストボディを uwsgi サーバに渡すかどうかを示します。uwsgi_pass_request_headers ディレクティブも参照してください。

オリジナルのリクエストのヘッダフィールドを uwsgi サーバに渡すかどうかを示します。uwsgi_pass_request_body ディレクティブも参照してください。

uwsgi サーバからの応答を読み込む際のタイムアウトを定義します。タイムアウトは2つの連続した読み込み操作の間にのみ設定され、応答全体の送信には設定されません。uwsgiサーバがこの時間内に何も送信しなかった場合、接続は閉じられます。

クライアントのリクエストボディのバッファリングを有効または無効にします。

バッファリングが有効な場合、リクエストを uwsgi サーバに送信する前にクライアントからリクエストボディ全体が読み込まれます。

バッファリングを無効にすると、リクエストボディは受信した直後に uwsgi サーバに送信されます。この場合、nginx が既にリクエストボディの送信を開始していると、次のサーバにリクエストを渡すことができません。

HTTP/1.1 chunked transfer encoding を使用して元のリクエストボディを送信する場合、ディレクティブの値に関わらずリクエストボディはバッファリングされます。

リクエストを uwsgi サーバに送信するためのタイムアウトを設定します。タイムアウトは2つの連続した書き込み操作の間にのみ設定され、リクエスト全体の送信には設定されません。この時間内に何も受信しなかった場合、接続は閉じられます。

uwsgiサーバへの送信接続の "TCP keepalive "動作を設定します。デフォルトでは、オペレーティングシステムの設定がソケットに対して有効になっています。ディレクティブの値が "on" に設定されている場合、SO_KEEPALIVE ソケットオプションがソケットに対して有効になります。

セキュリティ保護された uwsgi サーバへの認証に使用される PEM 形式の証明書を含むファイルを指定します。

セキュリティ保護された uwsgi サーバへの認証に使用する PEM 形式の秘密鍵のファイルを指定します。

ファイル (1.7.9) の代わりに engine:name:id を指定すると、OpenSSL エンジン名から指定された id の秘密鍵がロードされます。

安全な uwsgi サーバへのリクエストに対して有効な暗号化方式を指定します。暗号化方式は OpenSSL ライブラリで理解される形式で指定されます。

完全なリストは "openssl ciphers" コマンドで見ることができます。

セキュリティ保護された uwsgi サーバの証明書を検証するために使用される PEM 形式の失効した証明書 (CRL) を含むファイルを指定します。

セキュリティで保護された uwsgi サーバの証明書を検証し、セキュリティで保護された uwsgi サーバとの接続を確立する際に SNI を介して渡されるサーバ名をオーバーライドすることができます。

デフォルトでは uwsgi_pass のホスト部分が使用されます。

秘密鍵のパスフレーズを含むファイルを指定し、各パスフレーズを別の行で指定します。パスフレーズは、鍵の読み込み時に順番に試行されます。

セキュリティ保護された uwsgi サーバへのリクエストに対して指定されたプロトコルを有効にします。

セキュリティ保護された uwsgi サーバーとの接続を確立する際に、TLS Server Name Indication extension (SNI, RFC 6066) を通じてサーバー名を渡すことを有効または無効にします。

セキュリティで保護された uwsgi サーバで作業する際に SSL セッションを再利用できるかどうかを決定します。SSL3_GET_FINISHED:digest check failed "というエラーがログに表示された場合、セッションの再利用を無効にしてみてください。

セキュリティ保護された uwsgi サーバの証明書を検証するために使用される PEM 形式の信頼できる CA 証明書を含むファイルを指定します。

セキュリティ保護された uwsgi サーバ証明書の検証を有効または無効にします。

セキュリティ保護された uwsgi サーバ証明書チェーンの検証深度を設定します。

ファイルのディスクへの保存を有効にします。on パラメータを指定すると、エイリアスまたはルートに対応するパスでファイルを保存します。off パラメータはファイルの保存を無効にします。また、変数付きの文字列を使用して、ファイル名を明示的に設定することができます。

ファイルの修正時間は、受信した "Last-Modified "応答ヘッダフィールドに応じて設定される。レスポンスは最初に一時ファイルに書き込まれ、その後ファイル名が変更されます。バージョン0.8.9からは、一時ファイルと永続ストアを別のファイルシステムに置くことができます。しかし、この場合、ファイルは安価なリネーム操作ではなく、2つのファイルシステムにまたがってコピーされることに注意してください。したがって、任意の場所に保存ファイルと一時ファイルを保持するディレクトリ(uwsgi_temp_path ディレクティブで設定)を同じファイルシステムに置くことが推奨されます。

このディレクティブは、例えば、静的で変更不可能なファイルのローカルコピーを作成するために使うことができます。

新しく作成されたファイルやディレクトリのアクセス権限を設定します。

uwsgi_store_access user:rw group:rw all:r; いずれかのグループまたはすべてのアクセス権限が指定されている場合は、ユーザ権限を省略することができます。

uwsgi サーバからの応答の一時ファイルへのバッファリングが有効な場合、一度に一時ファイルに書き込まれるデータのサイズを制限します。デフォルトでは、uwsgi_buffer_size と uwsgi_buffers 記述内容で設定された2つのバッファでサイズが制限されます。一時ファイルの最大サイズは uwsgi_max_temp_file_size ディレクティブで設定されます。

uwsgiサーバから受信したデータの一時ファイルを格納するディレクトリを定義します。指定したディレクトリの下には、3階層までのサブディレクトリ階層を使用することができます。例えば、以下の設定では

uwsgi_temp_path /spool/nginx/uwsgi_temp 1 2. 一時ファイルは次のようになります。

/spool/nginx/uwsgi_temp/7/45/00000123457 uwsgi_cache_path ディレクティブの use_temp_path パラメータも参照してください。

Module ngx_http_v2_module

ngx_http_v2_module モジュール (1.9.5) は HTTP/2 をサポートしており、ngx_http_spdy_module モジュールの後継モジュールです。

このモジュールはデフォルトではビルドされていないので、 --with-http_v2_module 設定パラメータで有効にしなければなりません。

Known Issues バージョン 1.9.14 より前のバージョンでは、proxy_request_buffering, fastcgi_request_buffering, uwsgi_request_buffering, scgi_request_buffering ディレクティブの値に関わらず、 クライアントリクエストボディのバッファリングを無効にすることができませんでした。

設定例

TLS 上で HTTP/2 接続を受け入れるには、"Application-Layer Protocol Negotiation" (ALPN) TLS 拡張機能が必要であることに注意してください。この目的で "Next Protocol Negotiation" (NPN) TLS 拡張 (OpenSSL バージョン 1.0.1 以降で利用可能) を使用しても、動作は保証されません。

また、ssl_prefer_server_ciphers ディレクティブが値 "on" に設定されている場合、暗号化方式は RFC 7540, 付録 A ブラックリストに準拠し、クライアントがサポートするように設定されなければならないことに注意してください。

記述内容

リクエストボディが処理を開始する前に保存される可能性のある各リクエストごとのバッファのサイズを設定します。

応答ボディがスライスされるチャンクの最大サイズを設定します。値が低すぎるとオーバーヘッドが大きくなります。値が高すぎると、HOL ブロッキングによる優先順位付けが損なわれます。

接続を終了するまでの非アクティブ状態のタイムアウトを設定します。

接続での同時プッシュ要求の最大数を制限します。

接続での同時接続 HTTP/2 ストリームの最大数を設定します。

HPACK圧縮されたリクエストヘッダーフィールドの最大サイズを制限します。この制限は name と value の両方に等しく適用される。ハフマンエンコーディングが適用されている場合、展開された name と value の文字列の実際のサイズはより大きくなるかもしれないことに注意してください。ほとんどのリクエストでは、デフォルトの制限値で十分です。

HPACK 解凍後のリクエストヘッダリスト全体の最大サイズを制限します。ほとんどのリクエストでは、デフォルトの制限で十分です。

1 つの HTTP/2 コネクションを通して提供できるリクエスト (プッシュリクエストを含む) の最大数を設定します。

定期的に接続を閉じることは、接続ごとのメモリ割り当てを空けるために必要です。そのため、最大リクエスト数が多すぎるとメモリを過剰に使用することになるので、お勧めできません。

指定された URI へのリクエストを、元のリクエストへのレスポンスとともに先制的に送信 (プッシュ) します。絶対パスを持つ相対 URI のみが処理されます。

http2_push /static/css/main.css; uriの値には変数を含めることができます。

同じ設定レベルで複数の http2_push 記述内容を指定することができます。off パラメータは、前の設定レベルから継承した http2_push 記述内容の効果をキャンセルします。

Link」応答ヘッダーフィールドで指定されたプリロードリンクをプッシュリクエストに自動変換できるようにします。

ワーカーごとの入力バッファのサイズを設定します。

クライアントからより多くのデータを期待するためのタイムアウトを設定します。

埋め込み変数 ngx_http_v2_moduleモジュールは、以下の組み込み変数をサポートしています。

$http2 ネゴシエートされたプロトコル識別子。HTTP/2 over TLSであれば "h2"、HTTP/2 over cleartext TCPであれば "h2c"、それ以外の場合は空文字列。

Module ngx_http_xslt_module

ngx_http_xslt_module (0.7.8+) は、一つ以上の XSLT スタイルシートを使って XML レスポンスを変換するフィルタです。

このモジュールはデフォルトではビルドされていないので、 --with-http_xslt_module 設定パラメータで有効にしなければなりません。

このモジュールには libxml2 および libxslt ライブラリが必要です。

設定例

 

記述内容

文字実体を宣言するDTDファイルを指定します。このファイルは設定段階でコンパイルされます。技術的な理由から、モジュールは処理されたXMLで宣言された外部サブセットを使用することができないため、これは無視され、代わりに特別に定義されたファイルが使用されます。このファイルはXML構造を記述してはいけません。例えば、必要な文字実体だけを宣言すれば十分です。

This directive appeared in version 1.5.1.

This directive appeared in version 1.5.1.

応答のキャッシングを容易にするために、XSLT 変換中に元の応答から「Last-Modified」ヘッダフィールドを保持することを許可します。

デフォルトでは、変換中にレスポンスの内容が変更されると、ヘッダフィールドは削除され、元のレスポンスから独立して変更される動的に生成された要素や部分を含む可能性があります。

このディレクティブはバージョン 1.1.18 で登場しました。

XSLT スタイルシートのパラメータを定義します。値は XPath 式として扱われます。値は変数を含むことができます。文字列の値をスタイルシートに渡すには、 xslt_string_param ディレクティブを使うことができます。

いくつかの xslt_param ディレクティブを使うことができます。これらのディレクティブは、現在のレベルで xslt_param ディレクティブと xslt_string_param ディレクティブが定義されていない場合にのみ、前のレベルから継承されます。

XSLTスタイルシートの文字列パラメータを定義します。値の中の XPath 式は解釈されません。値は変数を含むことができます。

複数の xslt_string_param ディレクティブが存在する可能性があります。これらのディレクティブは、現在のレベルで xslt_param ディレクティブと xslt_string_param ディレクティブが定義されていない場合にのみ、前のレベルから継承されます。

XSLT スタイルシートとそのオプションのパラメータを定義します。スタイルシートは設定段階でコンパイルされます。

パラメータは、個別に指定するか、":" デリミタを使用して 1 行にまとめて指定することができます。パラメータが ":" 文字を含む場合、それは "%3A" としてエスケープされるべきです。また、libxslt は、英数字以外の文字を含むパラメータを、例えば一重引用符や二重引用符で 囲むことを要求します。

param1='http%3A//www.example.com':param2=value2

パラメータの記述には変数を含めることができ、例えば、パラメータの行全体を単一の変数から取ることができます。

複数のスタイルシートを指定することができます。これらは指定した順番で順次適用されます。

text/xml」に加えて、指定された MIME タイプを持つレスポンスでの変換を有効にします。特別な値「*」は、任意の MIME タイプにマッチします (0.8.29)。変換結果が HTML レスポンスの場合、その MIME タイプは「text/html」に変更されます。

Module ngx_mail_core_module

このモジュールはデフォルトではビルドされていませんので、 --with-mail設定パラメータで有効にしなければなりません。

設定例

記述内容

サーバがリクエストを受け付けるソケットのアドレスとポートを設定します。ポートだけを指定することも可能です。アドレスには、例えばホスト名を指定することもできます。

IPv6 addresses (0.7.58) are specified in square brackets:

UNIX ドメインソケット (1.3.5) は "unix:" 接頭辞で指定します。

異なるサーバは、異なるアドレス:ポートのペアでリッスンしなければなりません。

ssl パラメータでは、このポートで受け付けたすべての接続が SSL モードで動作するように指定することができます。

listen ディレクティブはソケット関連のシステムコールに特化したいくつかの追加パラメータを 持つことができます。

backlog=number

は listen() コールの backlog パラメータを設定し、保留中の接続のキューの最大長を制限します (1.9.2)。デフォルトでは、 FreeBSD, DragonFly BSD, macOS では -1、その他のプラットフォームでは 511 に設定されています。

rcvbuf=size

リスニングソケット(1.11.13)の受信バッファサイズ(SO_RCVBUFオプション)を設定する。

sndbuf=size

リスニングソケット(1.11.13)の送信バッファサイズ(SO_SNDBUFオプション)を設定する。

bind

このパラメータは、指定されたアドレス:ポートのペアに対して個別に bind() を呼び出すように指示します。実際には、同じポートでも異なるアドレスを持つ複数の listen ディレクティブが存在し、そのうちの一つが指定されたポート (*:port) のすべてのアドレスを listen している場合、nginx は *:port にのみ bind() を行います。この場合、接続を受け入れたアドレスを決定するために getsockname() システムコールが行われることに注意してください。ipv6only や so_keepalive パラメータが使用されている場合は、指定されたアドレス:ポートのペアに対して、常に個別の bind() コールが行われます。

ipv6only=on|off

このパラメータは、ワイルドカードアドレス[::]をリッスンしているIPv6ソケットがIPv6接続のみを受け入れるか、IPv6とIPv4の両方を受け入れるかを(IPV6_V6ONLY socketオプションを使用して)決定します。このパラメータはデフォルトでオンになっています。設定できるのは起動時に一度だけです。

so_keepalive=on|off|[keepidle]:[keepintvl]:[keepcnt]

このパラメータは、リスニングソケットのTCPキープアライブの動作を設定します。このパラメータが省略された場合、オペレーティングシステムの設定がソケットに対して有効になります。このパラメータが "on "に設定されている場合、SO_KEEPALIVEオプションがソケットに対して有効になる。オフに設定した場合、SO_KEEPALIVEオプションはソケットに対してオフになる。一部のオペレーティングシステムでは、TCP_KEEPIDLE, TCP_KEEPINTVL, TCP_KEEPCNT ソケットオプションを使用して、ソケットごとに TCP keepalive パラメータの設定をサポートしている。このようなシステム (現在のところ Linux 2.4+, NetBSD 5+, FreeBSD 9.0-STABLE) では、keepidle, keepintvl, および keepcnt パラメータを使用して設定することができます。1つまたは2つのパラメータを省略した場合、対応するソケットオプションのシステムデフォルト設定が有効になります。例えば、以下のようになります。

so_keepalive=30m::10

は、アイドルタイムアウト (TCP_KEEPIDLE) を 30 分に設定し、プローブ間隔 (TCP_KEEPINTVL) をシステムの既定値のままにして、プローブ数 (TCP_KEEPCNT) を 10 個に設定します。

メールサーバーのディレクティブが指定されている構成ファイルのコンテキストを提供します。

プロキシされたサーバーのプロトコルを設定します。サポートされているプロトコルは IMAP, POP3, SMTP です。

このディレクティブが設定されていない場合は、 listen ディレクティブで指定された既知のポートに基づいてプロトコルを自動的に検出します。

imap: 143, 993 pop3: 110, 995 smtp: 25, 587, 465

不要なプロトコルは、設定パラメータ --without-mail_imap_module, --without-mail_pop3_module, --without-mail_smtp_module を使って無効にすることができます。

クライアントのホスト名を検索して認証サーバに渡すために使用するネームサーバを構成し、SMTP をプロキシするときに XCLIENT コマンドで使用します。例えば、以下のようになります。

resolver 127.0.0.1 [::1]:5353; アドレスは、ドメイン名またはIPアドレスとして、オプションのポート(1.3.1, 1.2.2)を指定できます。ポートを指定しない場合は53番ポートを使用します。ネームサーバはラウンドロビン方式で照会されます。

バージョン1.1.7以前では、1台のネームサーバしか設定できませんでした。IPv6 アドレスを使用したネームサーバの指定は、バージョン 1.3.1 および 1.2.2 からサポートされています。 デフォルトでは、nginx は IPv4 アドレスと IPv6 アドレスの両方を検索して解決します。IPv6 アドレスを検索したくない場合は、ipv6=off パラメータを指定することができます。

IPv6 アドレスへの名前解決はバージョン 1.5.8 よりサポートされています。 デフォルトでは、nginx はレスポンスの TTL 値を使って回答をキャッシュします。オプションの有効なパラメータを指定することで、これを上書きすることができます。

resolver 127.0.0.0.1 [::1]:5353 valid=30s. バージョン 1.1.1.9 より前のバージョンでは、キャッシュ時間の調整ができず、nginx は常に 5 分間の回答をキャッシュしていました。 DNSスプーフィングを防ぐには、適切に保護された信頼できるローカルネットワークにDNSサーバを設定することをお勧めします。 オプションの status_zone パラメータ (1.17.1) を使用すると、指定したゾーンのリクエストとレスポンスの DNS サーバーの統計情報を収集することができます。このパラメータは、当社の商用サブスクリプションの一部として利用できます。

特別な値 off は解決を無効にします。

DNS操作のタイムアウトを設定します。

Sets the configuration for a server.

使用するサーバー名を設定します。

POP3/SMTP サーバの最初の挨拶で使用されるサーバ名を設定します。 SASL CRAM-MD5 認証時のソルトで。 XCLIENT コマンドの指定が有効な場合は、SMTP バックエンドに接続する際の EHLO コマンドで使用するサーバ名を設定します。 ディレクティブが指定されていない場合は、マシンのホスト名が使用されます。

バックエンドへのプロキシを開始する前に使用するタイムアウトを設定します。

Module ngx_mail_auth_http_module

記述内容

HTTP認証サーバのURLを設定します。プロトコルについては、以下に説明します。

認証サーバに送信されたリクエストに、指定されたヘッダを追加します。このヘッダは、リクエストが nginx からのものであることを確認するための共有シークレットとして使用することができます。例えば、以下のようになります。

auth_http_header X-Auth-Key "secret_string";

認証サーバに送信されたリクエストに、クライアント証明書を PEM 形式 (urlencoded) で添付した「Auth-SSL-Cert」ヘッダを追加します。

Syntax: auth_http_timeout time; Default: auth_http_timeout 60s; Context: mail, server 認証サーバとの通信のタイムアウトを設定します。

Protocol 認証サーバとの通信にはHTTPプロトコルを使用します。レスポンスボディのデータは無視され、情報はヘッダのみで渡されます。

Examples of requests and responses:

Auth-Wait "ヘッダがない場合は、エラーが返され、接続が閉じられます。現在の実装では、認証の試行ごとにメモリを確保しています。メモリはセッションの終了時にのみ解放されます。そのため、1回のセッションで無効な認証の試行回数を制限しなければなりません。 サーバは、10～20回の試行の後、"Auth-Wait "ヘッダなしで応答しなければなりません(試行回数は "Auth-Login-Atempt "ヘッダで渡されます)。

APOPやCRAM-MD5を使用した場合、request-responseは以下のようになります。

応答に「Auth-User」ヘッダが存在する場合、バックエンドでの認証に使用されるユーザ名を上書きします。

SMTP の場合、レスポンスは「Auth-Error-Code」ヘッダを追加で考慮に入れる。それ以外の場合は、「Auth-Status」ヘッダに535 5.7.0コードが追加される。

例えば、認証サーバから以下の応答を受信した場合。

と表示された場合、SMTPクライアントはエラー

451 4.3.0 一時的にサーバーに問題が発生しました。 SMTPをプロキシする際に認証を必要としない場合、リクエストは以下のようになります。

SSL/TLSクライアント接続(1.7.11)では、"Auth-SSL "ヘッダが追加され、"Auth-SSL-Verify "には、有効になっていればクライアント証明書の検証結果が格納されます。証明書が存在しない場合は "SUCCESS"、"FAILED:mecause"、"NONE "となります。

バージョン 1.11.7 より前のバージョンでは、「FAILED」結果には理由の文字列は含まれませんでした。 クライアント証明書が存在する場合、その詳細は以下のリクエストヘッダに渡されます。"Auth-SSL-Subject」、「Auth-SSL-Issuer」、「Auth-SSL-Serial」、「Auth-SSL-Fingerprint」です。auth_http_pass_client_certを有効にすると、"Auth-SSL-Cert "ヘッダに証明書自体が渡されます。リクエストは以下のようになります。

Module ngx_mail_proxy_module

記述内容

プロキシに使用するバッファのサイズを設定します。デフォルトでは、バッファサイズは1メモリページに相当します。プラットフォームに応じて、4K または 8K のいずれかになります。

バックエンドでの認証時に取得したエラーメッセージをクライアントに渡すかどうかを示す。

通常、nginx の認証が成功した場合、バックエンドはエラーを返すことができません。それでもエラーを返す場合は、何らかの内部エラーが発生したことを意味します。このような場合、バックエンドのメッセージにはクライアントに表示すべきではない情報が含まれている可能性があります。ただし、正しいパスワードを入力してもエラーが返ってくるのは、一部のPOP3サーバーでは通常の動作です。例えば、CommuniGateProは、定期的に認証エラーを出力することで、メールボックスのオーバーフローなどのイベントをユーザに通知します。この場合は、このディレクティブを有効にする必要があります。

クライアントまたはプロキシされたサーバー接続で、2 つの連続した読み取りまたは書き込み操作の間のタイムアウトを設定します。この時間内にデータが送信されない場合、接続は閉じられます。

SMTPバックエンドに接続する際に、クライアントパラメータでXCLIENTコマンドを渡すことを有効または無効にします。

XCLIENT を使用すると、MTA はクライアント情報をログに書き込み、このデータに基づいて様々な制限を適用することができます。

XCLIENTが有効な場合、nginxはバックエンドに接続する際に以下のコマンドを渡します。

サーバー名を持つEHLO XCLIENT クライアントから渡される EHLO または HELO

クライアントIPアドレスで見つかった名前が同じアドレスを指している場合は、XCLIENTコマンドのNAMEパラメータにその名前を渡します。名前が見つからなかったり、別のアドレスを指していたり、リゾルバが指定されていない場合は、NAMEパラメータに[UNAVAILABLE]を渡します。解決中にエラーが発生した場合は、[TEMPUNAVAIL]の値が使用されます。

XCLIENTが無効になっている場合、nginxはバックエンドに接続する際に、クライアントがEHLOを渡した場合はサーバ名と一緒にEHLOコマンドを、そうでない場合はサーバ名と一緒にHELOコマンドを渡します。

Module ngx_mail_ssl_module

ngx_mail_ssl_module モジュールはメールプロキシサーバが SSL/TLS プロトコルで動作するために必要なサポートを提供します。

このモジュールはデフォルトではビルドされていないので、 --with-mail_ssl_module 設定パラメータで有効にしなければなりません。

このモジュールには OpenSSL ライブラリが必要です。 設定例 プロセッサの負荷を軽減するには

ワーカープロセスの数をプロセッサの数と同じに設定します。 共有セッションキャッシュを有効にします。 内蔵のセッションキャッシュを無効にします。 また、セッションの有効時間を増やすこともできます (デフォルトでは 5 分)。 worker_processes auto.

記述内容

このディレクティブはバージョン 1.15.0 で廃止されました。代わりに listen ディレクティブの ssl パラメータを使うべきです。

指定したサーバの PEM 形式の証明書を含むファイルを指定します。一次証明書に加えて中間証明書を指定する場合は、次の順序で同じファイルに指定する必要があります。PEM 形式の秘密鍵を同じファイルに入れてもよい。

バージョン 1.11.0 以降では、このディレクティブを複数回指定して、RSA や ECDSA などの異なるタイプの証明書を読み込むことができます。

OpenSSL 1.0.2 以降では、異なる証明書に対して別々の証明書チェーンをサポートしています。それ以前のバージョンでは、1つの証明書チェーンしか使用できません。 ファイル (1.15.10) の代わりに data:certificate という値を指定することができますが、これは中間ファイルを使用せずに証明書をロードします。この構文を不適切に使用すると、秘密鍵データをエラーログに書き込むなどのセキュリティ上の意味合いがあることに注意してください。

指定したサーバの PEM 形式の秘密鍵を含むファイルを指定します。

ファイル (1.7.9) の代わりに engine:name:id を指定すると、OpenSSL エンジン名から指定された id で秘密鍵をロードします。

ファイル (1.15.10) の代わりに data:key を指定することもでき、中間ファイルを使用せずに秘密鍵をロードします。この構文を不適切に使用すると、秘密鍵データをエラーログに書き込むなどのセキュリティ上の意味合いがあることに注意してください。

有効な暗号化方式を指定します。暗号化方式は、例えば OpenSSL ライブラリが理解する形式で指定します。

ssl_ciphers ALL:!aNULL:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP. 完全なリストは "openssl ciphers "コマンドで確認できます。

以前のバージョンのnginxはデフォルトで異なる暗号を使用していました。

クライアント証明書の検証に使用される PEM 形式の信頼できる CA 証明書を含むファイルを指定します。

証明書のリストはクライアントに送られます。これが不要な場合は、ssl_trusted_certificate ディレクティブを使うことができます。

クライアント証明書の検証に使用される PEM 形式の失効した証明書 (CRL) を含むファイルを指定します。

DHE 暗号用の DH パラメータを持つファイルを指定します。

デフォルトではパラメータは設定されていないため、DHE 暗号は使用されません。

バージョン 1.11.0 より前のバージョンでは、組み込みのパラメータがデフォルトで使用されていました。

このディレクティブはバージョン 1.1.0.0 と 1.0.6 で登場しました。

ECDHE 暗号用のカーブを指定します。

OpenSSL 1.0.2以上を使用する場合は、例えば、複数の曲線を指定することが可能です(1.11.0)。

ssl_ecdh_curve prime256v1:secp384r1. 特別な値 auto (1.11.0) は、OpenSSL 1.0.2 以上、またはそれ以前のバージョンの prime256v1 を使用する場合に、nginx に OpenSSL ライブラリに組み込まれたリストを使用するように指示します。

バージョン 1.11.0 より前のバージョンでは、デフォルトで prime256v1 曲線が使用されていました。

秘密鍵のパスフレーズを含むファイルを指定し、各パスフレーズを別の行で指定します。パスフレーズは、鍵を読み込む際に順番に試行されます。

例

SSLv3 および TLS プロトコルを使用する場合、クライアント暗号よりもサーバ暗号を優先することを指定します。

Enables the specified protocols.

TLSv1.1 および TLSv1.2 パラメータ (1.1.1.13, 1.0.12) は OpenSSL 1.0.1 以降を使用している場合にのみ動作します。 TLSv1.3 パラメータ (1.13.0) は、TLSv1.3 をサポートして構築された OpenSSL 1.1.1 を使用している場合にのみ動作します。

セッションパラメータを保存するキャッシュのタイプとサイズを設定します。キャッシュは以下のタイプのいずれかになります。

off

セッションキャッシュの使用は厳密に禁止されています: nginx は明示的にクライアントにセッションを再利用してはならないと伝えています。

none

セッションキャッシュの使用は緩やかに禁止されています: nginx はクライアントにセッションを再利用することを伝えますが、実際にはセッションパラメータをキャッシュに保存しません。

builtin

OpenSSL で構築されたキャッシュで、1 つのワーカープロセスでのみ使用されます。キャッシュのサイズはセッションで指定します。サイズが指定されていない場合は、20480 セッションに相当します。ビルトインキャッシュを使用すると、メモリの断片化を引き起こす可能性があります。

shared

はすべてのワーカープロセス間で共有されるキャッシュです。キャッシュのサイズはバイト単位で指定され、1メガバイトで約4000セッションを保存できます。各共有キャッシュには任意の名前を付けなければなりません。同じ名前のキャッシュを複数のサーバーで使用することができます。 例えば、両方のキャッシュタイプを同時に使用することができます。

ssl_session_cache builtin:1000 shared:SSL:10m; が、内蔵キャッシュを使わずに共有キャッシュだけを使った方が効率的なはずです。

TLS セッションチケットの暗号化と復号化に使われる秘密鍵をファイルに設定します。このディレクティブは複数のサーバ間で同じ鍵を共有する必要がある場合に必要です。デフォルトでは、ランダムに生成された鍵が使われます。

複数の鍵が指定された場合は、最初の鍵のみが TLS セッションチケットの暗号化に使われます。これにより、例えば鍵のローテーションを設定することができます。

ssl_session_ticket_key current.key; ssl_session_ticket_key previous.key; ファイルには80バイトまたは48バイトのランダムデータが含まれている必要があり、以下のコマンドを使用して作成することができます。

openssl rand 80 > ticket.key ファイルサイズに応じて、暗号化には AES256 (80 バイト鍵、1.11.8) または AES128 (48 バイト鍵) を使用します。

TLS セッションチケットによるセッション再開を有効または無効にします。

クライアントがセッションパラメータを再利用できる時間を指定します。

クライアント証明書の検証に使用される PEM 形式の信頼できる CA 証明書を含むファイルを指定します。

ssl_client_certificate で設定された証明書とは対照的に、これらの証明書のリストはクライアントには送信されません。

クライアント証明書の検証を有効にする。検証結果は、認証要求の「Auth-SSL-Verify」ヘッダに渡される。

オプションのパラメータは、クライアント証明書を要求し、証明書が存在する場合に検証する。

optional_no_ca パラメータはクライアント証明書を要求しますが、信頼できる CA 証明書によって署名される必要はありません。これは、実際の証明書検証を nginx の外部サービスが行う場合に使用することを意図しています。証明書の内容は、認証サーバへのリクエストを通じてアクセス可能です。

クライアント証明書チェインの検証深度を設定します。

on

POP3にはSTLSコマンドを、IMAPとSMTPにはSTARTTLSコマンドを使用できるようにしました。

off

STLS および STARTTLS コマンドの使用を拒否します。

only

は、予備的な TLS 移行が必要です。

Module ngx_mail_imap_module

記述内容

IMAP クライアントで許可される認証方法を設定します。サポートされている方法は以下の通りです。

login

AUTH=LOGIN

plain

AUTH=PLAIN

cram-md5

AUTH=CRAM-MD5 とします。この方法を使用するには、パスワードを暗号化されていない状態で保存する必要があります。

external

AUTH=EXTERNAL (1.11.6).

CAPABILITYコマンドに応答してクライアントに渡されるIMAPプロトコル拡張リストを設定します。imap_auth ディレクティブと STARTTLS ディレクティブで指定された認証方法は、 starttls ディレクティブの値に応じて自動的にこのリストに追加されます。

クライアントがプロキシされる IMAP バックエンドでサポートされている拡張機能を指定することは理にかなっています (これらの拡張機能が認証後に使用されるコマンドに関連している場合、nginx がバックエンドへのクライアント接続を透過的にプロキシしている場合)。

現在の標準化された拡張機能のリストは www.iana.org で公開されています。

IMAP コマンドの読み込みに使用するバッファのサイズを設定します。デフォルトでは、バッファサイズは1メモリページに相当します。これは、プラットフォームに応じて4Kまたは8Kのいずれかです。

Module ngx_mail_pop3_module

記述内容

POP3 クライアントで許可される認証方法を設定します。サポートされている方法は以下の通りです。

plain

USER/PASS、AUTH PLAIN、AUTH LOGIN。これらの方法を無効にすることはできません。

apop

APOPを使用しています。この方法が機能するためには、パスワードを暗号化されていない状態で保存する必要があります。

cram-md5

AUTH CRAM-MD5。この方法が機能するためには、パスワードを暗号化されていない状態で保存する必要があります。

external

AUTH EXTERNAL（1.11.6）。

CAPA コマンドに応答してクライアントに渡される POP3 プロトコルの拡張子リストを設定します。pop3_auth ディレクティブで指定された認証方法 (SASL 拡張) と STLS は、starttls ディレクティブの値に応じて自動的にこのリストに追加されます。

クライアントがプロキシされる POP3 バックエンドでサポートされている拡張子を指定することは理にかなっています (これらの拡張子が認証後に使用されるコマンドに関連している場合、nginx がバックエンドへのクライアント接続を透過的にプロキシするとき)。

現在の標準化された拡張機能のリストは www.iana.org で公開されています。

Module ngx_mail_smtp_module

SMTP クライアントで許可される SASL 認証の方法を設定します。サポートされている方法は以下の通りです。

login

AUTH LOGIN

plain

AUTH PLAIN

cram-md5

AUTH CRAM-MD5。この方法を使用するには、パスワードを暗号化されていない状態で保存する必要があります。

external

AUTH EXTERNAL (1.11.6).

none

認証は不要です。

EHLOコマンドに応答してクライアントに渡されるSMTPプロトコル拡張リストを設定します。smtp_auth ディレクティブと STARTTLS で指定された認証方法は、starttls ディレクティブの値に応じて自動的にこのリストに追加されます。

クライアントがプロキシされる MTA でサポートされている拡張機能を指定することは理にかなっています (これらの拡張機能が認証後に使用されるコマンドに関連している場合、nginx がバックエンドへのクライアント接続を透過的にプロキシする際に使用されます)。

現在の標準化された拡張機能のリストは www.iana.org で公開されています。

SMTP コマンドの読み込みに使用するバッファのサイズを設定します。デフォルトでは、バッファサイズは1メモリページに相当します。これは、プラットフォームに応じて 4K または 8K のいずれかになります。

SMTPコマンドを送信する前のグリーティング待ちに失敗したクライアントを拒否するために、SMTPグリーティングを送信する前に遅延時間を設定することができます。

Module ngx_stream_core_module

ngx_stream_core_module モジュールはバージョン 1.9.0 以降で利用可能です。このモジュールはデフォルトではビルドされていないので、 --with-stream 設定パラメータで有効にする必要があります。

設定例

記述内容

記述内容

サーバが接続を受け付けるソケットのアドレスとポートを設定します。ポートだけを指定することも可能です。アドレスには、例えばホスト名を指定することもできます。

IPv6アドレスは角括弧で指定します。

UNIX ドメインのソケットは "unix:" 接頭辞で指定します。

listen unix:/var/run/nginx.sock; ポート範囲 (1.15.10) は、最初と最後のポートをハイフンで区切って指定します。

listen 127.0.0.1:12345-12399; listen 12345-12399; ssl パラメータでは、このポートで受け入れられたすべての接続が SSL モードで動作するように指定できます。

udpパラメータは、データグラムを扱うためのリスニングソケットを設定します(1.9.13)。同じセッションで同じアドレスとポートからのパケットを処理するには、reuseport パラメータも指定する必要があります。

プロキシされたサーバで作業する際にSSLセッションを再利用できるかどうかを決定します。SSL3_GET_FINISHED:digest check failed" というエラーがログに表示された場合は、セッションの再利用を無効にしてみてください。プロキシされたサーバへの接続で有効な暗号化方式を指定します。暗号化方式は OpenSSL ライブラリで理解できる形式で指定されます。

完全なリストは "openssl ciphers" コマンドで確認できます。

backlog=number

は listen() コールの backlog パラメータを設定し、保留中の接続のキューの最大長を制限します (1.9.2)。デフォルトでは、 FreeBSD、DragonFly BSD、macOS では backlog は -1 に、その他のプラットフォームでは 511 に設定されています。

rcvbuf=サイズ

リスニングソケット(1.11.13)の受信バッファサイズ(SO_RCVBUFオプション)を設定する。

sndbuf=サイズ

リスニングソケット(1.11.13)の送信バッファサイズ(SO_SNDBUFオプション)を設定します。

bind

このパラメータは、指定されたアドレス:ポートのペアに対して個別に bind() を呼び出すように指示します。実際には、同じポートで異なるアドレスを持つ複数の listen 記述内容があり、そのうちの一つが指定されたポート (*:port) のすべてのアドレスを listen している場合、nginx は *:port にのみ bind() を行います。この場合、接続を受け付けたアドレスを決定するために getsockname() システムコールが行われることに注意が必要です。ipv6only や so_keepalive パラメータが使用されている場合は、指定されたアドレス:ポートのペアに対して、常に個別の bind() コールが行われます。

ipv6only=on|off

このパラメータは、ワイルドカードアドレス[::]をリッスンしているIPv6ソケットがIPv6接続のみを受け入れるか、IPv6とIPv4の両方を受け入れるかを(IPV6_V6ONLY socketオプションを使用して)決定します。このパラメータはデフォルトでオンになっています。設定できるのは起動時に一度だけです。

reuseport

このパラメータ (1.9.1) は、カーネルがワーカープロセス間で着信接続を分散させることを可能にするために、 (Linux 3.9+ および DragonFly BSD では SO_REUSEPORT ソケットオプション、FreeBSD 12+ では SO_REUSEPORT_LB を使用して) 各ワーカープロセス用に個別のリスニングソケットを作成するように指示します。これはカーネルがワーカープロセス間で着信接続を分散できるようにします。 現在のところ、これは Linux 3.9+, DragonFly BSD, FreeBSD 12+ (1.15.1) でのみ動作します。 このオプションを不適切に使用すると、セキュリティに影響を及ぼす可能性があります。 so_keepalive=on|off|[keepidle]:[keepintvl]:[keepcnt] このパラメータは、リスニングソケットのTCPキープアライブの動作を設定します。このパラメータが省略された場合、オペレーティングシステムの設定がソケットに対して有効になります。このパラメータが "on "に設定されている場合、SO_KEEPALIVEオプションがソケットに対して有効になる。オフに設定した場合、SO_KEEPALIVEオプションはソケットに対してオフになる。一部のオペレーティングシステムでは、TCP_KEEPIDLE, TCP_KEEPINTVL, TCP_KEEPCNT ソケットオプションを使用して、ソケットごとに TCP keepalive パラメータの設定をサポートしている。このようなシステム (現在のところ Linux 2.4+, NetBSD 5+, FreeBSD 9.0-STABLE) では、keepidle, keepintvl, および keepcnt パラメータを使用して設定することができます。1つまたは2つのパラメータを省略した場合、対応するソケットオプションのシステムデフォルト設定が有効になります。例えば、以下のようになります。

so_keepalive=30m::10

はアイドルタイムアウト(TCP_KEEPIDLE)を30分に設定し、プローブ間隔(TCP_KEEPINTVL)をシステムデフォルトのままにして、プローブ数(TCP_KEEPCNT)を10プローブに設定します。 異なるサーバは、異なるアドレスとポートのペアでリッスンする必要があります。

プリリードバッファのサイズを指定します。

プリリードフェーズのタイムアウトを指定します。

PROXYプロトコルヘッダの読み込みが完了するまでのタイムアウトを指定します。この時間内にヘッダ全体が送信されない場合、接続は閉じられます。

上流のサーバの名前をアドレスに解決するために使用されるネームサーバを設定します。

resolver 127.0.0.0.1 [::1]:5353。

アドレスは、ドメイン名または IP アドレスとして指定でき、オプションのポートを指定します。ポートが指定されていない場合は、53番ポートが使用されます。ネームサーバーはラウンドロビン方式で照会されます。

デフォルトでは、nginx は IPv4 と IPv6 の両方のアドレスを検索して解決します。IPv6 アドレスを検索したくない場合は、ipv6=off パラメータを指定することができます。

デフォルトでは、nginx は応答の TTL 値を使って回答をキャッシュします。オプションの valid パラメータを指定すると、それを上書きすることができます。

resolver 127.0.0.1 [::1]:5353 valid=30s;

DNSスプーフィングを防ぐには、適切に保護された信頼できるローカルネットワークでDNSサーバーを構成することをお勧めします。 オプションの status_zone パラメータ (1.17.1) を使用すると、指定したゾーンのリクエストとレスポンスの DNS サーバー統計情報を収集できます。このパラメータは、当社の商用サブスクリプションの一部として利用できます。

バージョン 1.11.3 以前のバージョンでは、このディレクティブは商用購読の一部として利用可能でした。

名前解決のタイムアウトを設定します。

resolver_timeout 5s.

バージョン 1.11.3 より前のバージョンでは、このディレクティブは商用利用の一部として利用可能でした。

サーバーの構成を設定します。

ストリームサーバの記述内容を指定する設定ファイルのコンテキストを提供します。

TCP_NODELAY オプションの使用を有効または無効にします。このオプションは、クライアント接続とプロキシサーバ接続の両方で有効になります。

変数のハッシュテーブルのバケットサイズを設定します。ハッシュテーブルの設定の詳細は別のドキュメントで説明しています。

変数のハッシュテーブルの最大サイズを設定します。ハッシュテーブルの設定の詳細については、別のドキュメントに記載しています。

埋め込み変数 ngx_stream_core_moduleモジュールは1.11.2以降の変数をサポートしています。

$binary_remote_addr

バイナリ形式のクライアントアドレス、値の長さは IPv4 アドレスの場合は常に 4 バイト、IPv6 アドレスの場合は 16 バイトです。

$bytes_received

クライアントから受信したバイト数 (1.11.4)

$bytes_sent

送信バイト数

$connection

コネクションシリアル番号

$hostname

ホスト名

$msec

現在時刻をミリ秒単位で表示します。 $nginx_version nginxバージョン $pid 作業者プロセスのPID

$protocol

クライアントとの通信に使用されるプロトコル。TCP または UDP (1.11.4)

$proxy_protocol_addr

クライアントアドレスを PROXY プロトコルヘッダから取得します (1.11.4)。 PROXY プロトコルは listen ディレクティブで proxy_protocol パラメータを設定することで、事前に有効にしておかなければなりません。

$proxy_protocol_port

クライアントポートを PROXY プロトコルヘッダから指定します (1.11.4)。 PROXY プロトコルは listen ディレクティブで proxy_protocol パラメータを設定することで、事前に有効にしておかなければなりません。

$proxy_protocol_server_addr

サーバのアドレスを PROXY プロトコルヘッダから取得します (1.17.6)。 PROXY プロトコルは listen ディレクティブで proxy_protocol パラメータを設定することで、事前に有効にしておかなければなりません。

$proxy_protocol_server_port

サーバのポートを PROXY プロトコルヘッダから指定します (1.17.6)。 PROXY プロトコルは listen ディレクティブで proxy_protocol パラメータを設定することで、事前に有効にしておかなければなりません。

$remote_addr

クライアントアドレス

$remote_port

ポートクライアント

$server_addr

接続を受け付けたサーバのアドレス この変数の値を計算するには、通常、1回のシステムコールが必要です。システムコールを避けるために、listen 記述内容はアドレスを指定して bind パラメータを使用しなければなりません。

$server_port

接続を受け付けたサーバのポート

$session_time

セッションの持続時間をミリ秒単位で指定します (1.11.4)。

$status

セッションステータス(1.11.4)は、以下のいずれかになります。

200

セッション成功

400

クライアントデータが解析できませんでした。

403

アクセス禁止、例えば特定のクライアントアドレスにアクセスが制限されている場合など

500

内部サーバエラー

502

例えば、アップストリームサーバが選択されていないか、または到達できなかった場合などです。

503

接続数に制限がある場合などに利用できないサービス

$time_iso8601

ISO8601標準フォーマットでの現地時間

$time_local

コモンログフォーマットのローカルタイム

Module ngx_stream_access_module

ngx_stream_access_module モジュール (1.9.2) では、特定のクライアントアドレスへのアクセスを制限することができます。

設定例

ルールは、最初に一致するものが見つかるまで順番にチェックされます。この例では、IPv4ネットワーク10.1.1.1.0/16と192.168.1.1.1を除く192.168.1.0/24、およびIPv6ネットワーク2001:0db8::/32に対してのみアクセスが許可されています。

記述内容

指定したネットワークまたはアドレスへのアクセスを許可します。特別な値 unix: を指定すると、すべての UNIX ドメインのソケットに対してアクセスを許可します。

指定したネットワークまたはアドレスへのアクセスを拒否します。特別な値 unix: を指定すると、すべての UNIX ドメインソケットに対するアクセスを拒否します。

Module ngx_stream_geo_module

ngx_stream_geo_moduleモジュール(1.11.3)は、クライアントのIPアドレスに応じた値を持つ変数を作成します。

設定例

記述内容

指定した変数の値のクライアントIPアドレスに対する依存関係を記述します。デフォルトでは、アドレスは $remote_addr 変数から取得されますが、例えば別の変数から取得することもできます。

変数は使用時にのみ評価されるので、宣言された多数の「ジオ」変数が存在しても、接続処理のための余分なコストは発生しません。 変数の値が有効なIPアドレスを表さない場合、"255.255.255.255.255 "アドレスが使用されます。

アドレスは、CIDR表記の接頭辞（個々のアドレスを含む）または範囲として指定されます。

以下の特別なパラメータもサポートされています。

delete

指定したネットワークを削除します。

default

クライアントアドレスが指定されたアドレスのいずれとも一致しない場合に変数に設定される値。アドレスがCIDR表記で指定されている場合、デフォルトの代わりに "0.0.0.0.0/0 "と"::/0 "を使用することができます。defaultが指定されていない場合、デフォルト値は空文字列となります。

include

には、アドレスと値を含むファイルが含まれています。いくつかのインクルードがあります。

ranges

は、アドレスが範囲として指定されていることを示します。このパラメータは最初に指定する必要があります。ジオベースの読み込みを高速化するために、アドレスは昇順に配置する必要があります。

Example:

conf/geo.confファイルには以下の行が含まれている可能性があります。

最も具体的に一致する値が使用されます。例えば、127.0.0.0.1のアドレスでは、"US "ではなく "RU "が選択されます。

range を使った例。

Module ngx_stream_geoip_module

ngx_stream_geoip_moduleモジュール(1.11.3)は、コンパイル済みのMaxMindデータベースを使用して、クライアントのIPアドレスに応じた値を持つ変数を作成します。

IPv6 対応のデータベースを使用する場合、IPv4 アドレスは IPv4 マップされた IPv6 アドレスとして検索されます。

このモジュールはデフォルトではビルドされていないので、--with-stream_geoip_module設定パラメータで有効にする必要があります。

このモジュールには MaxMind GeoIP ライブラリが必要です。

設定例

記述内容

クライアントの IP アドレスに応じて国を決定するために使用するデータベースを指定します。このデータベースを使用する際には、以下の変数を使用できます。

$geoip_country_code

2文字の国コード、例えば "RU", "US "など。

$geoip_country_code3

3文字の国コード、例えば "RUS", "USA "など。

国コードは、"RUS"、"USA "などです。

国名、例えば "ロシア連邦"、"アメリカ合衆国 "など。

クライアントの IP アドレスに応じて国、地域、および都市を決定するために使用するデータベースを指定します。このデータベースを使用する際には、以下の変数を使用できます。

$geoip_area_code

電話番号の市外局番(米国のみ)です。 対応するデータベースフィールドが非推奨なので、この変数には古い情報が含まれている可能性があります。

$geoip_city_continent_code

2文字の大陸コード、例えば "EU", "NA "など。

$geoip_city_country_code

2文字の国コード、例えば "RU", "US "など。

$geoip_city_country_code3

3文字の国コード、例えば "RUS", "USA "など。

$geoip_city_country_name

国名、例えば "ロシア連邦"、"アメリカ合衆国 "など。

$geoip_dma_code

Google AdWords APIのジオターゲティングによると、米国のDMAリージョンコード（「メトロコード」とも呼ばれる）。

$geoip_latitude

緯度

緯度を指定してください。

経度。

$geoip_region

二文字国地域コード (地域, territory, state, province, federal land and the like), for example, “48”, “DC”.

$geoip_region_name

国の地域名（地域、領土、州、州、連邦の土地など）、例えば「モスクワ市」、「コロンビア特別区」など。

$geoip_city

都市名、例えば "モスクワ"、"ワシントン "など。

$geoip_postal_code

郵便番号

クライアントの IP アドレスに応じて組織を決定するために使用するデータベースを指定します。このデータベースを使用する場合は、次の変数を指定します。

$geoip_org

組織名、例えば "The University of Melbourne "など。

Module ngx_stream_js_module

ngx_stream_js_module モジュールは njs - JavaScript 言語のサブセット - にハンドラを実装するために使用されます。

ダウンロードとインストールの手順はこちらをご覧ください。

設定例

この例は0.4.0から動作します。

記述内容

アクセスフェーズで呼び出されるnjs関数を設定します。0.4.0以降、モジュール関数を参照できるようになりました。

データフィルタを設定します。0.4.0以降、モジュール関数を参照できるようになりました。

njsでロケーションハンドラと変数ハンドラを実装したモジュールをインポートします。export_nameはモジュールの関数にアクセスするための名前空間として使用されます。export_nameが指定されていない場合は、モジュール名が名前空間として使用されます。

js_import stream.jsを指定します。 ここでは、エクスポートにアクセスする際に、モジュール名のストリームが名前空間として使用されます。インポートされたモジュールに foo() が含まれている場合は、それを参照するために stream.foo が使用されます。

js_import 記述内容はいくつか指定できます。

njsでサーバーや変数のハンドラを実装するファイルを指定します。

nginx.conf:

stream.js:

このディレクティブは 0.4.0 以降では非推奨となっており、代わりに js_import ディレクティブを使うべきです。

njsモジュールの追加パスを設定します。

prereadフェーズで呼び出されるnjs関数を設定します。0.4.0以降、モジュール関数を参照できるようになりました。

指定した変数にnjs関数を設定します。0.4.0以降、モジュール関数を参照できるようになりました。

セッションオブジェクトのプロパティ 各ストリーム njs ハンドラは 1 つの引数、ストリームセッションオブジェクトを受け取ります。

Module ngx_stream_keyval_module

ngx_stream_keyval_module モジュール (1.13.7) は、API が管理するキーと値のペアから取得した値を持つ変数を作成します。

このモジュールは、商用サブスクリプションの一部として利用できます。

設定例

記述内容

新しい $variable を作成し、その値が key-value データベースのキーによって検索されるようにします。一致するルールは keyval_zone ディレクティブの type パラメータで定義されます。データベースはzoneパラメータで指定した共有メモリゾーンに格納されます。

キー値データベースを保持する共有メモリゾーンの名前とサイズを設定します。キーと値のペアはAPIによって管理されます。

オプションのstateパラメータは、キー値データベースの現在の状態をJSON形式で保持し、nginxの再起動時に永続化するファイルを指定します。

Examples:

SD

オプションの timeout パラメータ (1.15.0) は、キーと値のペアがゾーンから削除されるまでの時間を設定します。

オプションの type パラメータ (1.17.1) は、特定の型のキーのマッチングに最適化された追加のインデックスを有効にし、 keyval $variable を評価する際のマッチングルールを定義します。

インデックスは同じ共有メモリゾーンに格納されているため、追加のストレージが必要になります。

type=string

変数の検索は、レコードキーと検索キーの完全一致を使用して実行されます。

type=ip

レコードキーと一致するためには、検索キーはレコードキーで指定されたサブネットに属するか、IPアドレスと正確に一致しなければなりません。

type=prefix

変数の検索は、レコードキーと検索キーの接頭辞マッチを使用して行われます (1.17.5)。レコードキーにマッチするには、レコードキーが検索キーの接頭辞でなければなりません。 オプションのsyncパラメータ(1.15.0)を使用すると、共有メモリゾーンの同期が可能になります。同期化にはタイムアウト・パラメータの設定が必要です。

同期化が有効になっている場合、キーと値のペアの削除は(1つであってもすべてであっても)対象となるクラスタノードでのみ実行されます。他のクラスタノード上の同じキー値ペアは、タイムアウト時に削除されます。

Module ngx_stream_limit_conn_module

address.ngx_stream_limit_conn_module モジュール (1.9.3) は、定義されたキーごとの接続数、特に単一の IP アドレスからの接続数を制限するために使用します。

設定例

記述内容

共有メモリゾーンと、指定されたキー値に対して許可される最大接続数を設定します。この制限を超えると、サーバは接続を終了します。例えば

は一度に一つの IP アドレスに対して一つの接続しか許可しません。

複数の limit_conn ディレクティブが指定されている場合は、構成された制限が適用されます。

ディレクティブは、現在のレベルに limit_conn ディレクティブがない場合にのみ、前のレベルから継承されます。

ドライランモードを有効にします。このモードでは接続数に制限はありませんが、共有メモリゾーンでは通常通り過剰接続数を処理します。

サーバーが接続数を制限している場合のロギングレベルを設定します。

様々なキーの状態を保持する共有メモリゾーンのパラメータを設定します。特に、状態には現在の接続数が含まれます。キーには、テキスト、変数、およびそれらの組み合わせを含めることができます (1.11.2)。空のキー値を持つ接続は考慮されません。使用例。

limit_conn_zone $binary_remote_addr zone=addr:10m;

ここでは、変数$binary_remote_addrで設定されたクライアントIPアドレスがキーとなります。binary_remote_addrのサイズは、IPv4アドレスの場合は4バイト、IPv6アドレスの場合は16バイトです。保存される状態は、常に32ビットプラットフォームでは32バイトまたは64バイト、64ビットプラットフォームでは64バイトを占有します。1メガバイトのゾーンは、約32,000個の32バイトの状態、または約16,000個の64バイトの状態を保持することができる。ゾーンの保存容量を使い切った場合、サーバは接続を終了します。

さらに、商用利用の一環として、1.17.7以降のAPIを使用して、各共有メモリゾーンのステータス情報を取得したり、リセットしたりすることができます。

Embedded Variables

$limit_conn_status 接続数を制限した結果を保持します(1.17.6)。PASSED、REJECTED、またはREJECTED_DRY_RUN

Module ngx_stream_log_module

ngx_stream_log_moduleモジュール(1.11.4)は、指定したフォーマットでセッションログを書き込みます。

設定例

記述内容

バッファ付きログ書き込みのパス、フォーマット、および構成を設定します。同一レベルで複数のログを指定することができます。syslog へのログ記録は、最初のパラメータに "syslog:" という接頭辞を指定することで構成できます。特別な値 off は、現在のレベルのすべての access_log 記述内容をキャンセルします。

buffer または gzip パラメータが使用されている場合、ログへの書き込みはバッファリングされます。

バッファのサイズは、ディスクファイルへのアトミックライトのサイズを超えてはなりません。FreeBSD では、このサイズは無制限です。 バッファリングが有効な場合、データはファイルに書き込まれます。

次のログ行がバッファに収まらない場合。 バッファリングされたデータが flush パラメータで指定された値よりも古い場合。 ワーカープロセスがログファイルを再オープンしているとき、またはシャットダウンしているとき。 gzip パラメータが使用されている場合、バッファリングされたデータはファイルに書き込む前に圧縮されます。圧縮レベルは、1 (最速、低圧縮) から 9 (最遅、最高圧縮) の間で設定できます。デフォルトでは、バッファサイズは64Kバイトで、圧縮レベルは1に設定されています。 データはアトミックブロックで圧縮されているので、ログファイルはいつでも "zcat "によって解凍したり、読み込んだりすることができます。

Example:

access_log /path/to/log.gz basic gzip flush=5m;

gzip 圧縮が動作するためには、nginx は zlib ライブラリでビルドされている必要があります。 ファイルパスは変数を含むことができますが、そのようなログにはいくつかの制約があります。

ワーカープロセスで使用されている認証情報を持つユーザは、そのようなログを持つディレクトリにファイルを作成する権限を持っていなければなりません。 バッファリングされた書き込みは動作しません。 バッファリングされた書き込みは機能しません。しかし、頻繁に使われるファイルの記述子はキャッシュに保存されるので、 古いファイルへの書き込みは open_log_file_cache ディレクティブの有効なパラメータで指定された時間の間は続けることができます。 ifパラメータは条件付きロギングを有効にします。条件が "0" または空の文字列として評価された場合、セッションはログに記録されません。

escape パラメータ (1.11.8) は、変数内の json またはデフォルト文字のエスケープを設定することができ、デフォルトではデフォルトのエスケープが使用されます。noneパラメータ(1.13.10)は、エスケープを無効にします。

デフォルトのエスケープでは、"""", "", その他の値が 32 以下または 126 以上の文字は、"\xXX "としてエスケープされます。変数値が見つからない場合は、ハイフン("-")がログに記録されます。

jsonのエスケープでは、JSONの文字列で許可されていない全ての文字がエスケープされます。 characters “"” and “\” are escaped as “"” and “\”, characters with values less than 32 are escaped as “\n”, “\r”, “\t”, “\b”, “\f”, or “\u00XX”.

名前に変数が含まれているよく使うログのファイルディスクリプタを保存するキャッシュを定義します。このディレクティブのパラメータは以下の通りです。

max

キャッシュが一杯になった場合，最近使用された(LRU)ディスクリプタはクローズされます．

inactive

この時間内にアクセスがなかった場合に、キャッシュされたディスクリプタがクローズされる時間を設定します。

min_uses

は、記述子をキャッシュで開いたままにしておくために、inactiveパラメータで定義された時間内のファイル使用数の最小値を設定します。

valid

は、同じ名前のファイルがまだ存在することを確認する時間を設定します。

off

キャッシュオフ

Usage example:

open_log_file_cache max=1000 inactive=20s valid=1m min_uses=2;

 

Module ngx_stream_map_module

ngx_stream_map_moduleモジュール(1.11.2)は、他の変数の値に依存する変数を作成します。

設定例

記述内容

最初のパラメータで指定された1つ以上のソース変数の値に依存する値を持つ新しい変数を作成します。

変数は使用されたときにのみ評価されるので、大量の "マップ "変数を宣言しても、接続処理に余分なコストはかかりません。 マップブロック内のパラメータは、ソースと結果の値の間のマッピングを指定します。

ソース値は文字列または正規表現で指定されます。

文字列は大文字小文字を無視してマッチします。

正規表現は、大文字小文字を区別しないマッチングの場合は"~"シンボルから始まるか、大文字小文字を区別しないマッチングの場合は"~*"シンボルから始まるべきです。正規表現には、結果の変数と一緒に他の記述内容で後で使用できる名前付きのキャプチャと位置のキャプチャを含めることができます。

ソース値が、以下に説明する特別なパラメータの名前の一つに一致する場合、それは""シンボルの前に接頭辞を付けなければならない。

結果として得られる値は、テキスト、変数、およびそれらの組み合わせを含むことができます。

以下の特別なパラメータもサポートされています。

default value は、元の値が指定されたバリアントのどれにも一致しない場合に、結果の値を設定します。default が指定されていない場合、デフォルトの結果値は空の文字列となります。

hostnames は、ソース値が接頭辞または接尾辞マスク付きのホスト名であることを示します。

このパラメータは、値のリストの前に指定する必要があります。 include file には値を含むファイルが含まれます。いくつかのインクルードがあります。 volatile は、その変数がキャッシュできないことを示します (1.11.7)。 ソース値が指定されたバリアントのうちの1つ以上にマッチする場合、例えばマスクと正規表現の両方にマッチする場合、最初にマッチするバリアントが優先度の高い順に選択されます。

string value without a mask longest string value with a prefix mask, e.g. “.example.com” longest string value with a suffix mask, e.g. “mail.” 最初に一致する正規表現(設定ファイルの出現順)

default value

マップ変数ハッシュテーブルのバケットサイズを設定します。デフォルト値はプロセッサのキャッシュラインサイズに依存します。ハッシュテーブルの設定の詳細については、別のドキュメントを参照してください。

マップ変数のハッシュテーブルの最大サイズを設定します。ハッシュテーブルの設定の詳細については、別のドキュメントで説明します。

Module ngx_stream_proxy_module

ngx_stream_proxy_module モジュール (1.9.0) を使用すると、TCP、UDP (1.9.13)、UNIX ドメインソケット上でデータストリームをプロキシすることができます。

設定例

記述内容

指定されたローカルIPアドレスからプロキシサーバへの発信接続を行います。パラメータ値には変数を含めることができます (1.11.2)。特別な値 off を指定すると、以前の構成レベルから継承された proxy_bind ディレクティブの効果がキャンセルされ、システムがローカル IP アドレスを自動割り当てできるようになります。

transparent パラメータ (1.11.0) は、プロキシされたサーバへの発信接続を、例えばクライアントの実在の IP アドレスなど、ローカルではない IP アドレスから発信することを許可します。

proxy_bind $remote_addr transparent;

このパラメータを動作させるためには、通常、スーパーユーザ権限で nginx ワーカープロセスを実行する必要があります。Linux では、transparent パラメータが指定されている場合、ワーカープロセスはマスタープロセスから CAP_NET_RAW 機能を継承するため、このパラメータは必須ではありません (1.13.8)。また、プロキシされたサーバからのネットワークトラフィックを傍受するために、カーネルルーティングテーブルを設定する必要があります。

このディレクティブはバージョン 1.9.4 で登場しました。

プロキシされたサーバからデータを読み込むためのバッファのサイズを設定します。また、クライアントからのデータ読み込みに使用するバッファのサイズも設定します。

プロキシされたサーバとの接続を確立するためのタイムアウトを定義します。

プロキシされたサーバーからのデータの読み込み速度を制限します。レートは 1 秒あたりのバイト数で指定します。ゼロの値はレートの制限を無効にします。nginxが同時に2つの接続を開いた場合、全体の速度は指定された制限値の2倍になります。

パラメータ値には変数を含めることができます（1.17.0）。ある条件によってはレートを制限したい場合に便利かもしれません。

プロキシ先サーバへの接続が確立できなかった場合、クライアント接続を次のサーバに渡すかどうかを判断します。

次のサーバーに接続を渡すかどうかは、試行回数と時間によって制限されます。

次のサーバーへの接続を許可する時間を制限します。0 の値を指定すると、この制限は無効になります。

次のサーバーに接続を渡すための試行回数を制限します。0 の値を指定すると、この制限は無効になります。

プロキシされたサーバーのアドレスを設定します。アドレスは、ドメイン名またはIPアドレス、ポートを指定できます。

proxy_pass localhost:12345;

またはUNIXドメインのソケットパスとして使用します。

proxy_pass unix:/tmp/stream.socket;

ドメイン名が複数のアドレスに解決された場合、すべてのアドレスがラウンドロビン方式で使用されます。また、サーバーグループとしてアドレスを指定することもできる。

アドレスは変数を使って指定することもできます(1.11.3)。

proxy_pass $upstream;

この場合、記載されているサーバグループの中からサーバ名を検索し、見つからなければリゾルバを用いて決定する。

プロキシされたサーバーへの接続のためのPROXYプロトコルを有効にします。

クライアントと既存のUDPストリームセッション間の結合を解除するクライアントのデータグラム数を設定します。指定された数のデータグラムを受信した後、同じクライアントからの次のデータグラムを受信すると、新しいセッションが開始される。セッションは、すべてのクライアントデータグラムがプロキシサーバに送信され、期待される数の応答を受信したとき、またはタイムアウトに達したときに終了する。

UDPプロトコルが使用されている場合、クライアントのデータグラムに応答してプロキシされたサーバーから期待されるデータグラムの数を設定します。この数は、セッション終了のヒントとして機能します。既定では、データグラムの数は制限されません。

ゼロ値が指定された場合、応答は期待されない。しかし、応答を受信してもセッションが終了しない場合は、応答が処理されます。

プロキシサーバーがグループから削除された後、または永久に使用できないとマークされた後に、そのプロキシサーバーへのすべてのセッションを終了することを有効にします。これは、再リゾルブまたはAPI DELETEコマンドによって発生する可能性があります。サーバーが不健全であると判断された場合、またはAPI PATCHコマンドを使用して永久に利用できないとマークされることがあります。各セッションは、クライアントやプロキシされたサーバに対して次の読み書きイベントが処理されたときに終了します。

このディレクティブは商用の購読の一部として利用可能です。

プロキシされたサーバーへの発信接続の「TCP keepalive」動作を設定します。デフォルトでは、オペレーティングシステムの設定がソケットに対して有効になっています。ディレクティブの値が "on" に設定されている場合、SO_KEEPALIVE ソケットオプションがソケットに対して有効になります。

プロキシされたサーバーへの接続のための SSL/TLS プロトコルを有効にします。

プロキシされたサーバーへの認証に使用する PEM 形式の証明書のファイルを指定します。

プロキシされたサーバーへの認証に使用される PEM 形式の秘密鍵を持つファイルを指定します。

プロキシされたサーバへの接続で有効な暗号化方式を指定します。プロキシされたサーバへの接続で有効な暗号化方式を指定します。暗号化方式は OpenSSL ライブラリで理解できる形式で指定されます。

完全なリストは "openssl ciphers" コマンドで確認できます。

プロキシされたサーバーの証明書を検証するために使用される PEM 形式の失効した証明書 (CRL) を含むファイルを指定します。

プロキシ先サーバの証明書を検証し、プロキシ先サーバとの接続を確立する際に SNI を介して渡されるサーバ名をオーバーライドすることができます。サーバー名は変数を使用して指定することもできます (1.11.3)。

デフォルトでは、proxy_passアドレスのホスト部分が使用されます。

秘密鍵のパスフレーズを含むファイルを指定し、各パスフレーズを別の行で指定します。パスフレーズは、鍵の読み込み時に順番に試行されます。

プロキシされたサーバーへの接続に指定されたプロトコルを有効にします。

プロキシされたサーバーとの接続を確立する際に、TLS Server Name Indication extension (SNI, RFC 6066) を通じてサーバー名を渡すことを有効または無効にします。

プロキシされたサーバで作業する際にSSLセッションを再利用できるかどうかを決定します。SSL3_GET_FINISHED:digest check failed "というエラーがログに表示された場合は、セッションの再利用を無効にしてみてください。

プロキシされたサーバの証明書を検証するために使用される PEM 形式の信頼された CA 証明書を含むファイルを指定します。

プロキシされたサーバー証明書の検証を有効または無効にします。

プロキシされたサーバ証明書チェインの検証深度を設定します。

クライアントまたはプロキシされたサーバー接続で、2 つの連続した読み取りまたは書き込み操作の間のタイムアウトを設定します。この時間内にデータが送信されない場合、接続は閉じられます。

クライアントからのデータの読み込み速度を制限します。レートは 1 秒あたりのバイト数で指定します。ゼロの値を指定すると、レートの制限が無効になります。制限は 1 つの接続ごとに設定されるため、クライアントが同時に 2 つの接続を開いた場合、全体のレートは指定された制限の 2 倍になります。

パラメータ値には変数を含めることができます（1.17.0）。ある条件によってはレートを制限したい場合に便利です。

Module ngx_stream_realip_module

Embedded Variables ngx_stream_realip_module モジュールは、クライアントのアドレスとポートを PROXY プロトコルヘッダ (1.11.4) で送られてくるものに変更するために使用します。PROXY プロトコルは listen ディレクティブで proxy_protocol パラメータを設定することで、事前に有効にしておく必要があります。

このモジュールはデフォルトではビルドされていませんので、 --with-stream_realip_module 設定パラメータで有効にする必要があります。

設定例

記述内容

正しい置換アドレスを送信することが知られている信頼されたアドレスを定義します。特別な値 unix: が指定された場合、すべての UNIX ドメインソケットが信頼されます。

Embedded Variables

$realip_remote_addr

は元のクライアントアドレスを保持します。

$realip_remote_port

は元のクライアントポートを保持します。

Module ngx_stream_return_module

ngx_stream_return_module モジュール (1.11.2) では、指定した値をクライアントに送信してから接続を閉じることができます。

設定例

 

記述内容

クライアントに送信する値を指定します。値には、テキスト、変数、およびそれらの組み合わせを含めることができます。

Module ngx_stream_split_clients_module

ngx_stream_split_clients_moduleモジュール(1.11.3)は、スプリットテストとも呼ばれるA/Bテストに適した変数を作成します。

設定例

記述内容

例えば、A/Bテスト用の変数を作成します。

元の文字列の値を MurmurHash2 でハッシュ化します。この例では、0 から 21474835 (0.5%) までのハッシュ値が $variant 変数の値 ".one" に、21474836 から 107374180 (2%) までのハッシュ値が値 ".two" に、107374181 から 4294967295 までのハッシュ値が値 "" (空の文字列) に対応しています。

Module ngx_stream_ssl_module

ngx_stream_ssl_module モジュール (1.9.0) は、ストリームプロキシサーバが SSL/TLS プロトコルで動作するために必要なサポートを提供します。このモジュールはデフォルトではビルドされていないので、 --with-stream_ssl_module 設定パラメータで有効にしなければなりません。

設定例

プロセッサの負荷を軽減するには

ワーカープロセスの数をプロセッサの数と同じに設定します。 共有セッションキャッシュを有効にします。 内蔵のセッションキャッシュを無効にします。 また、セッションの有効時間を増やすこともできます (デフォルトでは 5 分)。

記述内容

指定したサーバの PEM 形式の証明書を含むファイルを指定します。一次証明書に加えて中間証明書を指定する場合は、次の順序で同じファイルに指定する必要があります。PEM 形式の秘密鍵を同じファイルに入れてもよい。

バージョン 1.11.0 以降では、このディレクティブを複数回指定して、RSA や ECDSA などの異なるタイプの証明書を読み込むことができます。

OpenSSL 1.0.2 以降では、異なる証明書に対して別々の証明書チェーンをサポートしています。それ以前のバージョンでは、1つの証明書チェーンしか使用できません。 バージョン1.15.9以降、OpenSSL 1.0.2以上では、ファイル名に変数を使用できるようになりました。

変数を使用することは、SSL ハンドシェイクのたびに証明書が読み込まれることを意味し、パフォーマンスに悪影響を及ぼす可能性があることに注意してください。

中間ファイルを使用せずに変数から証明書をロードするファイル(1.15.10)の代わりに、値 data:$variable を指定することができます。この構文を不適切に使用すると、秘密鍵データをエラーログに書き込むなどのセキュリティ上の意味合いがあることに注意してください。

指定したサーバーの PEM 形式の秘密鍵を持つファイルを指定します。

ファイルの代わりに engine:name:id を指定すると、OpenSSL エンジン名から指定された id で秘密鍵をロードします。

data:$variable は、中間ファイルを使用せずに変数から秘密鍵をロードするファイル (1.15.10) の代わりに指定することができます。この構文を不適切に使用すると、秘密鍵のデータをエラーログに書き込むなどのセキュリティ上の問題が生じる可能性があることに注意してください。

バージョン 1.15.9 以降、OpenSSL 1.0.2 以降では、ファイル名に変数を使用できるようになりました。

有効な暗号化方式を指定します。暗号化方式は、例えば OpenSSL ライブラリが理解する形式で指定します。

ssl_ciphers ALL:!aNULL:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP. 完全なリストは "openssl ciphers" コマンドで確認できます。

クライアント証明書の検証に使用される PEM 形式の信頼できる CA 証明書を含むファイルを指定します。

証明書のリストはクライアントに送られます。これが不要な場合は、ssl_trusted_certificate ディレクティブを使うことができます。

クライアント証明書の検証に使用される PEM 形式の失効した証明書 (CRL) を含むファイルを指定します。

DHE 暗号用の DH パラメータを持つファイルを指定します。 デフォルトではパラメータは設定されていないため、DHE 暗号は使用されません。 バージョン 1.11.0 より前のバージョンでは、組み込みのパラメータがデフォルトで使用されていました。

ECDHE暗号用のカーブを指定します。

OpenSSL 1.0.2以上を使用している場合、例えば1.11.0のように複数のカーブを指定することが可能です。

ssl_ecdh_curve prime256v1:secp384r1. 特別な値 auto (1.11.0) は、OpenSSL 1.0.2 以上、またはそれ以前のバージョンの prime256v1 を使用している場合に、nginx に OpenSSL ライブラリに組み込まれたリストを使用するように指示します。

バージョン 1.11.0 より前のバージョンでは、デフォルトで prime256v1 の曲線が使用されていました。

SSLハンドシェイクが完了するまでのタイムアウトを指定します。

秘密鍵のパスフレーズを含むファイルを指定し、各パスフレーズを別の行で指定します。パスフレーズは、鍵の読み込み時に順番に試行されます。

Example:

SSLv3 および TLS プロトコルを使用する場合、クライアント暗号よりもサーバ暗号を優先することを指定します。

指定したプロトコルを有効にします。

TLSv1.1 および TLSv1.2 パラメータは、OpenSSL 1.0.1 以降を使用している場合にのみ動作します。 TLSv1.3 パラメータ (1.13.0) は、TLSv1.3 をサポートして構築された OpenSSL 1.1.1 を使用している場合にのみ動作します。

セッションパラメータを保存するキャッシュのタイプとサイズを設定します。キャッシュは以下のタイプのいずれかになります。

off

セッションキャッシュの使用は厳密に禁止されています: nginx は明示的にクライアントにセッションを再利用してはならないと伝えています。

none

セッションキャッシュの使用は緩やかに禁止されています: nginx はクライアントにセッションを再利用することを伝えますが、実際にはセッションパラメータをキャッシュに保存しません。

builtin

OpenSSL で構築されたキャッシュで、1 つのワーカープロセスでのみ使用されます。キャッシュのサイズはセッション単位で指定します。サイズが指定されていない場合は、20480 セッションに相当します。ビルトインキャッシュを使用すると、メモリの断片化を引き起こす可能性があります。

shared

はすべてのワーカープロセス間で共有されるキャッシュです。キャッシュのサイズはバイト単位で指定され、1メガバイトで約4000セッションを保存できます。各共有キャッシュには任意の名前を付けなければなりません。同じ名前のキャッシュを複数のサーバーで使用することができます。 例えば、両方のキャッシュタイプを同時に使用することができます。

ssl_session_cache builtin:1000 shared:SSL:10m。

を使っていますが、組み込みキャッシュを使わずに共有キャッシュだけを使った方が効率が良いはずです。

TLS セッションチケットの暗号化と復号化に使われる秘密鍵をファイルに設定します。このディレクティブは複数のサーバ間で同じ鍵を共有する必要がある場合に必要です。デフォルトでは、ランダムに生成された鍵が使われます。

複数の鍵が指定された場合は、最初の鍵だけが TLS セッションチケットの暗号化に使われます。これにより、例えば鍵のローテーションを設定することができます。

ファイルには80バイトまたは48バイトのランダムデータが含まれている必要があり、以下のコマンドを使用して作成することができます。

TLS セッションチケットによるセッション再開を有効または無効にします。

クライアントがセッションパラメータを再利用できる時間を指定します。

クライアント証明書の検証に使用される PEM 形式の信頼できる CA 証明書を含むファイルを指定します。

ssl_client_certificate で設定された証明書とは対照的に、これらの証明書のリストはクライアントには送信されません。

クライアント証明書の検証を有効にします。検証結果は $ssl_client_verify 変数に格納されます。クライアント証明書の検証中にエラーが発生した場合や、クライアントが必要な証明書を提示していない場合は、接続を閉じます。

オプションのパラメータは、クライアント証明書を要求し、証明書が存在するかどうかを検証します。

optional_no_ca パラメータは、クライアント証明書を要求しますが、信頼できる CA 証明書による署名は要求しません。これは、実際の証明書検証を nginx の外部サービスが行う場合に使用することを意図しています。証明書の内容は $ssl_client_cert 変数からアクセスできます。

クライアント証明書チェインの検証深度を設定します。

Embedded Variables ngx_stream_ssl_moduleモジュールは1.11.2以降の変数をサポートしています。

$ssl_cipher

は、確立されたSSL接続に使われている暗号の名前を返します。

$ssl_ciphers

はクライアント (1.11.7) がサポートしている暗号化方式のリストを返します。既知の暗号は名前で表示され、未知の暗号は16進数で表示されます。 例：AES128-SHA:AES256-SHA:0x00ff この変数はOpenSSLバージョン1.0.2以上を使用している場合にのみ完全にサポートされます。古いバージョンでは、この変数は新しいセッションでのみ利用可能で、既知の暗号のみをリストアップします。

$ssl_client_cert

は、確立されたSSL接続のPEM形式のクライアント証明書を返します。 $ssl_client_fingerprint は、確立されたSSL接続(1.11.8)のクライアント証明書のSHA1フィンガープリントを返します。

$ssl_client_i_dn

は、RFC 2253 (1.11.8) に基づいて確立された SSL 接続用のクライアント証明書の "発行者 DN" 文字列を返します。

$ssl_client_raw_cert

は、確立された SSL 接続 (1.11.8) 用の PEM 形式のクライアント証明書を返します。

$ssl_client_s_dn

は、RFC 2253 (1.11.8) に基づいて確立された SSL 接続のクライアント証明書の "subject DN" 文字列を返します。

$ssl_client_serial

は、確立されたSSL接続(1.11.8)のクライアント証明書のシリアル番号を返します。

$ssl_client_v_end

クライアント証明書の終了日 (1.11.8) を返します。

$ssl_client_v_remain

は、クライアント証明書の有効期限が切れるまでの日数を返します (1.11.8)。

$ssl_client_v_start

は、クライアント証明書の開始日 (1.11.8) を返します。

$ssl_client_verify

は、クライアント証明書の検証結果を返します (1.11.8)。証明書が存在しない場合は "SUCCESS"、"FAILED:mason"、証明書が存在しない場合は "NONE "となります。

$ssl_curves

はクライアント(1.11.7)がサポートしている曲線のリストを返します。既知のカーブは名前でリストアップされ、未知のカーブは16進数で表示されます。 0x001d:prime256v1:secp521r1:secp384r1 この変数は OpenSSL バージョン 1.0.2 以降でのみサポートされています。それ以前のバージョンでは、変数の値は空の文字列になります。 この変数は新しいセッションでのみ使用可能です。

$ssl_protocol

は確立されたSSL接続のプロトコルを返します。

$ssl_server_name

SNI で要求されたサーバー名を返します。

$ssl_session_id

は確立されたSSL接続のセッション識別子を返します。

$ssl_session_reused

SSLセッションが再利用された場合は "r "を、そうでない場合は". "を返します。

Module ngx_stream_ssl_preread_module

ngx_stream_ssl_preread_module モジュール (1.11.5) を使うと、SSL/TLS を終了させずに ClientHello メッセージから情報を抽出することができます。このモジュールはデフォルトではビルドされていませんので、 --with-stream_ssl_preread_module 設定パラメータで有効にしてください。

設定例 サーバー名に基づいてアップストリームを選択します。

プロトコルに基づいてアップストリームを選択します。

SSLプロトコルのバージョンに基づいてアップストリームを選択します。

記述内容

プリリード時に ClientHello メッセージから情報を抽出できるようにします。

埋め込み変数
$ssl_preread_protocol

クライアントがサポートするSSLプロトコルの最高バージョン (1.15.2)

$ssl_preread_server_name

エスエヌアイで要求されたサーバ名

$ssl_preread_alpn_protocols

ALPN (1.13.10) を通じてクライアントがアドバタイズしたプロトコルのリスト。値はカンマで区切られています。

Module ngx_stream_upstream_module

ngx_stream_upstream_module モジュール (1.9.0) は、proxy_pass ディレクティブで参照できるサーバのグループを定義するために使用されます。

設定例

定期的なヘルスチェックを備えた動的に構成可能なグループは、当社の商用サブスクリプションの一部としてご利用いただけます。

記述内容

サーバーのグループを定義します。サーバは異なるポートでリッスンすることができます。さらに、TCPとUNIXドメインのソケットをリッスンするサーバを混在させることができます。

Example:

デフォルトでは、接続は加重ラウンドロビン分散方式を使用してサーバ間に分散されます。上記の例では、7つの接続が以下のように分散されます。5つの接続がbackend1.example.com:12345に行き、1つの接続が2番目と3番目のサーバに行きます。サーバとの通信中にエラーが発生した場合、その接続は次のサーバに渡されます。全てのサーバとの通信に失敗した場合は、接続を終了します。

サーバのアドレスやその他のパラメータを定義する。アドレスは、ドメイン名や義務的なポートを持つIPアドレス、または "unix: "接頭辞の後にUNIXドメインのソケットパスを指定することができる。複数のIPアドレスに解決するドメイン名は、一度に複数のサーバを定義する。

以下のパラメータを定義することができます。

weight=number

はサーバの重量を設定します。

max_conns=number

プロキシされたサーバへの最大同時接続数を制限します (1.11.5)。デフォルト値はゼロで、制限はありません。サーバーグループが共有メモリに存在しない場合、制限は各ワーカープロセスごとに動作します。 バージョン 1.11.5 より前のバージョンでは、このパラメータは商用サブスクリプションの一部として利用可能でした。

max_fails=number

は、fail_timeout パラメータで設定された持続時間内にサーバーとの通信に失敗した試行回数を設定します。デフォルトでは、失敗した試行の数は1に設定されています。 ゼロの値は試行の処理を無効にします。ここで、失敗した試行は、サーバーとの接続を確立している間のエラーまたはタイムアウトです。

fail_timeout=time
sets

指定された回数のサーバーとの通信に失敗した場合に、サーバーが利用できないと判断されるまでの時間。 サーバーが利用できないとみなされる期間。 デフォルトでは、このパラメータは10秒に設定されています。

backup

は、そのサーバーをバックアップサーバーとしてマークします。バックアップサーバーへの接続は、プライマリサーバーが利用できない場合に渡されます。 このパラメータは、ハッシュおよびランダムな負荷分散方法と一緒に使用することはできません。

down

は、サーバーを恒久的に利用できない状態にします。 さらに、以下のパラメータは、当社の商用サブスクリプションの一部として利用可能です。

resolve

は、サーバのドメイン名に対応するIPアドレスの変更を監視し、nginxを再起動することなく上流側の設定を自動的に変更します。サーバグループは共有メモリに存在する必要があります。 このパラメータを動作させるためには、ストリームブロックまたは対応するアップストリームブロックにリゾルバディレクティブを指定する必要があります。

service=name

DNS SRV レコードの解決を有効にし、サービス名を設定します (1.9.13)。このパラメータを動作させるためには、サーバの resolve パラメータを指定し、ポート番号を含まないホスト名を指定する必要があります。 サービス名にドット(".")が含まれていない場合は、RFC準拠の名前が構築され、サービスのプレフィックスにTCPプロトコルが追加されます。例えば、http.tcp.backend.example.comのSRVレコードを調べるには、ディレクティブを指定する必要があります。

server backend.example.com service=http resolve;

サービス名に 1 つ以上のドットが含まれている場合、サービス名はサービスの接頭辞とサーバ名を結合して作成されます。例えば、http.tcp.backend.example.com と server1.backend.example.com の SRV レコードを検索するには、ディレクティブを指定する必要があります。

server backend.example.com service=http.tcp resolve;
server example.com service=server1.backend resolve;

優先度の高いSRVレコード（同じ最下位の優先度値を持つレコード）はプライマリサーバとして解決され、残りのSRVレコードはバックアップサーバとして解決されます。サーバにbackupパラメータが指定されている場合、優先度の高いSRVレコードはバックアップサーバとして解決され、残りのSRVレコードは無視されます。

slow_start=time

は、不健康なサーバーが健康になったとき、または利用できないと考えられていた期間の後にサーバーが利用可能になったときに、サーバーがゼロから公称値に回復する時間を設定します。デフォルト値はゼロで、スロースタートは無効になっています。 このパラメータは、ハッシュやランダムな負荷分散方法と一緒に使用することはできません。 グループ内に1つのサーバーしかない場合、max_fails、fails_timeout、slow_startパラメータは無視され、そのようなサーバーは利用できないとは考えられません。

ワーカープロセス間で共有されるグループの設定とランタイム状態を保持する共有メモリゾーンの名前とサイズを定義します。複数のグループが同じゾーンを共有することがあります。この場合、サイズは一度だけ指定すれば十分です。

さらに、商用サブスクリプションの一部として、このようなグループは nginx を再起動することなく、グループのメンバーシップを変更したり、特定のサーバーの設定を変更したりすることができます。設定は API モジュール (1.13.3) からアクセスできます。

バージョン 1.13.3 より前のバージョンでは、設定は upstream_conf が扱う特別な場所からしかアクセスできませんでしたが、バージョン 1.13.3 より前のバージョンでは、設定は upstream_conf が扱う特別な場所からしかアクセスできませんでした。

このディレクティブはバージョン 1.9.7 で登場しました。

動的に設定可能なグループの状態を保持するファイルを指定します。

Examples:

現在の状態は、パラメータを持つサーバーのリストに限定されています。ファイルは設定を解析する際に読み込まれ、上流の設定が変更されるたびに更新されます。ファイルの内容を直接変更することは避けるべきです。このディレクティブはサーバディレクティブと一緒に使うことはできません。

設定のリロードやバイナリのアップグレード中に行われた変更は失われる可能性があります。 このディレクティブは商用の購読の一部として利用できます。

クライアントとサーバーのマッピングがハッシュ化されたキー値に基づいて行われるサーバーグループのロードバランシング方法を指定します。キーには、テキスト、変数、およびそれらの組み合わせを含めることができます (1.11.2)。使用例。

クライアントとサーバーのマッピングがハッシュ化されたキーの値に基づいているサーバー グループのロード バランシング方法を指定します。キーには、テキスト、変数、およびそれらの組み合わせを含めることができます (1.11.2)。使用例。

hash $remote_addr; グループからサーバを追加または削除すると、ほとんどのキーが異なるサーバにリマッピングされる可能性があることに注意してください。このメソッドは、Cache::Memcached Perl ライブラリと互換性があります。

一貫性パラメータを指定すると、代わりに ketama 一貫性ハッシュ・メソッドが使用されます。このメソッドは、サーバがグループに追加されたり、グループから削除されたりしたときに、少数のキーのみが異なるサーバにリマップされるようにします。これにより、キャッシュサーバのキャッシュヒット率を高めることができます。このメソッドは、ketama_points パラメータを 160 に設定した Cache::Memcached::Fast Perl ライブラリと互換性があります。

サーバーの重みを考慮して、アクティブな接続数が最も少ないサーバーに接続を渡す負荷分散方法をグループで使用することを指定します。このようなサーバが複数ある場合は、重み付きラウンドロビン分散方式を使って順番に試行されます。

グループが、サーバーの重みを考慮して、平均時間とアクティブな接続数が最も少ないサーバーに接続を渡す負荷分散方法を使用することを指定します。このようなサーバが複数ある場合は、重み付きラウンドロビン分散法を使用して順番に試行されます。

connectパラメータが指定された場合、上流のサーバに接続するまでの時間が使用されます。first_byte パラメータが指定された場合、最初のバイトのデータを受信するまでの時間を使用する。last_byte を指定した場合は、最後のバイトのデータを受信するまでの時間を使用する。また、flightパラメータを指定した場合(1.11.6)は、不完全接続も考慮します。

バージョン 1.11.6 より前のバージョンでは、不完全な接続はデフォルトで考慮されていました。 このディレクティブは商用の購読の一部として利用できます。

このディレクティブはバージョン 1.15.1 で登場しました。

サーバの重みを考慮して、ランダムに選択されたサーバに接続を渡す負荷分散方法を使うように指定します。

オプションの two パラメータは nginx に 2 台のサーバをランダムに選択し、指定された方法でサーバを選択するように指示します。デフォルトの方法は least_conn で、アクティブな接続数が最も少ないサーバーに接続を渡します。

least_timeメソッドは、平均時間が最も短く、アクティブな接続数が最も少ないサーバへの接続を渡します。least_time=connectパラメータが指定された場合、上流のサーバに接続するまでの時間が使用されます。least_time=first_byteパラメータが指定された場合、最初のバイトのデータを受信するまでの時間が使用されます。least_time=last_byte を指定した場合は、最後のバイトのデータを受信するまでの時間を使用する。

least_timeメソッドは、弊社の商用サブスクリプションの一部としてご利用いただけます。

このディレクティブはバージョン 1.17.5 で登場しました。

上流のサーバの名前をアドレスに解決するために使用するネームサーバを設定します。

resolver 127.0.0.0.1 [::1]:5353。 アドレスは、ドメイン名または IP アドレスとして指定でき、オプションのポートを指定します。ポートが指定されていない場合は、53番ポートが使用されます。ネームサーバーはラウンドロビン方式で問い合わせを行います。

デフォルトでは、nginx は IPv4 と IPv6 の両方のアドレスを検索して解決します。IPv6 アドレスを検索したくない場合は、ipv6=off パラメータを指定することができます。

デフォルトでは、nginx は応答の TTL 値を使って回答をキャッシュします。オプションの valid パラメータを使用すると、これを上書きすることができます。

resolver 127.0.0.0.1 [::1]:5353 valid=30s. DNSスプーフィングを防ぐには、適切に保護された信頼できるローカルネットワークでDNSサーバを構成することをお勧めします。 オプションの status_zone パラメータは、指定されたゾーンでのリクエストとレスポンスの DNS サーバの統計情報を収集することを可能にします。

このディレクティブは商用の購読の一部として利用できます。

このディレクティブはバージョン 1.17.5 で登場しました。

名前解決のタイムアウトを設定します。

resolver_timeout 5s。 このディレクティブは商用サブスクリプションの一部として利用可能です。 埋め込まれた変数 ngx_stream_upstream_moduleモジュールは、以下の組み込み変数をサポートしています。

$upstream_addr

はIPアドレスとポート、またはアップストリームサーバのUNIXドメインソケットへのパス(1.11.4)を保持します。プロキシ中に複数のサーバに連絡があった場合、それらのアドレスはカンマで区切られます。サーバを選択できない場合、変数はサーバグループの名前を保持します。

$upstream_bytes_received

アップストリームサーバから受信したバイト数 (1.11.4)。複数のコネクションからの値は、$upstream_addr変数のアドレスのようにカンマで区切られています。

$upstream_bytes_sent

アップストリームサーバに送信したバイト数 (1.11.4)。複数のコネクションからの値は、$upstream_addr変数のアドレスのようにカンマで区切られています。

$upstream_connect_time

アップストリームサーバ (1.11.4) に接続するまでの時間を指定します。複数の接続の時間は、変数 $upstream_addr のアドレスのようにカンマで区切られています。

$upstream_first_byte_time

データの最初のバイトを受信するまでの時間 (1.11.4); この時間はミリ秒の分解能で秒単位で保持されます。複数の接続の時間は、$upstream_addr変数のアドレスのようにカンマで区切られています。

$upstream_session_time

セッションの持続時間をミリ秒単位で指定します (1.11.4)。複数の接続の時間は、変数 $upstream_addr のアドレスのようにカンマで区切られています。

Module ngx_stream_upstream_hc_module

ngx_stream_upstream_hc_module モジュール (1.9.0) を使用すると、グループ内のサーバの定期的なヘルスチェックが可能になります。サーバグループは共有メモリに存在しなければなりません。

ヘルスチェックが失敗した場合、そのサーバは不健康とみなされます。同じグループのサーバに対して複数のヘルスチェックが定義されている場合、いずれかのチェックが一度でも失敗すると、対応するサーバは不健康とみなされます。クライアント接続は、不健康なサーバや「チェック中」状態のサーバには渡されません。

このモジュールは、当社の商用サブスクリプションの一部としてご利用いただけます。

設定例

この設定では、nginx は tcp グループ内の各サーバへの TCP 接続を 5 秒ごとに確立できるかどうかをチェックします。サーバーへの接続が確立できない場合、ヘルスチェックは失敗し、そのサーバーは不健康とみなされます。

ヘルスチェックはUDPプロトコルに対して設定することができます。

この場合、送信された文字列 "nginx health check "の返信にICMP "Destination Unreachable "メッセージがないことが予想されます。

ヘルスチェックはサーバから取得したデータをテストするように設定することもできます。テストは match ディレクティブを使って個別に設定され、 health_check ディレクティブの match パラメータで参照されます。

記述内容

グループ内のサーバーの定期的なヘルスチェックを有効にします。

以下のオプションのパラメータがサポートされています。

interval=time

は、2 つの連続したヘルスチェックの間隔を設定します。

jitter=time

は、各ヘルスチェックがランダムに遅延する時間を設定します。

fails=number

特定のサーバのヘルスチェックに連続して失敗した回数を設定します。

passes=number

特定のサーバのヘルスチェックに連続してパスした回数を設定します。 必須 は、最初のヘルスチェックが完了するまでの間、サーバの最初の「チェック中」状態を設定します (1.11.7)。クライアント接続は、「検査中」状態のサーバーには渡されません。パラメータが指定されていない場合、サーバーは最初に健康状態とみなされます。

match=name

は、接続が成功した場合にヘルスチェックが通過するためのテストを構成するマッチブロックを指定します。デフォルトでは、TCP の場合、サーバとの TCP 接続を確立する能力のみがチェックされます。UDP では、送信された文字列 "nginx health check" の返信に ICMP "Destination Unreachable" メッセージがないことが期待されます。 バージョン 1.11.7 より前のバージョンでは、デフォルトでは、UDP のヘルスチェックは send および expect パラメータとのマッチブロックを必要としていました。

port=number

は、ヘルスチェックを実行するためにサーバに接続する際に使用するポートを定義します (1.9.7)。デフォルトでは、サーバのポートに等しくなります。

udp

は、デフォルトのTCPプロトコル(1.9.13)の代わりにUDPプロトコルをヘルスチェックに使用することを指定します。

ヘルスチェックのproxy_timeout値をオーバーライドします。

ヘルスチェックに対するサーバーの応答を検証するために使用する名前付きテストセットを定義します。

以下のパラメータを構成できます。

リテラル文字列(1.9.12)またはサーバから取得したデータが一致するべき正規表現を指定します。正規表現は、前の"~*"修飾子(大文字小文字を区別しないマッチングの場合)、または "~"修飾子(大文字小文字を区別しないマッチングの場合)で指定される。 sendパラメータとexpectパラメータの両方とも、接頭辞「\x」の後に2つの16進数が続く16進リテラルを 含むことができる(例えば、「\x80」(1.9.12)。

Health check is passed if:

TCP 接続が正常に確立されました。 send パラメータの文字列 (指定されている場合) が送信されました。 サーバから得られたデータが、指定されている場合は expect パラメータの文字列または正規表現と一致している。 経過時間が health_check_timeout ディレクティブで指定された値を超えていない。

Example:

サーバから取得したデータの最初のproxy_buffer_sizeバイトのみを検査する。

Module ngx_stream_zone_sync_module

ngx_stream_zone_sync_module モジュール (1.13.8) は、クラスタのノード間で共有メモリゾーンのコンテンツを同期化するために必要なサポートを提供します。特定のゾーンの同期を有効にするには、対応するモジュールがこの機能をサポートしていなければなりません。現在のところ、HTTP スティッキーセッション、過剰な HTTP リクエストに関する情報、キーと値のペアを http とストリームの両方で同期させることが可能です。

このモジュールは、当社の商用サブスクリプションの一部としてご利用いただけます。

設定例

最小限の構成。

SSLを有効にし、DNSで定義されたクラスタメンバーを使用して、より複雑な設定を行います。

 

記述内容

クラスタノード間の共有メモリゾーンの同期を有効にします。クラスタノードは zone_sync_server ディレクティブを使用して定義されます。

ゾーンコンテンツのプッシュに使用するゾーンごとのバッファの数とサイズを設定します。デフォルトでは、バッファサイズは1メモリページに相当します。これは、プラットフォームに応じて4Kまたは8Kのいずれかである。

1つのバッファは、同期化される各ゾーンのエントリを保持するのに十分な大きさでなければなりません。

別のクラスタノードへの接続試行の間隔を定義します。

他のクラスタノードとの接続を確立するためのタイムアウトを定義します。

共有メモリゾーンの更新をポーリングする間隔を定義します。

同期メッセージの受信ストリームを解析するために使用する接続ごとの受信バッファのサイズを設定します。バッファサイズはzone_sync_buffersの1つ以上でなければなりません。デフォルトでは、バッファサイズはzone_sync_buffersのサイズに数値を掛けたものになります。

クラスタノードのアドレスを定義します。アドレスは、ドメイン名または必須ポートを持つIPアドレス、または "unix: "接頭辞の後に指定されたUNIXドメインのソケットパスとして指定することができます。複数の IP アドレスに解決するドメイン名は、複数のノードを一度に定義します。

resolveパラメータは、ノードのドメイン名に対応するIPアドレスの変更を監視し、nginxを再起動することなく自動的に設定を変更するように指示します。

クラスタノードは動的にresolveパラメータを持つ単一のzone_sync_serverディレクティブとして指定されるか、静的にはパラメータを持たない複数のディレクティブとして指定されます。

各クラスタノードは一度だけ指定する必要があります。 すべてのクラスタノードは同じ設定を使用しなければなりません。 resolve パラメータが動作するためには、ストリームブロックで resolve ディレクティブを指定しなければなりません。

Example:

別のクラスタサーバーへの接続のためのSSL/TLSプロトコルを有効にします。

他のクラスタサーバへの認証に使用する PEM 形式の証明書を含むファイルを指定します。

他のクラスタサーバへの認証に使用されるPEM形式の秘密鍵を持つファイルを指定します。

別のクラスタサーバへの接続で有効な暗号化方式を指定します。暗号化方式は OpenSSL ライブラリで理解される形式で指定されます。

完全なリストは "openssl ciphers" コマンドで確認できます。

別のクラスタサーバの証明書を検証するために使用される PEM 形式の失効した証明書 (CRL) を含むファイルを指定します。

クラスタサーバとの接続を確立する際に、クラスタサーバの証明書を検証し、SNI に渡すために使用されるサーバ名をオーバーライドすることができます。

デフォルトでは、zone_sync_server アドレスのホスト部分、または resolve パラメータが指定されている場合は解決済みの IP アドレスが使用されます。

秘密鍵のパスフレーズを含むファイルを指定し、各パスフレーズを別の行で指定します。パスフレーズは、鍵の読み込み時に順番に試行されます。

別のクラスタサーバへの接続のために指定されたプロトコルを有効にします。

他のクラスタサーバとの接続を確立する際に、TLS Server Name Indication extension (SNI, RFC 6066) を通してサーバ名を渡すことを有効または無効にします。

別のクラスタサーバの証明書を検証するために使用される PEM 形式の信頼できる CA 証明書を含むファイルを指定します。

別のクラスタサーバ証明書の検証を有効または無効にします。

別のクラスタサーバ証明書チェーンの検証深度を設定します。

他のクラスタノードへの接続における2つの連続した読み取りまたは書き込み操作の間のタイムアウトを設定します。この時間内にデータが送信されなかった場合、接続は閉じられます。

API エンドポイント

ノードの同期状態は、以下のメトリックを返すAPIの/stream/zone_sync/エンドポイントを介して利用できます。

クラスタノードの起動、停止、削除

新しいノードを起動するには、クラスタホスト名のDNSレコードを新しいノードのIPアドレスで更新し、インスタンスを起動します。新しいノードはDNSまたは静的構成から他のノードを検出し、それらのノードへの更新の送信を開始します。他のノードは最終的にDNSを使用して新しいノードを発見し、そのノードへの更新のプッシュを開始します。静的構成の場合、新しいノードに更新を送信するためには、他のノードをリロードする必要があります。

ノードを停止するには、インスタンスにQUIT信号を送信します。ノードはゾーン同期を終了し、開いている接続を優雅に閉じます。

ノードを削除するには、クラスタホスト名のDNSレコードを更新し、ノードのIPアドレスを削除します。他のすべてのノードは最終的にノードが削除されたことを発見し、そのノードへの接続を閉じ、そのノードに接続しようとしなくなります。ノードが削除された後は、上記のようにノードを停止することができます。静的構成の場合、削除されたノードへの更新情報の送信を停止するためには、他のノードをリロードする必要があります。

Module ngx_google_perftools_module

ngx_google_perftools_module モジュール (0.6.29) は、Google Performance Tools を使用して nginx ワーカープロセスのプロファイリングを可能にします。このモジュールは nginx 開発者向けです。

このモジュールはデフォルトではビルドされていないので、 --with-google_perftools_module 設定パラメータで有効にする必要があります。

このモジュールには gperftools ライブラリが必要です。

設定例

google_perftools_profiles /path/to/profile;

プロファイルは、/path/to/profile.<worker_pid>として保存されます。

記述内容

nginxワーカープロセスのプロファイリング情報を保持するファイル名を設定します。ワーカープロセスのIDは常にファイル名の一部であり、ファイル名の末尾にドットの後に付加されます。