流量突然翻倍，不等于遭遇攻击；请求量看似正常，也可能掩盖针对少数接口的恶意访问。判断拒绝服务攻击期间如何区分用户激增与恶意请求，应把流量变化与用户行为、服务压力和业务结果放在一起看，不能只凭单一告警或某个来源下结论。
先看六项指标，而不是只盯总请求数
1. 流量是否符合可解释的基线
将当前请求速率与相同星期、相近时段的历史数据比较，并结合已知的发布、通知或公共事件。可以先按5分钟窗口观察；若流量达到常态的数倍并持续多个窗口，值得升级排查，但这个倍数本身不能证明攻击。合法活动也可能造成陡升，关键是变化是否有业务原因、是否符合以往峰值形态。
2. 请求集中在哪些路径和操作
按接口路径、HTTP 方法和状态码拆分请求。真实访问常覆盖首页、搜索、详情和提交等不同功能；恶意流量可能集中冲击登录、搜索或耗费计算资源的接口，也可能反复请求不存在的路径。若全站请求都增加，影响与只有一个接口激增不同：后者应优先检查该接口的请求量、错误率和资源消耗。
3. 会话行为是否连贯
观察一次会话是否包含页面加载、后续查询和正常操作，还是大量请求以固定间隔重复同一动作。浏览器加载页面时通常会产生不同类型的资源请求；自动化请求则可能呈现高度重复的路径和参数。不过，辅助技术、应用程序和搜索引擎爬虫也会产生非典型行为，不能仅凭请求规律就封禁。
4. 来源分布是否突然失衡
查看来源网络、自治系统编号（ASN）、地区及客户端类型的分布变化，并与业务受众相比较。新地区访问增加可能来自媒体曝光或活动传播；来源极度集中也可能是企业网络、校园网络或移动运营商出口的共同表现。应结合请求内容与成功行为判断，避免把某个地区或网络整体当作恶意来源。
5. 连接与协议表现是否异常
比较新建连接数、并发连接、连接持续时间、重置比例及协议错误。短时间出现大量连接建立后立即中断，或连接数上升而有效请求、完成响应没有同步增加，可能提示资源消耗型流量。反过来，正常客户端网络不稳定也会造成重试和断连，因此还要核对服务端连接池、负载均衡器和应用日志。
6. 业务结果与资源压力是否同步
把请求曲线与延迟、错误率、CPU、内存、队列长度和业务完成量并排查看。合法需求上涨时，成功页面访问、查询或提交通常也会增加；攻击可能让请求量上升，却没有相应的有效业务结果，并推高延迟或错误。用p95延迟（95%的请求不超过该时长）观察尾部体验，并与正常时段及同类接口比较。
现场核验：按顺序收集证据
记录异常开始时间、请求速率、受影响路径和服务指标，统一使用相同时间窗口；不要只截取最高峰。
调取访问日志与监控数据，按路径、方法、状态码、会话、来源网络和客户端类别分组，寻找多个指标同时变化的部分。
核对发布记录、公告、营销活动和外部访问来源。若流量峰值紧随公开事件出现，且访问路径、完成行为相符，更支持用户激增的判断，但仍需确认服务承压情况。
检查重复请求比例、无效请求比例和单位时间内的失败情况。可将异常窗口与过去相似时段对比；样本少或日志不完整时，先标记为待确认，不急于扩大拦截。
必要时先采取可回退的限流或挑战措施，按接口逐步实施，同时观察有效请求成功率、延迟和错误率。措施生效后若误伤增加，应缩小范围或恢复原策略。
要回答拒绝服务攻击期间如何区分用户激增与恶意请求，实用判断方式是交叉验证：流量异常、行为重复、来源分布变化、连接特征异常和业务结果脱节中，若多项同时出现，攻击可能性才更值得重视。高流量但访问路径多样、有效操作同步增长且来源符合事件背景，更像真实需求；两类情况也可能同时存在。
常见问题
请求量增长多少就可以认定遭受攻击？
没有适用于所有服务的固定倍数。应结合历史基线、持续时间、受影响接口和服务指标判断；短时峰值只能触发核查，不能单独定性。
来源集中是否代表恶意流量？
不一定。共享网络、校园出口和移动网络都可能让大量真实用户看起来来自少数网络，应再核对会话行为、请求路径和业务完成情况。
证据不完整时应先封禁吗？
优先选择范围小、可回退的限流或验证措施，并监测正常请求是否受影响。避免仅依据地区或单个客户端特征采取大范围封禁。
最终，判断拒绝服务攻击期间如何区分用户激增与恶意请求，要看六项指标是否形成一致证据链，并在处置中持续检查误伤与服务恢复情况。