被逗比攻击，菊花”不可描述”了2天！
如果你的服务器被攻击到数据库目录被塞满垃圾日志、入口带宽被打瘫，最快2小时可以恢复基础服务，但数据完整修复可能要2天，本文用一次真实遭遇讲清楚香港服务器被DDoS后的完整排查与自救流程。
被逗比攻击的第一天：症状从”卡顿”到”菊花残”
那天早上我照常打开运维后台，发现监控面板上的出入流量曲线像被猫抓过一样，入站带宽直接怼满100Mbps，而平时这个数字只有2-3Mbps，一开始以为是谁在跑爬虫，没太在意，到了中午，网站开始间歇性502，数据库连接数爆表，登录服务器敲命令都感觉”肉肉的”,延迟从正常的30ms飙到800ms。
真正让我意识到不对劲的，是下午两点左右，服务器彻底”菊花不可描述”SSH都连不上了，ping只能偶尔通一下，丢包率超过70%，这种症状基本可以断定：被打了，而且是那种不带脑子的流量型攻击典型的SYN Flood加HTTP Flood混合，业内俗称”逗比攻击”，因为攻击者根本不管你的业务是什么，纯粹拿僵尸网络的路由器、摄像头当炮灰,一顿乱拳打死老师傅。
给服务器”验伤”：被攻击后最先崩溃的往往是日志分区
恢复SSH后第一件事，不是看流量,而是看磁盘。
df -h结果显示/dev/vda1使用率6%,再查大文件：
du -sh /var/log/ | sort -rh | head -20真相浮出水面：/var/log/nginx/access.log已经膨胀到37GB，/var/log/messages也有12GB，攻击者制造的海量无效请求被Nginx照单全收，每秒上千条日志写入直接把磁盘写满了，磁盘满之后，MySQL的binlog也写不进去了，数据库引擎直接进入只读保护模式，这才是”菊花不可描述”的真正元凶不是带宽，是日志把系统盘塞爆了。
你以为带宽被打是主要矛盾，其实日志刷盘才是内伤，这个过程很多运维新手会忽略，因为流量监控面板上的数字太扎眼，容易让人忽略磁盘、CPU、连接数这些底层指标，行业共识认为，DDoS攻击的次级伤害往往比流量本身更致命。
香港服务器被DDoS后的止血三步：从拒绝服务到服务降级
第一步：先屏蔽攻击源IP段，别指望”硬扛”
香港服务器有个特点：带宽通常按Mbps计费，超额流量费用极高，硬扛不用一分钟，账单就能让你心疼，我的做法是登录防火墙（用的是firewalld
）,先封掉当时抓到的几个高频来源IP段：
firewall-cmd --permanent --add-rich-rule='rule family=ipv4 source address=103.xx.xx.0/24 port port=80 protocol=tcp reject'
firewall-cmd --reload这些IP段多数来自境外VPS的跳板机，封了之后连接数立刻从7万降到2万。
第二步：限流Nginx连接数，让正常用户还有口饭吃
封IP治标不治本，攻击者可以不停换源，更务实的做法是限制单IP连接频率,在Nginx配置里加入：
limit_conn_zone $binary_remote_addr zone=perip:10m;
limit_conn perip 10;
limit_req_zone $binary_remote_addr zone=reqlimit:10m rate=5r/s;这招的作用是：即便攻击流量还在，每IP的并发和请求速率被锁死，正常访客最多就是慢一点，不会完全打不开，这步操作在Linux服务器防CC攻击的场景下属于标配动作,不复杂但必须做。
第三步：清理日志，给磁盘腾出生存空间
> /var/log/nginx/access.log
journalctl --vacuum-size=500M
find /var/log -name ".gz" -mtime +7 -delete清理完日志后重启MySQL和Nginx，站点在当晚11点左右恢复访问，但速度依然不稳定,这是后续高防方案上线前必然经历的阵痛。
被攻击后的第二天：数据恢复与”内伤”排查
第二天主要做两件事：确认数据完整性和定位是否有后门文件被植入。
MySQL数据完整性的自查方法
攻击过程中MySQL频繁写入失败，可能会导致表损坏，不要直接信任innodb_force_recovery,先跑一遍检查：
mysqlcheck -u root -p --all-databases --check-only如果有表提示Table is marked as crashed，需要用myisamchk（MyISAM表）或直接使用REPAIR TABLE命令（InnoDB表一般很少损坏，但如果是在磁盘满时强制关闭，也可能出现误报）。
我当时的处理结果是：两个搜索建议表（MyISAM）损坏，重建索引后恢复正常，核心业务数据表毫发无损，这也符合InnoDB崩溃恢复机制的行业常识双写缓冲和重做日志能兜住大部分异常断电场景。
检查后门文件：攻击者通常不止打流量
查看最近的Webshell特征文件,用了一个很土但有效的方法：
find /usr/share/nginx/html -name ".php" -mtime -3 -type f
find /tmp /dev/shm -type f -name ".sh" -mtime -3攻击者用的是无脑流量包，没有留下网页后门，但在/tmp目录下发现了一个残留的
xmr.sh文件矿工程序的下载脚本，说明流量攻击之前僵尸网络已经尝试过植入挖矿木马，只是没成功，清理掉后，顺手检查了crontab -l和/etc/rc.local,确认没有定时任务残留。
不可描述的两天后，反思与加固：下一次怎么活下来
免费方案与收费方案的性价比对比
这次攻击全程没有启用高防，属于裸奔中招,事后罗列一下可选方案：
| 防护方案 | 成本 | 防御效果 | 适用场景 |
|---|---|---|---|
| Cloudflare免费版 | 0元 | 只能防小规模CC，带宽消耗型攻击基本挡不住 | 个人博客、低价值站点 |
| 香港本地高防IP | 约几百元/月 | 防御50-100Gbps流量型攻击，但延迟会增加约20ms | 面向东南亚和国内用户的业务站 |
| 国内BGP高防 | 数百至数千元/月 | 防御能力强，但需备案域名 | 国内用户为主、有备案条件的站点 |
| 自建CDN+源站白名单 | 成本可控 | 需要一定的运维能力，能有效隐藏源站IP | 有技术储备的团队 |
以我这次的情况，50Gbps左右的小规模流量攻击，其实Cloudflare的免费版都扛得住一部分，但问题在于我的服务器直接暴露了IP，CDN根本没接,等于攻击者可以直接绕过防御打源站。
核心教训：隐藏源站IP比堆带宽更重要
攻击者为什么会直接打到我？因为我的域名解析里，A记录直接指向了服务器IP，没有任何CDN前置，换句话说，香港服务器被DDoS怎么办的第一原则，是别让人知道你的服务器IP,具体操作包括：
- 将DNS解析切换至Cloudflare或国内CDN，开启代理模式（橙色云朵图标）
- 所有主动外联请求（如API回调、邮件发送）走独立子域或独立IP，避免暴露主站IP
- 服务器防火墙只放行CDN节点IP段，直接拒绝其他来源的80/443端口访问
这些做法不需要太高成本，但缺了任何一环,你都可能成为下一次攻击的靶子。
关于服务器租用价格和地域选择的实话
如果你正在对比香港服务器和其他地域节点的价格，行业内的公开行情大概是：入门级2核4G香港VPS年付在300-600元区间，带高防的同配置产品会贵50%-100%，有些商家宣称”无限防御”，实际是共享高防机房带宽，单IP被攻击时可能被黑洞路由暂时屏蔽1-2小时这种比被打还难受，因为
黑洞意味着你的IP直接断网。
我的建议是：如果网站有稳定业务收入，别在防护上省那几十块钱，反过来，如果只是测试项目，被打了就关机止损，等攻击结束再开机,成本最低。
服务器被攻击后关于数据备份的追问：为什么恢复花了2天？
很多人会问，为什么清理完日志、恢复数据库后，还花了2天才算真正收尾？答案在于观察期，攻击者可能会在首次攻击后72小时内发起二次试探，确认你是否放松警惕,这两天里我做了三件事：
- 持续监控
ss -lnt中SYN_RECV状态连接数，如果这个数超过1000就说明还在被SYN Flood锤 - 将
/var/log/nginx/access.log接入logrotate，日志每天切割，压缩保留3天 - 给重要数据目录（如
/usr/share/nginx/html和MySQL的datadir）加了每日定时异地备份，备份路径直接写到独立的OSS/挂载盘
这些操作全部完成后，去掉防火墙里临时封禁的IP段规则，放开Nginx的limit_req限速（因为太严会误伤搜索引擎爬虫）,才敢让服务回到满负荷状态。
常见问题：服务器被攻击后恢复要多久？
被DDoS攻击后服务器里的数据会不会丢？
大概率不会丢，流量型攻击的本质是堵塞带宽和消耗资源，并不直接读写或删除磁盘文件，但日志分区被写满会导致数据库无法写入新数据，这部分”增量数据”可能会丢失，所以恢复后的第一件事永远是检查磁盘空间和数据库完整性,而不是急着上线。
怎么判断服务器是被攻击还是硬件故障？
看三个指标：带宽占用率、TCP连接数、CPU负载，三者同时爆表且持续时间超过10分钟，基本可以判定是DDoS攻击，硬件故障通常表现为单项指标异常（如磁盘IO卡死但带宽正常）,且没有固定的来源IP流量模型。
国内高防服务器和香港高防服务器选哪个？
如果用户群体在国内、域名为已备案状态，且对延迟敏感，选国内BGP高防，防御清洗能力强，延迟最低，如果不想备案、面向跨境业务，选香港高防服务器，但需要接受更大的网络抖动和相对有限的防御带宽，通常个人开发者和小型团队会选择后者，因为省去备案环节,成本模型简单清晰。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/665758.html
