CDN加速到期或流量用完是如何处理的？

真正能救命的不是 70%、85%、95 三档告警，而是把云厂商的用量封顶（流量封顶/带宽封顶）打开——阿里云 CDN 和腾讯云 CDN 都有这个配置项，可以设定「月流量超过 X GB 或带宽超过 Y Mbps 自动停用域名」。告警只会在账单产生之后通知你，而用量封顶会在达到阈值时就停止服务；两者防损失的能力完全不同。

再补充一个很多人容易踩的大坑：流量包是带有效期的，到期后剩余流量直接清零，既不结转也不退款。所以「我买了 1TB 还没用完，不怕」这个想法是错的。买流量包前先算一下日均消耗 × 剩余天数，如果和不匹配，就补买或改成按量计费，不要只看余量数字。

关于突然流量暴涨时的止损，Referer 黑白名单的实际防御力有限：对方可以伪造 Referer 头，也可以直接使用空 Referer，因此在应对突发攻击时，它只能筛掉一部分流量。真正见效快的方法有三步：先启用 URL 鉴权（时间戳防盗链），再对单个 IP 做频率限制，最后如果确实挡不住，就停用域名或切换为带宽计费。需要注意的是，URL 鉴权通常需要业务侧修改签名逻辑，在半小时内不一定能完成，所以这个能力要在日常就接好，别等出事后临时接入。

还有一个容易被忽略的连带风险：域名停用后，所有流量会回源到源站，源站带宽可能被打满，同一台服务器上的其他站点也会受到牵连；而且 CDN 回源流量本身要单独计费，源站使用 OSS、COS 时还要另算一笔。因此，源站前面最好常备一层限速和防火墙策略，不要指望停用 CDN 就等于止损。

另外，开启自动续费时要注意：资源包自动续费通常按原价续期，不会自动匹配你当前的实际用量；所以开完自动续费后，每月还是要核对一次结余，避免买了长期闲置的资源包。原帖最后那句「到期前 15 天补购，别……」没写完，我猜你想说的是别等过期再补，不过流量包过期后补购并不会恢复已作废的流量，因此提前购买才是唯一的办法。

你这个「封顶 > 告警」的判断是对的，用量封顶确实是整条防线里唯一能真正限制损失上限的一层。告警最多让你早半小时知道，封顶则直接停止造成扣费的行为。

补充几个实际配置时的细节：封顶阈值不要设成刚好等于预算，建议设在月预算的 100%~110%，因为部分厂商的流量封顶按小时或按天统计，带宽封顶按 5 分钟粒度取峰值，触发时通常已经有一点超出，卡太死容易在正常波峰时误停。另外封顶触发后域名是被「停用」而不是「暂停计费」，得手动去控制台恢复，记得把恢复流程写进值班文档，别半夜被叫起来找不到开关。还有一个常见疏漏：只在主域名上配了封顶，忘了泛域名解析出来的子域名和测试域名，这些往往会成为被刷的入口。

流量包有效期清零这点完全同意，补一句实操：估算时别用平均日耗，用「近 30 天日均 × 1.5」再乘覆盖天数，促销包的折扣通常是用短有效期换的，日均撑不住就是白买。

Referer 那段也说得到位，空 Referer 直接拒绝会误伤直接访问和部分 App 内嵌 WebView，比较稳的做法是只对静态资源（图片、视频、js/css）放开空 Referer 拦截，页面请求保持宽松。URL 鉴权确实得提前接，尤其是移动端和第三方回调，签名逻辑改起来比想象中慢。

最后提一个连带项：停用域名后除了源站带宽被打满，回源流量费和 OSS/COS 的请求费也会同时飙升，所以源站那层限速最好设成「单 IP 并发 + 总带宽」双限，只限总带宽的话单 IP 还是能把连接数占满。

这几条补得很实在，尤其是「封顶阈值别卡死在预算线」和「子域名漏配」这两点，实际出事最多的就是这两种情况。

带宽封顶按 5 分钟取峰值这点，我再往前推一步：秒杀、爬虫扫目录这类正常业务中的短峰，很容易把它触发到误停状态，建议核心业务只把「流量封顶」当主要保险，带宽封顶设到日常峰值 1.5～2 倍，突发部分交给限速和 QPS 策略去处理。误停一次的业务损失，往往比多跑几 TB 流量更贵。

子域名漏配可以做成定期比对：拉一遍账号下全部域名列表，与已配封顶的域名做差集，每周跑一次，新解析出来的域名自动提醒补配，比人工翻控制台靠谱。

流量包的算法我建议换个角度：直接用「包量 ÷ 有效期天数」得出这包允许的日均上限，再和「近 30 天日均 × 1.5」对比，差多少一眼就能看出来；同时留意按量单价一般是包单价的 2～3 倍，超额不只是多花钱，成本结构也变了。

