モジュール ngx_http_uwsgi_module

ngx_http_uwsgi_moduleモジュールは、uwsgiサーバーへのリクエストの受け渡しを可能にします。

location / {
    include    uwsgi_params;
    uwsgi_pass localhost:9000;
}

uwsgiサーバーへの発信接続を、指定されたローカルIPアドレスとオプションのポート（1.11.2）から発生させます。パラメータ値には変数を含めることができます（1.3.12）。特別な値off（1.3.12）は、前の構成レベルから継承されたuwsgi_bindディレクティブの効果をキャンセルし、システムがローカルIPアドレスとポートを自動割り当てできるようにします。

transparentパラメーター（1.11.0）を使用すると、uwsgiサーバーへの発信接続を、クライアントの実際のIPアドレスなど、ローカルではないIPアドレスから発生させることができます。

uwsgi_bind $remote_addr transparent;

このパラメーターを機能させるには、通常、スーパーユーザー権限でnginxワーカープロセスを実行する必要があります。Linuxでは、transparentパラメーターが指定されている場合、ワーカープロセスはマスタープロセスからCAP_NET_RAW機能を継承するため、（1.13.8）は必要ありません。uwsgiサーバーからのネットワークトラフィックをインターセプトするようにカーネルルーティングテーブルを構成する必要もあります。

uwsgi_buffer_size 4k|8k;

uwsgiサーバーから受信した応答の最初の部分を読み取るために使用されるバッファのsizeを設定します。この部分には通常、小さな応答ヘッダーが含まれます。デフォルトでは、バッファサイズは1つのメモリーページと同じです。これは、プラットフォームに応じて4Kまたは8Kのいずれかです。ただし、小さくすることもできます。

uwsgi_buffering on;

uwsgiサーバーからの応答のバッファリングを有効または無効にします。

バッファリングが有効になっている場合、nginxはuwsgiサーバーから可能な限り早く応答を受信し、uwsgi_buffer_sizeおよびuwsgi_buffersディレクティブで設定されたバッファに保存します。応答全体がメモリに収まらない場合は、その一部をディスク上の一時ファイルに保存できます。一時ファイルへの書き込みは、uwsgi_max_temp_file_sizeおよびuwsgi_temp_file_write_sizeディレクティブによって制御されます。

バッファリングが無効になっている場合、応答は受信されるとすぐにクライアントに同期的に渡されます。nginxは、uwsgiサーバーから応答全体を読み取ろうとはしません。nginxがサーバーから一度に受信できるデータの最大サイズは、uwsgi_buffer_sizeディレクティブによって設定されます。

バッファリングは、 "X-Accel-Buffering"応答ヘッダーフィールドに "yes"または "no"を渡すことによって有効または無効にすることもできます。この機能は、uwsgi_ignore_headersディレクティブを使用して無効にできます。

uwsgi_buffers 8 4k|8k;

単一の接続のために、uwsgiサーバーからの応答の読み取りに使用されるバッファのnumberとsizeを設定します。デフォルトでは、バッファサイズは1つのメモリーページと同じです。これは、プラットフォームに応じて4Kまたは8Kのいずれかです。

uwsgi_busy_buffers_size 8k|16k;

uwsgiサーバーからの応答のバッファリングが有効になっている場合、応答が完全に読み取られていない間に、クライアントに応答を送信するために使用できるバッファの合計sizeを制限します。その間、残りのバッファは応答の読み取りに使用でき、必要に応じて、応答の一部を一時ファイルにバッファリングできます。デフォルトでは、sizeは、uwsgi_buffer_sizeおよびuwsgi_buffersディレクティブで設定された2つのバッファのサイズによって制限されます。

uwsgi_cache off;

キャッシュに使用される共有メモリゾーンを定義します。同じゾーンを複数の場所で使用できます。パラメーター値には変数を含めることができます（1.7.9）。offパラメーターは、前の構成レベルから継承されたキャッシュを無効にします。

uwsgi_cache_background_update off;

