Qué es Varnish Cache: instalación y configuración básica de Varnish Cache Server

Entorno de prueba Familia RHELAlmaLinux 9.8Cuenta rootVerificado el 2026-10-16

Varnish Cache es una caché de proxy inverso que se coloca delante del servidor web, guarda las respuestas HTTP en memoria y responde a las mismas solicitudes sin pasar por el servidor de origen. Al poner Varnish 6.6.2 delante de WordPress en un servidor AlmaLinux 9.8, las páginas no se almacenaban en caché por max-age=0, y lo solucionamos fijando un tiempo de almacenamiento en VCL.

Qué solicitudes se almacenan en caché y durante cuánto tiempo se guardan se escribe en un archivo VCL (Varnish Configuration Language).

1️⃣ Concepto de Varnish Cache: caché de proxy inverso

En cada solicitud, Varnish comprueba primero si hay una respuesta guardada. Si responde con una respuesta guardada, es un acierto de caché (HIT); si tiene que obtenerla del servidor de origen (backend), es un fallo de caché (MISS). La respuesta obtenida en un fallo se guarda durante su tiempo de almacenamiento y se usa en las siguientes solicitudes.

Varnish de código abierto no admite TLS, así que no puede recibir solicitudes HTTPS directamente. En el puerto 443, Nginx o HAProxy procesa el TLS y luego pasa la solicitud a Varnish.

El proyecto de código abierto Varnish Cache cambió su nombre a Vinyl Cache a partir de la versión 9.0, publicada en marzo de 2026. El nombre Varnish Cache lo sigue usando la versión que Varnish Software distribuye con funciones TLS añadidas.

2️⃣ Instalar Varnish Cache Server

En AlmaLinux 9 lo instalas con el paquete varnish del repositorio predeterminado (AppStream), y la versión de este paquete es Varnish 6.6.2, anterior al cambio de nombre.

dnf -y install varnish

Cuando termine la instalación, comprueba la versión con [varnishd -V].

varnishd -V
varnishd (varnish-6.6.2 revision 17c51b08e037fc8533fb3687a042a867235fc72f)
Copyright (c) 2006 Verdens Gang AS
Copyright (c) 2006-2020 Varnish Software

Los paquetes de la familia RHEL mantienen la versión 6.6.2, cuyo soporte por parte del proyecto ya terminó, y la distribuyen añadiendo solo correcciones de seguridad. El paquete 6.6.2-7, publicado en junio de 2025, incluye la corrección de una vulnerabilidad de HTTP request smuggling (CVE-2025-47905).

Al instalarlo se crean también [/etc/varnish/default.vcl] y [/usr/lib/systemd/system/varnish.service].

grep ExecStart= /usr/lib/systemd/system/varnish.service
ExecStart=/usr/sbin/varnishd -a :6081 -f /etc/varnish/default.vcl -s malloc,256m

[-a :6081] indica el puerto que recibe las solicitudes, y [-s malloc,256m], los 256MB de memoria que se usan como espacio de almacenamiento de la caché.

3️⃣ Configuración básica: backend y puerto

El archivo VCL predeterminado, [/etc/varnish/default.vcl], ya tiene configurado como backend el puerto 8080 del mismo servidor.

vcl 4.1;

backend default {
    .host = "127.0.0.1";
    .port = "8080";
}

En Apache, cambia el valor de [Listen] en [httpd.conf] a 8080 para que reciba las solicitudes que le pasa Varnish.

# /etc/httpd/conf/httpd.conf
Listen 8080

En los sitios que usan HTTPS, deja Varnish en el puerto 6081 y conecta Nginx, que procesa el TLS, para que pase las solicitudes a Varnish.

Que Varnish reciba las solicitudes directamente en el puerto 80 es una configuración adecuada para sitios que solo usan HTTP. En ese caso, crea una copia del archivo de servicio como indica la documentación de instalación de Varnish Software y cambia 6081 por 80 en la línea [ExecStart].

systemctl edit --full varnish

La copia que guardas en el editor se crea en [/etc/systemd/system/varnish.service], y el puerto cambiado se mantiene aunque actualices el paquete.

systemctl enable --now varnish

Elijas la configuración que elijas, al final registra el inicio automático en el arranque con el comando enable y la opción now, que además pone Varnish en marcha al momento.

4️⃣ Comprobar el funcionamiento: cabeceras X-Varnish y Age

Después de iniciar Varnish, comprueba con las cabeceras de respuesta si las páginas de WordPress salen realmente de la caché. La solicitud se envía al puerto 6081 de Varnish sin pasar por Nginx, así que el dominio y si es HTTPS se indican con las cabeceras [Host] y [X-Forwarded-Proto].

