What should I do if I failed to set a custom domain in the COS console?
1. Please first verify if the domain name has an ICP filing.
2. Confirm if the DNS resolution of the domain name is correct by using the Domain Check Tool. When CDN acceleration is disabled, you need to preconfigure the domain name to CNAME to the storage bucket's default domain in the DNS resolution console.
What’s the difference between enabling and disabling CDN acceleration if I have my own domain bound?
Enabling CDN acceleration: The domain is managed by CDN. Enabling CDN acceleration in the COS console has the same effect as adding a domain name (with COS as the origin) in the CDN console. When resolving the domain name, users need to use the CNAME record assigned by CDN. To configure, add the domain name first, then resolve the domain name. For domain name resolution, refer to Quickly Add Domain Name Resolution.
CDN acceleration disabled: The domain name is managed by COS. The domain name configuration is delivered to all download devices connected to the region where the bucket resides. The default domain name of the bucket is used as the CNAME record for DNS resolution.
Why does the Content-Disposition header I set for the object not take effect?
Other custom headers can take effect once set. However,
Content-Disposition takes effect only if the static website feature is enabled, and you access the object with a custom domain.What should I do if a static website cannot be accessed by using a CDN domain name?
Check the configuration of the CDN-accelerated domain name in the following steps:
1. Select Static Website Endpoint as the origin type.
2. Set origin-pull authentication and CDN service authorization based on the bucket permission:
If the bucket permission is private read, authorize the CDN service and enable origin-pull authentication.
If the bucket permission is public read, there is no need to authorize the CDN service or enable origin-pull authentication.
3. Set CDN authentication based on the bucket permission:
1. If the bucket is set to private-read:
CDN Authentication | Access with CDN Acceleration Domain Name | Access with COS Domain Name | Use Case |
Disabled (default) | Inaccessible | COS authentication is required | Allowing direct access to CDN domain names to protect the content on the origin |
Enabled | URL authentication is required | COS authentication is required | Securing access comprehensively (hotlink protection for CDN authentication is supported) |
2. If the bucket is set to public-read:
CDN Authentication | Access with CDN Acceleration Domain Name | Access with COS Domain Name | Use Case |
Disabled (default) | Yes | Yes | Allowing all public access to the entire website via the CDN or origin |
Enabled | URL authentication is required | Yes | Enabling hotlink protection for access via the CDN but not the origin server (not recommended) |
3. After confirming that the above configurations are correct, check the protocol used to access the CDN acceleration domain name and the forced HTTPS configuration of the static website:
If you are using the HTTP protocol to access the CDN acceleration domain name, do not enable forced HTTPS.
If you are using the HTTPS protocol to access the CDN acceleration domain name, we recommend you enable follow 301/302 for the CDN acceleration domain name. For more information, see Follow 301/302 Configuration.
4. If the problem persists after you perform the steps above, you can contact us.
What should I do if 404 is returned on refresh if the static website is used together with the frontend Vue framework and the router is set to History mode?
On the static website configuration page of the bucket, set the error document path to the landing page of the web application (mostly index.html) and set the status code of the error document to 200. For the configuration directions of static websites, please see Setting Up a Static Website.
Note
After completing the configuration using the above method, if you still need to implement the normal 404 response functionality, you can set it up yourself at the bottom layer of Vue's frontend routing configuration (usually by using a wildcard match to a custom 404 component).