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-Cacheheader is empty or missing) – No caching configured for this URI, or the page was requested via a method other than
OPTIONS. This means that
POSTrequests will always bypass the cache.
HIT– Cache Hit – Nginx found a matching fresh page in the cache and returned it to the visitor.
MISS– Cache 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.
EXPIRED– Cache 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.
UPDATING– Cache 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_enableoption (enabled by default).
BYPASS– Cache 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_pathsoption. Other options, such as
bypass_cookies, also influence whether or not the request bypassed the cache.
STATIC/TYPE– Static 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
STATIC/PATH– Static 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
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.