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.

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

Salida:

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 contenido que puede almacenarse en caché revela que a la respuesta le falta el encabezado Cache-Control obligatorio (se supone que el modo de almacenamiento en caché se usa para usar encabezados de origen).

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 públicamente 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

Salida:

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

Salida:

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

Salida:

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 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.

Para verificar esto, ejecuta curl varias veces y observa los cambios en el valor ETag:

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

Salida:

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
<em>etag: "10f-5a0f1256f1402"</em>
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

Salida:

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
<em>etag: "10f-5a0f11ca09b7a"</em>
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:

Console

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

    Abre el navegador de Storage

  2. Haz clic en un 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 deseas obtener más información sobre el control de acceso de Cloud Storage, consulta la documentación de administración de identidades y accesos (IAM) para 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 que están marcadas como almacenables en caché de forma pública y entrega 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 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

Si tienes tasas de aciertos de caché más bajas que las esperadas para los servicios de backend 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 sus 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 cadenas de consulta.

Además, puedes mejorar la tasa de aciertos de caché mediante el encabezado de respuesta Vary solo cuando sea necesario. Para obtener más información, consulta Claves de caché.

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 para 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 no comprime ni descomprime las respuestas en sí, pero puede entregar respuestas que genera el servidor de origen 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 inhabilitan de forma automáticamente la compresión de las solicitudes que incluyen 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 reenviadas mediante 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 de 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 Responses. 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) muestra 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 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 se pueden generar 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 la variante segura para URL de base64. Base64 estándar falla cuando los caracteres generados no son seguros para las URL. Se aceptó 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 sin necesidad. Los períodos de validez de menos de uno a dos 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.