期限切れのキャッシュアイテムを更新するためのバックグラウンドサブリクエストの開始を許可し、同時に古いキャッシュされた応答をクライアントに返します。更新中に古いキャッシュされた応答の使用を許可する必要があることに注意してください。

応答がキャッシュから取得されない条件を定義します。文字列パラメーターの少なくとも1つの値が空でなく、 "0"に等しくない場合、応答はキャッシュから取得されません

uwsgi_cache_bypass $cookie_nocache $arg_nocache$arg_comment;
uwsgi_cache_bypass $http_pragma    $http_authorization;

uwsgi_no_cacheディレクティブと一緒に使用できます。

キャッシュのキーを定義します。例：

uwsgi_cache_key localhost:9000$request_uri;

uwsgi_cache_lock off;

有効にすると、uwsgi_cache_keyディレクティブに従って識別された新しいキャッシュ要素を設定するために、一度に1つのリクエストのみがuwsgiサーバーにリクエストを渡すことが許可されます。同じキャッシュ要素の他のリクエストは、キャッシュに応答が表示されるか、この要素のキャッシュロックがuwsgi_cache_lock_timeoutディレクティブで設定された時間まで解放されるのを待ちます。

uwsgi_cache_lock_age 5s;

新しいキャッシュ要素を設定するためにuwsgiサーバーに渡された最後の要求が、指定されたtimeの間完了しなかった場合、もう1つの要求がuwsgiサーバーに渡される可能性があります。

uwsgi_cache_lock_timeout 5s;

uwsgi_cache_lockのタイムアウトを設定します。timeが期限切れになると、リクエストはuwsgiサーバーに渡されますが、応答はキャッシュされません。

1.7.8より前では、応答はキャッシュされる可能性がありました。

バイト範囲リクエストのオフセットをバイト単位で設定します。範囲がオフセットを超える場合、範囲リクエストはuwsgiサーバーに渡され、応答はキャッシュされません。

uwsgi_cache_methods GET HEAD;

クライアントリクエストメソッドがこのディレクティブにリストされている場合、応答はキャッシュされます。"GET"および "HEAD"メソッドは常にリストに追加されますが、明示的に指定することをお勧めします。uwsgi_no_cacheディレクティブも参照してください。

uwsgi_cache_min_uses 1;

応答がキャッシュされるまでのリクエストのnumberを設定します。

キャッシュのパスとその他のパラメーターを設定します。キャッシュデータはファイルに保存されます。キャッシュ内のファイル名は、キャッシュキーにMD5関数を適用した結果です。levelsパラメーターは、キャッシュの階層レベルを定義します。1〜3まで、各レベルは値1または2を受け入れます。たとえば、次の構成では

uwsgi_cache_path /data/nginx/cache levels=1:2 keys_zone=one:10m;

キャッシュ内のファイル名は次のようになります

/data/nginx/cache/c/29/b7f54b2df7773722d382f4809d65029c

キャッシュされた応答は最初一時ファイルに書き込まれ、次にファイルの名前が変更されます。バージョン0.8.9以降、一時ファイルとキャッシュを異なるファイルシステムに配置できます。ただし、この場合、安価な名前変更操作の代わりに、ファイルが2つのファイルシステム間でコピーされることに注意してください。したがって、特定の場所では、キャッシュと一時ファイルを保持するディレクトリの両方を同じファイルシステムに配置することをお勧めします。一時ファイルのディレクトリは、use_temp_pathパラメーター（1.7.10）に基づいて設定されます。このパラメーターが省略されているか、値onに設定されている場合、指定された場所のuwsgi_temp_pathディレクティブで設定されたディレクトリが使用されます。値がoffに設定されている場合、一時ファイルはキャッシュディレクトリに直接配置されます。

さらに、すべてのアクティブなキーとデータに関する情報は、共有メモリゾーンに保存され、そのnameとsizeはkeys_zoneパラメーターで構成されます。1メガバイトのゾーンには、約8千のキーを保存できます。