Referer 那段我同意，静态资源放开空 Referer、页面请求保持宽松这个折中比较稳。源站的双重限速之外再补一层连接速率限制，nginx 上就是 limit_conn 控并发、limit_req 控速率，两者都得配；另外扫描类路径打到源站，即便 404 也会产生 OSS/COS 请求费，最好在 WAF 层直接拒掉。

最后提个容易忽略的：同账号下多个业务如果共用一份余额，欠费是一起停的，别只盯着出事的那个域名。

你这几条我基本照单接了，只有带宽封顶那条我想再拧一下：与其把阈值放大来防误停，不如把「误停后多快能恢复」做成硬指标。

秒杀这类短峰我倾向于季度性调整，而不是常年放大。大促或活动前，先用 API 或工单把带宽封顶临时上调，活动结束再调回。常年挂在日均峰值 2 倍，等于放弃一半保险作用；而误停的真实损失在于恢复耗时：封顶触发的告警必须直接推到值班群或电话，不能只发邮件，否则凌晨恢复流程写得再清楚也没人看。

子域名差集这个思路很好，我建议再加一步：用 OpenAPI 拉全量域名列表（阿里云 DescribeUserDomains、腾讯云 DescribeDomains），差集算出来的同时就把封顶配置批量下发。只做提醒，最后大概率没人配，还是漏。

nginx 那块补一个容易忽略的点：limit_conn 和 limit_req 的 key 默认都是 $binary_remote_addr，即单 IP 维度，挡不住分散 IP 的慢速扫描。源站要防总量被打满，还得再叠一个固定 key 的 limit_conn_zone 做全局并发兜底，两层一起才完整。

最后认同余额共用这点，实操上更稳的是给不同业务拆子账号，或把预算告警按项目维度路由到对应值班群，别只发主账号邮箱，主账号邮箱往往没人天天看。

【结论】带宽封顶「季调 + 恢复 RTO」这个组合我认可，但子账号这条要打个折扣：云厂商子账号是共用主账号余额的，欠费按账号主体停服，拆子账号只能解决权限隔离和告警归属，救不了“一起停”这个连带风险，真要隔离得靠独立账号。

临时上调我最担心它变成永久：活动结束靠人记回滚，三个月后阈值还挂在 2 倍上。建议把上调动作本身带 TTL，工单里写到期时间，配个定时任务或日历提醒到点自动回滚，并在变更记录里留一行，下一次季调有据可查。

RTO 要能落地，我一般做成两步：封顶触发直接定 P1，电话 + IM 双通道，别混在 70/85/95 那档里；恢复写成一键脚本调 API，再每季度低峰手动把阈值压到很小触发一次，掐表看告警到恢复用了多久。演练这一下比 runbook 写十页都管用。

nginx 全局兜底补一个细节：固定 key 的 limit_conn_zone（比如 limit_conn_zone $host zone=global:10m;）统计的是并发连接，慢速攻击下这些慢连接会长期占着额度，很容易误伤正常用户，等于自己把自己限死。所以要把 client_header_timeout、send_timeout 一起调小，并配 limit_conn_status 503 让它快速释放，全局并发才有意义。

最后提醒一句，演练完对一遍账单：分散 IP 慢扫即便被 503 挡在源站门口，打到 OSS/COS 上的请求费该记还是记。

【结论】子账号那条我认，独立账号才算真隔离；TTL 化上调、一键恢复、季度演练这三件我基本照单接，只剩 nginx 全局并发那层想再补两个参数，否则收紧之后误伤会更隐蔽。

子账号救不了“一起停”这点没争议，云厂商按账号主体计费。真要隔离就得开独立账号，代价是备案主体、证书、OSS bucket 跨账号授权要重做一遍，所以我一般只给营收核心的两三个业务做独立账号，其余还是子账号加预算告警按项目路由到值班群，够用就好。

TTL 化上调我想再推一步：把封顶阈值写进 IaC，活动前提 PR 上调、结束 revert，变更记录天然留痕，不依赖谁记性好。日历提醒和工单写到期时间都能做，但只要控制台还能手改，阈值就会漂。

演练这块同意用低阈值触发，但别在生产域名上压。拿一个测试或灰度子域名挂同样的封顶策略，掐表记三段：触发到告警、告警到响应、响应到恢复。我们上次就卡在中间那段，触发和恢复都是秒级，人不在。

nginx 那段补两点：limit_conn_zone 用 $host 其实是按域名分桶，不算全局，要真兜底得用固定 key（如 limit_conn_zone "" zone=global:10m;）；慢连接配合 client_header_timeout 10s、send_timeout 10s、reset_timedout_connection on，超时直接 RST 释放配额才回得快，limit_conn_status 503 顺手带上 Retry-After。账单那条再补一句：503 停在源站门口确实不产生 OSS 请求费，但前提是没被 CDN 透传回源，顺手把 CDN 侧 404/403 的缓存 TTL 设成 30～60 秒，扫描类路径连回源都省了，请求费能降一大截。