Sucuri Docs > Website Firewall > Troubleshooting > Troubleshoot Cache Issues

Troubleshoot Cache Issues

March 27, 201910 min read Nate Chaddock

If you have caching issues on your website, here’s how you can solve your problem. As you work through the steps, they will become more advanced. Check if your problem has been solved before moving to the next step.

Keep in mind that caching is one of the most important techniques available to speed up your website and save resources.

  1. Check what the firewall is doing
  2. Clear the Firewall Cache
  3. Clear the Browser Cache
  4. Set Cache Level to Site Caching
  5. Cache Exceptions & Versioning
  6. Cron Job
  7. WebHook/Plugin
  8. Micro-caching
  9. Varnish, Squid, Redis, Memcached and Similar
  10. Non-Cached Pages
  11. Mobile Version
  12. Session Cookies and Private Pages
  13. Disable the Cache

1. Check what the firewall is doing

Before changing anything, find out whether the firewall is actually serving the page from its cache. To check, run this command three times, replacing the URL:

curl -s -o /dev/null -D - https://yourdomain.com/your-page/ | grep -i -E 'x-sucuri-cache|x-sucuri-id|cache-control|set-cookie'
  • x-sucuri-cache: HIT means the page came from the firewall cache.
  • MISS or BYPASS on every run means the firewall isn’t caching it. The problem is then elsewhere, such as your browser or your server’s own cache (steps 3 and 9).

The firewall stores a page only on its second request, so a cacheable page shows MISS, MISS, HIT. See Investigating Cache Headersfor every value.

2. Clear the Firewall Cache

Clear the cache from the Firewall dashboard: Performance → Clear Cache.

3. Clear the Browser Cache

Your browser caches a lot of content to make browsing faster, but that can result in an older version of the site being displayed. To avoid that, clear the browser cache and cookies or open the page in a private/incognito window..

4. Set Cache Level to “Site Caching”

Site

As explained in Caching Options, with Site Caching the firewall respects your server’s cache headers. It doesn’t cache pages that send Cache-Control: private, no-store or no-cache, an Expires date in the past, or Set-Cookie. This is the best option if you run a custom CMS, a forum, a membership site, or an online store.

Enabled and Minimal Caching levels will never cache a page that sends Cache-Control: private or Set-Cookie, but they ignore your server’s other cache headers and cache times.

Most popular applications send the correct cache headers, so authenticated users should not have issues. However, if you notice an issue or want to control how long pages are cached, you can check your application’s cache headers.

5. Cache Exceptions & Versioning

To stop specific pages or directories from being cached without disabling the whole cache, add them to Performance → Non-Cache URLs. See Cache Exceptions.

Attention: don’t add high-traffic pages or directories like /feed/ to the Non-Cache URLs settings. Your website will be more vulnerable to DDoS attacks if you do.

Images, .css, .js, .pdf, .txt, .mp3 and other static files are still cached on the firewall’s network, regardless of the cache setting chosen or the non-cached URL settings, unless your server sends them with Cache-Control: private. To see your changes use Developer Mode, clear the firewall cache or use Versioning.

Versioning means adding a query string such as ?ver=123.1 to the file’s URL and increasing it on each update (?ver=123.2). Each new version is fetched fresh from your server.

6. Cron Job

To clear the cache automatically, use a cron job.

Log in to the Firewall dashboard and then go to API → API Details. There you will see a Clear Cache (WAF API v1) button. Copy the link of the button and create a cron job on your server that opens that URL as often as you need.

For example, to clear the cache every 6 hours:

0 */6 * * * curl -skL "https://waf.sucuri.net/api?v2&k=api_key&s=api_secret&a=clear_cache" >/dev/null 2>&1

Replace api_key and api_secret with the values from API → API Details. If you copied the button’s link, just replace the whole URL between the quotes.

If you don’t know how to set up a cron job, see your hosting control panel’s documentation (cPanel, Plesk, InterWorx) or, on Linux VPS/Dedicated Servers, crontab -e.

ATTENTION: don’t clear the cache more often than you need. After each clear, every page has to be fetched from your server again, so clearing every hour or more often slows your site down and increases the load on your server. Clearing after each content update (step 7) is usually better.

If you don’t know how to do this, please open a General Support Request. A trained support agent can configure the cron job for you.

7. WebHook/Plugin

If you’d rather not use a cron job, clear the cache when your content changes.

If you are on WordPress, install the Sucuri Security plugin.

  1. Go to Sucuri Security → Firewall (WAF) in your WordPress dashboard.
  2. On the Clear Cache tab, select Clear cache when a post or page is updated.
  3. Press Clear Cache button.

Now, every time you update a post or page in WordPress, the Firewall cache will be cleared.

