WordPress a prueba de caídas: cómo configurar Object Cache Pro con “fail-open” en wp-config.php para seguir online si Redis falla

La caché de objetos es uno de los pilares del rendimiento en WordPress moderno. Object Cache Pro (OCP), el plugin comercial optimizado para Redis, reduce drásticamente consultas y latencias al guardar en memoria resultados de operaciones frecuentes. Sin embargo, cuando el back-end Redis se cae, se satura o queda inaccesible por red, el riesgo es claro: el propio WordPress puede ralentizarse o devolver errores si el plugin sigue intentando hablar con un servicio que no responde.

La solución pasa por un patrón sencillo y eficaz: fail-open. En lugar de “romper” el sitio cuando Redis no está disponible, se desactiva la caché de objetos de forma automática y WordPress continúa funcionando con su comportamiento por defecto (sin Redis), evitando caídas y mejorando la experiencia del usuario en situaciones de incidente.

A continuación se explica, en formato guía práctica, cómo integrar un fail-open simple directamente en wp-config.php, junto con una configuración comentada de Object Cache Pro. El objetivo: máxima resiliencia con el mínimo de complejidad.

---

¿Qué se va a conseguir?

• Detección rápida (≈ 200 ms) de si Redis está escuchando.
• Desactivación automática de Object Cache Pro si Redis no responde.
• Continuidad de servicio: el sitio sigue cargando sin errores ni pantallas en blanco.
• Restablecimiento automático: cuando Redis vuelve, Object Cache Pro se activa al próximo arranque/ciclo.

---

El fragmento clave en wp-config.php

Coloque este bloque antes de que WordPress cargue sus constantes definitivas y siempre antes de incluir el drop-in de caché. En la práctica, sitúelo por encima de otras constantes relacionadas con Redis/Cache y por debajo de las credenciales de base de datos para mantener el orden lógico.

/**
 * Fail-open simple de Redis para Object Cache Pro
 */
$__fp = @fsockopen('127.0.0.1', 6379, $errno, $errstr, 0.2);
define('WP_REDIS_DISABLED', ! $__fp);
if ($__fp) {
    fclose($__fp);
}

/**
 * Object Cache Pro setup
 */
define('WP_REDIS_CONFIG', [
    'token'            => 'privatetoken',
    'host'             => '127.0.0.1',
    'port'             => 6379,
    'username'         => 'USERNAME',
    'password'         => 'PASSWORD',
    'prefix'           => 'yourownprefix-rcredis',
    'database'         => 11,
    'timeout'          => 0.5,
    'read_timeout'     => 0.5,
    'retry_interval'   => 10,
    'retries'          => 7,
    'backoff'          => 'smart',
    'compression'      => 'lzf',
    'serializer'       => 'igbinary',
    'async_flush'      => true,
    'split_alloptions' => true,
    'prefetch'         => true,
    'strict'           => true,
    'debug'            => false,
    'save_commands'    => false,
]);
Lenguaje del código: PHP (php)

Qué hace: intenta abrir un socket TCP contra 127.0.0.1:6379 con un timeout de 0,2 s. Si no puede, define WP_REDIS_DISABLED como true. Object Cache Pro respeta esa constante: no se inicializa y WordPress sigue su ejecución sin la caché de objetos externa.

---

Por qué este “fail-open” funciona (y cuándo conviene)

1. Degradación controlada
   Sin Redis, WordPress sigue leyendo de MySQL. Puede perder algo de rendimiento, pero no se cae. Para quien prioriza disponibilidad, es mejor degradar que dejar de servir.
2. Tiempo de detección corto
   Un fsockopen() con timeout de 0,2 s (200 ms) evita que la pila PHP/WordPress desperdicie segundos valiosos intentando reconectar. En producción de alto tráfico, esos segundos se multiplican y saturan recursos.
3. Simplicidad operativa
   No añade dependencias, cron jobs ni un controlador externo. El propio wp-config.php decide en tiempo de arranque.
