服务器被DDoS打满带宽：自查连接分布与限速缓解

发布时间：2026-09-22 12:30 更新时间：2026-09-22 12:30 阅读量：0

带宽被打满时，服务器本身往往没有明显异常：CPU 不高、磁盘不忙，但网站就是打不开，SSH 也一卡一卡。这时候要做的第一件事是判断流量性质——是自己的业务真的涨了，还是有人在刷连接。判断清楚之后再决定是限速扛住，还是把流量交给云厂商清洗。不要一上来就封 IP，攻击源通常成千上万，封几个没有意义，还可能误伤真实用户。

先看连接分布：ss 和 netstat 怎么读

老服务器上习惯用 netstat，新系统更推荐 ss，它直接从内核 netlink 取数据，连接数上万时速度快很多。用法上两者接近，netstat -an 对应 ss -an。先按状态统计一下：

ss -s
ss -an | awk '{print $1}' | sort | uniq -c | sort -rn

如果 SYN-RECV 数量巨大，说明对方在用大量半开连接消耗你的连接表，属于典型的 SYN 洪水特征；如果 ESTAB 很多但来源 IP 高度集中，可能是少数几个 IP 在刷接口；如果连接数正常但 ss -ti 里显示大量重传，那更可能是链路问题而不是攻击。再看来源 IP 的 TOP 排行：

ss -an | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn | head -20

这一步能帮你区分两种场景：攻击流量是均匀撒在成千上万个 IP 上，还是集中在少数几个网段。前者基本只能靠上游清洗，后者可以在本机用防火墙先挡一挡。注意：ss 输出里 Local Address:Port 和 Peer Address:Port 的列位置在不同发行版上可能略有差异，以你机器上实际输出为准，必要时加 -H 去掉表头再配合 awk 处理。

本机应急：iptables 限速与连接数限制

在云清洗生效之前，本机可以先做两层缓解。第一层是限制单个 IP 的新建连接速率，防止少数来源刷爆连接表：

# 每个来源 IP 每分钟最多 60 个新建连接，超出则丢弃
 iptables -I INPUT -p tcp --syn -m hashlimit \
   --hashlimit-name syn_limit \
   --hashlimit-above 60/min \
   --hashlimit-burst 20 \
   --hashlimit-mode srcip \
   -j DROP

第二层是限制单 IP 的并发连接总数，适合接口被刷的场景：

iptables -I INPUT -p tcp --dport 443 -m connlimit \
   --connlimit-above 50 --connlimit-mask 32 -j REJECT --reject-with tcp-reset

两条规则都插在 INPUT 链最前面，测试完记得用 iptables -L -n --line-numbers 确认顺序，规则多了以后顺序错会互相抵消。另外要注意 hashlimit 和 connlimit 属于 xtables 扩展模块，部分精简系统默认没加载，先 modprobe 或确认内核支持再用，具体以官方文档和实际环境为准。这些手段只能缓解小规模流量，如果入口带宽本身已经被占满，本机一切配置都救不回来，因为包根本到不了你的网卡。

还有一个容易被忽略的点：限速规则本身也消耗 CPU。连接表被塞满时，内核会频繁做哈希查找，ksoftirqd 可能跑满单核。所以缓解的同时用 top 和 mpstat -P ALL 1 盯着软中断分布，必要时配合网卡多队列分散处理。

云厂商清洗：触发条件与配合动作

如果入口流量已经超过你购买的基础防护阈值，就得靠云厂商的流量清洗。各家产品命名和门槛不同，但触发逻辑大体一致：当公网入方向流量持续超过防护阈值一段时间后，自动把流量牵引到清洗中心，清洗后再回注。常见触发条件包括入方向带宽持续超过基础防护值、PPS（每秒包量）超过阈值，或者命中某些特征规则。阈值、持续时间和是否自动开启，都要以你购买的产品文档为准，很多云厂商的基础防护只覆盖一定带宽，超出部分要么按量计费要么直接黑洞。

被打的时候建议同时做三件事。第一，登录云控制台看流量监控曲线，确认是入方向还是出方向被打，出方向异常通常是服务器自己有问题，比如被入侵后对外发包。第二，如果站点前面有 CDN 或高防 IP，把源站 IP 换成只允许回源节点访问，避免攻击者绕过防护直接打源站。第三，把 DNS 的 TTL 提前调低，方便被打时快速切换解析。这些动作平时就该准备好，临时做往往来不及。

最后提醒一句：DDoS 是流量层面的问题，和服务器自身安全加固是两件事。日常把 SSH 密钥登录、防火墙最小放行、系统补丁这些做好，能减少被利用的风险，但挡不住纯粹的流量洪峰。真正有效的应对是提前评估业务能承受的带宽上限，配置好云防护阈值，再准备一套切换预案。出现异常先看 ss 连接分布判断性质，本机限速作为过渡，主力还是交给上游清洗，这样处理起来会从容很多。

继续阅读