Troubleshooting

Contents

Common problems and solutions

Responses aren't being cached

If responses aren't being cached, first check that Google Cloud CDN is enabled for your backend service. When you enable Cloud CDN for a backend service, it might take a few minutes before responses begin being cached.

Cloud CDN caches only responses that are marked public and specify an expiration time or maximum age. This information is conveyed in HTTP response headers. If responses for a URL aren't being cached, check which HTTP headers are being returned for that URL.

There are a number of ways to check response headers:

The following example demonstrates using curl to check the HTTP response headers for 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

$

Comparing these headers with the requirements in Caching Details reveals the response is missing the required Cache-Control header. Consult the documentation for your web server software for details on adding response headers.

After reconfiguring the web server to add the required header, curl can be used again to check the result:

$ 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

$

The last response in this example includes an Age header. Cloud CDN adds an Age header to responses it serves from cache. Here, the header indicates the response was successfully served from cache using a cache entry that was created 2 seconds ago.

Private content was cached, or cached content is incorrect

If you know why your virtual machine instances or buckets served the private or incorrect content and you can fix the problem, you can invalidate Cloud CDN caches using the following process:

  1. Ensure the web server software running on your instances will no longer return the private or incorrect content.
  2. Request a cache invalidation to instruct Cloud CDN to stop serving the incorrect content.

For more information, read the cache invalidation page.

Cloud CDN will cache only responses that are marked publicly cacheable and will serve responses from cache only up to the expiration time specified in the response. If you do not know why the content was cached or cannot fix the problem expediently, you might want to disable Cloud CDN until you can understand and fix the problem, then re-enable it. For more information on what content is cached and for how long, refer to Caching Details.

Cache hit rate is low, or multiple cache fills for the same content

If you're experiencing lower than expected cache hit rates for your backend services, make sure responses for the URLs of interest are being cached.

Cloud CDN incorporates the full request URI into its cache keys, so http://example.com/cat.jpg?1 and http://example.com/cat.jpg?2 will have separate cache entries. You can improve cache hit rates by always using a single URL for a given resource. If you need to pass parameters to JavaScript running on an otherwise cacheable page, consider using fragment identifiers instead of query strings. Additionally, you can improve cache hit rates by using the Vary response header only when necessary. Caching Details has more information on cache keys.

In general, you can reduce the number of cache fills by increasing the expiration times of your cacheable responses. Everything else being the same, you'll see fewer cache fills for a response with Cache-Control: public, max-age=86400 than one with Cache-Control: public, max-age=1. See Caching Details for information on expiration times and the documentation for your web server software for details on configuring the appropriate response headers. Note, though, that Cloud CDN operates numerous caches around the world, and old cache entries are routinely evicted to make room for new content. As a result, multiple cache fills per resource are expected as part of normal operation.

Compression isn't working

Cloud CDN does not compress or decompress responses itself, but it can serve compressed responses generated by your backend service.

If responses served by Cloud CDN are not compressed but should be, check that the web server software running on your instances is configured to compress responses. By default, some web server software will automatically disable compression for requests that include a Via header. The presence of a Via header indicates the request was forwarded by a proxy. HTTP proxies such as HTTP(S) load balancing add a Via header to each request as required by the HTTP specification. To enable compression, you may have to override your web server's default configuration to tell it to compress responses even if the request had a Via header.

If you are using the nginx web server software, modify the nginx.conf configuration file to enable compression. The location of this file depends on where nginx is installed. In many Linux distributions, the file is stored at /etc/nginx/nginx.conf. To allow nginx compression to work with HTTP(S) load balancing, add the following two lines to the http section of nginx.conf:

gzip_proxied any;
gzip_vary on;

The first line enables compression even for requests forwarded by a proxy like HTTP(S) load balancing. The second line adds a Vary: Accept-Encoding header to responses. Vary: Accept-Encoding notifies caching proxies such as Cloud CDN that they should maintain separate cache entries for compressed and non-compressed variants of compressible resources.

After modifying nginx.conf, you need to restart nginx before it will use the new configuration. In many Linux distributions, nginx can be restarted by running sudo service nginx restart or /etc/init.d/nginx restart.

Known issues

The following known issues and limitations affect Cloud CDN:

  • Responses with bodies larger than 10 MB (10,485,760 bytes) are not cached.
  • Cache invalidations are rate limited to one invalidation per URL map per minute.

Error codes

Cache Invalidation Errors
Error Code Notes
Invalid value for field 'resource.path' The path value had an invalid format. Paths must begin with a /, must not contain a ? or #, and must have only a single *, which must be a final character after a /. Paths must not be longer than 1024 characters.
(This error only addresses the format of the path. A path that is of valid format, but which doesn't exist, is still treated as valid.)
Rate Limit Exceeded Cloud CDN restricts the number of cache invalidation operations in progress at a time. Only one invalidation per minute is allowed. However, each operation can specify a path pattern that matches any number of objects.

Monitor your resources on the go

Get the Google Cloud Console app to help you manage your projects.

Send feedback about...

Cloud CDN Documentation