---
title: restart
summary: null
url: https://www.fastly.com/documentation/reference/vcl/statements/restart
---

```
restart();
```

**Available in:** recv, hit, fetch, error, deliver

The `restart` statement terminates processing of the current [VCL subroutine](https://www.fastly.com/documentation/reference/vcl/subroutines/) 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](https://www.fastly.com/documentation/guides/full-site-delivery/custom-vcl/clustering).

After a restart, clustering is automatically disabled. To re-enable it, set the value of the HTTP header `Fastly-Force-Shield` to `"1"`.

Restarts in user-defined subroutines work the same as built-in subroutines. As with return statements and variables, the validity of a restart within a user-defined sub depends on whether it would be valid to restart from its caller.

## Limitations to avoid loops

Requests are limited to three restarts per request, to avoid infinite loops. The fourth restart will trigger a `503 Service Unavailable` error.

The restart count is passed over the clustering protocol, which means this limit is enforced across both nodes in the cluster for a single request.

[Try it in Fastly Fiddle](https://fiddle.fastly.dev/191fe819)

As a result it's essential to execute the `restart` statement conditionally.