scgi_next_upstream
The `scgi_next_upstream` directive controls which error conditions trigger a retry of requests to the next upstream server when using SCGI.
Description
The scgi_next_upstream directive is used in contexts such as http, server, and location, and it plays a crucial role in managing request retry logic in the SCGI module. When a request fails due to specified error conditions, this directive allows the administrator to specify whether NGINX should attempt to send the request to the next server in the upstream block. The conditions include timeout errors, connection refusals, or bad gateway responses. This helps enhance reliability and ensures a more seamless experience for clients by rerouting requests to available servers in case of server-side issues.
The directive allows for multiple parameters to be specified, forming a comma-separated list which indicates how NGINX should behave upon encountering specific errors. For instance, you might want to retry the request on a timeout but not on a 500 Internal Server Error. Understanding the implications of each condition included in the directive is essential for building resilient applications. Misconfiguring this directive can lead to either unnecessary retries, which increase latency, or, conversely, not retrying when it could be advantageous.
It is also important to be aware of how default values interact with specified parameters. If no values are defined, NGINX performs no retries, and combining the directive with proper scgi_pass settings would ensure successful communication with SCGI applications.
Config Example
location /some_url {
scgi_pass backend;
scgi_next_upstream error_code timedout http_500;
}Ensure that upstream servers are properly defined to avoid routing errors.
Be cautious of overusing retries; excessive retries can lead to performance degradation or request pile-ups.
The order of parameters matters; understand the effects of each error condition specified.