商用サブスクリプションの一部として、共有メモリゾーンには拡張キャッシュの情報も保存されるため、同じ数のキーに対してより大きなゾーンサイズを指定する必要があります。たとえば、1メガバイトのゾーンには、約4千のキーを保存できます。

inactiveパラメーターで指定された時間内にアクセスされないキャッシュデータは、その鮮度に関係なくキャッシュから削除されます。デフォルトでは、inactiveは10分に設定されています。

特別な「キャッシュマネージャー」プロセスは、max_sizeパラメータで設定された最大キャッシュサイズと、キャッシュを持つファイルシステム上のmin_free（1.19.1）パラメータで設定された最小空き容量を監視します。サイズが超過した場合、または十分な空き容量がない場合、最も最近使用されていないデータを削除します。データの削除は、manager_files、manager_threshold、manager_sleepパラメータ（1.11.5）で設定されたイテレーションで行われます。1回のイテレーションで、manager_filesを超えるアイテムは削除されません（デフォルトは100）。1回のイテレーションの実行時間は、manager_thresholdパラメータ（デフォルトは200ミリ秒）で制限されます。イテレーションの間には、manager_sleepパラメータ（デフォルトは50ミリ秒）で設定された一時停止が行われます。

開始から1分後、特別な「キャッシュローダー」プロセスがアクティブになります。このプロセスは、ファイルシステムに保存されている以前にキャッシュされたデータに関する情報をキャッシュゾーンにロードします。ロードもイテレーションで行われます。1回のイテレーションで、loader_filesを超えるアイテムはロードされません（デフォルトは100）。さらに、1回のイテレーションの実行時間は、loader_thresholdパラメータ（デフォルトは200ミリ秒）で制限されます。イテレーションの間には、loader_sleepパラメータ（デフォルトは50ミリ秒）で設定された一時停止が行われます。

さらに、以下のパラメータは、当社の商用サブスクリプションの一部として利用可能です。

purger=on|off

ワイルドカードキーに一致するキャッシュエントリをキャッシュパーガーによってディスクから削除するかどうかを指示します（1.7.12）。パラメータをonに設定すると（デフォルトはoff）、すべてのキャッシュエントリを永続的にイテレーション処理し、ワイルドカードキーに一致するエントリを削除する「キャッシュパーガー」プロセスがアクティブになります。

purger_files=number

1回のイテレーション中にスキャンされるアイテム数を設定します（1.7.12）。デフォルトでは、purger_filesは10に設定されています。

purger_threshold=number

1回のイテレーションの実行時間を設定します（1.7.12）。デフォルトでは、purger_thresholdは50ミリ秒に設定されています。

purger_sleep=number

イテレーション間の一時停止を設定します（1.7.12）。デフォルトでは、purger_sleepは50ミリ秒に設定されています。

バージョン1.7.3、1.7.7、および1.11.10では、キャッシュヘッダーの形式が変更されました。以前にキャッシュされたレスポンスは、新しいnginxバージョンにアップグレードした後、無効と見なされます。

リクエストがキャッシュパージリクエストと見なされる条件を定義します。文字列パラメータの少なくとも1つの値が空ではなく、「0」と等しくない場合、対応するキャッシュキーを持つキャッシュエントリが削除されます。正常な操作の結果は、204（No Content）レスポンスを返すことで示されます。

パージリクエストのキャッシュキーがアスタリスク（「*」）で終わる場合、ワイルドカードキーに一致するすべてのキャッシュエントリがキャッシュから削除されます。ただし、これらのエントリは、非アクティブのために削除されるか、キャッシュパーガー（1.7.12）によって処理されるか、クライアントがアクセスしようとするまで、ディスク上に残ります。

設定例

uwsgi_cache_path /data/nginx/cache keys_zone=cache_zone:10m;

map $request_method $purge_method {
    PURGE   1;
    default 0;
}

server {
    ...
    location / {
        uwsgi_pass        backend;
        uwsgi_cache       cache_zone;
        uwsgi_cache_key   $uri;
        uwsgi_cache_purge $purge_method;
    }
}

