restart
restart;Available inrecvhitfetcherrordeliver
The restart statement terminates processing of the current VCL subroutine and starts request processing again in the vcl_recv subroutine.
Common use cases for restarting a request include:
- in case of an error response, to retry an origin server or switch to an alternative backend
- to allow a request to be 'annotated' with data from an API call (a pattern we call 'preflighting')
Upon restart, all backend response (beresp), cache object (obj) and client response (resp) variables are discarded. The state of the client request (req) is preserved, along with any modifications to it. If a restart is performed in the vcl_hit, vcl_fetch, or vcl_error subroutines, modifications made to req may not survive a restart due to the effects of clustering.
After a restart, clustering is automatically disabled. To re-enable it, set the value of the HTTP header Fastly-Force-Shield to "1".
Limitations to avoid loops
Requests are limited to three restarts, to avoid infinite loops. The fourth restart will trigger a 503 Service Unavailable error.
As a result it's essential to execute the restart statement conditionally.
Try it out
restart 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.
Detect leaked passwords
Detect requests that contain submitted passwords and use a service to determine whether the password has leaked before allowing the request to proceed to origin (data from haveibeenpwned).
Serve stale to search crawlers for better ranking
Prioritize human traffic over search crawlers by serving stale content to crawlers.
Smoke test a new origin
Send a copy of your traffic to a test origin before returning a response from production.
