Resolver problemas do Cloud CDN

Caso você encontre os problemas a seguir ao usar o Cloud CDN, veja os passos de solução de problemas.

Se o problema encontrado estiver relacionado a back-ends externos, consulte também a Solução de problemas de back-end externo e NEG da Internet.

Problemas gerais e soluções

Esta seção descreve alguns problemas comuns e as soluções deles.

As respostas não estão sendo armazenadas em cache

Se as respostas não estiverem sendo armazenadas em cache, primeiro confirme se o Cloud CDN está ativado no serviço ou no bucket de back-end. Quando você ativa o Cloud CDN, pode levar alguns minutos até que as respostas comecem a ser armazenadas em cache.

O Cloud CDN armazena em cache somente as respostas com conteúdo que pode ser armazenado em cache. Essas informações são transmitidas nos cabeçalhos de resposta HTTP, em combinação com a configuração do back-end. Ao configurar um cabeçalho de resposta personalizado com cdn_cache_status, é possível observar o status do cache nos registros do Cloud CDN e determinar se uma resposta foi mostrada como resultado de uma falha de cache.

Se as respostas para um URL não estiverem sendo armazenadas em cache, verifique quais cabeçalhos estão sendo retornados para esse URL e como o armazenamento em cache está configurado para seu back-end.

Há várias maneiras de verificar cabeçalhos de resposta:

O exemplo a seguir demonstra o uso de curl para verificar os cabeçalhos de resposta HTTP para http://example.com/style.css:

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

Resposta:

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

A comparação desses cabeçalhos com os requisitos de conteúdo armazenável em cache revela que a resposta não tem o cabeçalho Cache-Control necessário, supondo que o modo de cache esteja definido como USE_ORIGIN_HEADERS.

O método para definir cabeçalhos depende do tipo de servidor de origem. Se você estiver executando um servidor da Web no Compute Engine, consulte a documentação do software do servidor da Web para detalhes sobre como configurar cabeçalhos de resposta. No Cloud Storage, marcar o objeto como compartilhado publicamente faz com que os cabeçalhos apropriados sejam enviados.

Depois de reconfigurar o servidor de origem para adicionar o cabeçalho necessário, use curl novamente para verificar o resultado:

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

Resposta:

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

Resposta:

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

Resposta:

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

A última resposta neste exemplo inclui um cabeçalho Age. O Cloud CDN adiciona um cabeçalho Age às respostas veiculadas a partir do cache. Aqui, o cabeçalho indica que a resposta foi veiculada do cache usando uma entrada de cache criada há dois segundos.

Além disso, se as ETags estiverem ativadas nas instâncias de back-end, o Cloud CDN vai confiar nessas ETags para confirmar a atualização do objeto. Se as instâncias de back-end veicularem ETags diferentes no mesmo objeto, o Cloud CDN contará incompatibilidades como uma ausência no cache e atualizará o objeto. Para evitar isso, as instâncias de back-end precisam veicular a mesma ETag ou as ETags precisam ser desativadas.

Para verificar isso, execute curl repetidamente e observe as alterações no valor da ETag:

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

Resposta:

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

Resposta:

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

Não é possível acessar objetos do Cloud Storage

Para fornecer acesso a objetos no Cloud Storage, é necessário configurar URLs assinados ou conceder ao bucket e a todos os objetos dele acesso público para allUsers.

Se decidir fornecer acesso para allUsers, verifique o acesso no nível do objeto da seguinte forma:

Console

  1. No Console do Google Cloud, abra o navegador do Cloud Storage.

    Abrir o navegador do Storage

  2. Clique um bucket para visualizar a página Detalhes do bucket.

  3. Na coluna Acesso público, mantenha o cursor sobre o ícone de ponto de exclamação e clique em Editar acesso.

    Para cada objeto no bucket, verifique se a seguinte permissão está definida:

    • Entidade: usuário
    • Nome: allUsers
    • Acesso: leitor

