Checking cache
Last updated 2022-05-06
Checking the cache status of an object on your website can help when troubleshooting problems. You can use the web interface or the curl command (an open-source command line tool for transferring data with URL syntax from or to a server using one of many supported protocols) to check Fastly's cache nodes for a cached object, and you can use the information provided to examine the object's status, response time, and content hash.
Using the web interface
Follow the steps below to check the cache status of an object using the Fastly web interface:
- Log in to the Fastly web interface.
- From the Home page, select the appropriate service. You can use the search box to search by ID, name, or domain.
Click the Check Cache button. The Check Cache window appears.
In the Full URL path field, enter the full path to the object (e.g.,
http://www.example.com/object.html
).Click the Check Cache button. The results are displayed in the Check Cache window.
You can use this information to verify that the same copy of an object is stored on all of our servers. If the content hash is different across nodes, that usually indicates that there's a caching problem.
Using curl
The easiest way to tell if your request is caching in the Fastly network is to use the check cache feature in the Fastly web interface, but if you prefer command line utilities, you can also use one of two curl commands for debugging purposes:
- a simple curl command that displays the request and response headers for a given object
- a slightly more complex curl command that uses the
Fastly-Debug
header to expose information normally stripped by the simple curl
Using the simple curl command
The following curl command displays the request and response headers for a given object:
$ curl -svo /dev/null www.example.com/index.html
where www.example.com/index.html
is replaced with the full object path of the object you're testing.
For example, using curl -svo /dev/null www.example.com
produces something like the following section of output:
1[...]2
3< Age: 1424< X-Served-By: cache-jfk1041-JFK, cache-ord1720-ORD5< X-Cache: HIT, HIT6< X-Cache-Hits: 1, 77
8[...]
This output tells us the current age of the object in cache. It also shows shielding is enabled because two cache nodes display in X-Served-By
. However, we're most interested in the output of the X-Cache
header. A properly caching object displays a value of X-Cache: HIT
, X-Cache: HIT, HIT
, X-Cache: HIT, MISS
, or X-Cache: MISS, HIT
.
Using a Fastly-Debug header with curl
The Fastly-Debug
header provides additional information for debugging by exposing specific information that is normally stripped when using a simple curl command:
$ curl -svo /dev/null -H "Fastly-Debug:1" www.example.com/index.html
where www.example.com/index.html
is replaced with the full object path of the object you're testing.
For example, with optional shielding being used and a TTL set to 86400 (24 hours) using Surrogate-Control
, the command curl -svo /dev/null -H "Fastly-Debug:1" www.example.com
produces something like the following section of output:
1[...]2
3< Surrogate-Control: max-age=864004< Surrogate-Key: articles articles/1 articles/25
6[...]7< Age: 4038< Fastly-Debug-Path: (D cache-ord1722-ORD 1470672957) (F cache-ord1743-ORD 1470672629) (D cache-jfk1041-JFK 1470672629) (F cache-jfk1030-JFK 1470672554)9< Fastly-Debug-TTL: (H cache-ord1722-ORD 85997.246 0.000 403) (H cache-jfk1041-JFK - - 75)10< X-Served-By: cache-jfk1041-JFK, cache-ord1722-ORD11< X-Cache: HIT, HIT12< X-Cache-Hits: 1, 613
14[...]
Because surrogate keys are present, the Fastly-Debug
header exposes them. As with the simple curl command, this section of output tells us the current age of the object in cache. In addition, Fastly-Debug
exposes specific header details to help with debugging as noted below.
Information exposed by the Fastly-Debug header
Fastly-Debug Path
contains information about which cache server handles fetching and delivery of an object. The edge POP appears first in the sequence and the shield POP appears second.
D
represents which cache by name in the edge or shield ranvcl_deliver
F
represents which cache by name in the edge or shield ranvcl_fetch
- the number following each specific server name is a timestamp in seconds
With shielding enabled, you should generally see four cache servers listed in this header. In rare cases where a cache server exists as both an edge and a shield within the cluster for that object, you may see two or three caches listed.
Fastly-Debug-TTL
provides information on HIT and MISS timings.
H
represents a HIT, meaning the object was found in the cacheM
represents a MISS, meaning the object was not cached at the time of the query
For each of these timings:
- the first number specifies the TTL remaining for the object
- the second number specifies the grace period
- the third number specifies the current age of the object in cache
It may take a few requests to see these numbers populate as expected because they need to either hit the cluster node or a node where the content already exists in temporary memory.
X-Served-By
indicates the shield and edge servers that were queried for the request. The shield POP appears first in the sequence and the edge POP appears second.
X-Cache
indicates whether the request was a HIT or a MISS for the data center.
NOTE
Our shielding debugging documentation provides in depth details key to understanding the X-Served-By
, X-Cache
, and X-Cache-Hits
headers with shielded services.
Do not use this form to send sensitive information. If you need assistance, contact support.