Soluciona problemas

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 orígenes personalizados, consulta también Soluciona problemas de origen personalizado y NEG de Internet.

Problemas y soluciones generales

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 depósito de backend. Cuando habilitas Cloud CDN, es posible que tarde unos minutos antes de que las respuestas comiencen a almacenarse en caché.

Cloud CDN solo almacena en caché las respuestas que están marcadas como públicas y que especifican un plazo de vencimiento o antigüedad máxima. Esta información se transmite en los encabezados de respuesta HTTP. Si las respuestas para una URL no se almacenan en caché, verifica qué encabezados se muestran para esa URL.

Hay varias maneras de verificar los encabezados de respuesta:

En el siguiente ejemplo, se demuestra el uso de curl a fin de verificar los encabezados de respuesta HTTP para http://example.com/style.css:

$ curl -s -D - -o /dev/null http://example.com/style.css
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 comparas estos encabezados con los requisitos de Detalles de almacenamiento en caché, se revela que a la respuesta le falta el encabezado Cache-Control obligatorio.

El método para configurar encabezados depende del tipo de servidor de origen. Si ejecutas un servidor web en Google Compute Engine, consulta la documentación del software del servidor web para obtener detalles sobre la configuración de los encabezados de respuesta. En el caso de Google Cloud Storage, marcar el objeto como compartido públicamente hará que se envíen los encabezados adecuados.

Después de configurar el servidor de origen para agregar el encabezado obligatorio, se puede volver a usar curl a fin de verificar el resultado:

$ curl -s -D - -o /dev/null http://example.com/style.css
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
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
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é con una entrada de caché que se creó hace 2 segundos.

Además, si las ETags están habilitadas en las instancias de backend, Cloud CDN depende de ETags para confirmar la actualización 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
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
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 depósito y a todos sus objetos para allUsers.

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

  1. En Cloud Console, abre el navegador de Cloud Storage.
    Abrir el navegador de Cloud Storage

  2. Haz clic en el depósito para ver la página Detalles del depósito.

  3. En la columna Acceso público, coloca el cursor 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 depósito:

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

Si quieres obtener más información sobre el control de acceso y la IAM para Cloud Storage, consulta Cloud Identity and Access Management.

Para obtener más información sobre las URL firmadas, consulta Usa las 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, lee la página de invalidación de caché.

Cloud CDN almacenará en caché solo las respuestas que están marcadas como almacenables en caché de forma pública y entregará respuestas desde 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 solucionar el problema de manera apropiada, se recomienda inhabilitar Cloud CDN hasta que puedas entender y solucionar el problema. Una vez solucionado, vuelve a habilitar Cloud CDN. Para obtener información sobre qué contenido se almacena en caché y por cuánto tiempo, consulta Detalles de almacenamiento en caché.

La tasa de aciertos de caché es baja o hay varios llenados de caché para el mismo contenido

Si tienes tasas de aciertos de caché más bajas que las esperadas para los servicios o depósitos de backend, asegúrate de que las respuestas de las URL de interés se almacenen en caché.

Cloud CDN incorpora el URI de solicitud completo en las claves de caché, por lo que http://example.com/cat.jpg?1 y http://example.com/cat.jpg?2 tendrán entradas de caché independientes. Puedes mejorar las tasas de aciertos de caché si siempre usas una URL única 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. Además, puedes mejorar la tasa de aciertos de caché mediante el encabezado de respuesta Vary solo cuando sea necesario. La sección Detalles de almacenamiento en caché tiene más información sobre las claves de caché.

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. Consulta Detalles de almacenamiento en caché si quieres obtener información sobre los plazos de vencimiento y la documentación para el software del servidor web a fin de obtener detalles acerca de la configuración de los encabezados de respuesta adecuados. Sin embargo, ten en cuenta que Cloud CDN opera numerosas memorias caché en todo el mundo, y que 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 no comprime ni descomprime las respuestas en sí, pero puede entregar respuestas que genera el servidor de origen y que se comprimen mediante codificaciones como gzip y DEFLATE.

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, algunos softwares del servidor web inhabilitarán de manera automática la compresión de las solicitudes que incluyan un encabezado Via. La presencia de un encabezado Via indica que un proxy reenvió la solicitud. Los proxies HTTP, como el balanceo de cargas de HTTP(S), agregan un encabezado Via a cada solicitud como lo exige 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 el balanceo de cargas de HTTP(S), agrega las 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 que reenvía un proxy como el balanceo de cargas de HTTP(S). 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 mediante la comparación de los encabezados de respuesta ETag y Last-Modified. Si Cloud CDN encuentra 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 Stackdriver Logging con statusDetails byte_range_caching_aborted o si tus instancias muestran respuestas 412 Precondition Failed, asegúrate de que el software del servidor web que se ejecuta en todas las instancias de VM muestre los mismos valores ETag y Last-Modified para un recurso determinado.

Cuando se entregan archivos desde un disco, es común 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 las instancias de VM informen valores coherentes mediante el uso de 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 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 de URL y de firma, asegúrate de usar la variante segura para URL de base64. Base64 estándar falla cuando los caracteres generados no son seguros para las URL. Ten en cuenta que 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 depósito 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 de unión (&).

  • Asegúrate de que la marca de tiempo Expires de las cookies que emites no sea corta sin necesidad. Los períodos de validez de menos de 1 a 2 minutos pueden generar problemas de sesgo de reloj 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

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 /. 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, todavía se trata como 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

Los siguientes problemas y limitaciones conocidos afectan a Cloud CDN:

  • Las invalidaciones de caché se limitan a una invalidación por mapa de URL por minuto.