Soluciona problemas de Cloud CDN

Obtén información sobre los pasos para la solución de problemas que podrían resultar útiles si te encuentras con los siguientes problemas en Cloud CDN.

Si el problema que ves está relacionado con backends externos, consulta también Soluciona problemas de backend externos y NEG de Internet.

Problemas y soluciones generales

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

Las respuestas no se almacenan en caché

Si las respuestas no se almacenan en caché, primero verifica que Cloud CDN esté habilitado para el servicio de backend o el bucket de backend. Cuando habilitas Cloud CDN, es posible que tarde unos minutos antes de que las respuestas comiencen a almacenarse en caché.

Cloud CDN almacena en caché solo las respuestas con contenido en caché. Esta información se transmite en los encabezados de respuesta HTTP, en combinación con la configuración de backend. Si las respuestas para una URL no se almacenan en caché, verifica cuáles encabezados se muestran para esa URL y cómo está configurada la caché para tu backend.

Existen varias maneras de verificar los encabezados de respuesta:

En el siguiente ejemplo, se demuestra el uso de curl para verificar 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

La comparación de estos encabezados con los requisitos de contenido que puede almacenarse en caché revela que a la respuesta le falta el encabezado Cache-Control obligatorio (se supone que el modo de caché se establece en USE_ORIGIN_HEADERS).

El método para configurar 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 detalles sobre la configuración de los encabezados de respuesta. En Cloud Storage, marcar el objeto como compartido de manera pública hace que se envíen los encabezados adecuados.

Después de configurar el servidor de origen para agregar el encabezado obligatorio, puedes volver a usar curl a fin de verificar 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 agrega un encabezado Age a las respuestas que entrega desde la caché. En este caso, el encabezado indica que la respuesta se entregó de forma correcta desde la memoria caché mediante una entrada de caché que se creó hace dos segundos.

Además, si ETags están habilitados en las instancias de backend, Cloud CDN depende de ETags para confirmar la actualidad del objeto. Si las instancias de backend entregan ETag diferentes en el mismo objeto, Cloud CDN cuenta las discrepancias como un error de caché y actualiza el objeto. Para evitar esto, las instancias de backend deben entregar las mismas ETag o estas deben estar inhabilitadas.

A fin de verificar esto, 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

Si quieres proporcionar acceso a los objetos en Cloud Storage, debes configurar las URL firmadas, o bien otorgar acceso público al bucket y a todos sus objetos para allUsers.

Si decides proporcionar acceso de allUsers, puedes verificar el acceso a nivel del objeto como se muestra a continuación.

Console

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

    Abrir el navegador de Storage

  2. Haz clic en el bucket para ver la página Detalles del bucket .

  3. En la columna Acceso público, mantén el puntero sobre el ícono de signo de exclamación y haz clic en Editar acceso.

    Asegúrate de que se establezca el siguiente permiso para cada objeto en el bucket:

    • Entidad: Usuario
    • Nombre: allUsers
    • Acceso: Lector

Si deseas obtener más información sobre el control de acceso para Cloud Storage, consulta la documentación de administración de identidades y accesos (IAM) de Cloud Storage.

Para obtener más información sobre las URL firmadas, consulta Usa URL firmadas.

Si los objetos son accesibles, pero no se almacenan en caché, consulta Las respuestas no se almacenan en caché.

El contenido privado se almacenó en caché o el contenido almacenado en caché es incorrecto

Si sabes por qué el servidor de origen entregó el contenido privado o incorrecto y puedes solucionar el problema, puedes invalidar las memorias caché de Cloud CDN mediante el siguiente proceso:

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

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

Cloud CDN almacena en caché solo las respuestas con contenido que se almacena en caché y entrega respuestas de la caché solo hasta el plazo de vencimiento especificado en la respuesta. Si no sabes por qué el contenido se almacenó en caché o no puedes corregir el el problema de forma adecuada, inhabilitar Cloud CDN hasta que puedas entender y solucionar el problema y, luego, volver a habilitarla. Para obtener más información sobre qué contenido se almacena en caché y por cuánto tiempo, consulta la Descripción general del almacenamiento en caché.

