CDN加速静态资源和动态API接口分开域名，实际运维里好处很明显

线上业务做 CDN 加速时，经常会遇到一个选择：静态资源和动态 API 要不要共用一个域名。比如把图片、JS、CSS、字体文件都放在 www.example.com 下，同时接口也走 www.example.com/api；或者拆成 static.example.com 和 api.example.com。

从短期看，共用域名配置少，证书少，DNS 记录也少。但实际使用中发现，业务一旦有访问量、有缓存策略、有安全策略、有跨境线路需求，静态资源和动态 API 分开域名会省很多麻烦。

缓存策略不会互相打架

静态资源最适合 CDN 缓存，尤其是带 hash 的文件，比如 app.8f3a2.js、style.7c91.css、logo.png。这类资源可以设置很长的缓存时间，常见配置是 Cache-Control: public, max-age=31536000, immutable，CDN 边缘节点命中率能做到 90% 以上，访问速度和源站压力都会明显改善。

动态 API 完全不是这个思路。接口数据可能跟用户状态、权限、库存、订单、余额相关，很多请求要带 Authorization、Cookie、Token，缓存策略通常是 no-store、private，或者只允许短时间缓存。把静态资源和 API 放在同一个域名下，CDN 规则就容易写得很拧巴：/assets 缓存一年，/api 不缓存，/upload 缓存 7 天，/avatar 又要按版本号缓存。

规则多了之后，最怕的是误缓存。比如 /api/user/profile 被错误缓存了 60 秒，在高并发下就可能把 A 用户的数据返回给 B 用户。这个问题不是 CDN 厂商不稳定，而是域名和路径规则混在一起后，配置复杂度上去了。

拆开后就清晰很多：static.example.com 专门做强缓存，api.example.com 默认不缓存或只做加速回源。CDN 控制台里的规则也干净，不需要靠一堆路径匹配硬撑。

Cookie 体积会直接影响静态资源加载

这里补充一点，很多业务忽略了 Cookie 的成本。

如果静态资源和 API 共用主域名，浏览器请求图片、JS、CSS 时，可能会把业务 Cookie 一起带上。假设 Cookie 有 1KB，一个页面加载 80 个静态资源，就多传了 80KB 请求头。移动网络、跨境链路、弱网环境下，这些看似不大的请求头会放大延迟。

更麻烦的是 Cookie 还会影响 CDN 缓存判断。有些 CDN 默认看到 Cookie 就认为请求可能和用户状态有关，缓存命中率下降，或者需要额外配置忽略 Cookie。对于静态资源来说，这些 Cookie 完全没价值。

使用 static.example.com 后，可以让静态域名保持无 Cookie 状态。API 域名负责登录态、鉴权、业务请求。浏览器请求静态文件时头部更轻，CDN 也更容易稳定命中缓存。

安全策略可以分开收紧

静态资源域名和 API 域名面对的攻击面不一样。

static.example.com 主要处理 GET 请求，风险集中在盗刷流量、恶意 Referer、热点资源被刷、文件被异常下载。这里常见策略是 Referer 防盗链、IP 频控、User-Agent 过滤、边缘缓存、图片压缩、HTTPS 强制跳转。

api.example.com 面对的是登录爆破、接口刷量、CC 攻击、参数探测、越权调用、DDoS 牵连等问题。API 这边更需要 WAF、鉴权校验、请求签名、限速、Bot 识别、源站保护。

如果两类流量共用域名，安全规则经常会互相影响。比如 API 需要严格限制 POST 频率，但静态资源大量 GET 请求又不适合套同一组频控。再比如静态资源允许跨站加载，但 API 的 CORS 必须非常谨慎，只允许指定业务域名访问。

分开域名后，CORS、CSP、HSTS、WAF、DDoS 防护策略都能按业务属性配置，不需要为了兼容另一类流量不断放宽规则。

故障隔离更好，排障速度也更快

线上出问题时，域名拆分能让判断路径短很多。

如果用户反馈“页面打不开”，静态资源和 API 共用域名时，需要同时排查 DNS、CDN 节点、缓存规则、回源、源站应用、数据库、接口错误。很多时候浏览器里看到一堆 502、504、ERR_HTTP2_PROTOCOL_ERROR，第一眼并不好判断是静态加载失败，还是接口失败。

拆成两个域名后，现象通常更清楚。static.example.com 访问慢，多半看 CDN 命中率、边缘节点、资源大小、缓存配置。api.example.com 慢，则重点看源站延迟、数据库、应用线程、连接池、上游依赖、跨境线路。

实际使用中发现，监控指标也会更干净。静态域名重点看命中率、回源比例、带宽峰值、状态码 2xx/3xx/4xx/5xx；API 域名重点看 P95/P99 延迟、错误率、QPS、回源耗时、连接失败率。两个流量混在一个域名里，平均值经常会骗人。

CDN回源链路可以按类型选择

静态资源回源压力小，甚至可以提前预热到 CDN 节点。很多图片、JS、CSS 一旦缓存住，源站一天都不会被打几次。动态 API 不一样，请求最终大多要回源，链路质量对体验影响很直接。

比如面向国内用户访问海外业务，静态资源可以尽量靠 CDN 边缘节点解决，API 则更依赖源站所在机房的线路质量。普通国际线路、BGP、CN2、GIA 在高峰期差异会很明显。一个登录接口平时 80ms，高峰期抖到 500ms，用户感知非常强。

