🎨 Sysprovider Code
Sysprovider LogoWiki
🇪🇸Hosting español para ecommerce

Implementación de Caché Distribuida con Redis y Varnish para WordPress

Actualizado el 13 de mayo de 2026

Cuando un sitio WordPress empieza a recibir tráfico significativo, el servidor web típico (Apache o Nginx con PHP-FPM) se convierte en el cuello de botella. Cada petición de un visitante no autenticado desencadena la ejecución de PHP y múltiples consultas a la base de datos MySQL/MariaDB. La solución para escalar no es simplemente lanzar más hardware, sino implementar una estrategia de caché distribuida que separe la lógica dinámica del contenido estático.

En este artículo, exploraremos cómo implementar una arquitectura de caché robusta para WordPress combinando Varnish como proxy de caché inverso y Redis como almacén de objetos y sesiones. Esta combinación permite reducir la carga del servidor en un 90-95%, mejorando drásticamente los tiempos de respuesta.

¿Por qué una Caché Distribuida y no una simple caché de página?

Muchos plugins de caché para WordPress (como W3 Total Cache o WP Super Cache) generan archivos HTML estáticos en el disco del servidor. Esto funciona, pero tiene limitaciones: no escala horizontalmente, consume espacio en disco y no es eficiente para sitios con contenido dinámico (carritos de compra, comentarios de usuarios, etc.).

La caché distribuida resuelve estos problemas:

  • Redis actúa como un almacén de datos en memoria (RAM) ultra rápido. Almacena objetos de WordPress (consultas SQL, opciones, fragmentos de páginas) y sesiones de usuario. Al estar en memoria, es mucho más rápido que el disco.
  • Varnish se sitúa delante del servidor web. Almacena respuestas HTTP completas (páginas HTML, CSS, JS) en su propia memoria cache. Si un usuario solicita una página que Varnish tiene cacheada, la sirve directamente sin molestar a Apache/Nginx ni a PHP.

La clave está en la distribución. Redis puede ejecutarse en un servidor separado (o en un clúster) y Varnish en otro. Esto permite que tu infraestructura crezca de forma independiente: más servidores web, más caché, más base de datos.

Arquitectura Propuesta: Varnish + Redis + WordPress

El flujo de las peticiones será el siguiente:

  1. El usuario llega a Varnish (puerto 80/443).
  2. Varnish verifica si tiene la página en su caché.
  3. Si es un HIT (cache hit), Varnish devuelve la respuesta inmediatamente.
  4. Si es un MISS (cache miss), Varnish pasa la petición al servidor web (Apache/Nginx en el puerto 8080).
  5. El servidor web ejecuta WordPress. WordPress utiliza Redis como backend de caché de objetos (a través de un plugin como Redis Object Cache).
  6. WordPress genera la página y la devuelve a Varnish.
  7. Varnish almacena una copia de la página (según las reglas) y la sirve al usuario.

Esta arquitectura reduce drásticamente la cantidad de veces que PHP y MySQL tienen que trabajar.

Paso 1: Instalación y Configuración de Redis

Redis es el pilar de la caché de objetos. Es ligero y se instala en minutos.

Instalación en Ubuntu/Debian

sudo apt update
sudo apt install redis-server -y

Configuración básica de Redis

Edita el archivo de configuración (/etc/redis/redis.conf):

sudo nano /etc/redis/redis.conf

Realiza estos cambios clave:

  • Persistencia (opcional pero recomendada): Para evitar perder la caché al reiniciar, activa RDB. 
    save 900 1
save 300 10
save 60 10000
  • Seguridad: Establece una contraseña fuerte si Redis está expuesto a la red (aunque idealmente debería estar en localhost o en una VLAN privada). 
    requirepass TuContraseñaSuperSegura
  • Memoria máxima: Define un límite para que Redis no consuma toda la RAM del servidor. 
    maxmemory 512mb
maxmemory-policy allkeys-lru

    allkeys-lru es una política de desalojo que elimina las claves menos usadas cuando se alcanza el límite de memoria.

Reinicia Redis:

sudo systemctl restart redis-server
sudo systemctl enable redis-server

Instalación del Plugin Redis Object Cache en WordPress

Desde el panel de administración de WordPress, instala y activa el plugin Redis Object Cache (de Till Krüss). Luego, ve a Ajustes > Redis y haz clic en Enable Object Cache. El plugin se conectará automáticamente a Redis si está en localhost y puerto 6379. Si usas contraseña o un host remoto, configura las constantes en wp-config.php:

define('WP_REDIS_HOST', '127.0.0.1');
define('WP_REDIS_PORT', 6379);
define('WP_REDIS_PASSWORD', 'TuContraseñaSuperSegura');
define('WP_REDIS_DATABASE', 0); // Opcional, por defecto 0

