恶意爬虫非常可恶，设置托管质询

(http.host eq ".se"
 and
 not starts_with(http.request.uri.path, "/cdn-cgi/challenge-platform/")
 and
 not starts_with(http.request.uri.path, "/.well-known/")
 and
 (
   (
     http.request.uri.path eq "/wp-login.php"
   )
   or
   (
     http.request.method in {"GET" "HEAD"}
     and
     (
       http.request.uri.path eq "/shop/"
       or http.request.uri.path eq "/es/shop/"
       or http.request.uri.path eq "/fr/shop/"
       or starts_with(http.request.uri.path, "/shop/page/")
       or starts_with(http.request.uri.path, "/es/shop/page/")
       or starts_with(http.request.uri.path, "/fr/shop/page/")
     )
   )
   or
   (
     (
       starts_with(http.request.uri.path, "/size/")
       or starts_with(http.request.uri.path, "/es/size/")
       or starts_with(http.request.uri.path, "/fr/size/")
     )
     and
     lower(http.request.uri.query) contains "filter_tax_"
   )
 )
)

现在状态分两层看：

1、PHP 并发限制已经成功

你现在的关键数据：

Mem available: 4.0Gi
Swap used: 1.4Mi
lsphp: 21
Threads_connected: 3
Threads_running: 2
SHOW FULL PROCESSLIST: 基本为空

这说明：

maxConns 20
PHP_LSAPI_CHILDREN=20

已经生效了。

pgrep -fc lsphp = 21 是正常的，基本就是：

1 个 lsphp 主进程
20 个 worker 子进程

所以第一步止血成功了。

---

2、现在剩下的问题是 CPU 仍然被动态请求打高

内存已经恢复，但 vmstat 里 CPU 仍然有多次接近满载：

us = 94% ~ 96%
id = 0% ~ 3%
r = 4 ~ 8

数据库当前不是主要瓶颈，因为：

Threads_connected = 3
Threads_running = 2
SHOW FULL PROCESSLIST 基本为空

所以现在更像是：PHP 正在处理大量前端请求，不是数据库连接被打满。

最明显的入口是这个：

677 //xmlrpc.php
656 /shop/
390 /es/shop/
341 /fr/shop/
132 /shop/page/2/
121 /shop/page/4/
121 /es/shop/page/4/
67 /wp-login.php
40 trp-ajax.php

现在最该处理的是：xmlrpc.php、wp-login.php、shop 分页。

---

第一优先级：马上封 XML-RPC

你现在 //xmlrpc.php 在最近 5000 条访问里排第一：

677 //xmlrpc.php

这说明 XML-RPC 请求还在打到源站。

如果你已经在 Cloudflare 设置了规则，那说明规则没有匹配到 //xmlrpc.php，或者规则还没生效。

Cloudflare WAF Custom Rule 用这个：

(http.host eq ".se"
 and lower(http.request.uri.path) contains "xmlrpc.php")

动作：

Block

不要用：

http.request.uri.path eq "/xmlrpc.php"

因为你的日志里大量是：

//xmlrpc.php

eq "/xmlrpc.php" 可能匹配不到双斜杠请求。

---

源站也加一道保险

Cloudflare 规则生效前，你可以在 WordPress 根目录 .htaccess 里加一道源站拦截。

文件位置：

/usr/local/lsws/.se/html/.htaccess

先备份：

cp /usr/local/lsws/.se/html/.htaccess /usr/local/lsws/.se/html/.htaccess.bak.$(date +%F-%H%M)

编辑：

nano /usr/local/lsws/.se/html/.htaccess

在 WordPress 规则之前加入：

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_URI} (?i)/+xmlrpc\.php
RewriteRule ^ - [F,L]
</IfModule>

保存后不一定需要重启，OpenLiteSpeed 会读取 .htaccess。

然后测试：

curl -I --max-time 10 https://.se/xmlrpc.php
curl -I --max-time 10 https://.se//xmlrpc.php

理想结果是：

403

或者 Cloudflare 返回拦截页面。

---

第二优先级：wp-login.php 加 Challenge

最近 5000 条里：

67 /wp-login.php

这个数量不算最大，但对 WordPress 来说也应该保护。

Cloudflare WAF Custom Rule：

(http.host eq ".se"
 and http.request.uri.path eq "/wp-login.php")

动作：

Managed Challenge

如果你只允许自己登录后台，更狠一点可以做 IP Allowlist，但先用 Managed Challenge 比较安全。

---

第三优先级：shop 分页做限速

现在 /shop/ 和多语言 shop 页访问非常高：

656 /shop/
390 /es/shop/
341 /fr/shop/
132 /shop/page/2/
121 /shop/page/4/
121 /es/shop/page/4/
118 /es/shop/page/3/
111 /fr/shop/page/3/

这类 WooCommerce 商品归档页通常是动态重页面。

你现在 PHP worker 虽然被限制到 20，但这 20 个 worker 仍然会被 shop 请求吃满。

Cloudflare Rate Limiting 规则可以先这样做：

(http.host eq ".se"
 and http.request.method in {"GET" "HEAD"}
 and
 (
   http.request.uri.path eq "/shop/"
   or http.request.uri.path eq "/es/shop/"
   or http.request.uri.path eq "/fr/shop/"
   or starts_with(http.request.uri.path, "/shop/page/")
   or starts_with(http.request.uri.path, "/es/shop/page/")
   or starts_with(http.request.uri.path, "/fr/shop/page/")
 )
)

动作建议：

Managed Challenge

或者 Rate Limit，例如：

10 requests / 10 seconds / same IP

对普通用户影响不大，但会明显压住连续翻页爬虫。

---

第四优先级：TranslatePress 先观察，不要直接 Block

现在 trp-ajax.php 有：

40 /wp-content/plugins/translatepress-multilingual/includes/trp-ajax.php

这个比之前少很多，当前不是第一压力源。

暂时不要直接 Block：

trp-ajax.php

否则可能影响语言切换、翻译字符串加载或前台兼容性。

可以先观察，如果它又升到几百上千，再做温和限速。

---

现在你应该执行的下一组检查

先封 XML-RPC 后，等 2--5 分钟，再执行：

tail -n 5000 /usr/local/lsws/.se/logs/access.log \
| awk '{print $7}' \
| cut -d'?' -f1 \
| sort \
| uniq -c \
| sort -nr \
| head -40

再执行：

vmstat 1 10

和：

pgrep -fc lsphp
free -h
mysql -e "SHOW GLOBAL STATUS LIKE 'Threads%';"
mysql -e "SHOW FULL PROCESSLIST;"

判断标准：

//xmlrpc.php 明显下降或消失
lsphp 保持 21 左右
available memory 保持 3G+
Threads_connected 不再冲高
vmstat 的 id 不再长期接近 0

你现在已经把"60 个 PHP worker 拖死服务器"的问题压住了。下一步不是继续调 maxConns，而是把 //xmlrpc.php 和 shop 分页爬虫挡在 Cloudflare / 源站之外。