--- title: "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" description: "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 guarda..." url: https://wpdirecto.com/wordpress-a-prueba-de-caidas-como-configurar-object-cache-pro-con-fail-open-en-wp-config-php-para-seguir-online-si-redis-falla/ date: 2025-08-27 modified: 2025-08-27 author: "Editor WPDirecto" image: https://wpdirecto.com/wp-content/uploads/2025/04/redis-cache-wordpress.jpg categories: ["Plugins", "Rendimiento"] tags: ["cache", "object cache pro", "Redis Object Cache"] type: post lang: es --- # 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)](https://wpdirecto.com/objectcachepro)**, 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](https://wpdirecto.com/tag/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](https://wpdirecto.com/objectcachepro), su sitio gana **resiliencia**, **previsibilidad** y **tranquilidad** en los momentos críticos.