4. Reversión sin intervención
   Vuelve Redis, vuelve la caché. En el próximo arranque del proceso PHP (o vencimiento del opcache), el sondeo pasará y OCP se reactivará.

---

Buenas prácticas y ajustes recomendados

1) Ubicación exacta en wp-config.php

• Coloque el bloque antes de que se cargue cualquier drop-in (object-cache.php) y antes de otras constantes de Redis.
• Si usa entornos con config split (por ejemplo, wp-config.local.php), mantenga el sondeo en el archivo más cercano al servidor para reflejar el estado real de la instancia Redis.

2) Dirección y puerto correctos

• El ejemplo usa 127.0.0.1:6379. Adáptelo:
  • Docker/Kubernetes: use el DNS de servicio (p. ej., redis:6379) o la IP del pod/servicio.
  • Redis en socket UNIX: este snippet mide TCP. Si su Redis solo expone socket, valore un sondeo alternativo (p. ej., stream_socket_client('unix:///ruta/al/socket', ...)) o exponga también un puerto local para healthcheck.

3) Timeouts finos

• 0,2 s suele ser un buen compromiso. En redes remotas o con sidecars lentos, pruebe 0,3–0,5 s. Por encima de 1,0 s puede sentirse perezoso bajo carga.
• Los timeout de OCP ('timeout' => 0.5 y 'read_timeout' => 0.5) complementan el sondeo. Manténgalos cortos para evitar procesos PHP bloqueados.

4) Seguridad y secretos

• No exponga token, username y password en repositorios. Use variables de entorno inyectadas por el orquestador y constrúyalas en PHP: 'username' => getenv('WP_REDIS_USER') ?: null, 'password' => getenv('WP_REDIS_PASS') ?: null, 'token' => getenv('OCP_TOKEN') ?: null,
• Mantenga el database distinto por entorno (p. ej., 11 en producción, 12 en staging) para evitar colisiones.

5) Prefijos y multisitio

• Con multisite o varias instalaciones en el mismo Redis, prefix debe ser único por sitio/entorno (incluya el dominio o un hash).
• Evite prefijos genéricos (wp_) y documente su convención.

6) Compresión y serialización

• lzf y igbinary son elecciones populares: buen equilibrio entre CPU y Tamaño.
• Si su plataforma no tiene extensiones compiladas, OCP puede degradar a opciones nativas (más lentas). Compruebe que las extensiones están cargadas en PHP-FPM/CLI.

7) Retries y backoff

• Con 'retries' => 7, 'retry_interval' => 10 y 'backoff' => 'smart', OCP gestiona reconexiones de forma educada. Aun así, el fail-open evita que estos reintentos bloqueen el arranque en un incidente grave.

8) Modo “estricto”

• 'strict' => true ayuda a detectar misuse de la caché (tipo de datos, claves). Manténgalo activado en producción si sus desarrollos están probados.

9) Split alloptions

• 'split_alloptions' => true mitiga el clásico “alloptions bloat”, separando entradas grandes. Útil en sitios con muchos plugins que sobrecargan opciones.

10) Async flush con cabeza

• 'async_flush' => true agiliza vaciados (flush) sin bloquear peticiones. No abuse de los flush() masivos; programe purgas selectivas.

---

Operación y observabilidad: cómo saber que todo va bien

• Indicadores de cabecera: Object Cache Pro puede enviar cabeceras HTTP opcionales (cuando debug está en true en entornos controlados). Útil en staging para ver si la caché está activa.
• Métricas: exponga contadores de gets/hits/misses (por CLI o herramientas de APM) para comprobar el impacto cuando Redis está activo frente a desactivado.
• Alertas de salud: complemente este fail-open con un healthcheck del servicio Redis (p. ej., redis-cli PING) y alerte cuando falle. El sitio no caerá, pero sabrá que está degradado.

---

Escenarios especiales

Contenedores y redes overlay

