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のワーカープロセスを superuser 権限を使って実行する必要があります。Linux上では、transparentパラメータが指定された場合はワーカープロセスはマスタープロセスからCAP_NET_RAW機能を継承するため、必要ではありません (1.13.8)。uwsgiサーバからのネットワーク通信を捕らえるためにカーネルのルーティングテーブルを設定する必要もあります。

uwsgi_buffer_size 4k|8k;

uwsgiサーバから応答の最初の部分を読み込むために使われるバッファのsizeを設定します。この部分は通常小さな応答ヘッダを含んでいます。デフォルトでは、バッファサイズはメモリページと同じサイズです。これは4Kあるいは8kです。プラットフォームに依存します。しかしながら、もっと小さくすることができます。

uwsgi_buffering on;

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

バッファリングが有効な場合、nginxはuwsgiサーバからできるだけ早く応答を受け取り、 uwsgi_buffer_size と uwsgi_buffers ディレクティブで設定されるバッファに保存します。全ての応答がメモリに収まらない場合、一部をディスク上のtemporary fileに保存することができます。一時ファイルへの書き込みは、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を設定します。デフォルトでは、バッファサイズはメモリページと同じサイズです。これは4Kあるいは8kです。プラットフォームに依存します。

uwsgi_busy_buffers_size 8k|16k;

uwsgiサーバからの応答の buffering を有効にした場合、応答がまだ全て読み込まれていない間にクライアントに応答を送るのに忙しくなりえるバッファのsize を制限します。一方で、バッファの残りが応答を読み込むために使われることがあります。もし必要であれば応答の一部分が一時ファイルにバッファされます。デフォルトでは、size はuwsgi_buffer_size と uwsgi_buffers ディレクティブで設定される二つのバッファのサイズによって制限されます。

uwsgi_cache off;

キャッシュに使われる共有メモリ領域を定義します。同じ領域が幾つかの場所で使われるかも知れません。パラメータ値は変数を含むことができます (1.7.9)。off パラメータは、前の設定レベルから継承したキャッシングを無効にします。

uwsgi_cache_background_update off;

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

応答がキャッシュから取れない時の条件を設定します。stringパラメータのうちの一つでも空では無く"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サーバに渡すことで一度に一つのリクエストがuwsgi_cache_keyディレクティブによって識別される新しいキャッシュエレメントを生成するようにできるでしょう。同じキャッシュエレメントの他のリクエストは、uwsgi_cache_lock_timeoutディレクティブで設定された時間まで、キャッシュの中に現れるまで応答を待つか、このエレメントのキャッシュロックが開放されるのを待つかするでしょう。

uwsgi_cache_lock_age 5s;

もし指定されたtimeの間、新しいキャッシュ要素を作るためにuwsgiサーバへ送信された最後のリクエストが完了しない場合は、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 を設定します。

キャッシュのパスとその他のパラメータを設定します。キャッシュデータはファイルに保存されます。キャッシュの中のファイル名は、cache keyに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から、一時ファイルとキャッシュは異なるファイルシステムに置くことができます。しかし、この場合に注意が必要なのは、手軽なリネーム操作の代わりにファイルは二つのファイルシステムを超えてコピーされるということです。従って、どの指定されたlocationの一時ファイルに保持されるキャシュとディレクトリの両方が同じファイルシステムに配置されることが勧められます。一時ファイルのためのディレクトリはuse_temp_path パラメータに基づいて設定されます(1.7.10)。パラメータが省略あるいは値 onに設定されると、uwsgi_temp_pathディレクティブによって設定されたディレクトリが指定されたlocationに対して使われるでしょう。値が off に設定されると、一時ファイルは直接キャッシュディレクトリに配置されるでしょう。

更に、全てのアクティブなキーとデータに関する情報は共有メモリ領域に保持されます。その名前とサイズはkeys_zoneパラメータによって設定されます。一メガバイトの領域は約8000のキーを保持することができます。

商用許可の一部として、共有メモリ領域は拡張されたキャッシュ情報も格納し、従って同じ数のキーのためにより大きな領域サイズを指定する必要があります。例えば、1メガバイトの領域は約4000のキーを格納することができます。

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

