req.backend
BACKEND, can be read and set, but not unset.
Available inall subroutines.
The backend to use if the request is forwarded to origin.
HINT: If you want to log or otherwise report on which backend was used for a request, consider using req.backend.name instead.
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 by default is your service ID, but can be changed as part of the backend definition to consolidate healthcheck traffic.
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.
Use microservices to divide up a domain
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.
Auto retry a secondary backend
If primary backend fails, retry with a different backend without caching the failure or reducing cache efficiency.
