Deciphering Fastly-Debug header

You can send a Fastly-Debug: 1 header to cause us to not strip headers that we would normally strip, which can be helpful in debugging situations.

You’ll get an output like the following:

Fastly-Debug-Path: (D cache-lcy1128-LCY 1415969775) (F cache-lcy1130-LCY 1415969775) (D cache-sjc3132-SJC 1415969775) (F cache-sjc3128-SJC 1415969775)
Fastly-Debug-TTL: (M cache-lcy1128-LCY - - 0) (M cache-sjc3132-SJC - - 0)
X-Served-By: cache-sjc3132-SJC, cache-lcy1128-LCY
X-Cache: MISS, MISS, MISS
X-Cache-Hits: 0, 0

Please Note: the X-Served-By, X-Cache, and X-Cache-Hits headers are not stripped normally

Overview of Headers

The Fastly-Debug Path contains information about which nodes handled fetching and delivery of an object, as well as object TTL information (Edge PoP will appear first in the sequence, Shield PoP second)

• D: refers to which node in the edge or shield ran vcl_deliver
• F: refers to which node in the edge or shield ran vcl_fetch
• H: refers to a HIT, meaning the object was found in the cache
• M: refers to a MISS, meaning the object was not cached at the time of the query
• The number following specific server name is a time stamp in seconds

Fastly-Debug-TTL: provides information on various timings. In the following example,
Fastly-Debug-TTL: H cache-jfk1026-JFK 41733294.335 864000.000 2273

• the first number is the TTL remaining for the object
• the second number refers to the grace
• the third number is current age of the item in cache

Please Note: it may take a few requests to see these numbers populate as expected, as the request needs to either hit the cluster node, or a node where the content exists in temporary memory

X-Served-By: indicates the Shield, Edge servers that were queried for the request (Shield PoP will appear first in the sequence, Edge PoP second)

X-Cache: indicates whether it was a hit or a miss for the datacenter

(For further information on these two headers, please see https://docs.fastly.com/guides/performance-tuning/understanding-cache-hit-and-miss-headers-with-shielded-services)

Explanation of Request Flow

The reason you might see two nodes in both the edge and/or shield datacenter queried is because of clustering in Varnish. With inter-datacenter shielding enabled, you should generally see 4 cache servers listed in this header. In rarer cases where a server is both an edge and a shield within the cluster for that object, you may see 2 or 3 caches listed.

With clustering, there will be two nodes “responsible” for an object. These cluster nodes are determined via the result of vcl_hash subroutine in VCL. The edge node that receives the request will run vcl_recv and vcl_deliver, while it may proxy the request to the cluster node to run vcl_miss,vcl_hit,vcl_fetch. Depending on several factors, the object may be cached on only the cluster node or it may be cached on both the edge node and cluster node within a PoP.