Determining the Cache Status in UltraStack

Caching works in such a way that you may not always think of how it is working when it’s on. This is a good thing since the caching function is part of the UltraStack architecture. This article will cover how to determine your cache status using the cURL command.

Need a new home for your WordPress site? Check out InMotion’s WordPress Hosting solutions for secure, optimized servers that meet your budget needs.

Using Curl to Determine Cache Status

In order to use CURL, you will need to be logged into your site using SSH.

In the result below, you would basically be using the command like:

curl -is https://example.com/ -A "Troubleshooting" | head -14 
HTTP/1.1 200 OK
Server: nginx/1.13.3
Date: Fri, 21 Jul 2017 16:18:39 GMT
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
Connection: keep-alive
Vary: Accept-Encoding
Link: <https://example.com/wp-json/>; rel="https://api.w.org/", <https://example.com/>; rel=shortlink
X-Proxy-Cache: HIT

Cache Status Codes

Below is a list of possible values for the X-Proxy-Cache header, and a description of what they mean.

  • - (X-Proxy-Cache header is empty or missing) – No caching configured for this URI, or the page was requested via a method other than GET, HEAD, or OPTIONS. This means that POST requests will always bypass the cache.
  • HITCache Hit – Nginx found a matching fresh page in the cache and returned it to the visitor.
  • MISSCache Miss – No matching fresh page was found in the cache. Nginx made a request to the origin (Apache, PHP-FPM), then cached the resulting page for subsequent requests.
  • EXPIREDCache Expired – Nginx tried to retrieve an updated page from the origin (Apache, PHP-FPM), but encountered an error, so instead it served an expired page from the cache.
  • UPDATINGCache Updating – Nginx is currently waiting for a response from the origin to update the cache (from a previous request). In the meantime, Nginx served the visitor the existing (expired) page from the cache. This behavior can be controlled via the cache_lock_enable option (enabled by default).
  • BYPASSCache Bypass – This page was forwarded directly from the origin without caching due to explicitly defined exclusion rules that the customer has configured (or that are a part of the default configuration). Specific paths can be configured via the cache_bypass_paths option. Other options, such as bypass_cookies, also influence whether or not the request bypassed the cache.
  • STATIC/TYPEStatic Content (by type) – This asset was served directly by Nginx due to matching the file extension of the request URL with a predefined list in the template. This is enabled or disabled via the accel_static_content option.
  • STATIC/PATHStatic Content (by path) – This asset was served directly by Nginx due to matching the URI with a list defined by the customer (or part of the default configuration). This is configured with the static_content_paths option.

Congratulations, you now know how to find out the cache status using the CURL command in SSH. To learn more, see our other UltraStack tutorials.

Was this article helpful? Let us know!