同样是访问量突然升高，处理方式可能完全不同：有的流量在到达服务器前就占满链路，有的请求则能正常建立连接，却反复消耗应用资源。判断应用层防护与网络层流量清洗的适用场景，关键是看攻击发生在哪一层、影响了什么资源，而不是只看请求数量。
先看两种防护分别拦什么
网络层流量清洗主要处理网络和传输层的异常流量，例如异常数据包、连接洪泛和协议滥用。它通常部署在流量进入业务网络之前，适合在带宽、网络设备或连接表受压时分流、识别并过滤恶意流量。它的优势是能较早减轻基础设施压力；局限是难以仅凭网络特征判断一条合法的网页请求是否有业务恶意。
应用层防护检查 HTTP 请求及其上下文，可借助 WAF 规则、访问频率限制、身份验证和行为分析，拦截恶意路径、异常参数或过密的业务操作。它更适合保护登录、搜索、下单等具体功能，但流量若已堵塞上游链路，应用层设备可能收不到正常用户的请求，单独使用便不够。
五类场景，按症状选防护
1. 外部链路拥塞，多个服务同时变慢
如果入口带宽持续接近上限，网页、文件下载等不同服务都出现超时，而服务器本身资源未必同步耗尽，应优先排查网络层流量。需要由上游清洗异常流量，避免其继续挤占链路。此时只增加 WAF 规则，无法释放已经被占用的带宽。
2. 连接大量建立，应用请求却不明显
短时间内连接数异常、网络设备连接状态增多，但应用日志没有相应增长，可能是 TCP 连接洪泛等传输层问题。可先核对防火墙连接计数、服务器连接状态与应用访问日志，再请网络防护侧检查流量特征。过滤应针对异常来源、协议和连接行为，避免误伤正常长连接。
3. 少数网页接口拖垮应用
如果网络流量并未显著增加，Nginx 访问日志却显示某个 HTTP 路径请求密集，且该路径会触发搜索、报表或复杂查询，重点应转向应用层防护。可对相关路径设置频率限制、缓存或验证要求，并检查数据库查询耗时。仅按来源地址封禁可能误伤共享网络中的正常用户；限速也要结合正常业务峰值调整。
4. 登录、注册接口出现异常尝试
登录请求可能格式完整、连接正常，风险体现在短时间内反复尝试不同凭据或账号。网络层清洗通常无法判断凭据尝试是否合理。应用层可采用逐步限速、验证码或多因素验证，并按账号、设备和请求行为综合判断；还应避免把失败次数过多的真实用户永久锁定。
5. 大流量与业务接口滥用同时出现
若链路压力和特定接口负载同时升高，说明问题可能跨越多个层级。网络层清洗先缓解入口压力，应用层再识别恶意路径、异常参数和操作频率。两侧应共享事件时间、受影响服务和处置状态，防止一侧过滤成功后，另一侧仍被剩余请求拖累。
按证据执行排查与选择
- 确认影响范围：记录异常开始时间、受影响域名或功能，以及用户看到的错误；比较不同服务是否同时变慢。
- 对照三类指标：查看入口流量与丢包、连接状态变化、应用访问日志中的路径和响应时间。指标应与该服务自身的正常时段比较，不宜照搬固定阈值。
- 按瓶颈选措施：链路或连接资源受压，优先联系网络侧评估清洗；特定 HTTP 功能耗尽应用资源，先处理对应接口和访问行为。
- 小范围验证并复查：先对单一路径或明确的异常特征应用规则，再观察误拦、响应时间和错误率；情况缓解后仍要检查剩余入口与日志。
因此，应用层防护与网络层流量清洗的适用场景并非二选一：前者针对请求意图和业务行为，后者应对基础网络承载压力。先定位瓶颈，再按攻击特征分层处置，通常比单纯扩大拦截范围更稳妥。
常见问题
能只部署应用层防护吗？
若主要风险是接口滥用或恶意 HTTP 请求，应用层措施可能是重点；但链路拥塞或连接洪泛仍需网络层处置。
网络层清洗能识别恶意登录吗？
通常不能可靠判断凭据尝试的业务意图。登录频率、账号行为和验证流程更适合由应用层控制。
出现异常流量后，先看哪个指标？
先确认影响范围，再同时对照入口流量、连接状态和应用日志。单一指标不足以准确判断攻击层级。
两种防护可以同时开启吗？
可以，尤其适合混合型事件。规则需明确各自负责的流量特征，并持续检查正常请求是否被误拦。