Learn about troubleshooting steps that you might find helpful if you run into the following problems using Cloud CDN.
Common problems and solutions
Responses aren't being cached
If responses aren't being cached, first check that Cloud CDN is enabled for your backend service or backend bucket. When you enable Cloud CDN, it might take a few minutes before responses begin to be 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 headers are being returned for that URL.
There are a number of ways to check response headers:
- In Google Chrome, the DevTools network panel
- In Mozilla Firefox, the Developer Tools Network Monitor
- A command-line tool such as curl or GNU Wget
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 method for setting headers depends on the type of origin server. If you're running a web server on Google Compute Engine, consult the web server software's documentation for details on configuring response headers. For Google Cloud Storage, marking the object as shared publicly will cause the appropriate headers to be sent.
After reconfiguring the origin 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 the origin server served the private or incorrect content and you can fix the problem, you can invalidate Cloud CDN caches using the following process:
- Ensure that the origin server will no longer return the private or incorrect content.
- Request a cache invalidation to instruct Cloud CDN to stop serving the cached 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 or backend buckets, 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
otherwise cacheable page, consider using
Additionally, you can improve cache hit rates by using the
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
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
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
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
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
Responses terminate with byte_range_caching_aborted errors
When Cloud CDN assembles a response from multiple byte range requests, it checks whether those ranges are from the same version of the resource by comparing ETag and Last-Modified response headers. If Cloud CDN finds that the value of either header is inconsistent with ranges it has already served to the client, it will abort the response.
If you notice unexpected terminated responses, Stackdriver Logging log entries with
byte_range_caching_aborted statusDetails, or your instances returning
412 Precondition Failed responses, ensure that the web server software running
on all your VM instances returns the same ETag and Last-Modified values for a
When serving files from disk, it's common for web server software to derive the ETag and Last-Modified values from the file's modification time. In this case, you can ensure your VM instances report consistent values by using the same image for all instances. Consult the documentation for your web server software for details on how it determines ETag and Last-Modified values.
|Cache Invalidation Errors|
||The path value had an invalid format. Paths must begin with a
(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.)
||Cloud CDN restricts the rate at which cache invalidation operations can be performed. Only one invalidation per minute is allowed. However, each operation can specify a path pattern that matches any number of objects.|
The following known issues and limitations affect Cloud CDN:
- Cache invalidations are rate limited to one invalidation per URL map per minute.