How to configure HTTP cache and reverse proxy for Shopware 6?
Quick Answer
Shopware 6 supports built-in HTTP caching, but most high-traffic stores also add a reverse proxy layer like Varnish or Nginx FastCGI cache to reduce PHP execution and database load. The key is configuring cache invalidation correctly so product, pricing, and inventory updates purge immediately instead of serving stale content. Below is the setup flow we use on production Shopware stores, including cache headers, reverse proxy rules, invalidation, and testing.
Before You Start
- ✦ SSH access to the server — you’ll need to edit web server and Shopware environment configs
- ✦ Production mode enabled — HTTP cache behaves differently in development environments
- ✦ A staging environment — bad cache rules can break carts, login sessions, and pricing
Enable Shopware HTTP cache
Start with Shopware’s built-in HTTP cache before adding an external reverse proxy. This layer handles cache tagging and invalidation logic internally. In most setups, you’ll enable it through environment configuration and then warm the cache from CLI. Stores with large catalogs benefit immediately because category and CMS pages stop rebuilding on every request.
- Set APP_ENV=prod in your environment config
- Run cache:warmup after deployment
- Verify storefront responses include cache headers
bin/console cache:clear
bin/console cache:warmupAdd a reverse proxy
Once Shopware cache is working, place Varnish or Nginx in front of PHP-FPM. Varnish is usually the better fit for larger stores because it handles high concurrency and tag-based purging very well. Nginx FastCGI cache is simpler and cheaper operationally for mid-sized stores. Either way, the proxy should cache anonymous storefront traffic only.
- Route public traffic through Varnish or Nginx
- Bypass cache for carts, login, checkout, and account pages
- Cache GET and HEAD requests only
Configure cache invalidation
Fast caching is useless if updates stay stale for minutes or hours. Shopware solves this using cache tags. When a product or CMS page changes, Shopware sends invalidation requests to the reverse proxy. Your job is making sure those purge requests actually reach the proxy layer and clear the right objects.
- Enable BAN or PURGE support in Varnish
- Allow purge requests from trusted internal IPs only
- Test product updates and verify immediate invalidation
Set proper cache headers
Your reverse proxy depends on clean cache headers. Anonymous storefront pages should usually return public cache headers with a sensible TTL. Dynamic endpoints should return no-cache or private responses. Static assets like CSS, JS, and product images should use very long cache lifetimes with hashed filenames.
- Set public cache-control headers for CMS and category pages
- Use long browser cache TTLs for compiled assets
- Verify headers with curl or browser dev tools
Test cache behavior
Before going live, test cache hit ratios and invalidation paths under real conditions. A store can look fast during manual testing but still collapse under traffic because fragments bypass cache unexpectedly. Watch response headers, origin requests, and PHP worker usage during load testing.
- Check for HIT and MISS response headers
- Run load testing against category and search pages
- Monitor CPU and PHP-FPM usage during spikes
Shopware Cache Setup Checklist
0 of 8 completeMistakes Most Developers Make
! Caching logged-in customer pages
What happens: Customers can see incorrect carts, account data, or pricing.
Fix: Exclude all session-dependent routes from proxy caching and validate cookie behavior carefully.
! Missing purge permissions
What happens: Product and inventory updates stay stale until cache expiry.
Fix: Allow purge or BAN requests from your application server and test invalidation after every deployment.
! Ignoring cache hit ratios
What happens: Stores look cached but still overload PHP during traffic spikes.
Fix: Monitor HIT versus MISS headers and investigate pages bypassing cache unexpectedly.
Key Takeaway
The short version: Shopware’s built-in HTTP cache handles the application logic, while Varnish or Nginx handles high-speed delivery at the edge. The biggest problems usually come from bad invalidation rules or caching customer-specific pages accidentally. Focus first on anonymous storefront traffic, correct purge handling, and response headers. Once that works, load test the store before peak campaigns or launches. Start with Step 1—that one alone handles most of it.
Related Answers
Was this answer helpful?
Your feedback helps us improve our answers.
Still need help?
Talk to our Shopware experts
We've handled GDPR/CCPA compliance for dozens of EU & US Shopware stores.