ShieldCache in practice: WordPress, online shops and apps with WebSockets

The following examples show proven settings. Adapt them to your website and keep an eye on the WAF log and the statistics after every change.

WordPress

1. Cache: Under Cache > Rules, choose the WordPress template and save. It excludes /wp-admin, /wp-login.php, /wp-json, /xmlrpc.php and /wp-cron.php from the cache and adds the login cookies. Add cookies from plugins (for example for language or consent) yourself.
2. HTML cache: If your pages are the same for all visitors, set a cache duration for HTML under Cache > Settings, for example 5 minutes.
3. Firewall: Choose the WordPress application profile, and the WordPress file protection profile under Settings.
4. Rate limit: Login template for /wp-login.php (10 requests per 60 seconds). If you do not need xmlrpc.php, limit this path too.
5. Captcha check: Rate limit as the trigger - this way, real users end up at a check instead of an error page after too many attempts.

Online shop with WooCommerce or Shopware 6

1. Cache: WooCommerce or Shopware 6 template. It excludes the shopping basket, checkout and customer account from the cache and adds session and shopping basket cookies. Afterwards, test the complete ordering process once.
2. Firewall: WooCommerce or Shopware profile. Payment providers often report back via an interface - if their calls appear in the WAF log, create an exception for this path only, initially as “Release & log”.
3. Rate limit: Checkout template for /checkout (30 requests per 60 seconds).
4. Country filter: Be careful with “Allow selected only” - payment services and search engines often access your site from other countries.

Apps with WebSockets, SignalR or Blazor Server

ShieldCache passes WebSocket connections through; you do not need to switch anything on for this. For applications with persistent connections such as SignalR or Blazor Server, these settings are recommended:

1. Path without cache: Enter the connection path under Cache > Rules > Paths without cache; for Blazor Server /_blazor, for SignalR the path of your hub, for example /hubs/.
2. No rate limit on this path: Connection setup, reconnection and fallback methods generate many requests to the same path. A rate limit would disconnect real users.
3. Firewall exception if needed: If calls to this path appear in the WAF log, create an exception with “Starts with” for exactly this path - initially as “Release & log”.
4. Idle time and keep-alive: With the cache switched on, a WebSocket connection ends after 60 seconds without data traffic in either direction. Common libraries send pings before then; this is the default for SignalR and Blazor Server. If you have extended the keep-alive interval, keep it below 60 seconds.
5. Multiple origins: Blazor Server keeps the state of each connection in the memory of one server. For further origins, choose the Failover distribution so that all requests stay on the same server.
6. Visitor IP: If your application reads the IP from a fixed header of a previous protection service, enter it as a custom header under Origin > Advanced - see Setting up the origin server.

Agencies and multiple websites

Each website is a separate site in the project, with its own domains, rules and statistics. With Professional you protect three websites, with Enterprise ten. The rules of a site only apply to that site - so you can set stricter rate limits for a shop than for a simple business card website.