curl -sI -H "Host: example.com" -H "X-Forwarded-Proto: https" http://127.0.0.1:6081/ | grep -iE "^(HTTP|cache-control|x-varnish|age|via)"
HTTP/1.1 200 OK
Cache-Control: max-age=0
X-Varnish: 1001
Age: 0
Via: 1.1 varnish (Varnish/6.6)

[X-Varnish] es el número que Varnish asigna a la solicitud, y [Via: 1.1 varnish] indica que la respuesta pasó por Varnish. [Age] es el tiempo (en segundos) transcurrido desde que la respuesta se guardó en la caché.

Al enviar la misma solicitud otra vez 3 segundos después, [X-Varnish] seguía teniendo un solo número y [Age] era 0, así que de nuevo respondió el servidor de origen. Una regla que el plugin de caché añadió a [.htaccess] agrega [max-age=0] al HTML, y por eso la configuración predeterminada de Varnish calculó el tiempo de almacenamiento como 0 segundos.

Las solicitudes con cookies tampoco pasan por la caché con la configuración predeterminada. Lo mismo ocurre con las cookies de las herramientas de analítica, así que todas las solicitudes de visitantes que tienen esas cookies van al servidor de origen.

El VCL de abajo envía al servidor de origen las solicitudes de inicio de sesión y de administración y las que no son GET ni HEAD, y almacena en caché el resto después de quitarles las cookies. Las respuestas con un tiempo de almacenamiento de 0 segundos que no crean cookies se guardan 10 minutos, y las que indican que no se guarden, como [no-cache], no se guardan.

vcl 4.1;

backend default {
    .host = "127.0.0.1";
    .port = "8080";
}

sub vcl_recv {
    if (req.method != "GET" && req.method != "HEAD") {
        return (pass);
    }
    if (req.url ~ "^/(wp-admin|wp-login\.php)" || req.http.Cookie ~ "wordpress_logged_in_|wp-postpass_|comment_author_") {
        return (pass);
    }
    unset req.http.Cookie;
}

sub vcl_backend_response {
    if (beresp.ttl <= 0s && !beresp.http.Set-Cookie) {
        set beresp.ttl = 10m;
    }
}

Cuando cambies el archivo VCL, vuelve a cargarlo con [systemctl reload varnish]. Abajo está la segunda de las dos respuestas obtenidas al enviar dos veces la misma solicitud a Varnish con este VCL aplicado.

curl -sI -H "Host: example.com" -H "X-Forwarded-Proto: https" http://127.0.0.1:6081/ | grep -iE "^(HTTP|cache-control|x-varnish|age|via)"
HTTP/1.1 200 OK
Cache-Control: max-age=0
X-Varnish: 1004 1002
Age: 3
Via: 1.1 varnish (Varnish/6.6)

La segunda solicitud, enviada 3 segundos después de aplicar el VCL, tenía dos números en [X-Varnish] y [Age] era 3. Dos números significan que respondió la caché, y el segundo número es el de la solicitud que obtuvo la página del servidor de origen y la guardó.

La solicitud con la cookie de inicio de sesión tuvo un solo número y respondió el servidor de origen, mientras que la que solo llevaba la cookie de la herramienta de analítica recibió respuesta de la caché.

🔢 FAQ & contenido recomendado

Si fijas el tiempo de almacenamiento en 10 minutos en VCL, durante esos 10 minutos se responde con la página anterior a la edición guardada en la caché. Para vaciar la caché en cuanto guardas una entrada, necesitas una regla VCL que procese las solicitudes PURGE y un plugin como Proxy Cache Purge. En VCL, limita las solicitudes PURGE para aceptar solo las que se envían desde el mismo servidor.

Si el servidor web envía directamente, sin PHP, los archivos HTML que crea el plugin de caché, Varnish acaba haciendo el mismo trabajo otra vez. Si las páginas en caché también pasan por PHP para responder, Varnish responde delante y reduce la ejecución de PHP.

Un sitio puede usar Varnish aunque no se vea la cabecera, porque los administradores del servidor a veces cambian el nombre de las cabeceras de respuesta o las eliminan. En un servidor de Cloudways con Varnish activado, las respuestas de WordPress tenían las cabeceras [x-cache: HIT] y [age] en lugar de [X-Varnish].

ℹ️ Aviso de afiliados
El contenido de este sitio incluye enlaces de afiliado. Cuando un visitante compra un producto o servicio a través de uno de ellos, el sitio recibe una comisión del vendedor. El importe que paga el comprador(baja durante las promociones ↓)no aumenta. Los precios, descuentos y existencias publicados corresponden al momento de redacción y pueden variar, así que confírmalos con el vendedor antes de comprar. Los productos se eligen y evalúan con criterios propios, y las comisiones no influyen en el orden ni en el contenido de las reseñas.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Demuestra que eres humano: 6   +   6   =