判断应用层洪泛攻击造成源站资源耗尽的判断方法，关键不是看到请求变多就立即判定攻击，而是确认请求压力是否与源站资源消耗、服务能力下降同步出现。连接数、工作线程和后端资源的变化，比单看访问量更能说明问题。
先确认连接压力是否与服务退化同时发生
应用层洪泛通常表现为大量看似正常的业务请求持续到达。它可能针对搜索、登录、商品详情或查询接口；即使单个请求不大，频繁访问也会占用连接、应用处理能力或数据库资源。单独的流量峰值并不能证明源站已耗尽资源。
优先观察四类指标：并发连接数反映同时维持的连接压力；请求速率显示单位时间内到达的请求量；活动工作线程可反映应用正在处理的任务；数据库连接池的使用量及等待情况则能帮助判断压力是否传导到后端。若这些指标在同一时段上升，同时响应延迟增加、超时或错误增多，才更像资源受压链条。
用基线和时间关系排除误判
先选取业务正常时段作对照，尽量比较相近星期和相近时间，而不是拿节假日促销时段与普通工作日直接比较。可在监控面板上按1分钟、5分钟和15分钟窗口查看趋势：短窗口用于发现突发，较长窗口用于判断压力是否持续。具体判断阈值取决于应用容量和日常波动，不宜套用统一数字。
Nginx 的 stub_status 可查看活动连接以及正在读取、写入和等待的连接数，但它只反映接入层连接情况，不能独立证明应用或数据库耗尽。若连接等待增加，而活动工作线程和数据库连接池仍有余量，问题可能在网络或上游排队；若工作线程长期占满、数据库连接等待同步增长，且请求处理时间变长，则应继续排查后端瓶颈。Prometheus 等监控系统可将这些时序指标放在同一时间轴上对照。
按步骤核对请求来源与资源消耗
- 确认影响范围：记录告警起始时间、受影响接口、延迟和错误变化，并核对发布、促销或批量任务等正常业务事件。
- 对齐连接和资源指标：查看并发连接数、请求速率、活动工作线程、数据库连接池，以及主机的内存、文件描述符等容量指标，确认变化是否同起同落。
- 抽样检查访问日志：按接口、请求方法、来源地址和响应耗时分组，留意访问集中于少数昂贵接口、重复模式异常，或多个来源产生相似请求的情况。单一来源数量多并非充分证据，代理和共享出口也会影响分布。
- 验证缓解效果：在确认异常特征后，优先对高成本接口设置合理限速、排队或临时访问控制，并观察连接、线程、等待量和错误率是否回落。每次只调整一类策略，记录时间与影响，避免误伤正常用户。
区分源站耗尽与其他故障
如果请求速率上升但资源指标稳定，且业务延迟没有明显变化，更可能是容量尚能承受的流量增长；如果资源接近自身容量上限并伴随服务退化，才支持源站资源耗尽的判断。若请求量不高、响应却变慢，也要检查慢查询、外部依赖和近期变更，避免把应用故障误认成洪泛。
应用层洪泛攻击造成源站资源耗尽的判断方法，应当以多项指标的时间关联和日志证据为依据，而不是凭单一告警封禁大量来源。先定位被占用的资源，再采取范围有限、可观察的缓解措施，判断会更稳妥，也更容易减少误拦截。
常见问题
请求量增加就能确定是洪泛吗？
不能。业务活动、客户端重试或正常访问增长也会抬高请求量，需要结合来源特征、资源指标和服务表现判断。
连接数高但响应正常，是否代表资源耗尽？
不一定。连接数高说明连接压力较大，若工作线程、后端连接和响应延迟仍正常，源站可能尚未达到能力边界。
优先限制来源地址是否合适？
只有在来源特征明确且确认不会误伤共享出口用户时才适合。来源分散时，按接口成本和请求行为限速通常更有针对性。
监控数据应该保留多长时间？
应至少覆盖故障前、故障中和缓解后的阶段，并结合现有监控保留策略。具体时长取决于排查周期与存储能力。