特別な“cache manager”プロセスは、max_sizeパラメータで設定される最大キャッシュサイズを、ファイルシステム上でキャッシュを使ってmin_free (1.19.1) パラメータによって設定される最小空き容量を監視します。サイズを超えるか、または十分な空き領域が無い場合、最も使用頻度の低いデータが削除されます。データは、manager_files、manager_threshold、manager_sleepパラメータによって設定される繰り返しの中で削除されます (1.11.5)。1つの繰り返しの中では、anager_files 以下の項目が削除されます (デフォルトでは 100)。一回の繰り返しの持続期間は manager_threshold パラメータによって制限されます (デフォルトでは 200ミリ秒)。繰り返しの間は、loader_sleep パラメータ(デフォルトでは50ミリ秒)で設定される一時停止が置かれます。

その開始の1分後に、特別な"cache loader" プロセスが起動されます。それはファイルシステムに保持されている以前のキャッシュデータに関するデータをキャッシュ領域にロードします。そのロードも繰り返し行われます。一回の繰り返しではloader_files(デフォルトでは100)以下のアイテムがロードされます。その上、一回の繰り返しの持続期間は loader_thresholdパラメータ(デフォルトでは200ミリ秒)に制限されます。繰り返しの間は、loader_sleep パラメータ(デフォルトでは50ミリ秒)で設定される小休止が置かれます。

更に、次のパラメータが商用許可の一部として利用可能です:

purger=on|off

wildcard keyに一致するキャッシュエントリをキャッシュpurgerでディスクから削除するかどうかを伝えます (1.7.12)。パラメータを on (デフォルトは off)にすると、永続的に全てのキャッシュエントリを数え上げワイルドカードキーに一致するエントリを削除する"cache purger" プロセスを有効にするでしょう。

purger_files=number