Para saber mais sobre o controle de acesso do Cloud Storage, consulte a documentação de gerenciamento de identidade e acesso (IAM) do Cloud Storage.

Para saber mais sobre URLs assinados, consulte Como usar URLs assinados.

Se os objetos estiverem acessíveis, mas não estiverem em cache, consulte As respostas não estão sendo armazenadas em cache.

O conteúdo privado foi armazenado em cache ou está incorreto

Se você souber porque o servidor de origem veiculou conteúdo particular ou incorreto e se puder corrigir o problema, será possível invalidar os caches do Cloud CDN usando o seguinte processo:

  1. Garanta que o servidor de origem não retorne mais o conteúdo particular ou incorreto.
  2. Solicite uma invalidação de cache para instruir o Cloud CDN a parar de disponibilizar o conteúdo armazenado em cache.

Para mais informações, consulte a Visão geral da invalidação de cache.

O Cloud CDN armazena em cache somente as respostas com conteúdo que pode ser armazenado em cache e exibe respostas do cache apenas até o prazo de validade especificado nelas. Se você não souber por que o conteúdo foi armazenado em cache ou não conseguir corrigir o problema adequadamente, desative o Cloud CDN até conseguir entender e corrigir o problema. Depois, ative-o novamente. Para ver mais informações sobre qual conteúdo é armazenado em cache e por quanto tempo, consulte a Visão geral do armazenamento em cache.

A proporção de ocorrência em cache está baixa

Para desempenho e escalonabilidade, é importante otimizar as proporções de ocorrência em cache. Se você estiver com proporções menores de ocorrências em cache, verifique se está seguindo as práticas recomendadas para otimizar a proporção de ocorrência em cache.

Use a tabela a seguir para entender alguns dos possíveis motivos de uma proporção de ocorrência em cache baixa e as possíveis correções.

Motivos Comentários Correções
Seu conteúdo não pode ser armazenado em cache. Uma resposta armazenável em cache é uma resposta HTTP que o Cloud CDN pode armazenar. Verifique se o conteúdo é armazenável em cache.
O modo de cache não é o ideal para seu aplicativo. O Cloud CDN tem vários modos de cache. Se você não estiver usando cabeçalhos de controle de cache, a prática recomendada é permitir que o Cloud CDN armazene todo o conteúdo estático em cache.
O trânsito está pequeno. Durante os testes e experimentos, o volume de tráfego que você está gerando provavelmente será baixo. O Google tem um cache distribuído globalmente, e as solicitações de diferentes locais geográficos são direcionadas a diferentes locais de front-end do Google. Em cada local de front-end, o Google pode ter várias instâncias distintas do cache.
  • Verifique se o volume de tráfego suficiente está sendo enviado ao Google para preencher todos os caches relevantes.
  • Durante o teste, lembre-se de fragmentar o tráfego por URL para que todo o tráfego para cada conjunto de solicitações vá para o Google. Não fragmente aleatoriamente cada solicitação para um provedor de CDN diferente.
As respostas para URLs específicos não são armazenadas em cache. O Cloud CDN incorpora o URI de solicitação completo nas chaves de cache. Portanto, http://example.com/cat.jpg?color=orange e http://example.com/cat.jpg?color=gray têm entradas de cache separadas. Sempre use um único URL para um determinado recurso.

Se você precisar transmitir parâmetros para o JavaScript em execução em uma página armazenável em cache, use identificadores de fragmentos em vez de strings de consulta.
O cache é fragmentado desnecessariamente devido ao campo de cabeçalho Vary. O campo de cabeçalho Vary em uma resposta descreve quais partes de uma mensagem de solicitação (além do método, o campo de cabeçalho Host e o destino da solicitação), podem influenciar o processo do servidor de origem ao selecionar e representar uma resposta. Como exemplo, use o cabeçalho Vary: Accept-Encoding se você veicular conteúdo diferente para clientes que podem processar respostas compactadas e aqueles que não podem. Use o cabeçalho de resposta Vary somente quando necessário.
Você não está usando chaves de cache personalizadas. Por padrão, o Cloud CDN usa o URL de solicitação completo para criar a chave de cache. É possível personalizar as chaves de cache para incluir ou omitir qualquer combinação de protocolo, host e string de consulta. Por exemplo, se dois domínios usam o mesmo conteúdo estático, você pode criar uma chave de cache personalizada que omita o campo de host. Use chaves de cache personalizadas, quando necessário.

