[工作经验]服务器CPU爆表救火记：从99%负载到问题根治的完整实战
问题截图
惊魂一刻：CPU使用率如过山车
周日晚上21点，正准备躺平追剧，手机突然响起服务器告警：CPU使用率99%！
打开监控面板一看，好家伙，CPU曲线像过山车一样，88度的陡峭山坡直冲云霄。作为一个有着丰富"救火"经验的程序员，我立刻意识到：这不是正常的业务高峰，肯定出事了！
![CPU监控图示意]
第一步：火速定位问题进程
登录服务器，第一时间查看进程状态：
top
映入眼帘的是触目惊心的数据：
- PID 126970 的 httpd 进程，CPU占用 99%
- 启动用户：root
- 其他几个 httpd 子进程也在疯狂吃CPU
这明显不正常！正常情况下，Apache子进程应该是www用户启动，而且不会有这么高的CPU占用。
第二步：深挖日志找真凶
作为运维老司机，我知道日志是最好的线索。立刻查看Apache错误日志：
tail -50 /www/wwwlogs/error_log
关键发现：
- 频繁的段错误：
[core:notice] child pid 63026 exit signal Segmentation fault (11)
- 恶意攻击请求：
[core:error] [client 185.131.53.100:56336] AH10244: invalid URI path
(/cgi-bin/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/bin/sh)
- 进程异常重启：
[mpm_event:warn] AH00488: long lost child came home! (pid 56486)
真相大白！ 这是典型的目录遍历攻击，攻击者试图通过../跳转到系统根目录执行恶意命令。
第三步：紧急止血
3.1 立即封禁攻击IP
从日志中提取到几个频繁攻击的IP：
- 185.131.53.100
- 185.242.226.74
- 47.237.177.222
# 立即封禁
iptables -I INPUT -s 185.131.53.100 -j DROP
iptables -I INPUT -s 185.242.226.74 -j DROP
iptables -I INPUT -s 47.237.177.222 -j DROP
# 保存规则
service iptables save
3.2 重启Apache服务
# 杀死异常进程
kill -9 126970
# 重启服务
systemctl restart httpd
效果立竿见影！ CPU使用率瞬间从99%降到正常水平。
第四步：根治问题 - 加固防护
光是临时止血还不够，必须从根本上解决安全隐患。
4.1 Apache安全配置
编辑Apache主配置文件：
vi /www/server/apache/conf/httpd.conf
添加关键安全规则：
# 防止目录遍历攻击
Require all denied
# 阻止常见攻击模式
Require all denied
# 优化进程配置，防止资源耗尽
StartServers 3
MinSpareServers 3
MaxSpareServers 10
ServerLimit 16
MaxRequestWorkers 400
ThreadsPerChild 25
⚠️ 重要提醒： 这里的进程配置是应急处理措施，可以暂时这么配置防止资源耗尽。事后等防火墙配置好了，可以恢复一开始的配置，以获得更好的性能表现。
4.2 宝塔面板安全设置
- 开启CC防护：网站 → 防火墙 → 开启CC防护
- 限制连接数：设置单IP最大连接数
- 开启WAF：拦截SQL注入、XSS等攻击
4.3 HTTPS安全加固
如果使用宝塔配置HTTPS，建议进行以下加密优化：
# SSL安全配置
SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256
SSLHonorCipherOrder on
SSLCompression off
第五步：监控验证
配置完成后，持续观察：
# 实时监控错误日志
tail -f /www/wwwlogs/error_log
# 监控CPU使用率
top
# 检查连接数
netstat -an | grep :80 | wc -l
结果： CPU使用率稳定在5%以下，无异常日志产生。
复盘总结：经验教训
问题根因分析
- 安全配置缺失：Apache默认配置对目录遍历攻击防护不足
- 监控不到位：未及时发现异常访问模式
- 应急响应滞后：告警后处理时间过长
最佳实践建议
🔥 应急处理三板斧：
- 定位进程：
top+ps快速找到异常进程 - 分析日志：错误日志是最好的线索
- 立即止血：封IP + 重启服务
🛡️ 预防措施五要素：
- 最小权限原则：禁用不需要的目录和功能
- 输入验证：严格验证所有用户输入
- 实时监控：设置CPU、内存、连接数告警
- 定期巡检：每周检查访问日志异常
- 安全更新：及时更新系统和软件版本
🌐 架构安全建议：
-
DNS安全解析：推荐使用安全的DNS解析服务，如CloudFlare DNS (1.1.1.1) 或阿里云DNS，避免DNS劫持和污染
-
CDN必不可少：强烈建议所有服务都要部署CDN！哪怕是再便宜的CDN也要上，起码能隐藏真实IP，防止攻击者直接打你的真实服务器。推荐：
- 国内：阿里云CDN、腾讯云CDN
- 国外：CloudFlare、AWS CloudFront
-
多层防护：CDN + WAF + 服务器防火墙，构建立体防御体系
工具推荐
- 监控工具：Zabbix、Prometheus + Grafana
- 日志分析：ELK Stack、Graylog
- 安全防护：CloudFlare、阿里云WAF
写在最后
这次"救火"经历再次证明了一个道理：安全无小事，预防胜于治疗。
作为技术人，我们不能等到服务器"发烧"了才想起来要"吃药"。平时的安全配置、监控告警、应急预案，每一个环节都不能马虎。
记住这句话：你的服务器可能正在被攻击，只是你还不知道而已。
🛡️ 安防服务推广
如果你的服务器也经常遭受攻击，或者需要专业的安防配置服务，欢迎私信我！
服务范围：
- 服务器安全加固
- 攻击防护配置
- 应急响应处理
- 宝塔专业版授权合作
嘿嘿嘿，专业的事交给专业的人，让你的服务器固若金汤！💪
本文基于真实生产环境问题整理，希望对同行有所帮助。如果你也遇到过类似问题，欢迎留言分享你的"救火"经验！
关注我，分享更多实战运维经验！ 🚀
