访问突然变慢，不一定是请求总量太大。恶意请求也可能通过反复建立连接、拖延请求完成或占住连接池，让正常用户无法获得服务。判断时应结合多项恶意请求造成连接耗尽的识别指标，并与平时同一时段的数据对照，而不是凭单个告警下结论。
先看连接本身的变化
1. 并发连接数持续偏高
观察服务端当前连接数及其增长速度。若连接数持续上升，超过应用或代理配置的可用容量，且流量并未出现相称的业务增长，需进一步排查。单次短时峰值并不能证明恶意行为；容量上限、正常访问模式和部署规模都会影响判断。
2. 半开连接或连接队列积压
TCP 建连阶段的半开连接增多，或监听套接字的等待队列持续接近上限，可能意味着连接建立速度超过系统处理能力。可在 Linux 上用 ss -s 查看连接状态概况，再结合系统的 TCP 统计和应用日志确认。网络丢包、客户端异常及突发的正常流量也可能造成类似现象。
3. 连接存活时间异常
如果大量连接长期停留在等待数据、等待响应或空闲状态，连接占用时间明显偏离正常情况，就要检查是否存在慢速发送、慢速读取或未及时释放连接。对照应用设定的读取超时、空闲超时和连接复用策略，区分设计上的长连接与异常滞留。
再把请求表现与系统压力对起来
4. 请求速率与连接数不匹配
请求速率没有明显升高，但并发连接数却不断增加，可能说明每条连接占用时间变长；反过来，短时间内大量重复请求也可能迅速占满处理能力。应同时比较请求速率、连接建立速率和请求完成速率。只看每秒请求数，容易漏掉低速但持续占用资源的情况。
5. 超时和服务错误集中出现
连接耗尽常伴随请求超时，以及 502、503、504 等错误上升。使用 Nginx 时，可查看访问日志中的状态码、请求耗时和上游响应耗时；应用侧则检查连接池等待时间及超时记录。某一种错误也可能源于后端故障，需确认它是否与连接数上升在时间上同步。
6. CPU、内存或文件描述符接近限制
大量连接会占用文件描述符、内存和网络处理能力。若连接激增同时出现文件描述符使用量逼近进程限制、内存压力增大或 CPU 长时间繁忙，资源耗尽的判断更有依据。不同系统和应用的容量差异很大，不宜套用一个固定阈值；应以已配置上限、容量测试结果和历史基线为准。
最后核对请求来源与业务背景
7. 来源分布或请求特征高度集中
检查请求是否集中来自少数来源，或在路径、方法、请求头、访问间隔上高度相似。集中访问并不自动等于恶意：健康检查、自动化客户端和正常批处理也会形成规律流量。将访问日志与已知客户端、服务调用关系和请求内容一并核验，避免只按单一特征封禁。
8. 偏离同一业务的历史基线
把当前连接数、请求速率、超时率与相同日期类型、相近时段的记录比较，并结合发布、任务调度或外部依赖故障等事件解释变化。稳定的业务高峰通常有可识别的请求组成和完成结果；异常流量则可能表现为访问模式突变、完成率下降和连接持续占用。基线应按服务分别维护，避免拿不同服务直接比较。
按顺序完成排查
确认告警时间范围，记录连接数、请求速率、错误率和资源使用量的变化。
用系统连接状态信息和代理、应用日志，找出主要连接状态、访问路径及耗时分布。
对照历史基线、近期变更和已知自动化任务，排除正常流量增长及后端故障。
若多项指标同时异常，先按服务的既有应急流程限制异常请求或扩充处理能力，再持续观察正常请求是否恢复；操作后记录影响范围与回滚条件。
归纳来看，恶意请求造成连接耗尽的识别指标不是某个孤立数字，而是连接积压、请求特征、错误变化和资源压力之间的对应关系。至少两类证据同步异常，并排除可解释的业务事件，结论才更可靠。
常见问题
连接数高就代表遭到攻击吗？
不代表。长连接、正常高峰或后端变慢都可能抬高连接数，应结合请求完成率、连接时长和历史基线判断。
只看访问日志够不够？
通常不够。日志能显示请求特征，但未必记录未完成的连接；还应检查操作系统连接状态和应用资源。
发现异常后应立即封禁来源吗？
先核实来源是否属于正常客户端或自动化任务。确认后再按既有应急流程处理，并观察误拦截风险和服务恢复情况。