Solucionar problemas de Cloud CDN

Descubre soluciones que pueden resultarte útiles si tienes alguno de los siguientes problemas mientras usas Cloud CDN.

Si el problema que observas está relacionado con backends externos, consulta también el artículo Solucionar problemas con backends externos y NEG de Internet.

Problemas generales y soluciones

En esta sección se describen algunos problemas habituales y sus soluciones.

Las respuestas no se almacenan en caché

Si las respuestas no se almacenan en caché, primero comprueba que Cloud CDN esté habilitado en tu servicio de backend o en tu backend bucket. Cuando habilitas Cloud CDN, pueden pasar unos minutos antes de que las respuestas empiecen a almacenarse en caché.

Cloud CDN solo almacena en caché las respuestas con contenido almacenable en caché. Esta información se transmite en los encabezados de respuesta HTTP, junto con la configuración del backend. Cuando configuras un encabezado de respuesta personalizado con cdn_cache_status, puedes observar el estado de la caché en los registros de Cloud CDN y determinar si una respuesta se ha servido como resultado de un fallo en la caché.

Si no se almacenan en caché las respuestas de una URL, comprueba qué encabezados se devuelven para esa URL y cómo se configura la capacidad de almacenamiento en caché en tu backend.

Hay varias formas de comprobar los encabezados de respuesta:

En el siguiente ejemplo se muestra cómo usar curl para comprobar los encabezados de respuesta HTTP de http://example.com/style.css:

curl -s -D - -o /dev/null http://example.com/style.css

Resultado:

HTTP/1.1 200 OK
Date: Tue, 16 Feb 2016 12:00:00 GMT
Content-Type: text/css
Content-Length: 1977
Via: 1.1 google

Si comparamos estos encabezados con los requisitos del contenido que se puede almacenar en caché, vemos que falta el encabezado Cache-Control (suponiendo que el modo de caché esté configurado como USE_ORIGIN_HEADERS).

El método para definir encabezados depende del tipo de servidor de origen. Si ejecutas un servidor web en Compute Engine, consulta la documentación del software del servidor web para obtener información sobre cómo configurar los encabezados de respuesta. En Cloud Storage, si marcas el objeto como compartido públicamente, se enviarán los encabezados correspondientes.

Después de volver a configurar el servidor de origen para añadir el encabezado necesario, puede usar curl de nuevo para comprobar el resultado:

curl -s -D - -o /dev/null http://example.com/style.css

Resultado:

HTTP/1.1 200 OK
Date: Tue, 16 Feb 2016 12:00:30 GMT
Content-Type: text/css
Content-Length: 1977
Cache-Control: max-age=86400,public
Via: 1.1 google

curl -s -D - -o /dev/null http://example.com/style.css

Resultado:

HTTP/1.1 200 OK
Date: Tue, 16 Feb 2016 12:00:31 GMT
Content-Type: text/css
Content-Length: 1977
Cache-Control: max-age=86400,public
Via: 1.1 google

curl -s -D - -o /dev/null http://example.com/style.css

Resultado:

HTTP/1.1 200 OK
Date: Tue, 16 Feb 2016 12:00:30 GMT
Content-Type: text/css
Content-Length: 1977
Cache-Control: max-age=86400,public
Via: 1.1 google
Age: 2

La última respuesta de este ejemplo incluye un encabezado Age. Cloud CDN añade un encabezado Age a las respuestas que proporciona desde la caché. En este caso, el encabezado indica que la respuesta se ha servido correctamente desde la caché mediante una entrada de caché que se creó hace dos segundos.

Además, si los ETags están habilitados en las instancias de backend, Cloud CDN se basa en ellos para confirmar la actualización del objeto. Si las instancias de backend sirven diferentes encabezados ETag en el mismo objeto, Cloud CDN contabiliza las discrepancias como fallos en la caché y actualiza el objeto. Para evitarlo, las instancias de backend deben servir el mismo ETag o los ETags deben inhabilitarse.

Para comprobarlo, ejecuta curl varias veces y observa los cambios en el valor de ETag:

curl -s -D - -o /dev/null http://example.com/image.png

Resultado:

HTTP/2 200
date: Fri, 20 Mar 2020 15:02:30 GMT
server: Apache
strict-transport-security: max-age=31536000; includeSubDomains
last-modified: Mon, 16 Mar 2020 04:20:59 GMT
etag: "10f-5a0f1256f1402"
accept-ranges: bytes
content-length: 271
cache-control: public, max-age=864000
expires: Mon, 30 Mar 2020 15:02:30 GMT
vary: Accept-Encoding
x-xss-protection: 1; mode=block
x-content-type-options: nosniff
content-type: image/png
via: 1.1 google
alt-svc: clear

