业务突然卡顿、用户大面积反馈打不开页面、后台监控曲线直接拉满——这套流程跑过线上业务的人都不陌生。但这里有个容易栽跟头的判断误区：把所有的访问异常都当成DDoS，或者反过来，明明是DDoS却当成普通流量高峰处理。判断是否遭遇DDoS攻击，核心不是看流量大小，而是看流量的“行为特征”。这篇内容我把最常见的四种特征整理出来，都是可以直接在监控、日志、接入层快速核验的硬指标，不需要依赖复杂的安全设备，哪怕只有一台服务器和一台路由器，也能做出八九不离十的判断。
适合谁看？维护过线上业务、被突发的流量波动折腾过、或者正在搭建基础监控体系的人。内容不涉及商业安全产品的具体用法，全部基于通用网络原理和常见开源工具，看完可以直接对照自己的环境做排查。
1. 判断DDoS的第一步：先分清故障类型
很多人一看到带宽跑满就喊DDoS，其实先别急着下结论。线上业务的访问异常通常分三类：网络层故障（交换机、光缆、路由问题）、服务器层故障（CPU、内存、数据库连接数耗尽）、应用层故障（代码Bug、依赖服务超时）。DDoS攻击只是导致这三类故障的其中一种原因，甚至很多时候攻击者只是“点火”，真正把系统搞垮的是资源配置不合理或者代码健壮性差。
所以判断是否遭遇DDoS攻击，第一个动作不是查攻击特征，而是确认故障的范围和性质。先回答四个问题：是全站不可用还是部分区域不可用？是持续不可用还是间歇性不可用？是只有动态请求受影响还是静态资源也受影响？是用户侧反馈异常还是监控系统主动告警？
这四个问题的答案，能帮你快速缩小排查范围。比如全站不可用且静态资源都加载失败，大概率是网络层或者带宽被塞满；如果是只有登录接口超时、静态资源正常，那更像应用层问题。DDoS攻击的特征从网络层到应用层都有，不同层级的攻击对应的排查手段完全不同，先定位故障层级再判断是否遭受DDoS，思路才会清晰。
这里有一个实践中的判断技巧：用三个时间点做对比——攻击前的正常基线、异常出现时的峰值、异常结束后的回落情况。DDoS攻击的特征之一是流量“来得快、去得也快”，攻击停止后流量通常会迅速回落。如果流量是缓慢爬升又缓慢下降，那更像是业务自然增长或爬虫抓取导致的波动。
2. 四种高辨识度特征：一查便知的判断依据
判断是否遭遇DDoS攻击，真正管用的其实就四种特征。这四种特征分别对应不同攻击层级，组合起来基本能覆盖95%以上的DDoS场景。每一条都可以通过自有监控、流量工具或日志系统来验证，不需要额外采购设备。
2.1 特征一：流量曲线呈“断崖式”突增，且来源IP高度集中
DDoS攻击最直观的特征是流量曲线的形态异常。正常业务流量增长是渐进的，有白天晚上的自然波动，有促销活动带来的脉冲式增长，但无论哪种，流量曲线都是连续且可解释的。DDoS攻击不同——攻击流量通常会在几十秒内完成爆发式增长，曲线像被刀切了一样，从正常水平直接拉满到带宽上限。
这个特征的操作性在于：打开流量监控图，看异常发生前的基线值、异常时的峰值、异常持续的时间。真正的DDoS攻击，流量上升时间通常小于5分钟，峰值流量是基线的几倍甚至几十倍。如果是正常业务高峰，流量上升过程至少以小时为单位。
来源IP的分布是另一个硬指标。常规业务流量的来源IP必然分散，符合用户地理位置的自然分布。DDoS攻击的流量来源则高度集中——可能是某个IP段、某个机房段、某个国家的地址段。验证方法很直接：把异常时段的访问日志按来源IP做聚合统计，如果Top10的IP贡献了超过50%的流量，基本可以判断流量成分不正常。
我在实际排查中见过一个典型案例：某业务高峰期流量突然翻了8倍，最初被当成业务增长。后来拉取访问日志按IP聚合，发现单个IP在5分钟内发起了超过20000次请求，而正常用户几乎不会在5分钟内请求超过100次。IP集中度这个指标，是区分DDoS攻击和正常突发流量的第一道分水岭。
2.2 特征二：请求特征异常，集中在单一目标或特定协议
DDoS攻击不管层级的差别，背后都有一个共同点：攻击者要最大化消耗目标资源，所以攻击流量一定会集中在特定目标上——某个URL、某个API接口、某个页面，或者某些协议类型。正常用户访问路径是发散性的，有人看首页、有人看详情页、有人提交表单，请求分布相对均匀。DDoS攻击的请求分布则高度聚焦。
判断方法：在Web服务器日志里，按URL维度统计请求分布。如果异常时段内，单个URL的请求占比异常升高（比如超过总请求的70%），而这个URL平时占比不到10%，就需要警惕。很多DDoS攻击工具默认只打主页或固定路径，请求特征非常明显。
协议维度的判断也很有价值。如果流量主要消耗在TCP三次握手（表现为大量SYN报文、半连接数暴涨），属于SYN Flood攻击；如果UDP流量异常增大且目标端口集中在少数几个端口，属于UDP Flood攻击。这些在接入层交换机或服务器的连接状态统计里都能直接看到。
我建议的做法是：在Nginx或Apache日志里，临时增加按$request_uri、$http_user_agent、$http_referer三个维度的实时统计，持续观察10分钟。如果统计结果呈现高度集中的趋势，就说明流量成分不自然，大概率是攻击流量。
2.3 特征三：连接与协议行为异常，明显不符合正常用户习惯
这一条是最容易被忽视的，但对判断攻击类型最有帮助。正常用户的访问行为遵循一定的规律：先请求HTML页面，再请求页面里引用的CSS、JS、图片资源；每个连接发起的请求数有限；请求间隔是秒级或毫秒级，但访问总量与页面资源数匹配。
DDoS攻击的协议行为完全不是这样。常见的不符合正常习惯的行为包括：单个连接在极短时间内发起大量请求（正常浏览器一个连接最多同时处理6个请求）；请求间隔时间极短且非常有规律（正常用户有思考时间）；请求的HTTP头不完整或内容异常（缺少User-Agent、Accept等常规字段）；大量请求使用相同的User-Agent或使用明显改动的UA值。
判定方法可以量化为三个指标。第一，连接数与请求数的比例：正常业务一个连接通常对应2~10个请求，攻击流量往往一个连接一个请求，或一个连接对应几十上百个请求。第二，请求的时间间隔分布：正常业务的请求间隔呈自然分布，攻击请求的间隔高度均匀。第三，HTTP头完整率：正常浏览器请求都会带完整的头信息，攻击工具为了提升发包速度，经常省略非必要字段。
实操中，可以用一条命令快速统计当前TCP连接状态：
netstat -ant | awk '{print $6}' | sort | uniq -c | sort -n如果SYN_RECV状态的连接数远高于ESTABLISHED，说明有大量连接卡在三次握手阶段，这是SYN类的攻击特征。正常服务器上SYN_RECV的连接占比很低，且会快速完成握手转为ESTABLISHED或直接关闭。如果SYN_RECV积压持续不降，且数量达到系统最大连接数限制，基本可以认定为SYN Flood攻击。
2.4 特征四：业务指标与流量指标严重偏离
这一条是判断是否“被攻击打趴下”的最核心依据，但很多人会忽略。正常业务场景中，流量增长通常伴随业务指标同步增长——流量翻倍，订单数也应该增长，CPU使用率上升但仍在合理范围，响应时间可能略有增加但整体可用。DDoS攻击场景则完全不同：流量暴涨，但业务指标不涨反跌。
具体表现为：带宽占用从100M涨到800M，但单位时间的有效请求数没增加甚至下降；CPU使用率打满，但处理的业务逻辑请求数没有同步上涨；页面响应时间从200ms涨到10秒以上，但并发用户数没有真实增长。
这里需要特别留意：应用层DDoS攻击的特征是流量不明显、但业务指标剧烈恶化。攻击者模拟真实用户的请求行为，每次请求都消耗大量服务端资源（比如复杂的数据库查询、加密解密计算），单个请求的体积不大，但每个请求都让服务器“做重活”。这种攻击最阴险，因为流量层面看不出异常，只有深入业务指标才能发现。
判断方法：将监控系统里的带宽曲线、QPS（每秒请求数）、CPU使用率、平均响应时间四类指标放在同一个时间轴里对比。如果带宽和QPS暴涨、CPU打满，但成功请求数和业务成交量不变或下降，同时伴随响应时间显著劣化，这就是典型的资源耗尽型攻击特征。
还有一种偏离需要特别注意：请求成功率的异常。正常业务请求成功率在99%以上，如果出现大量请求超时、连接被重置、返回5XX错误，同时流量在涨，说明系统已经无法正常处理请求——要么是资源被耗尽，要么是接入层被堵住。这个现象配合前面三条，可以确定是DDoS攻击，而不是正常流量突发。
3. 实战排查路径：从发现异常到确认攻击的完整流程
判断是否遭遇DDoS攻击，不能只看某一个特征就下结论——需要多条特征交叉验证。这一节把完整排查路径拆出来，照着走一遍，10分钟内基本能出结论。
3.1 先看监控大盘：快速定位异常范围
第一步永远是从全局监控切入。打开你的带宽监控、服务器负载监控、应用性能监控（如果有的话），把异常发生前后的时间段调出来比对。重点看三个时间节点的数据：异常前15分钟的基线数据、异常开始时的拐点、异常过程中的峰值。
这张监控截图会告诉你三类信息：异常的开始时间（用于和业务改动、发布操作做关联排查）、异常的峰值强度（用于判断攻击规模）、异常的持续时间（用于判断攻击节奏）。如果异常发生在凌晨、没有任何业务变更的情况下突然出现，且达到带宽上限，DDoS的嫌疑就很大。
监控数据的选取建议：不要只看单台服务器的数据，要看整个出口链路的数据。因为DDoS攻击通常打到IP或带宽层，单台服务器可能已经被挤掉线，但网络出口的流量数据还在。如果条件允许，直接在路由器和防火墙上查看接口流量统计，这是最准确的第一手数据。
3.2 拉取日志做模式匹配：验证四条特征
监控确认异常后，第二步是拉日志验证特征。按时间窗口（异常开始前5分钟到当前时间）拉取接入层（Nginx、负载均衡）的访问日志，然后做四类统计：按来源IP聚合的请求数Top20；按URL聚合的请求数Top10；按User-Agent聚合的请求数Top10；TCP连接状态统计。
如果日志里出现以下模式：一个或几个IP贡献了绝大多数请求；请求高度集中于某个URL；UA字段为常见攻击工具的标记或大量重复值；SYN_RECV积压——四条特征里面命中两条以上，就可以基本确认是DDoS攻击，接下来要做的就是阻断和防护。
这个环节的效率取决于日志格式是否完善。建议在Nginx日志里打开以下字段：$remote_addr（来源IP）、$request_uri（完整请求路径）、$http_user_agent（UA）、$status（状态码）、$request_time（请求耗时）、$upstream_response_time（后端响应耗时）。命中三轮排查，就不会出现“日志字段不够导致查不下去”的情况。
3.3 用命令行工具做实时观测：动态确认攻击过程
静态日志分析有延迟，如果攻击仍在持续，需要用实时观测工具确认攻击的动态过程。这里分享三组常用的排查命令，都基于Linux系统自带工具，不需要额外安装。
第一组，看网络连接状态：
watch -n 1 'ss -s' watch -n 1 'netstat -ant | grep SYN_RECV | wc -l'ss -s显示系统级TCP统计，能快速看到连接数总量；第二行统计SYN_RECV数量，正常情况下这个数字应该在个位数或十位数，攻击时会飙升到数千甚至数万。
第二组，看流量来源：
tcpdump -i eth0 -nn -c 5000 port 80 | awk '{print $3}' | cut -d. -f1-4 | sort | uniq -c | sort -nr | head这条命令抓取5000个到达80端口的包，按来源IP聚合取Top10。正常场景Top10的占比不会超过20%，攻击场景下Top1就能占30%以上。
第三组，看请求处理效率：
top -bn1 | head -20 uptimeCPU使用率和负载均值能反映攻击是否已经压垮系统。如果CPU在100%附近徘徊，但业务QPS没有同步增长，说明CPU在空转——大量资源在处理垃圾请求。
3.4 交叉验证：从猜测到确认的完整闭环
有了监控数据、日志统计、实时观测三组信息，就可以做交叉验证了。验证的逻辑很简单：问三个问题。
第一，异常流量是否符合“来源集中、目标集中、行为异常”这三个模式？如果全部命中，是DDoS攻击的可能性极高。第二，业务指标是否与流量指标严重偏离？如果带宽在涨但业务量在跌，说明流量不产生业务价值，大概率是攻击流量。第三，异常是否与业务变更（上线、发布、活动）存在时间上的关联？如果没有任何业务变更，异常纯属凭空出现，攻击的可能性再次提升。
三个问题都命中，可以直接认定为DDoS攻击，进入防护流程。如果部分命中，建议继续观察5~10分钟，看特征是否持续。这里要提醒一个反向场景：如果是正常的突发流量（比如某外部平台导流），流量来源分散、请求路径多样、业务指标同步上涨——三条都与之相反，就不能误判成DDoS，否则可能导致错误的封禁操作，把真实用户也挡在门外。
4. 典型误判场景与排查避坑实录
判断DDoS攻击的难点不在“判断本身”，而在“判断准确”。我把实际操作中见过最多的误判场景整理出来，每条都对应一种具体的教训，值得在排查前先过一遍。
4.1 场景一：爬虫流量被当成DDoS
搜索引擎爬虫、数据采集工具、监控探测源，这些正常但“不太守规矩”的流量，和DDoS攻击的行为特征有部分重叠——高IP集中度、规律性请求、特定的UA标记。
区分的关键指标是“请求是否有目的性”。爬虫的请求虽然频繁，但会遵循一定规则：会读取robots.txt、会等待页面加载完成、请求的URL有规律（通常是详情页、列表页）。DDoS攻击的请求基本没有目的性，就是围绕固定目标反复打。
实操建议：如果怀疑是爬虫，先看UA并做反向DNS解析。主流搜索引擎的爬虫UA明确且可验证，且有对应的反解域名。如果UA可疑、IP归属不明、反解失败，再纳入攻击判断。
一个更实用的比例指标：爬虫通常只占总体流量的20%以下（除非站点本身以内容抓取为核心场景）。如果单个来源的流量占比超过总流量的30%，且来源IP在反向DNS中无法识别归属，攻击的可能性大。
4.2 场景二：数据库慢查询导致的“伪DDoS”
这是我自己踩过最深的坑。有一次线上服务查询突然超时严重，流量、带宽都没有异常，但CPU打满、QPS暴跌，第一反应就是被应用层DDoS打了。排查一圈后发现，是有个新上线的报表功能在特定时间触发了一个全表扫描，数据库连接池被占满，后端请求全部排队超时。
教训是什么？业务指标与流量指标偏离时，除了攻击，还要排查自身系统问题。前端流量正常、后端资源被打满的情况，既可能是精准打击后端的应用层DDoS，也可能是自身代码缺陷、数据量增长或慢SQL导致的雪崩。
排查建议：先看慢查询日志和数据级指标（数据库连接数、锁等待时间），再看应用日志中的异常堆栈。如果数据库侧找到明显的慢查询、全表扫描或锁竞争，优先处理自身的性能问题。攻击的特征是“流量有变化”，自身问题的特征通常是“流量没变、性能变了”或“流量没变、性能变了”。
还有一个细节：应用层DDoS攻击通常会持续且有节奏（打一会儿、停一会儿），自身系统问题则往往有明确的触发点（定时任务、特定查询条件、特定页面访问）。查看异常首次出现前5分钟的后台日志，找有没有定时任务启动、缓存过期、冷数据加载的记录。
4.3 场景三：缓存雪崩和热点Key问题被当成DDoS
缓存失效导致大量请求同时穿透到数据库，现象和DDoS非常像：QPS瞬间暴增、数据库压力剧增、响应时间抬高。但本质区别在于：穿透流量来自真实用户，来源IP分散，请求路径多样，且业务指标（订单、页面浏览、登录）在同步上涨。
判断方法回到“特征四”：看业务指标是否同步变化。缓存雪崩时用户能正常使用业务，只是响应变慢，真正成交、访问等业务量不会跌；DDoS攻击时，用户根本进不来，业务指标一定是下跌的。
区分建议：查一下缓存服务的命中率监控。如果命中率在异常时段突然从95%跌到20%，说明是缓存层面的问题；如果命中率没变但流量暴涨，才考虑是攻击流量直接打到接入层。
4.4 场景四：真正的“慢速攻击”容易被漏判
和前面的误判方向相反，有一种DDoS攻击流量特征很不明显——慢速攻击。攻击者建立连接后不发送完整请求，或者以极低速率发数据，把服务器的连接池慢慢占满。这种攻击的流量曲线几乎看不出异常，带宽占用可能只有几Mbps，但连接数会持续爬升，直到服务器无法接受新连接。
判断方法不在流量大小，而在连接数与业务量的比值：连接数持续上升、但实际完成的请求数很低，或大量连接处于空闲/半开状态。用前面的netstat命令观察ESTABLISHED状态的连接数量和持续时间，如果大量连接长时间存在但没有数据交互，就要考虑慢速攻击。
常见的慢速攻击手法包括Slowloris（慢慢发送HTTP请求头）、Slow POST（缓慢发送请求体）和慢速读（客户端缓慢读取响应）。这三种攻击流量层都很安静，但都会导致连接池被占满。识别要点：大量ESTABLISHED连接长时间保持但传输字节数为0或极低。
把这个问题单独提出来，是因为很多团队的监控只做带宽和QPS，没有做连接数的趋势监控。慢速攻击会让带宽指标“看起来正常”，但业务已经不可用，这是最容易漏判的攻击类型，值得专门增加连接数监控。
5. 确认攻击之后的应急处理思路
判断确认后，处理环节同样有讲究。这里不展开完整的DDoS防护方案（那是另一篇内容），只讲几个在判断环节之后必须马上做的动作，避免“判断对了、处理错了”的尴尬。
5.1 第一步：立刻确认防护能力和攻击规模是否匹配
判断确认后的第一个动作不是“硬扛”，而是评估自身防护能力。如果你的出口带宽只有100M，攻击流量已经到500M，此时无论服务器配置多高，带宽都会先被打满，业务一样不可用。这时候需要做的不是调服务器参数，而是联系上游带宽提供商或云服务商，启用流量清洗或黑洞策略。
评估核心指标是：攻击流量峰值 vs 自身出口带宽；SYN_RECV积压 vs 系统最大连接数限制；服务器CPU负载 vs CPU核数。三个指标中任意一个达到80%以上，说明系统正在资源耗尽边缘，必须快速决策。
5.2 第二步：先阻断再溯源，不要边阻断边溯源
很多人习惯先分析攻击来源再做处置，这个顺序在DDoS场景中是错的。DDoS攻击的特征是流量大、持续时间不定，多分析一分钟，业务就多瘫痪一分钟。正确顺序是：先用粗粒度手段将攻击流量挡在门外，再从容地分析日志、保留证据。
阻断手段按层级从低到高：在防火墙上设置ACL（拒绝特定来源IP）；在接入交换机上用黑洞路由将目标IP流量丢弃；在Web服务器上用iptables限制并发连接数和请求速率；有云WAF就走云WAF的防护策略。原则是越快恢复业务越好，溯源的工作放在业务恢复之后。
5.3 第三步：保留攻击前后完整证据链路
判断DDoS攻击的特征依赖日志，后续溯源、追责、改善防护同样依赖日志。确认攻击后，立刻备份以下数据：攻击开始前24小时的访问日志（用于建立正常基线）；攻击过程中的流量抓包文件（tcpdump抓5~10分钟即可）；防火墙和接入设备的告警日志；监控系统的性能曲线导出。
抓包操作建议在前面“实时观测”的命令基础上升级，加上时间窗口和端口过滤，保存为pcap文件备用：
timeout 300 tcpdump -i eth0 -nn -s0 -w attack_capture.pcap port 80 or port 443这组数据是后续做攻击溯源、出具分析报告、和云服务商对线索赔（如果有SLA）的核心依据。判断DDoS攻击从来不只是“知道是攻击”就完事，完整的证据闭环才能让一次排查产生长期的防护价值。
5.4 第四步：攻击结束后复盘防护短板
攻击结束后，对照前面四条特征做一次复盘：哪条特征最先暴露了攻击迹象？现有监控是否覆盖了该指标？攻击流量从哪个层级进入？现有防护在哪个环节失守？
我见过做得好的团队，会把每次DDoS攻击的关键数据归档成一张表：攻击类型、峰值流量、持续时间、攻击源IP段、最有效的阻断手段、从发现到恢复的耗时。积累几轮之后，再遇到攻击就能快速匹配历史模式，判断和处置效率会有质的提升。DDoS攻击的特征虽然多变，但攻击者的手法套路是有限的，用“历史经验库”去匹配新攻击，是最实用主义的高效路径。
6. 判断能力的底层：把监控做扎实比判断技巧更重要
说了这么多判断特征，最后想回到一个更根本的问题：判断DDoS攻击的所有技巧，都建立在一个前提上——你手上有可以查的数据。没有历史基线、没有访问日志、没有连接状态统计，再多的判断特征都是空中楼阁。我的实际体会是，把基础监控补齐，比研究攻击特征值更优先。
一个基础但完整的监控组合至少包括四层：网络层（带宽、出入流量、丢包率）；系统层（CPU、内存、连接数、负载）；应用层（QPS、响应时间、错误率、业务成交量）；安全层（防火墙拦截数、访问日志异常聚合）。四层数据配合，才能完整支撑“流量和业务指标是否偏离”这一核心判断逻辑。
尤其是连接数这个指标，很多团队没有纳入监控。DDoS攻击几乎都会体现在连接数的异常变化上——要么是连接总量暴涨，要么是半开连接积压，要么是连接长期占用不释放。把连接数趋势监控加上，慢速攻击这类隐蔽攻击也逃不过眼睛。
另外分享一个实操经验：监控数据尽量保留30天以上。DDoS攻击的特征判断极度依赖基线对比，如果只有当天的数据，异常发生后很难准确判断“这个流量值是不是正常”。保留一个月的监控数据，不仅方便判断攻击，还能帮你找出业务本身的流量节奏——正常的高峰时段、促销活动的流量形态、爬虫流量的日常占比，这些都是判断“异常”的对照物。
下次再遇到流量异常，别急着看服务器日志，先打开流量监控，把当前曲线和历史基线的差别看清楚，再用这篇文章里的四条特征逐条验证。判断DDoS攻击本质上是一个“对比”的过程——和基线对比、和正常行为对比、和业务指标对比。对比维度足够多，误判的概率自然就低。判断准确了，后续的防护动作才做得对。
