MageEnv
Server room network cabling

Performance

Magento 2 Cache Issues: Troubleshooting Varnish, Redis, and Full Page Cache

MageEnv TeamMageEnv Team·2026-07-06·7 min read

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:clean

cache: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-Debug

HIT 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=6

Using 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 ping

A 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 layout

Re-enable everything before you're done:

bin/magento cache:enable

Quick Diagnostic Order

  1. bin/magento cache:status — confirm which caches are even enabled.
  2. Check the X-Magento-Cache-Debug header to see if Varnish/FPC is the layer serving stale content.
  3. Regenerate Varnish's VCL if the exported version doesn't match your Varnish version.
  4. redis-cli ping to isolate whether Redis itself or Magento's config is the problem.
  5. Check env.php cache and session blocks separately — they can be misconfigured independently of each other.