Redis object caching can reduce repeated database work, but it is not a universal speed switch. When a site behaves differently with object cache enabled, debug the cache as a system rather than repeatedly flushing it.
Confirm the connection you think WordPress is using
Verify host, port or socket, database index, authentication and the active object-cache drop-in. Multiple WordPress sites sharing Redis need deliberate separation.
Use unique cache prefixes in shared environments
When several sites share one Redis database, key collisions can produce extremely confusing cross-site behavior. Prefixes should be unique and stable for each installation.
Look at eviction and memory pressure
A cache that constantly evicts useful objects may add network work without retaining the data you expect. Memory policy and workload size matter more than simply seeing that Redis is “connected.”
Understand persistent groups and invalidation
WordPress and plugins assume specific invalidation behavior. Stale data can come from application code that does not clear a changed value correctly, not only from Redis itself.
Do not use flush-all as a diagnostic method
If every symptom disappears only after flushing the cache, capture which keys and request paths are involved before the next flush. Otherwise the evidence is removed each time.
Test with and without the object-cache drop-in
A controlled comparison can show whether Redis is part of the failure path. Do it in staging or a safe maintenance window when the site depends on cached session-like data or heavy traffic.