“Redis connection refused” in WordPress is usually an availability or configuration problem in the object-cache path, not a reason to clear the whole database. The site may still have perfectly valid persistent data while the cache client cannot reach Redis or is using the wrong endpoint, credentials, database number or socket.
First decide whether WordPress can run safely without Redis
Confirm whether the object-cache drop-in is required or optional for this site. If the application can fall back to the database, temporarily bypassing the broken cache layer may restore service while you diagnose it. Do not improvise this on a cluster where Redis also carries sessions, locks or other application state.
Evidence that separates network, service and configuration failures
- Redis host/socket, port and database configured for WordPress.
- Whether the Redis service is running and reachable from the WordPress container/host.
- The exact object-cache error and timestamp.
- Recent deploys, environment changes or credential rotations.
Check the cache client and server as two separate systems
A healthy Redis process does not prove WordPress is pointing at it, and a correct WordPress config does not prove the service is reachable. Validate both sides before flushing anything.
Restore the connection with the least destructive change
- Correct host/socket, port, authentication or network policy as needed.
- Verify the object-cache drop-in matches the plugin/runtime actually in use.
- Only flush cache data when you understand the scope and the application can rebuild it safely.
- Test frontend, admin and a representative write operation after reconnecting.
Scheduled failures can make an intermittent Redis problem look random
If errors correlate with background processing, compare WP-Cron and missed-schedule diagnostics. If the incident coincides with unexplained code or filesystem changes, use file-integrity triage instead of assuming Redis itself is the root cause.
Do not delete Redis data as the first troubleshooting step
A flush cannot repair a refused connection and may create a second incident if other services share the same Redis instance or database.
Verification
The cache client should reconnect consistently through normal requests and background jobs, WordPress writes should persist correctly, and Redis memory/error metrics should remain stable without repeated reconnect loops.
WP REPAIR INCIDENT STANDARD
Safe intervention sequence
Restarting Redis may restore service temporarily, but host, port, password, database selection, network and eviction policy still need verification.
- Capture the Redis error, destination host, port and database index.
- Check whether object-cache.php remains active even when its plugin is disabled.
- Test connectivity from the WordPress runtime, not only the host.
- Inspect Redis memory, evictions, authentication and restart history.
What must be verified
- Front end, admin, REST and cron work with the intended cache state.
- Redis remains connected through restart and realistic load.
- No stale data, cross-site keys or eviction storm appears.
Official technical sources
This guide explains the diagnosis. If the site is affected now, the intervention should preserve a rollback path and verify the real business journey.
See the emergency repair service →ABOUT THIS SYMPTOM
Frequently asked questions about this guide.
Will simply restarting Redis fix this permanently?+
A restart often restores service temporarily, but it does not confirm that host, port, password, database index, network path, and eviction policy are all correctly aligned. Without checking those, the same connection failure can recur under load or after the next deploy.
Is it safe to flush the entire Redis instance to clear the error?+
Not on shared Redis. Other sites, sessions, queues, or locks may live in different logical databases or use different key prefixes on the same instance, so a blind flush can break unrelated systems. Only flush the specific cache database confirmed to hold no sessions or queues.
Why does object-cache.php keep loading even after I deactivate or delete the caching plugin?+
object-cache.php is a drop-in file that WordPress loads directly from wp-content before normal plugins run, so removing the plugin does not remove the drop-in itself. The stale file has to be removed or replaced directly, otherwise WordPress keeps trying to connect to Redis through it.
Could this be a memory problem rather than a pure connectivity issue?+
Yes. Memory pressure causing evictions or out-of-memory restarts on the Redis side can produce the same connection instability as a genuine network or credential fault. Checking Redis memory usage, eviction counts, and restart history alongside the connection settings is necessary to tell the two apart.