The website works from cache. How do you check the origin server?

Save the headers and the context of a successful test

For a read-only URL, run curl -sS -D - -o /dev/null https://example.com/, replacing the domain with your own. The command displays headers and discards the body; check the content separately. Record the time, URL, status and Cache-Control. Age estimates the time since the response was generated or successfully validated at the origin. It is not the content's last modification date. Missing Age does not prove origin contact either.

Include the provider's diagnostic headers. With Cloudflare, CF-Cache-Status: HIT means the resource was found in its cache. Check other headers against the documentation for the layer in use. Sketch the request's route through the CDN, proxy and application. Do not infer every layer's condition from one cache's response, and attach the measurement location to each result.

Distinguish a stored response from a current result

The stale-if-error extension allows a cache, under the relevant conditions, to use a response past its freshness lifetime when an error occurs. Actual behaviour depends on support and configuration. This protection can preserve a visitor's access to content. During diagnosis, ask a different question: can the origin now generate the response needed for the failing feature? Successfully displaying a stored article does not check that.

A random URL parameter is not a universal bypass. Cloudflare, for example, can exclude the query string from its cache key. Check the actual rules. In a response's Cache-Control, no-cache without arguments requires validation before reuse; no-store prohibits storage. Keep those meanings distinct. A diagnostic URL's name or an added timestamp alone does not establish that you reached the application.

Keep the hostname and TLS verification in a direct test

If you know the correct origin address and have access, an HTTPS example is curl --noproxy '*' --resolve example.com:443:192.0.2.10 https://example.com/. Replace both the domain and illustrative IP with your own values. --resolve changes the address for that hostname and port while retaining the URL name for SNI and certificate verification. --noproxy '*' disables the proxy configured for curl.

This test distinguishes a specific direct route from the public route through the CDN; it is not a complete infrastructure test. Before comparing results, check the origin's protocol and authentication. For a protected origin, measure from an authorised internal location and preserve access rules. Assess certificate errors against the expected TLS configuration. Keep certificate verification enabled so the HTTPS test retains its meaning.

Make monitoring check both routes

For a recurring origin check, prepare a read-only route with verified cache bypass at each relevant layer. With NGINX, distinguish proxy_cache_bypass, which determines whether to use a stored response, from proxy_no_cache, which determines whether to store a new one. Confirm the configuration's intent with a request record at the origin too. A successful check without that verification does not yet explain what the monitor measures.

Keep the public check through the CDN because it follows the visitor's route. Track the origin result separately, comparing time, errors and expected content. After repair, repeat the dynamic operation that failed and verify that a new response reaches the normal route. This establishes whether the application has recovered and whether the client receives the correct result through cache as well.

• Save the URL, time, status and cache headers.
• Check the cache key, freshness and bypass rules.
• Test the origin over the correct route with its hostname preserved.
• Compare the origin, public route and original operation.