La tasa de aciertos de caché es baja

Para el rendimiento y la escalabilidad, es importante optimizar la proporción de aciertos de caché. Si tienes tasas de aciertos de caché más bajas que las esperadas, asegúrate de seguir las prácticas recomendadas para optimizar la proporción de aciertos de caché.

Usa la siguiente tabla para comprender algunos de los posibles motivos de una baja tasa de aciertos de caché 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 puede almacenar Cloud CDN. Asegúrate de que tu contenido se pueda almacenar en caché.
El modo de almacenamiento en caché no es óptimo para tu aplicación. Cloud CDN tiene varios modos de almacenamiento en caché. Si no usas encabezados de control de caché para controlar el comportamiento de almacenamiento en caché, se recomienda que Cloud CDN almacene en caché todo el contenido estático.
Hay una pequeña cantidad de tráfico. Durante las pruebas y la experimentación, es probable que la cantidad de tráfico que generas sea baja. Google tiene una caché distribuida global, y las solicitudes de diferentes ubicaciones geográficas van a diferentes ubicaciones de 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 suficiente volumen de tráfico a Google para propagar todas las memorias caché relevantes.
  • 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 de forma aleatoria cada solicitud a un proveedor de CDN diferente.
Las respuestas para determinadas URL 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 tendrán entradas de caché independientes. Usa siempre una sola URL para un recurso determinado.

Si necesitas pasar parámetros a la versión de JavaScript que se ejecuta en una página que puede almacenarse en caché, considera usar identificadores de fragmentos en lugar de strings de consulta.
La caché está fragmentada de manera innecesaria debido al campo del encabezado Vary. El campo del encabezado Vary en una respuesta describe qué partes de un mensaje de solicitud (aparte del método, el campo del encabezado Host y el destino de la solicitud) podrían influir en el proceso del servidor de origen para la selección y representación de una respuesta. Por ejemplo, es posible que desees usar el encabezado Vary: Accept-Encoding si entregas contenido diferente a los clientes que pueden manejar respuestas comprimidas y aquellos que no. Usa el encabezado de respuesta Vary solo cuando sea necesario.
No usas claves de caché personalizadas. Según la configuración predeterminada, Cloud CDN usa la URL de solicitud completa para compilar la clave de caché. Puedes personalizar las claves de caché para omitir o incluir cualquier combinación de protocolo, host y string de consulta. Por ejemplo, si dos dominios usan el mismo contenido estático, puedes crear una clave de caché personalizada que omita el campo de host. Usa claves de caché personalizadas cuando sea necesario.

Existen varios llenados de caché para el mismo contenido

En general, puedes reducir el número de llenados de caché; para ello, aumenta los plazos de vencimiento de las respuestas que pueden almacenarse en caché. Si todo lo demás permanece igual, verás menos llenados de caché para una respuesta con Cache-Control: public, max-age=86400 que una con Cache-Control: public, max-age=1.

Para obtener más información sobre los plazos de vencimiento, consulta Plazos de vencimiento y solicitudes de validación. Si deseas obtener información a fin de configurar los encabezados de respuesta adecuados, consulta la documentación para el software del servidor web.

Cloud CDN opera numerosas memorias caché en todo el mundo, y las entradas de caché antiguas se expulsan de manera habitual a fin de dejar lugar para el contenido nuevo. Como resultado, se esperan varios llenados de caché por recurso como parte del funcionamiento normal.

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, recomendamos que uses la compresión en el origen porque reduce la caché los costos de relleno.

Si las respuestas que entrega Cloud CDN no están comprimidas, pero deberían estarlo, verifica que el software del servidor web que se ejecuta en las instancias esté configurado para comprimir respuestas. De forma predeterminada, algunas opciones de software del servidor web inhabilitan de forma automática la compresión de las solicitudes que incluyen un encabezado Via. La presencia de un encabezado Via indica que un proxy reenvió la solicitud. Proxies HTTP como el balanceador de cargas de aplicaciones externo agrega un Via encabezado a cada solicitud que requiere la especificación HTTP. Para habilitar la compresión, es posible que tengas que anular la configuración predeterminada del servidor web para indicarle que comprima las respuestas, incluso si la solicitud tiene un encabezado Via.

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

