SiteGround 应对突发流量：内容爆了、被大 V 转发、促销日流量翻十倍怎么办

突发流量为什么容易搞挂网站

绝大多数站点平时跑得挺稳，一遇到流量高峰就崩，根本原因不是「主机不行」，而是架构没为高峰准备。默认状态下：

每个访客都要执行一遍 PHP、查一遍数据库
图片、CSS、JS 都从源服务器直出
缓存可能没开、或者规则不完整
数据库连接池、PHP 进程数、内存都是按平时量配的

流量翻十倍，等于让同一套资源做十倍的活，很快就跑满 CPU、内存或 IO。这时候服务器只能开始拒绝新请求——就是你看到的 502/503。

好消息是：SiteGround 从最低档 StartUp 起就自带了应对突发流量的核心工具（动态缓存、免费 CDN、SG Optimizer 插件），只是很多人从来没打开过。下面按时间线走一遍。

事前配置：平时就该打开的四个开关

这四件事最好在流量来之前就做完。做完之后，即使突然来一波高峰，也大概率扛得住。

1. 打开动态缓存（Dynamic Cache）

Site Tools → Speed → Caching，把 Dynamic Cache 打开。它会把 WordPress 生成的完整 HTML 缓存下来，后续访客直接吃缓存，不再走 PHP 和数据库。

一个站点开缓存前后的差别可能是几十倍——原本每个请求要执行几百毫秒的 PHP，现在直接返回静态 HTML，几毫秒搞定。

需要注意的例外：

登录后台的用户默认绕过缓存（否则会看到别人的购物车/评论草稿）
WooCommerce 的购物车、结账、我的账户页面要排除在缓存外
装了会员/表单类插件的，看下插件文档有没有推荐的缓存排除规则

SiteGround 的缓存已经内置了大部分 WordPress/WooCommerce 的合理排除规则，一般不用手工调。

2. 打开 Memcached

同一个 Speed 页面下，Memcached 也打开。它是对象缓存，把数据库查询结果缓存到内存里，那些不能整页缓存的动态请求（比如后台、购物车）也能少查很多次数据库。

动态缓存 + Memcached 是标配组合，两个都开才完整。详细的缓存配置见缓存设置指南。

3. 启用免费 CDN

Site Tools → Speed → CDN，一键启用 SiteGround 自带的免费 CDN。启用后：

静态资源（图片、CSS、JS、字体）从离访客最近的边缘节点返回
源服务器压力大幅降低
全球访客访问速度均衡

对突发流量场景，CDN 还有一个隐藏作用：边缘节点会吸收掉大部分请求，源服务器只处理真正需要动态生成的那一小部分。等于给你的服务器加了一层缓冲区。

如果对 CDN 有更细的配置需求（自定义缓存规则、按路径 purge），可以看CDN 使用指南。

4. 装 SG Optimizer 并配置好

SG Optimizer 是 SiteGround 官方的 WordPress 性能插件，配合前面的服务端缓存做前端优化：

图片懒加载和 WebP 转换
前端资源合并压缩（CSS/JS minify、combine）
关键 CSS 内联
浏览器缓存头
Heartbeat API 降频（WordPress 后台每 15 秒 ping 一次服务器，高峰期这个也要限流）

插件本身免费，在 WordPress 后台插件仓库直接搜就有。装完按提示一路开启即可，不需要额外配置。

事中应对：流量已经打进来了，怎么快速稳住

如果你正在看实时统计发现流量暴涨，或者已经开始收到 502 报告，按下面顺序处理：

第一步：确认缓存命中率

去 Site Tools → Statistics → Traffic 或 Speed → Caching 看缓存命中比例。正常应该在 80% 以上。如果命中率很低，说明大量请求走了 PHP，服务器很容易撑不住。

命中率低的常见原因：

缓存刚清过（等 5-10 分钟重新暖起来）
页面被 URL 参数打散（?utm_source=xxx 之类）——用 SG Optimizer 或缓存规则忽略这些参数
主题/插件在页面上加了动态内容（比如随机推荐、实时在线人数），导致每次输出都不一样，缓存没法命中

第二步：临时关闭不必要的动态元素

流量高峰期，能省则省：

关掉实时在线人数、最新评论滚动、随机推荐这类每请求都要查库的模块
关掉 WooCommerce 的最近浏览/相关商品如果它们没走对象缓存
临时停掉重量级插件（比如某些表单插件、A/B 测试插件、日志插件）

这些都是可以在 WordPress 后台一键停用的，等高峰过去再开回来。

