Qué importa primero: WordPress puede cargar wp-content/object-caché.php antes de plugins normales. Si esa caída requiere Redis y no se puede conectar, parte pública, administrador, cron y CLI pueden fallar o ser muy lentos.
Qué indica realmente este síntoma
Reiniciar Redis puede restaurar el servicio temporalmente, pero la política de servidor, puerto, contraseña, selección de bases de datos, red y desalojo todavía necesita verificación.
Recopila pruebas antes de cambiar nada
- Captura el error Redis, el servidor de destino, el puerto y el índice de base de datos.
- Comprueba si el objeto-caché.php permanece activo incluso cuando su plugin está desactivado.
- Prueba la conectividad desde el entorno de ejecución de WordPress, no solo desde el servidor.
- Inspecciona la memoria Redis, los expulsiones, la autenticación y el historial de reinicioss.
Causas más habituales
- Servicio no disponible: Redis se detiene, reinicia o es inalcanzable a través del límite entre contenedores o redes.
- Desajuste de credenciales: El drop-in utiliza una antigua contraseña o índice de base de datos.
- Caída obsoleto persistente: El plugin fue eliminado, pero el objeto-caché.php sigue cargando.
- Presión de la memoria: Los expulsiones o reinicios de OOM hacen que el comportamiento de caché sea inestabla.
Secuencia segura de diagnóstico y reparación
- Restaurar la conectividad con Redis o eliminar temporalmente la caída específica con un rollback listo.
- Alinea la configuración de la conexión a través del entorno, plugin y los secretos del contenedor.
- Vacía solo la base de datos caché afectada después de confirmar que no almacena sesiones ni colas.
- Reactiva el almacenamiento en caché persistente y probar las solicitudes frías y cálidas, administración y cron.
Cómo distinguir entre las causas probables
No trates Servicio no disponible y Desajuste de credenciales como causas equivalentes. Redis se detiene, reinicia o es inalcanzable a través del límite entre contenedores o redes. En cambio, el drop-in utiliza una antigua contraseña o índice de base de datos. Para distinguirlas, usa estas dos comprobaciones: Captura el error Redis, el servidor de destino, el puerto y el índice de base de datos; y comprueba si el objeto-caché.php permanece activo incluso cuando su plugin está desactivado. Con esos datos podrás decidir si conviene aplicar la primera acción controlada —Restaurar la conectividad con Redis o eliminar temporalmente la caída específica con un rollback listo— o si debes conservar el estado actual y ampliar la investigación.
En un sitio de WordPress en producción, repite la petición que falla mientras compruebas una página que funciona correctamente y el área de administración. Un fallo aislado en una ruta requiere un rollback más acotado que un problema que afecta a PHP, la base de datos o todas las peticiones. Documenta la fecha y hora exactas, la URL o transacción afectada, el último estado correcto conocido y cada cambio realizado durante el diagnóstico. Ese registro permite distinguir una reparación reproducible de una desaparición temporal del síntoma.
Qué no debes hacer
No vacíes una instancia de Redis compartida entera a ciegas. Otros sitios, sesiones, colas o bloqueos pueden utilizar diferentes bases de datos lógicas o prefijos.
Cómo verificar la reparación
- End frontal, administración, REST y cron funcionan con el estado caché previsto.
- Redis permanece conectado a través del reinicio y la carga realista.
- No aparecen datos obsoletos, claves cruzadas o expulsiones masivas.
Que el síntoma visible desaparezca no es suficiente. Cierra la incidencia solo cuando la acción original que fallaba, el recorrido de negocio relacionado y los registros relevantes confirmen que el problema ha desaparecido.