中文版

The risky part of a first CDN rollout is usually the order of changes. Moving DNS before certificates and origin connectivity are ready can send users into a broken path. Retiring the previous entrance too early also removes the easiest rollback.

The steps below follow the order used for a production rollout. Keep the existing origin entrance and DNS values at hand, and begin with a test hostname or a lower-risk production hostname.

Available controls may vary by account, plan and service region. Treat the status and guidance shown in Console as authoritative.

Onboarding sequence and pre-change preparation

The onboarding work has six stages:

  1. Add the domain and origin.
  2. Verify domain ownership.
  3. Point the business domain to its CNAME.
  4. Validate TLS and origin connectivity.
  5. Configure caching and WAF policy.
  6. Confirm the rollout through logs, status codes and usage.

After these steps, continue watching logs, usage and billing. Retire the previous entrance only after resolution, HTTPS and origin behavior have been verified from the regions that matter.

1. Account status and permission checks

Open IXCDN Console. If there is no active session, you will be sent to the sign-in page.

Before adding a domain, confirm:

  • the active account and language;
  • permission to manage domains;
  • any usage, balance or service-limit notice;
  • security recommendations such as MFA or a password update.

2. Domain and origin configuration

Open Domains and find the domain onboarding form.

Provide:

  • Domain: for example, app.example.com;
  • Origin: an origin hostname or IP:port;
  • Origin scheme: HTTP or HTTPS, matching the service at origin;
  • Verify origin certificate: keep this enabled for HTTPS origins;
  • Also add www: use this when the root and www hostnames should be onboarded together.

It is normal for the domain not to become Active immediately. IXCDN first verifies ownership so another account cannot onboard a domain it does not control.

3. Ownership verification with DNS TXT

Open the new domain. Console displays the DNS TXT record required for verification. Add the exact record name and value at the authoritative DNS provider for the domain.

After DNS propagation, return to Console and run the verification check. Typical states are:

  • pending: waiting for verification;
  • verified: ownership has been confirmed;
  • failed: the record was not found or did not match.

If verification fails, do not repeatedly delete and recreate the domain. Check the DNS zone, whether the provider appended the zone name automatically, and whether the TXT value contains extra quotes or spaces.

4. CNAME cutover and rollback preparation

After verification, Console provides a dedicated alias ending in cdn.agslb.com, for example:

app.example.com.cdn.agslb.com

At the DNS provider for the business domain, point app.example.com to the complete alias shown in Console. Do not guess or shorten the target.

The domain may move through pending_dns, propagating and active. DNS propagation takes time and can produce different answers by region. Keep the existing origin entrance available until the regions that matter all resolve through the new path.

5. Client-side and origin-side TLS validation

Open the domain’s Connection and TLS views. Check:

  • origin address and port;
  • HTTP or HTTPS origin scheme;
  • origin certificate verification;
  • origin SNI when required;
  • redirect behavior from visitor HTTP to HTTPS;
  • edge certificate status and validity.

Domain onboarding, origin, CNAME, verification and WAF controls in the IXCDN tenant console

If the origin uses a self-signed certificate, do not treat disabled verification as a permanent fix. Prefer a valid origin certificate. If a private certificate chain is required, contact support to confirm the origin arrangement.

6. Cache-policy baseline

Open Cache. Begin with a conservative policy:

  • cache static assets;
  • decide whether HTML or API responses are safe to cache;
  • bypass personalized paths such as login, checkout and account pages;
  • start with a reasonable default TTL and tune it with observed results;
  • invalidate affected content when a release requires it.

After saving the policy, use Usage to watch cache hit ratio and origin traffic. A low hit ratio is not automatically a failure. Static images or scripts that always return to origin, however, are a reason to inspect response headers, cache rules and URL parameters.

7. WAF transition from detection to blocking

Open Security and select a WAF policy for the domain.

A controlled rollout is:

  1. Start in detect mode.
  2. Review matched paths, client IPs and actions in WAF events.
  3. Address clear false positives.
  4. Move to block after normal application behavior has been confirmed.

The strictest policy is not necessarily the right policy. API request bodies, uploads and unusual parameters may trigger rules, so measure false positives before moving to blocking.

8. Log-based troubleshooting sequence

Open Logs, select a domain and time range, then use the main query controls or column-header filters for:

  • status code;
  • request path;
  • client IP;
  • HTTP method;
  • cache status;
  • edge node.

Access logs identify the request, status distribution shows whether the problem is concentrated, and WAF events show whether security policy took action.

A useful investigation sequence is:

  1. isolate 4xx or 5xx responses;
  2. check whether failures cluster around one path;
  3. compare cache status and edge node;
  4. review WAF events for a matching security action;
  5. for 5xx responses, verify origin health and connectivity.

9. Post-launch usage and billing monitoring

Use Usage for requests, egress, cache hit ratio and top domains. Check Billing for the current period, balance or plan state.

During the first week after rollout, review:

  • whether egress matches expectations;
  • whether cache hit ratio is stable;
  • whether 4xx or 5xx responses are increasing;
  • whether unusual IPs, paths or nodes appear;
  • whether usage is approaching a budget or service limit.

Go-live checklist

  • Domain ownership is verified.
  • The business domain points to the complete alias shown in Console.
  • Domain status is Active.
  • HTTP and HTTPS behave as intended.
  • Origin certificate verification succeeds.
  • Dynamic and personalized paths are not cached incorrectly.
  • WAF has completed an observation period in detect mode.
  • Logs show real requests, status codes and cache outcomes.
  • Usage and billing state are healthy.
  • The previous origin entrance remains available until the rollout is stable.

If you are still deciding what to onboard, read Six Technical Criteria for Production CDN Evaluation.