The cache honors backend's Cache-Control, Expires, and etc. since version 0.7.48, Cache-Control: private and no-store only since 0.7.66, though. Vary handling is not implemented.

Directives

fastcgi_bind

syntax:fastcgi_bind address

default:none

context:http, server, location

version:≥ 0.8.22

example:

fastcgi_bind 192.168.1.1;

This directive binds each upstream socket to a local address before calling connect(). It may be useful if host has several interfaces/aliases and you want to pass outgoing connections from specific interface/address.

If a fastcgi response is 12k then fastcgi_buffers 64 4k will allocated 3 buffers of 4k. This is why fastcgi_buffers has two parameters, while fastcgi_buffer_size (used for response header and first part) has just one paramter. After fastcgi_buffer_size has been emptied, it used together with fastcgi_buffers.

Be advised that a HEAD request can cause an empty response to be cached & later be distributed to GET requests, avoid this by having $request_method in the cache key. Including the $scheme for the same reason may be beneficial to avoid serving up pages with insecure content to HTTPS visitors (or vice-versa).

fastcgi_cache_lock_timeout

fastcgi_cache_methods

syntax:fastcgi_cache_methods [GET HEAD POST];

default:fastcgi_cache_methods GET HEAD;

context:main, http, location

This directive specifies which HTTP methods are allowed to be used when caching FastCGI requests. Note that
GET and HEAD are syntactic sugars, i.e., a mere convenience in terms of this directive configuration logic. They cannot be disabled even if you set:

Caching data is first written to the temporary file which is then moved to the final location in a cache directory. Starting from 0.8.9 it is possible to store temporary and cache files on different file systems, but it should be kept in mind that in such a case instead of cheap and atomic rename syscall a full file copy is performed. So it's better to use the same file system in both parameters of fastcgi_temp_path and fastcgi_cache_path directives.

In addition, all active keys and information about data are kept in the shared memory zone, which name and size are specified by the options of the key_zone parameter. In case this data haven't been accessed for the time, specified in the option of inactive parameter, it is wiped out from the memory. By default inactive period is set to 10 minutes.

To maintain the maximum size of the cache, which is set by max_size parameter, a special process cache manager periodically deletes old data from the cache.

fastcgi_ignore_client_abort

This directive determines if current request to the FastCGI-server must be aborted in case the client aborts the request to the server.

In 1.0.2 POST requests are not handled correctly when fastcgi_ignore_client_abort is set to on which can lead to workers processes segfaulting. Switching fastcgi_ignore_client_abort back to default (off) should resolve this issue.

fastcgi_intercept_errors

This directive determines whether or not to transfer 4xx and 5xx errors back to the client or to allow Nginx to answer with directive error_page.

Note: You need to explicitly define the error_page handler for this for it to be useful. As Igor says, "nginx does not intercept an error if there is no custom handler for it it does not show its default pages. This allows to intercept some errors, while passing others as are."

fastcgi_next_upstream

This directive defines in which cases request will be passed to the next server:

error — an error occurred during connection to the server, passing request to it or reading server respond header;

timeout — a timeout occurred during connection to the server, passing request to it or reading server respond header;

invalid_header — server returned empty or invalid answer;

http_500 — server returned 500 respond;

http_503 — server returned 503 respond;

http_404 — server returned 404 respond;

off — explicitly forbids passing request to the next server;

It should be clear that passing request to the next server is possible only if no data have been yet returned to the client. So, if the error or timeout occurred during the data transmission to the client it's too late to fix it.

fastcgi_param

Directive assigns the parameter, which will be transferred to the FastCGI-server.

It is possible to use strings, variables and their combination as values. Directives not set are inherited from the outer level. Directives set in current level clear any previously defined directives for the current level.

fastcgi_read_timeout

Directive sets the amount of time for upstream to wait for a fastcgi process to send data. Change this directive if you have long running fastcgi processes that do not produce output until they have finished processing. If you are seeing an upstream timed out error in the error log, then increase this parameter to something more appropriate.

fastcgi_redirect_errors

fastcgi_send_timeout

Directive specifies request timeout to the server. The timeout is calculated between two write operations, not for the whole request. If no data have been written during this period then serve closes the connection.

fastcgi_store

This directive sets the path in which upstream files are stored. The parameter "on" preserves files in accordance with path specified in directives alias or root. The parameter "off" forbids storing. Furthermore, the name of the path can be clearly assigned with the aid of the line with the variables:

The time of modification for the file will be set to the date of "Last-Modified" header in the response. To be able to safe files in this directory it is necessary that the path is under the directory with temporary files, given by directive fastcgi_temp_path for the data location.

This directive can be used for creating the local copies for dynamic output of the backend which is not very often changed, for example:

fastcgi_temp_path

This directive sets the path where to store temporary files received from another server. It is possible to use up to 3 levels of subdirectories to create hashed storage. Level value specifies how many symbols will be used for hashing. For example, in the following configuration:

Parameters, transferred to FastCGI-server.

The request headers are transferred to the FastCGI-server in the form of parameters. In the applications and the scripts run from the FastCGI-server, these parameters are usually accessible in the form of environment variables. For example, the header "User-agent" is transferred as parameter HTTP_USER_AGENT. Besides the headers of the HTTP request, it is possible to transfer arbitrary parameters with the aid of directive fastcgi_param.

Variables

$fastcgi_script_name

This variable is equal to the URI request or, if if the URI concludes with a forward slash, then the URI request plus the name of the index file given by fastcgi_index. It is possible to use this variable in place of both SCRIPT_FILENAME and PATH_TRANSLATED, utilized, in particular, for determining the name of the script in PHP.