Best Practices - Video CDN [EN]

Avoid CDN over a CDN

Using an external proxy-based CDN (e.g., Cloudflare) in front of vCDN/aCDN is not recommended.

This configuration leads to:

• Increased latency, since each request passes through two CDN layers sequentially.

• Higher risk of cache incoherence between edge nodes.

• Complicated troubleshooting when delivery issues arise.

• Inefficient use of CDN resources: the effective response time becomes limited by the slowest CDN in the chain.

To help detect misconfiguration:

• The panel verifies DNS records for connected domains.

• If a domain points to Cloudflare or another external CDN, the interface displays a warning icon (e.g., ⚠️) to alert the user.

Recommendation: Always connect domains directly to Video CDN. Avoid placing them behind other proxy CDNs to ensure predictable caching, consistent latency, and simpler monitoring.

In case you have no opportunity to follow the recommendation, check the Manipulate delivery algorithm section to mitigate any negative consequences possible.

Use callback for status check

If a client needs finer control over the import process (for example, to confirm whether a file was ultimately imported into the CDN), the simplest (but not ideal) approach is to periodically request the file from the CDN and check the HTTP response: 200 OK if the file is available, or 404 Not Found if it isn’t.

However, this method isn’t fully reliable because file status may be cached differently across redirectors. As a result, one request might return 200 OK from one node and 404 Not Found from another, leading to inconsistent status checks.

There is a better way.

To solve this, we offer a callback mechanism. When adding a file to the CDN, the client can specify not only the source URL (where the file should be fetched from) but also a callback URL. Once the CDN determines whether the file has been successfully imported or rejected, it makes a request to this callback URL.

What qualifies as a successful import? For instance, if the client declared an expected file size, but the origin responds with a different size, the CDN will reject the file and mark it as failed, recording the reason so the client can take corrective action.

When the file is successfully downloaded and becomes active, the CDN calls the callback URL. This lets the client handle the event automatically — for example, by updating a database or running a PHP script to mark the file as ready for use.

Watch your origin closely

From the user’s perspective, it’s simplest to describe the CDN as a cloud layer that handles content delivery independently. If certain files aren’t present on edge nodes, the CDN can proxy these requests to the origin and still deliver the content to end users. To do this reliably, the CDN continuously monitors load and availability. (See page Requests to non-existing files for more details.)

If your origin becomes temporarily unavailable, the system responds with an appropriate HTTP status code (e.g., 501), which the browser then displays as an error message. This helps clients and technical teams identify that the issue is related to origin capacity or availability.

It’s also worth noting that many clients might not actively monitor system metrics. As a result, they may only discover the problem when end users start reporting that “the service isn’t working.” That’s why it’s good practice to set up clear alerts and proactively communicate when origin capacity has been reached — so clients know action is required.