モジュール ngx_http_scgi_module

ngx_http_scgi_module モジュールは、SCGI サーバーにリクエストを渡すことを可能にします。

location / {
    include   scgi_params;
    scgi_pass localhost:9000;
}

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

transparent パラメータ (1.11.0) を使用すると、SCGI サーバーへの発信接続を、クライアントの実際の IP アドレスなど、非ローカル IP アドレスから開始できます。

scgi_bind $remote_addr transparent;

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

scgi_buffer_size 4k|8k;

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

scgi_buffering on;

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

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

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

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

scgi_buffers 8 4k|8k;

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

scgi_busy_buffers_size 8k|16k;

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

scgi_cache off;

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

scgi_cache_background_update off;

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

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

scgi_cache_bypass $cookie_nocache $arg_nocache$arg_comment;
scgi_cache_bypass $http_pragma    $http_authorization;

scgi_no_cache ディレクティブと組み合わせて使用できます。

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

scgi_cache_key localhost:9000$request_uri;

scgi_cache_lock off;

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

scgi_cache_lock_age 5s;

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

scgi_cache_lock_timeout 5s;

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

1.7.8 より前のバージョンでは、応答をキャッシュすることができました。

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

scgi_cache_methods GET HEAD;

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

scgi_cache_min_uses 1;

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

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

scgi_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 の値に設定した場合、指定された場所の scgi_temp_path ディレクティブで設定されたディレクトリが使用されます。値が off に設定されている場合、一時ファイルはキャッシュディレクトリに直接配置されます。

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

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

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=数値

1回の反復処理中にスキャンされるアイテム数を設定します (1.7.12)。デフォルトでは、purger_filesは10に設定されています。

purger_threshold=数値

1回の反復処理の時間を設定します (1.7.12)。デフォルトでは、purger_thresholdは50ミリ秒に設定されています。

purger_sleep=数値

反復処理間のポーズを設定します (1.7.12)。デフォルトでは、purger_sleepは50ミリ秒に設定されています。

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

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

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

設定例

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

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

server {
    ...
    location / {
        scgi_pass        backend;
        scgi_cache       cache_zone;
        scgi_cache_key   $uri;
        scgi_cache_purge $purge_method;
    }
}

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

scgi_cache_revalidate off;

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

scgi_cache_use_stale off;

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

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

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

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

• 「Cache-Control」ヘッダーフィールドの「stale-while-revalidate」拡張機能は、現在更新中の古いキャッシュされた応答を使用することを許可します。
• 「Cache-Control」ヘッダーフィールドの「stale-if-error」拡張機能は、エラーが発生した場合に古いキャッシュされた応答を使用することを許可します。

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

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

scgi_cache_valid 200 302 10m;
scgi_cache_valid 404      1m;

コード200と302の応答に対して10分のキャッシュ、コード404の応答に対して1分のキャッシュを設定します。

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

scgi_cache_valid 5m;

200、301、および302の応答のみがキャッシュされます。

さらに、anyパラメータを指定して、すべての応答をキャッシュできます

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

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

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

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

scgi_connect_timeout 60s;

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

scgi_force_ranges off;

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

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

scgi_ignore_client_abort off;

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

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

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

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

scgi_intercept_errors off;

コードが300以上のSCGIサーバー応答をクライアントに渡すか、インターセプトして、error_pageディレクティブを使用してnginxにリダイレクトして処理するかどうかを決定します。

scgi_limit_rate 0;

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

scgi_max_temp_file_size 1024m;

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

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

この制限は、ディスクにキャッシュまたは保存される応答には適用されません。

scgi_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のケースは、失敗した試行とは決してみなされません。

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

scgi_next_upstream_timeout 0;

リクエストを次のサーバーに渡すことができる時間を制限します。0の値は、この制限をオフにします。

scgi_next_upstream_tries 0;

次のサーバーへのリクエストの受け渡しの試行回数を制限します。0の値は、この制限をオフにします。

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

scgi_no_cache $cookie_nocache $arg_nocache$arg_comment;
scgi_no_cache $http_pragma    $http_authorization;

scgi_cache_bypassディレクティブとともに使用できます。

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

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

location / {
    include scgi_params;
    ...
}

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

scgi_param HTTPS $https if_not_empty;

SCGIサーバーのアドレスを設定します。アドレスは、ドメイン名またはIPアドレスとポートとして指定できます。

scgi_pass localhost:9000;

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

scgi_pass unix:/tmp/scgi.socket;

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

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

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

scgi_pass_request_body on;

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

scgi_pass_request_headers on;

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

scgi_read_timeout 60s;

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

scgi_request_buffering on;

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

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

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

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

scgi_send_timeout 60s;

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

scgi_socket_keepalive off;

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

scgi_store off;

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

scgi_store /data/www$original_uri;

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

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

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

location /fetch/ {
    internal;

    scgi_pass         backend:9000;
    ...

    scgi_store        on;
    scgi_store_access user:rw group:rw all:r;
    scgi_temp_path    /data/temp;

    alias             /data/www/;
}

scgi_store_access user:rw;

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

scgi_store_access user:rw group:rw all:r;

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

scgi_store_access group:rw all:r;

scgi_temp_file_write_size 8k|16k;

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

scgi_temp_path scgi_temp;

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

scgi_temp_path /spool/nginx/scgi_temp 1 2;

一時ファイルは次のようになります

/spool/nginx/scgi_temp/7/45/00000123457

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