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ディレクティブの効果をキャンセルすることを可能にします。

ユーザー名とパスワードを保持するファイルを次の形式で指定します。