Instalación y Configuración de V

Instalación de software — paso a paso

Ahora que el servidor está preparado, procedamos con la instalación de Varnish Cache, así como Nginx (como servidor web backend) y Caddy (como frontend para terminación SSL y proxy).

1. Instalación de Nginx (servidor web backend)

Nginx escuchará en un puerto interno y entregará contenido a Varnish. Instalaremos la versión actual disponible a través de los repositorios de Ubuntu 24.04 LTS.

# Actualizamos la lista de paquetes
sudo apt update
# Instalamos Nginx (versión 1.25.x o posterior para 2026)
sudo apt install nginx -y
# Verificamos el estado de Nginx
sudo systemctl status nginx

Nginx debe estar activo (active (running)).

2. Instalación de Varnish Cache

Instalaremos Varnish Cache desde los repositorios oficiales de Ubuntu. Para 2026, se espera una versión estable de Varnish 7.x (por ejemplo, 7.4 o 7.5).

# Añadimos la clave GPG para el repositorio oficial de Varnish
sudo curl -s https://packagecloud.io/varnishcache/varnish7/gpgkey | sudo gpg --dearmor | sudo tee /usr/share/keyrings/varnishcache.gpg > /dev/null
# Añadimos el repositorio de Varnish Cache
echo "deb [signed-by=/usr/share/keyrings/varnishcache.gpg] https://packagecloud.io/varnishcache/varnish7/ubuntu/ $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/varnishcache.list
# Actualizamos la lista de paquetes para incluir el nuevo repositorio
sudo apt update
# Instalamos Varnish Cache (versión 7.4.x o posterior)
sudo apt install varnish -y
# Verificamos el estado de Varnish
sudo systemctl status varnish

Varnish también debe estar activo. Por defecto, puede estar configurado para escuchar en el puerto 6081 o 80. Cambiaremos esto en la siguiente sección.

3. Instalación de Caddy (terminador SSL y frontend)

Caddy es un servidor web moderno con HTTPS automático. Escuchará en los puertos 80 y 443, manejará SSL y reenviará las solicitudes a Varnish. Para 2026, Caddy 2.x será la versión estable principal.

# Instalamos las dependencias para Caddy
sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https
# Añadimos la clave GPG para el repositorio de Caddy
sudo curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
# Añadimos el repositorio de Caddy
sudo curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list
# Actualizamos la lista de paquetes
sudo apt update
# Instalamos Caddy (versión 2.x)
sudo apt install caddy -y
# Verificamos el estado de Caddy
sudo systemctl status caddy

Caddy también debe estar activo.

4. Apertura de puertos en el firewall para comunicación interna

Necesitaremos abrir puertos internos para la comunicación entre Caddy, Varnish y Nginx. Varnish escuchará en el puerto 8080 y Nginx en el 8081. Estos puertos no deben ser accesibles desde el exterior.

# Permitimos los puertos internos 8080 y 8081 solo para localhost (127.0.0.1)
sudo ufw allow in on lo to any port 8080
sudo ufw allow in on lo to any port 8081
# Verificamos que las reglas se hayan aplicado
sudo ufw status verbose

Ahora todos los componentes necesarios están instalados, y podemos proceder a su configuración.

Copias de seguridad y mantenimiento

Las copias de seguridad regulares y el mantenimiento oportuno son cruciales para la estabilidad y seguridad de su sitio web que funciona con Varnish Cache.

1. Qué respaldar

Para Varnish Cache y la infraestructura asociada, es necesario respaldar los siguientes elementos:

• Archivos de configuración de Varnish:
  • /etc/varnish/default.vcl (archivo VCL principal)
  • /etc/systemd/system/varnish.service.d/override.conf (configuración de Systemd)
• Archivos de configuración del servidor web (Nginx):
  • /etc/nginx/nginx.conf
  • /etc/nginx/sites-available/su_dominio.conf
  • /etc/nginx/sites-enabled/ (enlaces simbólicos)
