网站平时访问很稳，某天突然变慢、接口超时、后台打不开，很多人第一反应是“服务器是不是不够用了”。这个判断不一定错，但如果只盯着 CPU 和内存，很容易把真正的问题漏掉。突发流量可能来自正常活动、搜索引擎抓取、接口被刷、图片外链、恶意扫描，也可能只是缓存失效后把压力重新打回源站。
排查这类问题的关键，不是马上升级配置，而是先把“谁在访问、访问了什么、压力落在哪里”拆开看。下面按线上处理顺序，把一次突发流量排查拆成几个可执行步骤。
先确认是不是流量问题
用户反馈网站慢时，先不要急着修改配置。第一步应该确认慢在哪里：是首页打开慢、后台登录慢、接口响应慢，还是只有部分地区慢。可以同时看浏览器访问、服务器负载、Web 服务状态和监控面板。如果 CPU、负载、连接数、带宽或磁盘 IO 在同一时间段明显抬高，基本可以判断服务器端确实承受了额外压力。
如果资源指标没有明显变化，但用户仍然感觉慢，就要把 DNS、CDN、运营商线路、证书握手和前端资源加载也纳入范围。突发流量排查最怕先入为主，把所有慢都归因到“机器不够”。只有先确认瓶颈位置，后面的动作才不会越修越乱。
看访问日志的入口
Web 日志是判断突发流量来源的核心证据。Nginx 通常看 access.log 和 error.log，Apache 则看访问日志和错误日志。可以先按时间段截取异常窗口，再统计访问 IP、URL、状态码、User-Agent 和响应大小。真正有价值的不是单条日志，而是聚合后的趋势。
例如某个 IP 每分钟请求上千次，说明可能存在爬虫或攻击；某个动态接口占据大部分请求，说明业务逻辑或缓存需要检查；大量 404 可能是扫描；大量 499、502、504 则说明用户端中断、上游超时或后端处理能力已经跟不上。先把日志分组统计出来，才能判断下一步是限流、加缓存、优化接口，还是扩容。
区分正常访问和异常请求
不是所有突增访问都应该拦截。活动推广、搜索引擎收录、社交平台转发，都可能带来短时间流量峰值。正常访问通常 URL 分布比较自然，静态资源、列表页、详情页都有；异常请求则往往集中在少数接口、登录页、搜索页、不存在的路径，或者 User-Agent 明显伪装。
判断时可以重点看四类特征：访问频率是否异常、路径是否集中、状态码是否异常、来源是否单一。如果单个 IP 或一小段网段反复请求登录、搜索、接口提交等高成本路径，就不该只靠升级服务器硬扛。更合理的做法是加验证码、限速、WAF 规则、接口签名或临时封禁。
检查缓存是否被绕过
突发流量真正压垮网站的常见原因，是缓存没有命中。静态页面、图片、CSS、JS 如果能被 CDN 或本地缓存承接，源站压力通常可控；但如果所有请求都进入 PHP、数据库或后端接口，再高的带宽也救不了响应时间。尤其是带查询参数的 URL、登录态页面、搜索结果页、购物车、后台接口，往往天然不适合直接缓存。
可以检查 CDN 命中率、Nginx 缓存规则、WordPress 缓存插件、接口响应头和数据库查询量。如果发现访问量增加后数据库连接数、慢查询、PHP-FPM 进程数同步上升，就说明缓存层没有挡住压力。此时优先处理高频动态路径，而不是盲目增加前端静态资源缓存。
再决定限流还是扩容
如果突发流量来自异常请求，优先做限流和拦截。Nginx 可以通过 limit_req、limit_conn 控制频率，防火墙可以临时封禁明显异常 IP，CDN 或 WAF 可以按路径、地区、User-Agent 制定规则。对登录、搜索、评论、表单提交这类高成本入口，还可以加入验证码或频率限制。
如果流量是真实业务增长，就要考虑扩容和架构调整。短期可以提升带宽、CPU、内存，或把静态资源交给 CDN；中期要拆分数据库、缓存、队列和后台任务。对于面向国内外用户的网站，线路选择也会影响体感。比如需要兼顾大陆访问和海外业务时，可以根据用户分布选择速维云的云服务器或香港服务器方案，把线路、带宽和业务峰值一起评估，而不是只看单项配置。
复盘要留下规则
突发流量处理完以后，最容易被忽略的是复盘。建议记录异常时间、峰值访问量、主要来源、影响接口、采取动作和最终效果。这样下次再出现类似情况，就不用从零开始猜。尤其是临时封禁、限流规则、缓存调整，最好写清楚生效范围和回滚方式，避免几天后忘记原因。
更稳妥的做法，是把关键指标纳入日常监控：QPS、状态码比例、带宽、连接数、后端响应时间、数据库慢查询、磁盘 IO、缓存命中率都值得关注。网站不是等到被打慢才开始运维，平时把日志、监控和应急规则准备好，突发流量来了才有余地处理。
