General questions about Yandex Cloud CDN

The section below covers the frequently asked questions related to Cloud CDN, plus common issues and fixes.

• CDN responds to file requests with 3xx codes (redirect)
• CDN responds to file requests with 4xx codes (client error)
• CDN responds to file requests with 5xx codes (server error)
• Why are the origin workload and its operation costs increasing?
• Requests with the POST, PUT, PATCH, and DELETE methods are not available to users
• Updated settings failed to apply to the resource
• CDN resource has the Not active status, preventing content delivery to users
• What happens to a CDN resource if the billing account is suspended due to non-payment?
• Unable to configure the TLS certificate
• CDN sends compressed files to users who do not request compressed content
• How do I enable WebSocket support?
• How do I update access policy settings for specific IP addresses in a created CDN resource?

CDN responds to file requests with 3xx codes (redirect)CDN responds to file requests with 3xx codes (redirect)

Make sure to specify the following resource settings:

• Protocol used by the origins as the primary one (HTTP or HTTPS). If origins redirect requests from http URIs to https URIs, select HTTPS for the resource, and vice versa.

• Host HTTP header value to which origins respond without redirects.

  For example, if the header value is set to www.example.com, and origins redirect requests with this value to example.com, change the value in the settings to example.com.

CDN responds to file requests with 4xx codes (client error)CDN responds to file requests with 4xx codes (client error)

Make sure that:

• The resource settings allow end clients to access content.

• Origins return files in response to direct requests, bypassing the CDN.

• Origins allow and correctly process requests that match the resource settings:

  • Over the specified protocol: HTTP or HTTPS.
  • With the specified value of the Host HTTP header and other headers.

CDN responds to file requests with 5xx codes (server error)CDN responds to file requests with 5xx codes (server error)

Make sure that:

• Origins respond to CDN server requests within 5 seconds.

• Origins allow and correctly process requests that match the resource settings:

  • Over the specified protocol: HTTP or HTTPS.
  • With the specified value of the Host HTTP header and other headers.

Also, check the Cloud CDN status here.

Why are the origin workload and its operation costs increasing?Why are the origin workload and its operation costs increasing?

Cloud CDN does not guarantee any particular percentage of cached requests hitting the cache (cache hits). If the CDN server cannot respond to a request from the cache, it accesses and gets content from the origin. Depending on your settings for caching, cache cleanup, new content publication, or the nature of user requests, the number of requests to the origin and the amount of data it sends back may increase. At the same time, the amount of data the origin sends to CDN servers may be comparable to the amount of outgoing CDN traffic.

Cloud CDN does not charge for incoming traffic CDN servers are getting from origins, even when the origin is outside of Yandex Cloud. Outgoing traffic from Yandex Cloud resources to CDN servers is treated as internal and Yandex Cloud services do not charge you for it. For example, if the origin is an Object Storage bucket, transferring data from the bucket to Cloud CDN is not billed on the Object Storage side.

At the same time, the origin's operating costs may depend on the number of incoming requests. For example, if requests are handled by a function, the number of its calls will be factored in. If there is a traffic filtering or DDoS protection service upstream of the origin, its costs may depend on the amount of processed traffic, bandwidth, or request count.

Make sure the origin can withstand potential peak loads, and its pricing conditions do not imply substantial extra costs. If required, protect the origin at the application layer (L7) of the OSI model, e.g., using Yandex Smart Web Security.

Yandex Cloud does not compensate for consequential losses due to increased load on the origin.

Requests with the POST, PUT, PATCH, and DELETE methods are not available to usersRequests with the POST, PUT, PATCH, and DELETE methods are not available to users

By default, the POST, PUT, PATCH, and DELETE methods are not available in client requests. To find out whether you can use these methods, contact support. When contacting, describe your use case.

Updated settings failed to apply to the resourceUpdated settings failed to apply to the resource

It may take up to 15 minutes for the new settings of the existing resource to apply to the CDN servers. After that, we recommend purging the resource cache.

The CDN resource has the status, preventing content delivery to usersThe CDN resource has the Not activestatus, preventing content delivery to users

Resources can show as Not active due to receiving no user requests for 90 days or being deactivated manually. To make them active again, enable End-user access to content in the basic resource settings. To enable or disable resources, you need the cdn.editor role or higher.

What happens to a CDN resource if the billing account is suspended due to non-payment?What happens to a CDN resource if the billing account is suspended due to non-payment?

If your billing account is suspended due to non-payment, access to content via the CDN resource gets halted.

Unable to configure the TLS certificateUnable to configure the TLS certificate

Certificates from Yandex Certificate Manager are supported. You can issue a new Let's Encrypt® certificate or upload one of your own.

The certificate must be located in the same folder as your CDN resource.

Below is an example of a CLI error you receive when the certificate and the CDN resource reside in different folders:

ERROR: operation (id=bcdb6qaiw8mb********) failed: rpc error: code = InvalidArgument desc = folder ids of user and certificate don't match; operation-id: bcdb6qaiw8mb********

The CDN sends compressed files to users who do not request compressed contentThe CDN sends compressed files to users who do not request compressed content

Cloud CDN may send compressed files even if a user does not request compressed content. This may happen in the following cases:

1. First request from the client for the file not yet in the CDN cache had the Accept-Encoding: gzip header. The same header is provided to the origin.
2. The origin transfers the compressed file to the CDN cache but does not add the Vary: Accept-Encoding header. For example, this happens if you set an Object Storage bucket as the origin.

In this case, the CDN cache saves the compressed file, which all clients will receive. Also, it is irrelevant whether their devices support compression or whether they add the Accept-Encoding: gzip header to their requests.

To avoid this, enable file compression. This way, Cloud CDN will always request non-compressed content from the origin, and if the client request has the Accept-Encoding: gzip header, it will compress files on its own without sending the header to the origin.

How do I enable WebSocket support?How do I enable WebSocket support?

To enable the WebSocket protocol, contact support. Specify the following:

• Your use case for WebSocket.
• Tasks you plan to address.
• Approximate traffic size.

How do I update access policy settings for specific IP addresses in a created CDN resource?How do I update access policy settings for specific IP addresses in a created CDN resource?

Navigate to the Security tab of the CDN resource and click Edit.