• Archivos de configuración de Caddy:
  • /etc/caddy/Caddyfile
  • /etc/caddy/.env (si se usa)
  • /var/lib/caddy/.local/share/caddy/ (certificados Let's Encrypt, si no se usan plugins DNS)
• Archivos del sitio web: Todo el contenido de su sitio web (HTML, CSS, JS, imágenes, scripts PHP, etc.), generalmente ubicado en /var/www/su_dominio/html.
• Base de datos: Si su sitio utiliza una base de datos (MySQL, PostgreSQL), asegúrese de hacer un volcado de la misma.
• Configuraciones del sistema: /etc/ssh/sshd_config, /etc/ufw/, /etc/fail2ban/.

2. Script simple de copia de seguridad automática

Puede usar un script simple de bash en combinación con cron para crear archivos automáticamente. Para el almacenamiento, puede usar rsync para copiar a otro servidor o restic/borg para copias de seguridad deduplicadas y cifradas en un almacenamiento compatible con S3.

Ejemplo de un script simple para crear archivos (/usr/local/bin/backup_script.sh):

#!/bin/bash

# Configuración
BACKUP_DIR="/var/backups/webserver"
DATE=$(date +%Y-%m-%d_%H-%M-%S)
WEB_ROOT="/var/www/su_dominio/html"
NGINX_CONF="/etc/nginx"
VARNISH_CONF="/etc/varnish"
CADDY_CONF="/etc/caddy"
DB_NAME="su_base_de_datos" # Reemplace con el nombre de su BD
DB_USER="su_usuario_bd" # Reemplace con el usuario de la BD
DB_PASS="su_contraseña_bd" # Reemplace con la contraseña de la BD
MYSQL_CMD="/usr/bin/mysqldump" # O pg_dump para PostgreSQL

# Creamos el directorio para las copias de seguridad si no existe
mkdir -p $BACKUP_DIR

# 1. Copia de seguridad de archivos web
echo "Creando copia de seguridad de archivos web..."
tar -czf $BACKUP_DIR/web_files_$DATE.tar.gz $WEB_ROOT

# 2. Copia de seguridad de configuraciones de Nginx
echo "Creando copia de seguridad de configuraciones de Nginx..."
tar -czf $BACKUP_DIR/nginx_config_$DATE.tar.gz $NGINX_CONF

# 3. Copia de seguridad de configuraciones de Varnish
echo "Creando copia de seguridad de configuraciones de Varnish..."
tar -czf $BACKUP_DIR/varnish_config_$DATE.tar.gz $VARNISH_CONF /etc/systemd/system/varnish.service.d/override.conf

# 4. Copia de seguridad de configuraciones de Caddy
echo "Creando copia de seguridad de configuraciones de Caddy..."
tar -czf $BACKUP_DIR/caddy_config_$DATE.tar.gz $CADDY_CONF /var/lib/caddy/.local/share/caddy/

# 5. Copia de seguridad de la base de datos (ejemplo para MySQL)
if [ -n "$DB_NAME" ]; then
    echo "Creando copia de seguridad de la base de datos..."
    $MYSQL_CMD -u $DB_USER -p$DB_PASS $DB_NAME | gzip > $BACKUP_DIR/database_$DATE.sql.gz
fi

# Eliminando copias de seguridad antiguas (más de 7 días)
echo "Eliminando copias de seguridad antiguas..."
find $BACKUP_DIR -type f -name ".tar.gz" -o -name ".sql.gz" -mtime +7 -delete

echo "Copia de seguridad completada."

# Guarde el script
sudo nano /usr/local/bin/backup_script.sh
# Hágalo ejecutable
sudo chmod +x /usr/local/bin/backup_script.sh

Agregue una tarea a cron para su ejecución diaria (por ejemplo, a las 3:00 AM):

# Abrimos crontab
sudo crontab -e

Agregue la siguiente línea:

0 3   * /usr/local/bin/backup_script.sh > /dev/null 2>&1

3. Dónde almacenar las copias de seguridad

Nunca almacene las copias de seguridad en el mismo servidor que los datos originales. Esto es inútil en caso de fallo del disco o compromiso del servidor.

• Almacenamiento externo compatible con S3: Amazon S3, DigitalOcean Spaces, Backblaze B2. Esta es una opción económica y fiable. Use restic o borgbackup para el cifrado y la deduplicación.
• VPS separado: Un VPS pequeño y económico en otra ubicación, destinado exclusivamente al almacenamiento de copias de seguridad. Use rsync por SSH.
• Almacenamiento local en su máquina: Para proyectos pequeños, puede descargar periódicamente las copias de seguridad a su ordenador.

4. Actualizaciones: rolling vs maintenance window

Mantener el software actualizado es importante para la seguridad y el rendimiento.

• Actualizaciones de SO y paquetes (Ubuntu, Nginx, Caddy, Varnish):
  • Rolling updates: Para sistemas no críticos o en un entorno de prueba, se pueden configurar actualizaciones de seguridad automáticas. Sin embargo, para servidores de producción, se recomienda la actualización manual con pruebas previas.
  • Maintenance window (ventana de mantenimiento): Planifique ventanas de mantenimiento regulares (por ejemplo, una vez al mes) durante el tiempo de menor actividad. Antes de aplicar las actualizaciones, haga una copia de seguridad.
• Actualización de Varnish:
  • Las versiones principales de Varnish (por ejemplo, de 6.x a 7.x) pueden requerir la adaptación del archivo VCL debido a cambios en la sintaxis o la API. Lea atentamente el changelog.
  • Las actualizaciones menores (7.4.0 a 7.4.1) suelen ser retrocompatibles y seguras.

# Actualización del sistema
sudo apt update && sudo apt upgrade -y
# Reinicio de servicios, si fueron actualizados
sudo systemctl restart nginx caddy varnish

Siempre verifique la funcionalidad del sitio después de cualquier actualización.

Solución de problemas + Preguntas frecuentes

Esta sección recopila problemas típicos y preguntas frecuentes que pueden surgir al trabajar con Varnish Cache.

Error: Varnish no almacena contenido en caché (X-Cache: MISS)

Qué verificar: Asegúrese de que Varnish esté configurado correctamente y reciba las solicitudes. Verifique su archivo VCL (/etc/varnish/default.vcl) en busca de reglas que puedan provocar un salto de caché (return (pass) o return (pipe)). A menudo, la causa son los encabezados Set-Cookie, Cache-Control: private o solicitudes con un método diferente a GET/HEAD. Use sudo varnishlog para analizar las solicitudes y respuestas.

Cómo solucionarlo: Optimice el archivo VCL. Si el Set-Cookie es enviado por el backend, considere eliminarlo para los objetos en caché en vcl_fetch. Verifique que su backend (Nginx) no envíe encabezados que prohíban el almacenamiento en caché. Asegúrese de que no haya Cache-Control: no-cache o no-store para las páginas en caché.

Error: El sitio no está disponible o muestra un error 502 Bad Gateway

Qué verificar: Esto indica un problema con la conexión de Varnish al backend (Nginx) o de Caddy a Varnish. Verifique los registros de Caddy (sudo journalctl -u caddy --since "5 minutes ago"), Varnish (sudo varnishlog) y Nginx (sudo tail -f /var/log/nginx/error.log). Asegúrese de que todos los servicios (Caddy, Varnish, Nginx) estén en ejecución y escuchando en los puertos correctos (Caddy: 80/443, Varnish: 127.0.0.1:8080, Nginx: 127.0.0.1:8081). Verifique las reglas del firewall (UFW) para detectar el bloqueo de puertos internos.

Cómo solucionarlo: Reinicie los servicios en el orden correcto: primero Nginx, luego Varnish, luego Caddy. Asegúrese de que /etc/caddy/Caddyfile especifique la dirección correcta de Varnish (127.0.0.1:8080), y que /etc/varnish/default.vcl especifique la dirección correcta de Nginx (127.0.0.1:8081). Verifique override.conf para Varnish para asegurarse de que esté escuchando en el puerto 8080.

Error: Problemas con los certificados SSL (Caddy)

Qué verificar: Verifique los registros de Caddy. Si Caddy no puede obtener un certificado Let's Encrypt, esto podría deberse a errores en los registros DNS, al bloqueo del puerto 80/443 por el firewall o a una configuración incorrecta del desafío DNS (si se usa). Asegúrese de que su dominio apunte a la dirección IP del servidor.

Cómo solucionarlo: Asegúrese de que los puertos 80 y 443 estén abiertos en UFW. Verifique los registros A/AAAA de su dominio. Si usa el desafío DNS, asegúrese de que el token de API esté especificado correctamente y tenga los permisos necesarios. Deshabilite temporalmente el desafío DNS en Caddyfile e intente el desafío HTTP (asegúrese de que el puerto 80 esté abierto).

¿Qué configuración mínima de VPS es adecuada para Varnish Cache?

Para un sitio web pequeño con tráfico moderado, un VPS con 1 núcleo de CPU, 1-2 GB de RAM y 20-40 GB de disco NVMe/SSD será suficiente. Esto es suficiente para el funcionamiento de Varnish, el servidor web y el sistema operativo. Sin embargo, para obtener una mejora notable en el rendimiento y la capacidad de almacenar más contenido en la memoria caché, se recomiendan 2-4 GB de RAM.

¿Qué elegir — VPS o dedicado para esta tarea?

Para la mayoría de los proyectos medianos y grandes, un VPS será una excelente opción, ofreciendo un buen equilibrio entre rendimiento y costo. Un servidor dedicado solo es necesario en casos de carga muy alta (cientos de millones de solicitudes al mes), cuando se requiere almacenar cientos de gigabytes de datos en la memoria caché, o cuando existen requisitos estrictos de aislamiento de hardware y equipo específico. Comience con un VPS y escale a un dedicado si surge una necesidad real.

¿Por qué Varnish no almacena en caché las páginas para usuarios autenticados?

Qué verificar: Por defecto, Varnish evita almacenar en caché páginas que contienen cookies (Cookie en la solicitud, Set-Cookie en la respuesta) para evitar mostrar contenido personalizado a otros usuarios. Este es un comportamiento estándar, orientado a la seguridad y la corrección.

Cómo solucionarlo: Si necesita almacenar en caché páginas con cookies, debe eliminar explícitamente el encabezado Cookie de la solicitud en vcl_recv para URL o tipos de contenido específicos, así como Set-Cookie de la respuesta en vcl_fetch. Esto requiere una configuración muy cuidadosa de VCL para no romper la funcionalidad del sitio (por ejemplo, inicio de sesión, carrito de compras). Considere usar Edge Side Includes (ESI) para partes dinámicas de las páginas.

¿Cómo limpiar la caché de Varnish?

Qué verificar: Varnish ofrece varias formas de limpiar la caché. La más sencilla es reiniciar el servicio, pero esto borrará toda la caché. Métodos más granulares incluyen el uso de solicitudes HTTP PURGE o BAN.

Cómo solucionarlo:

• Reinicio de Varnish: sudo systemctl restart varnish (borra toda la caché).
• PURGE (limpieza de una URL específica): Agregue reglas en VCL para manejar el método PURGE. Por ejemplo, en vcl_recv:

  
      if (req.method == "PURGE") {
          if (!client.ip ~ "127.0.0.1") { # Permitir PURGE solo desde localhost
              return (synth(403, "Forbidden"));
          }
          return (hash);
      }
      sub vcl_hit {
          if (req.method == "PURGE") {
              return (synth(200, "Purged"));
          }
      }
      sub vcl_miss {
          if (req.method == "PURGE") {
              return (synth(200, "Purged"));
          }
      }
                  

  Después de esto, puede usar: curl -X PURGE http://127.0.0.1:8080/path/to/page.
• BAN (limpieza por patrón): También requiere configuración en VCL. Permite eliminar de la caché todos los objetos que coincidan con una expresión regular (por ejemplo, todas las páginas que comienzan con /blog/).