带宽买再多，也救不了缓存配得一塌糊涂的站。cdn内容在边缘节点上放多久、按什么条件判断“这份东西我这儿有”、什么时候必须回源，这三件事定下来，同一份带宽能扛的访问量差别很大。见过太多人一遇到慢就先升带宽，账单涨上去了，页面还是那个速度——钱花错地方了。
cdn内容的缓存时长，一刀切十分钟最亏
面板里那个“缓存过期时间”，图省事全站填十分钟是最常见的操作。图片视频这种一年都不带变的资源，每十分钟回源拉一次，回源带宽白白烧掉；反过来首页 HTML 缓存十分钟，编辑刚发的稿子自己先看不到，转头就来问客服。合理的做法是按类型分档：图片、视频、字体、压缩包这类带版本号或者极少改动的，时间往长了设；纯 HTML 短一点，几分钟甚至不缓存；接口那类 JSON 干脆不缓存。源站能发 Cache-Control 头的更好，让 CDN 走“遵循源站”，max-age 给浏览器，s-maxage 给共享缓存——s-maxage 只有 CDN 这种共享缓存认，浏览器不认，这点很多人搞混。源站压根不发缓存头的，面板里又不手动配规则，很可能一路不缓存，看着像“接了 CDN 没效果”，八成症结在这儿。
忽略 URL 参数，回源量能掉下来
一张图片的链接后面挂上 ?utm_source=xxx、?from=朋友圈、?v=一串随机数，在缓存系统眼里就是几十份不同的东西，各存一份、各回源一次，节点硬盘被同一张图塞满。去面板里找“忽略参数”或者“参数过滤”，打开，再配个保留名单：真正会改变内容的参数留着，像 id、page、lang、size 这种，推广用的 utm_*、spm、from 和随机数全部丢掉。注意别手一抖全忽略，有些站的文章详情就是靠 ?id= 区分内容的，全忽略等于全站互相串页，那乐子就大了。
缓存键别把 Cookie 带进去
有些默认策略会拿 Cookie 参与缓存键，结果一个访客一份缓存，命中率约等于没有。把“忽略 Cookie”打开，或者只保留跟内容相关的那一两个。但会员中心、购物车、下单、后台这些必须回源，给它们单独配“不缓存”规则，按路径绕过去。别图省事整站不缓存——那 CDN 就退化成一条贵一点的专线，带宽一分没省，钱照花。
回源那一层，带宽真正被吃掉的地方
边缘节点没命中就得回源，回源 HOST 写错是最常见的坑：节点拿着错的 Host 去请求源站，源站回 403 或者 404，用户那边就是一片空白。回源协议也得跟源站对齐，源站只开了 HTTPS，回源还走 HTTP，多半连不上。大文件建议开 Range 回源，别每次都从头拉一遍。还有缓存刚清空或者被瞬间打穿的当口，一堆节点同时回源，源站直接被压趴下，这种时候预热能缓一缓压力。
刷新和预热，不是救命按钮
改版上线按一下“全站刷新”挺爽，等于把缓存全清了，接下来那几个小时的回源压力全砸在源站身上。刷新有配额，也有生效延迟，紧急情况够用，日常更新用目录刷新或者按 URL 刷更稳。预热正好反过来，把热门资源提前推到节点上，大促、发新版本之前推一遍，第一批用户不用干等回源。这两个按钮一个是减法一个是加法，别搞混了用。
怎么确认这几个设置真生效了
别只看“感觉快了”。CDN 报表里有命中率和回源带宽两项，看趋势不看单点。命令行也能验：curl -I 请求一下那张图，看响应头里的 Age、X-Cache、Via 这些字段，Age 有数值说明这份是从缓存里出来的，X-Cache 有的厂商写 HIT 有的写 MISS，具体字段含义以服务商文档为准。源站访问日志里 CDN 回源请求占多大比例，也能反推命中情况。
动手顺序给个建议：先把缓存时长按文件类型分好档，再处理参数和 Cookie 这两个命中率杀手，最后才去动回源和预热。三步做完再回头看带宽，不少站会发现原来的带宽其实是够用的，只是被无效回源吃掉了。带宽是花钱买来的，缓存是配置出来的，后者便宜，也更值钱。
【版权声明】：本站内容若无意侵犯到您的权利，请及时与我们联系将尽快删除相关内容!
