Configurar Varnish Cache: guía completa para alto tráfico

configurar Varnish Cache

📅 Publicado el 23 de septiembre, 2026 · Por Equipo RedServicio

Si tu web recibe un volumen alto de visitas, configurar Varnish Cache es probablemente una de las decisiones más rentables que puedes tomar. ¿Qué es exactamente? Un acelerador HTTP de código abierto que se coloca entre tus visitantes y el servidor web, guardando en memoria RAM copias de las páginas que más se piden. La diferencia se nota de verdad: tiempos de respuesta que pasan de cientos de milisegundos a menos de 10 ms, y un backend que por fin respira. En esta guía verás qué es, qué necesitas y cómo instalarlo sobre Apache o Nginx, paso a paso.

¿Qué es Varnish Cache y por qué tu sitio de alto tráfico lo necesita?

Varnish funciona como un proxy inverso con caché. Todas las peticiones HTTP pasan primero por él, antes de llegar a Apache o Nginx. Si la respuesta ya está en memoria, la sirve al instante, sin tocar el servidor de origen. Esta técnica —el llamado content caching— es la misma que usan Wikipedia o The Guardian, por poner dos ejemplos conocidos.

Para un sitio con tráfico elevado, las ventajas saltan a la vista:

  • Velocidad extrema: al servir desde RAM, las respuestas llegan a ser hasta 300 veces más rápidas que las generadas dinámicamente por PHP o una base de datos.
  • Menor consumo de recursos: un solo servidor con Varnish puede atender decenas de miles de peticiones por segundo. Tu infraestructura se descarga casi por completo.
  • Mejor SEO: Google tiene en cuenta la velocidad de carga al posicionar, sobre todo en móvil.
  • Resiliencia ante picos: si tu producto sale en medios o lanzas una campaña, Varnish absorbe el golpe sin que la web se caiga.

Brilla especialmente en WordPress, WooCommerce, Magento y cualquier CMS que genere páginas al vuelo. Eso sí, hay un matiz importante: el contenido de usuarios autenticados, los carritos de compra o las zonas de administrador deben configurarse para que no se cacheen (de eso trataremos en la segunda parte de la serie).

Requisitos previos antes de configurar Varnish Cache en tu servidor

Antes de instalar nada, revisa que cumples lo básico:

  1. Servidor con acceso root (SSH): necesitas un VPS, servidor dedicado o cloud. El hosting compartido no deja instalar Varnish; si tu web ha crecido, quizá sea buen momento para migrar a un plan con recursos dedicados como los de RedServicio.
  2. Sistema operativo compatible: Debian 11/12 o Ubuntu 20.04/22.04 son lo más habitual, aunque también existe para CentOS/RHEL y AlmaLinux.
  3. Mínimo 2 GB de RAM: Varnish trabaja en memoria, así que a más RAM, más caché disponible. Para tráfico muy alto, lo razonable son 4-8 GB.
  4. Apache o Nginx funcionando: Varnish se coloca delante, no los sustituye.
  5. Dominio con SSL: Varnish no gestiona HTTPS de forma nativa, así que el manejo de certificados (con Nginx como terminador SSL) lo dejamos para la tercera parte de la guía.

Un consejo práctico que no deberías saltarte: antes de tocar producción, replica tu entorno en un servidor de pruebas o en un snapshot. Un error en la configuración de la caché puede acabar mostrando contenido privado a visitantes anónimos. Y eso, creedme, no es algo que quieras descubrir por las malas.

Instalación de Varnish paso a paso (Apache y Nginx)

Instalaremos la última versión estable (la 7.x) desde el repositorio oficial, que da mejor soporte que la que traen las distribuciones.

Paso 1: Preparar el sistema

Actualiza paquetes e instala las dependencias previas:

sudo apt update && sudo apt upgrade -y
sudo apt install apt-transport-https curl gnupg -y

Paso 2: Añadir el repositorio oficial de Varnish

En Ubuntu/Debian, ejecuta esto:

curl -fsSL https://packagecloud.io/varnishcache/varnish70/gpgkey | sudo gpg –dearmor -o /usr/share/keyrings/varnish-archive-keyring.gpg
echo «deb [signed-by=/usr/share/keyrings/varnish-archive-keyring.gpg] https://packagecloud.io/varnishcache/varnish70/ubuntu focal main» | sudo tee /etc/apt/sources.list.d/varnishcache.list
sudo apt update

Paso 3: Instalar Varnish

Con el repositorio listo, la instalación es directa:

sudo apt install varnish -y
varnishd -V

El segundo comando debe devolverte la versión instalada. Si aparece, todo va bien.

Paso 4: Cambiar el puerto de escucha a 80

Por defecto Varnish escucha en el 6081, pero tiene que recibir el tráfico web directamente. Edita el servicio con sudo systemctl edit varnish y ajusta:

[Service]
ExecStart=
ExecStart=/usr/sbin/varnishd -a :80 -a localhost:8443,PROXY -p feature=+http2 -s malloc,1g

Paso 5: Mover tu servidor web al puerto 8080

El backend debe dejar libre el puerto 80. Con Apache, edita /etc/apache2/ports.conf y cambia Listen 80 por Listen 8080, además de los VirtualHosts en sites-available. Con Nginx, modifica en cada bloque server la directiva listen 80; por listen 8080;. Después, reinicia ambos servicios:

sudo systemctl restart apache2
sudo systemctl restart varnish

