BACKEND, can be read and set, but not unset.

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 STRING context, 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 null in vcl_log, and is reported inaccurately in vcl_deliver as a side effect of internal Fastly routing. To access the value of req.backend in vcl_deliver or vcl_log, copy the value into a custom HTTP header earlier in your VCL program.

Try it out

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.