AiWCLOUD：高防CDN，大陆节点免备，过移动屏蔽在缓存与回源工程下

一、很多人把“缓存”和“高防”当成两件事

做运维的人常有一种直觉：

CDN 管缓存，高防管攻击，两边各干各的。

但高防CDN 的真实工程难度，恰恰不在“能不能洗掉 500G 攻击”，而在——攻击来了的时候，缓存还在不在？回源会不会被打爆？动态接口会不会被误拦？静态资源更新会不会串版本？

高防CDN 本质上是在同一组数据面上同时跑两条目标：

• 加速目标：让正常请求少回源、低延迟、高命中；
• 安全目标：让异常请求早拦截、不回源、不触达源站。

这两条目标如果分开设计，一定会冲突。比如：

• 为了安全，把所有请求都送回源站做深度检测 → 源站被自己人打死；
• 为了加速，边缘节点无脑缓存一切 → 登录态、订单、API 响应被串给用户；
• 为了防 CC，全局限频太狠 → 学校/企业 NAT、App 批量刷新全部误杀；
• 为了抗 DDoS，回源链路不加密 → 中间人能看到业务报文。

所以高防CDN 的缓存与回源模块，不是“CDN 附带安全”，而是一套带安全约束的内容分发系统。

二、先分语义：什么能缓存，什么绝不能缓存

高防CDN 第一步不是配规则，而是给请求打标签。

1. 可长期缓存：静态资产

图片、CSS、JS、字体、视频切片、安装包、Web 组件。

特征：

• 同一 URL 对所有人返回内容一致；
• 不带用户态；
• 更新靠发版，不靠每次请求。

工程做法：

• 图片 / 字体：30 天以上；
• CSS / JS：7–30 天，但文件名带 hash 或版本号；
• 视频：支持 Range 请求、分片缓存；
• 静态 HTML 模板：数分钟到数小时，看业务更新频率。

2. 可短缓存：半动态公共数据

地区天气、商品类目、公告列表、排行榜、公开配置。

特征：

• 大家看到的一样；
• 但几分钟或几秒就会变；
• 回源成本高于误旧成本。

工程做法：

• TTL 5s / 30s / 60s；
• 后台刷新（background revalidation）；
• 请求合并：100 个用户同时要新排行榜，边缘只回源 1 次。

3. 不缓存：动态与写请求

登录、下单、支付、购物车、用户中心、API 写操作、WebSocket 升级、Token 校验。

特征：

• 带 Cookie / Authorization；
• 同 URL 不同用户结果不同；
• 写请求有副作用。

工程做法：

• Cache-Control: no-store；
• 边缘只做 WAF / 限流 / 人机识别，不缓存响应；
• 回源走独立连接池，和静态回源隔离。

4. 最容易被忽略：错误响应缓存

源站临时 404 / 502 / 302，如果被边缘缓存了，业务恢复后用户仍然看到错误页。

高防CDN 正确做法是：

• 默认不缓存 5xx；
• 404 可按“不存在资源”短缓存，防缓存穿透，但业务接口 404 不缓存；
• 502/504 不缓存或只缓存几秒；
• 用 Cache-Control 响应头优先，控制台规则兜底。

三、缓存穿透：看起来像访问，其实是回源攻击

攻击者不打带宽，只打源站 CPU：

纯文本

/image/abck123.png
/image/x7s9uu.png
/api/product?id=999999999
/api/user?uid=random-uuid

这些 URL 不存在或命中率低，CDN 缓存未命中，全部回源。

源站数据库一查、缓存一 miss、连接一占，业务就挂了。

高防CDN 的应对不是“加带宽”，而是边缘做三件事：

1. 不存在资源短缓存

对 404 静态资源缓存 10–30 秒，避免同一随机路径反复回源。

2. 回源并发配额

每个 URL、每个源站、每个租户有回源并发上限：

• 100 个用户同时要没命中的热点 → 边缘合并成 1 个回源；
• 随机 URL 洪峰 → 超过回源预算直接挑战或拒绝，不压源站。

3. 接口成本评分

/api/login 和 /api/public-banner 成本不同。

高防CDN 给接口打“回源成本分”：

• 低成本：可观察、可合并；
• 高成本：严格限频、强制鉴权、异常即挑战；
• 写接口：不允许重试盲发，幂等键由源站校验。

四、回源连接池：高防CDN 的“隐形性能层”

用户不回源，但边缘要回源。回源链路做不好，加速再好也白搭。

1. 连接复用

边缘到源站开大量短连接，会吃掉：

• TCP 握手时间；
• TLS 握手 CPU；
• 源站 ephemeral port；
• 内核 conntrack 表。

正确做法：

• HTTP/1.1 Keep-Alive；
• HTTP/2 多路复用；
• 边缘到源站复用连接池；
• 不同业务优先级隔离连接池，避免“图片刷新把下单接口挤死”。

2. 回源限速，不是源站限速

攻击期边缘如果疯狂回源，源站比被攻击还惨。

高防CDN 要在边缘做：

