BACKEND, can be read and
set, but not
Available in all subroutines.
The backend to use to service the request.
Since the type of this variable is
BACKEND, an assignment must use one of the defined backends within your Fastly service. Backends defined within the web interface are prefixed with
F_ when referencing them in VCL. For example:
set req.backend = F_primary_origin;
It's possible to see all the defined backends in your service by viewing the service's generated VCL, either via the API or using the web interface.
Upon reading in a
req.backend is converted to a
STRING and prepended with the backend's
share_key property, which is your service ID (for backends created via the API, CLI, or web interface), the string "fastlyshield" (for shield backends), or whatever you defined (for backends defined in VCL).
While this variable is accessible in all VCL subroutines, it is always
vcl_log, and is reported inaccurately in
vcl_deliver as a side effect of internal Fastly routing. To access the value of
vcl_log, copy the value into a custom HTTP header earlier in your VCL program.
req.backend 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.
URL path based routing for microservices
Send request to different origin servers based on the URL path.
Smoke test a new origin
Send a copy of your traffic to a test origin before returning a response from production.
Failover to a secondary backend
If primary backend fails, retry with a different backend without caching the failure or reducing cache efficiency.
Custom condition for triggering WAF
The web application firewall runs only on traffic to your origin, but you can further refine when it should be invoked.