Error Establishing a Redis Connection: The Drop-In Is Talking to a Server That Is Not There

"Error establishing a Redis connection" is printed by the object cache drop-in at wp-content/object-cache.php, not by WordPress core: the drop-in tried to reach the Redis server and could not. Rename that file and the site comes back immediately on the default, non-persistent cache. Then find out why Redis is unreachable, fix it, and flush Redis before you put the file back.

Where the message comes from

WordPress core's object cache does not talk to Redis, and this message is not in core. What it does have is a hook point: in wp_start_object_cache(), called early in wp-settings.php, core checks whether wp-content/object-cache.php exists and, if it does, loads it with require_once. If the file defines wp_cache_init(), core switches into "external object cache" mode and every wp_cache_get() and wp_cache_set() call from then on goes through the drop-in.

The drop-in is usually installed by a caching plugin or by the host. It connects to Redis, and when the connection fails it decides what to do. Some drop-ins stop the request with this message; others log the failure and carry on without caching. Which behaviour you get depends on the drop-in and its settings, often a "graceful" or fail-open constant in wp-config.php.

Two details of core's loading explain most of the confusion:

You can see the file in the admin under Plugins › Drop-ins, where WordPress labels it "External object cache."

Get the site back first

Rename the drop-in over SFTP, in the hosting file manager or from a shell:

mv wp-content/object-cache.php wp-content/object-cache.php.off

The site now runs on WordPress's built-in object cache, which lives only for the length of one request. Nothing is lost: an object cache holds copies of database data, not the data itself. Expect more database queries and slower admin pages until Redis is back.

Find out why Redis is unreachable

Work from the server outwards. Each check rules out one layer:

redis-cli ping                      # PONG = server is running and reachable locally
redis-cli -s /path/to/redis.sock ping   # if the site uses a Unix socket
php -m | grep -i redis              # is the PHP extension loaded for the CLI?

The common causes, roughly in order of frequency:

1. The site moved to a new host and Redis did not. A migration copies wp-content in full, drop-in included. The new server has no Redis, or has it on a different port or socket. This is the most frequent cause of a sudden failure right after a move.
2. The Redis service stopped. A server reboot without Redis enabled at boot, or the kernel killing it when memory ran out. Check the service status and the system log.
3. Connection settings no longer match. Host, port, socket path, password, database number. Drop-ins read these from constants in wp-config.php; a server upgrade that moved the socket, or a new password, breaks the connection without anything changing in WordPress.
4. The PHP extension is missing. After a PHP version upgrade, the Redis extension is often not installed for the new version. php -m on the command line may show it while PHP-FPM does not, because they use different configuration; check a temporary phpinfo() page served by the web server, and delete it afterwards.
5. Redis is full and refusing writes. When maxmemory is reached and the policy is noeviction (the default), Redis answers writes with an OOM error instead of storing data. The connection itself works, but a drop-in that treats every Redis error as fatal can show the same message. redis-cli info memory shows usage against the limit.

The trap: stale data when you switch back

Here is the step most guides skip. While the drop-in was off, WordPress wrote changes straight to the database: options, posts, user sessions, transients. If the Redis server itself was running the whole time, for example when only the socket path was wrong, or if it saved its data to disk and reloaded it on restart, it still holds the values from before the outage.

Put the drop-in back without flushing and WordPress reads those old copies first. Symptoms range from settings that seem to revert, to a plugin you deactivated during the outage running again, because active_plugins is one of the options read from cache on every request.

So the order matters:

1. Fix the connection.
2. Flush the Redis data the site uses: redis-cli -n <database> FLUSHDB on the site's database number only.
3. Rename object-cache.php.off back to object-cache.php.

wp cache flush only reaches Redis while the drop-in is in place, so it cannot replace step 2. Running it right after step 3 works on a quiet site, but a busy one serves stale values in the seconds between.

Do not run FLUSHALL on a shared server: it empties every database on that Redis instance, including other sites' caches and any non-cache data stored there. Clearing the other layers in the right order is covered in how to clear the WordPress cache.

Common mistakes

• Renaming the plugins folder and concluding the problem is not caused by caching.
• Deleting wp-content/cache or the caching plugin's folder while leaving object-cache.php in place.
• Restoring the drop-in without flushing, then chasing "settings that will not save".
• Turning on a fail-open setting and never noticing that the cache is off. If you use one, make sure connection failures still reach the debug log.

Verify

• redis-cli ping returns PONG using the same host or socket as the drop-in.
• With the drop-in restored, the front end and the admin load without the message.
• Tools › Site Health no longer recommends a persistent object cache, which it only does while no external cache is active.
• redis-cli -n <database> dbsize grows as you browse the site, which shows WordPress is writing to it.