Si fsockopen('127.0.0.1', 6379) siempre da positivo pero el tráfico real va por otro host (p. ej., redis-service en Kubernetes), el sondeo puede engañar. Alinee el host del sondeo con el mismo endpoint que usa OCP:

$redisHost = getenv('WP_REDIS_HOST') ?: '127.0.0.1';
$redisPort = (int) (getenv('WP_REDIS_PORT') ?: 6379);

$__fp = @fsockopen($redisHost, $redisPort, $errno, $errstr, 0.2);
define('WP_REDIS_DISABLED', ! $__fp);
if ($__fp) { fclose($__fp); }

define('WP_REDIS_CONFIG', [
    'host' => $redisHost,
    'port' => $redisPort,
    // ... resto de opciones
]);
Lenguaje del código: PHP (php)

Redis por socket UNIX

Si su Redis escucha en /var/run/redis/redis.sock y no expone TCP:

$socket = 'unix:///var/run/redis/redis.sock';
$__fp = @stream_socket_client($socket, $errno, $errstr, 0.2);
define('WP_REDIS_DISABLED', ! $__fp);
if ($__fp) { fclose($__fp); }

define('WP_REDIS_CONFIG', [
    'host' => null,
    'port' => null,
    'path' => '/var/run/redis/redis.sock',
    // ...
]);
Lenguaje del código: PHP (php)

Nota: compruebe permisos del socket (usuario de PHP-FPM) y políticas SELinux/AppArmor.

Rolling restarts y balanceadores

En entornos con varios pods o workers, algunos procesos pueden evaluar el sondeo como true y otros como false durante una transición. Es normal que convivan nodos con caché y nodos sin caché por unos minutos; use sesiones sin estado y evite dependencias fuertes de la caché para lógica crítica.

---

Validación segura (checklist)

1. Apague Redis (o bloquee su puerto) en staging y recargue PHP-FPM.
   • El sitio debe seguir respondiendo.
   • No deben aparecer errores de conexión a Redis en logs.
2. Encienda Redis y reinicie PHP-FPM.
   • El sitio debe activar la caché de nuevo sin cambios en código.
3. Pruebe carga moderada (p. ej., 200–500 rps) con y sin Redis.
   • Con Redis: menos consultas MySQL, menor TTFB.
   • Sin Redis: mayor TTFB, pero sin errores 5xx.
4. Revise métricas de hits/misses y validaciones wp_options/alloptions.

---

Preguntas frecuentes (FAQ)

¿El fail-open impacta al SEO o al usuario final?
Cuando Redis cae, el sitio no se rompe: solo pierde la aceleración de la caché de objetos. Los usuarios pueden notar ligero aumento de latencia, pero no errores. Para SEO es mucho mejor degradar el rendimiento que devolver 5xx.

¿Puedo combinar este enfoque con Page Cache/CDN?
Sí. La caché de objetos acelera PHP y consultas; la caché de página y la CDN reducen peticiones al origen. Si Redis falla, su CDN seguirá sirviendo contenido cacheado y el impacto real será menor.

¿Es seguro dejar credenciales en wp-config.php?
Es habitual, pero se recomienda variables de entorno y restringir permisos del archivo (0400/0440). Nunca suba wp-config.php con secretos a repositorios públicos.

¿Cómo saber si Object Cache Pro está activo en producción?
Use herramientas de APM, metrics endpoints del entorno, o habilite debug => true solo en staging para inspeccionar cabeceras/logs. También puede contrastar contadores en Redis (INFO, MONITOR en entornos controlados).

---

Conclusión

Integrar un fail-open de Redis en wp-config.php es una mejora pequeña de código con un enorme retorno operativo: evita caídas ante incidencias de red o mantenimiento del clúster, y mantiene WordPress funcionando con dignidad mientras el equipo corrige la causa raíz. Combinado con timeouts cortos, backoff inteligente y una configuración prudente de Object Cache Pro, su sitio gana resiliencia, previsibilidad y tranquilidad en los momentos críticos.