繰り返しの間に走査される項目の数を設定します (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バージョンにアップグレードした後で無効だと見なされるでしょう。

キャッシュの一掃リクエストと見なされるリクエストの条件を定義します。stringパラメータのうちの一つでも空では無く"0"と等しくない場合は、cache keyに対応するキャッシュエントリが削除されます。操作が成功した結果は204(No Content)応答が返されることによって示されます。

一掃リクエストのcache keyが("*")で終わる場合は、ワイルドカードに一致する全てのキャッシュのエントリがキャッシュから削除されます。ただし、これらのエントリは、非アクティブのために削除されるか、cache purger(1.7.12)によって処理されるか、クライアントがアクセスしようとするまで、ディスクに残ります。

設定例

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

map $request_method $purge_method {
    <s0>'purge'</s0>
    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"ヘッダフィールドを持つ条件付きリクエストを使って、expireしたアイテムの再検証を有効にします。

uwsgi_cache_use_stale off;

uwsgiサーバとの通信でエラーが起きた場合に、新鮮ではない応答が使われるかどうかを決定します。ディレクティブのパラメータはuwsgi_next_upstreamディレクティブのパラメータと一致します。

もしリクエストを処理するためのuwsgiサーバが選択できない場合は、error パラメータは新鮮ではないキャッシュ応答を使うことも許可します。

更に、updatingパラメータはもしキャッシュが更新されていても新鮮ではないキャッシュ応答を使うことを許可します。これにより、キャッシュされたデータの更新時にuwsgiサーバへのアクセス数を最小限にすることができます。

応答が古くなった後で指定された秒数の間応答ヘッダの中で古くなったキャッシュされた応答の使用が有効になるかも知れません。これはディレクティブパラメータの使用よりも優先度が低いです。

• 今更新されている場合は“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分を設定します。

キャッシング時間だけを指定するには、

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"ヘッダフィールドは応答のキャッシュ時間を秒数で設定します。0の値は、応答のキャッシュを無効にします。値が@プリフィックスで始まる場合、Epochからその応答がキャッシュされるまでの絶対的な秒数を設定します。
• ヘッダーに"X-Accel-Expires"フィールドが含まれない場合、キャッシングのパラメータは"Expires"または"Cache-Control"ヘッダーフィールドに設定されるかも知れません。
• ヘッダーが"Set-Cookie"フィールドを含む場合、そのような応答はキャッシュされないでしょう。
• ヘッダが "Vary” フィールドに特別な値"*"を含む場合、そのような応答はキャシュされないでしょう(1.7.7)。ヘッダが"Vary"フィールドに他の値を含む場合、そのような応答は応答リクエストヘッダフィールドを考慮してキャッシュされるでしょう(1.7.7)。

これらの一つ以上の応答フィールドの処理を無効にするには、uwsgi_ignore_headers ディレクティブを使います。

uwsgi_connect_timeout 60s;

uwsgiサーバとの接続の確立のタイムアウトを定義します。このタイムアウトは通常75秒以上にならないことに注意が必要です。

uwsgi_force_ranges off;

応答の中の"Accept-Ranges"フィールドに応じてuwsgiサーバからのキャッシュおよびキャッシュされていない応答の両方において、byte-rangeのサポートを有効にします。

デフォルトでは、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” は応答 cachingのパラメータを設定します;
• "X-Accel-Redirect" は特定のURIに対してinternal redirect を実行します。
• "X-Accel-Limit-Rate" はクライアントへの応答の転送について rate limitを設定します;
• "X-Accel-Buffering" は応答のbufferingを有効または無効にします ;
• "X-Accel-Charset"は望ましい応答のcharsetを設定します。

uwsgi_intercept_errors off;

uwsgiサーバの300以上の応答コードが、クライアントへ渡されるべきかまたは遮断されるべきか、そしてerror_page ディレクティブで処理するためにnginxにリダイレクトすべきかを決定します。

uwsgi_limit_rate 0;

uwsgiサーバから応答を読み込む時のスピードを制限します。rateは秒間あたりのバイトで指定されます。0の値はレートの制限を無効にします。制限はリクエストごとに設定されます。もしnginxがuwsgiサーバに同時に二つの接続を開いた場合は、全体のレートは指定された制限の二倍になるでしょう。この制限はuwsgiサーバからの応答のbufferingが有効な場合にのみ動作します。

uwsgi_max_temp_file_size 1024m;

uwsgiサーバからの応答のbuffering が有効な場合で、応答の全体が uwsgi_buffer_size とuwsgi_buffers ディレクティブで設定されるバッファに収まらない場合に、応答の一部を一時ファイルに保存することができます。このディレクティブは一時ファイルのsize最大値を設定します。一時ファイルに一度に書き込まれるデータのサイズは、uwsgi_temp_file_write_sizeディレクティブで設定されます。

0の値は、一時ファイルの応答のバッファリングを無効にします。

この制限はディスク上に cached あるいは stored される応答については適用されないでしょう。

uwsgi_modifier1 0;

uwsgi packet headerのmodifier1 フィールドの値を設定します。

uwsgi_modifier2 0;

uwsgi packet headerのmodifier2 フィールドの値を設定します。

uwsgi_next_upstream error timeout;

どの場合にリクエストが次のサーバに渡されるべきかを指定します:

エラー

サーバへの接続の確立時、あるいはサーバにリクエストを渡す時、あるいは応答ヘッダーを読み込む時にエラーが起きた場合;

timeout

サーバへの接続の確立時、あるいはサーバにリクエストを渡す時、あるいは応答ヘッダーを読み込む時にタイムアウトが起きた場合;

invalid_header

サーバが空あるいは無効な応答を返した場合;

http_500

サーバがコード500の応答を返した場合;

http_503

サーバがコード503を返した場合;

http_403

サーバがコード403を返した場合;

http_404

サーバがコード404の応答を返した場合;

http_429

サーバがコード429の応答を返した場合 (1.11.13);

non_idempotent

もしリクエストがupstream サーバに送信された場合は、通常 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 の値はこの制限を無効にします。

応答がキャッシュに保存されない状況を定義します。stringパラメータのうちの一つでも空では無く"0"に等しくない場合は、応答は保存されないでしょう。

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

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

uwsgiサーバに渡されるべき parameter を設定します。valueにはテキスト、 変数、それらの組み合わせを含むことができます。現在のレベルにuwsgi_paramディレクティブが無い場合に限り、これらのディレクティブは上の設定レベルから引き継がれます。

標準的な CGI environment variables はuwsgiヘッダとして提供されるべきです。配布物で提供されている uwsgi_params ファイルを見てください:

location / {
    include uwsgi_params;
    ...
}

ディレクティブがif_not_empty (1.1.11)で指定されている場合、そのようなパラメータは値が空では無い場合のみ、サーバに渡されないでしょう:

uwsgi_param HTTPS $https if_not_empty;

uwsgiサーバのプロトコルとアドレスを設定します。protocolとして、"uwsgi"または"suwsgi"(secured uwsgi, uwsgi over SSL) を指定することができます。アドレスはドメイン名またはIPアドレスと、ポートで指定することができます。

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

あるいは、UNIXドメインソケットパス:

uwsgi_pass unix:/tmp/uwsgi.socket;

ドメイン名が幾つかのアドレスに解決される場合は、ラウンドロビンの形式でそれら全てが使われるでしょう。更に、server groupとしてアドレスを指定することができます。

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

Secured 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サーバから応答を読み込む時のタイムアウトを定義します。タイムアウトは二つの連続する読み込み操作の間に設定され、応答全体の転送のためのものではありません。この時間内にuwsgiサーバが何も転送しなかった場合、接続が閉じられます。

uwsgi_request_buffering on;

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

バッファが有効な場合は、リクエストをuwsgiサーバに渡す前にリクエストボディの全体が読み込まれます。

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

元のリクエストボディを送信するためにHTTP/1.1 chunked transfer encoding が使用された場合は、指定された値に関係なくバッファされます。

uwsgi_send_timeout 60s;

uwsgiサーバへのリクエストの転送のタイムアウトを設定します。タイムアウトは二つの連続する書き込み操作の間に設定され、リクエスト全体の転送のためのものではありません。この時間内にuwsgiサーバが何も受け取らなかった場合、接続が閉じられます。

uwsgi_socket_keepalive off;

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

secureなuwsgiサーバに対して認証に使われるPEM形式の証明書の ファイルを指定します。

バージョン 1.21.0以降、file名に変数を使うことができます。

secureなuwsgiサーバに対して認証に使われるPEM形式の秘密鍵の ファイルを指定します。

engine:name:id の値は file の代わりに指定することができ(1.7.9)、 特定のOpenSSLのnameの特定の id と一緒に秘密鍵を取り付けます。

バージョン 1.21.0以降、file名に変数を使うことができます。

uwsgi_ssl_ciphers DEFAULT;

secured uwsgiサーバへのリクエストで有効なcipherを指定します。cipherはOpenSSLライブラリで理解される形式で指定されます。

全てのリストは"openssl ciphers"コマンドを使ってみることができます。

secured uwsgi サーバとの接続を確立する時に、任意のOpenSSL設定コマンドを設定します。

このディレクティブはOpenSSL 1.0.2以降を使う場合にサポートされます。

いくつかのuwsgi_ssl_conf_commandディレクティブは同じレベルに設定できます。現在のレベルにuwsgi_ssl_conf_commandディレクティブが無い場合に限り、これらのディレクティブは上の設定レベルから引き継がれます。

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

secured uwsgiサーバの証明書をverifyするために使われるPEM形式の無効な証明書(CRL)のfileを指定します。

uwsgi_ssl_name host from uwsgi_pass;

secured uwsgiサーバの証明書をverifyするために使われるサーバ名を上書きし、secured uwsgiサーバと接続を確立する時にpassed through SNIできます。

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

secret keysのためのそれぞれのパスフレーズが一行に指定されているfileを指定します。パスフレーズはキーがロードされる時に順番に試されます。

uwsgi_ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

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

uwsgi_ssl_server_name off;

secured uwsgiサーバと接続を確立する時に、TLS Server Name Indication extension (SNI, RFC 6066) を使ってサーバ名を渡すことを有効または無効にします。

uwsgi_ssl_session_reuse on;

secured uwsgiサーバと動作する時に、SSLセッションを再利用するかどうかを決定します。ログに"SSL3_GET_FINISHED:digest check failed"が現れる場合は、セッションの再利用を無効にしてみてください。

secured uwsgiサーバの証明書をverifyするために使われるPEM形式の信頼されたCA証明書のfileを指定します。

uwsgi_ssl_verify off;

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

uwsgi_ssl_verify_depth 1;

secured uwsgiサーバの連鎖証明書の検証の深さを設定します。

uwsgi_store off;

ファイルのディスクへの保存を有効にします。onパラメータはファイルをalias または rootディレクティブに対応するパスに保存します。offパラメータはファイルの保存を無効にします。更に、ファイル名は明示的に変数とともにstring を使って設定することができます:

uwsgi_store /data/www$original_uri;

ファイルの修正時間は受け取った"Last-Modified"応答ヘッダフィールドに従って設定されます。応答はまず一時ファイルに書き込まれ、それからファイルはリネームされます。バージョン0.8.9から、一時ファイルと恒久的な保存は別のファイルシステムに置くことができます。しかし、この場合に注意が必要なのは、手軽なリネーム操作の代わりにファイルは二つのファイルシステムを超えてコピーされるということです。従って、いずれの指定されたlocationの保存されたファイルと一時ファイルを保持するディレクトリの両方が、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サーバから一時ファイルへの応答のバッファリングが有効にされた場合、一時ファイルに一度に書き込まれるデータのsizeを制限します。 デフォルトでは、sizeはuwsgi_buffer_size とuwsgi_buffers ディレクティブで設定される二つのバッファによって制限されます。一時ファイルの最大サイズは 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 パラメータも見てください。