curl -s -D - -o /dev/null http://example.com/image.png

Resultado:

HTTP/2 200
date: Fri, 20 Mar 2020 15:03:11 GMT
server: Apache
strict-transport-security: max-age=31536000; includeSubDomains
last-modified: Mon, 16 Mar 2020 04:18:31 GMT
etag: "10f-5a0f11ca09b7a"
accept-ranges: bytes
content-length: 271
cache-control: public, max-age=864000
expires: Mon, 30 Mar 2020 15:03:11 GMT
vary: Accept-Encoding
x-xss-protection: 1; mode=block
x-content-type-options: nosniff
content-type: image/png
via: 1.1 google
alt-svc: clear

No se puede acceder a los objetos de Cloud Storage

Para proporcionar acceso a los objetos de Cloud Storage, debes configurar URLs firmadas o dar acceso público al segmento y a todos sus objetos para allUsers.

Si decides proporcionar acceso allUsers, puedes verificar el acceso a nivel de objeto de la siguiente manera.

Consola

  1. En la Google Cloud consola, abre el navegador de Cloud Storage.

    Abrir el navegador de almacenamiento

  2. Haz clic en un segmento para ver la página Detalles del segmento.

  3. En la columna Acceso público, coloque el puntero sobre el icono de signo de exclamación y haga clic en Editar acceso.

    En cada objeto del segmento, asegúrate de que se haya definido el siguiente permiso:

    • Entidad: User
    • Nombre: allUsers
    • Acceso: lector

Para obtener más información sobre el control de acceso de Cloud Storage, consulta la documentación de Gestión de Identidades y Accesos (IAM) de Cloud Storage.

Para obtener más información sobre las URLs firmadas, consulte Usar URLs firmadas.

Si se puede acceder a los objetos, pero no se almacenan en caché, consulta Las respuestas no se almacenan en caché.

Se ha almacenado en caché contenido privado o el contenido almacenado en caché es incorrecto

Si sabes por qué el servidor de origen ha servido contenido privado o incorrecto y puedes solucionar el problema, puedes invalidar las cachés de Cloud CDN siguiendo este proceso:

  1. Asegúrate de que el servidor de origen ya no devuelva contenido privado o incorrecto.
  2. Solicita una invalidación de caché para indicar a Cloud CDN que deje de servir el contenido almacenado en caché.

Para obtener más información, consulta el resumen de la invalidación de caché.

Cloud CDN solo almacena en caché las respuestas con contenido almacenable en caché y sirve las respuestas de la caché solo hasta la hora de vencimiento especificada en la respuesta. Si no sabes por qué se ha almacenado en caché el contenido o no puedes solucionar el problema rápidamente, te recomendamos que inhabilites Cloud CDN hasta que puedas entender y solucionar el problema, y que luego lo vuelvas a habilitar. Para obtener más información sobre qué contenido se almacena en caché y durante cuánto tiempo, consulta la descripción general del almacenamiento en caché.

La tasa de aciertos de caché es baja

Para mejorar el rendimiento y la escalabilidad, es importante optimizar las tasas de aciertos de caché. Si las ratios de aciertos de caché son inferiores a las esperadas, asegúrese de seguir las prácticas recomendadas para optimizar la ratio de aciertos de caché.

Consulta la siguiente tabla para identificar algunos de los posibles motivos por los que la proporción de aciertos de caché es baja y las posibles soluciones.

Razones Comentarios Correcciones
Tu contenido no se puede almacenar en caché. Una respuesta almacenable en caché es una respuesta HTTP que Cloud CDN puede almacenar. Asegúrate de que tu contenido se pueda almacenar en caché.
El modo de caché no es óptimo para tu aplicación. Cloud CDN tiene varios modos de caché. Si no usas encabezados de control de caché para controlar el comportamiento del almacenamiento en caché, te recomendamos que permitas que Cloud CDN almacene en caché todo el contenido estático.
Hay poco tráfico. Durante las pruebas y los experimentos, es probable que la cantidad de tráfico que generes sea baja. Google tiene una caché distribuida global y las solicitudes de diferentes ubicaciones geográficas se dirigen a diferentes ubicaciones del frontend de Google. En cada ubicación de frontend, Google puede tener varias instancias discretas de la caché.
  • Asegúrate de que se envíe a Google un volumen de tráfico suficiente para rellenar todas las cachés pertinentes.
  • Durante las pruebas, asegúrate de fragmentar el tráfico por URL para que todo el tráfico de cada conjunto de solicitudes se dirija a Google. No fragmentes aleatoriamente cada solicitud a un proveedor de CDN diferente.