Há vários preenchimentos de cache para o mesmo conteúdo

Em geral, você pode reduzir o número de preenchimentos de cache modificando as datas de expiração das suas respostas armazenáveis. Como todo o restante é igual, você verá menos preenchimentos de cache para uma resposta com Cache-Control: public, max-age=86400 do que uma com Cache-Control: public, max-age=1.

Para mais informações sobre os prazos de validade, consulte Prazos de validade e solicitações de validação. Para mais informações sobre como configurar os cabeçalhos de resposta adequados, consulte a documentação do software do seu servidor da Web.

O Cloud CDN opera vários caches em todo o mundo, e entradas de cache antigas são removidas periodicamente para liberar espaço para novos conteúdos. Consequentemente, vários preenchimentos de cache por recurso são esperados como parte da operação normal.

A compressão não funciona

O Cloud CDN oferece a compactação dinâmica para origens que não podem compactar as respostas. Sempre que possível, recomendamos que você use a compactação na origem, já que ela reduz os custos de preenchimento de cache.

Se as respostas veiculadas pelo Cloud CDN não forem compactadas conforme o necessário, confirme se o software servidor da Web em execução nas suas instâncias está configurado para compactar respostas. Por padrão, alguns softwares servidores da Web desativam automaticamente a compactação para solicitações que incluem um cabeçalho Via. A presença de um cabeçalho Via indica que a solicitação foi encaminhada por um proxy. Proxies HTTP, como o balanceador de carga de aplicativo externo, adicionam um Via para cada solicitação como exigido pela especificação HTTP. Para ativar a compactação, talvez seja necessário substituir a configuração padrão do servidor da Web para que ele compacte as respostas mesmo que a solicitação tenha um cabeçalho Via.

Se você estiver usando o software servidor da Web nginx, modifique o arquivo de configuração nginx.conf para ativar a compactação. O local desse arquivo depende de onde o nginx está instalado. Em muitas distribuições Linux, o arquivo é armazenado em /etc/nginx/nginx.conf.

Para permitir que a compactação nginx funcione com seu balanceador de carga de aplicativo externo, adicione as duas linhas a seguir à seção http do nginx.conf:

gzip_proxied any;
gzip_vary on;

  • A primeira linha ativa a compactação até mesmo para solicitações encaminhadas por um proxy como o balanceador de carga de aplicativo externo.

  • A segunda linha adiciona um cabeçalho Vary: Accept-Encoding às respostas. O cabeçalho Vary: Accept-Encoding notifica aos proxies de armazenamento em cache, como o Cloud CDN, que eles precisam manter as entradas de cache das variantes compactadas e não compactadas separadas dos recursos compactáveis.

Após modificar o nginx.conf, você precisará reiniciar o nginx antes que ele use a nova configuração. Em muitas distribuições Linux, é possível reiniciar o nginx executando sudo service nginx restart ou /etc/init.d/nginx restart.

As respostas são encerradas com erros byte_range_caching_aborted

Quando o Cloud CDN agrupa uma resposta de várias solicitações de intervalo de bytes, ele verifica se esses intervalos são da mesma versão do recurso por meio da comparação entre os cabeçalhos de resposta ETag e Last-Modified. Se o Cloud CDN constatar que o valor de um dos cabeçalhos é inconsistente com os intervalos que ele já veiculou ao cliente, ele abortará a resposta.

Caso você observe respostas encerradas inesperadamente, entradas de registro do Cloud Logging com statusDetails byte_range_caching_aborted ou instâncias retornando respostas 412 Precondition Failed, certifique-se de que o software servidor da Web em execução em todas as instâncias de máquina virtual (VM) retorne os mesmos valores de ETag e Last-Modified do recurso em questão.