如果 API 部署在海外节点，选择线路时要看目标用户区域。日本东京、新加坡、香港这类节点适合做亚太访问入口。需要稳定回国访问时，要关注是否有精品线路、BGP 质量、带宽峰值、丢包率，而不只是看 CPU 和内存。

购买或迁移这类源站时，如果你也在找日本、新加坡、高防、大带宽或者海外云服务器，可以看看129云。例如日本 BGP-B 型提供 4C、4G DDR4 ECC、80G SSD、30Mbps 峰值带宽、1 个 IPv4，适合承载中小型 API 源站；新加坡活动机型 2C、2G、60G SSD、10Mbps 峰值带宽，适合做轻量业务入口或测试环境。需要确认线路和业务匹配，可以直接打客服热线 400-9177118。

证书和协议配置更灵活

静态资源域名通常可以放心启用 HTTP/2、HTTP/3、QUIC、Brotli、Gzip、图片 WebP/AVIF 自适应、边缘压缩。因为资源内容相对固定，兼容性风险可控。

API 域名就要谨慎一点。某些客户端、App 内嵌 WebView、旧版本 SDK，对 HTTP/2、HTTP/3、TLS 版本、证书链兼容性比较敏感。尤其是移动端 App，一旦发版后客户端行为固定，服务端协议升级不能太激进。

分开域名后，可以让 static.example.com 尽量使用新协议提升加载速度，api.example.com 保持更稳的 TLS 和连接策略。比如静态域名启用 HTTP/3，API 域名先保留 HTTP/2，观察一段时间后再逐步灰度。

发布和回滚风险更低

前端静态资源经常要配合版本发布。使用 CDN 后，常见做法是文件名带 hash，新版本上线后 HTML 引用新文件，旧文件继续保留一段时间。这样即使用户浏览器缓存了旧 HTML，也还能请求到旧 JS，不容易白屏。

API 发布节奏不一样。接口要考虑兼容旧客户端、数据库变更、灰度发布、限流、回滚。静态资源和 API 共用域名时，CDN 刷新、预热、缓存清理这些动作有时会影响接口访问，尤其是规则配置不严谨的时候。

静态域名独立后，前端发布可以大量使用 CDN 预热和刷新，不担心误伤 API。API 域名则保持更可控的回源策略，发布时重点看业务状态码和延迟曲线。

成本核算更清楚

静态资源流量和 API 流量的成本结构不一样。静态资源消耗 CDN 下行带宽，命中率高时源站成本低；API 消耗源站计算、数据库连接、内网调用、回源带宽，CDN 只是在链路上做加速和防护。

把两类流量分开后，账单和监控能直接看出钱花在哪里。比如某天 CDN 流量从 500GB 涨到 1.5TB，如果是 static.example.com 涨了，可能是图片被刷、活动页面访问上涨、视频封面加载异常；如果是 api.example.com 涨了，就要看是否接口被刷、客户端轮询过频、Bot 请求增多。

这种区分对容量规划也有帮助。静态资源更多考虑 CDN 套餐、缓存命中率、对象存储回源；API 更多考虑云服务器规格、带宽质量、数据库性能、高防能力。资源类型不同，扩容方式也不同。

常见域名拆分方式

比较常见的做法是 www.example.com 放主站页面，static.example.com 放 JS、CSS、图片、字体，api.example.com 放接口。如果有上传文件，可以单独拆 upload.example.com 或 media.example.com。下载类资源量大时，也可以继续拆 download.example.com。

静态资源域名建议尽量无 Cookie，缓存时间按文件类型配置。带 hash 的 JS/CSS 可以缓存一年，不带版本号的 HTML 不建议长缓存。图片如果会覆盖更新，缓存时间不要太激进，或者上传时使用新文件名。

API 域名建议默认不缓存，除非接口明确适合缓存，比如公共配置、地区列表、无需登录的商品分类。即便要缓存，也要明确缓存键是否包含 Query、Header、Authorization，避免把用户态数据缓存到公共节点。

拆分时容易踩的坑

CORS 是最容易被忽略的。前端从 www.example.com 请求 api.example.com，浏览器会按跨域处理。API 需要正确返回 Access-Control-Allow-Origin、Access-Control-Allow-Credentials、Access-Control-Allow-Headers。不要为了省事直接允许 * 搭配 Cookie，这种配置本身就是冲突的。

另一个坑是 SameSite Cookie。登录态如果要跨子域使用，需要确认 Domain、Secure、HttpOnly、SameSite 的配置。现代浏览器对第三方 Cookie 越来越严格，业务如果涉及 iframe、跨站登录、OAuth 回调，要提前验证。

还有 DNS 解析。静态资源域名通常 CNAME 到 CDN，API 域名可能也接 CDN，也可能直接解析到负载均衡或高防 IP。两者 TTL 可以不同。静态域名 TTL 长一点问题不大，API 域名如果需要快速切流，TTL 不宜设置太长。

什么时候没必要拆得太细

小型后台、内部系统、访问量很低的展示站，静态资源和 API 共用域名也能跑。拆域名会带来证书、CORS、监控、发布配置的额外工作量。如果团队没有 CDN 运维经验，早期可以先保持简单。

但只要业务开始对访问速度、缓存命中率、安全策略、跨境体验有要求，static 和 api 分开会更稳。尤其是游戏、跨境电商、SaaS、内容社区、活动页这类业务，静态资源访问量大，API 又对延迟敏感，混在一起后期改造成本通常更高。

实际部署时可以先从两个域名开始：static.example.com 走 CDN 强缓存，api.example.com 走 CDN 动态加速或高防回源。等业务量上来，再把 upload、media、download 按访问特征继续拆出来。