Las respuestas de URLs concretas no se almacenan en caché. Cloud CDN incorpora el URI de solicitud completo en sus claves de caché, por lo que http://example.com/cat.jpg?color=orange y http://example.com/cat.jpg?color=gray tienen entradas de caché independientes. Utiliza siempre una sola URL para un recurso determinado.

Si necesita transferir parámetros a JavaScript que se ejecuta en una página que se puede almacenar en caché, le recomendamos que utilice identificadores de fragmento en lugar de cadenas de consulta.
La caché se ha fragmentado innecesariamente debido al campo de encabezado Vary. El campo de encabezado Vary de una respuesta describe qué partes de un mensaje de solicitud (aparte del método, el campo de encabezado Host y el destino de la solicitud) pueden influir en el proceso del servidor de origen para seleccionar y representar una respuesta. Por ejemplo, puedes usar el encabezado Vary: Accept-Encoding si sirves contenido diferente a los clientes que pueden gestionar respuestas comprimidas y a los que no. Usa el encabezado de respuesta Vary solo cuando sea necesario.
No estás usando claves de caché personalizadas. De forma predeterminada, Cloud CDN usa la URL de solicitud completa para crear la clave de caché. Puede personalizar las claves de caché para incluir u omitir cualquier combinación de protocolo, host y cadena de consulta. Por ejemplo, si dos dominios usan el mismo contenido estático, puede crear una clave de caché personalizada que omita el campo de host. Usa claves de caché personalizadas cuando sea necesario.

Hay varias entradas en caché para el mismo contenido

En general, puede reducir el número de llenados de caché aumentando los tiempos de caducidad de sus respuestas almacenables en caché. Si todo lo demás es igual, verás menos rellenos de caché en una respuesta con Cache-Control: public, max-age=86400 que en una con Cache-Control: public, max-age=1.

Para obtener más información sobre los tiempos de vencimiento, consulta Tiempos de vencimiento y solicitudes de validación. Para obtener información sobre cómo configurar los encabezados de respuesta adecuados, consulta la documentación del software de tu servidor web.

Cloud CDN opera numerosas cachés en todo el mundo y las entradas de caché antiguas se eliminan periódicamente para dejar espacio a contenido nuevo. Por lo tanto, es normal que se rellene la caché varias veces por recurso.

La compresión no funciona

Cloud CDN ofrece compresión dinámica para orígenes que no pueden comprimir sus respuestas. Siempre que sea posible, le recomendamos que use la compresión en el origen, ya que reduce los costes de llenado de la caché.

Si las respuestas que sirve Cloud CDN no están comprimidas, pero deberían estarlo, compruebe que el software del servidor web que se ejecuta en sus instancias esté configurado para comprimir las respuestas. De forma predeterminada, algunos softwares de servidor web inhabilitan automáticamente la compresión de las solicitudes que incluyen un encabezado Via. La presencia de un encabezado Via indica que la solicitud se ha reenviado a través de un proxy. Los proxies HTTP, como el balanceador de carga de aplicaciones externo, añaden un encabezado Via a cada solicitud, tal como requiere la especificación HTTP. Para habilitar la compresión, es posible que tengas que anular la configuración predeterminada de tu servidor web para indicarle que comprima las respuestas aunque la solicitud tenga un encabezado Via.

Si usas el software de servidor web nginx, modifica el archivo de configuración nginx.conf para habilitar la compresión. La ubicación de este archivo depende de dónde esté instalado nginx. En muchas distribuciones de Linux, el archivo se almacena en /etc/nginx/nginx.conf.

Para permitir que la compresión de nginx funcione con tu balanceador de carga de aplicaciones externo, añade las dos líneas siguientes a la sección http de nginx.conf:

gzip_proxied any;
gzip_vary on;

  • La primera línea habilita la compresión incluso para las solicitudes reenviadas por un proxy, como el balanceador de carga de aplicaciones externo.

  • La segunda línea añade un encabezado Vary: Accept-Encoding a las respuestas. Vary: Accept-Encoding notifica a los proxies de almacenamiento en caché, como Cloud CDN, que deben mantener entradas de caché independientes para las variantes comprimidas y no comprimidas de los recursos comprimibles.

Después de modificar nginx.conf, debes reiniciar nginx para que use la nueva configuración. En muchas distribuciones de Linux, puedes reiniciar nginx ejecutando sudo service nginx restart o /etc/init.d/nginx restart.

Las respuestas terminan con errores byte_range_caching_aborted