Paso 2: Instalación y Configuración de Varnish

Varnish es un proxy de caché HTTP increíblemente rápido. Se sienta delante de tu servidor web.

Instalación

sudo apt install varnish -y

Configuración del Puerto de Escucha

Por defecto, Varnish escucha en el puerto 6081. Para que actúe como proxy público, debe escuchar en el puerto 80 (HTTP) o 443 (HTTPS, con un proxy SSL como Hitch o Nginx). Editamos la configuración del servicio:

sudo nano /lib/systemd/system/varnish.service

Busca la línea ExecStart y cambia el puerto:

ExecStart=/usr/sbin/varnishd -a :80 -f /etc/varnish/default.vcl -s malloc,1G

-s malloc,1G asigna 1GB de RAM para la caché de Varnish. Ajusta según la memoria disponible.

Recarga systemd y reinicia Varnish:

sudo systemctl daemon-reload
sudo systemctl restart varnish

Configuración del Backend (Apache/Nginx)

Ahora, tu servidor web (Apache o Nginx) debe escuchar en un puerto diferente al 80, por ejemplo el 8080. En Apache, edita /etc/apache2/ports.conf y cambia Listen 80 por Listen 8080. Luego, en los VirtualHost, cambia el puerto. En Nginx, edita el bloque server y cambia listen 80; por listen 8080;.

Reinicia el servidor web:

sudo systemctl restart apache2  # o nginx

Creación de la Política de Caché (default.vcl)

Este es el archivo más importante. Define qué páginas cachear, por cuánto tiempo y cómo purgar la caché. Crea o edita /etc/varnish/default.vcl:

vcl 4.1;

# Backend: Apache/Nginx corriendo en el puerto 8080
backend default {
    .host = "127.0.0.1";
    .port = "8080";
}

# ACL para purgar la caché (solo desde localhost o IPs de confianza)
acl purgers {
    "127.0.0.1";
    "localhost";
    # "192.168.1.0/24"; # Si tienes otros servidores
}

sub vcl_recv {
    # Manejar peticiones de purga (BAN)
    if (req.method == "BAN") {
        if (!client.ip ~ purgers) {
            return (synth(405, "Not allowed"));
        }
        ban("req.url ~ " + req.url + " && req.http.host == " + req.http.host);
        return (synth(200, "Ban added"));
    }

    # No cachear peticiones POST, PUT, DELETE
    if (req.method != "GET" && req.method != "HEAD") {
        return (pass);
    }

    # No cachear peticiones de administración de WordPress
    if (req.url ~ "^/wp-(login|admin)" || req.url ~ "preview=true") {
        return (pass);
    }

    # No cachear si hay cookies de usuario logueado o comentarios
    if (req.http.cookie) {
        if (req.http.cookie ~ "wordpress_logged_in_" || req.http.cookie ~ "comment_author_") {
            return (pass);
        }
        # Eliminar cookies que no son de WordPress para mejorar el hit rate
        if (req.http.cookie ~ "wordpress_") {
            return (hash);
        }
        # Si hay otras cookies, no cachear
        return (pass);
    }

    # Eliminar cookies de Google Analytics, etc. (mejora el cacheo)
    if (req.http.cookie) {
        set req.http.cookie = regsuball(req.http.cookie, "(^|;\s*)(_ga|_gid|_gat)=[^;]*", "");
        set req.http.cookie = regsuball(req.http.cookie, "^;\s*", "");
        if (req.http.cookie == "") {
            unset req.http.cookie;
        }
    }

    # Cachear páginas de error (5xx) por poco tiempo
    if (req.method == "GET" && req.http.cookie == "") {
        return (hash);
    }

    return (hash);
}

sub vcl_backend_response {
    # No cachear si el backend devuelve errores
    if (beresp.status >= 500) {
        set beresp.ttl = 0s;
        return (deliver);
    }

    # Cachear páginas estáticas por mucho tiempo (CSS, JS, imágenes)
    if (bereq.url ~ "\.(css|js|png|gif|jpg|jpeg|ico|svg|webp)$") {
        unset beresp.http.set-cookie;
        set beresp.ttl = 24h;
        return (deliver);
    }

    # Cachear páginas HTML por 1 hora (ajusta según tu sitio)
    if (bereq.url ~ "\.html$" || bereq.url == "/") {
        set beresp.ttl = 1h;
        return (deliver);
    }

    # Por defecto, cachear 5 minutos para contenido dinámico
    set beresp.ttl = 5m;
    return (deliver);
}

sub vcl_deliver {
    # Añadir cabecera para depuración (X-Cache: HIT o MISS)
    if (obj.hits > 0) {
        set resp.http.X-Cache = "HIT";
    } else {
        set resp.http.X-Cache = "MISS";
    }
}

