In short. A ContentGuard block occurs before Fastly reaches the cache layer or VCL snippets.
Definition: No. Fastly applies ContentGuard category and identity actions before VCL in pre-cache inspection. A request blocked by those actions does not reach the cache layer or VCL snippets, so VCL cannot recover it.
Key facts
- Fastly's ContentGuard traffic management documentation requires Bot Management with pre-cache inspection on each service where ContentGuard is used.
- Fastly's Bot Management overview says pre-cache inspection examines all requests before the cache layer, including requests for cached and uncached resources.
- A category action covers all bots in that category. An identity action covers all requests from the selected bot, and changing it makes the category action
Custom. - Fastly requires Protection mode
Blockfor category and identity actions to be enforced.Logrecords results, whileOffleaves monitoring, logging, and blocking inactive. - Fastly documents VCL as a later stage: bots blocked by category or identity actions do not reach the cache layer or VCL snippets.
Where does ContentGuard sit in the request path?
Fastly calls ContentGuard its pre-cache inspection deployment. The Bot Management overview says that this deployment inspects every request before it reaches the cache layer and controls access to cached and uncached resources. It also identifies ContentGuard as the feature enabled by pre-cache inspection.
The ContentGuard page requires Bot Management to use pre-cache inspection on every Fastly service where ContentGuard is intended. On the Protection page, a category action applies to all bots in that category. A more specific identity action applies to requests from the selected bot, and changing that identity value changes the category menu to Custom.
Can VCL change a ContentGuard block?
No. Fastly's ordering statement places VCL after Bot Management applies category and identity actions. A bot rejected by one of those actions therefore has no request available to a VCL snippet, because it has not reached either the cache layer or VCL execution.
The Protection mode matters before this ordering takes effect. Block enforces the configured category and identity decisions. Log monitors and records results for observation, and Off disables monitoring, logging, and blocking. A category or identity action configured while the service is in Log is therefore not an active ContentGuard block.
What can VCL handle when the request reaches it?
Fastly documents VCL for custom bot logic beyond the Bot Management controls. Its example uses the bot category and bot name variables to produce a VCL error for a matching request:
if (fastly.bot.category.is_search_engine_crawler) {
if (fastly.bot.name ~ "Yandex") {
error 403 "Service restricted in this region.";
}
}
The same page describes custom response pages or redirects in vcl_error for error codes triggered by VCL logic. That is a response-handling path for a request that reached VCL and received a VCL-generated error. It is separate from a ContentGuard category or identity action that stopped the request earlier.
Fastly's vcl_recv reference defines that subroutine as running when Fastly receives a client request. Its default GET path then performs a cache lookup. ContentGuard's earlier block prevents the request from entering that VCL path.
How should you diagnose the result?
Start with Security, Bot Management, Protection for the service. Check the Protection mode, then inspect the category Action menu and the Configure bots identity actions. Block is the mode that enforces those decisions; Log supplies observation without enforcement.
If the request is allowed through those controls, inspect the VCL snippets placed in vcl_recv and any vcl_error snippet handling a VCL-generated status. If the category or identity action blocked the bot, Fastly's documented processing order puts the event before both the cache layer and those snippets. Fastly documents the ordering and reachability, but does not state a status code for this ContentGuard block in the traffic management page.
Related terms
- Does Fastly inspect bots before or after the cache?
- Why are Fastly ContentGuard category actions not enforced in Log mode?
FAQ
Does a cached response bypass ContentGuard?
No. Fastly says pre-cache inspection examines all requests before the cache layer and covers cached and uncached resources.
Does Log mode create a block that VCL can recover?
No active block is applied in Log mode. Fastly describes Log as monitoring traffic and recording results, while Block enforces category and identity decisions.
Can vcl_error customize a ContentGuard block?
Fastly documents vcl_error for error codes triggered by VCL logic. The ContentGuard page places VCL after category and identity enforcement, so its documented custom error path applies to VCL-generated errors that reach that stage.
Sources
Check how a page reads to answer engines. Open the GEO score analyzer