• 回源 QPS 预算；
• 单源站最大并发；
• 回源排队时间上限；
• 源站变慢时：先保核心接口，再降级推荐/评论/画像；
• 源站 502/504 时：返回边缘托底页，不把错误链放大给用户。

3. 回源加密与身份

客户端 → 边缘 用 HTTPS，不等于边缘 → 源站 也安全。

高防CDN 生产级架构要求：

• 回源 HTTPS / TLS 1.2+，优先 TLS 1.3；
• OCSP Stapling 减少证书验证延迟；
• 回源 Token / 自定义 Header 校验：源站只认带暗号的回源；
• 高安全场景用 mTLS，源站只信 CDN 客户端证书；
• 独立回源域名，只解析到源站，不挂业务 CDN 记录，防回源环路。

五、攻击态下的缓存策略会自动变形

好的高防CDN 不是“平时一套规则，攻击时人工改”，而是策略随状态切换。

关键点：静态业务在源站挂了以后还能跑，这才是高防CDN 和“只抗流量”的高防 IP 的本质区别。

六、动态加速：高防CDN 不只是缓存静态

很多人以为 CDN 对 API 没用。错。

高防CDN 对动态请求的价值不是缓存，而是：

• 边缘终止 TCP/TLS，源站少做握手；
• 边缘做 WAF、Bot、CC 检查，源站少处理垃圾；
• 边缘到源站走私有骨干网，比公网直连稳；
• 边缘做请求鉴权，非法请求根本不回源；
• 边缘做 API 语义校验：参数畸变、越权字段、重复调用直接拦。

换句话说：

静态内容靠缓存省回源，动态接口靠边缘过滤省源站算力。

七、缓存与安全的冲突点：必须有人拍板

1. 登录页缓存了 → 串号

现象：A 用户登录后，B 用户看到 A 的页面。

根因：把带 Cookie 的 HTML 按 URL 缓存了。

解法：按 Cookie / Authorization / Vary 区分，或干脆不缓存。

2. 价格接口被缓存 → 大促亏钱

现象：商品降价了，用户还看到旧价。

根因：JSON 接口被当成公共数据缓存 5 分钟。

解法：价格/库存类接口短 TTL 或边缘计算拼接，源站出真实价。

3. 防 CC 太严 → App 启动不了

现象：App 冷启动并发请求被限频，首屏白屏。

根因：限速键只用 IP，没区分设备、租户、接口成本。

解法：限速键用 IP + UA + 设备摘要 + 接口成本，NAT 场景降权重。

4. 回源域名和业务域名混用 → 环路

现象：CDN 回源域名也被 CDN 自己代理，死循环。

根因：没用独立 origin 域名。

解法：origin.xxx.com 只解析源站，不开业务 CDN 记录。

八、一套能直接抄的缓存/回源配置模板

text

# 静态资产
/images/*        Cache 30d  Vary: Accept
/css/*          Cache 30d  Filename hash
/js/*           Cache 30d  Filename hash
/fonts/*        Cache 30d
/video/*        Cache 7d   Range enabled
# 半动态公共数据
/api/banner      Cache 30s  Revalidate background
/api/category    Cache 60s
/api/rank        Cache 5s   Collapse requests
# 动态/写接口
/api/login       No cache  WAF + Rate limit + Bot check
/api/cart        No cache  Auth required
/api/order       No cache  Idempotency key
/api/pay         No cache  mTLS + Challenge
# 错误响应
404 static       Cache 10s
404 api          No cache
5xx              No cache
302              No cache unless business rule

回源侧：

text

Origin domain: origin.example.com（独立域名，不挂业务 CDN）
Protocol: HTTPS/TLS1.3
Auth: X-Origin-Token + optional mTLS
Connection pool: per tenant / per priority
Concurrency limit: yes
Retry: read request limited, write request no blind retry
Source firewall: only CDN node IP ranges

九、高防CDN 的“真本事”：攻击时业务像没发生

评价高防CDN 行不行，不要只看：

• 防护多少 T；
• 节点多少个；
• 是不是 Anycast。

要看这几条：

1. 攻击时静态页还能不能开；
2. 登录接口有没有被误杀；
3. 源站 QPS 有没有被边缘拦掉 90%；
4. 回源连接有没有被复用而不是雪崩；
5. 动态 API 有没有边缘鉴权；
6. 源站 IP 是不是公网根本摸不到；
7. 缓存更新有没有版本机制，不串数据。

能做到这 7 条，才是“高防CDN”，不是“CDN 加个防火墙页面”。

十、结语

高防CDN 的技术含量，一半在清洗，一半在缓存与回源工程。

清洗决定“打不打得进来”，缓存与回源决定“平时快不快、攻击时源站死不死、业务数据串不串”。

真正成熟的高防CDN 应该是这样的：

• 正常用户：静态命中、动态低延迟、登录下单不掉链；
• 攻击者：边缘被识别、挑战不过、根本进不了源站；
• 源站：平时只处理真实业务，攻击时连“被照顾”的机会都没有；
• 运维：策略分层、日志可追、误杀可解释、回源可观测。

高防 CDN 不是把攻击挡在外面那么简单。

它是让“加速”和“安全”在同一张边缘网络里，用同一套策略语言说话。