Para permitir que la compresión nginx funcione con tu balanceador de cargas de aplicaciones externo, agrega el siguientes dos líneas 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 cargas de aplicaciones externo.

  • La segunda línea agrega 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é separadas para las variantes comprimidas y no comprimidas de los recursos que se pueden comprimir.

Después de modificar nginx.conf, es necesario que reinicies nginx antes de que use la configuración nueva. En muchas distribuciones de Linux, puedes reiniciar nginx si ejecutas sudo service nginx restart o /etc/init.d/nginx restart.

Las respuestas terminan con errores byte_range_caching_aborted

Cuando Cloud CDN arma una respuesta a partir de varias solicitudes de rango de bytes, verifica si esos rangos son de la misma versión del recurso. Para ello, compara los encabezados de respuesta ETag y Last-Modified. Si Cloud CDN descubre que el valor de cualquiera de los encabezados es incoherente con los rangos que ya entregó al cliente, anulará la respuesta.

Si observas respuestas canceladas inesperadas, entradas de registro de Cloud Logging con statusDetails byte_range_caching_aborted o tus instancias muestran respuestas 412 Precondition Failed, asegúrate de que el software del servidor web que se ejecuta en todas tus instancias de máquina virtual (VM) muestre los mismos valores de ETag y Last-Modified para un recurso determinado.

Cuando se entregan archivos desde el disco, es común que el software del servidor web derive los valores de ETag y Last-Modified de la hora de modificación del archivo. En este caso, puedes asegurarte de que las instancias de VM informen valores coherentes mediante la misma imagen para todas las instancias. Consulta la documentación sobre el software del servidor web para obtener detalles sobre cómo determina los valores de ETag y Last-Modified.

Solución de problemas de cookies firmadas

Los siguientes problemas pueden ocurrir si usas cookies firmadas.

Codificación

Cuando se genera una firma, la solicitud se rechaza de forma inesperada debido a una discrepancia de firma.

Cuando codifiques los valores URL y Signature, asegúrate de usar el Variante segura para URLs de base64. Base64 estándar falla cuando los caracteres generados no son seguros para las URL. 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 para el servicio o bucket de backend que usa Cloud CDN.

  • No firmes parámetros de búsqueda cuando generes y firmes un URLPrefix. Asegúrate de que URLPrefix contenga solo el esquema, el host y los componentes de la ruta de acceso (parcial) de la URL.

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

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

  • No incluyas un carácter de 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 tus clientes deban enviar porque muchos servidores web también tienen límites máximos de encabezados de la solicitud.

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

  • Asegúrate de que la marca de tiempo Expires de las cookies que emites no sea innecesariamente corta. Los períodos de validez de menos de uno a dos minutos pueden generar problemas de sesgo de tiempo entre la app emisora y la infraestructura de Cloud CDN.

  • Asegúrate de no configurar varias cookies para el mismo Domain y la misma Path con valores diferentes. Establece una sola cookie por usuario con un valor de prefijo de URL que abarque todo el contenido al que el usuario necesita acceder.

Mensajes de error

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

Errores de invalidación de caché

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

El valor de la ruta de acceso tenía un formato no válido. Las rutas de acceso deben comenzar con /, no deben contener ? ni # y deben tener solo un *, que debe ser el carácter final después de una /.

Las rutas de acceso no deben tener más de 1,024 caracteres. Si recibes este error, verifica el valor de la ruta de acceso y corrige cualquier error de formato.

Este error solo aborda el formato de la ruta de acceso. Una ruta de acceso que tiene un formato válido, pero que no existe, también se considera válida.
Rate Limit Exceeded Cloud CDN restringe la velocidad a la que pueden realizarse las 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 de acceso que coincida con cualquier cantidad de objetos.

Problemas conocidos

  • Las invalidaciones de caché tienen un límite de frecuencia de una invalidación por mapa de URL por minuto.

    Resolución: Espera al menos un minuto antes de intentar invalidar otro mapa de URL.

    Para obtener más información sobre el límite de frecuencia de invalidación de caché, consulta Limitaciones.