Comprueba que funciona con curl -I http://tudominio.com. Si en la respuesta aparece la cabecera Via: 1.1 varnish, la instalación ha ido bien. En la siguiente parte configuraremos el archivo default.vcl para definir exactamente qué contenido se cachea y cuánto tiempo se conserva.

Configuración del archivo VCL: reglas de caché y ejemplos prácticos

Todo en Varnish gira alrededor de un fichero: default.vcl, que casi siempre encontrarás en /etc/varnish/. Ahí se decide, usando el lenguaje VCL, qué peticiones se cachean, cuánto tiempo viven los objetos y cómo hablan entre sí Varnish y el backend (Apache o Nginx, normalmente a la escucha en el puerto 8080).

Una configuración básica que funciona tendría tres piezas:

  1. Definir el backend: en vcl 4.1, declara backend default { .host = «127.0.0.1»; .port = «8080»; } para señalar dónde vive tu servidor web real.
  2. Controlar la caché en vcl_recv: excluye peticiones con cookies de sesión y limita el caché a métodos GET y HEAD.
  3. Ajustar el TTL en vcl_backend_response: define cuánto tiempo se servirá cada objeto desde la caché.

Un ejemplo práctico de reglas en vcl_recv:

Con if (req.method != «GET» && req.method != «HEAD») { return (pass); } evitas cachear formularios y peticiones POST. Y con if (req.url ~ «\.(png|jpg|jpeg|css|js|woff2)(\?.*)?$») { return (hash); } te aseguras de que los assets estáticos entren siempre en caché.

En vcl_backend_response puedes establecer TTLs diferenciados:

  • if (bereq.url ~ «\.(css|js|png|jpg|jpeg|gif|ico|svg|woff2)$») { set beresp.ttl = 7d; }
  • if (bereq.url ~ «\.html$») { set beresp.ttl = 1h; }
  • Para el resto, un TTL de 5 minutos con set beresp.ttl = 5m; es un punto de partida razonable.

No olvides añadir set beresp.http.Cache-Tags o similar si tu CMS usa purga por etiquetas. Y antes de recargar el servicio, verifica siempre la sintaxis con varnishd -C -f /etc/varnish/default.vcl; un error de sintaxis dejaría Varnish sin arrancar, y no es la llamada que quieres hacer a las tres de la madrugada.

Cómo excluir contenido dinámico y probar que Varnish funciona

El fallo más común al configurar Varnish Cache es cachear contenido que debería ser dinámico: carritos de compra, áreas de usuario, panel de administración, páginas con tokens CSRF. La regla de oro cabe en una línea. Si la respuesta depende de cookies o del usuario, pásalo (pass).

En WordPress, por ejemplo, excluye el login y la administración con:

if (req.url ~ «wp-admin|wp-login») { return (pass); } y elimina cookies de sesión de los visitantes anónimos con unset req.http.Cookie; cuando no existan cookies de sesión activas. En WooCommerce, añade también las rutas de carrito (/carrito|/finalizar-compra|/mi-cuenta) a la lista de exclusiones.

Si tu aplicación usa cookies propias (PHPSESSID, por ejemplo), elimínalas en el backend con unset beresp.http.Set-Cookie;, pero solo cuando tengas la certeza de que el contenido es público.

¿Y cómo compruebas que todo funciona? Tienes varias herramientas:

  • varnishlog: muestra en tiempo real las peticiones que atraviesan Varnish. Útil para ver si una URL hace HIT o MISS.
  • varnishstat: consulta los contadores cache_hit y cache_miss; un ratio de acierto superior al 80% indica que la configuración va bien encaminada.
  • curl -I: lanza curl -I http://tudominio.com dos veces; la primera debe mostrar X-Varnish con un valor y Age: 0, la segunda debería incrementar Age y marcar HIT.

Consejo: si tras los cambios ves siempre MISS, revisa que el backend no esté enviando cabeceras Cache-Control: no-cache o Set-Cookie. Varnish las respeta por defecto y descarta el objeto de la caché, con toda su lógica.

Conclusión: potencia tu hosting con Varnish y soporte especializado

Configurar Varnish Cache como es debido puede multiplicar por diez la velocidad de tu web bajo tráfico alto, reduciendo drásticamente la carga del backend y mejorando el posicionamiento SEO gracias a tiempos de respuesta inferiores a 100 milisegundos. La clave está en una VCL bien ajustada: TTLs coherentes, exclusión cuidadosa del contenido dinámico y monitorización constante con varnishstat.

No te olvides de la purga selectiva. Cuando publiques contenido nuevo, ejecuta varnishadm «ban req.url ~ /articulo» o integra la purga automática en tu CMS; de lo contrario, tus visitantes verán versiones obsoletas de tus páginas.

En RedServicio.net ponemos a tu disposición planes de hosting web optimizados para alto tráfico, con soporte técnico 24/7 listo para ayudarte a desplegar y ajustar Varnish Cache en tu servidor, revisar tus reglas VCL o resolver cualquier incidencia en minutos. Si tu web crece, tu infraestructura debería crecer con ella. Confía en un equipo especializado y dedícate a lo que de verdad importa: tu proyecto.

📝

Equipo RedServicio

Artículos escritos y revisados por nuestro equipo técnico especializado en hosting e infraestructura web en España.

¿Listo para un hosting de verdad?

Servidores en España · Soporte 24/7 en español · Migración gratuita

Ver Planes desde 3,95€/mes →

Te puede interesar:

Página Gratis — Crea tu web gratis

Clisec — Seguridad informática

Scroll al inicio