Sucuri Firewall PluginClear Cache Page

OR you can install and activate the Code Snippets plugin.

  1. Go to Snippets → Add New in your WordPress dashboard.
  2. In Name, enter “Sucuri Clear Cache”.
  3. In Code, paste this code: https://pastebin.sucuri.net/6gufoxj0t3
  4. Between the quotes of $key and $secret, enter your API Key and API Secret from API → API Details
  5. Press Save Changes and Activate.

Sucuri

For other platforms the logic is the same: when content changes (for example a post is updated), send a GET request to the Clear Cache URL from the API. Your developer should be able to assist with this task.

8. Micro-caching (max-age)

If a short delay before visitors see your updates is acceptable, set the Cache Level to “Site Caching” and have your server send a short cache time.

For example, 5 minutes:

Cache-Control: max-age=300

The firewall then keeps each page for 300 seconds, so your updates appear within 5 minutes, while most visits are still served from the cache. Most cache plugins/modules can set this header for you.

In case the Firewall is wrongly caching private pages, add the following code in your .htaccess file:

On Apache, you can set it in .htaccess:

# BEGIN Micro-caching for dynamic pages
<IfModule mod_headers.c>
  <FilesMatch "\.(x?html?|php)$">
    Header set Cache-Control "max-age=300"
  </FilesMatch>
</IfModule>
# END Micro-caching for dynamic pages

Note: Only use this for public pages. Pages that show personal or session data must not be cached: see step 12.

For NGINX or IIS servers, ask your hosting provider to convert these .htaccess lines to NGINX or IIS rules.

9. Varnish, Squid, Redis, Memcached and Similar

A common reason for seeing an old version of your content is a cache on your hosting server. If step 1 shows the firewall isn’t caching the page (MISS/BYPASS) and you still see old content, disable full-page caches such as Varnish or Squid, and clear other cache systems such as Redis, Memcached or your CMS cache plugin.

10. Non-Cached Pages

Some platforms don’t send the right cache headers for certain pages, such as WordPress password protected pages. Add those pages to Non-Cache URLs, then clear the firewall cache, or it won’t take effect for pages already cached.

11. Mobile Version

The firewall caches mobile and desktop visitors separately. It is able to detect phones and tables from the browser’s User Agent. A site with a separate mobile version usually works without any change.

If your mobile version isn’t served correctly:

Mobile version is not the same as responsive design. A responsive site sends the same page to every device and lets the browser adapt to it. Don’t add Vary: User-Agent to a responsive site. Almost every browser version has a different User-Agent, so the firewall would keep one copy per browser version and your cache hit rate would drop.

If you need assistance, please open a General Support Request.

12. Session Cookies and Private Pages

If your site uses cookies to keep members logged in, or to hold a shopping cart, and something breaks after activating the firewall (members get logged out, carts empty or show old content), a visitor-specific page is probably being cached.

  1. Make your server mark those pages as private. The firewall never caches a page sent with Cache-Control: private, for every Cache Level. On Apache, add to .htaccess:
    2. # BEGIN Prevent caching of private pages
<IfModule mod_headers.c>
  <FilesMatch "\.(x?html?|php)$">
    Header set Cache-Control "private, no-store, no-cache, must-revalidate"
  </FilesMatch>
</IfModule>
# END Prevent caching of private pages

    Or in PHP, before any output (check with your developer first):

    // Prevent the firewall and browsers from caching this page.
header('Cache-Control: private, no-store, no-cache, must-revalidate');

    Apply it only to the pages that need it (accounts, cart, checkout, members area), not the whole site, or nothing will be cached.

  2. Clear the firewall cache.

If you can’t change the server, add the private pages to Non-Cache URLs instead. That works on every caching level.

Vary: Cookie doesn’t help. Older versions of this article recommended Header append "Vary Cookie". On the firewall, Vary: Cookie doesn’t stop a page from being cached. Use Cache-Control: private, as explained above.

For NGINX or IIS servers, ask your hosting provider to convert these .htaccess lines to NGINX or IIS rules.

13. Disable the Cache

This option should be your last resort and should always be avoided if possible.

With the cache level set to Disabled:

  • Static files (images, .css, .js, .pdf, .txt, .mp3, .mp4, fonts and so on) are still cached for up to 3 days.
  • Pages are still cached for 1 minute, but only for visitors without any cookie.
  • If your server sends Cache-Control: max-age=XXX, the firewall follows it and caches the page for XXX seconds.

Don’t forget: static files are always cached by the firewall unless you use versioning (step 5) or Developer Mode. Another option is to serve static files from a separate sub-domain that isn’t behind the firewall’s cache, but that is an advanced setup best done by a specialist.

Was this article helpful?

Popular Articles