この機能は、当社の商用サブスクリプションの一部として利用可能です。

uwsgi_cache_revalidate off;

「If-Modified-Since」および「If-None-Match」ヘッダーフィールドを使用した条件付きリクエストを使用して、期限切れのキャッシュアイテムの再検証を有効にします。

uwsgi_cache_use_stale off;

uwsgiサーバーとの通信中にエラーが発生した場合に、古いキャッシュされたレスポンスを使用できるケースを決定します。ディレクティブのパラメータは、uwsgi_next_upstreamディレクティブのパラメータと一致します。

errorパラメータは、リクエストを処理するuwsgiサーバーを選択できない場合にも、古いキャッシュされたレスポンスの使用を許可します。

さらに、updatingパラメータは、現在更新中の場合でも古いキャッシュされたレスポンスの使用を許可します。これにより、キャッシュデータの更新時にuwsgiサーバーへのアクセス数を最小限に抑えることができます。

古いキャッシュされたレスポンスの使用は、レスポンスが古くなった後、指定された秒数に対してレスポンスヘッダーで直接有効にすることもできます（1.11.10）。これは、ディレクティブパラメータを使用するよりも優先度が低くなります。

• 「Cache-Control」ヘッダーフィールドの「stale-while-revalidate」拡張機能により、現在更新中の場合でも古いキャッシュされたレスポンスを使用できます。
• 「Cache-Control」ヘッダーフィールドの「stale-if-error」拡張機能により、エラーが発生した場合に古いキャッシュされたレスポンスを使用できます。

新しいキャッシュ要素の入力時にuwsgiサーバーへのアクセス数を最小限に抑えるために、uwsgi_cache_lockディレクティブを使用できます。

異なるレスポンスコードのキャッシュ時間を設定します。たとえば、次のディレクティブは

uwsgi_cache_valid 200 302 10m;
uwsgi_cache_valid 404      1m;

コード200および302のレスポンスに対して10分のキャッシュ、コード404のレスポンスに対して1分のキャッシュを設定します。

キャッシュtimeのみが指定されている場合

uwsgi_cache_valid 5m;

200、301、および302のレスポンスのみがキャッシュされます。

さらに、anyパラメータを指定して、任意のレスポンスをキャッシュできます。

uwsgi_cache_valid 200 302 10m;
uwsgi_cache_valid 301      1h;
uwsgi_cache_valid any      1m;

キャッシュのパラメータは、レスポンスヘッダーで直接設定することもできます。これは、ディレクティブを使用してキャッシュ時間を設定するよりも優先度が高くなります。

• 「X-Accel-Expires」ヘッダーフィールドは、レスポンスのキャッシュ時間を秒単位で設定します。ゼロの値は、レスポンスのキャッシュを無効にします。値が@プレフィックスで始まる場合、レスポンスがキャッシュされる可能性のある、エポックからの絶対時間を秒単位で設定します。
• ヘッダーに「X-Accel-Expires」フィールドが含まれていない場合、キャッシュのパラメータはヘッダーフィールド「Expires」または「Cache-Control」で設定できます。
• ヘッダーに「Set-Cookie」フィールドが含まれている場合、そのようなレスポンスはキャッシュされません。
• ヘッダーに特別な値「*」を持つ「Vary」フィールドが含まれている場合、そのようなレスポンスはキャッシュされません（1.7.7）。ヘッダーに別の値を持つ「Vary」フィールドが含まれている場合、そのようなレスポンスは、対応するリクエストヘッダーフィールドを考慮してキャッシュされます（1.7.7）。

これらのレスポンスヘッダーフィールドの1つ以上の処理は、uwsgi_ignore_headersディレクティブを使用して無効にできます。

uwsgi_connect_timeout 60s;

uwsgiサーバーとの接続を確立するためのタイムアウトを定義します。このタイムアウトは通常75秒を超えることはできないことに注意する必要があります。

uwsgi_force_ranges off;