Cuando Cloud CDN ensambla una respuesta a partir de varias solicitudes de intervalo de bytes, comprueba si esos intervalos son de la misma versión del recurso comparando los encabezados de respuesta ETag y Last-Modified. Si Cloud CDN detecta que el valor de alguno de los encabezados no coincide con los intervalos que ya ha servido al cliente, aborta la respuesta.

Si observa respuestas terminadas inesperadamente, entradas de registro de Cloud Logging con byte_range_caching_aborted statusDetails o sus instancias devuelven respuestas 412 Precondition Failed, asegúrese de que el software del servidor web que se ejecuta en todas sus instancias de máquina virtual (VM) devuelva los mismos valores ETag y Last-Modified para un recurso determinado.

Cuando se sirven archivos desde el disco, es habitual que el software del servidor web derive los valores ETag y Last-Modified de la hora de modificación del archivo. En este caso, puedes asegurarte de que tus instancias de VM registren valores coherentes usando la misma imagen en todas las instancias. Para obtener información sobre cómo determina el software de tu servidor web los valores de ETag y Last-Modified, consulta la documentación del software de tu servidor web.

Solucionar problemas con las cookies firmadas

Los siguientes problemas pueden producirse cuando utilizas cookies firmadas.

Codificación

Al generar una firma, la solicitud se rechaza de forma inesperada debido a que la firma no coincide.

Cuando codifiques los valores URL y Signature, asegúrate de usar la variante segura para URLs de base64. La codificación base64 estándar falla cuando los caracteres generados no son seguros para URLs. Se acepta el relleno.

Firma

Cloud CDN rechaza tu solicitud.

  • Asegúrate de usar HMAC-SHA-1 como algoritmo de firma y no otra variante de HMAC.

  • Confirma que el parámetro KeyName (que distingue entre mayúsculas y minúsculas) coincide con un nombre de clave válido del servicio de backend o del backend bucket que usa Cloud CDN.

  • No firme los parámetros de consulta al generar y firmar un URLPrefix. Asegúrate de que URLPrefix solo contenga el esquema, el host y los componentes de la ruta (parcial) de la URL.

  • Asegúrate de que el bloque de firma (URLPrefix, Expires, KeyName y el propio Signature) sean las últimas secciones delimitadas por : de la cookie.

  • Asegúrate de que URLPrefix, Expires, KeyName y Signature se produzcan en ese orden.

  • No incluyas un asterisco (*) al final de un URLPrefix en una cookie firmada.

Cookies

  • Los navegadores suelen limitar las cookies a 4 KB por dominio, con un límite de 50 cookies por dominio en total. Toma nota de otras cookies que emitas y que requieras que tus clientes envíen, ya que muchos servidores web también tienen límites máximos en los encabezados de solicitud.

  • Asegúrese de usar el carácter de dos puntos (:), punto de código Unicode U+003A, como delimitador de los parámetros con nombre de una cookie firmada, y no el carácter de signo "&" (&).

  • Asegúrate de que la marca de tiempo Expires de las cookies que emitas no sea innecesariamente breve. Los periodos de validez de menos de uno o dos minutos pueden ser propensos a problemas de desfase del reloj entre la aplicación emisora y la infraestructura de Cloud CDN.

  • Asegúrese de no definir varias cookies para el mismo Domain y Path con valores diferentes. Defina una sola cookie por usuario con un valor de prefijo de URL que abarque todo el contenido al que el usuario necesite acceder.

Mensajes de error

En esta sección se proporciona información sobre algunos mensajes de error habituales y cómo resolverlos.

Errores de invalidación de caché

Código de error Notas
Invalid value for field 'resource.path'

El valor de la ruta tenía un formato no válido. Las rutas deben empezar por /, no pueden contener ? ni #, y solo pueden tener un *, que debe ser el último carácter después de un /.

Las rutas no pueden tener más de 1024 caracteres. Si aparece este error, comprueba el valor de la ruta y corrige los errores de formato.

Este error solo hace referencia al formato de la ruta. Una ruta con un formato válido, pero que no existe, se sigue tratando como válida.
Rate Limit Exceeded Cloud CDN restringe la frecuencia con la que se pueden realizar operaciones de invalidación de caché. Solo se permite una invalidación por minuto. Sin embargo, cada operación puede especificar un patrón de ruta que coincida con cualquier número de objetos.

Problemas conocidos

  • Las invalidaciones de caché están limitadas a una invalidación por mapa de URLs al minuto.

    Resolución: espera al menos un minuto antes de intentar invalidar otra asignación de URLs.

    Para obtener más información sobre la limitación de la frecuencia de invalidación de caché, consulta Limitaciones.