流量突增时，先限流，再加带宽这是治标和治本的顺序，顺序错了，系统崩溃的概率会成倍增加。 给带宽扩容，解决的是“路够不够宽”的问题；限流，解决的是“服务器还扛不扛得住”的问题，流量冲进来的那一瞬间，你真正能救命的操作，往往是先把闸门关小一点。
流量突增为什么不能先加带宽
很多人的第一反应是：带宽不够，升带宽就完事了，这个逻辑在平时没错，但在突发流量面前，有两个致命的时间差和成本问题。
云厂商的带宽生效有时间差
控制台点开“升配”按钮，看似简单，但实际上云厂商的带宽调整需要经过路由策略下发、交换机配置变更等步骤，快则几十秒，慢则几分钟。在这几分钟里，流量已经像洪水一样灌进来，服务器早就被冲垮了，在故障场景下，每一秒都决定服务是“短暂抖动”还是“彻底宕机”，多数事故从检测到异常到服务不可用，窗口期只有3-5分钟，你等不起。
带宽不是唯一瓶颈，甚至不是主要瓶颈
行业内有一个共识：突发流量导致站点打不开，绝大多数情况下不是带宽不够，而是后端应用层先扛不住了，数据库连接数爆了、CPU跑满、内存溢出、PHP-FPM进程全部阻塞……这些才是压垮系统的最后一根稻草，你升了带宽，流量进来得更多更快，后端资源被加速耗尽，结果是系统崩溃得更彻底。
一个典型的场景：一台4核8G的云服务器，出口带宽跑满需要好几个G的流量，但服务器本身的并发处理能力可能几百个请求就顶不住了，带宽升得再大，后端就那么多“座位”，人挤人，谁都进不来。
成本账：临时带宽不便宜
云服务器的临时带宽,价格通常是包年带宽的数倍甚至十几倍，如果流量尖峰只持续十几分钟，你直接升配带宽，花的钱可能是按天算的，下午还得手动降回来，一个不小心忘记降配，账单直接爆表。
先限流，业务稳定了，再评估是临时升带宽还是加机器，成本就会可控得多。
什么情况下可以“先加带宽”
直接定死“必须先限流”也不对，有一种场景确实应该先升带宽。
判断标准：只有带宽是短板的时候
如果你的应用是无状态的,比如静态文件下载站、视频分发节点、CDN回源，后端负载很低，CPU和内存余量充足，唯独带宽被打满100%，那么这个时候，带宽就是唯一的瓶颈。在带宽和资源同时告急时先限流；如果只有带宽告急，直接升带宽是最高效的解法。
怎么判断？进监控系统，看三个指标：CPU利用率、内存使用率、带宽占用率，前两项都在安全水位以下，只有带宽打满，那就是加带宽，反之，CPU、内存、数据库连接数全部告急，你还加带宽，那就是给火堆里添柴。
一个更稳妥的折中方案
拿不准的时候就不要做选择题。先在网关层把流量拦一下，限一个略高于当前处理能力的安全阈值，然后去升带宽，等带宽生效了，再把限流阈值慢慢调高，整个过程业务不间断，这套流程，是线上事故处理的标准操作，业内专家指出，双管齐下才是应对流量突增最稳妥的策略。
限流的具体操作路径
既然先限流是核心,那限流到底怎么做？不扯复杂的概念，直接讲可落地的步骤。
接入层限流：Nginx 配置
Nginx 的 limit_req 模块，是大多数场景下最快速有效的限流方式，在 http 块或 server 块中，加一段配置：
limit_req_zone $binary_remote_addr zone=mylimit:10m rate=10r/s;
server {
location / {
limit_req zone=mylimit burst=20 nodelay;
proxy_pass http://backend;
}
}
这条配置的意思是：每个IP每秒允许10个请求，突发情况下可以额外放行20个，改完配置，
nginx -t 验证后 reload，服务基本不需要中断，几十秒内就能把流量挡住。
网关层限流：动态调整更灵活
如果你的架构里有API网关（比如Spring Cloud Gateway、Kong或云上自带的网关产品），限流阈值可以动态调整，不用改代码。网关层面按服务维度设置QPS上限，比如下单服务允许2000 QPS，超出直接返回“系统繁忙”，这样即使流量冲进来，核心接口也不会被拖垮。
云监控 + 告警：第一时间发现异常
限流的前提是你得知道自己被打爆了。在云监控面板上，把带宽使用率、CPU使用率、QPS这三个指标加上告警规则，阈值设到80%，触发后通过短信、电话通知运维，很多公司服务器流量突发处理不及时，不是不知道怎么处理，而是发现问题太晚，告警先行，你才有时间去操作限流。
加带宽的正确姿势
限流把系统稳住了,接下来才考虑扩容，这一步操作不难，但有几个细节值得注意。
临时升配的操作路径
以主流云厂商为例,登录控制台，找到你的云服务器实例，进入“更多”菜单，选择“网络配置”或“调整带宽”，把带宽临时提升到目标值。注意选择“按量/按天付费”模式，不要直接改包年包月的配置，后者要等工单审核，前者几乎秒级生效，更适合应急场景。
先小步扩容，别一步到位
流量突增的规模你可能还没摸清,别一口气把带宽从10M升到200M。先升到50M，观察后端负载和实际带宽占用情况，如果带宽依然打满，再继续升，一来避免浪费钱云服务器临时带宽价格不低；二来防止扩容幅度过大，后端流量涌入过快，直接压垮数据库，比如常见的场景，某华东地区电商公司大促期间流量翻倍，运维先限流、再加带宽，最后加了两台应用服务器，系统平稳扛过了峰值。
带宽恢复正常后记得降配
流量高峰过去,带宽峰值回落到正常水平，记得去控制台把临时带宽取消，这步操作不难，但特别容易忘，欠费事小，下个月账单翻倍才是真疼，给所有临时升配操作设置一个提醒，或者写在运维交接表里，避免遗漏。
常见问题解答
Q：带宽已经升了，为什么流量还是进不来？
典型的“盲人摸象”式操作，只加带宽相当于把高速公路入口拓宽了，但收费站（应用服务器）就那么几个窗口，车全堵在入口，这时候的瓶颈在后端，检查CPU、内存和数据库连接数，大概率已经濒临上限，正确做法是先限流，把请求控制在系统能承载的范围内，再逐步扩容后端资源，等后端有余量了，再放开接入层限流阈值。
Q：Nginx限流会误伤正常用户吗？
会,但这个“误伤”是层面的选择，当流量超出系统承载能力时，保护整体可用性优先于部分请求的可用性，用 burst 参数设置一个合理缓冲，可以过滤掉大部分突发请求，正常用户的低频访问基本不受影响，真正健康的风控策略是：优先保证老用户和核心接口的可用率，新用户或边缘请求可以拒绝掉一部分，对于一次性流量高峰，返回标准的限流提示页面，用户刷新后即可恢复。
Q：流量突增先限流还是先加带宽，栈长怎么判断？
一句话：看监控，不看感觉，打开监控面板，带宽打到红线，CPU和内存仍然有比较大的余量，优先升带宽；CPU、内存、数据库连接数全部告急，则先限流保命，最怕的情况是：后端起火，你还往带宽上加煤，每次操作前先做30秒的状态评估，判断瓶颈在哪个环节，再做决定。