CDN not caching my files (x-cdn-cache: MISS)

Hello,

I'm trying to use caching on one of my websites; I followed the guide https://docs.ovhcloud.com/fr/guides/web-cloud/web-hosting/cdn-how-to-use-cdn, but it doesn't work—I still see x-cdn-cache: MISS in the headers and the CDN log analysis confirms it.

Details:

  • a static website
  • CDN enabled with rules for CSS and JS (40 min) and JPG (20 min)
  • a .htaccess file used for testing
<FilesMatch "\.jpg$">
Header set Cache-Control "max-age=1200, public"
</FilesMatch>

<FilesMatch "\.css$">
Header set Cache-Control "max-age=2400, public"
</FilesMatch>

This is indeed being applied, as I see those values in the response headers.

In Firefox with the web developer tools, here are the response headers I see on a .css file:

Cache-Control: 	max-age=2400
content-type: text/css
date: Wed, 30 Sep 2026 09:47:40 GMT
last-modified: Mon, 28 Sep 2026 14:44:16 GMT
X-CDN-Cache: MISS
X-CDN-Pop: sbg

And I have max-age=1200 on a .jpg.

I've been circling this problem for a while without understanding what's wrong.

Does anyone have an idea of what I missed?

In fact it seems more complicated than I thought: for the same request (e.g., a CSS file) I sometimes get HITs and sometimes MISSes. With consecutive requests in a short time span (a few minutes)

Is there an explanation for this? Is the CDN having problems?

The main cause of the intermittency is the distributed nature of the CDN. OVHcloud has multiple Points of Presence and servers worldwide. When a user makes a request, they are directed to the nearest PoP. The first time a PoP requests a resource, it fetches it from your origin server and stores it in its local cache (that is the MISS). Subsequent requests to the same PoP will be served from its cache (the HIT).

You have configured a Cache-Control: max-age=2400 for CSS in your .htaccess. So when the origin sends cache headers, the CDN respects them and does not blindly apply the manager's rules. In other words, the TTL of 2400 seconds you set in your .htaccess is the one that takes precedence, not the 40‑minute value you might have configured in the panel.

What matters is not that every individual request yields a HIT, but that the overall hit rate is high over time. If you see that most repeated requests return HIT, the CDN is functioning correctly.

Hope I helped you,
Sergio Turpín

In this case I always run my tests from the same IP, so I have to hit the same PoP each time.

If it’s the max-age provided by the server that is taken into account, what is the purpose of the one set in the CDN rules in the OVN admin—only for cleaning (purge) of the CDN?

Regarding the 2400, I corrected it already 1–2 hours ago to set it to 86400 (1 day), but the headers still show 2400. When does it get updated?

The general rule is that if your origin server sends a Cache‑Control header, the CDN respects it and uses it as the primary source. In other words, your .htaccess has the final word on the TTL.

The .css file you are requesting has already been cached by the OVHcloud PoP with the 2400‑second value you had before. While that TTL has not expired, the CDN will continue serving you the old copy with the old headers. Your change in the .htaccess does not affect what is already in the CDN’s cache.

To see the new value of 86400, you need to force the purge of that specific cache for that file.

Once the cache is purged, the next request for that .css will go to your origin server, pick up the new max-age=86400 and the CDN will store that new version with the updated TTL. From then on, you will see the correct value :slightly_smiling_face:

So don’t worry @TechS your configuration is correct, you just need to purge the cache so the header changes are reflected in the CDN.

Hope I helped you,
Sergio Turpín

I purged the CDN and waited longer than the 2400 seconds, and the problem persists.

If you tell me that everything is OK, I’ll believe it, but I like deterministic results, and these waiting times without knowing why or when it will be resolved are neither pleasant nor practical.

Have you checked this page? :backhand_index_pointing_down:

https://docs.ovhcloud.com/en/guides/web-cloud/web-hosting/cdn-how-to-use-cdn

