SCDN complete access and troubleshooting
Complete SCDN onboarding in verifiable steps, from origin preparation, DNS and certificates to caching, API exceptions and failbacks.
Contents of this article
When accessing for the first time, first complete the verification of a low-risk domain name, and then migrate it in batches. When using the commands in this article, replace the example values with your actual configuration. The console entrance is SCDN console。
Preparation before accessing
Prepare a domain name account that can modify DNS, available SCDN plans, origin server management rights, and certificate information. Check the account real name, line applicable conditions and fees first Purchase requirements and billing。
| Actual value to be recorded | Where to check | Access pass conditions |
|---|---|---|
| Domain names, plans and lines | Current website configuration and purchased plans | Domain name quota, functions and lines meet the needs of this business |
| Origin IP or independent origin domain name | Instance information of the server or cloud platform | The address is real and available; the independent origin domain name will not be resolved back to this CDN |
| Back-to-origin protocol and port | origin server monitoring configuration and SCDN website configuration | Both ends are consistent, and the firewall allows corresponding back-to-source connections. |
| Back to origin Host, HTTPS SNI | origin server virtual host, certificate and actual back-to-origin configuration | The request reaches the correct site and the TLS handshake uses the correct name |
| Access domain name certificate | Certificate details vs actual HTTPS connection | Covers the complete access domain name, has not expired, and has a complete certificate chain |
| CNAME target, legacy resolution, and TTL | SCDN allocation results and DNS provider records | Each domain name is recorded and the previous access path can be restored. |
| Login, API, callback and WebSocket paths | Business routing and interface documents | Make it clear what cannot be cached and cannot accept browser challenges |
Mainland China, Overseas Optimized and Asia-Pacific Optimized routes are currently available fromWAF included from Standard, fromWebSocket is supported starting from the Basic; The Personal does not support these two items, and the Basic does not support WAF. View specific configuration SCDN plan table and actual orders.
Step 1: Check the origin server and return to origin
First confirm that the origin server can handle real business requests, and then configure the CDN. If the browser directly accesses the IP successfully, it can only indicate that the access was successful, but it cannot prove that all CDN nodes can connect to the correct site.
| Project | Check method | Common fixes |
|---|---|---|
| Source address | Compare with the origin server instance address and domain name resolution results one by one | Use the real origin server address and exclude the origin server domain name from pointing to the CDN again to form a loop. |
| Protocols and ports | Check the protocol and port actually monitored by the origin server’s web service | HTTPS back-to-origin cannot be configured when the origin server only listens to HTTP; first confirm plan support for non-standard ports |
| Network release | Check security group, firewall and origin server access logs | Confirm the current back-to-source IP range with technical support, release designated ports as needed and maintain updates |
| Back to source Host | Check the domain name bound to the origin server’s virtual host and the Host in the access log | Make sure the request matches the business site, not the default site |
| HTTPS SNI | Check the origin server certificate name and TLS virtual host configuration | Check the SNI, origin certificate and back-to-origin verification requirements actually sent by the CDN |
| Multi-origin server | Check the same URL and business version one by one | Confirm the health of each origin server to prevent requests from occasionally landing on the wrong instance |
Host is the site name in the HTTP request, and SNI is the server name used in the TLS handshake phase; changing the source address to IP does not mean that these two values should also be changed to IP. If the console does not display the independent SNI or back-to-origin Host settings, please provide the origin domain name and certificate information to technical support to confirm the actual behavior. Do not guess the default values.
In the early stage of access, priority should be given to checking the return-to-origin port, host, protocol, and origin server certificate; when encountering 504, it should be judged based on logs, and should not be determined to be an attack or node failure based on the status code alone.504 troubleshooting experience in the early stage of access
Test the origin server with a real domain name
The following command is in Windows Terminalin operation.www.example.com and 192.0.2.10 is an example domain name and reserved test address, please replace it; Linux/macOS can curl.exe Change to curl、NUL Change to /dev/null。
curl.exe --resolve www.example.com:80:192.0.2.10 -sS -D - -o NUL http://www.example.com/
curl.exe --resolve www.example.com:443:192.0.2.10 -sS -D - -o NUL https://www.example.com/
These two commands only specify the connection address in this request and do not modify the DNS; the HTTPS example retains the Host, SNI and certificate verification corresponding to the access domain name. Do not use the results of ignored certificate errors as the basis for online acceptance. If a different Host, SNI or port is actually used for back-to-origin, the test should be based on that set of actual values; if necessary, ask technical support to initiate a check from the CDN side. When the origin server only allows CDN return-to-origin addresses, local testing may be rejected and a controlled diagnostic portal should be used.
Step 2: Check the two HTTPS sections separately
There are two connections from the visitor to the CDN and from the CDN to the origin server. Check them separately:
- Visitors to CDN: The accessed domain name has been bound to the correct certificate, the certificate covers the domain name, the private key matches and the certificate chain is complete. The root domain name and subdomain names are checked separately, not just one of them.
- CDN to origin server: Configure back-to-origin according to the HTTP or HTTPS actually supported by the origin server. HTTPS back-to-origin also needs to check the origin certificate, SNI and platform verification requirements.
- HTTPS redirect: Confirm that the redirect policies of the CDN and the origin server do not conflict with each other. When the origin server needs to know the original access protocol, use the protocol header actually passed by the platform and trusted by the origin server, test it first, and then enable the jump.
- Renewal liability: Record the expiration date, update person, and deployment location of the edge certificate and origin certificate. Just because the console has a certificate does not mean that the origin server has been updated synchronously.
If repeated jumps occur, check each response Location, confirm which link switches the request back to HTTP or another domain name. First restore the recently modified jump configuration, and then locate it item by item. Certificate access see also SSL access overview。
Step 3: Configure cache and business exceptions
First distinguish between public static resources and personalized responses, and then set the cache range and time.
| Business type | Recommended treatment | Must verify |
|---|---|---|
| Public CSS, JS, images with version numbers | Set cache based on resource update frequency | The content of repeated requests is correct, and new resources can be obtained by releasing a new version. |
| Login, user center, order, shopping cart | Explicitly exclude public caches | The two test accounts do not exchange data with each other, and the status is correct after logging out. |
| Interface with Cookie or Authorization | Clear cache exceptions based on authentication and business design | Not logged in, logged in, and different permissions return the correct results. |
| Payment notification, Webhook, machine call API | Eliminate incompatible browser challenges and retain necessary authentication and protection | Validate method, request body, signature and return value with actual client |
| WebSocket | Confirm plan, proxy support and connection timeout | Use a real client to check handshakes, messaging and reconnections |
Don't assume that all cookies, Authorization or Set-Cookie The responses are automatically excluded from cache. Check console rule priority and origin server Cache-Control and actual hit results; for sensitive responses, use the appropriate private、no-store policy and confirm that the CDN does not override these restrictions.
APIs and callbacks generally cannot perform JS validation or interactive captchas. Exceptions should be limited to necessary paths, methods or trusted sources, and business signatures, authentication and necessary rate limits should be retained. Don't just return the interface 200 If it is determined to be successful, it is also necessary to check whether the returned content is a challenge page. File type reference Commonly used cache file suffixes。
Step 4: Switch DNS
- Save the current A, AAAA, CNAME records, TTL and original access path of each domain name, and confirm that there is an available fallback target.
- Copy the actual assigned CNAME of the domain name from the current SCDN website configuration, without splicing it yourself, nor directly applying the targets of other websites.
- Modify the corresponding records at the DNS service provider according to the access requirements. Check the conflicts between A, AAAA and CNAME with the same name and legacy IPv6 resolution; whether the root domain name supports alias resolution is subject to the capabilities of the DNS service provider.
- First cut a domain name, review it on different networks and recursive DNS, and then switch batches one by one. After adjusting the TTL, existing caches still need to wait for the original TTL to expire.
nslookup -type=CNAME www.example.com
nslookup www.example.com
If the DNS service provider uses root domain name aliases or CNAME flattening, the query may directly return the address. This should be judged based on the service provider's records and the actual allocation results of the CDN. After confirming the DNS, visit the business page and check the response and origin server logs; simply finding the CNAME does not prove that the business is normal.
When accessing in batches, verify and observe the load status of the origin server in batches to allow time for DNS cache propagation. Record the inspection results on a domain-by-domain basis and complete the acceptance from the main visited areas.Batch domain name access experience
Step 5: Complete online acceptance
| Acceptance items | pass standard |
|---|---|
| DNS and HTTPS | Multiple network access expected paths, certificate domain name, validity period and chain are correct |
| Home page and static resources | Pages and resources are complete, with no error jumps, mixed content, or old version residues |
| Login and permissions | Login, refresh, and logout are normal, and data from different test accounts are isolated. |
| Forms and APIs | Use the real method and request body to complete the operation and return the expected business results |
| Callbacks and long connections | Complete the callback in the test environment or controllable process; WebSocket sending, receiving and reconnecting are normal |
| Origin and protection | There is no abnormal increase in error rate, time consumption, CPU, bandwidth and number of connections, and business requests are intercepted without error. |
In the initial stage of launch, the change time, test domain name, results and operator will be retained. Confirm that one batch is stable before proceeding to the next batch; if an exception occurs, stop expanding the scope of changes.
Common Errors and Troubleshooting Orders
Errors may be returned by the origin server, CDN, or other proxies in the link. The actual return party should be located using the time of occurrence, request ID, and logs on both sides.
| phenomenon | Check first | Next step |
|---|---|---|
| DNS has no results or still reaches the old site | DNS records, domain status, TTL, A/AAAA and CNAME | Compare authoritative records and different network query results |
| TLS handshake failure, certificate alarm | Currently connected domain name, certificate chain, validity period, SNI | Check edge and origin TLS separately, fix and retest |
| 301/302 loop | Location, force HTTPS, origin server jump and original protocol identification |
Restore conflict rules and verify a normal jump layer by layer |
| 401/403 | Login credentials, origin server permissions, anti-leeching and protection logs | Distinguish between business denial and protection interception, and then adjust the minimum scope rules |
| 404 | Request path, Host, virtual host and release version | Verify the origin directly using the same Host and path |
| 429 | Rate limiting strategy and retry behavior of the origin server or CDN | Confirm which side the restriction comes from and adjust according to actual business |
| 502 | Upstream connection, protocol, TLS, origin server exception response | Compare origin error logs with CDN request records |
| 503 | Origin service, maintenance status, available backends and resource usage | Restore healthy instances or address resource bottlenecks |
| 504 | Back-to-origin network, port, host, response time | Check the security group, application time, database and number of connections, and then check the links and nodes |
When 502/504 persists, check the origin server resources, database connections, and back-to-origin records during the failure period; do not just modify the timeout parameters. Then adjust the cache or multi-origin configuration based on the troubleshooting results.502/504 Troubleshooting and Optimization Guide
Fallback steps
When a critical process fails, is cached incorrectly, or continues to receive errors, record the fault and current configuration first, and then restore according to the prepared plan.
**If personalized content is cached by mistake, immediately stop the relevant caching and clear the cached content, and check the scope of the impact; if necessary, contact technical support to prevent further leaks. Do not wait for DNS fallback to take effect. **The general fallback steps below do not replace this processing.
- Targeting recent changes: If the problem comes from the newly modified cache, protection or jump rules, restore the original value of the item first and verify it.
- Confirm that the fallback target is available: Re-verify the domain name, HTTPS, capacity and protection path of the original service. When the original solution relies on other proxies, that full path should be restored.
- Restore DNS: When you really need to exit this CDN access, restore the previously saved DNS resolution records and TTL. DNS fallback does not take effect immediately, and there may be requests on both paths during the transition period.
- Retain transition services: Before local caches are updated and requests are confirmed to be stable, retain the current CDN website and certificate configuration, and do not delete services that may still accept requests in advance.
- Review and record: Confirm that each path has been restored and the cache problem has been resolved, and then save the reason, correction items and re-access conditions.
When the original solution is to directly access the origin server, restoring the direct connection will also restore the origin server exposure and original load-bearing pressure. Please use the available path confirmed before accessing, and contact technical support for assistance with recovery if necessary.
Contact technical support
Pass Online technical support or Contact us Submit the following information:
- Products, plans, problematic domain names, origin server protocols, and ports.
- Occurrence time and time zone, affected area or operator, error code and reproducible path.
- The content of this change, DNS query results, and differences between direct connection and CDN testing.
- redacted request identifiers, response headers, origin server access and error logs; if providing screenshots, please use the current actual interface and cover sensitive information.
Do not submit account passwords, certificate private keys, full cookies, Authorization or interface keys. When the Host/SNI default behavior, return-to-origin IP list, timeout, and feature switches are not clearly shown in the current configuration, please confirm it with the ticket.