Magento 2.4.9 Redis Unix Socket Bug: Silent Filesystem Cache Fallback

Magento 2.4.9 contains a particularly difficult Redis caching bug: a store can be configured to use Redis, report its cache types as enabled and continue serving pages normally—while silently writing its application cache to the filesystem instead.

There may be no Magento exception, no obvious warning in the logs and no failed cache command. Unless someone checks Redis itself and traces the cache adapter Magento constructed at runtime, the problem can go unnoticed.

We recently diagnosed this behaviour on a Magento 2.4.9 staging environment. This article explains the symptoms, the root cause, how to prove whether your installation is affected and the safe workaround we implemented.

The short version

The affected configuration uses a Unix socket for Magento’s default or page_cache Redis backend:

'backend' => 'redis',
'backend_options' => [
    'server' => '/var/run/redis/redis-server.sock',
    'database' => '14',
    'port' => '0',
]

Magento 2.4.9’s new Symfony-based cache implementation constructs the Redis connection incorrectly when server contains a socket path. The connection fails internally, but Magento catches the exception and silently creates a filesystem cache adapter instead.

The immediate workaround is to connect over the local TCP listener:

'backend' => 'redis',
'backend_options' => [
    'server' => '127.0.0.1',
    'database' => '14',
    'port' => '6379',
]

This keeps Redis local to the server while avoiding the broken Unix-socket handling.

Why this issue is easy to miss

Most routine Magento checks do not reveal it.

For example:

bin/magento cache:status

can report every cache type as enabled. Cache clean and flush commands can also complete successfully. The storefront remains operational because Magento has fallen back to its filesystem cache rather than losing caching altogether.

From an administrator’s perspective, everything appears healthy. In reality:

The expected Redis database remains empty.
Files continue accumulating below var/cache/.
Magento loses the operational and performance benefits expected from Redis.
Multi-node installations can suffer consistency problems because their fallback caches are local to each node.
No useful error may be written to the Magento logs.

This is an especially unpleasant failure mode because it looks like a working Redis configuration until the storage backend is inspected directly.

What changed in Magento 2.4.9?

Magento 2.4.9 replaced the older Zend-based caching layer with Symfony Cache. Existing cache backends are intended to remain supported, but the new connection provider does not currently build the correct connection string for a Unix socket.

The upstream analysis shows that Magento constructs a TCP-style DSN in the form:

redis://host:port/database

When the configured host is actually a filesystem path, the resulting value resembles:

redis:///var/run/redis/redis-server.sock:0/14

Symfony then interprets the socket filename as redis-server.sock:0, which does not exist. Magento catches the resulting exception and instantiates Symfony\Component\Cache\Adapter\FilesystemAdapter without logging the failure.

This exact behaviour is documented in Magento issue #41118. A proposed upstream correction is available in pull request #41001. At the time of writing, both remain open.

How to check whether your site is affected

1. Confirm the Magento version

Run the command using the PHP version assigned to the site:

php bin/magento --version

The case we investigated was running Magento 2.4.9.

2. Check the expected Redis database

If the cache should use database 14:

redis-cli -s /var/run/redis/redis-server.sock -n 14 DBSIZE

An empty database is suspicious if caching is enabled and the storefront has received requests.

To view a sample without using the expensive KEYS * command:

redis-cli -s /var/run/redis/redis-server.sock -n 14 SCAN 0 COUNT 20

Use SCAN on production systems because it is incremental and safer than asking Redis to return every key at once.

3. Look for filesystem cache entries

du -sh var/cache
find var/cache -type f | head

If the configured Redis database is empty while files are actively being created under var/cache/, Magento is probably using its fallback adapter.

4. Do not confuse session storage with application cache

Magento sessions, the default application cache and full-page cache should use separate Redis databases. Seeing keys in the session database only proves that Redis sessions work; it does not prove that Magento’s application cache is using Redis.

Similarly, a Redis full-page-cache database can legitimately remain empty when Varnish is selected as the full-page cache application.

Check the configured FPC application with:

php bin/magento config:show system/full_page_cache/caching_application

A value of 2 indicates Varnish.

Proving the silent fallback at runtime

During our investigation, Magento’s merged deployment configuration correctly reported:

'backend' => 'redis'

