You need to log in to the Customer Portal of Leaseweb to access the Multi-CDN Dashboard. If you are logging in for the first time, you may look into this page for more information.
You can access the CDN dashboard via the Leaseweb customer portal. Once you log in, select “CDN” from the side menu to view the CDN overview page.
Check out the below articles for additional information on our Multi-CDN product:
A 404 (Not Found) error indicates that the requested content was not found on the origin server. The CDN does not generate 404 errors on its own; it only forwards them if the origin responds with this status code.
It’s important to differentiate this from other errors like 502 (Bad Gateway) or 504 (Gateway Timeout), which may occur if the CDN is unable to reach the origin due to connectivity issues.
⚠️ After content is uploaded to the origin, there may be a short delay (up to 1 minute) before the CDN stops returning a cached 404 and begins serving the new content. This ensures efficient caching and protects the origin from excessive requests.
HTTP 502 (Bad Gateway) and 504 (Gateway Timeout) errors typically indicate that the CDN edge server was unable to establish a successful connection with the origin server. This can happen due to several reasons:
These errors are not generated by the CDN itself, but are passed through from the origin when it fails to respond properly.
In most case, investigation by Leaseweb support is required. However, before escalating, please provide:
curl command showing the errorThis information is essential for diagnosing the root cause efficiently.
Gzip compression is not supported for MPEG-DASH streaming. This is due to limited compatibility—only one of our four CDN providers currently supports Gzip for streaming content. Enabling it could lead to inconsistent behavior across providers, so it is not recommended.
Some customers request our CDN IP ranges to restrict access to their origin servers and allow only our infrastructure.
For Leaseweb infra/shields:
No. For consistency and reliability, each origin must be configured to use either HTTP or HTTPS exclusively. Mixing both protocols for the same origin configuration is not supported and may lead to unpredictable behavior or connectivity issues.
No. Our CDN automatically selects the optimal PoP based on the end-user’s location and network conditions to ensure the lowest possible latency. Manually specifying a PoP is not supported, as it would interfere with the performance benefits of dynamic routing.
Yes. HTTP/2 is supported by default across all of our CDN providers, making it a standard feature of our platform. No additional configuration is required to enable it.
Yes, but only if the object storage is configured as a simple origin—meaning it does not require any authentication. Authenticated object storage endpoints are not supported within origin groups.
Our Multi-CDN platform is designed to deliver optimal performance by distributing traffic across multiple partner CDNs. As a result, usage data must be collected from each of these partners and then processed before appearing in your dashboard.
This aggregation process can introduce a delay in updating statistics, particularly when there are interoperability issues or delays on the provider side. While we strive to minimize this delay, it may occasionally take longer than expected. In such cases, the data will continue to update incrementally as we catch up with the latest metrics.
When an SSL certificate is updated on a CDN distribution, it can take several minutes for the new certificate to propagate across all CDN nodes globally. During this time, some end users may still see the old certificate due to propagation delay or local DNS/SSL caching.
If the new certificate has not taken effect after more than an hour, it’s likely that there is an issue preventing proper propagation. In such cases, please contact support — the issue may require investigation by Leaseweb support to resolve.
To assist with troubleshooting, please ensure you’ve cleared local caches and verified the certificate using tools like openssl or SSL checking services.
These cases should be communicated with the Leaseweb support team with the details below which will help us resolve the issue as quickly as possible:
A high load on your origin is often related to caching configuration, particularly the Time-To-Live (TTL) settings. If the CDN is not caching content effectively, it will forward more requests to your origin, increasing its load.
To reduce the load on your origin, we recommend:
These adjustments help ensure that more traffic is served directly from the CDN cache rather than your origin.
There are a few possible reasons why your traffic may appear to be routed through only one CDN provider:
This behavior is expected and part of our optimization strategy to ensure reliable and fast content delivery.
Using an object storage as the origin for your Multi-CDN distribution is possible through simple origins.
For more details: Simple Origin
The API endpoints which allow management of the SSL certificates are described in the following URL: https://developer.leaseweb.com/docs/#tag/CDN The procedure for updating an SSL certificate using the API is similar to how it’s done on the dashboard:
The CDN dashboard does not currently offer 95th percentile statistics. However, you can still extract this information using the CDN API.
A wildcard invalidation is a common approach when a customer is updating several contents in the same directory. To do a wildcard invalidation for Multi-CDN in the CDN Portal the customer can add the wildcard symbol (\*) after their URL+ path. Here are some examples:
⚠️ Warning
Wildcard invalidations are not supported on the Shield distributions.
You can find the details of GEO targeting/blocking or IP subnet targeting/blocking or Referrer blocking in the Security Settings section of Multi-CDN Knowledge Base. After filling in all the relevant fields in that specific distribution you want to apply the targeting/blocking, save your changes by clicking on Save.
In order to setup a proper CORS policy to support XMLHttpRequest to the origin, the HTTP response header Access-Control-Allow-Origin needs to be set, as described here: Mozilla CORS specification
For cache efficiency reasons, our CDN discards this header by default.
If your origin is already producing this header (recommended), add the header name in the Passthrough headers of your distribution, as described below:
If however your origin is not producing the CORS headers, you can configure the CDN to do it instead:
Selecting the correct cache settings plays a key role while delivering live streams. Short-term cache settings for adaptive live streaming is recommended. Streaming protocols typically consist of two main types of files:
When a user starts playback, their player first requests a manifest file to understand the available segments and playback options. Then, it fetches the segment files listed in the manifest to begin streaming.
In live streams, video manifests are periodically refreshed when new segments become available, specially for HLS. We recommend setting manifest file TTLs to less than half of the video segment duration, typically 1-2 seconds for 5-second video segments. Caching segments too briefly may lead to 404 errors if the manifest references segments that have already expired in cache.
You can adjust your cache settings as explained in Cache Settings.
⚠️ Warning
Using shield-distributions is not recommended, because they add another caching layer, which increases the latency and the lower TTLs of chunks and playlists will start expiring. It’s recommended to enable Origin Controlled Delivery Cache.
Video files are generally large in size, so using a longer TTL is recommended to reduce unnecessary origin requests. Shield distributions can also be utilized if desired, as the extended TTL ensures that files are cached longer and do not need to be re-uploaded frequently.
You can adjust your cache settings as explained in Cache Settings.
This issue can occur due to the specific setup of your origin. Here are the most common causes:
This setup indicates the use of an S3 proxy. In such configurations, we also advise disabling the “Origin Control” option and manually configuring the TTL settings.
By adjusting your cache settings as described, you can ensure that your content is cached effectively across the CDN network.
This typically happens when your CDN distribution is configured with multiple domains under the “Domain(s)” section. It’s a common and valid setup—especially for users who serve content through several custom domains or subdomains. If you are seeing traffic across different domains and would prefer to limit this:
This will ensure that your distribution only responds to requests made to the specified domains you’ve retained.
There’s no issue with having multiple domains configured, but cleaning up unused or unnecessary entries can help simplify monitoring and reporting.
These headers are automatically added by our CDN providers as part of their internal request tracking and routing mechanisms. Examples include:
“`
x-id-fe: fr5-hw-edge-gc62
x-id: fr5-hw-edge-gc15
x-llid: bbfd8235bc828032a0b8e444c6e17a22
“`
These headers:
You can safely ignore these headers—they are intended for diagnostic and support purposes by the CDN network.
Changes to a distribution can take up to 30 minutes to fully propagate across all CDN providers. This is a normal behavior due to the distributed nature of CDN infrastructure.
Additionally, if you have modified TTL settings or updated the content on your origin, it is recommended to perform a full invalidation of the distribution. This ensures that stale content is removed from the cache and new settings take effect properly.
If the issue persists beyond the expected propagation time, please contact support for further assistance.
