A field-tested design for putting an ESA edge in front of an ApsaraVideo Live playback domain — architecture, design decisions, step-by-step configuration, acceptance tests, and a troubleshooting matrix
Scenario. A broadcaster runs live channels on Alibaba Cloud ApsaraVideo Live. The playback domain pull.example.com serves HLS pull streams at https://pull.example.com/app/stream.m3u8?auth_key=<signature>, with Type-A URL signing enabled. Viewers arrive through web players (hls.js / native HLS in Safari) and mobile SDKs. The audience spans mainland China and overseas markets. The business has three recurring pain points: origin egress and request volume grow linearly with concurrency; bandwidth abuse (playlist harvesting, PCDN-style leeching) inflates the monthly bill; and scheduled premieres attract DDoS attacks that coincide exactly with peak revenue moments.
Goals. (1) Move segment delivery to the edge so origin egress stops scaling with viewer count. (2) Keep playlist freshness within a few seconds so live latency and segment availability are unaffected. (3) Apply WAF, bot/abuse control, and DDoS protection at the edge without breaking legitimate players. (4) Keep ApsaraVideo Live URL signing as the origin-side authorization layer. (5) Require zero changes to players, encoders, or the live service.
Non-goals. Sub-second glass-to-glass latency (that is what RTS/WebRTC delivery is for; HLS is inherently ≥10 s), DRM packaging changes, and origin-side transcoding. This solution optimizes and protects the HLS pull path as it exists today.
Viewers (browser hls.js / Safari HLS / mobile SDK)
| https://live.example.com/app/stream.m3u8?auth_key=...
v
+----------------------------------------------------+
| Alibaba Cloud ESA edge (3,200+ nodes) |
| - WAF managed rules, rate limiting, abuse control |
| - DDoS scrubbing (always-on baseline) |
| - Cache: .ts cached, .m3u8 bypass / <=3 s TTL |
| - CORS header injection (transform rules) |
+----------------------------------------------------+
| origin fetch, Host & SNI = pull.example.com
v
ApsaraVideo Live playback domain (pull.example.com)
URL signing Type A, ingest/transcode/origin dist.Request flow: every request first passes edge security checks. Playlist polls then bypass (or briefly touch) the cache and reach the live origin, so MEDIA-SEQUENCE always advances in real time. Segment requests hit the edge cache after the first fetch per node; because segment names embed a creation timestamp, cached objects are immutable and always safe to serve. The origin sees one request per segment per edge node instead of one per viewer.
The multi-viewer behavior is worth understanding before capacity planning. With N concurrent viewers spread across M edge nodes, steady-state origin traffic converges to roughly one playlist poll per viewer (playlists are per-session and stay dynamic) plus one segment fetch per node per segment interval. Segment egress — typically 90% or more of total bytes — therefore scales with edge-node count, not audience size. Playlist request volume still scales with viewers, which is why the security layer's rate limiting and the origin's signing verification matter even after caching is in place. Regionally, the same rule set behaves differently by market: mainland China traffic is served from the dense domestic footprint (all seven regions, essentially every province and carrier) and requires ICP filing on the site, while international viewers are served from North America, Europe, three Asia-Pacific zones, the Middle East/Africa, and South America. Sites whose origin lives overseas but whose audience includes mainland viewers should evaluate ESA's cross-region network optimization (Enterprise add-on) as part of this solution, since public-internet cross-border routing is the dominant source of stall events in that topology.
D1 — Hostname plan and play-URL generation. Onboard live.example.com on ESA via CNAME and generate play URLs by swapping only the host of the existing playback URL. This works because Type-A signing hashes the URI path with timestamp, rand, uid, and the private key — the hostname is not part of the signature — so the same auth_key stays valid on the ESA domain. No player SDK changes are needed.
D2 — Split cache policy by object class. In HLS, the playlist is the control plane (must be fresh) and segments are the data plane (immutable). Therefore .m3u8 gets bypass-cache or a 1–3 s edge TTL (ESA's minimum TTL is 1 s) with browser caching disabled; .ts gets a long custom TTL (one day is safe).
D3 — Explicit negative-cache control. Live origins often return error pages carrying long Cache-Control headers (we have seen max-age=86400 on 404 bodies). Under ESA's default status-code caching behavior, such a 404 would be pinned at the edge for a day. The solution sets an explicit, minimal status-code TTL for 404 on media paths.
D4 — Cache-key integrity. The query string (which carries auth_key) must remain part of the cache key. Ignoring query strings would merge different sessions and signatures into one cache entry and break URL-based purge semantics.
D5 — Security at the edge, authorization at the origin. ESA provides WAF, bot/abuse control, and DDoS absorption; ApsaraVideo Live URL signing remains enabled as the second layer. Each layer fails independently and neither replaces the other.
D6 — Challenge policy for media paths. Native players and SDKs cannot solve JS or slider challenges. Interactive challenges are therefore restricted to web-only paths; media paths are protected by frequency control, IP reputation, and region rules instead.
D7 — Observability-first operation. Every decision above produces a measurable signal: X-Site-Cache-Status distinguishes bypass, miss, and hit per request; cache analytics show HIT ratio by suffix; security analytics separate blocked from allowed traffic; and the Eagleid response header ties any single viewer complaint to a full edge trace. The solution is considered operational only when these four signals are being watched during broadcasts.
D8 — Change management through purge and canary. Edge cache state outlives configuration changes: a rule edit does not invalidate objects already cached under the old rule. Therefore every cache-affecting change in this solution is paired with a directory purge and a canary stream before production rollout. This is treated as a hard operational rule, not a suggestion — most "the config is correct but behavior is wrong" reports trace back to stale edge state.
Step 0 — Prerequisites. If the acceleration region includes mainland China (regions: Mainland China, or Global), the domain needs a valid ICP filing; Global excluding Mainland China does not. Plan selection: Standard or above is recommended for managed WAF rules and scan protection; Enterprise adds full-protection DDoS tiers, cross-border network optimization, and L4 proxying.
Step 1 — Site and DNS. In the ESA console, add the root domain as a site, choose the acceleration region matching your audience, and create a CNAME record pointing live.example.com to the ESA-assigned CNAME value (unique per hostname).
Step 2 — HTTPS and transport. Attach an ESA-managed certificate to live.example.com, enforce HTTP-to-HTTPS redirection for the playback hostname, and enable HTTP/2 so playlist polls and segment fetches multiplex over one connection per viewer.
Step 3 — Origin rules. Under Rules → Origin Rules, set a custom origin Host of pull.example.com and, for HTTPS origin fetches, an origin SNI of the same value. The live service routes streams by Host header; omitting this makes every request 404 at the live edge. This is the single most common deployment error.
Step 4 — Cache rules. Create two rules; ESA matches top-down, first hit wins, so order matters.
| # | Match condition | Cache eligibility | Edge TTL | Browser TTL | Status-code cache |
|---|---|---|---|---|---|
| 1 (top) | (http.request.uri.path ends_with ".m3u8") |
Bypass cache (or eligible) | — (or 1–3 s) | No cache | — |
| 2 | (http.request.uri.path ends_with ".ts") |
Eligible | Ignore origin, custom TTL = 1 day | Follow origin | 404 → minimum (0–1 s) |
Guardrails: keep rule 1 above any site-wide caching rule; never enable "ignore query strings" in custom CacheKey for these paths; after any rule change, purge the affected directory from the console (browser refreshes do not clear edge state).
Step 5 — CORS at the edge. Under Rules → Transform Rules → Modify Response Header, position "ESA to client": for public streams add Access-Control-Allow-Origin: * statically; for whitelisted origins match http.request.headers["origin"] and echo it back dynamically (type = dynamic, value = http.request.headers["origin"]), adding Access-Control-Allow-Credentials only in the echo variant. ESA's header configuration overrides origin-side CORS when both exist.
Step 6 — Security configuration. Enable WAF managed rules and scan protection site-wide; enable abuse prevention (bandwidth-theft protection) on the streaming hostname. Add a frequency-control rule sized to real polling cadence — roughly one playlist request per target duration per viewer plus segment bursts. As a starting point for a 8–10 s target duration, allow on the order of 40–60 requests per 10 s per client IP across the media path (playlist polls plus parallel segment fetches plus retries), with a block or slider action lasting 10–60 minutes; then validate against a recorded session from your most aggressive player build — including background retry storms on poor networks — and tighten from measured reality, never from intuition. Apply interactive challenges only to web-only paths per D6. Optionally add IP/ASN/region rules for known-bad ranges, and a whitelist rule for your own monitoring probes so they skip checks entirely. DDoS needs no configuration at baseline (all plans include platform protection up to 10 Gbps L3/L4 and 100k QPS CC); Enterprise customers should set the HTTP DDoS protection level and deep-learning mode before announced events. For ticketed premieres, enable waiting room (Advanced and above) to queue launch spikes at the edge.
Step 7 — Purge and staged rollout. Purge directory https://live.example.com/app/ (method: direct delete) so no object cached under the old rules survives the change. Then roll out in three stages rather than flipping all traffic at once. Stage 1 (canary): point a single low-stakes test stream at the ESA hostname and run a full player-matrix session (hls.js, Safari native, mobile SDK) for at least ten minutes while watching X-Site-Cache-Status per request and the cache-analytics HIT curve; segment HIT ratio should climb as the stream runs while playlist status stays BYPASS/MISS. Stage 2 (partial): move a small, representative slice of production channels — enough to generate real concurrency across several edge regions — and hold it for one broadcast, comparing origin request volume before and after (it should drop sharply for segments while playlist volume tracks viewer count). Stage 3 (full): switch all remaining streams to the ESA hostname, keeping the origin playback domain live and signing enabled as an instant fallback path.
Capacity sizing for the migration window: with segment egress offloaded, the origin's residual load is dominated by playlist polls, roughly one per viewer per target-duration interval. For a 10 s target duration and 10,000 concurrent viewers, that is on the order of 1,000 playlist requests per second against the origin in the worst case (before any per-session smoothing), plus one segment fetch per edge node per interval. Confirm the live origin and its signing service can sustain that playlist rate before Stage 3, and set the frequency-control ceiling from Stage 1's measured per-viewer cadence rather than from an assumed average. Record a rollback trigger in advance — for example, sustained playlist 5xx above 1% or HIT ratio flat at zero after five minutes — so the operator reverts to the origin hostname on evidence instead of under pressure during a live event.
| Check | Method | Expected |
|---|---|---|
| Playlist freshness |
curl the m3u8 twice, 5 s apart; compare MEDIA-SEQUENCE
|
Sequence advances; X-Site-Cache-Status: BYPASS or MISS
|
| Segment caching |
curl one .ts URL twice |
First MISS, second HIT
|
| 404 not pinned | Request a nonexistent .ts twice |
Both MISS (no cached 404 HIT) |
| CORS |
curl -I -H "Origin: https://www.example.com" on m3u8 |
Access-Control-Allow-Origin present and correct |
| Signing pass-through | Play with valid / tampered auth_key
|
200 playback / 403 rejected |
| Player matrix | hls.js on Chrome, Safari native HLS, iOS/Android SDK, 10-min session | Continuous playback, no segment 404s |
| Abuse control | Single-IP high-frequency pull simulation | Requests throttled/blocked; blocked traffic unbilled |
Record baseline HIT ratio (near-zero HIT on playlists by design, rising HIT on segments with concurrency) and keep the Eagleid header handy from any failing request for support tracing.
T-1 day: purge the live directory, confirm rule order and status-code settings, re-validate rate-limit thresholds, confirm DDoS protection level. T-1 hour: open security and DDoS analytics, brief on-call on the Eagleid procedure. During the event: watch playlist MISS ratio and 4xx spikes; a sudden segment-404 wave means stale playlists — purge and re-verify rule 1. Post-event: export DDoS and security summaries to size next quarter's protection.
| Symptom | Likely cause | Fix |
|---|---|---|
| Every request 404s at origin | Origin Host/SNI missing | Step 3 |
| Playback starts, then segments 404 | Stale playlist cached (long m3u8 TTL) | Rule 1 bypass/short TTL + purge |
| Failure persists long after origin recovers | 404 negative-cached via origin Cache-Control
|
Status-code rule + purge |
| Browser player fails, native apps fine | CORS headers missing | Step 5 |
| Native apps fail after enabling bot rules | Interactive challenge on media paths | D6 / Step 6 |
| 403 on segments | Signing expired, or query stripped from cache key/origin | Check validity window; D4 |
| Origin load unchanged after onboarding | Query strings ignored, or rule order wrong | D4; move rule 1 to top |
This solution changes nothing about how you produce live streams: the integration surface is one DNS record, one hostname swap in the play URL, and a page of edge rules. What changes is where the work happens — segments served from a dense edge, attacks absorbed before they reach billing-relevant traffic, and the origin reduced to a control-plane role it was always best suited for.
9 posts | 1 followers
FollowBryan, Zhang - October 7, 2026
Bryan, Zhang - June 17, 2026
Bryan, Zhang - October 5, 2026
Bryan, Zhang - June 23, 2026
Alibaba Clouder - July 8, 2020
Bryan, Zhang - May 20, 2026
9 posts | 1 followers
Follow
Broadcast Live Solution
This solution provides tools and best practices to ensure a live stream is ingested, processed and distributed to a global audience.
Learn More
Edge Security Acceleration (Original DCDN)
Edge Security Acceleration (ESA) provides capabilities for edge acceleration, edge security, and edge computing. ESA adopts an easy-to-use interactive design and accelerates and protects websites, applications, and APIs to improve the performance and experience of access to web applications.
Learn More
Real-Time Streaming
Provides low latency and high concurrency, helping improve the user experience for your live-streaming
Learn More
Real-Time Livestreaming Solutions
Stream sports and events on the Internet smoothly to worldwide audiences concurrently
Learn MoreMore Posts by ESA Big Fan