攻击流量清洗后，入口流量下降只是第一步，源站可能仍在处理清洗前积压的请求，或因连接、队列和缓存压力而响应缓慢。新手做攻击流量清洗后源站性能恢复与容量检查，应先确认业务是否恢复，再判断现有资源能否承受正常访问与短时波动，不能只看流量图是否回落。
先确认恢复的是业务，而不只是入口
先从外部和源站内部各验证一次。外部检查页面、登录等关键功能是否可用；内部查看应用日志和监控，确认请求成功率、响应时间、错误率是否回到平时区间。若没有历史基线，可与攻击前相近时段比较，并标记流量、发布和计划任务等差异。
重点关注 5xx 错误、连接超时、页面间歇性失败，以及用户操作后数据是否正常写入。入口流量恢复正常，但 Nginx 错误日志仍持续出现上游超时，说明应用或其依赖可能尚未恢复。不要用一次首页打开成功，代替对核心业务流程的验证。
按资源层次检查残留压力
主机与应用进程
观察 CPU、内存、磁盘空间和磁盘读写等待。短时峰值未必代表异常，连续数分钟偏高、同时伴随响应变慢或错误增加，更值得处理。可把 CPU 长时间超过约 70%—80%作为排查提示，而不是通用故障线；可用空间低于约 10%—15%时，也应留意日志增长、临时文件和写入失败风险。具体阈值要结合机器规格和业务基线调整。
检查应用进程是否反复重启，工作队列是否持续增长，日志是否出现重复报错。若使用 Java 服务，还要留意垃圾回收频率和堆内存占用；若是 PHP 应用，则可核对 PHP-FPM 工作进程是否长期占满。不同技术栈指标不同，不要把单个监控数值当成全部结论。
数据库与依赖服务
检查 PostgreSQL 或 MySQL 的活跃连接、等待连接和慢查询情况，并核实连接池是否接近上限。若连接数未回落，应用线程可能仍被占用；若查询变慢，应进一步区分数据库负载、锁等待和磁盘瓶颈。Redis 等缓存服务则应查看内存使用、命中情况和积压任务；缓存命中率突然下降时，数据库负担可能随之增加。
用小步验证估算剩余容量
记录当前正常访问下的请求速率、p95 响应时间、错误率及 CPU、内存占用，作为恢复检查的快照。
核对回源带宽、应用进程、数据库连接池和后台队列是否仍有余量。可将持续保留约 20%—30%资源作为初步规划参考，但突发流量、机器规格和服务架构会改变合适比例。
先恢复少量真实用户流量或逐步放开访问，观察数分钟至十几分钟；具体观察时长取决于访问波动和任务周期。每次调整后记录指标变化，避免同时改动多个配置。
若响应时间或错误率再次上升，先暂停扩大流量，确认问题来自源站还是依赖服务，再决定是否扩容、限制非关键任务或继续保持防护。不要为了追求流量全开而忽略资源余量。
确认关键功能稳定后，继续观察至少一个业务高峰或完整任务周期，并保留监控截图、日志时间段和变更记录，便于复盘。
攻击流量清洗后源站性能恢复与容量检查的重点，是把“请求已减少”与“服务可持续承载”分开判断。尤其要同时看响应时间、错误率和资源余量：指标相互印证，才适合逐步恢复正常访问。
常见问题
流量降下来了，为什么页面仍然慢？
可能有请求积压、应用进程耗尽、数据库连接等待或缓存失效等情况。结合应用日志、队列和依赖服务指标逐层排查。
没有攻击前的监控数据怎么办？
先记录当前指标，并与相近时段的业务量、错误日志和用户反馈交叉核对。之后建立日常基线，避免下一次只能凭感觉判断。
什么时候可以完全恢复流量？
关键功能正常、错误率和响应时间稳定，且主机与依赖服务保有余量后，再分阶段放开。若放量时指标反弹，应暂停并重新定位瓶颈。
CPU 不高，是否代表容量足够？
不一定。磁盘等待、数据库连接池、网络带宽或单个应用队列都可能先成为瓶颈，应结合多项指标判断。
做好攻击流量清洗后源站性能恢复与容量检查，才能确认源站不仅恢复响应，也能在正常波动下稳定运行。