To bypass the Edge Security Acceleration (ESA) cache for resources that match the default cache rule, create a rule to filter requests and set Cache Eligibility to Bypass Cache.
If no cache rules or configurations are set, caching on ESA points of presence (POPs) follows the default cache rule.
Scenarios
If your origin server has resources that you do not want to cache on ESA POPs, such as dynamic resources where each request must fetch the latest content from the origin, configure a bypass cache rule for those resources. Bypassing the cache for dynamic resources improves access performance.
Cache eligibility rules determine whether a request is cached by ESA edge nodes. Common use cases include:
Static resource caching — Improve performance by caching images, CSS, and JavaScript files at edge nodes.
Dynamic content bypass — Ensure login pages, APIs, and personalized content are not cached.
Dynamic-static separation — Cache static assets while bypassing dynamic requests to the origin server.
Selective no-cache — Prevent specific files or paths from being cached.
Procedure
In the ESA console, you can choose Site Management. In the Website column, you can click the target site.
In the navigation pane on the left, choose .
Click Create Rule and enter a Rule Name.
In the If requests match... section, set the request attributes to match. For more information about how to configure rules, see Composition of a rule expression.
In the Cache Eligibility area, select a cache policy and click OK.
Bypass Cache: All requests skip the POP cache and fetch directly from the origin, allowing you to view the latest resources from the origin server in real time. When enabled, only the Browser Cache TTL setting applies.
Eligible for Cache: All eligible requests are served from POP cache nodes instead of the origin. This avoids long origin fetch paths, reduces latency, and improves access performance.
Cache eligibility options and limitations
Bypass Cache
When Bypass Cache is selected:
Matching requests are forwarded directly to the origin server without being stored at ESA edge nodes.
Only the Browser Cache TTL setting takes effect. Other cache-related features (such as Cache Deception Defense and Serve Stale Content) are disabled for this rule.
ESA does not support configuring no-cache behavior based on HTTP response headers (such as
X-Fallback) or HTML comment markers. Use request-header-based or URL-based match conditions instead.
Default cache behavior
When no cache rules are configured, or when no rule matches a request, ESA applies the following default behavior:
Requests follow the ESA default cache policy.
Dynamic requests with URLs ending in
/are forwarded to the origin server by default.When the origin server returns a
no-cacheresponse header, the response is not cached.
Advanced cache features
The following features are disabled by default and must be manually enabled in a cache rule:
Cache Deception Defense: Protects against cache deception attacks.
Serve Stale Content: Allows ESA to serve stale cached content when the origin is temporarily unavailable.
Common configuration examples
The following examples cover high-frequency scenarios for configuring cache eligibility.
Example 1: Bypass cache for dynamic APIs
Scenario: Prevent dynamic API endpoints from being cached at edge nodes.
Configuration:
Match Condition: URL path contains
/api, OR URL path contains/prod-api/, OR file name extension equalsphpCache Eligibility: Bypass Cache
When specifying file name extensions, do not include the dot. Enter php, not .php.
Example 2: Bypass cache for admin and login pages
Scenario: Prevent WordPress admin pages, CMS management interfaces, or login endpoints from being cached.
Configuration:
Match Condition: URL path contains
/wp-admin, OR URL path contains/admin, OR URL path contains/loginCache Eligibility: Bypass Cache
Place this rule at the top of the rule list to ensure it takes priority over general static resource caching rules.
Example 3: Cache SPA root path
Scenario: ESA does not cache extension-free URLs (such as /) by default. To cache text/html content for single-page applications (SPAs):
Configuration:
Match Condition: Request header
Acceptcontainstext/htmlCache Eligibility: Eligible for Cache
Cache TTL: Set according to your SPA update frequency.
Example 4: Bypass cache for specific files
Scenario: Prevent specific files such as sitemap.xml from being cached.
Configuration:
Match Condition: URL path contains
sitemap(without file name extension), OR file name extension equalsxml(enterxml, not.xml)Cache Eligibility: Bypass Cache
Example 5: Dynamic-static separation
Scenario: Cache static assets while ensuring dynamic requests are forwarded to origin.
Recommended approach:
Delete any existing full-site cache rules.
Create a rule to cache static resources. For example, match file name extension equals one of
jpg,png,css, orjs.Create a separate rule to bypass cache for dynamic API endpoints. For example, match URL path contains
/api.
This approach prevents dynamic requests from being accidentally cached.
Configuration notes
One cache TTL per rule — A single cache rule can only define one cache TTL. If different file name extensions or directories require different cache durations, create a separate rule for each.
Rule independence — Disabling or deleting a specific cache rule does not affect caching behavior for other resources. ESA continues to match remaining rules in order.
Reducing origin load — Configure bypass cache rules for dynamic content and enable cache rules for static resources to minimize requests forwarded to the origin server.
FAQ
Why does my bypass cache rule not take effect?
Check the following:
Incorrect match condition: Verify the rule expression. Common mistakes include:
An OR condition unintentionally matches requests from other domains.
File name extension or path values are formatted incorrectly. For example,
.phpinstead ofphp.
Missing request characteristics: If the rule depends on a specific request header (such as
sec-fetch-site), confirm that actual client requests include this header.Insufficient rule priority: ESA evaluates rules from top to bottom. If the bypass cache rule is positioned below a long-TTL caching rule, the earlier rule may match first. Move the bypass cache rule to a higher position in the list.
Cache not flushed after rule change: After modifying rules, flush affected URLs or directories in the ESA console. Refreshing your browser does not invalidate content cached at edge nodes.
Plan limitations: The Free Edition may not guarantee consistent rule enforcement. Consider upgrading to a paid plan.
Verification approach: Check the
Serverresponse header to confirm whether requests are being processed by ESA edge nodes. Use an incognito browser window to eliminate local browser cache interference.
Why can't I log in, or why do pages redirect incorrectly after enabling ESA?
Cause: This typically occurs when a full-site cache rule or an improperly configured cache rule causes login cookies, session data, or dynamic API responses to be cached at ESA edge nodes.
Resolution:
Suspend or delete any suspicious full-site cache rules.
Create Bypass Cache rules specifically for login pages, CAPTCHA endpoints, and admin paths. Position these rules at the top of the rule list to give them the highest priority.
In the ESA console, flush the cache for the affected URLs.
Verify the fix using an incognito browser window.
If the issue persists after configuration is correct: Check your origin server business logic. For example, verify that 302 redirect logic correctly identifies the login state. If the origin server is not correctly handling login state, this is outside the scope of ESA.
What is the difference between "equals" and "contains" in match conditions?
Match type | Behavior |
Equals | Exact match of the specified URL path. Also automatically matches all sub-paths. For example, configuring |
Contains | Fuzzy match. Any URL that includes the specified string anywhere is matched. |
For hostname matching, both Equals and Contains produce equivalent results and can be used interchangeably.
Why does enabling cache rules make probing succeed, but disabling them causes timeouts?
When cache rules are active, ESA edge nodes serve requests directly from cache, reducing load on the origin server.
When cache rules are disabled, all requests — including high-volume dynamic requests — go directly to the origin server in real time. Under high-concurrency load testing, this can overwhelm the origin server and cause request timeouts.
This behavior reflects an origin server performance bottleneck, not an ESA issue. To address this:
Configure cache rules to reduce the volume of requests forwarded to origin.
Enable JS Challenge or Intelligent Rate Limiting to protect the origin server from excessive concurrent requests.
Related documentation
Rule-related features vary in effective priority, reentrancy, and effective granularity. For details, see Properties of Rule-Related Features.