[工作经验]服务器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

关键发现：

1. 频繁的段错误：

   [core:notice] child pid 63026 exit signal Segmentation fault (11)

2. 恶意攻击请求：

   [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)

3. 进程异常重启：

   [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

添加关键安全规则：

# 防止目录遍历攻击
<Directory />
    AllowOverride None
    Require all denied
</Directory>

# 禁用危险目录
<LocationMatch "/(cgi-bin|bin|etc|tmp)/">
    Require all denied
</LocationMatch>

# 阻止常见攻击模式
<LocationMatch "\.\.|%2e%2e|%252e|%%32%65">
    Require all denied
</LocationMatch>

# 优化进程配置，防止资源耗尽
StartServers 3
MinSpareServers 3
MaxSpareServers 10
ServerLimit 16
MaxRequestWorkers 400
ThreadsPerChild 25

⚠️ 重要提醒： 这里的进程配置是应急处理措施，可以暂时这么配置防止资源耗尽。事后等防火墙配置好了，可以恢复一开始的配置，以获得更好的性能表现。

4.2 宝塔面板安全设置

1. 开启CC防护：网站 → 防火墙 → 开启CC防护
2. 限制连接数：设置单IP最大连接数
3. 开启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%以下，无异常日志产生。

复盘总结：经验教训

问题根因分析

1. 安全配置缺失：Apache默认配置对目录遍历攻击防护不足
2. 监控不到位：未及时发现异常访问模式
3. 应急响应滞后：告警后处理时间过长

最佳实践建议

🔥 应急处理三板斧：

1. 定位进程：top + ps 快速找到异常进程
2. 分析日志：错误日志是最好的线索
3. 立即止血：封IP + 重启服务

🛡️ 预防措施五要素：

1. 最小权限原则：禁用不需要的目录和功能
2. 输入验证：严格验证所有用户输入
3. 实时监控：设置CPU、内存、连接数告警
4. 定期巡检：每周检查访问日志异常
5. 安全更新：及时更新系统和软件版本

🌐 架构安全建议：

1. DNS安全解析：推荐使用安全的DNS解析服务，如CloudFlare DNS (1.1.1.1) 或阿里云DNS，避免DNS劫持和污染

2. CDN必不可少：强烈建议所有服务都要部署CDN！哪怕是再便宜的CDN也要上，起码能隐藏真实IP，防止攻击者直接打你的真实服务器。推荐：

   • 国内：阿里云CDN、腾讯云CDN
   • 国外：CloudFlare、AWS CloudFront

3. 多层防护：CDN + WAF + 服务器防火墙，构建立体防御体系

工具推荐

• 监控工具：Zabbix、Prometheus + Grafana
• 日志分析：ELK Stack、Graylog
• 安全防护：CloudFlare、阿里云WAF

写在最后

这次”救火”经历再次证明了一个道理：安全无小事，预防胜于治疗。

作为技术人，我们不能等到服务器”发烧”了才想起来要”吃药”。平时的安全配置、监控告警、应急预案，每一个环节都不能马虎。

记住这句话：你的服务器可能正在被攻击，只是你还不知道而已。

🛡️ 安防服务推广

最后打个小广告：如果你的服务器也经常遭受攻击，或者需要专业的安防配置服务，欢迎私信我！

服务范围：

• 服务器安全加固
• 攻击防护配置
• 应急响应处理
• 宝塔专业版授权合作

嘿嘿嘿，专业的事交给专业的人，让你的服务器固若金汤！💪

本文基于真实生产环境问题整理，希望对同行有所帮助。如果你也遇到过类似问题，欢迎留言分享你的”救火”经验！

关注我，分享更多实战运维经验！ 🚀

本作品采用《CC 协议》，转载必须注明作者和本文链接