Caché Básico con Nginx: Mejora los Tiempos de Respuesta

El caché básico con Nginx puede mejorar los tiempos de respuesta guardando una copia de las respuestas del servidor ascendente y sirviéndolas de nuevo sin preguntar a la aplicación cada vez. Cuando se usa con cuidado, el caché reduce la carga del backend, suaviza los picos de tráfico y hace que las solicitudes repetidas se sientan más rápidas.

El caché no es solo para sitios grandes. Incluso una aplicación pequeña puede beneficiarse cuando las páginas, las respuestas de API o los archivos estáticos se solicitan con frecuencia y no cambian cada segundo.

Lo que Nginx Puede Almacenar en Caché

Nginx puede almacenar en caché las respuestas de un servidor ascendente cuando actúa como proxy inverso. Esto es diferente del caché normal del navegador. El caché del navegador almacena archivos en el dispositivo del usuario. El caché de proxy de Nginx almacena respuestas en el servidor para que muchos usuarios puedan beneficiarse de la misma copia en caché.

Una configuración simple de caché de proxy tiene dos partes. Primero, define una zona de caché en el bloque http:

proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=app_cache:10m
    max_size=1g inactive=60m use_temp_path=off;

Luego habilita ese caché en un bloque server o location:

location / {
    proxy_pass http://127.0.0.1:3000;
    proxy_cache app_cache;
    proxy_cache_valid 200 10m;
    proxy_cache_valid 404 1m;
    add_header X-Cache-Status $upstream_cache_status;
}

La directiva proxy_cache_path crea el área de almacenamiento del caché. keys_zone define la memoria compartida para las claves de caché y metadatos. max_size limita el uso del disco. inactive elimina elementos que no se han accedido durante un tiempo.

Las directivas proxy_cache_valid deciden cuánto tiempo ciertos códigos de respuesta permanecen en caché. En el ejemplo, las respuestas exitosas se almacenan en caché durante 10 minutos, mientras que las respuestas 404 se almacenan durante 1 minuto.

El encabezado X-Cache-Status es útil durante las pruebas. Puede mostrar valores como MISS, HIT, BYPASS o EXPIRED, dependiendo de lo que suceda.

Para sitios que también usan Nginx como proxy inverso, esto se combina naturalmente con la configuración de proxy inverso.

Decidiendo Qué Debe Almacenarse en Caché

La parte más difícil del caché de Nginx no es escribir las directivas. Es decidir qué contenido es seguro reutilizar.

Buenos candidatos para el caché incluyen:

• Páginas de marketing públicas.
• Páginas de documentación públicas.
• Páginas de listado de productos que se actualizan en un horario predecible.
• Respuestas de API anónimas.
• Respuestas ascendentes costosas que son idénticas para muchos usuarios.

Malos candidatos para el caché incluyen:

• Páginas de cuenta.
• Carritos de compras.
• Pantallas de administración.
• Respuestas que incluyen datos privados del usuario.
• Páginas que cambian según cookies o encabezados de autorización.

Si una respuesta es diferente para cada usuario, no la almacenes en caché a menos que tengas una estrategia de clave de caché muy clara. Servir accidentalmente la respuesta privada de un usuario a otro usuario es un error grave.

Puedes omitir el caché cuando las solicitudes incluyen datos de sesión o autorización:

proxy_cache_bypass $http_authorization;
proxy_no_cache $http_authorization;

Para sesiones basadas en cookies, puedes usar un patrón similar:

proxy_cache_bypass $cookie_session;
proxy_no_cache $cookie_session;

El nombre exacto de la cookie depende de tu aplicación. No copies esto a ciegas sin verificar cómo maneja las sesiones tu aplicación.

Un escenario práctico: la página de inicio de tu blog público es generada por una aplicación y tarda 300 milisegundos en un día ocupado. Si almacenas en caché esa página durante 5 minutos, la mayoría de los visitantes reciben la copia en caché rápidamente, y la aplicación solo la regenera ocasionalmente. Ese es un caso de uso sólido porque la página de inicio es pública y no específica del usuario.

Claves de Caché, Encabezados y Purga

Nginx usa una clave de caché para decidir si dos solicitudes deben compartir la misma respuesta en caché. La clave de caché predeterminada generalmente se basa en el esquema, método, host y URI. Para muchos sitios, eso es suficiente.

Si las cadenas de consulta cambian la respuesta, asegúrate de que sean parte de la clave. Si las cadenas de consulta son solo parámetros de seguimiento, es posible que desees normalizarlas en la aplicación o en la capa de CDN en lugar de permitir que cada utm_source cree una entrada de caché separada.

Los encabezados de caché ascendentes también importan. Tu aplicación puede enviar encabezados como:

Cache-Control: public, max-age=600

o:

Cache-Control: private, no-store

Nginx puede configurarse para respetar o anular estos encabezados, pero debes elegir una política clara. Si los desarrolladores de la aplicación esperan que Cache-Control: no-store evite el almacenamiento en caché, anular ese comportamiento en Nginx puede crear resultados confusos y arriesgados.

La purga es otra cuestión operativa. Nginx de código abierto no incluye un punto final de purga de caché simple incorporado de la misma manera que algunos módulos comerciales o de terceros. Muchos equipos manejan esto usando duraciones de caché cortas, URL versionadas o scripts de implementación que limpian el directorio de caché durante lanzamientos controlados.

Los TTL cortos a menudo son suficientes. Un caché de 60 segundos en un punto final ocupado aún puede eliminar una gran cantidad de tráfico de backend mientras mantiene el contenido razonablemente fresco.

Probando el Comportamiento del Caché

Después de habilitar el caché, solicita la misma URL varias veces e inspecciona los encabezados de respuesta:

curl -I https://example.com/

Si agregaste X-Cache-Status, la primera solicitud puede mostrar MISS, y las solicitudes posteriores deberían mostrar HIT. Si cada solicitud es un MISS, verifica los encabezados de respuesta, las reglas de omisión de caché, las cookies de solicitud y si el directorio de caché es escribible por el proceso de trabajo de Nginx.

También prueba el comportamiento de inicio y cierre de sesión. Aquí es donde aparecen muchos errores de caché. Abre una ventana de navegador privada, inicia sesión como usuario de prueba y confirma que las páginas privadas no se almacenan en caché públicamente.

Monitorea también el uso del disco. Un caché sin límite práctico puede llenar un sistema de archivos. Usa max_size, mantén el almacenamiento de caché separado de las particiones críticas del sistema cuando sea posible y alerta sobre la presión del disco.

Cuándo Buscar Ayuda

Trae a un ingeniero experimentado en Nginx o plataforma si el contenido en caché aparece bajo el usuario incorrecto, si tu tasa de aciertos de caché se mantiene baja después del ajuste, o si los archivos de caché están llenando el disco inesperadamente. Los problemas de caché pueden parecer simples mientras ocultan un comportamiento específico de la aplicación.

También debes buscar ayuda antes de almacenar en caché APIs autenticadas, paneles multiinquilino o flujos relacionados con pagos. Esas áreas necesitan un diseño cuidadoso.

El caché básico con Nginx funciona mejor cuando comienzas con respuestas públicas y repetibles y duraciones de caché cortas. Agrega encabezados de estado de caché visibles durante las pruebas, respeta los límites de contenido privado y mide tanto el tiempo de respuesta como la carga del backend. Bien hecho, el caché da a los usuarios páginas más rápidas mientras le da a tu aplicación espacio para respirar.