uwsgiサーバーからのキャッシュされたレスポンスとキャッシュされていないレスポンスの両方で、これらのレスポンスの「Accept-Ranges」フィールドに関係なく、バイト範囲サポートを有効にします。

デフォルトでは、nginxは、uwsgiサーバーのレスポンスからクライアントにヘッダーフィールド「Status」および「X-Accel-…」を渡しません。uwsgi_hide_headerディレクティブは、渡されない追加のフィールドを設定します。逆に、フィールドの通過を許可する必要がある場合は、uwsgi_pass_headerディレクティブを使用できます。

uwsgi_ignore_client_abort off;

クライアントがレスポンスを待たずに接続を閉じた場合に、uwsgiサーバーとの接続を閉じる必要があるかどうかを決定します。

uwsgiサーバーからの特定のレスポンスヘッダーフィールドの処理を無効にします。次のフィールドを無視できます：「X-Accel-Redirect」、「X-Accel-Expires」、「X-Accel-Limit-Rate」（1.1.6）、「X-Accel-Buffering」（1.1.6）、「X-Accel-Charset」（1.1.6）、「Expires」、「Cache-Control」、「Set-Cookie」（0.8.44）、および「Vary」（1.7.7）。

無効にされていない場合、これらのヘッダーフィールドの処理には次の効果があります。

• 「X-Accel-Expires」、「Expires」、「Cache-Control」、「Set-Cookie」、および「Vary」は、レスポンスのキャッシュのパラメータを設定します。
• 「X-Accel-Redirect」は、指定されたURIへの内部リダイレクトを実行します。
• 「X-Accel-Limit-Rate」は、クライアントへのレスポンスの送信のレート制限を設定します。
• 「X-Accel-Buffering」は、レスポンスのバッファリングを有効または無効にします。
• 「X-Accel-Charset」は、レスポンスの目的の文字セットを設定します。

uwsgi_intercept_errors off;

300以上のコードを持つuwsgiサーバーレスポンスをクライアントに渡すか、error_pageディレクティブを使用した処理のためにnginxにインターセプトしてリダイレクトするかを決定します。

uwsgi_limit_rate 0;

uwsgiサーバーからのレスポンスの読み取り速度を制限します。rateは、1秒あたりのバイト数で指定されます。ゼロの値は、レート制限を無効にします。制限はリクエストごとに設定されるため、nginxが同時にuwsgiサーバーへの2つの接続を開くと、全体のレートは指定された制限の2倍になります。この制限は、uwsgiサーバーからのレスポンスのバッファリングが有効になっている場合にのみ機能します。パラメータ値には変数を含めることができます（1.27.0）。

uwsgi_max_temp_file_size 1024m;

uwsgiサーバーからのレスポンスのバッファリングが有効になっており、レスポンス全体がuwsgi_buffer_sizeおよびuwsgi_buffersディレクティブで設定されたバッファに収まらない場合、レスポンスの一部を一時ファイルに保存できます。このディレクティブは、一時ファイルの最大sizeを設定します。一時ファイルに一度に書き込まれるデータのサイズは、uwsgi_temp_file_write_sizeディレクティブによって設定されます。

ゼロの値は、一時ファイルへのレスポンスのバッファリングを無効にします。

この制限は、キャッシュされるか、ディスクに保存されるレスポンスには適用されません。

uwsgi_modifier1 0;

uwsgiパケットヘッダーのmodifier1フィールドの値を設定します。

uwsgi_modifier2 0;

uwsgiパケットヘッダーのmodifier2フィールドの値を設定します。

uwsgi_next_upstream error timeout;

リクエストを次のサーバーに渡す必要があるケースを指定します。

error

サーバーとの接続を確立しているとき、リクエストをサーバーに渡しているとき、またはレスポンスヘッダーを読み取っているときにエラーが発生しました。

timeout

サーバーとの接続を確立しているとき、リクエストをサーバーに渡しているとき、またはレスポンスヘッダーを読み取っているときにタイムアウトが発生しました。

invalid_header

サーバーが空または無効なレスポンスを返しました。