第三步：看资源占用，判断是不是要升档

Site Tools → Statistics → Resource Usage，能看到 CPU 秒数、内存、进程数的实时消耗。如果你的账户资源已经跑到 90% 以上，说明当前档位撑不住了，需要立刻升档。

SiteGround 的档位升级流程见资源限制与档位说明。

第四步：一键升档（不用迁移）

SiteGround 的一个大好处是同账户内升档不用迁移，也不用停机。在用户中心点几下就能从 StartUp 升到 GrowBig 或 GoGeek，服务器资源立即扩容，站点继续跑。

差价按剩余天数折算，几分钟内完成。这一步在流量已经打进来的时候做也来得及——比紧急迁移到别的主机快得多。

第五步：极端情况切云主机

如果你的站点是电商大促、发布会直播导流这种可预期的极端峰值，或者共享档位已经到顶（GoGeek 仍然撑不住），可以考虑切到 Cloud Hosting。云主机是独立资源，不受邻居影响，而且可以按需临时加 CPU/内存。

云主机的价格比共享档贵不少（起步 $100/月量级），但电商大促一天的收入远超这个成本，值不值得算得清。

事后升级：扛过去了，接下来做什么

流量高峰过后，别急着把配置改回去。做几件事：

1. 复盘命中率与资源占用曲线

看 Site Tools 里的历史统计：命中率、CPU 峰值、内存峰值、请求响应时间。这些数据能告诉你下一次该提前多久升档、哪些页面是拖累、哪些插件在高峰时消耗异常。

2. 优化数据库

WordPress 用久了数据库里会积累大量修订版本、垃圾评论、过期 transient。高峰过后跑一次数据库清理（WP-Optimize 或 SG Optimizer 自带）能明显减小数据库体积，日常查询也更快。

3. 图片压缩一遍

如果站点上有很多未压缩的大图，趁这时候批量转成 WebP（SG Optimizer 有这功能）。图片是绝大多数站点的最大流量来源，压一半等于带宽省一半。

4. 决定要不要长期升档

如果这次高峰不是「一次性事件」而是业务增长的信号——比如你的内容开始被更多平台转载、SEO 排名进入正循环、电商订单量稳步上升——那就应该长期升到更高档位，别每次临时抱佛脚。

档位选择的完整逻辑见方案对比和建站路径选择器。

5. 把速度纳入日常监测

用 UptimeRobot、Pingdom、GTmetrix 之类的第三方工具定期跑测，把响应时间、可用性纳入日常监测。等下次高峰来的时候，你会提前几天看到「速度开始变慢」的信号，而不是被 502 打脸才知道。相关的 SLA 与可用性数据见可用性 SLA 指南。

常见误区

误区一：「我流量不大，不用配缓存」——缓存不是给大站准备的，是给所有站准备的。哪怕一天只有 100 访客，开缓存也能让每个访客打开更快，SEO 和转化率都受益。而且真到突发流量那天，你根本来不及配置。

误区二：「升到最贵档就万事大吉」——档位只是资源上限，架构不优化的话，最贵的档位也能被打满。先把缓存、CDN、SG Optimizer 配好，再考虑升档，性价比最高。

误区三：「云主机一定比共享主机快」——不一定。云主机的优势是资源独占和可扩展，日常小流量站点在共享档 GrowBig 上跑得可能比在最低配云主机上还快（因为共享档有 SuperCacher 等预置优化）。云主机适合的场景是「稳定的高流量」或「频繁的高峰」，不是所有站都需要。

误区四：「CDN 会拖慢国内访问」——SiteGround 免费 CDN 在全球有边缘节点，国内访客命中的通常是亚洲节点，不会明显变慢。真正影响国内访问速度的是主机所在的物理机房，选新加坡数据中心会好很多，具体见中国用户访问指南和数据中心选择指南。

结尾

突发流量是好事——说明你的内容或产品被看见了。但好事变成事故，往往就差在「事前有没有把缓存、CDN、SG Optimizer 打开」这几步。

如果你现在用的是 SiteGround，花十分钟把上面「事前配置」的四个开关全部打开，就已经能扛住大多数中小规模的流量高峰了。真到了共享档撑不住的那一天，一键升档或者切云主机的路径也是清晰的，不用临时抓瞎。

还没上 SiteGround 的、正在为「以后万一火了怎么办」焦虑的，可以通过本站链接注册——首年促销价能省一大半，且免费 CDN、动态缓存、SG Optimizer 从最低档就自带，不用另付费。