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.
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
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.
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.
Review and modify the rule in the OVHcloud panel 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 Once the rule is changed, purge the CDN once more.
Test with a “clean” file 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.
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.
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 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.