Indicates whether the backend is a customer origin.
Shielding directs traffic from the Fastly POPs closest to the end user to the Fastly POP closest to your backend, and onward to your servers. It is therefore possible for a resource to be fetched from a backend that is another Fastly POP. When this is the case,
req.backend.is_shield will be
req.backend.is_origin will be
WARNING: The value of this variable depends on a backend having already been assigned to
req.backend. VCL snippets run before the default backend assignment, so in
vcl_recv this variable is only effective if you are using custom VCL and your custom VCL code is inserted after the
#FASTLY recv macro. In subroutines other than
vcl_recv, snippets can be used, and in general, the best place to interact with this variable is in
req.backend.is_origin is used in the following code examples. Examples apply VCL to real-world use cases and can be deployed as they are, or adapted for your own service. See the full list of code examples for more inspiration.
Click RUN on a sample below to provision a Fastly service, execute the code on Fastly, and see how the function behaves.
Follow redirects at the edge
Protect clients from redirects by chasing them internally at the edge, and then return the eventual non-redirect response.
Auto retry a secondary backend
If primary backend fails, retry with a different backend without caching the failure or reducing cache efficiency.