[WARNING] Esta configuración es básica. Para sitios WooCommerce o con miembros, necesitarás reglas más complejas para evitar cachear carritos o contenido privado.

Reinicia Varnish para aplicar los cambios:

sudo systemctl restart varnish

Paso 3: Integración y Ajustes Finos

Purgar la Caché Automáticamente

Cuando publicas un nuevo artículo o modificas uno, Varnish debe purgar la caché de esa URL. El plugin Varnish HTTP Purge (de Michael Keck) se encarga de esto. Al activarlo, cada vez que guardas un post, envía una petición BAN a Varnish para invalidar la caché.

Configurar el TTL (Time To Live) en WordPress

Para que Varnish sepa cuánto tiempo cachear, podemos añadir cabeceras Cache-Control desde WordPress. Añade esto al functions.php de tu tema (o mejor, en un plugin de funcionalidades):

// Forzar cabeceras de caché para páginas públicas
add_action('template_redirect', function() {
    if (is_user_logged_in() || is_admin()) {
        return;
    }
    header('Cache-Control: public, max-age=3600'); // 1 hora
    header('X-Cache-TTL: 3600');
});

Monitorización y Depuración

Para ver si Varnish está funcionando, revisa las cabeceras HTTP de respuesta:

curl -I https://tudominio.com

Deberías ver:

X-Cache: HIT
X-Cache: MISS

También puedes ver las estadísticas de Varnish:

varnishstat

Paso 4: Escalando la Caché Distribuida

Una vez que tienes Redis y Varnish funcionando, puedes escalar horizontalmente:

  • Redis en clúster: Para sitios con mucho tráfico, puedes configurar un clúster de Redis con replicación (maestro-esclavo). El plugin Redis Object Cache soporta conexiones a clústeres.
  • Múltiples instancias de Varnish: Puedes poner un balanceador de carga (HAProxy, Nginx) delante de varios servidores Varnish. Cada Varnish tendrá su propia memoria caché, pero puedes sincronizarlas usando Varnish Cache (VCL) con sharding o un backend compartido como Apache Traffic Server.
  • Separar Redis por funcionalidad: Usa una instancia de Redis para caché de objetos y otra para sesiones de PHP (usando session.save_handler = redis en php.ini).

Beneficios Reales en el Rendimiento del Servidor

¿Qué ganamos con todo esto?

  • Reducción de la carga en la CPU: Varnish sirve páginas sin ejecutar PHP. Redis responde consultas sin tocar MySQL. El servidor web respira.
  • Disminución de la latencia: Un HIT en Varnish se sirve en milisegundos. Un MISS puede tardar 200-500ms si el backend está optimizado.
  • Mayor capacidad de usuarios concurrentes: Un solo servidor Varnish puede manejar miles de peticiones por segundo. Tu servidor web solo procesa las peticiones que realmente necesitan ser dinámicas.
  • Mejor experiencia de usuario: Las páginas se cargan más rápido, lo que mejora el Core Web Vitals y el SEO.

[TIP] Si usas un CDN como Cloudflare, puedes combinarlo con Varnish. Configura Cloudflare para que pase el tráfico a Varnish (tu origen) y Varnish a tu servidor web. Así tienes una caché en el edge (CDN) y otra en el origen (Varnish).

Posibles Problemas y Soluciones

  • Caché de páginas de error: Si tu sitio genera un error 500, Varnish podría cachearlo. Asegúrate de tener la regla if (beresp.status >= 500) en vcl_backend_response.
  • Cookies de sesión: Si usas un plugin de membresía, asegúrate de que Varnish no cachee páginas con cookies de sesión. La regla req.http.cookie ~ "wordpress_logged_in_" es crítica.
  • Purga incompleta: Si al publicar un artículo no se purga la página principal (home), puede que el plugin Varnish HTTP Purge no envíe la petición correctamente. Prueba a purgar manualmente con curl -X BAN https://tudominio.com/.

Conclusión

La implementación de una caché distribuida con Redis y Varnish transforma un WordPress lento y propenso a caídas en una máquina de servir contenido a alta velocidad. Redis se encarga de la lógica interna (consultas, objetos, sesiones), mientras que Varnish se ocupa de la entrega de páginas completas. Juntos, reducen drásticamente la carga del servidor y mejoran la experiencia del usuario.

No es una configuración trivial, pero los beneficios en rendimiento del servidor y escalabilidad son inmensos. Empieza por instalar Redis y el plugin de caché de objetos, luego añade Varnish delante. Monitorea, ajusta los TTL y verás cómo tu sitio web vuela.

¿Necesitas ayuda?Son dos de nuestros técnicos, Agustín y Mikel, y están disponibles para resolver cualquier problema.

Hablar con ellos ahora
Agustín y Mikel