Solução de problemas

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 origens personalizadas, consulte também a Solução de problemas de origem personalizada e NEG da Internet.

Problemas gerais e soluções

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 respostas marcadas como públicas e que especificam a data de expiração ou a idade máxima. Essa informação é fornecida nos cabeçalhos de respostas HTTP. Se as respostas para um URL não estiverem sendo armazenadas em cache, confirme quais cabeçalhos HTTP estão sendo retornados para esse URL.

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

Saída:

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.

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

Saída:

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

Saída:

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

Saída:

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 (em inglês) estiverem ativadas nas instâncias de back-end, o Cloud CDN 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 ETag:

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

Saída:

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

Saída:

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

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 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, passe 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 armazenará em cache somente respostas marcadas como armazenáveis publicamente e veiculará 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é entender e corrigir o problema e depois reative-o. Para mais informações sobre qual conteúdo é armazenado em cache e por quanto tempo, consulte a Visão geral de armazenamento em cache.

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

Se você estiver com proporções de ocorrência em cache inferiores ao esperado para seus serviços ou buckets de back-end, certifique-se de que as respostas para os URLs de interesse estejam sendo armazenadas em cache.

O Cloud CDN incorpora o URI de solicitação completo nas chaves de cache. Portanto, http://example.com/cat.jpg?1 e http://example.com/cat.jpg?2 têm entradas de cache separadas. É possível melhorar as proporções de ocorrência em cache usando sempre um URL apenas para 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.

Além disso, é possível melhorar as proporções de ocorrência em cache usando o cabeçalho de resposta Vary somente quando necessário. Para mais informações, consulte Chaves de cache.

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

Em geral, é possível reduzir o número de preenchimentos de cache aumentando os períodos de validade das 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 não compacta nem descompacta respostas, mas pode veicular respostas geradas pelo servidor de origem que são compactadas usando codificações como gzip e DEFLATE (links em inglês).

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. Os proxies HTTP, como o balanceamento de carga HTTP(S), adicionam um cabeçalho Via a cada solicitação, conforme exigido pela especificação HTTP (em inglês). 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 o balanceamento de carga HTTP(S), adicione as duas linhas a seguir à seção http do arquivo 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 balanceamento de carga HTTP(S).

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

Encoding

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

Erros de invalidação de cache

Código do erro Notas
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 *, que tem de ser caractere final após uma /.

Os caminhos 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

Os seguintes problemas e limitações conhecidos afetam o Cloud CDN:

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