Ao veicular arquivos a partir do disco, é comum que o software servidor da Web derive os valores ETag e Last-Modified do horário de modificação do arquivo. Nesse caso, você pode garantir que suas instâncias de VM relatem valores consistentes usando a mesma imagem para todas as instâncias. Para mais detalhes sobre como o software servidor da Web determina os valores ETag e Last-Modified, consulte a documentação do software.

Solução de problemas de cookies assinados

Os seguintes problemas podem ocorrer quando você usa cookies assinados.

Codificação

Ao gerar uma assinatura, a solicitação é rejeitada inesperadamente devido a uma incompatibilidade de assinatura.

Ao codificar os valores URL e Signature, verifique se você está usando a variante segura para URL de base64. A Base64 padrão falha quando os caracteres gerados não são seguros para URL. O padding é aceito.

Assinatura

Sua solicitação é rejeitada pelo Cloud CDN.

  • Verifique se você está usando HMAC-SHA-1 como algoritmo de assinatura, e não outra variante do HMAC.

  • Confirme se o parâmetro KeyName (que diferencia maiúsculas de minúsculas) corresponde a um nome de chave válido para o serviço ou bucket de back-end em uso pelo Cloud CDN.

  • Não assine parâmetros de consulta ao gerar e assinar um URLPrefix. Verifique se URLPrefix contém apenas o esquema, o host e os componentes do caminho (parcial) do URL.

  • Verifique se o bloco de assinatura (URLPrefix, Expires, KeyName e Signature) são as últimas seções delimitadas por : do cookie.

  • Verifique se URLPrefix, Expires, KeyName e Signature ocorrem nesta ordem.

  • Não inclua um caractere asterisco (*) no final de um URLPrefix em um cookie assinado.

Cookies

  • Os navegadores normalmente limitam cookies a 4 KB por domínio, com um limite de 50 cookies por domínio no total. Anote os outros cookies que você está emitindo e exigindo que seus clientes enviem porque muitos servidores da Web também têm limites máximos de cabeçalho de solicitação.

  • Verifique se você está usando o caractere de dois-pontos (:) ou ponto de código Unicode U+003A, como o delimitador dos parâmetros nomeados em um cookie assinado, e não o caractere "e" comercial (&).

  • Verifique se o carimbo de data/hora Expires nos cookies que você está representando não é muito curto. Períodos de validade de menos de um a dois minutos podem ser propensos a distorções de relógio entre o app emissor e a infraestrutura do Cloud CDN.

  • Verifique se você não está configurando vários cookies para os mesmos Domain e Path com valores diferentes. Defina apenas um cookie por usuário com um valor de prefixo de URL que inclua todo o conteúdo que o usuário precisa acessar.

Mensagens de erro

Esta seção fornece informações sobre algumas mensagens de erro comuns e como resolvê-las.

Erros de invalidação de cache

Código do erro Observações
Invalid value for field 'resource.path'

O valor do caminho tinha um formato inválido. Os caminhos precisam começar com /, não podem conter ? ou # e precisam ter apenas um * como caractere final após uma /.

Além disso, eles não podem ter mais de 1.024 caracteres. Se você receber esse erro, verifique o valor do caminho e corrija quaisquer erros de formatação.

Este erro aborda somente o formato do caminho. Um caminho com formato válido, mas que não existe, ainda é considerado válido.
Rate Limit Exceeded O Cloud CDN restringe a frequência das operações de invalidação de cache. Somente uma invalidação por minuto é permitida. Porém, cada operação pode especificar um padrão de caminho que corresponda a qualquer número de objetos.

Problemas conhecidos

  • As invalidações de cache têm limitação de taxa a uma invalidação por mapa de URL por minuto.

    Resolução: aguarde pelo menos um minuto antes de tentar invalidar outro mapa de URL.

    Para mais informações sobre a limitação da taxa de invalidação de cache, consulte Limitações.