bereq.first_byte_timeout
RTIME, can be read and set, but not unset.
The amount of time Fastly should wait for a backend server to deliver the first byte of an HTTP response body, before triggering a timeout.
May be set to any value between 0 and 600s. By default, the timeout is 15s.
If the timeout is triggered, Fastly will create an error object and invoke vcl_error with obj.status set to 503 and obj.response set to "first byte timeout". Learn more about errors.
Effects of shielding and clustering
If clustering or shielding is enabled, the request will pass through more than one Fastly server before it is sent to the origin.
The timeout between nodes in a cluster is always 60s and is not configurable. This means that, for services with clustering enabled, the effective maximum bereq.first_byte_timeout is 60s.
The timeout between POPs in a shielding arrangement is affected by the settings in each case, since the full VCL configuration will be executed at each POP separately. For example, to set a timeout that applies only when connecting to the origin and not when connecting to an upstream shield POP, use the following VCL:
if (req.backend.is_origin) { set bereq.first_byte_timeout = 10s;}Longer timeouts
To set a timeout of more than 60 seconds, you must perform the fetch to your origin server directly from the first Fastly server that handles the request, without clustering. You can do this in two ways, both of which significantly impact Fastly's ability to cache your content:
- Mark the request as a PASS by executing
return(pass)invcl_recv. Responses will not be cached. - Disable clustering. Cache hit ratio will be severely reduced.
In such cases, consider limiting this behavior to only the URLs that require an extreme timeout. For example, the following code sets a 5-minute first byte timeout for all requests to paths starting with /slow/response:
if (req.url ~ "^/slow/response") { set bereq.first_byte_timeout = 300s;}