http_500

サーバーがコード500のレスポンスを返しました。

http_503

サーバーがコード503のレスポンスを返しました。

http_403

サーバーがコード403のレスポンスを返しました。

http_404

サーバーがコード404のレスポンスを返しました。

http_429

サーバーがコード429のレスポンスを返しました（1.11.13）。

non_idempotent

通常、非冪等メソッド（POST、LOCK、PATCH）を持つリクエストは、リクエストがアップストリームサーバーに送信された場合、次のサーバーに渡されません（1.9.13）。このオプションを明示的に有効にすると、このようなリクエストを再試行できます。

off

リクエストを次のサーバーに渡すことを無効にします。

リクエストを次のサーバーに渡すことができるのは、まだクライアントに何も送信されていない場合に限られることに注意する必要があります。つまり、レスポンスの転送中にエラーまたはタイムアウトが発生した場合、これを修正することは不可能です。

このディレクティブは、サーバーとの通信が失敗とみなされる条件も定義します。error、timeout、invalid_header の場合は、ディレクティブで指定されていなくても、常に失敗とみなされます。http_500、http_503、http_429 の場合は、ディレクティブで指定されている場合にのみ失敗とみなされます。http_403 と http_404 の場合は、決して失敗とはみなされません。

次のサーバーへのリクエストの受け渡しは、試行回数と時間によって制限できます。

uwsgi_next_upstream_timeout 0;

リクエストを次のサーバーに渡すことができる時間を制限します。0 の値を指定すると、この制限は無効になります。

uwsgi_next_upstream_tries 0;

リクエストを次のサーバーに渡すための試行回数を制限します。0 の値を指定すると、この制限は無効になります。

レスポンスがキャッシュに保存されない条件を定義します。文字列パラメータの少なくとも1つの値が空ではなく、かつ "0" と等しくない場合、レスポンスは保存されません。

uwsgi_no_cache $cookie_nocache $arg_nocache$arg_comment;
uwsgi_no_cache $http_pragma    $http_authorization;

uwsgi_cache_bypassディレクティブと一緒に使用できます。

uwsgiサーバーに渡す必要があるパラメータを設定します。値には、テキスト、変数、およびそれらの組み合わせを含めることができます。これらのディレクティブは、現在のレベルで uwsgi_param ディレクティブが定義されていない場合にのみ、前の設定レベルから継承されます。

標準のCGI環境変数は、ディストリビューションで提供されるuwsgi_paramsファイルを参照して、uwsgiヘッダーとして提供する必要があります。

location / {
    include uwsgi_params;
    ...
}

ディレクティブがif_not_empty（1.1.11）で指定されている場合、そのパラメータの値が空でない場合にのみ、サーバーに渡されます。

uwsgi_param HTTPS $https if_not_empty;

uwsgiサーバーのプロトコルとアドレスを設定します。プロトコルとして、"uwsgi" または "suwsgi" (セキュアuwsgi、SSL上のuwsgi) を指定できます。アドレスは、ドメイン名またはIPアドレスとポートとして指定できます。

uwsgi_pass localhost:9000;
uwsgi_pass uwsgi://localhost:9000;
uwsgi_pass suwsgi://[2001:db8::1]:9090;

またはUNIXドメインソケットパスとして指定できます。

uwsgi_pass unix:/tmp/uwsgi.socket;

ドメイン名が複数のアドレスに解決される場合、それらはすべてラウンドロビン方式で使用されます。さらに、アドレスはサーバーグループとして指定できます。

パラメータ値には変数を含めることができます。この場合、アドレスがドメイン名として指定されている場合、その名前は記述されたサーバーグループの中で検索され、見つからない場合はリゾルバーを使用して決定されます。

セキュアuwsgiプロトコルは、バージョン1.5.8以降でサポートされています。

それ以外は無効になっているヘッダーフィールドを、uwsgiサーバーからクライアントに渡すことを許可します。

uwsgi_pass_request_body on;

