Performance
Magento 2 Cache Issues: Troubleshooting Varnish, Redis, and Full Page Cache
Magento's caching is actually three separate systems working together — config/block cache, Redis as a cache and session backend, and Varnish (or the built-in cache) for full-page caching. Most "cache issues" are really "I cleared the wrong one" issues.
First: Know Which Cache You Actually Need to Clear
bin/magento cache:status- Config/layout/block cache — clear this after changing configuration, layout XML, or template code.
- Full page cache (Varnish or built-in) — clear this when storefront pages show outdated content despite the config cache being fine.
- Redis — this backs both cache storage and sessions; connection issues here affect logins and cart persistence, not just page content.
bin/magento cache:flush
bin/magento cache:cleancache:clean invalidates cache entries (Magento can regenerate them as needed); cache:flush wipes the storage entirely. Reach for flush when something seems structurally broken, clean for routine "did my change take effect" checks.
Verifying Varnish Is Actually Serving What You Think
Check the debug header to see if a request hit cache or passed through to Magento:
curl -I https://yourstore.com | grep X-Magento-Cache-DebugHIT means Varnish served a cached copy — if you just made a change and still see HIT, the page genuinely wasn't invalidated, which usually points to a VCL/version mismatch rather than Magento itself.
Regenerating Varnish's VCL
If Varnish is serving stale content after every fix except a full restart, or misbehaving in ways that don't match Magento's cache settings, regenerate the VCL and make sure the exported version matches your actual Varnish version:
bin/magento varnish:vcl:generate --output-file=var/varnish.vcl --export-version=6Using a VCL generated for the wrong Varnish major version is a common, hard-to-spot cause of "cache clearing does nothing" — Varnish silently ignores directives it doesn't understand rather than erroring loudly.
Redis Connection Errors
If cache or session errors reference Redis specifically, first confirm it's actually reachable:
redis-cli -h 127.0.0.1 -p 6379 pingA response of PONG confirms Redis itself is fine — if Magento still can't connect, the issue is almost always a mismatch between app/etc/env.php and Redis's actual host/port/database:
'cache' => [
'frontend' => [
'default' => [
'backend' => 'Cm_Cache_Backend_Redis',
'backend_options' => [
'server' => '127.0.0.1',
'port' => '6379',
'database' => '0',
],
],
'page_cache' => [
'backend' => 'Cm_Cache_Backend_Redis',
'backend_options' => [
'server' => '127.0.0.1',
'port' => '6379',
'database' => '1',
],
],
],
],Note the separate database index for the page cache backend versus the default backend — a common misconfiguration is pointing both at the same Redis database, which works but makes it much harder to clear one without affecting the other.
Sessions Disappearing or Logins Not Sticking
If users get logged out unexpectedly or carts don't persist, check whether sessions are also configured to use Redis (a separate session block in env.php from the cache block above) and confirm that connection independently — a healthy cache connection doesn't guarantee a healthy session connection if they're pointed at different Redis instances or databases.
During Active Development
Full page cache actively fighting you while you iterate on templates is common enough that Magento supports disabling specific cache types entirely while you work:
bin/magento cache:disable full_page block_html layoutRe-enable everything before you're done:
bin/magento cache:enableQuick Diagnostic Order
bin/magento cache:status— confirm which caches are even enabled.- Check the
X-Magento-Cache-Debugheader to see if Varnish/FPC is the layer serving stale content. - Regenerate Varnish's VCL if the exported version doesn't match your Varnish version.
redis-cli pingto isolate whether Redis itself or Magento's config is the problem.- Check
env.phpcache and session blocks separately — they can be misconfigured independently of each other.