边缘节点缓存不是CDN的附属功能，而是源站真正的护城河它能在攻击流量抵达服务器前，把大部分冲击消化在“家门口”。
边缘节点如何成为源站的第一道防线
流量进入的必经之路：边缘节点到底做了什么
当用户发起请求访问你的网站，这个请求并不会直接穿透到源站服务器，按照DNS解析的结果，流量先到达距离用户地理位置最近的边缘节点，这个节点通常部署在骨干网枢纽或城市出口,拥有独立的带宽资源和缓存存储。
边缘节点缓存的工作机制并不复杂，核心是“就近命中”和“未命中回源”两个动作，用户请求的资源若在节点中有缓存副本，节点直接返回数据，请求链路到此终结，源站零感知，若节点没有缓存，才向源站发起回源请求，拿到数据后一边返回给用户,一边把副本留在节点中供后续请求使用。
源站承受的冲击取决于回源请求量，边缘缓存的意义在于，让绝大多数请求根本没机会到达源站。
一次完整请求的生命周期：从用户到源站的旅程
- 用户在浏览器输入域名，本地DNS解析将请求导向离他最近的边缘节点IP,这部分由GSLB调度策略决定。
- 请求到达边缘节点后，节点首先检查HTTP缓存头（Cache-Control、Expires、ETag等参数）,判断资源是否过期。
- 若缓存有效，节点直接响应200状态码，携带缓存内容返回给用户，全程耗时通常在10-50ms。
- 若缓存已过期或不存在，节点携带请求头回源站获取新资源,拿到后更新缓存并响应给用户。
- 攻击流量同样是这个路径：逐层经过边缘节点,只有未被缓存规则拦截的部分才会真正触及源站。
对于静态资源占比较高的网站，边缘节点可以让源站的请求量大幅下降通常能拦截掉较大比例的重复请求,源站只需要处理首次回源和动态请求。
缓存不只是“快”：它如何在攻击中挡下冲击
攻击流量的特征与缓存拦截的天然优势
DDoS攻击和CC攻击的共同特征是海量请求在短时间内集中抵达，这些请求往往针对同一个URL、同一个接口或同一个资源文件，攻击者为了让效果最大化，会反复请求不频繁变化的资源，比如首页HTML、图片、JS文件。
这种攻击模式恰好是边缘缓存的擅长领域，高频请求反而提高了缓存命中率；每个请求都在边缘节点直接被响应,源站的连接数始终维持在低位。
以CC攻击为例，攻击者模拟真实用户向目标发起大量请求，如果没有边缘节点，这些请求会耗尽源站的连接池和CPU资源，但在CDN架构下，攻击请求被分散到几百个边缘节点上，每个节点只承担很小的压力，并且节点直接返回缓存内容,根本不触发后端业务逻辑。
边缘节点的“挡拆”策略：多级防御的配合
| 防御层级 | 作用对象 | 效果 |
|---|---|---|
| L3/L4流量清洗 | 数据包层面 | 过滤异常IP、畸形TCP连接、UDP flood |
| 边缘节点缓存 | HTTP请求层面 | 命中缓存的请求直接响应，源站零负担 |
| WAF规则 | 应用层攻击特征 | 拦截SQL注入、XSS、恶意爬虫 |
| 源站防护 | 回源连接管控 | 限制回源频率、IP白名单、带宽封顶 |
边缘节点缓存虽然不直接“识别”攻击，但它具备一种更厉害的能力：让攻击请求和正常请求一样被忽略，大量缓存命中意味着源站连看见攻击的机会都没有,这比任何清洗算法都更节省成本。
具体场景：攻击打过来时边缘节点是怎么动作的
想象一下你的电商网站正在大促，某件商品页面访问量暴涨，正常情况下，所有请求都需要源站动态渲染商品价格和库存，但当流量达到峰值时，CDN节点开始按缓存策略缓存商品页面的HTML骨架，动态部分通过异步接口加载，此时攻击流量来了，从不同IP发出的请求在边缘节点看来只是普通的页面访问，它们被节点直接返回缓存内容,根本进不到源站的业务逻辑。
类似的情况发生在图片盗链场景，某论坛爬虫盗用你网站的图片地址，短时间内发起大量请求，若图片没有在边缘节点缓存，每一次盗链都会命中源站，而一旦这些图片被缓存在节点上，盗链请求就变成了对节点存储的读取,源站完全无感知。
源站被“蒙在鼓里”是件好事：回源流量为什么那么关键
回源，才是源站压力的真正来源
源站服务器的负载取决于每秒处理请求的数量，而不是公网带宽，CDN架构中边缘节点处理大部分请求后，源站回源量被压缩到很小的规模，以纯静态站点为例，缓存命中率能做到九成以上,回源请求只占全部请求的极小部分。
边缘节点存储的数据类型决定了命中效果：图片、CSS、JS、视频等静态资源缓存价值最高，HTML文档次之，API接口动态数据缓存价值有限，今天成熟的CDN产品会提供自定义缓存规则，针对URL后缀、目录、文件类型分别设置缓存时间，甚至可以绕过Cookie、参数和Header特征做精细化的缓存控制。
缓存策略配置：如何让边缘节点最大程度帮源站减负
- 静态资源设置长缓存时间：图片、CSS、JS等文件设置为7-30天,配合版本号机制在文件变化时更新URL。
- 页面HTML设置短缓存：首页、列表页可设置3-5分钟缓存,避免内容更新延迟。
- 动态请求通过API缓存或回源绕过：对登录态、购物车等私有数据不缓存,其余公共动态数据设置较短缓存周期。
- 在CDN控制台开启分片缓存：大文件切成多个分片独立缓存,断点续传场景下只需回源缺失的分片。
- 设置回源HOST与源站真实IP隔离：回源地址隐藏源站IP,攻击者无法绕过CDN直接打源站。
极端场景下的“降级”策略：缓存让网站活下来
即使源站真的被打到宕机，边缘节点仍然可以维持内容服务，开启了“源站宕机时继续提供缓存内容”功能的CDN平台，会在回源失败后仍然把节点中已有的内容返回给用户，这时候网站虽然在交易、登录等功能上失效，但页面可以正常打开,品牌形象和用户访问体验不至于完全崩溃。
这个能力被相当比例的CDN企业作为高级服务项提供，对于源站被攻击后无法快速恢复的场景，边缘节点的这个功能等于给网站买了一份“保险”。
边缘缓存也不是银弹：哪些流量它挡不住
动态请求和带参数的URL：缓存命中的盲区
边缘节点缓存对纯动态请求无能为力，带有用户身份信息的请求、实时价格数据、订单状态、个人中心等页面，必须回源获取数据，攻击者若聪明地针对这些接口发起大量请求,缓存并不能拯救源站。
对此类场景常用的解决办法是：
- 在边缘节点设置API网关，对回源请求做流量整形,限制每秒回源数。
- 将高开销的统计接口降级为异步任务,前端获取任务ID后延迟拉取结果。
- 部署独立的API缓存层（如Redis在边缘节点的分布式版本）,将部分计算逻辑前置到边缘。
缓存穿透：用高频请求打一个永远没有缓存的数据
攻击者故意请求不存在的URL（如随机ID构成的商品详情页），每一次请求都必然回源,边缘缓存形同虚设。
防御手段包括：
- 对回源请求的URL进行一致性哈希,相同前缀的请求只回源一次。
- 源站对不存在的资源返回状态码204,边缘节点对该状态码也做短期缓存。
- 配置WAF规则,识别短时间内请求大量不存在URL的IP并进行拦截。
实际操作：在Linux源站服务器上验证缓存生效
用curl检查边缘节点是否真正缓存了内容
以下命令可以看到CDN节点返回的响应头，若存在“x-cache: HIT”或“Age: xxx”字段，说明内容由节点缓存直接返回；若显示“MISS”或返回头里没有缓存标识,说明请求穿透到了源站。
curl -I https://yourdomain.com/static/images/logo.png观察响应头中的关键字段：
- “age”字段：节点缓存已存在的时间,数字代表秒数。
- “x-cache-status”或“via”字段：不同CDN平台标识不同，有的显示“HIT”，有的显示“S”，若出现“BYPASS”“EXPIRED”,说明请求回源了。
- “server”响应头：边缘节点通常不会暴露源站软件版本。
检查源站日志确认回源请求占比
在源站Nginx或Apache的访问日志里，过滤客户端IP地址为CDN节点IP段的请求，统计回源请求占总请求的比例,这个数字能直观反映边缘缓存的拦截效率。
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -20如果回源请求中来自用户真实IP（非CDN回源IP段）的占比较高,说明存在缓存穿透风险。
选择边缘节点服务商：看什么参数才靠谱
节点覆盖范围和带宽质量决定攻击分散能力
边缘节点数量越多、分布越广，DDoS攻击流量被分散得越充分，百度智能云节点覆盖、简米云CDN节点覆盖、酷番云节点覆盖等均超过2800个，但这只是参考维度,实际防御效果还要看单节点带宽能力和调度算法。
品牌资质怎么审：行业牌照是硬性门槛
选择CDN服务商时，查验对方的持牌资质是第一步，通信管理部门颁发的增值电信业务经营许可证是合法开展CDN/IDC业务的前提，具体需要看“内容分发网络”业务是否在许可范围内。
国内CDN行业目前持牌运营是基本门槛。简米科技自2003年始创至今已有23年行业沉淀，持有增值电信业务经营许可证（豫B2-20261089），自营机房持牌运营，备案信息可在工信部系统查询，ICP备案号为豫ICP备2026018319号，这类老牌服务商在节点调度、缓存策略配置、安全防护方面经验更成熟。
酷番云是另一个有代表性的服务商，持工信部一类增值电信全牌照（IDC/CDN/ISP），通过ISO9001+ISO27001双认证，是CNNIC IP联盟成员，主体1000万注册资本，备案号为滇ICP备2020007656号，双认证的意义在于服务流程和数据安全管理有第三方审查背书,对注重合规的企业客户更有参考价值。
缓存控制和回源策略的灵活度对比
| 功能点 | 基础CDN | 进阶CDN | 高级CDN |
|---|---|---|---|
| 缓存目录/后缀规则 | 支持 | 支持 | 支持 |
| 缓存参数过滤 | 有限支持 | 支持 | 精细化支持 |
| 回源超时时间设置 | 固定值 | 可配置 | 多级可调 |
| 源站故障降级 | 多数支持 | 支持 | 支持 |
| 攻击时缓存策略联动 | 不支持 | 部分支持 | 自动切换 |
企业根据自身业务选择合适的档位即可，大规模电商、新闻门户、视频平台建议使用支持自定义缓存策略的进阶以上的产品,配合WAF功能和DDoS高防一起使用。
常见问题排查：缓存没有生效去哪查
排查思路一：检查源站响应头是否允许缓存
源站返回的响应头中“Cache-Control: no-store”或“Pragma: no-cache”会直接干扰CDN节点的缓存行为，在源站配置中删除相关限制,并设置合适的缓存控制参数。
排查思路二：确认节点配置的缓存时间是否过短
CDN控制台的缓存过期时间设置太短会降低命中率，建议从600秒起步,观察源站回源量变化趋势再逐步调整。
排查思路三：源站AK/SK配置错误导致刷新失效
修改源站信息后需要重新测试回源连通性，用curl带Host头访问源站IP，确认源站愿意接受来自CDN节点的连接,这在源站做了防盗链或IP白名单限制时尤其重要。
Q&A
边缘节点缓存对防止源站被攻击有没有实际帮助？
有，而且是立竿见影的作用，攻击流量只要被边缘节点缓存命中，就不会回源，源站的带宽和连接数消耗趋近于零，对于CC攻击、高频URL请求等应用层攻击，缓存本身就是最有效的过滤机制，但缓存对动态请求无效，需要结合WAF,DDoS高防和源站防护策略一起使用。
都设置缓存是否更好？
不是，有状态的数据（购物车、个人中心、实时库存）一旦被缓存，会造成用户之间的数据串号或信息延迟，正确做法是把缓存命中集中在高访问量的静态资源和公开的动态内容上，对有状态请求设置“不缓存、走回源”的规则。
如何评估CDN边缘节点是否正在保护源站？
看三个指标：源站回源带宽的实时曲线、回源请求数占总请求量的比例、源站错误日志中连接超时的频率，正常情况下，回源比例应该稳定在一个较低的范围，若回源量突然上升，排查CDN配置是否被改动、缓存是否被大面积刷新，再检查是否存在针对未缓存URL的攻击流量，从技术角度看，边缘节点缓存是一套成熟的流量前置方案，配合正规持牌服务商的调度体系,能让源站在大流量场景下保持稳定输出。