Why can an Azure Front Door origin override disable caching?

Definition: In Azure Front Door Standard and Premium, a route configuration override can replace the origin group or caching configuration used for a request. When the action overrides the route configuration, Azure Front Door requires an explicit caching setting; without one, caching is disabled for that request.

Key facts

• The route configuration override action can change the origin group or caching configuration, and Microsoft states that caching must be configured when the route configuration is overridden. Microsoft's rule set actions reference documents this behavior.
• The route's Caching option enables caching of static content in Azure Front Door. Microsoft's route configuration guide describes the option in the route settings.
• Rules Engine caching configuration takes precedence over the route configuration. Microsoft's caching documentation also states that a disabled cache setting prevents response contents from being cached regardless of origin response directives.
• With caching enabled, the override can define the query string cache-key behavior, compression, cache behavior, and cache duration. The maximum cache duration documented for the action is 366 days.

What does the origin override replace?

An origin group is the group Azure Front Door forwards traffic to when a request reaches the origin. The route configuration guide lists the origin group, origin path, forwarding protocol, caching, and rule sets as route settings. The route's Caching option enables caching of static content.

The rule action has an Override origin group property. When it is set to Yes, the action requires an origin group and a forwarding protocol, and those values replace the corresponding settings in the Front Door endpoint route. The same action has a separate Caching property with two supported values: Enabled, which forces caching for the request, and Disabled, which forces it off.

This separation explains the behavior. An origin-group override changes where the request is forwarded, while the action also becomes responsible for the caching choice when the route configuration is overridden. The rule reference states that leaving this caching configuration unconfigured disables caching for the request.

Why does an override need an explicit cache setting?

Azure Front Door evaluates caching at the edge. When caching is configured on a route, the receiving edge site checks for a valid cached response. Without one, the request is forwarded to the origin. Rules Engine caching configuration always overrides the route configuration, so a rule-level decision can replace the route-level setting.

The caching documentation limits cacheability further. Only GET requests are cacheable. Responses with Cache-Control values such as private, no-cache, or no-store remain uncacheable even when Rules Engine overrides the caching behavior. These response directives are part of the origin response, while the rule action determines whether Front Door applies caching for the matched request.

What should the rule configure?

When the action sets Caching to Enabled, Microsoft documents settings for the cache key, compression, cache behavior, and duration. The cache behavior can honor the origin, always override the origin's TTL, or provide a TTL when the origin supplies none. A cache duration is required for the two override modes, and the documented maximum is 366 days.

The reference gives this JSON example for a route configuration override that includes customerId in the cache key, enables compression, and honors the origin's caching policies:

{
  "name": "RouteConfigurationOverride",
  "parameters": {
    "cacheConfiguration": {
      "queryStringCachingBehavior": "IncludeSpecifiedQueryStrings",
      "queryParameters": "customerId",
      "isCompressionEnabled": "Enabled",
      "cacheBehavior": "HonorOrigin",
      "cacheDuration": null
    },
    "originGroupOverride": null,
    "typeName": "DeliveryRuleRouteConfigurationOverrideActionParameters"
  }
}

The query string setting can ignore all query strings, use each full URL, ignore specified parameters, or include specified parameters. If a specified-parameter mode is selected, the query parameter names are supplied separately.

Related terms

• How can Azure Front Door ignore selected tracking parameters in its cache key?
• Does Azure Front Door insert a separator when appending a response header?
• How can Azure Front Door preserve the rest of a path during a rewrite?

FAQ

Does choosing a different origin automatically turn caching off?

The documented rule action combines origin-group override and caching controls. When the route configuration is overridden, the action requires a caching configuration, and an unconfigured caching setting disables caching for the request.

Can an enabled override cache every response?

No. Azure Front Door only caches GET requests and honors private, no-cache, and no-store response directives. A response must therefore remain cacheable after the rule setting is applied.

Which cache behavior should a rule use?

HonorOrigin follows the origin response directive. OverrideAlways uses the action's duration when the response is cacheable, while OverrideIfOriginMissing supplies that duration when the origin provides no caching TTL.

Sources

1. Microsoft Learn, "Rule set actions", 4 June 2025
2. Microsoft Learn, "Caching with Azure Front Door", 15 July 2026
3. Microsoft Learn, "Add a new endpoint with Front Door manager", 1 May 2026

---

Check how a page reads to answer engines. Open the GEO score analyzer