元のリクエストボディをuwsgiサーバーに渡すかどうかを示します。uwsgi_pass_request_headersディレクティブも参照してください。

uwsgi_pass_request_headers on;

元のリクエストのヘッダーフィールドをuwsgiサーバーに渡すかどうかを示します。uwsgi_pass_request_bodyディレクティブも参照してください。

uwsgi_read_timeout 60s;

uwsgiサーバーからのレスポンスの読み取りタイムアウトを定義します。タイムアウトは、レスポンス全体の転送ではなく、連続する2つの読み取り操作の間でのみ設定されます。uwsgiサーバーがこの時間内に何も送信しない場合、接続は閉じられます。

uwsgi_request_buffering on;

クライアントのリクエストボディのバッファリングを有効または無効にします。

バッファリングが有効な場合、リクエスト全体がuwsgiサーバーに送信される前に、クライアントから読み取られます。

バッファリングが無効な場合、リクエストボディは受信されるとすぐにuwsgiサーバーに送信されます。この場合、nginxがすでにリクエストボディの送信を開始している場合、リクエストを次のサーバーに渡すことはできません。

元のリクエストボディを送信するためにHTTP/1.1チャンク転送エンコーディングが使用される場合、ディレクティブの値に関係なく、リクエストボディはバッファリングされます。

uwsgi_send_timeout 60s;

uwsgiサーバーへのリクエストの送信タイムアウトを設定します。タイムアウトは、リクエスト全体の転送ではなく、連続する2つの書き込み操作の間でのみ設定されます。uwsgiサーバーがこの時間内に何も受信しない場合、接続は閉じられます。

uwsgi_socket_keepalive off;

uwsgiサーバーへの発信接続の「TCP keepalive」動作を構成します。デフォルトでは、ソケットにはオペレーティングシステムの設定が有効です。ディレクティブが値 "on" に設定されている場合、SO_KEEPALIVE ソケットオプションがソケットに対して有効になります。

セキュアuwsgiサーバーへの認証に使用される、PEM形式の証明書を含むファイルを指定します。

バージョン 1.21.0 以降、変数名をファイル名に使用できます。

セキュアuwsgiサーバーへの認証に使用される、PEM形式の秘密鍵を含むファイルを指定します。

ファイルの代わりにengine:名前:IDという値を指定して（1.7.9）、指定されたIDを持つ秘密鍵をOpenSSLエンジン名前からロードできます。

バージョン 1.21.0 以降、変数名をファイル名に使用できます。

uwsgi_ssl_ciphers DEFAULT;

セキュアuwsgiサーバーへのリクエストで有効にする暗号スイートを指定します。暗号スイートは、OpenSSLライブラリで理解される形式で指定されます。

完全なリストは、「openssl ciphers」コマンドを使用して表示できます。

セキュアuwsgiサーバーとの接続を確立するときに、任意のOpenSSL構成コマンドを設定します。

このディレクティブは、OpenSSL 1.0.2以上を使用している場合にサポートされます。

同じレベルで複数の uwsgi_ssl_conf_command ディレクティブを指定できます。これらのディレクティブは、現在のレベルで uwsgi_ssl_conf_command ディレクティブが定義されていない場合にのみ、前の設定レベルから継承されます。

OpenSSLを直接構成すると、予期しない動作が発生する可能性があることに注意してください。

セキュアuwsgiサーバーの証明書を検証するために使用される、失効した証明書（CRL）を含むPEM形式のファイルを指定します。

セキュアuwsgiサーバー接続のSSLキーのロギングを有効にし、キーログファイルのパスを指定します。キーは、Wiresharkと互換性のあるSSLKEYLOGFILE形式でログに記録されます。

このディレクティブは、商用サブスクリプションの一部として利用できます。

uwsgi_ssl_name host from uwsgi_pass;

セキュアuwsgiサーバーの証明書を検証するために使用されるサーバー名を上書きし、セキュアuwsgiサーバーとの接続を確立するときにSNIを介して渡すことを許可します。

デフォルトでは、uwsgi_passからのホスト部分が使用されます。

