CDN website management

This article is used for daily configuration verification of existing websites. For first-time access, DNS switching and fault recovery, please press SCDN complete access and troubleshooting Complete verification.

When operating SCDN console The actual configuration value of the current website shall prevail. For fields or options that are not displayed, please check with technical support to see if they are available.

Access website

Open the website you want to manage, check the domain name and plan ownership, and then check the origin server information. Also prepare this information when adding a new website:

Switch between DNS resolution and verification

1. Save the original DNS records and TTL to confirm that the original access path can still be restored.
2. First check the origin server, edge certificate and back-to-origin protocol, and set up necessary cache, protection and business exceptions.
3. Use the console to modify the DNS for the real CNAME target assigned to the current website, checking for record conflicts with the same name and legacy AAAA records.
4. Confirm resolution and HTTPS from different networks, and then verify the home page, resources, login, submission, API, callbacks and long connections required by the business.
5. After a batch of domain names are verified to be stable, the next batch will be cut; when encountering key business exceptions, perform rollback according to the complete guide.

DNS caching may cause different regions to temporarily take different paths, so domain-by-domain acceptance records should be maintained.Batch access experience

Basic configuration

HTTP and origin settings

The listening port for guests to access the CDN and the port for the CDN to access the origin server are two configurations that need to be checked separately. Whether non-standard ports can be used depends on the current plan and actual configuration.

In a multi-origin scenario, check the currently provided load methods and health check options. If polling is used, it must be confirmed that each origin server can complete the same service; if IP Hash is used, it cannot be regarded as a guarantee that the user session will be fixed forever. Session and data consistency still need to be handled by the business itself.

If health check is provided, check the check protocol, host, port, path and success status code, and confirm that the check can reflect whether the service is available. Don’t return because of a certain origin server 404 Just directly 404 To join the successful list, you should first confirm whether the path configuration is correct.

The origin firewall needs to allow actual back-to-origin connections. Please obtain the current back-to-origin IP range from technical support and configure it according to the service port; do not take the successful direct connection of the local machine as evidence that the CDN back-to-origin is normal. For the positioning ideas of the return-to-origin port, protocol and Host, see 504 troubleshooting at the initial stage of access。

HTTPS settings

• edge certificate: Check the access domain name, certificate validity period, certificate chain and current binding result.
• HTTPS back to origin: Separately confirm the origin server monitoring, certificate, SNI and platform certificate verification requirements.
• Force HTTPS: Check the jumps on both sides of the CDN and origin server to confirm there are no loops; test the root domain name and subdomain names.
• Protocols and ports: Configure according to the options provided by the current console and the actual capabilities of the origin server.

After saving, actually access HTTPS, check the certificate and complete the redirect process. For more information on certificate preparation, see SSL access overview。

Security settings

CC Protection and Business Exceptions

Check the currently enabled default rules, custom match conditions, and execution actions. Browser validation affects clients that cannot perform JavaScript or interactive validation; retest using real clients after configuring necessary exceptions for APIs, payment callbacks, webhooks, etc.

Exceptions should be limited to necessary paths, methods or trusted sources as much as possible, while retaining interface authentication, signature verification and appropriate rate limiting. Check the log to confirm which rule the mistaken interception comes from, and then modify the corresponding conditions.

WAF and plan capabilities

Mainland China, Overseas Optimized and Asia-Pacific Optimized routes are all fromWAF included from Standard, no need to purchase separately; the Personal and Basic do not support WAF. View specific configuration SCDN plan table and actual orders. For protective purposes see Introduction to Web Application Firewall。

Black and white lists and access control

Check the IP, IP segment, region, User-Agent, source and anti-hotlink conditions according to the format supported by the current field. Save the original value before modification, and test the allowed and rejected requests separately after modification.

The whitelist may affect the execution order of other rules, which needs to be confirmed based on the current rule description and logs. The release of crawlers, APIs and callbacks should have specific business basis, and avoid release based only on User-Agent or an excessively large address range. When configuring region restrictions, check the console's actual defined region scope.

Content and connection optimization

Caching and compression

Compression reduces transmission volume, and caching reduces repeated returns to the source. Both items need to be checked separately. After compression, it can be checked in the actual response. Content-Encoding; Caching needs to be judged based on console records, response headers and origin server logs.

First set up public static resources, and then explicitly exclude login, user information, order and authentication interfaces. For extension matching and verification methods, see Commonly used cache file suffixes。

WebSocket configuration

Mainland China, Overseas Optimized and Asia-Pacific Optimized routes are all fromWebSocket is supported starting from the Basic, the Personal does not support it. After confirming the plan and proxy configuration, use a real client to verify handshake, message sending and receiving, idle connection and reconnection; timeout and concurrency limits are subject to actual plan and technical support confirmation.

error page

If the current configuration provides a custom error page, confirm that the response body and status code still meet business needs after modification. Beautifying error pages is not a substitute for fixing back-to-origin issues, nor should monitoring treat errors as successes.

Steering and request headers

URL redirection

Set the matching conditions and target address according to the current interface instructions. Check status code using actual URL, Location, parameter retention and loop jump; URLs containing order or authentication information also need to check whether the information has been mistakenly brought to other domain names.

Origin request header

First confirm the client IP and original protocol fields actually passed by the platform, and then adjust the origin server processing method. The origin server should only trust the forwarding header from the confirmed proxy link, and cannot directly regard the header with the same name submitted by the public network client as the real identity.

CDN response header

After modifying the response header, use the browser developer tools or HTTP client to view the real results. Specially check cache, cross-domain and security-related response headers to avoid conflicts caused by repeated settings of the origin server and CDN.

Minimal verification after saving

Only modify one set of relevant configurations at a time, and record the original values and time. After saving, check at least the homepage, static resources, HTTPS, login, and affected interfaces, and compare the origin server logs with the actual request records available on the console.

If 502/504 occurs, you can troubleshoot based on origin server resources, network permissions, protocol ports, and application time.502/504 Troubleshooting Guide;For more complete status codes and rollback steps, see SCDN complete access and troubleshooting。

When you cannot confirm the meaning of the field or the scope of the function, bring the domain name, plan, occurrence time, desensitization log and screenshot of the current actual interface, and pass Online technical support Check.