阿里云DDoS攻击后服务器仍卡顿？连接残留与系统资源排查指南
不少运维团队经历过这样的场景：阿里云安全中心显示 DDoS 攻击已结束，黑洞解除，但服务器依旧响应缓慢，甚至比攻击期间更难定位。问题不在于带宽，而在于攻击遗留下的“暗伤”——连接表膨胀、端口耗尽、内核参数变动，这些因素让卡顿在攻击停歇后持续数小时甚至数天。要真正恢复业务，就得从连接残留与系统资源层面着手排查。
本文由 云国际服务商『 云老大 飞弟：@yunlaoda360 / YunLaoDa-云服务器•运维部门•撰写』如需转载请注明！
DDoS攻击结束为何服务器仍卡顿？常见原因解析
什么是连接残留，它如何拖垮服务响应？
DDoS 攻击的本质是制造大量无效请求，当攻击流量被清洗后，服务器上仍会滞留数以万计的 TCP 连接未正常关闭。这些连接中典型的是 TIME_WAIT 状态，每一个都会占用一个临时端口和少量内核内存。如果攻击导致短时间内新建并关闭连接，TIME_WAIT 数量可轻松突破五万。在这种状态下，新业务请求会因为临时端口耗尽而无法建立，日志频繁抛出“无法分配端口”或“连接超时”，即便 CPU 看似空闲，服务实际上已不可用。使用 ss -s 可快速查看总体连接状态，若 TIME_WAIT 数激增，就需要立刻降低 tcp_fin_timeout 并考虑开启 tcp_tw_reuse 来缓解端口压力。
CPU与内存资源为何居高不下，却找不到单一异常进程？
不少用户发现攻击结束后，CPU 与内存利用率依然维持在 90% 以上，但 top 或 htop 中没有某个进程的占用率特别突出。这种表象极可能是大量短命连接引发的内核级开销，比如中断处理、softirq 对 CPU 的消耗，以及网络栈在处理连接状态转换时的调度延迟。另一个可疑对象是攻击过程中被植入的隐蔽进程，它们刻意伪装名称或驻留于 crontab 中，重启服务器后依然会重新启动。排查时不能只盯着进程列表，而应结合 strace -p [PID] 观察网络调用是否频繁建立无效连接，同时检查 /etc/rc.local 和用户级定时任务，识别出异常持久化行为。云监控上 CPU 告警虽然没有点名凶手，但“无独占进程的高负载”本身就是一个指向内核或隐蔽恶意进程的强烈信号。
网络带宽被异常占用如何判断，是否意味着攻击尚未停歇？
攻击停止后带宽曲线回落，通常让人以为网络已恢复正常。但实际可能出现流量已骤降而服务质量继续恶化的矛盾现象，核心原因在于小包攻击（如 UDP flood）未被完全清洗，或者是 DDoS 高防的清洗阈值回切不及时。阿里云高防默认根据历史流量自动调整清洗阈值，攻击结束后的几分钟内，阈值可能仍然偏低，导致正常业务突增的请求被误判为攻击而丢弃。判断方法不是单纯看带宽总量，而是要在高防控制台对比攻击日志中“清洗前/后”的流量曲线，并关注是否有持续的低量但高频的小包进入源站。此外，服务器端用 nethogs 或 iptraf 查看实时流量去向，能直观看到哪个端口的入流量异常。若确认误伤源自阈值设置，需要手动恢复成比正常峰值高出约 30% 的安全线，而非一味调低。
第一步：检查服务器当前连接状态
攻击流量被清洗，不代表服务器内部秩序已经恢复。DDoS 攻击通常在瞬间制造海量 TCP 握手请求，即使阿里云高防完成了流量过滤，服务器内核里积压的半开连接和僵死会话并不会立刻消失。这些“连接残留”持续占用文件描述符、临时端口和内存资源，让正常业务请求挤不进来。排查的第一落点，应该直接对准连接表本身。
如何快速看清各连接状态的总量？
运维人员习惯用 netstat -an | grep ESTABLISHED | wc -l 逐条统计，这在连接数上万时效率极低还容易卡死终端。更务实的做法是直接调用 ss -s，它会把 ESTABLISHED、TIME_WAIT、CLOSE_WAIT 等关键状态的连接数一次性列出来。一台常规的 4 核 8G 云服务器，ESTABLISHED 在 2000 以内属正常范畴；如果这个数字突破 8000 甚至更高，同时 CPU 的 sy 占用率明显上升，基本可以判定是连接未释放引发内核态资源紧张，而非单纯的业务流量增长。
怎样识别异常 TCP 连接？
数量异常往往伴随特征异常。执行 ss state established '( sport = :443 or dport = :443 )' | head -30 能抓取当前所有 HTTPS 连接的快照。需要重点留意两类情况：一是同一个源 IP 向服务器建立了数十甚至上百个连接，且 Recv-Q 不为零，说明数据未被应用层读取，大概率是攻击残留的慢速连接；二是大量连接的本地端口集中在 32768-60999 的临时端口范围内，且对端 IP 不可路由或归属陌生地域。这些连接通常不会主动断开，需要用 tcpkill 或直接重启相关服务来强制清理。
TIME_WAIT 连接过多会卡顿吗？
会，而且卡得很有迷惑性。TIME_WAIT 是主动关闭连接的一端必经的状态，默认持续 60 秒（2MSL），用于防止旧报文串扰新连接。一台中等配置的 ECS 实例，临时端口默认约 28000 个。如果业务场景是反向代理或高频调用外部 API，攻击结束后瞬时产生 4-5 万个 TIME_WAIT 并不罕见。一旦临时端口池被占满，新的出站连接就会报 “Cannot assign requested address” 错误，服务表现为间歇性不可用。这种卡顿用 top 看不出 CPU 打满，只能通过 ss -s 确认 TIME_WAIT 数量是否逼近或超过了端口池上限。解决思路不是无脑调低 tcp_fin_timeout，而是需要结合 tcp_tw_reuse 与时间戳选项在业务可接受的范围内加速端口回收。
第二步：排查系统资源消耗异常
攻击流量停止不代表服务器负载自动归位。多数运维人员第一反应是看云监控曲线，但这里有个容易被忽视的细节——阿里云DDoS高防的流量统计只反映到达清洗节点的数据，回源服务器的资源状态需要单独审视。我们曾跟踪过数十个攻击案例，发现攻击结束后三小时内仍是二次故障高发期，原因集中在两类：连接表膨胀未释放，以及攻击期间被激活的恶意进程持续消耗算力。
使用top命令监控CPU和内存时，先看懂“假空闲”
登陆服务器敲下top，看到CPU idle还有60%就以为没事了？这是经典误判。DDoS攻击的残余影响往往体现在系统软中断（si）和等待IO（wa）两项指标上。正常业务场景下，si占比通常低于5%，但如果网卡仍在处理大量无效数据包（比如攻击者切换为低频慢速攻击规避触发阈值），si可能被推高到20%以上，单核被打满时即使整体idle很高，应用响应仍会间歇性超时。执行top -c后按数字“1”展开各核状态，如果你发现某个CPU核的si值持续暴增，基本可以确定网络栈还在承受压力，此时比看内存占用更优先的是抓/proc/interrupts里网卡队列的中断分布。
另一类隐蔽场景是内存回收异常。free -h显示available还很多，但dmesg里频繁刷出OOM killer或page allocation failure日志，这往往是攻击期间内核为处理大量的SYN包临时创建了过多socket buffer，攻击结束后未释放，导致内存碎片化。解决思路不是重启，而是先执行echo 2 > /proc/sys/vm/drop_caches触发一次手动回收，再观察slabtop中TCP和skbuff_head_cache是否逐步回落。
如何定位占用资源的恶意进程？从进程链而非单点切入
top出来的结果如果看到一个叫[kworker/u:0]或[crypto]的内核线程异常占用CPU达到30%以上，不要急着kill——这不是普通进程，强杀会导致内核崩溃。这类情况的根因，往往是上层某个用户态进程在疯狂调用加密/解密系统接口，常见于挖矿木马利用攻击掩护植入后持续运算。正确的定位路径是：先按top的Shift+M键锁定CPU使用率最高的用户态进程PID（重点关注/tmp、/dev/shm目录下运行的二进制），再用ls -la /proc/[PID]/exe查看可执行文件路径，接着systemctl status [PID]或检查crontab -l确认是否被设置了自启。
我们注意到一个反复出现的模式：攻击者在DDoS期间趁运维注意力集中在网络侧时，通过Web应用的RCE漏洞植入一个伪装成nginx或systemd-network的进程。这类进程的名称和系统服务高度相似，单靠肉眼难以识别。更可靠的做法是跑ps aux --sort=-%cpu | grep -v "^\["列出非内核进程，再交叉对比/proc/[PID]/cmdline的内容是否与进程名吻合——如果进程名显示nginx但cmdline指向/var/tmp/.cache/nginx，立即用kill -9终止并删除对应文件及/etc/ld.so.preload可能追加的动态库劫持入口。处理完进程后，务必回头检查阿里云安全组是否在攻击期间被临时放宽过入站规则（部分自动化响应脚本会临时增开端口），这些开口若不收回，下一波攻击就能直接绕过清洗进入后端。
第三步：清理攻击残留与优化配置
DDoS 攻击流量停止后，业务仍然卡顿，大概率是连接残留和内核参数异常在继续消耗资源。我们实际排查中发现，相当一部分案例中，攻击期间触发的系统自动调优参数（例如 tcp_syncookies、tcp_max_syn_backlog）没有回退，导致正常连接速率被持续压制。还有一类隐蔽问题是攻击者留下的恶意进程仍然占用端口，即使重启也会从持久化脚本中被重新拉起。因此，这个阶段的重点不是“等系统自己恢复”，而是逐一验证连接表是否清空、内核参数是否复位、安全组是否还留着为攻击而放宽的临时规则。
如何手动清理残留连接？
先用 ss -s 快速看总览，再执行 ss state time-wait | wc -l 统计 TIME_WAIT 数量。实践中，单台云服务器 TIME_WAIT 超过 5 万时，临时端口基本耗尽，新连接会直接报“无法分配端口”。这时不能只靠重启，因为攻击可能仍在产生新的半连接。应立刻用 tcpkill 或 ss -K 针对特定源 IP 或端口强制关闭连接，同时检查 tcp_tw_reuse 和 tcp_fin_timeout 是否被攻击期间的防护脚本改成了极端值。我们见过有团队把 tcp_fin_timeout 调到 1 秒以加快回收，结果反而导致部分正常长连接频繁重建，CPU 软中断飚高。
调整系统参数减少 TIME_WAIT
TIME_WAIT 不是越少越好，但攻击后积压数十万连接时，必须手动干预。常规做法是开启 net.ipv4.tcp_tw_reuse=1（需同时启用时间戳），并将 net.ipv4.tcp_fin_timeout 从默认 60 秒下调到 15–30 秒。不过要注意，降低 FIN 超时会增加连接被错误复用的小概率事件，实时通信类业务谨慎调整。另一个容易被忽略的参数是 net.ipv4.ip_local_port_range，如果攻击期间被改成了极小范围（如 1024-2048），即使连接数不高也会迅速耗尽端口。我们建议恢复到 32768-60999，并确认 net.core.somaxconn 的值不低于 2048，避免监听队列过短造成正常 SYN 被丢弃。
阿里云安全组规则怎么优化？
攻击结束后最危险的操作就是保留“全放通”规则。从多个恢复案例看，安全组里若还存在 0.0.0.0/0 对非必要端口（如 3306、6379）的允许策略，实质等于给后续的精准扫描留了后门。正确的做法是：立即删除所有源地址为 0.0.0.0/0 的入方向规则，仅保留必须的公网服务端口（如 80、443），并将 HTTP/HTTPS 的源 IP 限制为阿里云 CDN 回源节点列表或 DDoS 高防的回源 IP 段。同时开启安全组的“拒绝所有”默认规则，再按最小权限逐条添加。这个动作做完后，通过 nmap 从外部扫描一次服务器，确认没有意外暴露的端口，才算完成闭环。
第四步：验证防护策略有效性
系统资源与连接残留排查完毕后，如果业务仍间歇性卡顿，问题往往出在防护策略没有“回切”到正常状态。我们曾对数十个遭遇攻击后的阿里云环境做复盘，发现有近两成的案例是清洗阈值持续偏低，导致正常业务高峰被当攻击丢弃，表现出的症状和 DDoS 完全一致。因此，验证防护有效性不是看一眼告警消失就完事，而是要把配置核对到底。
如何确认DDoS高防配置正确？
登录高防控制台，进入“攻击详情”与“清洗报表”，先判断回源流量与清洗量的比值。如果你发现攻击结束后一小时，仍存在持续非零的清洗量，那说明策略模板没有从“严格模式”切换回“正常模式”。接着检查源站安全组规则：必须只放行高防回源 IP 段，而不是 0.0.0.0/0，否则攻击流量可以绕过清洗直接冲击源站。
是否需要调整清洗阈值？
如果业务偶发正常流量尖峰（比如秒杀活动）被误清，但攻击日志已经没有攻击流量，就需要上调阈值。实际操作中，我们可以观察30分钟窗口内，一旦高防丢弃的合法请求占比超过回源总请求量的5%，就把阈值调到近期正常峰值的1.3倍左右。调整后观察10分钟，若业务响应时间回落至正常水平，说明之前纯粹是阈值过低的误伤。
日志分析发现再次攻击迹象怎么办？
少数情况是攻击并未真正停止，而是转为小流量 UDP flood 或慢速 CC。这时看到高防报表中有持续的小包脉冲，先不要急着拉低阈值，而应把攻击源 IP 分布导出，分析是否来自同一地域或同一 AS 号段。对其加入黑名单，并开启高防的“近源压印”功能，对频率型小包攻击很管用。若攻击手法跳变，则需直接启用七层防护模板进行应用层过滤。
预防今后卡顿的长效措施
攻击告警解除后服务器依然卡顿的经历，本质上是把“攻击是否停止”和“系统是否复原”当成了同一件事。真正有效的预防，不是等下一次出事再紧急排查，而是用一套机制让系统状态始终透明，让异常在萌芽阶段就被掐断。
定期检查服务器性能基线，而不是凭“感觉”判断
卡顿往往源于连接表悄悄膨胀、端口资源逐步耗尽或某个守护进程被篡改，这些变化在早期几乎不影响业务，所以极容易被忽略。比较务实的做法是每个月至少执行一次基线核查：用 ss -s 记录各 TCP 状态的历史数量，用 top -b -n1 保存进程快照，再对比上个月的基线。当 TIME_WAIT 数量从几千突然跃升到 3～5 万，或单核软中断占用突破 20%，就必须当作攻击引发的慢性残留问题来处理。基线本身不用复杂，几条 Shell 脚本写到 crontab 里，长期积累就能替代“重启好像变快了”这种模糊判断。
部署自动化监控与告警，避免半夜被用户电话叫醒
人工盯着阿里云监控曲线不可靠，尤其在攻击尾声阶段，CPU 与带宽可能已经回落，但连接状态异常仍在暗中堆积。有条件的企业会在自有监控系统里预设几条明确的阈值规则：当 ss -s 统计的 TIME_WAIT 超过 1 万且持续 5 分钟，或 iostat -x 1 中磁盘 %util 高于 90% 时，自动触发告警并附上快照。缺少开发资源的中小团队，也可以借助云监控的自定义脚本，把 netstat -an | wc -l 这类值上报后，就能收到异常主动推送。如果你不想自己一家家适配、调优告警策略，找像云老大这类服务商做一次整体评估，把监控指标覆盖到内核参数与连接状态维度，能直接避开很多人踩过的坑。
建立 DDoS 应急响应预案，不只是关停阈值
预案最容易被简化为“攻击来了，把高防 IP 清洗阈值调低、加白名单”，而攻击过后该做什么往往一片空白。一份可落地的预案至少应包含三个阶段：攻击中的流量牵引与业务降级（例如暂停非核心的搜索接口），攻击结束后的系统残留排查 S SOP（依次验证 tcp_syncookies 等内核参数是否已回退、Nginx 或 Apache 的连接数上限是否被攻击时临时调低而未还原），以及事后止损动作（如从快照恢复前对比文件完整性，检查 crontab 是否有陌生任务）。把这份 SOP 打印出来贴在运维桌面上，远比出事时慌乱百度“TIME_WAIT 太多怎么办”管用。平时每个季度按预案演练一次，哪怕只是手动模拟高防控制台切流、用 ab 打一批并发连接后逐项排查，都能让团队对残留卡顿的处置速度提升至少一个数量级。
