无活跃用户时WHM/cPanel主机lsphp进程高CPU占用的排查与请求来源定位问询

兄弟，这种情况确实闹心——GA显示没活人访问，但服务器CPU被lsphp拉满，还钉死在/product/index.php上，结合你开了Cloudflare攻击模式和CSF还没解决，咱们一步步来排查：

一、精准揪出请求来源（突破Cloudflare代理的IP隐藏） #

Cloudflare的代理会把真实IP藏在X-Forwarded-For头里，咱们得从日志和抓包双管齐下：

• 实时监控LiteSpeed访问日志：cPanel下LiteSpeed的站点日志一般在/home/username/logs/目录，找到对应域名的访问日志（比如yourdomain.com.access_log），用命令实时追踪：

  tail -f /home/username/logs/yourdomain.com.access_log | grep "/product/index.php"
  

  重点看日志里的X-Forwarded-For字段（这是Cloudflare传递的真实访客IP），还有请求的User-Agent、请求频率。如果短时间内刷出大量相同IP或奇怪UA（比如带curl、python-requests的），那基本就是CC攻击了。
• 用tcpdump抓原始流量：要是日志信息不够细，直接抓服务器上的HTTP/HTTPS流量，过滤目标文件的请求：

  tcpdump -i any port 80 or 443 | grep "/product/index.php"
  

  这个能看到最原始的IP和请求内容，还能和Cloudflare的防火墙日志交叉验证——去Cloudflare后台看“安全>防火墙”里的日志，对比服务器抓到的IP，确认是不是恶意请求。
• 检查CSF的拦截日志：CSF的攻击日志在/var/log/lfd.log，搜你的用户名看看有没有相关封禁记录：

  grep "lfd:" /var/log/lfd.log | grep "username"
  

  要是有大量IP被临时封禁，说明确实有攻击在撞你的站点。

二、排查/product/index.php本身的问题（哪怕你说没改文件） #

有时候“没修改”不代表没问题，咱们得确认：

• 核对文件修改时间：用stat命令看文件的最后修改时间，确认是不是真的没被篡改：

  stat /home/username/public_html/product/index.php
  

  如果mtime和你上次维护的时间对不上，大概率是被植入了恶意代码（比如挖矿脚本、后门），可以直接打开文件搜eval()、base64_decode()这类常见恶意特征，或者和备份文件对比差异。
• 手动测试文件CPU消耗：直接在命令行执行这个PHP文件，看是不是代码本身有死循环或低效逻辑：

  cd /home/username/public_html/product/
  php index.php
  

  执行的时候开着htop看CPU，如果手动跑也拉满，那就是代码问题——比如某个循环没终止，或者数据库查询没加索引导致全表扫描卡死。
• 查看PHP错误日志：LiteSpeed的PHP错误日志在/home/username/logs/php_error.log，搜index.php看看有没有报错：

  grep "index.php" /home/username/logs/php_error.log
  

  比如数据库连接失败后的无限重试、未处理的异常导致的重复执行，都可能导致CPU跑满。

三、结合现有防护细化规则（别让Cloudflare和CSF白开） #

既然已经开了攻击模式和CSF，咱们得把规则调得更精准：

• Cloudflare端：在“规则>速率限制”里给/product/index.php单独设限制，比如每分钟最多10次请求，超过直接拦截；另外开启“Bot Fight Mode”（或Super Bot Fight Mode）过滤恶意爬虫和自动化工具。
• CSF端：调整/etc/csf/csf.conf里的CT_LIMIT（单IP最大连接数），比如从默认的100调到30，同时确保CT_BLOCK设为1，自动封禁超标的IP；还要把Cloudflare的所有IP段加到csf.allow里，避免CSF误封Cloudflare的代理IP（不然正常用户也进不来）。
• LiteSpeed端：在cPanel的“LiteSpeed Web Server”设置里，给该域名限制PHP进程的最大数量，或者缩短PHP执行超时时间，避免单个lsphp进程长时间占用CPU。

备注：内容来源于stack exchange，提问作者omid