Additionally, let’s run the following test:

  • Review and modify the rule in the OVHcloud panel :right_arrow: Go to Multisite > ... > Configure CDN. Find the rule you created for the CSS files. Change its TTL duration to 86400 seconds directly in the panel.
  • Purge the cache again :right_arrow: Once the rule is changed, purge the CDN once more.
  • Test with a “clean” file :right_arrow: To avoid any residual browser cache, rename a test CSS file (for example, styles.css to styles-v2.css). Since it’s a new name, neither the CDN nor your browser has a previous copy. When requested, a new cache entry should be generated with the TTL you defined.

If after this the new file still shows an old TTL, then we’re dealing with a deeper inconsistency in the platform.

Let me know, best regards.
Sergio Turpín

Yes, I have generally followed this documentation correctly.

Following your advice, I have

  • checked that the rule for CSS is set to 1 day, which is the equivalent of the 86 400 seconds indicated in my .htaccess
  • purged the CDN cache on this site
  • added a style2.css file that didn’t exist before
  • run a curl request to avoid potential browser‑cache effects; here’s what I got
curl -i https://my.domain.tld/style2.css
HTTP/2 200
date: Thu, 01 Oct 2026 08:33:27 GMT
content-type: text/css
last-modified: Thu, 01 Oct 2026 08:33:22 GMT
cache-control: max-age=2400
age: 0
x-cdn-cache: MISS
x-cdn-request-id: 377782468
x-cdn-pop: rbx
accept-ranges: bytes
content-length: 288

We indeed see max‑age=2400 whereas my .htaccess contains

<FilesMatch "\.(js|css)$">
Header set Cache-Control "max-age=86400, public"
</FilesMatch>

Someone will need to explain to me what I’m doing wrong, otherwise I’ll start thinking that OVH’s CDN is completely buggy…

To extend my tests I

  • disabled the CDN
  • re-enabled the CDN: the previous rules were still present
  • sent another request for
    • style.css: max‑age is still the old value
    • style2.css: finally I get 86400!!!
    • again style.css where I still got 2400

I then enabled the CDN’s "dev mode" and after a few requests I got 86400 on style.css and on the jpg files. After disabling this mode, it seems OK.

I'm glad the solution has been found :wink:

Regards @TechS :waving_hand:
Sergio Turpín

There's at least one thing I don't understand: what are the CDN rules we add in the OVH admin interface for?

I just ran tests with a new subdomain on which I enabled the CDN with no rules and added an .htaccess with Cache-Control.

I made several requests and got MISSes as well as HITs!

I really need someone who knows the CDN product very well and can tell me

  • what are the expiration rules that can be inserted? What difference in behavior is there between setting them or not?
  • how does cache expiration work? Is it governed by these rules or only by Cache-Control?
    • e.g.: if I have a max-age of 1 day, and an identical expiration rule (assuming it is useful), if I make a request 25 or 48 hours after the last one, will the cache be invalidated and will it query the server to fetch the latest version?

I'm asking precise questions but I need to know the exact behavior of the CDN, not just what the docs say, so I can use it properly and advise my clients.

Thanks

Hi @TechS

What I can tell you here is that the panel's cache rules determine how frequently the cache is refreshed for specific resources on your site.

Now, what happens when your .htaccess also sends a Cache-Control? If the origin server sends cache headers, the CDN respects them. In practice, this means that the max‑age in your .htaccess takes precedence over the panel rule. The panel rule serves as a default value for files that don’t have their own headers, and also allows you to purge selectively by extension, folder, or URI.

I’m sorry I can’t be more specific :smirking_face: unfortunately I don’t have much expertise in this area. If you have a particular question, I recommend opening a support ticket. There, a specialist technician will be able to help you much better.

How can I create a support ticket?

Click this link to create a support request from the OVHcloud Help Center. Then, log in with your OVHcloud credentials.

Once you’re logged in, click ✉ Tickets on the Ticket creation button. Select the reason for your request and then choose the product and service in question. Next, specify your request to get personalized help suggestions and advice. If this does not meet your needs, click Next to complete your request and create a support ticket. Be sure to provide as much information as possible so our teams can assist you better.

Kind regards,
Sergio Turpín