Problem:
You have placed your website behind CloudGuard and activated the cache mechanism. But the content (some URLs) of your website is not getting cached and is received from the origin server.
The Root Cause of the problem:
If the content is not being cached, there could be several reasons, outlined in the following order:
- Cache Mode: Ensure that you have activated the cache mechanism on your website.
- Developer Mode: Check if your site’s cache mechanism is in Developer Mode. In this scenario, no content is cached, and CloudGuard does not consider the page rules.
- Non-Static Files: By default, CloudGuard only caches static content. This includes addresses on your website with static extensions such as jpg, js, css, etc. HTML files and similar types are not cached by default. If you want the entire site to be cached, consider creating page rules that match the entire content and enable caching. (List of extensions that CloudGuard assumes as static content)
- Page Rule: Utilize page rules to enable or disable page caching for specific addresses on your website.
- Cache-Control: Check if your origin server sets the Cache-Control header to values such as private, no-store, no-cache, etc. These values tell the CDN that the page should not be cached, preventing the content from being saved in the cache.
- Expires: Your origin server sets the Expires header to an old date. When the content is considered expired upon receipt, it is not cached.
- Set-Cookie: Your origin server sends the Set-Cookie header in the response. Pages with a set cookie for the browser are not cached because the content of the cookie is used to distinguish users and may contain security values such as session keys. Consequently, the request leading to the setting of the cookie is not cached in the CDN. Note that other pages not changing the cookie are cached, and only the request resulting in a change to the cookie is not cached.
Troubleshooting:
You can examine the CG-Cache-Status header to determine the cache status of your pages. This header reflects one of the following values:
- HIT: The page had been cached and sent to the browser.
- MISS: The page was not available in the cache and was obtained from the origin server. It is now cached, and you should get a HIT on the next request, unless it expires due to timeout or cache deletion.
- EXPIRED: Similar to MISS, but the existing cache is expired, leading to the content being received again.
- UPDATING, STALE: This occurs only if you have enabled “Always On.” In this case, the cache has expired, but the origin server did not respond or throws an error. Consequently, the latest cache content (despite expiration) was sent to the client.
- Empty: If there is no CG-Cache-Status header, it indicates that the cache has not been enabled for this page.
Analysis Method:
To view the CG-Cache-Status header in your browser, activate Developer Tools (usually by pressing the F12 key) and navigate to the Networks tab.
On this tab, click on each request and check the followings:
- Ensure that the URL address of the request is related to CloudGuard. Note that when loading a page, various contents may be received from different websites and domains, not all of which are necessarily behind CloudGuard.
- The CG-Server-Tag header, is designed to show the node from which the information was received. Different nodes have separate caches.
- CG-Cache-Status header is designed to show the cache status.
- The Cache-Control header is designed to show which requests the origin server had about chaching the page.
- The Expires header is designed to show the period in which the page is allowed to be cached.
- The Set-Cookie header is designed to show whether the origin server has set a cookie or not.
To add a header to the table, simply right-click on the columns of the ‘Request Table’ in your browser. Then, select ‘Response headers’ > ‘Manage Custom headers’ to view the header’s value for all requests