CDN和WAF一起用，速度和安全能不能兼得？🚀

先说一个容易被忽略的事实：WAF是会增加延迟的。它要解析请求、匹配规则，必要时还得缓存请求体，这些都是实打实的计算开销。所以"又快又安全"不是开个开关就能拿到的结果，配置不当的话，两头都落不着。

下面讲的是让两者相互配合而不是相互拖累的具体做法。

一、CDN提速的关键不是接入，是缓存命中率 📊

接上CDN却没感觉变快，十有八九是命中率太低。几个高频原因：

缓存键设计出了问题。 推广链接常带的追踪参数（utm_source、渠道标识之类），如果被计入缓存键，同一张图片会因为参数不同生成几十份独立缓存，命中率直接崩掉。正确做法是在CDN配置里把无关参数忽略掉，只保留真正影响内容的参数。

Set-Cookie污染了静态资源。 带Set-Cookie响应头的内容，共享缓存默认不会缓存。很多站点的CSS、JS、图片是从主域名发出的，顺带把会话Cookie也带上了，结果全部不可缓存。解决办法是把静态资源放到独立的无Cookie域名下。

TTL设置一刀切。 静态资源应该配长缓存时间，通过文件名加哈希做版本控制（改内容就改文件名）；而动态接口、个人中心这类页面必须明确标记不缓存，否则会出现A用户看到B用户数据的严重问题。

传输层还有空间可挖： 启用Brotli压缩，对HTML、CSS、JS这类文本资源的压缩率优于传统Gzip；开启HTTP/2实现多路复用；有条件再上HTTP/3（QUIC），它对丢包环境和移动网络的改善尤其明显；TLS 1.3能把握手往返次数减少一轮，首次连接的体感差异不小。

回源侧别忘了： 开启回源长连接（Keep-Alive），避免每次回源都重新建立TCP和TLS；大文件启用分片回源，能显著降低首字节等待时间。

二、WAF的性能损耗怎么压下来 ⚙️

按路径分级检测，不要全站一把梭。
图片、字体、CSS这类静态资源，跑SQL注入和命令注入规则毫无意义，纯属浪费算力。把深度检测集中在动态接口、表单提交、登录和支付路径上，静态路径走轻量规则或直接放行。

限制请求体检测大小。
文件上传接口如果每次都全量扫描几十MB的请求体，延迟会非常难看。设一个合理的检测上限，超出部分改用其他手段管控。

人机校验按需触发。
默认给所有访客发JS挑战，正常用户的首屏时间会明显变长。合理的做法是设阈值——只有当某个IP或指纹的请求频率、行为模式出现异常时才触发校验。

三、被低估的协同点：缓存本身就是防护 🔑

这条值得单独讲。命中边缘缓存的请求根本不会回源，意味着一次针对首页的CC攻击，如果首页缓存命中率高，绝大部分请求会被边缘节点直接消化掉，源站压力几乎不变。

反过来，WAF日志能帮你优化缓存。日志里高频出现的扫描路径、异常参数组合，说明有人在探你的接口；这些路径要么单独限流，要么直接封禁，同时还能提醒你哪些接口设计得过于开放。

所以提升命中率和提升抗压能力，在很大程度上是同一件事。

四、既不快也不安全的典型配置 🚩

• 源站真实IP还能被直连。 攻击者绕过CDN直接打源站，加速和防护同时归零。源站防火墙必须只放行回源IP段，这是所有配置里优先级最高的一条。
• 全站默认开最严规则。 误杀率和延迟双高，最后被迫全部关掉，等于白买。
• 证书链不完整。 部分客户端会因为补链失败导致握手变慢甚至报错，而站长自己用的浏览器可能完全正常，很难发现。
• 动态内容被误缓存。 轻则数据不实时，重则用户信息串号。

五、上线后盯这几个数字 📈

缓存命中率要分两个看：请求命中率（多少次请求命中）和字节命中率（多少流量命中）。大文件多的站点，两个数字差距会很大，节省带宽看字节命中率更准。

TTFB和P95延迟，别只看平均值，平均值会掩盖长尾问题。

回源带宽，接入后如果没明显下降，说明缓存策略基本没生效。

拦截量与误报率，拦截数上升不一定是好事，先确认拦的是真攻击还是自己的业务请求。

六、推荐的落地顺序 ✅

别把加速和防护同时开。分四步走，出问题时才知道是哪一环：

1. 先只接加速，跑一周，把缓存规则调到理想命中率，记录性能基线。
2. 再开WAF观察模式，只记录不拦截，收集一周误报样本。
3. 配好白名单后切拦截模式，重点放行富文本提交、搜索接口、上传接口。
4. 最后锁死源站，切断直连通道。

蓝易云CDN官网标注其方案采用傲盾DDoS防火墙并支持WAF防护，具备Anycast近源清洗和智能人机识别能力，节点覆盖全球约60个地区，属于加速与防护在同一链路上的一体化形态，适合不想分开对接多家服务商的中小团队。

不管选哪家，上面这套配置逻辑和验证顺序都是通用的。具体参数和套餐以官方实时方案为准，配置前先在测试域名上验证一轮，别拿生产环境试错。😊