Redis was running, PHP’s Redis extension was installed, and both the Unix socket and TCP listener worked when tested as the website’s PHP-FPM user. Despite that, tracing the instantiated Magento cache frontend revealed:

Magento\Framework\Cache\Frontend\Adapter\Symfony
Symfony\Component\Cache\Adapter\FilesystemAdapter

We also performed a direct save and load through Magento’s own cache frontend. Magento returned success and could read the test value back, but the Redis database remained empty. That proved the operation was being served by the filesystem adapter rather than Redis.

This distinction is important: testing the socket with redis-cli, or even connecting successfully through PHP’s Redis class, does not establish which backend Magento has actually selected.

The workaround

Change the server and port values inside both relevant cache frontends in app/etc/env.php.

Before:

'cache' => [
    'frontend' => [
        'default' => [
            'backend' => 'redis',
            'backend_options' => [
                'server' => '/var/run/redis/redis-server.sock',
                'database' => '14',
                'port' => '0',
            ],
        ],
    ],
],

After:


'cache' => &#91;
    'frontend' => &#91;
        'default' => &#91;
            'backend' => 'redis',
            'backend_options' => &#91;
                'server' => '127.0.0.1',
                'database' => '14',
                'port' => '6379',
            ],
        ],
    ],
],

Apply the equivalent change to page_cache if Redis is used for Magento’s built-in full-page cache. When Varnish is active, that Redis FPC backend is not used for normal page delivery.

After changing the configuration:

php bin/magento cache:flush
systemctl restart php-fpm

Use the actual PHP-FPM service name on your server—for example, a Plesk handler may be named plesk-php84-fpm.

Verify the result

Browse several uncached areas of the site, then check Redis:

redis-cli -n 14 DBSIZE
redis-cli -n 14 SCAN 0 COUNT 20

A working Magento default cache should rapidly create entries such as cache data, tag sets and ID-to-tag mappings. In our case, the database immediately populated with keys carrying the configured Magento prefix.

You can also re-run:

find var/cache -type f -mmin -5

Remember that old filesystem cache files may remain after the switch. The important evidence is that new Magento application-cache activity appears in the correct Redis database.

Important security note about TCP Redis

Moving from a Unix socket to TCP does not mean Redis should be exposed publicly. Ensure Redis listens only on localhost or a properly protected private interface:

ss -lntp | grep 6379

For a single-server installation, the expected listener is normally 127.0.0.1:6379, not 0.0.0.0:6379. Firewall controls and Redis authentication should also be reviewed where appropriate.

Does this affect Redis sessions?

Not necessarily. Magento’s Redis session handler is separate from the new Symfony application-cache adapter. A working session configuration using:

'host' => '/var/run/redis/redis-server.sock',
'port' => '0',

can therefore be left unchanged if its Redis database is demonstrably populated and sessions are functioning correctly.

For the cache backend the option is named server; for Redis sessions it is named host. They should not be changed indiscriminately.

A separate Magento 2.4.9 preload-key issue

Magento 2.4.9 also has a confirmed issue involving preload keys with the new Symfony cache adapter. Contrary to older examples, the configured id_prefix should not currently be repeated inside each preload_keys value.

Use:

'id_prefix' => 'ef9_',
'preload_keys' => [
    'EAV_ENTITY_TYPES',
    'GLOBAL_PLUGIN_LIST',
    'DB_IS_UP_TO_DATE',
    'SYSTEM_DEFAULT',
],

rather than prefixing each entry with ef9_. This separate behaviour is tracked in Magento issue #40877.

Conclusion

The most concerning aspect of this Magento 2.4.9 bug is not simply that a Unix-socket connection fails. It is that Magento silently substitutes filesystem caching while its normal cache-management commands continue to report success.

If you have upgraded to Magento 2.4.9 and use a Redis or Redis-compatible Unix socket for the default cache, check the actual Redis keyspace rather than relying solely on bin/magento cache:status.

Until the upstream correction is merged and released, using a loopback TCP connection is a straightforward and effective workaround. Confirm that Redis remains bound securely, flush Magento’s caches and verify the target database directly.

Dx3webs provides specialist Magento hosting, performance investigation and server-level troubleshooting. If your Magento installation reports healthy caching but performance or cache behaviour suggests otherwise, contact us for a full runtime review.

Ready to get started?

We are here to help your business grow
Let's talk.