秘密鍵のパスフレーズを含むファイルを指定します。各パスフレーズは別々の行に指定します。パスフレーズは、キーをロードするときに順番に試行されます。

uwsgi_ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;

セキュアuwsgiサーバーへのリクエストに対して指定されたプロトコルを有効にします。

TLSv1.3パラメータは、1.23.4以降デフォルトで使用されます。

uwsgi_ssl_server_name off;

セキュアuwsgiサーバーとの接続を確立するときに、TLS Server Name Indication拡張機能（SNI、RFC 6066）を介したサーバー名の受け渡しを有効または無効にします。

uwsgi_ssl_session_reuse on;

セキュアuwsgiサーバーでの作業時にSSLセッションを再利用できるかどうかを決定します。ログにエラー「SSL3_GET_FINISHED:digest check failed」が表示される場合は、セッションの再利用を無効にしてみてください。

セキュアuwsgiサーバーの証明書を検証するために使用される、信頼できるCA証明書を含むPEM形式のファイルを指定します。

uwsgi_ssl_verify off;

セキュアuwsgiサーバーの証明書の検証を有効または無効にします。

uwsgi_ssl_verify_depth 1;

セキュアuwsgiサーバーの証明書チェーンの検証深度を設定します。

uwsgi_store off;

ファイルをディスクに保存できるようにします。onパラメータは、aliasまたはrootディレクティブに対応するパスを持つファイルを保存します。offパラメータは、ファイルの保存を無効にします。さらに、変数を含む文字列を使用して、ファイル名を明示的に設定できます。

uwsgi_store /data/www$original_uri;

ファイルの変更時刻は、受信した "Last-Modified" レスポンスヘッダーフィールドに従って設定されます。レスポンスは最初に一時ファイルに書き込まれ、次にファイルの名前が変更されます。バージョン0.8.9以降、一時ファイルと永続ストアを異なるファイルシステムに配置できます。ただし、この場合、安価な名前変更操作ではなく、2つのファイルシステム間でファイルがコピーされることに注意してください。したがって、特定の場所については、保存されたファイルと、uwsgi_temp_pathディレクティブで設定された一時ファイルを保持するディレクトリの両方を同じファイルシステムに配置することをお勧めします。

このディレクティブを使用して、変更不可能な静的ファイルのローカルコピーを作成できます。例：

location /images/ {
    root               /data/www;
    error_page         404 = /fetch$uri;
}

location /fetch/ {
    internal;

    uwsgi_pass         backend:9000;
    ...

    uwsgi_store        on;
    uwsgi_store_access user:rw group:rw all:r;
    uwsgi_temp_path    /data/temp;

    alias              /data/www/;
}

uwsgi_store_access user:rw;

新しく作成されたファイルとディレクトリのアクセス許可を設定します。例：

uwsgi_store_access user:rw group:rw all:r;

groupまたはallのアクセス許可が指定されている場合は、userのアクセス許可を省略できます。

uwsgi_store_access group:rw all:r;

uwsgi_temp_file_write_size 8k|16k;

uwsgiサーバーからのレスポンスの一時ファイルへのバッファリングが有効になっている場合、一時ファイルに一度に書き込まれるデータのサイズを制限します。デフォルトでは、サイズは、uwsgi_buffer_sizeおよびuwsgi_buffersディレクティブによって設定された2つのバッファによって制限されます。一時ファイルの最大サイズは、uwsgi_max_temp_file_sizeディレクティブによって設定されます。

uwsgi_temp_path uwsgi_temp;

uWSGIサーバーから受信したデータを格納するための一時ファイルのディレクトリを定義します。指定されたディレクトリの下に、最大3レベルのサブディレクトリ階層を使用できます。例えば、以下の設定では、

uwsgi_temp_path /spool/nginx/uwsgi_temp 1 2;

一時ファイルは次のようになる可能性があります。

/spool/nginx/uwsgi_temp/7/45/00000123457

uwsgi_cache_path ディレクティブの use_temp_path パラメータも参照してください。