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 bucket de backend. 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 proporcionado 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 ETags en el mismo objeto, Cloud CDN contabiliza las discrepancias como un fallo 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.

    Comprueba que se haya definido el siguiente permiso para cada objeto del segmento:

    • Entidad: usuario
    • 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, de otro modo, se podría 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. Use 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 rellenos 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 utiliza 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, te recomendamos que uses 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 software 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 más información sobre cómo determina el software de tu servidor web los valores 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.

Al codificar los valores URL y Signature, asegúrese de usar la variante segura para URLs de Base64. La base64 estándar falla cuando los caracteres generados no son seguros para URLs. Se acepta el relleno.

Firma